Localities and nodes
The UML documentation states that UML nodes are classifiers that have processing ability and memory. Used in deployment diagrams, the UML node semantics support reasoning about the hosting processors for the software components. The implicit assumption is that the physical resources are outside the software under consideration. For example, in software engineering, the hardware is often seen as an enabling layer below the operating system. UML does provide design and
Descriptor diagrams: For the design level
Instance diagrams: For the implementation level
In particular, instance deployment diagrams are meant to capture configurations and actual choices of hardware and software, and to provide a basis for system analysis and design, serving as an implementation level in the distribution viewpoint.
The UML reference manual describes an instance version of a deployment diagram as a diagram that shows the configuration of
In MDSD, this intent is to model the places where services are performed, that is, where the functionality described in the logical models happens. Modeling localities allows for reasoning about the distribution of functionality. Localities express a set of constraints on the realization of the functionality performed by hardware, software and people. Using localities, engineers can model what functionality can (and cannot) be grouped together.
Localities, services, and interfaces
A locality specifies places where logical services are provided. In practice, each locality will provide a subset of the services of one or more of the logical subsystems. The determination of those services is an outcome of the joint realization.
The set of hosted subsystem services for a given locality should be captured with UML or SysML interfaces. Subsystems are classifiers, and their services are classifier operations. Both UML and SysML allow operations, and therefore subsystem services, to be organized into interfaces. That is, an interface is a subset of subsystem services. In this approach, we define the needed interfaces for each of the subsystems and then assign them to the appropriate localities. Generally, there will be more than one interface associated to a locality2.
2See further discussion and illustration (Figure
