Ultra-large scale software-intensive systems exist in a wide variety of application domains. Classical examples are Internet-wide decision support systems, command and control, telecommunications, as well as modeling and simulation. Increasingly, however, the same set of challenges also arises in the domain of automotive software and other technical domains. In automotive, for instance, thousands of software-enabled functions are distributed over up to 80 Electronic Control Units (ECUs) that are connected via multiple different networking protocols and technologies.
Our basic research on systems of systems integration solutions is grounded in this wide spectrum of application domains. We have successfully applied our research and development results to projects covering all the application domains mentioned above.
Establishing the correct interplay among the components in a distributed, reactive system is one of the crucial development tasks. Model-based development has been suggested as a means for capturing key structural and behavioral requirements of the system under consideration before code is written by hand or generated automatically. However, most of the corresponding development approaches focus on components as the central development entity, leaving the integration of the resulting components as a separate, difficult and error-prone task. We are developing a fresh approach, where services, not the components implementing them, are the center of concern from the early phases of requirements capture all the way to implementation.
Long-lived, large-scale system of systems integration efforts will bring together a wide variety of stable and emerging applications, systems and underlying technologies. This induces a mix of stable and emerging requirements, as well as a correspondingly broad spectrum of risks and agility demands. Therefore, we propose instituting a tailored development process that takes this broad spectrum into account.
We work with a development process consisting of two phases: service elicitation and architecture definition. In the first phase we develop a logical model of the system’s services and their dependencies. In the second phase we establish a mapping from the set of services to target architectures. This separates functionality from structure and enables the support of product-line variations, as well as modifications of the target architectures or technical infrastructures.
SAINT also has extensive experience in tailoring both agile and plan-driven development processes towards the needs of large scale systems of systems integration projects. Development processes and process models we have successfully tailored in the past include SCRUM, Rational Unified Process, EIA-632, and XP.
We are developing a a prototypic toolchain for supporting the service-oriented development process outlined above. One purpose of the tool support is to provide models for services that can be transformed into executables. The tool chain consists of several ingredients: a process support tool (SODA), our center-piece service modeling tool for modeling roles and their interactions (M2Code), a modeling, simulation, verification and test tool for component configurations (MSCCheck), code generators for the RTCORBA middleware platform (RTCodeGen) and for aspect-oriented implementations (M2Aspects), as well as model-checking and reverse engineering tools.
Based on this tool suite we have developed a runtime monitoring approach for Quality-of-Service properties (including deadlines) in real-time environments. To that end we have combined the end-to-end protocol modeling capabilities of M2Code with the automatic generation of a distributed runtime monitoring facility; this facility can determine on a per-service basis whether all QoS properties are met at runtime.
M2Code is our tool for modeling roles and their interactions, which are the defining elements for services. Thus, M2Code covers, in particular, the early phases of the service-oriented development process. A centerpiece of M2Code is its capability for (semi)automatically deriving state machines from interaction patterns given as Message Sequence Charts (MSCs). In particular, it can deal with overlapping, alternatives, parallel composition, loops, and preemption.
The output of M2Code is a role domain model together with one automaton for each role defined in this domain model; these automata implement the respective role's contribution to all the services it is associated with.
M2 Code is built as a plugin for Microsoft Visio, and visualizes both the MSCs entered by the developer and, using automated layout algorithms, displays state machines for validation purposes.
Finally, M2Code supports exporting the modeling elements (both the automata and the system structure, i.e. the role domain model) as an XML document preparing verification/validation and code generation.
We are developing a coge generator that takes abstract, validated models of distributred, reactive systems as input, and produces executables for the RT CORBA middleware implementing the properties checked for the abstract models. This closes a gap in the development process for reliable distributed and reactive systems by eliminating the manual transition from captured requirements to implementation.
The SODA tool (Service-Oriented Design and Architecture Development) governs the development process and provides project support by managing project resources and tracking project progress. It embeds and triggers other tools and has the capability of generating project relevant documentation and reports. The SODA tool is a platform for capturing and cross-referencing information about a system or software under development. Information is structured according to a changeable domain model and is stored as XML with associated data files. SODA contains a generic XML editor that enables editing data documents based on arbitrary XML schemas. We designed an XML schema that contains elements for service-oriented development projects, such as “Use Case”, “Textual Requirement”, “Service”, “Component” and many more. The schema designer can further structure and specify types and attributes for each of these elements Based on the type of element or attribute, specific data editors are invoked. SODA provides a powerful linking and cross-referencing facility that applies to all elements, as defined in the XML schema. SODA provides powerful mechanisms for editing, linking and post-processing.
In our reference data model for service-oriented development projects, the system developer enters requirements as hierarchically structured use cases, which contain free form text and embedded figures. Use cases are linked to structured textual requirements; both use cases and requirements are additionally linked to the services of the system in development. All the before mentioned object types and their cross-references are defined in the underlying XML schema.
SODA has a plug-in architecture that enables consistency checks of the currently edited data model. For instance, SODA can detect referencing errors (such as link cycles) and missing references (such as a use case with no linked service). SODA also has powerful plug-ins for generating LaTeX, PDF, HTML and other type documents from the model. We use this to generate requirements and software architecture documents out of the data model.
The M2Aspects tool translates services into aspects; the aspect-weaving capabilities of the AspectJ compiler then create the executable implementation. We use multiple such prototypical implementations of the same service repository but with different target architectures for quick architecture exploration and validation
Thinking in terms of services triggers a fresh look at how software-architectures are crafted. As a result, the notion of service emerges as a first-class modeling element – instead of being only a first-class implementation element. Effective architectures are required to support service-oriented designs. Such architectures are based on clear, precisely defined syntactic and semantic interfaces and support hierarchical decomposition while preserving basic properties of the system.
We develop such architectures in a compositional way; these service-oriented architectures are described transparently using industry standards such as UML2 and SysML, or using our own service-oriented Architecture Definition Language (Service-ADL, see below).
Successful system of systems integration will rely heavily on the notion of service, as well as on the management of information flow among the subsystems. This will require systematic domain modeling (to identify the subsystem interfaces, including their information exchange protocols & associated data formats, value-added services and their interaction protocols), as well as the design of an integration platform (including, but not limited to, an integrated access mechanism, such as a common web portal), supporting flexible process definition and composition mechanisms, policy definition and enforcement mechanisms, data storage and dissemination, knowledge management, scalability, reliability, safety, security etc.
A suitable IT infrastructure needs to fulfill the requirements described above, including application integration, security, workflow support, transactionality and reliable messaging. The flexibility to support changing requirements and thus to provide the ability to declaratively alter infrastructure capabilities or application configuration properties is essential. To meet these needs we have developed an integration architecture based on an Enterprise Service Bus (ESB). An ESB can provide flexible and reusable infrastructure services that may be configured and augmented easily and quickly.
To facilitate agile system of systems integration we have configured Enterprise Service Busses (ESBs) and corresponding portal solutions using a wide variety of commercial and open source products, including but not limited to, IBM WebSphere, Groove, .Net, DMIS, JBOSS, Mule, ServiceMix, ActiveMQ, Hibernate.
networks vary in sizes, hardware devices, network topologies and
protocols, etc. In other words, for applications to make use of
a sensor network, the application must deal with the heterogenous
nature of the underlying hardware. Sensor network middleware provides
a layer of abstraction between the heterogeneous set of resources
in the sensor network and the applications that are deployed on
these resources. Unfortunately, constraints on the hardware (power,
network trasmission mode, etc.) seem to require this layer of abstraction
to bend (if not break), where application design must take hardware
constraints into consideration to run at reasonably high performance
(directed diffusion, being one example). What is in need is a programming
model for applications that suit the unique constraints of sensor
networks, but also provides portability across hardware domains
through a set of middleware services.
Our research focuses on a new, hierarchical programming model fo sensor networks; this model abstracts from the details of hardware layouts, and provides uniform access to sensor networks for multiple applications.
Related Projects: RUNES
Our teams, S3EL/SAINT are well versed in the use of DoD Architecture Framework (DoDAF), Federal Enterprise Architecture (FEA), Rational Unified Process Architecture (RUP), and other architecture development and documentation standards. This is particularly useful in large scale system of systems integration projects, where the overall integration solution needs to be transparently documented.
In addition to applying these established standards, we investigate the potentials of new, hierarchic notations focusing on services and their defining interactions; to that end, we investigate existing notations – including Message Sequence Charts (MSCs) and architecture definition languages (ADLs) – as a mechanism to capture the requirements of service-oriented systems of systems integration architectures.
Sequence Charts (MSCs) have emerged in the context of SDL as a means
for specifying communication protocols in telecommunication systems;
they provide a rich graphical notation for capturing point-to-point
interaction patterns. We have extended the notation of MSCs further
to make it more adequate especially for highly complex, embedded
systems; to that end, we have introduced syntactic elements for
capturing broadcasting communication, preemption, overlapping interactions
and trigger composition (enabling transparent specification of liveness
properties). We have also developed systematic refinement notions
for MSCs, capturing refinements of behavior, component structure,
Because we use interaction patterns as the defining elements of our service notion, MSCs are an excellent starting point for service specifications.
We are developing a methodological approach to using MSCs both individually and in the context of service specifications. To that end, we are also investigating the transformation from MSC specifications to statecharts and other automaton models, and study the utility of these transformations for simulation, code generation, test, and verification.
We are developing> an Architecture Definition Language (ADL) which captures services as interaction patterns among a set of roles. Each role models the behavior a concrete component must display to participate in the implementation of a service. Our use of roles in the definition of the service notion decouples services from target component configurations and architectures. We can define mappings from a set of services onto a given target architecture by appropriately associating roles with components implementing their interaction behaviors. This allows exploration of multiple “candidate” architectures implementing the same set of services.
To foster a solid understanding of services and their properties, a profound mathematical foundation for services is crucial to the systematic development of high-quality systems. A carefully defined, precise, compositional service notion, integrating both static and dynamic aspects of component interaction, highlights the complementary roles of services and components as partial and complete behavior specifications, respectively.
We are developing a precise foundation for the notion of service, based on the mathematical model of streams. This service notion captures, in particular, the interaction patterns required to establish the task under consideration; this captures dynamic information as well as static information about services, and thus goes beyond the lists of methods usually found as service descriptors. Based thereon we develop powerful composition operators, refinement and refactoring techniques for service development; we integrate these results into the toolchain discussed below.
We have developed a formal model of services, based on interactions among roles, service composition and software architectures composed out of services and components. We will extend our methodological basis towards more powerful concepts such as role abstractions.
Services (sometimes also called features) are one of the cornerstones of applications in the telecommunications domain. Similarly, services play an important role in both established and evolving technologies and implementation infrastructures.
We are developing a precise foundation for the notion of service, based on the mathematical model of streams. This service notion captures, in particular, the interaction patterns required to establish the task under consideration; this captures dynamic information as well as static information about services, and thus goes beyond the lists of methods usually found as service descriptors.
Based on this foundation we develop powerful composition operators, refinement and refactoring techniques for service development; we integrate these results into the toolchain discussed above.