Design Article
NATO experiences of modeling military embedded systems
5/18/2011 12:02 PM EDT
3. System design process
3.1 Use case models
The informal requirements provided by the customer were used to generate a set of formal use cases in the UML, a subset of which are shown in Figure 2.
The initial use cases were defined to capture the overall requirements. These use cases were then expanded to include lower level use cases according to the domain model. For this project, the team structure, use case hierarchy and domain hierarchy were all mapped to three system levels as indicated in Figure 3. This ensured that the architecture development remained partitioned according to the different subject matters that were identified, thereby effectively engaging the expertise available and matching the industrial system that would provide components for the system architecture.
3.2 Plug and play domain architecture
The MDA strategy is based upon the notion that any system comprises a set of subject matters, or domains.
These units will be used as a basis for partitioning the specification effort for the system. Domain-based, or subject matter based partitioning has established itself as the dominant strategy for partitioning large, component-based systems.
Each domain addresses one subject matter only, and is uncontaminated by knowledge of other system aspects. This results in large components that are highly reusable, and can be ported to many different execution environments. The set of domains that are to be used in the context of a particular system development is shown as a UML package diagram known as a domain chart.
The domain chart for the weaponized aircraft system is shown in Figure 4. Each domain (shown as a UML package) on the chart represents a distinct set of capabilities within the whole system, whilst the dotted arrows represent dependencies between the domains. A dependency indicates that the source (client) domain requires some services that are fulfilled by the target (server) domain.
3.3 Interaction diagrams
For each use case scenario, a Sequence Diagram is constructed, representing the various capabilities that the system must deliver in terms of interactions between the domains. An example is shown in Figure 5. These serve to verify the chosen domain partitioning by showing how the domains will cooperate to deliver the system-level behavior defined by each use case. They are also used to drive the incremental development of the domain models, which can be built on a use case by use case basis. Finally they will form the bedrock of the domain use cases and the execution scenarios used to test the domains. On this project, an agile process was deployed, in which each timebox / sprint was based upon one or two use cases, and included modeling, model simulation testing, code generation (manual or automatic) and code testing.
Information Exchange Requirements (IERs) are initially expressed as interactions between these domains and actors. The deployment architecture is realized by allocating (or tagging) each domain to a system node, and from these tagged models the IER documents for all possible system allocations are generated automatically. This is a key advantage to a model-centric approach, as maintaining the multiple documents manually as requirements and interfaces evolve would be very expensive and error prone.
3.1 Use case models
The informal requirements provided by the customer were used to generate a set of formal use cases in the UML, a subset of which are shown in Figure 2.
Figure 2 -Use cases capture the system requirements
The initial use cases were defined to capture the overall requirements. These use cases were then expanded to include lower level use cases according to the domain model. For this project, the team structure, use case hierarchy and domain hierarchy were all mapped to three system levels as indicated in Figure 3. This ensured that the architecture development remained partitioned according to the different subject matters that were identified, thereby effectively engaging the expertise available and matching the industrial system that would provide components for the system architecture.
Figure 3 - Use cases layered to match stakeholder needs
3.2 Plug and play domain architecture
The MDA strategy is based upon the notion that any system comprises a set of subject matters, or domains.
These units will be used as a basis for partitioning the specification effort for the system. Domain-based, or subject matter based partitioning has established itself as the dominant strategy for partitioning large, component-based systems.
Each domain addresses one subject matter only, and is uncontaminated by knowledge of other system aspects. This results in large components that are highly reusable, and can be ported to many different execution environments. The set of domains that are to be used in the context of a particular system development is shown as a UML package diagram known as a domain chart.
The domain chart for the weaponized aircraft system is shown in Figure 4. Each domain (shown as a UML package) on the chart represents a distinct set of capabilities within the whole system, whilst the dotted arrows represent dependencies between the domains. A dependency indicates that the source (client) domain requires some services that are fulfilled by the target (server) domain.
Figure 4 - Domain model with plug-in domains
3.3 Interaction diagrams
For each use case scenario, a Sequence Diagram is constructed, representing the various capabilities that the system must deliver in terms of interactions between the domains. An example is shown in Figure 5. These serve to verify the chosen domain partitioning by showing how the domains will cooperate to deliver the system-level behavior defined by each use case. They are also used to drive the incremental development of the domain models, which can be built on a use case by use case basis. Finally they will form the bedrock of the domain use cases and the execution scenarios used to test the domains. On this project, an agile process was deployed, in which each timebox / sprint was based upon one or two use cases, and included modeling, model simulation testing, code generation (manual or automatic) and code testing.
Figure 5 – Use case sequence diagram
Information Exchange Requirements (IERs) are initially expressed as interactions between these domains and actors. The deployment architecture is realized by allocating (or tagging) each domain to a system node, and from these tagged models the IER documents for all possible system allocations are generated automatically. This is a key advantage to a model-centric approach, as maintaining the multiple documents manually as requirements and interfaces evolve would be very expensive and error prone.
|
|
|
|
|
Navigate to related information
Dr DSP
5/22/2011 6:18 PM EDT
The concept of using Abstraction and then Automation to simplify the development process is a common one, but the detailed examples given here were well worth the read. Thanx for the reminder of how powerful these concepts are and how they can be used together for even more savings.
Sign in to Reply