Concept: Deployment View |
This architectural view describes how software elements map onto the electronics (software case) or how the elements from various engineering disciplines interact (systems case). This can be done asymmetrically, where each piece of software is assigned at design time to run on a particular hardware target, or symmetrically where runtime locale decisions are made dynamically at runtime to permit load-balancing.
Relationships
Related Elements | Views Software Analysis Discipline Software Design Discipline Optimize Deployment Architecture
Main Description
The deployment view focuses on how the software architecture maps onto the physical devices such as processors, disk drives, displays, and so on. As in Unified Modeling Language (UML) the concept of a node can be used to represent physical devices. Nodes are often stereotyped to indicate the kind of hardware they represent. Some developers may only differentiate between processors (devices that execute code that you write) and devices (ones that don't), while others prefer to identify more detail such as whether a device is a stepper motor, DC motor, thermometer, IR sensor, and so on. The primary use for the deployment view is to represent asymmetric deployment architectures. Then the hardware platform can be schematically represented and the mapping of software subsystems and components can be detailed. For asymmetric systems this is particularly important to understand how the software on the different processors will collaborate and permits performance analysis. You can either nest the software components inside the system or use a dependency from the component or software subsystem to indicate that the node supports or executes that software element. Care must be taken to fully specify the interfaces between the disciplines so that the specific engineering disciplines may work with appropriate expectations on how to interact with the other. Inadequate or incorrect specification of interfaces - especially between electronics and software - can lead to expensive and delayed integration late in the development process. We recommend, therefore, that the interfaces between disciplines be identified early and frozen under configuration management. If the interface specification is later found to be inadequate or incorrect, then it can be thawed, renegotiated, re-specified and refrozen. This may mean that some rework must be done, but in our experience it is far better to have a known, well-specified and frozen target interface, even if it is wrong in some detail, than to let the interface "float" until late in the project. The preferred method for showing the deployment architecture is with a class diagram. This is maximally flexible and allows the clear identification of interfaces. In the case of software-only development, a deployment diagram can be used. It is less semantically capable than a class diagram but can show allocations of software components to processors, buses, links and devices.
More Information
Examples | Deployment Example with a Class Diagram
IBM® Rational® Harmony™ for Embedded RealTime Development Base Concepts Plug-in Copyright