The Unified Modeling Language User Guide SECOND EDITION [Electronic resources] نسخه متنی

Terms and Concepts

A system is a collection of subsystems organized to accomplish a purpose and described by a set of models, possibly from different viewpoints. A subsystem is a grouping of elements, some of which constitute a specification of the behavior offered by the other contained elements. A model is a semantically closed abstraction of a system, meaning that it represents a complete and self-consistent simplification of reality, created in order to better understand the system. In the context of architecture, a view is a projection into the organization and structure of a system's model, focused on one aspect of that system. A diagram is the graphical presentation of a set of elements, most often rendered as a connected graph of vertices (things) and arcs (relationships).

To put it another way, a system represents the thing you are developing, viewed from different perspectives by different models, with those views presented in the form of diagrams.

A diagram is just a graphical projection into the elements that make up a system. For example, you might have several hundred classes in the design of a corporate human resources system. You could never visualize the structure or behavior of that system by staring at one large diagram containing all these classes and all their relationships. Instead, you'd want to create several diagrams, each focused on one view. For example, you might find one class diagram that includes classes, such as Person, Department, and Office, assembled to construct a database schema. You might find some of these same classes, along with other classes, in another diagram that presents an API that's used by client applications. You'd likely see some of these same classes mentioned in an interaction diagram, specifying the semantics of a transaction that reassigns a Person to a new Department.

As this example shows, the same thing in a system (such as the class Person) may appear multiple times in the same diagram or even in different diagrams. In each case, it's the same thing. Each diagram provides a view into the elements that make up the system.

In modeling real systems, no matter what the problem domain, you'll find yourself creating the same kinds of diagrams, because they represent common views into common models. Typically, you'll view the static parts of a system using one of the following diagrams.

1. Class diagram

2. Component diagram

3. Composite structure diagram

4. Object diagram

5. Deployment diagram

6. Artifact diagram

You'll often use five additional diagrams to view the dynamic parts of a system.

1. Use case diagram

2. Sequence diagram

3. Communication diagram

4. State diagram

5. Activity diagram

Every diagram you create will most likely be one of these nine or occasionally of another kind, defined for your project or organization. Every diagram must have a name that's unique in its context so that you can refer to a specific diagram and distinguish one from another. For anything but the most trivial system, you'll want to organize your diagrams into packages.

You can project any combination of elements in the UML in the same diagram. For example, you might show both classes and objects in the same diagram (a common thing to do), or you might even show both classes and components in the same diagram (legal, but less common). Although there's nothing that prevents you from placing wildly disparate kinds of modeling elements in the same diagram, it's more common for you to have roughly the same kinds of things in one diagram. In fact, the UML's defined diagrams are named after the element you'll most often place in each. For example, if you want to visualize a set of classes and their relationships, you'll use a class diagram. Similarly, if you want to visualize a set of components, you'll use a component diagram.

Structural Diagrams

The UML's structural diagrams exist to visualize, specify, construct, and document the static aspects of a system. You can think of the static aspects of a system as representing its relatively stable skeleton and scaffolding. Just as the static aspects of a house encompass the existence and placement of such things as walls, doors, windows, pipes, wires, and vents, so too do the static aspects of a software system encompass the existence and placement of such things as classes, interfaces, collaborations, components, and nodes.

The UML's structural diagrams are roughly organized around the major groups of things you'll find when modeling a system.

Class Diagram

A class diagram shows a set of classes, interfaces, and collaborations and their relationships. Class diagrams are the most common diagram found in modeling object-oriented systems. You use class diagrams to illustrate the static design view of a system. Class diagrams that include active classes are used to address the static process view of a system.

Component Diagram

An component diagram shows the internal parts, connectors, and ports that implement a component. When the component is instantiated, copies of its internal parts are also instantiated.

Composite Structure Diagram

An

composite structure diagram shows the internal structure of a class or a collaboration. The difference between components and composite structure is small and this book treats them both as component diagrams.

Object Diagram

An object diagram shows a set of objects and their relationships. You use object diagrams to illustrate data structures, the static snapshots of instances of the things found in class diagrams. Object diagrams address the static design view or static process view of a system just as class diagrams do, but from the perspective of real or prototypical cases.

Artifact Diagram

An

artifact diagram shows a set of artifacts and their relationships to other artifacts and to the classes that they implement. You use artifact diagrams to show the physical implementation units of the system. (UML considers artifacts to be part of deployment diagrams, but we separate them for convenience of discussion.)

Deployment Diagram

A deployment diagram shows a set of nodes and their relationships. You use deployment diagrams to illustrate the static deployment view of an architecture. Deployment diagrams are related to component diagrams in that a node typically encloses one or more components.

Note

There are some common variants of these four diagrams, named after their primary purpose. For example, you might create a subsystem diagram to illustrate the structural decomposition of a system into subsystems. A subsystem diagram is just a class diagram that contains, primarily, subsystems.

Behavioral Diagrams

The UML's behavioral diagrams are used to visualize, specify, construct, and document the dynamic aspects of a system. You can think of the dynamic aspects of a system as representing its changing parts. Just as the dynamic aspects of a house encompass airflow and traffic through the rooms of a house, so too do the dynamic aspects of a software system encompass such things as the flow of messages over time and the physical movement of components across a network.

The UML's behavioral diagrams are roughly organized around the major ways you can model the dynamics of a system.

Use Case Diagram

A use case diagram shows a set of use cases and actors (a special kind of class) and their relationships. You apply use case diagrams to illustrate the static use case view of a system. Use case diagrams are especially important in organizing and modeling the behaviors of a system.

Interaction diagram is the collective name given to sequence diagrams and communication diagrams. All sequence diagrams and communication diagrams are interaction diagrams, and an interaction diagram is either a sequence diagram or a communication diagram. These diagrams share the same underlying model, although in practice they emphasize different things. (Timing diagrams are another kind of interaction diagram that are not covered in this book.)

Sequence Diagram

A sequence diagram is an interaction diagram that emphasizes the time ordering of messages. A sequence diagram shows a set of roles and the messages sent and received by the instances playing the roles. You use sequence diagrams to illustrate the dynamic view of a system.

Communication Diagram

A communication diagram is an interaction diagram that emphasizes the structural organization of the objects that send and receive messages. A communication diagram shows a set of roles, connectors among those roles, and messages sent and received by the instances playing the roles. You use communication diagrams to illustrate the dynamic view of a system.

State Diagram

A state diagram shows a state machine, consisting of states, transitions, events, and activities. You use state diagrams to illustrate the dynamic view of a system. They are especially important in modeling the behavior of an interface, class, or collaboration. State diagrams emphasize the event-ordered behavior of an object, which is especially useful in modeling reactive systems.

Activity Diagram

An activity diagram shows the flow from step to step within a computation. An activity shows a set of actions, the sequential or branching flow from action to action, and values that are produced or consumed by actions. You use activity diagrams to illustrate the dynamic view of a system. Activity diagrams are especially important in modeling the function of a system. Activity diagrams emphasize the flow of control within the execution of a behavior.

Note

There are obvious practical limitations to illustrating something that's inherently dynamic (the behavior of a system) using diagrams (inherently static artifacts, especially when you draw them on a sheet of paper, a whiteboard, or the back of an envelope). Rendered on a computer display, there are opportunities for animating behavioral diagrams so that they either simulate an executable system or mirror the actual behavior of a system that's executing. The UML allows you to create dynamic diagrams and to use color or other visual cues to "run" the diagram. Some tools have already demonstrated this advanced use of the UML.