System Design using Model Driven Architecture
Kennedy Carter offers a mature, highly optimised system and software design process that has been specifically designed to reduce the amount of time needed to deliver a new concept to market. It is founded on a lightweight, joined-up system and software modelling process, in which the modelling notations are simple, precise and universally comprehensible. Our approach will help you to unify your engineering process by allowing your systems and software people to communicate using a common language, while providing a clear delineation between the two disciplines. Software engineers capitalise on the work of systems engineers, avoiding duplication and providing continuity and traceability throughout the process, saving time and money.
System Requirements: DOORS and Use Cases
The first step is to capture and organise system requirements as a set of use case diagrams. Each use case represents a capability to be provided by the system, without prejudice to whether it is realised using hardware, software, firmware or liveware. Systems engineers explore all required behaviour, including failure modes, by means of use case scenarios. These use case scenarios will form the basis for testing the models as they emerge. Traceability from requirement tools such as DOORS is fully supported.
System Component Architecture: Domains
The next step is to examine the capabilities identified by the use case model, and establish a system design comprising a set of components, or domains, that will together allow those capabilities to be realised. Again, system designers can safely defer decisions about hardware / software boundaries, although it is of course possible to formalise boundaries over which there is no discretion. Each domain is unpolluted by knowledge of other domains, keeping them simple and greatly increasing their portability and reuse potential.
System Interfaces: Interaction Modelling
The final step of the system design part of the lifecycle is to take each use case scenario and show the set of domain interactions that will occur when executing that use case. This allows system designers to establish confidence in their domain architecture, and provides traceability from requirements into the system components. It also establishes a preliminary interface specification for each component, allowing them to be developed separately and concurrently at low risk.
Requirements Management and Traceability
Our toolset is fully integrated with the DOORS requirement management tool, and allows systems and software engineers to create and maintain a full record of their decisions in the form of linkages between DOORS requirements and UML system and software model elements. It also maintains an audit trail of queries and responses that arise daily on any project. All mainstream configuration management tools are also supported.
Software Design using Executable UML
We believe that it is vital for software models to be comprehensible not only to software engineers but to systems engineers, quality assessors and customers. It is also important that the emerging models can be tested to demonstrate that they are compliant with the requirements. To this end, we use a simple, precise subset of UML known as Executable UML (xUML). The xUML subset has been specifically designed to allow construction of platform independent models (PIMs) that can be systematically and automatically transformed into a platform specific implementation. This removes the cost and time typically expended maintaining multiple design artefacts, as only the PIM needs to change in response to requirement changes.
Software Structure: Class Modelling
The software design process begins by taking each domain identified by the system designers, and designing a set of classes that will support the capabilities defined in the use cases. The domain interfaces, specified by the system designers as they built the sequence diagrams, form a key driver for this activity. Any discussions between the systems and software people is focussed on the single, universally comprehensible model, making the consequences of any refinements clear to all parties, and allowing objective trade-offs to be made.
Software Communication: Class Interaction Models
Once the set of classes has been established, the software designers specify the set of interactions, starting with those defined at the domain boundary by the system designers, that will allow the classes to interact and deliver the required behaviour as defined by the use cases. This automatically creates clear traceability links from the system design into the software design artefacts.
Software Behaviour: State Models
Finally, for those classes that are shown on the interaction model as receiving signal events (asynchronous messages), we build a state model to process those messages and generate the required responses. Any synchronous processing is specified using operations on the classes. The resulting models can be executed as they are incrementally developed, allowing simulation of individual use cases, entire components or the complete system. This raises the confidence of all involved, and provides an objective measure of progress.
Model Simulation and Code Generation
Our UML modelling, testing and code generation toolset provides an advanced development environment for software design. Simulation and validation through model execution, combined with some of the most sophisticated and configurable code generation technology available, enables the deployment of correct-by-construction software. Our process, based on an optimised realisation of MDA with UML, supports the capture and re-use of software intellectual property in models that can be easily targeted to different platforms.
Further Information
If you wish to find out more about how our System and Software Engineering Process can help your organisation achieve significant benefits, please contact us by phone or by e-mail.