UML
Up to now, we've shown how UML can be used to represent the concepts presented in this book. Here we present a summary that maps in the other direction.
Although UML was not developed for modeling software architectures, constructs have been added that are useful when documenting software architectures. This section gives a brief overview of diagrams defined within UML v1.4, the important elements and relations they contain, and how they relate to what we describe in this book.
11.3.1 Class and Object Diagrams
In the category of "static structure diagrams," UML offers two diagram types: the class diagram and the object diagram.
- A class diagram contains primarily classes and their variants, such as metaclass, parameterized class, utility, and so on. It can also contain structuring elements, such as model, subsystem, and package. UML defines generalization, association, and dependency as relations between classes, as well as containment and dependency among packages, subsystems, and models. Interfaces for classes and subsystems are also defined.
- An object diagram is an instance of a class diagram, showing a snapshot of the detailed state of a system at a point in time. UML defines that class diagrams can contain instances, and so it is possible to create object diagrams by using class diagrams.
UML class diagrams can be used in the module view. The following list reconciles UML class diagrams with our advice in this book.
| UML Class Diagram Elements | Map to |
|---|---|
| Class diagram | A hybrid style that combines the decomposition, uses, and generalization styles of the module viewtype |
| Class and its variants | Specialized modules |
| Interface | Syntactic part of an interface: signature |
| Subsystem | A specialized module |
| Model | A complete view for a specific stakeholder |
| Package | Used to combine information about parts of a system-inclusive cartoon and supporting documentation, it maps to a view packet |
| Generalization and its variants | Generalization relation |
| Association and its variants | Uses and decomposition relations |
| Dependency and its variants | Depends-on relation |
| Instance | Requires the definition of a new style of the module viewtype, whereby an instance would be a specialized module |
11.3.2 Component Diagrams
Component diagrams show the dependencies among software components, including the classifiers that specify themfor example, implementation classesand the artifacts that implement them, such as source code files, binary code files, executable files, and scripts. Therefore, a component diagram can be seen as a hybrid style composed of the module viewtype and the implementation style of the allocation viewtype. The module viewtype part defines the components with their dependencies and the classifiers that define them, whereas the implementation style part defines the artifacts that implement the components. The following list reconciles UML component diagrams with our advice in this book.
| UML Component Diagram Elements | Map to |
|---|---|
| Component diagram | A hybrid style that combines the module viewtype and the implementation style of the allocation viewtype |
| Component | Module |
| Classifier | Module |
| Artifact | Environmental element |
| Dependency (relationship between components) | Depends-on relation |
| Reside (relationship between classifier and component) | Is-part-of relation |
| Implement (relationship between component and artifact) | Allocated-to relation |
11.3.3 Deployment Diagrams
Deployment diagrams show the configuration of runtime processing elements and the software components, processes, and objects that execute on them. Software component instances represent runtime manifestations of software code units. This definition maps well to the definition of the deployment style of the allocation viewtype, in which the software elements are either components or processes of the component-and-connector viewtype. The following list reconciles UML deployment diagrams with our advice in this book:
| UML Deployment Diagram Elements | Map to |
|---|---|
| Deployment diagram | Deployment style of the allocation viewtype |
| Component | Component of the C&C viewtype |
| Process | Communicating-processes style of the C&C viewtype |
| Node | Environmental element (computational unit) |
| Communication | Environmental element (network) |
| Deploy (relationship between component and node) | Allocated-to relation |
| Become (migration from one node to another) | Migrates-to relation |
11.3.4 Behavioral Diagrams
UML offers a wide variety of notations to model system behavior. Most of them are mentioned in Chapter 8 in this book. Table 11.6 summarizes those UML diagrams.
| UML Diagram | Definition |
|---|---|
| Use case diagram | Shows actors and use cases together with their relationships. The use cases represent functionality of a system or parts of it, as manifested to external interactors with the system or the classifier. |
| Sequence diagram | Shows the explicit sequence of communications and is good for real-time specifications and for complex scenarios. |
| Collaboration diagram | Shows an interaction organized around the roles in the interaction and their relationships. |
| Statechart diagram | Represents the behavior of entities capable of dynamic behavior by specifying its response to the receipt of event instances. |
| Activity diagram | Shows workflow, in which the states represent the performance of actions or subactivities, and the transitions are triggered by the completion of the actions or subactivities. |