8.6 Unified Modeling Language Notation

UML is specified using a metamodel that is one layer in a four-layer architectural pattern defined by the OMG for enterprise system development. The UML layer is intended to document the metamodel of applications and systems. The structures in the UML layer are used to document classes whose instantiation, packing, and deployment are described in the model layer. The other layers in the pattern include the meta-metamodel layer, the model layer, and the user objects layer. Given the origins of UML, it should not be a surprise that the UML layer can be used on its own in many other system development methodologies as well as in conjunction with the model-driven architecture (MDA) approach advocated by the OMG. The meta-metamodel layer is described by the OMG's Meta Object Facility (MOF) specification and can be used to generate the UML metamodel layer. In the meta-metamodel, the metaclasses in the UML metamodel are instances of MOF meta-metaclasses.

The UML standard includes several sections. The UML notation guide is the specification that is most likely to provide benefits. The diagrammed notation is defined along with a minimal set of semantics that defines the meaning of the notation. There also exists a much more elaborate semantic description of UML called the UML metamodel, a standard that provides additional details about the fine-grained issues of diagram meaning. In addition, UML includes an object constraint language, which is a textual notation using first-order logic that enables rigorous description of diagram-based constraints.

There are two categories of UML diagram types, as shown in Figure 8.2. Static diagrams represent the logical structure of information objects. Dynamic diagrams represent the behavior and activities of these objects. The static diagram types include use case diagrams, static structure diagrams, and implementation diagrams. Use case diagrams are used for enterprise viewpoint modeling and other kinds of top-down analysis to discover the key functionality of information systems. Static structure diagrams are used for information viewpoint objects as well as other important descriptions because they identify exclusive objects and define constraints on those objects, including the object attributes, the object operations, and other characteristics. Implementation diagrams enable the description of the computational components as well as the technology objects and how they are deployed and allocated.

"Always design a thing by considering its next larger context-a chair in a room, a room in a house, a house in an environment, an environment in a city plan."

-Eero Saarinen

Dynamic UML diagrams include interaction diagrams and state charts. Interaction diagrams represent the time-based behavior of groups of objects exchanging object-oriented messages. State chart diagrams are usually used to represent the internal states and transitions of individual objects.

Figure 8.3 represents a running example that we will use to help explain the capabilities of UML notation. In this example, we are modeling various characteristics of a purchasing system. This is a contrived example, and we will only define aspects of this system that are useful for describing the features of UML. In this purchasing system, some employees engage in the acquisition of capital equipment. There are corporate buyers who have the authority to conduct purchasing transactions and vendors who manufacture and market capital equipment that the employees need.

Figure 8.4 is an example of packages, used to represent the key architectural viewpoints. A package is used to represent any grouping of UML modeling elements, much as parentheses are used to group words in sentences. In modeling tools, packages are used to represent subsidiary diagrams. Wherever a package appears, there is yet another more detailed diagram, viewable on another modeling screen or page.

Figure 8.5 is a use case diagram representing the top-level, static functionality of the procurement system. A use case diagram describes a sequence of actions that are initiated by external entities, called actors, and that provide some value to the stakeholders or actor. The primary purpose of the use case is to illustrate the functionality of the system from the perspective of the end-user. This identifies the system boundaries and scope. In this diagram, the boundary of the procurement system is represented as a UML package. UML packages appear as file folders in diagrams and usually represent the existence of an embedded diagram within a particular viewpoint. In a case tool, clicking on a package will reveal a more detailed diagram from that viewpoint of the system. In our use case, a number of stick figures represent actors that participate in using the system. Actors are analysis objects and interact with the system functionality that is within the system boundaries, modeled within the rectangle. Each of the use cases is represented by an oval in the diagram and represents some major function of the system that can be detailed later as analysis and design progresses. Dependencies between actors in use cases are represented as arrows in this diagram (Figure 8.5). Use cases can reuse other use cases through generalization, using an <extends> relationship to another use case, and through inclusion, also known as a use relationship, using the <include> tag or through inheritance between use case actors. The power of use case analysis is that the diagrams are simple representations of what the system does and for whom. Use case analysis forces the modelers to focus on the highest priority capabilities of the system that provide value to the users.

