Product Description
Since the dawn of computing, software designers and developers have searched for ways to describe the systems they worked so hard to create. Flowcharts enabled the concise documentation of program-flow and algorithms. Entity-relationship diagrams enabled database designers to convey the structure underlying the collection of tables and columns that made up a schema. From the beginning, technologists recognized the descriptive power inherent in visual representations of a system, yet it wasn't until 1997 that the first attempt to create a visual language that could be used across all aspects of a system development project came to fruition. Unified Modeling Language (UML) was born.
UML has taken the software development industry by storm. Widely supported by development and documentation tools, UML can be used on the one hand by programmers to record such things as the detailed design of classes in an object-oriented system and on the other hand by business analysts to give the broad-brush picture of how a system interacts with users and other systems. UML has become the lingua franca of software development, and no one in the software industry can afford to be without knowledge of this powerfully expressive visual language.
Learning UML introduces UML and places it in perspective, then leads you through an orderly progress towards mastery of the language. You'll begin by learning how UML is used to model the structure of a system. Many key UML concepts, especially that of the general (classes) versus the specific (objects), are illustrated in the chapter on class and object diagrams. Next, you'll learn how to use use-case diagrams to model the functionality of a system. Finally, you'll see how component and deployment diagrams are used to model the way in which a system is deployed in a physical environment.
Structural modeling answers the "who" and "what" questions of systems development. Behavioral modeling addresses the questions of "when," "how," and "why." You'll learn how to use sequence and collaboration, to model the interaction over time between system components, how to use state diagrams to describe the life cycle of system components, and how to use activity diagrams to document control-flow and responsibility.
Throughout this book, author Sinan Si Alhir maintains a clear focus on UML the language and avoids getting caught up in the cobwebs of methodology. His presentation is direct and to-the-point. Each chapter ends with a set of exercises that you can use to test your growing knowledge of UML and its concepts. As you work your way through the book, you'll find yourself warming up to the simple yet expressive language that is UML, and using it to communicate effectively and professionally about all aspects of system design.
About the Author
Excerpted from Learning UML by Sinan Si Alhir. Copyright © 2003. Reprinted by permission. All rights reserved.
This chapter focuses on activity diagrams, which depict the activities and responsibilities of elements that make up a system. First, I introduce activity diagrams and how they are used. Next, I discuss action states and their details. Finally, I go over flows and their details. Many details of activity diagrams that were not fleshed out in
Chapter 2 are more fully elaborated here, and throughout the chapter, I include suggestions relating to activity diagrams.
Activity modeling is a specialized type of behavioral modeling concerned with modeling the activities and responsibilities of elements. You usually apply activity modeling in conjunction with sequence and collaboration modeling (Chapter 6) to explore the activities and responsibilities of interacting and collaborating elements.
Action States
As discussed in Chapter 2, as elements communicate with one another within a society of objects, each element has the responsibility of appropriately reacting to the communications it receives. An action state represents processing as an element fulfills a responsibility. There are various types of action states, including simple, initial, and final action states. The next few sections discuss these different types of action states.
Simple Action States
A simple action state represents processing. For example, the project management system may have the following simple action states:
Project Manager Enters Report Criteria
Indicates that the project manager enters report criteria
Project Management System Generates Report
Indicates that the project management system generates a report
Printer Prints Report
Indicates that the printer prints the report
In the UML, an action state is shown as a shape with a straight top and bottom and convex arcs on the two sides, and is labeled with the name of an operation or a description of the processing.
Initial and Final Action States
An initial action state indicates the first action state on an activity diagram. In the UML, an initial action state is shown using a small solid filled circle. A final action state indicates the last action state on an activity diagram. In the UML, a final action state is shown using a circle surrounding a small solid filled circle (a bull’s eye). An activity diagram may have only one initial action state, but may have any number of final action states.
Flow Transitions
Given a collection of action states, how are those action states related to one another? Flow transitions address this issue. As discussed in Chapter 2, a flow transition shows how action states are ordered or sequenced. There are various types of flow transitions, including control-flow and object-flow transitions, which are mentioned in Chapter 2 and discussed here.
Control-Flow Transitions
A control-flow transition indicates the order of action states. That is, once a source action state completes its processing, a target action state starts its processing. For example, the project management system may have the following order of action states for the task of generating a report:
1. The Project Manager Enters Report Criteria action state occurs first, because the project manager must enter the report criteria before the system can generate a report.
2. The Project Management System Generates Report action state occurs next, because the project management system must generate the report before the printer can print the report.
3. The Printer Prints Report action state occurs last, once the report has been generated by the project management system.
