2.4 Paragraphs

A paragraph is a grouping of sentences about a common subject. For example, the English language groups sentences into paragraphs, such as the one you are currently reading. UML paragraphs are diagrams. A diagram is a collection of UML sentences. The elements that make up a diagram are known as diagram elements. For example, all the elements on the figures shown earlier are diagram elements.

The main subject about which we communicate is a system that resides in a domain. A domain, also known as a context, is a broad area of interest that has a generally accepted collection of concepts and their relationships. These concepts are classes, and their relationships are associations; both are known as domain elements. For example, the project management system may be used to manage projects in various industries, including product manufacturing, strategic services, financial services, information technology consulting, and so forth, and each industry is a different domain. Understanding a user's domain is critical as a launching point for developing a system that the user and other stakeholders (those having a stake or interest in the project) will find useful and valuable.

A system is a collection of elements organized together for a specific purpose. These elements are known as system elements. To understand a system, we focus on its architecture. The architecture of a system involves the elements that make up the system and the way they work together to provide the functionality of the system. The major elements that make up a system are known as architectural elements. A system's elements and their relationships define the system's structure, and the way the elements interact and collaborate define the system's behavior.

A system may be recursively decomposed into smaller systems, called subsystems and primitive elements. Subsystems may be further decomposed into sub-subsystems and primitive elements, and so forth. When fully decomposed, a system and all its subsystems consist of primitive elements. Primitive elements cannot be further decomposed. For example, the project management system can be decomposed into the following:

A user interface subsystem responsible for providing an interface through which users can interact with the system.
A business processing subsystem responsible for implementing business functionality.
A data subsystem responsible for implementing data storage functionality.

When the primitive elements of a system or subsystem are objects, the system is considered an object-oriented system. When the primitive elements are simply data elements and functions or procedures, the system is considered a non-object-oriented system.

The UML provides various modeling techniques for communicating using diagrams. Each type of diagram emphasizes something about a system, and any number of diagrams may be used to communicate about a system. The next sections introduce these diagram types using the project management system requirements provided at the beginning of this chapter. Each diagram is further explored in Parts II and III of this book.

In addition to the diagram types shown in the following sections, the UML allows us to define our own diagrams, as necessary. For example, we can define a database schema diagram that communicates the tables in a database and their relationships. In the UML, diagrams belong to two broad categories or types: structural and behavioral. Also, there are other, more general elements that apply to both types of diagrams.

2.4.1 Structural Modeling

Structural modeling assists in understanding and communicating the elements that make up a system and the functionality the system provides. The following sections briefly introduce the various structural modeling diagrams provided by the UML. Part II describes each diagram type in more detail.

2.4.1.1 Class diagrams

Class diagrams depict the structure of a system in general. Class diagrams have the following types of elements:

A class: Shown as a solid-outline rectangle labeled with a name, this represents a general concept.
An association: Shown as a solid-line path labeled with a name, this represents a relationship between classes.
An attribute: Shown as a text string in a class's second compartment, this represents what objects of the class know.
An operation: Shown as a text string in a class's third compartment, this represents what objects of the class can do.

Figure 2-15 is based on the following paragraphs from the requirements description provided at the beginning of the chapter, and combines many of the sentences discussed in the figures shown earlier in this chapter:

A project manager uses the project management system to manage a project. The project manager leads a team to execute the project within the project's start and end dates. Once a project is created in the project management system, a manager may initiate and later terminate the project due to its completion or for some other reason.

As input, a project uses requirements. As output, a project produces a system (or part of a system). The requirements and system are work products: things that are created, used, updated, and elaborated on throughout a project. Every work product has a description, is of some percent complete throughout the effort, and may be validated. However, validation is dependent on the type of work product. For example, the requirements are validated with users in workshops, and the system is validated by being tested against the requirements. Furthermore, requirements may be published using various types of media, including on an intranet or in paper form; and systems may be deployed onto specific platforms.

These paragraphs describe some of the classes that make up the project management system. We can communicate this information on a single diagram as shown in Figure 2-15, or by using multiple diagrams, as done throughout the earlier part of this chapter. Chapter 3 describes class diagrams in detail.

Figure 2-15. Class diagram

2.4.1.2 Object diagrams

Object diagrams depict the structure of a system at a particular point in time. Object diagrams have the following types of elements:

An object: Shown as a solid-outline rectangle labeled with a name followed by a colon followed by the name of its class, all fully underlined, this represents a specific concept. Both names are optional, and the colon is only present if the class is specified.
A link: Shown as a solid-line path labeled with the name of its association fully underlined, this represents a specific relationship between objects.
An attribute value: Shown as a text string followed by an equal symbol and its value in an object's second compartment, this represents what the object knows.

Figure 2-16 is based on the following paragraph from the requirements description provided at the beginning of the chapter:

