O'reilly learning uml.chm

• Table of Contents
• Index
• Reviews
• Reader Reviews
• Errata
Learning UML
By Sinan Si Alhir
Publisher: O'Reilly
Pub Date: July 2003
ISBN: 0-596-00344-7
Pages: 252
Slots: 1
Learning UML introduces the Unified Modeling Language and leads you through an orderly progress towards mastery of
the language. 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.
Страница 1
This document is created with a trial version of CHM2PDF Pilot
http://www.colorpilot.com

• Table of Contents
• Index
• Reviews
• Reader Reviews
• Errata
Learning UML
By Sinan Si Alhir
Publisher: O'Reilly
Pub Date: July 2003
ISBN: 0-596-00344-7
Pages: 252
Slots: 1
Dedication
Copyright
Preface
Audience
Using This Book
Organization and Content
Conventions Used in This Book
Comments and Questions
Acknowledgments
Part I: Fundamentals
Chapter 1. Introduction
Section 1.1. What Is the UML?
Section 1.2. The UML and Process
Section 1.3. Learning the UML
Chapter 2. Object-Oriented Modeling
Section 2.1. Project Management System Requirements
Section 2.2. Alphabets, Words, and Sentences
Section 2.3. The Object-Oriented Paradigm
Section 2.4. Paragraphs
Section 2.5. Sections
Section 2.6. Documents
Part II: Structural Modeling
Chapter 3. Class and Object Diagrams
Section 3.1. Classes and Objects
Section 3.2. Associations and Links
Section 3.3. Types, Implementation Classes, and Interfaces
Section 3.4. Generalizations, Realizations, and Dependencies
Section 3.5. Packages and Subsystems
Section 3.6. Exercises
Chapter 4. Use-Case Diagrams
Страница 2

Chapter 4. Use-Case Diagrams
Section 4.1. Actors
Section 4.2. Use Cases
Section 4.3. Communicate Associations
Section 4.4. Dependencies
Section 4.5. Generalizations
Chapter 5. Component and Deployment Diagrams
Section 5.1. Components
Section 5.2. Nodes
Section 5.3. Dependencies
Section 5.4. Communication Associations
Part III: Behavioral Modeling
Chapter 6. Sequence and Collaboration Diagrams
Section 6.1. Roles
Section 6.2. Messages and Stimuli
Section 6.3. Interactions and Collaborations
Section 6.4. Sequence Diagrams
Section 6.5. Collaboration Diagrams
Chapter 7. State Diagrams
Section 7.1. States
Section 7.2. Transitions
Section 7.3. Advanced State Diagrams
Chapter 8. Activity Diagrams
Section 8.1. Action States
Section 8.2. Flow Transitions
Section 8.3. Swimlanes
Section 8.4. Decisions
Section 8.5. Concurrency
Part IV: Beyond the Unified Modeling Language
Chapter 9. Extension Mechanisms
Section 9.1. Language Architecture
Section 9.2. Stereotypes
Section 9.3. Properties
Section 9.4. Profiles
Chapter 10. The Object Constraint Language
Section 10.1. Expressions
Section 10.2. Simple Constraints
Section 10.3. Complex Constraints
Part V: Appendixes
Appendix A. References
Section A.1. World Wide Web
Section A.2. Books
Appendix B. Exercise Solutions
Section B.1. Structural Modeling
Section B.2. Behavioral Modeling
Section B.3. Extension Mechanisms and the Object Constraint Language
Страница 3

Colophon
Index
Страница 4

Dedication
This book is dedicated to my wife, Milad, and my daughter, Nora, whose love of learning is truly
immeasurable.
—Sinan Si Alhir
Страница 5