The second type of static diagram in UML is called the class model. The purpose of the class model is to identify the concepts and constraints that are structural within the information system and to illustrate the internal static structure of a system. Class models contain two types of entities: classes and objects. Classes represent a specific category of behavior. Objects represent specific instances of classes. Classes and objects are represented with rectangles in the UML. Objects are distinguished because the name appearing in the top cell of the rectangle will be underlined. Whenever we have this underlined element in a UML diagram, we generally mean that we are representing an instance of that entity.

Figure 8.6 is a class model for the purchasing system. In this case, there is a package that represents the purchasing communities and various information objects that represent various kinds of documents involved in the purchasing process. For example, there are purchase requisition documents, procurement checklist documents, and purchase order documents. Relationships among the classes are represented by lines. These lines are called associations. Another common notation (shown in Figure 8.9) is a comment or note, which is represented by a rectangle with the top-right corner folded in. A note is attached to one or more model elements and specifies additional constraints or semantics for the diagram.

Figure 8.7 is another class model showing the employee type class and various subclasses including employee contacts and purchasing contacts. The unique kind of association that represents inheritance is shown in Figure 8.7 as a line with an open-ended arrow. This is called a generalization association. Figure 8.8 shows major forms of associations appearing in UML. The purpose of associations is to show relationships between model entities. These relationships may be one-to-one, one-to-many, or other types of cardinality constraints. Most associations in UML diagrams are plain lines between objects and classes. An association can have a name attached to it and an identification of roles at each end of the association. Each of the roles can be identified by numbers or ranges of numbers. If the asterisk symbol is used, this means many, which denotes any number from zero to infinity.

Other types of associations include generalization for representing inheritance, dependency for showing general kinds of change relationships, aggregation for showing part-whole relationships and collections, and composition, which is a stronger form of aggregation that implies that the life cycles of the related objects are tightly coupled. In other words, in composition, if the aggregate object is deleted, all the objects that are part of that composition are also deleted (Figure 8.8).

Figure 8.9 is yet another class model and shows more of the details of associations and attributes and operations that UML can represent. When particular elements of UML are not explicitly represented, such as operations and attributes, it does not mean that these constraints do not exist. It simply means that in this particular model for this purpose it was not necessary to represent that constraint. Figure 8.9 shows several objects with explicit representations of attributes and operations. If the class element is represented explicitly, it has by default three compartments. The top compartment is the name of the class; the second compartment is a list of the attributes of the class. Each attribute represents state information, which may be public, protected, or private. The state information can include representation of data type and default initial values. The third compartment contains operations by default. The operations are identified by their visibility; whether they are public, protected, or private; the operation name; a parameter list; and a return type. All these characteristics may be optionally included except for the operation name, which is required.

The class model is the most important part of UML to understand properly because it is the richest set of descriptive features in UML and is useful for virtually any application of modeling static structure and constraints. Component diagrams are another type of static representation. Figure 8.10 is an example showing various components and dependency relationships between them. Component diagrams are analogous to the computational viewpoint objects described earlier. Component objects are software modules that have interfaces and dependencies upon other computational objects. Figure 8.10 shows the computational objects as rectangles with interface components. Components can implement one or more interfaces and may contain dependencies with other component interfaces. Component diagrams are heavily used in component-oriented development and to model how to distribute the classes of an enterprise system into logical, cohesive modules that can be later deployed to particular operating environments, machines, and/or processors.

Deployment diagrams are another form of structural representation. They are very simple and are particularly useful for enterprise applications that are deployed across a number of machines. Deployment diagrams are essential to define explicitly the specific targeted operating environment where an enterprise system is expected to be deployed. Deployment diagrams include processor symbols, which represent independent computing elements, and device symbols, which represent dependent computing elements such as peripherals, and they may also include middleware used to connect software components. Figure 8.11 is an example of the deployment diagram. The processing elements have shaded surfaces, and the device elements do not. Associations between these deployment objects represent various kinds of physical connections. Dynamic modeling diagrams include state chart diagrams and interaction diagrams.

There are two types of interaction diagrams, collaboration diagrams and sequence diagrams. The purpose of interaction diagrams is to illustrate the behavioral view of the system by modeling the element interactions within a system and their relationships in a particular scenario. These diagrams are isomorphic. In other words, for any given collaboration diagram, an equivalent sequence diagram contains the same information represented differently. This applies in the reverse direction as well. Collaboration diagrams resemble ordinary static structure diagrams; however, in this book, they represent the dynamic time-base behavior of a set of objects that is executing. Ordinary UML objects, which have underlying names and messages that are directed associations between these objects, exist within these diagrams. The details of the associations, such as their multiplicities, while present on the static structure diagrams, are not contained on the collaboration diagram.