The project management system must be able to handle the following scenario. Si, who is a manager, manages three projects, named Eagle, Falcon, and Hawk. All projects involve anonymous or unnamed teams. The Eagle project is producing a project management system, similar to the one being described. The Falcon project is using the Java platform to produce another type of system, which is targeted for the broad market. The Hawk project is using the Microsoft .NET platform to produce a system similar to the Falcon project, but one that has additional organization-specific requirements. Therefore, the Falcon and Hawk projects share some common requirements, while the Hawk project has additional organization-specific requirements.

This paragraph describes a specific situation that the project management system must be able to handle using the various classes that make up the system. We can communicate this information on a single diagram, as shown in Figure 2-16, or by using multiple diagrams, as has been done earlier in this chapter. Chapter 3 describes object diagrams in detail.

Figure 2-16. Object diagram

2.4.1.3 Use-case diagrams

Use-case diagrams depict the functionality of a system. Use-case diagrams have the following types of elements:

An actor: Shown as a "stick figure" icon, this represents users and external systems with which the system we are discussing interacts.
A use case: Shown as an ellipse, this represents a functional requirement that is described from the perspective of the users of a system.
A communicate association: Shown as a solid-line path from an actor to a use case, this represents that the actor uses the use case.

Figure 2-17 is based on the following part of a paragraph from the requirements description provided at the beginning of the chapter:

A project manager uses the project management system to manage a project.

This identifies specific functionality that the project management system must provide to its users. Chapter 4 describes use-case diagrams in detail.

Figure 2-17. Use-case diagram

2.4.1.4 Component diagrams

Component diagrams, also known as implementation diagrams, depict the implementation of a system. Component diagrams have the following types of elements:

A component: Shown as a rectangle with two small rectangles protruding from its side, this represents a part of the system that exists while the system is executing.
A dependency relationship: Shown as a dashed arrow from a client component to a suppler component, this represents that the client component uses or depends on the supplier component.

Figure 2-18 is based on the following part of a paragraph from the requirements description provided at the beginning of the chapter:

For auditing and security purposes, the project management system has two parts, a user interface and database.

This paragraph describes how the project management system is implemented when it is executing. Chapter 5 describes component diagrams in detail.

Figure 2-18. Component diagram

While the object-oriented paradigm focuses on using objects, the component-based paradigm focuses on using components. Both paradigms are based on the principles of abstraction, encapsulation, generalization, and polymorphism.

2.4.1.5 Deployment diagrams

Deployment diagrams, also known as implementation diagrams, depict the implementation environment of a system. Note that both component and deployment diagrams are specific types of implementation diagrams. Deployment diagrams have the following types of elements:

A node: Shown as a three-dimensional rectangle, this represents a resource that is available during execution time. A component that resides on a node is nested inside the node.
A communication association: Shown as a solid-line path between nodes, this represents a communication path between the nodes.

Figure 2-19 is based on the following part of a paragraph from the requirements description provided at the beginning of the chapter:

The database of the project management system executes on a central server. The user interface of the project management system executes on a desktop client computer, has access to a printer, and uses the database to store project-related information.

This describes the implementation environment of the project management system. Chapter 5 describes deployment diagrams in detail.

Figure 2-19. Deployment diagram

2.4.2 Behavioral Modeling

Behavioral modeling assists in understanding and communicating how elements interact and collaborate to provide the functionality of a system. The UML supports a number of diagrams useful for behavioral modeling, and these are briefly described in the following sections. Part III describes these types of diagrams in more detail.

2.4.2.1 Sequence diagrams

Sequence diagrams, also known as interaction diagrams, depict how elements interact over time. A horizontal axis shows the elements involved in the interaction, and a vertical axis represents time proceeding down the page. Sequence diagrams have the following types of elements:

Classes and objects: Classes are shown much the same way as on class diagrams. Objects may also be shown much the same way as on object diagrams. In Chapter 6, you will encounter roles, which define placeholders for classes and objects.
A lifeline: Shown as a vertical dashed line from an element, this represents the existence of the element over time.
A communication: Shown as a horizontal solid arrow from the lifeline of the sender to the lifeline of the receiver and labeled with the name of the operation to be invoked, this represents that the sender sends a message or stimulus to the receiver.

Figure 2-20 is based on the following part of a paragraph from the requirements description provided at the beginning of the chapter:

When creating a project, a project managers use a user interface to enter their contact information (at minimum, a name and phone number), the project's name, start and end dates, a description of the requirements and system, and a description of the team. Once the required information is provided, the system processes the request appropriately by storing the information and confirming completion.

This paragraph describes a specific scenario the classes and objects that make up the project management system must be able to handle. Chapter 6 describes sequence diagrams in detail.

Figure 2-20. Sequence diagram

2.4.2.2 Collaboration diagrams