Copyright © 2003 O'Reilly & Associates, Inc.
Printed in the United States of America.
Published by O'Reilly & Associates, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472.
O'Reilly & Associates books may be purchased for educational, business, or sales promotional use. Online editions are
also available for most titles (http://safari.oreilly.com). For more information, contact our corporate/institutional sales
department: (800) 998-9938 or corporate@oreilly.com.
Nutshell Handbook, the Nutshell Handbook logo, and the O'Reilly logo are registered trademarks of O'Reilly &
Associates, Inc. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as
trademarks. Where those designations appear in this book, and O'Reilly & Associates, Inc. was aware of a trademark
claim, the designations have been printed in caps or initial caps. The association between the image of a kitten and the
topic of UML is a trademark of O'Reilly & Associates, Inc.
While every precaution has been taken in the preparation of this book, the publisher and authors assume no
responsibility for errors or omissions, or for damages resulting from the use of the information contained herein.
Страница 6

Preface
Learning UML is the quintessential tutorial for the Unified Modeling Language (UML). The Unified Modeling Language is a
language for communicating about systems: an evolutionary, general-purpose, broadly applicable, tool-supported, and
industry-standardized modeling language for specifying, visualizing, constructing, and documenting the artifacts of a
system-intensive process.
The UML was originally conceived by, and evolved primarily from, Rational Software Corporation and three of its most
prominent methodologists, the Three Amigos: Grady Booch, James Rumbaugh, and Ivar Jacobson. The UML emerged as
a standard from the Object Management Group (OMG) and Rational Software Corporation to unify the information
systems and technology industry's best engineering practices as a collection of modeling techniques.
The UML may be applied to different types of systems (software and non-software), domains (business versus
software), and methods or processes. The UML enables and promotes (but does not require nor mandate) a use-case-
driven, architecture-centric, iterative and incremental, and risk-confronting process that is object-oriented and
component-based. However, the UML does not prescribe any particular system development approach. Rather, it is
flexible and can be customized to fit any method.
The UML is significantly more than a standard or another modeling language. It is a "paradigm," "philosophy,"
"revolution," and "evolution" of how we approach problem solving and systems. It is often said that the English
language is the world's "universal language"; now it is virtually certain that the UML will be the information systems and
technology world's "universal language."
Страница 7

Audience
This book is for anyone interested in learning and effectively and successfully applying the UML, including analysts and
end users who specify requirements, architects who broadly design systems that satisfy requirements, designers who
detail designs, developers who implement designs, testers who verify and validate systems against requirements,
managers (portfolio, product, program, and project) who orchestrate system development efforts, and others involved
in system development. No specific prior knowledge or skills are assumed; however, familiarity with object-oriented
concepts may be of benefit.
Страница 8

Using This Book
While other tutorials focus on teaching you about the UML or some pseudomethodology or process that uses the UML,
this one focuses on teaching you the essentials. It shows how to effectively and successfully apply the UML, including
coverage of object orientation, common usage guidance, and suggestions on how to model systems. Each chapter uses
an example-driven approach to progressively introduce key UML concepts with increasingly more involved examples. A
project-management system case study is elaborated throughout the book, guiding you in learning how to read,
understand, write, and effectively and successfully apply the UML. The objective is not to create a "complete" or
"comprehensive" design from which to implement the system, but to explore the case study and to learn how to
effectively and successfully apply the UML to communicate in real-world system development. Exercises are included so
that you can practice and improve your skills.
When you are done reading this book, you will understand how to use the various UML diagrams and their elements
based upon what you want to communicate and what each diagram emphasizes rather than based upon some
pseudomethodology or process. You will also have gained insight into the rationale behind the language and how
different pieces of the language fit together rather than be left with the perception that the UML is a hodgepodge of
different types of diagrams without any underlying scheme, so that you'll generally be able to more effectively and
successfully apply the UML. Such an understanding will allow you to stay abreast of the UML as it evolves and new
versions become available.
This book, just like every other book ever written, is a snapshot of thoughts in time. The UML will most likely have
evolved since the writing of this book; however, this book captures the foundation for learning and effectively and
successfully applying the UML. Therefore, this book should remain valuable to you.
Страница 9

Organization and Content
This book consists of 5 parts, 10 chapters, and 2 appendixes.
Part I introduces the UML and object-oriented modeling. These chapters focus on why the UML is as it is and what each
part is used for.
Chapter 1, Introduction
Introduces the UML.
Chapter 2, Object-Oriented Modeling
Introduces the object-oriented paradigm and the UML's modeling techniques.
Part II covers structural modeling and focuses on how the UML is used for modeling the elements that make up a
system and their relationships.
Chapter 3, Class and Object Diagrams
Shows you how to model the structure of a system in general and at a particular point in time using class and
object diagrams, respectively.
Chapter 4, Use-Case Diagrams
Shows you how to model the functionality of a system using use-case diagrams.
Chapter 5, Component and Deployment Diagrams
Shows you how to model the implementation and environment of a system, respectively.
Part III covers behavioral modeling and focuses on how the UML is used for modeling the interactions and
collaborations of the elements that make up a system.
Chapter 6, Sequence and Collaboration Diagrams
Shows you how to model the behavior of elements that make up a system as they interact over time using
sequence diagrams. It also shows you how to use collaboration diagrams to model behavior over time, and at
the same time shows how the elements are related in space.
Chapter 7, State Diagrams
Shows you how to model the lifecycle of elements that make up a system using state diagrams.
Chapter 8, Activity Diagrams
Shows you how to model the activities and responsibilities of elements that make up a system using activity
diagrams.
Part IV introduces other capabilities of the UML, including extending the language and capturing constraints or rules for
model elements.
Chapter 9, Extension Mechanisms
Allows you to understand the UML's extension mechanisms, and gives you a glimpse of some of the possibilities
of applying the UML's extension mechanisms.
Chapter 10, The Object Constraint Language
Introduces you to the UML's Object Constraint Language (OCL). You can reference other, OCL-specific books to
learn more about the OCL.
Part V contains supporting material.
Appendix A, References
Offers references to notable resources on the World Wide Web and various books.
Appendix B, Exercise Solutions
Offers solutions to the exercises.
This book does not contain any source code, because focus is given to the modeling language independent of any
translation to a specific implementation. Rather than show you how to translate a system to a specific implementation,
the focus is on learning and effectively and successfully applying the UML.
Страница 10

Conventions Used in This Book
This book uses the following typographic conventions:
Constant width
Constant width is used for UML keywords, UML element names such as class and object names, method names
and signatures, constraints, properties, and any other time text from a UML diagram that is referenced in the
main body of the text.
Italic
Italic is used for emphasis, for first use of a technical term, and for URLs.
...
Ellipses indicate text in examples or UML diagrams that has been omitted for clarity.
This icon indicates a tip, suggestion, or general note.
This icon indicates a warning or caution.
Страница 11

Comments and Questions
We have tested and verified the information in this book to the best of our ability, but you may find that features have
changed or that we have made mistakes. If so, please notify us by writing to:
O'Reilly & Associates
1005 Gravenstein Highway North
Sebastopol, CA 95472
800-998-9938 (in the U.S. or Canada)
707-829-0515 (international or local)
707-829-0104 (FAX)
You can also send messages electronically. To be put on the mailing list or request a catalog, send email to:
info@oreilly.com
To ask technical questions or comment on the book, send email to:
bookquestions@oreilly.com
We have an online catalog page for this book, where you can find examples and errata (previously reported errors and
corrections are available for public view there). You can access this page at:
http://www.oreilly.com/catalog/learnuml
For more information about this book and others, see the O'Reilly web site:
http://www.oreilly.com
Readers who would like to contact the author to ask questions or to discuss this book, the UML, object orientation, or
other related topics are very welcome to do so at the email address, salhir@earthlink.net. You may also visit the
author's home page at http://home.earthlink.net/~salhir.
Страница 12

Acknowledgments
There are a number of individuals who made this work possible, specifically those who had to live with me, who
demonstrated an abundance of encouragement, patience, understanding, and had to sacrifice a part of themselves to
make this endeavor real.
I thank God for making everything possible, and I thank my family for what they have been, are, and will be—the
essence of my world: my father Saad and mother Rabab, my brothers Ghazwan and Phillip, my wife Milad, and last but
surely never least, my daughter, Nora.
I would also like to thank my mentors, Dr. Carl V. Page and Dr. George C. Stockman, for their continued and
everlasting "presence" in my world.
In addition, I would like to thank the many practitioners leveraging my first book UML in Nutshell (O'Reilly) and my
second book Guide to Applying the UML (Springer-Verlag) from across the world for their support and continued
acknowledgment of their value.
I would also like to thank Tim O'Reilly for giving me the opportunity to do this book; my editor, Jonathan Gennick, for
his effort and understanding and for showing me the true fabric that makes O'Reilly and Associates and Learning books
a success; and all of the staff at O'Reilly and Associates for their work in bringing this book to life. Thanks also go to the
following reviewers for their feedback: Don Bales, Peter Komisar, and John Whiteway.
I will not forget any of you, and I only ask that you please remember me.
Страница 13

Part I: Fundamentals
Страница 14

Chapter 1. Introduction
This chapter introduces the Unified Modeling Language (UML). I discuss why the UML is important and how one can
learn it, by focusing on the object-oriented paradigm, structural modeling techniques, behavioral modeling techniques,
and other capabilities of the UML. There are many good reasons to learn and use the UML. Quite simply, the UML is the
lingua franca of the information systems and technology industry. More formally, the UML is a general-purpose and
industry-standard language that is broadly applicable and well supported by tools in today's marketplace.
System development involves creating systems that satisfy requirements using a system development lifecycle process.
Essentially, requirements represent problems to be addressed, a system represents a solution that addresses those
problems, and system development is a problem-solving process that involves understanding the problem, solving the
problem, and implementing the solution. Natural languages are used to communicate the requirements. Programming
languages (and more broadly, technology-based implementation languages such as the Extensible Markup Language
(XML), the Structured Query Language (SQL), Java, C#, and so forth) are used to communicate the details of the
system. Because natural languages are less precise than programming languages, modeling languages (such as the
UML) are used in a problem-solving process to bridge the chasm between the requirements and the system.
A general-purpose language such as the UML may be applied throughout the system-development process all the way
from requirements gathering to implementation of the system. As a broadly applicable language, UML may also be
applied to different types of systems, domains, and processes. Therefore, we can use the UML to communicate about
software systems and non-software systems (often known as business systems) in various domains or industries such
as manufacturing, banking, e-business, and so forth. Furthermore, we can apply the UML with any process or approach.
It is supported by various tool vendors, industry-standardized, and not a proprietary or closed modeling language.
Страница 15

1.1 What Is the UML?
Quite simply, the UML is a visual language for modeling and communicating about systems through the use of diagrams
and supporting text. For example, Figure 1-1 communicates the following:
A manager leads a team that executes a project.
Each manager has a name and phone number, and may initiate a project or terminate a project.
Each project has a name, start date, and end date.
Each team has a description, and that is all we are interested in concerning the team.
Don't worry if Figure 1-1 does not make complete sense. We will explore this figure and the UML in more detail in
Chapter 2.
Figure 1-1. Managers, projects, and teams
1.1.1 The Three Aspects of UML
As you know by now, UML is an abbreviation for Unified Modeling Language. Each of these words speaks to an
important aspect of the UML. The next few sections talk about these aspects, working through the words of the
abbreviation in reverse order.
1.1.1.1 Language
A language enables us to communicate about a subject. In system development, the subject includes the requirements
and the system. Without a language, it is difficult for team members to communicate and collaborate to successfully
develop a system.
Languages, in the broad sense, are not always composed of written words. For example, we commonly use "counting
language" to introduce children to counting and arithmetic. A child is given a number of apples, oranges, pebbles, or
some other type of object to represent a quantity. For the child, the representation of five might end up being five
apples. The operations of addition and subtraction are then represented by the physical action of adding or removing
objects from the child's collection. We adults, on the other hand, prefer the language of arithmetic, which represents a
specific quantity using a string of Arabic numerals, and which uses the + and - operators to represent addition and
subtraction.
Figure 1-2 contrasts a young child's counting language with the more abstract arithmetic language used by adults.
Figure 1-2. The quantity five in two "languages"
Страница 16

Figure 1-2. The quantity five in two "languages"
Now consider these two languages for communicating some specific number of days for a project. To model and
express the quantity of five, the counting language uses five objects while arithmetic uses the string "5". To model and
express a more involved quantity of, say, 365, the counting language uses 365 objects (however, having so many
objects may be impractical), while the arithmetic language uses the string "365". To model and express the quantity of
four and a half, the counting language uses 4 objects and one half of an object (again, however, one half of an object
may or may not be practical), and arithmetic uses the string "4.5". Because arithmetic allows us to more easily and
practically represent a wider range of quantities than the counting language, arithmetic is said to be more expressive
than the counting language. Likewise, a quantity is expressed more concisely using arithmetic rather than the counting
language. By using languages that are more expressive, we can communicate complex information about complex
subjects in a more concise manner than would be possible otherwise.
Stated somewhat formally, the UML is a language for specifying, visualizing, constructing, and documenting the artifacts
of a system-intensive process. A system-intensive process is an approach that focuses on a system, including the steps
for producing or maintaining the system given the requirements the system must meet. Specifying involves the creation
of a model that describes a system. Visualizing involves the use of diagrams to render and communicate the model (the
model is the idea and the diagrams are the expression of the idea). Constructing involves the use of this visual
depiction to construct the system, similar to how a blueprint is used to construct a building. Documenting uses models
and diagrams to capture our knowledge of the requirements and of the system throughout the process.
The UML itself is not a process. A process applies a set of steps described by a methodology to solve a problem and
develop a system that satisfies its user's requirements. A method addresses only part of the development process; for
example, requirements gathering, analysis, design, and so forth, whereas a methodology addresses the whole
development process from requirements gathering until the system is made available to its users. The different ways
for gathering and using requirements, analyzing requirements, designing a system, and so forth are known as
techniques. Artifacts are work products that are produced and used within a process, including documentation for
communication between parties working on a system and the physical system itself. Each type of UML diagram is also
known as a modeling technique.
1.1.1.2 Model
A model is a representation of a subject. For example, as I noted earlier, to model and express the quantity of five, the
counting language uses five objects, whereas arithmetic uses the string "5". A model captures a set of ideas known as
abstractions about its subject. Without a model, it is very difficult for team members to have a common understanding
of the requirements and the system, and for them to consider the impact of changes that occur while the system is
being developed.
When creating a model, if we try to represent everything about the subject all at once, we will be easily overwhelmed
by the amount of information. Therefore, it is important to focus on capturing relevant information required for
understanding the problem at hand, solving that problem, and implementing the solution, while excluding any irrelevant
information that may hinder our progress. By managing what abstractions make up a model, how detailed they are, and
when to capture them throughout the development process, we can better manage the overall complexity involved in
system development.
1.1.1.3 Unified
The term unified refers to the fact that the Object Management Group (OMG), an industry-recognized standardization
organization, and Rational Software Corporation created the UML to bring together the information systems and
technology industry's best engineering practices. These practices involve applying techniques that allow us to more
successfully develop systems. Without a common language, it is difficult for new team members to quickly become
productive and contribute to developing a system.
1.1.2 Goals and Scope
By understanding the OMG's goals and scope for the UML, we can better understand the motivations behind the UML.
The OMG's goals were to make the UML:
Страница 17

The OMG's goals were to make the UML:
Ready to use
Expressive
Simple
Precise
Extensible
Implementation-independent
Process-independent
By being ready to use, expressive, simple, and precise, the UML can immediately be applied to development projects.
To enable the development of precise models, the OMG introduced the Object Constraint Language (OCL), a
sublanguage for attaching conditions that the elements of a model must satisfy for the model to be considered correct
(also known as well formed). The OCL is discussed in Chapter 10.
An extensible language allows us to define new concepts, similar to introducing new words and extending the
vocabulary of a natural language. Extensibility is discussed in Chapter 9. An implementation-independent language may
be used independently of any specific implementation technologies, such as Java or .NET. A process-independent
language may be used with various types of processes.
The OMG's scope when creating the UML included combining the modeling languages of three of the most prominent
system-development methods — Grady Booch's Booch `93 method, James Rumbaugh's Object Modeling Technique
(OMT) -2 method, and Ivar Jacobson's Object-Oriented Software Engineering (OOSE) method — with the information
systems and technology industry's best engineering practices. Separately, these are only methods, but together, they
form a fairly complete methodology.
1.1.3 History
The UML's history consists of five distinct time periods. By understanding these periods, you can understand why the
UML emerged and how it is still evolving today.
1.1.3.1 The fragmentation period
Between the mid-1970s and the mid-1990s, organizations began to understand the value of software to business but
only had a fragmented collection of techniques for producing and maintaining software. Amongst the various emerging
techniques and methods that focused on producing and maintaining software more effectively (each having its own
modeling languages), three methods stood out:
Grady Booch's Booch `93 method (from Booch `91) emphasized the design and construction of software
systems.
James Rumbaugh's Object Modeling Technique (OMT) -2 method (from OMT-1) emphasized the analysis of
software systems.
Ivar Jacobson's Object-Oriented Software Engineering (OOSE) method emphasized business engineering and
requirements analysis.
As object-oriented methods began to evolve from structured methods, the industry fragmented around these three—
and other—methods. Practitioners of one method could not easily understand artifacts produced using a different
method. In addition, practitioners encountered problems moving from one organization to the next because such a
move frequently entailed learning a new method. Furthermore, tool support was nonexistent to minimal because there
were so many methods. Therefore, it was often cost prohibitive to use any method at all.
1.1.3.2 The unification period
Between the mid-1990s and 1997, the UML 1.0 emerged. James Rumbaugh, and later Ivar Jacobson, joined Grady
Booch at Rational Software Corporation to unify their approaches. Because of their unification effort, they became
known as the Three Amigos. As organizations began to see the value of the UML, the OMG's Object Analysis and Design
Task Force issued a Request for Proposal (RFP) to establish a standard that defines the meaning of object-oriented
Страница 18

Task Force issued a Request for Proposal (RFP) to establish a standard that defines the meaning of object-oriented
technology concepts for tools that support object-oriented analysis and design. Together with various other
organizations, Rational Software Corporation formed the UML Partners Consortium, and the partners submitted Version
1.0 of the UML to the OMG as one of many initial RFP responses.
1.1.3.3 The standardization period
In the later half of 1997, the UML 1.1 emerged. All the RFP responses were combined into Version 1.1 of the UML. The
OMG adopted the UML and assumed responsibility for further development of the standard in November 1997.
1.1.3.4 The revision period
After adoption of the UML 1.1, various versions of the UML emerged. The OMG charted a revision task force (RTF) to
accept public comments on the UML and make minor editorial and technical updates to the standard. Various product
and service vendors began to support and promote the UML with tools, consulting, books, and so forth. The current
version of the UML is 1.4, and the OMG is currently working on a major revision, UML 2.0.
1.1.3.5 The industrialization period
In parallel with the revision period, the OMG is proposing the UML standard for international standardization as a
Publicly Available Specification (PAS) via the International Organization for Standardization (ISO). The most current
version of the UML specification is available from the OMG at http://www.omg.org.
Страница 19

1.2 The UML and Process
Even though the UML is process-independent, its authors promote a process that is use-case driven, architecture-
centric, iterative, and incremental. By understanding how the UML is related to process and the type of process the
UML's authors promote, you can better understand how to best approach learning the UML. However, any type of
process—even one without these characteristics—may use the UML.
Generally, every system development lifecycle process involves the following types of lifecycle activities:
Requirements-gathering activities to capture requirements that define what a system should do
Analysis activities to understand the requirements
Design activities to determine how a system will satisfy its requirements
Implementation activities to build a system
Testing activities to verify that a system satisfies its requirements
Deployment activities to make a system available to its users
There are many types of approach for applying these activities to develop a system. Traditionally, a waterfall approach
has been applied. Now, an iterative approach is more common.
1.2.1 Applying a Waterfall Approach
When applying a waterfall approach, lifecycle activities are performed in a single, linear sequence for all the
requirements. This often results in the discovery, during testing activities when the different pieces of the system are
integrated, of quality-related problems that have remained hidden during the design and implementation activities.
Because such problems are discovered late in the development process, it may be too late to resolve them or they may
be too costly to resolve. For example, discovering that a specific database management system's performance will be
insufficient for the applications that use it after all of the applications have already been developed represents a colossal
problem.
Consider a project that involves 10 requirements, perhaps the generation of 10 different types of reports where each
report stems from a different requirement. Within a waterfall approach, all the requirements are captured and analyzed,
and the whole system is designed, implemented, tested, and deployed in this linear sequence. Within such an approach,
the UML may readily be used to communicate the requirements and description of the system. However, because
activities are performed in a single linear sequence for all the requirements, the UML models must be fairly complete at
each step. This level of completeness is often hard to measure or achieve, because while the UML is more precise than
natural languages, it is less precise than programming languages. Therefore, rather than focusing on the system, teams
using UML in a waterfall approach often struggle in trying to determine whether their UML models are complete enough.
1.2.2 Applying an Iterative Approach
When applying an iterative approach, any subsets of the lifecycle activities are performed several times to better
understand the requirements and gradually develop a more robust system. Each cycle through these activities or a
subset of these activities is known as an iteration, and a series of iterations in a step-wise manner eventually results in
the final system. This enables you to better understand the requirements and gradually develop a more appropriate
system through successive refinement and incrementally gaining more detail as you do more and more iterations. For
example, you can investigate a specific database management system's performance and discover that it will be
insufficient for the applications that use it before the applications have been completely developed, and thus make the
appropriate modifications to the applications or investigate using another database management system before it
becomes too late or too costly.
Consider a project that involves generating 10 different types of reports. Within an iterative approach, the following
sequence of iterations is possible:
1. We identify five requirements (named R1 through R5) and analyze three of the five requirements (perhaps R1,
R3, and R5).
2. We capture five new requirements (named R6 through R10), analyze the two requirements that were not
analyzed in the previous iteration (R2 and R4), and design, implement, and test the system that satisfies the
three requirements that were analyzed in the previous iteration (R1, R3, and R5) and the two requirements
analyzed in this iteration (R2 and R4), but we don't deploy the system because we did not allocate enough time
in the current iteration for that activity.
Страница 20

3. We deploy the system that satisfies the five requirements tested in the previous iteration (R1 through R5) and
continue working on the other requirements (R6 through R10).
4. We continue working on the system but must address changes to one requirement that has already been
deployed (perhaps R3), changes to other requirements that have not yet been deployed (perhaps R6 and R10),
and other technical changes to the system.
This sequence of iterations may appear quite chaotic; however, an iterative approach is only a concept and the UML is
only a language; thus, a methodology is required when using the UML on actual projects. When iterations are used by a
methodology, they are not chaotic but are organized and quite dynamic within the context of the methodology.
An iterative approach to system development offers the following benefits:
We can better manage complexity by building a system in smaller increments rather than all at once.
We can better manage changing requirements by incorporating changes throughout the process and not trying
to capture and address all the requirements at once.
We can provide partial solutions to users throughout the process rather than have them wait until the end of
the process, at which time they receive the whole system and perhaps conclude that it is not what they
expected.
We can solicit feedback from users concerning the parts of the system already developed, so we may make
changes and guide our progress in providing a more robust system that meets their requirements.
An iterative process is incremental because we don't simply rework the same requirements in successive iterations, but
address more and more requirements in successive iterations. Likewise, activities may occur in parallel within a single
iteration when they focus on different parts of the system and don't conflict. Therefore, an iterative approach involves a
series of iterations wherein the system is developed incrementally. Even though such an approach is often known as
iterative and incremental, it is actually iterative, incremental, and parallel. Because such an approach gradually
develops a system through successive refinement and incrementally increasing detail, we are better able to determine
the appropriate level of completeness of our UML models than within a waterfall approach. For example, if we have a
question or concern that needs to be addressed, and if we are unable to readily use our UML models to address that
concern, perhaps we need to elaborate them further; otherwise, we can proceed without spending more time and effort
elaborating our UML models.
With such a dynamic approach in which activities within iterations occur in parallel and a system is constructed
incrementally, how do we keep our activities organized and driven to satisfy the requirements? How do we maintain
focus on the system and avoid constructing a system that may be difficult to maintain and enhance because it is simply
a collection of parts glued together without some overarching scheme? What requirements do we address first, and
what pieces of the system do we implement first? Answering these questions is where use cases, architecture, and risk
management are critical within an iterative approach.
1.2.2.1 Use cases
A use case is a functional requirement described from the perspective of the users of a system. For example, functional
requirements for most systems include security functionality allowing users to log in and out of the system, input data,
process data, generate reports, and so forth. Use cases are the subject of Chapter 4.
A use-case driven process is one wherein we are able to use use cases to plan and perform iterations. This allows us to
organize our activities and focus on implementing the requirements of a system. That is, we capture and analyze use
cases, design and implement a system to satisfy them, test and deploy the system, and plan future iterations.
Therefore, use cases are the glue between all the activities within an iteration.
1.2.2.2 Architecture
Architecture encompasses the elements making up a system and the manner in which they work together to provide
the functionality of the system. For example, most systems include elements for handling security functionality,
inputting and processing data, generating reports, and so forth. The elements and their relationships are known as the
system's structure. Modeling a system's structure is known as structural modeling. Structural modeling is the subject of
Part II. The elements and how they interact and collaborate is known as the system's behavior. Modeling a system's
behavior is known as behavioral modeling. Behavioral modeling is the subject of Part III. The different types of
elements that constitute a system's architecture, both structure and behavior, are determined by the object-oriented
paradigm. The principles and concepts of the object-oriented paradigm are the subject of Chapter 2.
An architecture-centric process focuses on the architecture of a system across iterations. This allows us to better ensure
that the resulting system is not a hodgepodge of elements that may be difficult to integrate, maintain, and enhance.
Therefore, architecture is the glue between all the elements that make up the system as the system is incrementally
developed across iterations.
1.2.2.3 Risk
Страница 21

1.2.2.3 Risk
A risk is any obstacle or unknown that may hinder our success. For example, when developing a system, risks include
such things as insufficient funding, untrained team members with critical responsibilities, and unstable technologies.
To determine what use cases ought to drive an iteration and what parts of the architecture to focus on in the iteration,
we first identify project risks. We then address those use cases that confront the highest risks and those elements of
the architecture that, when built, resolve the highest risks. Such an approach is often known as risk confronting.
Consider once again the project that involves generating 10 different types of reports. Say that three reports (perhaps
R1, R3, and R5) require significant database access, and that four reports (perhaps R3, R6, R8, and R10) require
significant user input. Perhaps there are two risks: the risk of not having an intuitive user interface (named X1) and the
risk of having an inefficient database management system (named X2). From these descriptions, we know that R1, R3,
and R5 are associated with risk X1, and that R3, R6, R8, and R10 are associated with X2. If X1 is more critical to our
project, and has a higher possibility of occurring or a higher impact on the project, we would address R1, R3, and R5 or
as many of their requirements as possible first, because they confront risk X1. If X2 is more critical to our project, and
has a higher possibility of occurring or a higher impact on the project, we would address R3, R6, R8, and R10 or as
many of their requirements as possible first because they confront risk X2. However, in either case, we ought to target
R3 first, because it addresses both risks.
The UML provides structural and behavioral modeling techniques that may be used in a step-wise process that is driven
by requirements, focuses on developing an architecturally sound system that satisfies the requirements, and enables
you to confront risks throughout the system-development process.
Страница 22

1.3 Learning the UML
Learning the UML can be quite overwhelming given the breadth and depth of the language and its lack of a process if
you don't know on what parts of the UML to focus. But by understanding how the UML is related to process, you know
to focus on:
The object-oriented paradigm, because it establishes the foundation for the UML
Structural modeling and behavioral modeling, because they allow you to understand requirements and
architecture
Other capabilities of the UML
In addition, when learning the UML, it is important to focus on the essentials and understand how to effectively and
successfully apply the UML to model systems rather than bog yourself down in trying to learn every comprehensive
aspect of the language.
For the remainder of the book, I will use a project management system case study to help you learn how to read,
understand, write, and effectively and successfully apply the UML. The objective is not to create a complete or
comprehensive model from which to implement the system, but to explore the case study and learn how to effectively
and successfully apply the UML to communicate in real-world system development. I've included exercises, so you can
practice and improve your skills.
Generally, the project management system in the case study provides functionality to manage projects and resources
and to administer the system. It defines the following roles:
Project manager
Responsible for ensuring a project delivers a quality product within specified time, cost, and resource
constraints.
Resource manager
Responsible for ensuring trained and skilled human resources are available for projects.
Human resource
Responsible for ensuring that their skills are maintained and that quality work is completed for a project.
System administrator
Responsible for ensuring that a project management system is available for a project.
More detail about the case study is provided where appropriate throughout the remainder of the book. I purposely don't
offer all the detail at once, so that you will see how different information is used with the various UML modeling
techniques. That, in turn, will help you know when you should seek such detail, and it's a good illustration of how an
iterative approach allows you to steadily gain more detail as a project develops.
Rather than introduce some contrived pseudomethodology or process, I will focus on how to use the various UML
diagrams and their elements based upon what each diagram communicates and emphasizes. This will allow us to focus
on how the different pieces of the language fit together rather than treat the UML as a hodgepodge of different types of
diagrams without any underlying scheme, and you'll be able to more effectively and successfully apply the UML.
Chapter 2 focuses on the object-oriented paradigm and how the different pieces of the language fit together. Part II
focuses on functional requirements and modeling the structure of the project management system using the UML's
structural modeling techniques. Part III focuses on modeling the behavior of the project management system using the
UML's behavioral modeling techniques. Part IV introduces some of the other capabilities of the UML, including the OCL
and facilities for extending the language.
Страница 23

Chapter 2. Object-Oriented Modeling
This chapter introduces the object-oriented paradigm and the UML's modeling techniques. As the UML is a language for
communicating about a system and its requirements, we communicate our understanding of the subject using an
alphabet, words, sentences, paragraphs, sections, and documents. First, I discuss how to write sentences—UML
diagram fragments—about the subject using the language's alphabet and words, and I also introduce the concepts and
principles of the object-oriented paradigm. Next, I talk about how sentences are organized into paragraphs—UML
diagrams—and I introduce the various UML modeling techniques. Next, I go over how paragraphs are organized into
sections—architectural views. Finally, I discuss how sections are organized into documents—models. Many details are
not fleshed out in this chapter but are more fully elaborated in subsequent chapters.
Страница 24

2.1 Project Management System Requirements
Throughout this chapter, I will use the following partial requirements description of a very small part of the project
management system under development as the case study for this book:
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 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 on paper, and systems may be deployed onto
specific platforms.
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.
When creating a project, a project manager uses a user interface to enter his contact information (at
minimum, a name and phone number), the project's name, the start and end dates, a description of the
requirements and the system, and a description of the team. Once the required information is provided,
the system appropriately processes the request by storing the information and confirming completion.
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.
For auditing and security purposes, the project management system has two parts, a user interface and
database. 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 description provides significant detail; however, it does not provide all the detail concerning the project
management system. By using the UML throughout this chapter, we should be able to better understand this
description, and by using a process, we may be able to inquire about missing information to develop the system.
Страница 25

2.2 Alphabets, Words, and Sentences
Because requirements and implementation technologies are complex and constantly changing, a language must not
only facilitate communication about a subject, but also enable us to better manage change and complexity when we
communicate about the subject. A language is based on a paradigm, a way of viewing a subject, that defines the types
of concepts that may be used in the language and the principles of why they are useful. A language's syntax specifies
the notation used for communication and is determined by the language's alphabet. A language's semantics specify the
meaning that is communicated and is determined by the language's words and sentences. The syntax of the UML
involves diagrams, and its semantics are based on the object-oriented paradigm.
To communicate using a language, we must understand its alphabet, how its alphabet is used to form words, and how
its words are used to form sentences. We must also understand the concepts and principles of its underlying paradigm.
2.2.1 Alphabet
An alphabet defines the simplest parts of a language: letters, characters, signs, and marks. For example, the English
language has 26 letters. The UML's alphabet consists of symbol fragments (rectangles, lines, and other graphical
elements) and strings of characters. These don't have meaning by themselves; the smallest units of meaning in a
language are its "words."
2.2.2 Words
A word is a grouping of elements from a language's alphabet that defines a unit of meaning. For example, the English
language has various words, including "project," "manager," "team," "lead," "execute," and so forth. In the UML, words
belong to two broad categories or types:
Concepts
Concepts are shown as solid-outline rectangles or symbols labeled with a name.
Relationships between concepts
Relationships between concepts are shown as line paths connecting symbols labeled with a name.
In addition to their names, concepts and relationships may have other strings of characters attached to them specifying
other information.
Figure 2-1 shows various concepts identified from the project management system requirements by focusing on nouns,
including Project, Manager, Team, Work Product, Requirement, and System.
Figure 2-1. Concepts
Likewise, Figure 2-2 shows various relationships identified from the project management system requirements by
focusing on verbs, including Manage, Lead, Execute, Input, and Output.
Figure 2-2. Relationships
You would not normally show all these relationships in isolation as in Figure 2-2, but would combine them with the
concepts shown in Figure 2-1. When you combine relationships with concepts, you are really combining UML words to
Страница 26

concepts shown in Figure 2-1. When you combine relationships with concepts, you are really combining UML words to
form UML sentences.
2.2.3 Sentences
A sentence is a grouping of words from a language's vocabulary that defines a grammatical unit of meaning containing
a subject and an expression about the subject. A language's grammar specifies the rules for combining words to form
sentences. For example, the English language has rules for combining words to form sentences, in which the sentence
"a manager leads a team" follows the grammar rules, but the sentence "leads manager team" does not. UML sentences
are diagram fragments or very simple diagrams.
Figure 2-3 shows a UML sentence communicating that a team will execute a project as indicated in the project
management system requirements. Team and Project are concepts (nouns), and Execute is the relationship (verb)
between the two concepts.
Figure 2-3. A team will execute a project
Figure 2-4 shows a somewhat more elaborate UML sentence in which a manager manages a project and leads a team.
Figure 2-4. A manager manages a project and leads a team (Version 1)
Notice that Figure 2-4 communicates about a manager's relationship with a team and project, but it does not
communicate that the team will execute the project, as Figure 2-3 did. Just like the English language, we can
communicate whatever we want using the UML. Perhaps one way to look at this is that the UML sentence in Figure 2-4
has a different subject (manager) than the UML sentence in Figure 2-3 (team).
The visual location of concepts and relationships does not have any special meaning so long as symbols are not nested
inside one another. A relationship is usually read from left to right and top to bottom; otherwise, its name may have a
small black solid triangle arrow next to it where the point of the triangle indicates the direction in which to read the
name; the arrow is purely descriptive, and the name of the relationship should be understood by the meaning of the
concepts it relates. For example, Figure 2-5 communicates the same information as Figure 2-4.
Figure 2-5. A manager manages a project and leads a team (Version 2)
In Figure 2-5, if I did not show the small black solid triangle arrows next to the relationship, we would still know that
managers manage projects and lead teams, because that is what it means to be a manager. This is why it is important
to know the semantics of what we depict in the UML rather than simply the syntax. Saying that teams lead managers
and projects manage managers would be meaningless!
Страница 27

2.3 The Object-Oriented Paradigm
Now that you know how to use simple UML words and sentences, let's consider the object-oriented paradigm on which
the UML's semantics are based. We'll look at how object-oriented concepts enable us to view the world around us, and
at how the paradigm's principles enable us to better manage change and complexity.
2.3.1 Concepts
The object-oriented paradigm is based on a few key concepts that enable us to view the world around us. The next few
sections discuss these key concepts.
2.3.1.1 Classes, associations, objects, and links
Figures Figure 2-3 through Figure 2-5 represent general sentences, because they don't identify particular projects,
managers, teams, and so forth. The general concepts shown in the sentences are known as classes, and the general
relationships are known as associations. Similar to natural languages, we can also communicate in the UML using
specific sentences involving specific projects, managers, teams, and so forth, where specific concepts are known as
objects and specific relationships are known as links.
A class defines a type of object and the characteristics of its objects, and an object is an instance of a class. For
example, Figures Figure 2-4 and Figure 2-5 show three classes, including Manager, Team, and Project. We can have many
managers, teams, and projects, and each specific manager, team, and project is an instance or object of its class. In
the UML, a specific concept is shown using the same symbol as its general concept. The symbol is labeled with a specific
name followed by a colon followed by the name of its general concept. The entire string—specific name, colon, and
general name—is fully underlined. Both names are optional, and the colon is only present if the general concept is
specified. Figure 2-6 shows a specific class for each of the three objects shown earlier in Figures Figure 2-4 and Figure
2-5.
An association defines a type of link and the characteristics of its links, and a link is an instance of an association. A
specific relationship is shown as a line path and may be labeled with the fully underlined name of its general
relationship. Figure 2-6 shows two specific links of the associations shown earlier in Figures Figure 2-4 and Figure 2-5.
Figure 2-6. Si manages the Eagle project and leads an anonymous team
Figure 2-6, a specific sentence based on the general sentence shown in Figures Figure 2-4 and Figure 2-5, shows that
Si, who is a manager, manages the Eagle project and leads an anonymous or unnamed team. This notation and naming
convention between a class and its instances, or an association and its instances, is used throughout the UML and is
known as a type-instance dichotomy.
The object-oriented paradigm views the world as a collection of unique objects, often referred to as a society of objects.
Each object has a lifecycle where it knows something, can do something, and can communicate with other objects.
What an object knows and can do are known as features. For example, a manager knows his or her name, can initiate
or terminate a project, and can communicate with a team to lead the team to successfully execute the project. Features
belong to two broad categories or types: attributes and operations.
2.3.1.2 Attributes
Something that an object knows is called an attribute, which essentially represents data. A class defines attributes and
an object has values for those attributes. Even if two objects have the same values for their attributes, the objects are
unique and have their own identities. In a UML diagram, a class may be shown with a second compartment that lists
these attributes as text strings. Likewise, an object may be shown with a second compartment that lists these attributes
as text strings, each followed by an equal symbol (=) and its value. Only attributes we wish to communicate are shown;
other attributes that are not important for us to communicate on a given diagram need not be shown. Associations and
attributes are known as structural features, because they communicate the class's structure similar to how structural
modeling is used to communicate structure as discussed in Chapter 1.
Figure 2-7 elaborates on Figure 2-4 and shows that a manager has a name, a team has a description, and a project has
a name, start date, and end date.
Страница 28

a name, start date, and end date.
Figure 2-7. Classes with attributes
Figure 2-8 elaborates on Figure 2-6 showing various objects with values for the attributes introduced in Figure 2-7.
Figure 2-8. Objects with attribute values
2.3.1.3 Operations and methods
Something an object can do is called an operation or specification and essentially represents processing. How an object
does the processing for a given operation is known as the operation's method or implementation. For example, when
using a programming language, we declare functions or procedures and define their bodies (lines of code) that
determine what the functions or procedures do when they are invoked and executed; a function's declaration is the
operation, and the body definition is the method. A class defines operations and methods that apply to its objects. A
class may be shown with a third compartment that lists these operations as text strings. A class's methods—the code
actually implementing the operations—are not shown on a class, but may be described using other UML modeling
techniques. An object does not have a third compartment, because all the objects of a class have the same operations
and share their class's methods. Likewise, only operations we wish to communicate need be shown on a given diagram.
Other operations that are not important for us to communicate on a given diagram need not be shown. If attributes are
not shown, an empty attributes compartment must be shown such that the third compartment is used to list the
operations. Operations and methods are known as behavioral features, because they communicate a class's behavior
similar to how behavioral modeling is used to communicate behavior as discussed in Chapter 1.
By showing two operations, Initiate Project and Terminate Project, Figure 2-9 shows that a manager may initiate or
terminate a project. Notice that the second compartment for Manager is empty, because I'm focusing only on a
manager's operations.
Figure 2-9. Classes with operations
Figure 2-10 combines Figure 2-7 and Figure 2-9 by showing the attributes and operations for each class on the same
diagram.
Figure 2-10. Classes with attributes and operations
Страница 29

Figure 2-10. Classes with attributes and operations
2.3.1.4 Messages and stimuli
In the object-oriented paradigm, communication from a sender object to a receiver object is used to convey information
or request processing. For example, we don't initiate a project for a manager but communicate a request to the
manager to initiate the project. Once the manager receives the request, an operation is invoked to handle the request,
and the manager executes the method associated with the operation. The sending of a request and reception of a
request are events, or occurrences. Communication between objects via their links is called a stimulus, and
communication between classes via their associations is called a message. A stimulus is an instance of a message
similar to how an object is an instance of a class and a link is an instance of an association. The sender is known as the
client, and the receiver is known as the supplier. A message or stimulus is shown as an arrow attached to an
association or link pointing from the sender toward the receiver and labeled with a sequence number showing the order
in which the message or stimulus is sent, followed by a colon followed by the name of the operation to be invoked.
Figure 2-11 shows that a manager assigns activities and tasks to a team based on a project's requirements.
Figure 2-11. General interaction
Figure 2-12 shows a specific interaction between Si (who is a manager), the Eagle project, and the team.
Figure 2-12. Specific interaction
2.3.2 Principles
The object-oriented paradigm is based on four principles that enable us to better manage change and complexity. The
next few sections discuss these principles.
2.3.2.1 Abstractions
Concepts and relationships are known as abstractions. Classes and associations are general abstractions, and objects
Страница 30

Concepts and relationships are known as abstractions. Classes and associations are general abstractions, and objects
and links are specific abstractions. A good abstraction is well defined and includes essential information required for
understanding it, but excludes any irrelevant or incidental information. For example, when communicating about
managers, it is essential that we know their names, but it is not essential for us to know how many pets they own or
the types of pets they own, if any. Likewise, by considering various managers, we can determine what similarities and
differences they have that allow us to classify them as managers. By using well-defined abstractions, we can better
manage complexity by focusing on what is essential rather than being distracted by what is incidental.
2.3.2.2 Encapsulation
Combining attributes and operations to form classes and objects and hiding methods behind operations is known as
encapsulation.
Combining attributes and operation to form classes and objects is also known as localization. By combining attributes
and operations into single units, we can better manage change and complexity by reducing the number of places we
have to consider when a change occurs. For example, when there is a change to the Manager class, such as a need to
track the manager's years of experience, we simply need to go to the class and update its attributes or operations
rather than go to one location to update the manager's data (or attributes) and another location to update its
processing (or operations).
When classes or objects communicate, the client is usually interested only in the results of the operation and not the
method the supplier uses to perform the operation; thus, a method may be completely hidden from its clients. For
example, a manger is interested in having the team execute a project, but the manger is not so much interested in the
intricate details of how the team executes the project. An attribute may also be made inaccessible or hidden from
clients in that it must be accessed via operations, called getters and setters, which retrieve and set the value of the
attribute. For instance, how the budget associated with a project is stored may be hidden from clients, in that it is either
stored in a database or a flat file, and is accessible via getter and setter operations.
Hiding a method behind an operation is also known as information hiding. Doing this allows us to better manage change
and complexity, because we are able to modify a class's method without impacting its clients who use the operation
implemented by the method. For example, when a manager directs the team to execute a project, the team may use
various techniques, and may change techniques without impacting the manager. Also, the getters and setters for the
budget associated with a project may be changed to store the budget in a database instead of a flat file, or vice versa,
without impacting clients.
2.3.2.3 Generalization
Figure 2-13 shows the classes that represent requirements and systems based on the requirements for the project
management system case study. Note that requirements and systems are work products with some similar attributes
and operation but different methods for validation and various attributes unique to their classes. That is, both systems
and requirements have a Percent Complete attribute and a Description attribute, but requirements also have a Media
attribute while systems have a Platform attribute. While both systems and requirements have a Validate operation,
requirements also have a Publish operation while systems have a Deploy operation. We can use a generalization to
capture and reuse their commonality. A generalization is used between a more general class and a more specific class
to indicate that the more specific class receives the attributes, relationships, operations, and methods from the more
general class. A generalization is shown as a solid-line path from the more specific class to the more general class, with
a large hollow triangle at the end of the path connected to the more general class.
Figure 2-13. Project requirements and systems
Figure 2-14 shows how a generalization is used to communicate that both requirements and systems are work products
that have a description, percent complete, and may be validated. Notice that the Validate operation has been moved into
the Work Product class, similar to the Description and Platform attributes, but the Validate operation also appears in the
Requirement class and System classes. In the next section, I will discuss why the Validate operation appears in all the
classes. By using a generalization, we can better manage change and complexity. We gain the ability to reuse existing
abstractions to define new abstractions, and changes we make to a more general class are propagated to its more
specific classes. For example, we can use the Work Product class to define other types of work products such as user
documentation, installation and administration manuals, and so forth as necessary in the future.
Figure 2-14. Project work products, requirements, and systems
Страница 31

Figure 2-14. Project work products, requirements, and systems
2.3.2.4 Polymorphism
Figure 2-14 shows that the Validate operation appears in all the classes. It is identified or declared in the Work Product
class, perhaps with a default method, but the Requirement class and System class provide their own methods for
validation. Hence the need for the Requirement and System classes to list their own Validate operations. Had these classes
simply inherited the default Validate functionality from the Work Product class, you wouldn't list the Validate method again.
The ability to have multiple methods for a single operation is called polymorphism.
Because a generalization between a more general class and a more specific class also indicates that objects of the more
specific class are simply specialized objects of the general class, objects of the specific class may be substituted for
objects of the general class. For example, requirements and systems may be substituted for work products. Simply
applying the Validate operation on a work product without knowing its actual class causes the appropriate method to be
invoked. By using polymorphism, we can better manage change and complexity by reusing operations with new
methods, and we can communicate requests without having to manage which actual methods are invoked. That is, we
can manipulate requirement work products, system work products, and other specific types of work products simply as
general types of work products. For every requirement work product, the Validate method provided by the Requirement
class is invoked to handle validation requests. For every system work product, the Validate method provided by the
System class is invoked to handle validation requests, and so forth for any other types of work products.
Страница 32

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
Страница 33

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.
Страница 34

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
Страница 35

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.
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.
Страница 36

Shown as a solid-line path between nodes, this represents a communication path between the nodes.
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.
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
Страница 37

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.
Страница 38

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.
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.
Страница 39

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
Страница 40

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.
Страница 41

2.5 Sections
A UML section is a grouping of paragraphs about a common subject. For instance, the English language groups
paragraphs into sections, such as the one you are currently reading. UML sections are architectural views. An
architectural view is a category of diagrams addressing a specific set of concerns. All the different architectural views
determine the different ways in which we can understand a system. For example, all the figures shown so far in this
chapter may be organized into different views, including those for addressing functional, structural, behavioral, and
other pieces of the project management system. The elements that make up a view are known as view elements. For
example, all the elements in the figures are view elements when we classify the diagram on which they appear into a
specific view.
Because the UML is a language and not a methodology, it does not prescribe any explicit architectural views, but the
UML diagrams may be generally organized around the following commonly used architectural views:
The use-case or user architectural view
Focuses on the functionality of a system, using use-case diagrams to communicate what functionality the
system provides to its users.
The structural or static architectural view
Focuses on the structure of a system, using class and object diagrams to communicate what elements and
relationships make up the system.
The behavioral or dynamic architectural view
Focuses on the behavior of a system, using sequence, collaboration, state, and activity diagrams to
communicate the interactions and collaborations of the elements that make up the system.
The component or implementation architectural view
Focuses on the implementation of a system, using component diagrams to communicate how the system is
implemented.
The deployment or environment model architectural view
Focuses on the implementation environment, using deployment diagrams to communicate how the implemented
system resides in its environment.
Even though each type of diagram is organized around a single architectural view, any diagram type can be used in any
architectural view. For example, an interaction diagram can be used in a use-case view to communicate how users
interact with a system. Furthermore, the UML allows us to define our own architectural views, as necessary. For
example, we can define a data store architectural view, and we can define a new type of diagram, perhaps called a
database schema diagram, to communicate the tables in a database and their relationships. We could then use other
types of diagrams to communicate the triggers and stored procedures in a database.
Страница 42

2.6 Documents
A UML document is a grouping of sections about a common subject, including any non-UML diagrams, textual
documents, and other supporting information. UML documents are models. For example, the English language groups
sections into documents, such as this book. A model is a representation of a system. For example, all the figures in this
chapter and their supporting textual documentation are a model of the project management system. The elements that
make up a model are known as model elements. For example, any element used on the diagrams in this chapter, with
any supporting documentation necessary for communicating about that element, forms a model element.
The relationship between models, architectural views, and diagrams is similar to the relationship between databases,
views, and queries. A database houses data, views organize subsets of the data into meaningful information, and
queries extract subsets of the information. A model element is similar to a data element in the database, view elements
are similar to data elements used within views, and diagram elements are similar to data elements used within queries.
This establishes a general scheme or approach for how the UML is organized and how it allows us to communicate.
Because the UML is a language and not a methodology, it does not prescribe any explicit steps for applying models to
develop a system given its requirements, but any methodology may generally address the models in association with
these architectural views.
Models and diagrams help us capture and communicate our understanding of the requirements and system throughout
the system development lifecycle process. They not only enable us to manage change and complexity, but also to
assess our understanding before spending resources in producing a system that is unacceptable or does not sufficiently
satisfy the requirements. Models capture all the detail in crossing the chasm between requirements and systems; we
surely don't capture design and implementation details in the requirements, and we surely don't capture detailed
requirements in the implementation of the system. However, we capture such details in a model that matures
throughout a process as our understanding of the requirements and system likewise mature.
Страница 43

Part II: Structural Modeling
Страница 44

O'reilly learning uml.chm

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a O'reilly learning uml.chm

Semelhante a O'reilly learning uml.chm (20)

Último

Último (20)

O'reilly learning uml.chm