Figure 8.12 is an example showing an execution sequence and the order of messaging of this information exchange between the object and the purchasing system. The order of object message transmission is indicated by a numbering sequence-one, two, three, and so forth. These imply a time-based dependency between these messages and how they interact with the information objects. Sequence diagrams, another very important form of UML notation, are used to convey the details of use cases and how use cases will operate as well as show the description of the system in a manner that is readily interpreted by most users.

Sequence diagrams, like collaboration diagrams, contain objects that are rectangles with underlying names in the notation. Their primary purpose is to model the logic of the main user scenarios explicitly. Frequently, sequence diagrams are used to illustrate how system components collaborate to fulfill the requirements of a particular use case or perhaps an alternate scenario of a use case. They model the internal logic of the system enabling the documentation of how a system will satisfy a use case and how components are intended to be reused across various use cases. Figure 8.13 is an example of the sequence diagram showing the purchasing system completing a purchase transaction. Notice that the messages and objects in Figure 8.13 correspond exactly to the transaction that we represented in the collaboration diagram in Figure 8.12. Each object has a dashed line that is extended from the object and runs down the paper. This is the object life-cycle line; it represents the time when the object is actively processing a particular message. The object life-cycle line runs down the page in increasing time to illustrate a chronological progression of messaging between the objects.

A UML activity diagram is used to document the flow of a particular use case or business process. An activity diagram starts with a filled-in circle that is the starting point of a particular process. From the starting point, arrows, which are used to represent the transition between processes, are drawn to rounded rectangles that represent processes or activities that are performed. Diamonds are used to model decision points where the decision dictates a particular flow direction. The text next to the arrows represents conditions that must be filled if the transition from one process or activity to another is to be filled. The thick bar, which transition arrows flow into, models the start and end of potentially concurrent tasks. Finally, an activity diagram terminates into a filled circle with a white border that determines the end of the specific process or activity. Figure 8.13 provides an example of a UML diagram for the purchasing system. A UML activity diagram is essentially an object-oriented version of a data flow diagram because it also shows how data moves through a process in a specific scenario.

The final type of UML diagram is the state chart. State charts represent control flows that cause state transitions. Typically, state chart diagrams represent the state of a single object and the transition between these states as the object executes. Figure 8.14 is an example of a state chart diagram for our purchase system example. In this case, the states of the buyer object are represented. The state chart represents several decision points and their representative states, which are significant to the object's functioning. These states can be used to determine the overall structure of the source code for this object. State charts are suggested to understand particularly complex classes, especially those whose behaviors change or depend on the initial state of a resource or another class.

For more detailed information on the UML notation, refer to either the current version of the UML specification from the OMG or one of the available UML reference books such as Martin Fowler and Kendall Scott's UML Distilled [Fowler 1999].

Of course, in addition to UML diagrams, user interface prototypes are useful to get stakeholder buy-in of how specifically the system will function from the users' perspective. Early feedback from the user is essential for iterating over the requirements and making sure that everyone has a shared understanding of the external behavior of the system. Prototypes may be developed with a prototyping tool or language or consist of walking through scenarios using storyboards to illustrate screens required to navigate through the system to accomplish essential tasks. Keep in mind, however, that using prototyping tools to produce a navigable prototype frequently creates an expectation for a particular interface style that will constrain the choice of implementation technology. For example, if a prototype is developed using Microsoft's Visual Basic, stakeholders may be unpleasantly surprised to discover that following the Java development style guide produces a final application that looks and behaves differently than what they believed would be delivered.

In addition to UML diagrams, it is typically desirable to define specific system constraints. Constraints restrict the range of alternatives a software architect has in creating a design. Constraints are nonfunctional requirements that reflect the decisions of the stakeholders and have an effect on the tradeoffs and design decisions that are made such as a limitation or prior decision regarding system resources, project resources, or an operating environment.

"If you can't explain it in five minutes, either you don't understand it or it doesn't work"

-Rechtin 1997.