Collaboration diagrams, also known as interaction diagrams, depict how elements interact over time and how they are related. Note that both sequence and collaboration diagrams are specific types of interaction diagrams. Collaboration diagrams have the types of elements that are described in the list shown next.

Classes and objects: Classes are shown much the same way as on class diagrams. Objects may also be shown much the same way as on object diagrams. Again, in Chapter 6, you will encounter roles that define placeholders for classes and objects.
Associations: These are shown much the same way as on class diagrams. Links may also be shown much the same way as on object diagrams.
A communication: This is shown as an arrow attached to a relationship pointing from the sender toward the receiver. It is labeled with a sequence number showing the order in which the communication is sent followed by a colon followed by the name of the operation to be invoked. It represents that the sender sends a message to the receiver.

Figure 2-21 is based on the same part from the requirements description provided at the beginning of the chapter as Figure 2-20 but additionally includes the relationships. Chapter 6 describes collaboration diagrams in detail.

Figure 2-21. Sequence diagram

2.4.2.3 State diagrams

State diagrams, also known as statechart diagrams, depict the lifecycle of an element. State diagrams have the following types of elements:

A state: Shown as a rectangle with rounded corners, this represents a condition or situation of an element.
An event: This is an occurrence of receiving a message.
A transition: Shown as a solid line from a source state to a target state labeled with an event, this represents that if the element is in the source state and the event occurs, it will enter the target state.
Initial state: When an element is created, it enters its initial state, which is shown as a small, solid, filled circle. The transition originating from the initial state may be labeled with the event that creates the element.
Final state: When an element enters its final state, which is shown as a circle surrounding a small solid filled circle (a bull's eye), it is destroyed. The transition to the final state may be labeled with the event that destroys the element.

Figure 2-22 is based on the following part of a paragraph from the requirements description provided at the beginning of the chapter:

Initially, the project is inactive. It becomes active when human resources are assigned to the project, may become inactive again if human resources are unassigned from the project, and is removed from the system once it is completed.

This paragraph describes the lifecycle of a project object that makes up the project management system. Chapter 7 describes state diagrams in detail.

Figure 2-22. Sequence diagram

2.4.2.4 Activity diagrams

Activity diagrams depict the activities and responsibilities of elements. Activity diagrams have the following types of elements:

An action state: Shown as a shape with straight top and bottom with convex arcs on the two sides, this represents processing.
A control-flow transition: Shown as a solid line from a source action state to a target action state, this represents that once the source action state completes its processing, the target action state starts its processing.
An initial action state: Shown as a small solid filled circle, the control-flow transition originating from the initial state specifies the first action state.
A final action state: Shown as a circle surrounding a small solid filled circle (a bull's eye), the control-flow transition to the final state specifies the final action state.
An object-flow: Shown as a dashed arrow between an action state and an object, this represents that the action state inputs or outputs the object. An input object flow, which points to an action state, represents that the action state inputs the object. An output object flow, which points to an object, represents that the action state outputs the object.
A swimlane: Shown as a visual region separated from neighboring swimlanes by vertical solid lines on both sides and labeled at the top with the element responsible for action states within the swimlane, this represents responsibility.

Figure 2-23 is based on the same part of the requirements description provided at the beginning of the chapter as Figures Figure 2-20 and Figure 2-21, but emphasizes the activities and responsibilities of a project manager and the project management system. Chapter 8 describes activity diagrams in detail.

Figure 2-23. Activity diagram

2.4.3 Other Elements

A language often contains elements that are purely notational and other elements that allow for extending the language. UML is no different. UML provides notational items such as notes. Stereotypes and properties allow you to extend the UML.

2.4.3.1 Notes

A note, shown as a rectangle with a bent upper-right corner that may be attached to another element using a dashed line, represents a comment similar to comments in programming languages.

Figure 2-24 shows a comment attached to the Project class.

Figure 2-24. Notes, stereotypes, and properties

2.4.3.2 Stereotypes

A stereotype, shown as a text string keyword enclosed in guillemets («», pronounced gee-a-may) or double-angle brackets, before or above the name of an element, represents a specific meaning associated with the element.

Figure 2-24 shows a stereotype attached to the Project class in this example, indicating that the class represents a database table. Chapter 9 describes stereotypes in more detail.

2.4.3.3 Properties

Properties are shown as a comma-delimited list of text strings inside a pair of braces ({}) after or below the name of an element, and expressed in any natural or computer language, represents characteristics of the element. The text string representing a property can take on two forms:

A text string may be a tagged value, shown as a keyword-value pair (a keyword followed by an equal sign followed by its value) that represents a characteristic of the element and its value.
A text string may be a constraint, shown as a text string that may be expressed in the Object Constraint Language (OCL) that represents a condition the element must satisfy.

Figure 2-24 shows the properties of the Project class, including the version that is used, as well as the business rule concerning the start and end dates of a project. Chapter 9 describes properties in more detail, and Chapter 10 describes the OCL in more detail.