<Day Day Up>

UML Bible
byTom Pender ISBN:0764526049
John Wiley & Sons 2003 (940 pages)
For beginning to advanced users, this book provides
comprehensive coverage of the versatility of 1.4 and 2.0 UML
specifications, and shows how to use UML to improve
timeliness, quality, and efficiency in development.
Companion Web Site

Table of Contents
UML Bible
Preface
Part I - An Introduction to UML
Chapter 1 - What Is UML?
Chapter 2 - UML Architecture
Chapter 3 - UML Diagrams and Extension Mechanisms
Chapter 4 - Object-Oriented Concepts
Part II - Modeling Object Structure
Chapter 5 - Capturing Rules about Objects in a Class Diagram
Chapter 6 - How to Capture Rules about Object Relationships
Chapter 7 - Testing with Objects
Part III - Modeling Object Interactions
Chapter 8 - Modeling Interactions in UML 1.4
Chapter 9 - Modeling Interactions in UML 2.0
Chapter 10 - Modeling an Object's Lifecycle in UML 1.4
Chapter 11 - Modeling an Object's Lifecycle in UML 2.0
Part IV - Modeling Object Behavior
Chapter 12 - Modeling the Use of a System with the Use Case Diagram
Chapter 13 - Modeling Behavior Using an Activity Diagram
Part V - Modeling the Application Architecture
Chapter 14 - Modeling the Application Architecture
Chapter 15 - Modeling Software Using the Component Diagram
Chapter 16 - Using Deployment Diagrams in UML 1.4
Chapter 17 - Representing an Architecture in UML 2.0
Part VI - Bringing Rigor to the Model
Chapter 18 - Applying Constraints to the UML Diagrams
Chapter 19 - Action Semantics
Part VII - Automating the UML Modeling Process
Chapter 20 - Using a Modeling Tool
Chapter 21 - Customizing UML Using Profiles
Chapter 22 - XML Metadata Interchange
Appendix A - UML 1.4 Notation Guide
Appendix B - UML 2.0 Notation Guide
Appendix C - Standard Elements
Glossary
<Day Day Up>
UML Bible
byTom Pender ISBN:0764526049
John Wiley & Sons 2003 (940 pages)
For beginning to advanced users, this book provides
comprehensive coverage of the versatility of 1.4 and 2.0 UML
specifications, and shows how to use UML to improve
timeliness, quality, and efficiency in development.
Companion Web Site

Table of Contents
UML Bible
Preface
Part I - An Introduction to UML
Chapter 1 - What Is UML?
Chapter 2 - UML Architecture
Chapter 3 - UML Diagrams and Extension Mechanisms
Chapter 4 - Object-Oriented Concepts
Part II - Modeling Object Structure
Chapter 5 - Capturing Rules about Objects in a Class Diagram
Chapter 6 - How to Capture Rules about Object Relationships
Chapter 7 - Testing with Objects
Part III - Modeling Object Interactions
Chapter 8 - Modeling Interactions in UML 1.4
Chapter 9 - Modeling Interactions in UML 2.0
Chapter 10 - Modeling an Object's Lifecycle in UML 1.4
Chapter 11 - Modeling an Object's Lifecycle in UML 2.0
Part IV - Modeling Object Behavior
Chapter 12 - Modeling the Use of a System with the Use Case Diagram
Chapter 13 - Modeling Behavior Using an Activity Diagram
Part V - Modeling the Application Architecture
Chapter 14 - Modeling the Application Architecture
Chapter 15 - Modeling Software Using the Component Diagram
Chapter 16 - Using Deployment Diagrams in UML 1.4
Chapter 17 - Representing an Architecture in UML 2.0
Part VI - Bringing Rigor to the Model
Chapter 18 - Applying Constraints to the UML Diagrams
Chapter 19 - Action Semantics
Part VII - Automating the UML Modeling Process
Chapter 20 - Using a Modeling Tool
Chapter 21 - Customizing UML Using Profiles
Chapter 22 - XML Metadata Interchange
Appendix A - UML 1.4 Notation Guide
Appendix B - UML 2.0 Notation Guide
Appendix C - Standard Elements
Glossary
Index
List of Figures
List of Tables
List of Listings
List of Sidebars
<Day Day Up>
<Day Day Up>
Back Cover
Todays economy demands top quality software development in record time and maximum efficiency. UML arms you to meet
that challenge, and the UML Bible supplies the most comprehensive UML education you can get. One volume covers
everything from understanding and using UML and diagramming notation to the object constraint language (OCL) and
profiles, in both 1.4 and 2.0 UML specifications. Its the one resource you can rely on to virtually guarantee your success.
Learn to model object structure, interactions, behavior, and architecture using UML
Explore diagram structure and usage
Understand how to utilize the overlapping features of the UML diagrams to facilitate the modeling process
Learn to exploit the features of the UML diagrams to test them for consistency and accuracy
Learn to assess modeling tools to choose the one that suits your needs
Comprehend how the statechart diagram is used to model changes in an object over its lifetime
Apply object constraint language (OCL) and work with Action Semantics to specify behaviors that ultimately will be
implemented in code
Understand the XML Model Interchange (XMI) standard that helps enable model sharing between modeling tools and
other XMI-compatible applications
Customize UML to meet the needs of specific industries or application types
About the Author
Tom Pender is currently a teacher and mentor for UML courses offered through Sun Microsystems and DigitalThink, Inc.
Tom has worked as a software engineer for more than 20 years in a wide variety of industries. He has worked in just about
every position within software development from programmer to manager. His extensive and diverse experience brings the
real world into the classroom, where he has spent the past six very successful years teaching analysis and design using
UML. He has authored four online courses about UML through DigitalThink, Inc. and the book UML Weekend Crash Course,
which has been enthusiastically praised as a very practical, approachable, and comprehensive introduction to UML.
<Day Day Up>
<Day Day Up>
UML Bible
Tom Pender
WILEY
Wiley Publishing, Inc.
Published by
Wiley Publishing, Inc.
10475 Crosspoint Boulevard
Indianapolis, IN 46256
http://www.wiley.com
Copyright 2003 Wiley Publishing, Inc., Indianapolis, Indiana
Library of Congress Control Number: 2003101942
0-7645-2604-9
Manufactured in the United States of America
10 9 8 7 6 5 4 3 2 1
1B/QZ/QZ/QT/IN
No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any
means, electronics, mechanical, photocopying, recording, scanning or otherwise, except as permitted under
Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the
Publisher, or authorization through payment of the appropriate per copy fee to the Copyright Clearance center,
222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8700. Requests to the Publisher for
permission should be addressed to the Legal Department, Wiley Publishing, Inc., 10475 Crosspoint Blvd.,
Indianapolis, IN 46256, (317) 572-3447, fax (317) 572-4447, E-Mail: permcoordinator@wiley.com.
LIMIT OF LIABILITY/DISCLAIMER OF WARRANTY: WHILE THE PUBLISHER AND AUTHOR HAVE USED
THEIR BEST EFFORTS IN PREPARING THIS BOOK, THEY MAKE NO REPRESENTATIONS OR
WARRANTIES WITH RESPECT TO THE ACCURACY OR COMPLETENESS OF THE CONTENTS OF THIS
BOOK AND SPECIFICALLY DISCLAIM ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR
A PARTICULAR PURPOSE. NO WARRANTY MAY BE CREATED OR EXTENDED BY SALES
REPRESENTATIVES OR WRITTEN SALES MATERIALS. THE ADVICE AND STRATEGIES CONTAINED
HEREIN MAY NOT BE SUITABLE FOR YOUR SITUATION. YOU SHOULD CONSULT WITH A PROFESSIONAL
WHERE APPROPRIATE. NEITHER THE PUBLISHER NOR AUTHOR SHALL BE LIABLE FOR ANY LOSS OF
PROFIT OR ANY OTHER COMMERCIAL DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL,
INCIDENTAL, CONSEQUENTIAL, OR OTHER DAMAGES.
For general information on our other products and services or to obtain technical support, please contact our
Customer Care Department within the U.S. at (800) 762-2974, outside the U.S. at (317) 572-3993 or fax (317)572-
4002.
Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be
available in electronics books.
Trademarks: Wiley, the Wiley Publishing logo, and related trade dress are trademarks or registered trademarks of
John Wiley & Sons, Inc. and/or its affiliates, in the United States and other countries, and may not be used without
written permission. UML is a trademark of Object Management Group, Inc. All other trademarks are the property of
their respective owners. Wiley Publishing, Inc., is not associated with any product or vendor mentioned in this book.
Diagrams identified by the text "OMG 1.4" are from the OMG UML specification v1.4 and are used with
permission of the OMG. Copyright C 2001, Object Management Group, Inc. http://www.omg.org.
Diagrams identified by the text "OMG 2.0" are from the OMG UML specification v2.0 and are used with
permission of the OMG. Copyright C 2003, Object Management Group, Inc. http://www.omg.org.
Figures identified by the text "No Magic" are printed with permission from No Magic, Inc., 1998--2003, All rights
reserved.
WILEY is a trademark of Wiley Publishing, Inc.
About the Authors
Tom Pender is currently a teacher and mentor for UML courses offered through Sun Microsystems and
DigitalThink, Inc. Tom has worked as a software engineer for more than 20 years in a wide variety of industries. He
has worked in just about every position within software development from programmer to manager. His extensive
and diverse experience brings the real world into the classroom, where he has spent the past six very successful
years teaching analysis and design using UML. He has authored four online courses about UML through
DigitalThink, Inc. (http://www.digitalthink.com/) and the book UML Weekend Crash Course, which has been
enthusiastically praised as a very practical, approachable, and comprehensive introduction to UML. When not
standing on the UML soapbox, Tom works with orphanages in Romania and with challenged families in his
community, trains his dogs, and periodically indulges in his hobby of collecting old comic books. Tom can be
reached at tom@pender.com or via the Wiley Web site, http://www.wiley.com/compbooks/pender.
Eugene McSheffrey has over sixteen years experience in the software industry and is a senior consultant with
Popkin Software, a company which provides enterprise architecture modeling tools and services that help
companies to align their business and IT. Since joining Popkin in 1996, he has worked as a consultant and trainer,
helping clients in Europe, Asia, and North America to build effective architecture and development models using
UML and other modeling techniques. Eugene holds a B.Sc. degree from the University of Edinburgh and a M.Sc.
degree in Computing for Commerce and Industry from the Open University.
Lou Varveris is Director of Research & Communications at Popkin Software and also serves as UML Product
Manager for System Architect. He has been involved with the implementation of object methodologies for nine
years. He has published white papers, given seminars, and written and taught numerous training courses and
tutorials on UML and enterprise architecture. Prior to working at Popkin Software, he was an engineer at Unisys
Corporation for nine years. He holds a B.S. in Engineering Science from the College of Staten Island, CUNY, and
an M.S. in Specialized Journalism, with graduate engineering work in communication theory, from Polytechnic
University.
Credits
Senior Acquisitions Editor
Jim Minatel
Project Editor
Sara Shlaer
Technical Editors
Robert Rodes
Lou Varveris
Copy Editor
Maryann Steinhart
Editorial Manager
Mary Beth Wakefield
Vice President & Executive Group Publisher
Richard Swadley
Vice President and Executive Publisher
Bob Ipsen
Vice President and Publisher
Joseph B. Wikert
Executive Editorial Director
Mary Bednarek
Project Coordinator
Regina Snyder
Graphics and Production Specialists
Amanda Carter, Jennifer Click,
Michael Kruzil, Lynsey Osborn,
Mary Gillot Virgin
Quality Control Technician
Charles Spencer
Carl William Pierce
Permissions Editor
Carmen Krikorian
Media Development Specialist
Kit Malone
Proofreading and Indexing
TECHBOOKS Production Services
I dedicate this book to my wife Jackie, my son Tom, and my daughter Tami, who have stood by me through
the demands and the chaos of work and writing, and through it all have managed to preserve our family life. I
love you all.
Acknowledgments
Thank you to my wife Jackie, my son Tom, and my daughter Tami who put up with my crazy work schedule and
my mood swings as I juggled work, writing, and my family life (not always very successfully). Their patience and
steadfast support keep me going. Thank you for standing by me through the challenges.
Sara Shlaer was indispensable. She held my hand through the first book, UML Weekend Crash Course, showing
me the ropes and showing me how little I knew (know) about writing well. UML Bible was a much bigger
undertaking, and once again Sara exemplified professionalism, talent, and patience. I sincerely appreciate the
tremendous effort Sara made to keep me on track despite the myriad specification changes, schedule revisions,
and missed deadlines. She always made an effort to keep our working relationship humane, balancing our
humanity and our obligations with grace and compassion. I could not have done this book without her.
Bob Rhodes labored diligently to understand my often cryptic text and sort out what I really meant to say (or so he
hoped I meant to say), always giving me the benefit of the doubt, deserved or not. Thank you very much, Bob, for
hanging in there through all the changes to the specification and the hundreds of detailed diagrams used to
illustrate this book.
Lou Varveris is the product manager for Software Architect at Popkin Software. He helped me as technical editor
on my first book, UML Weekend Crash Course. Then as here he was a tremendous help. Lou is meticulous,
patient, and thorough. His insights were always dead on and saved me embarrassment on many occasions. Thank
you, Lou. Lou also authored the chapters on packages and automating the UML using XMI, profiles, and modeling
tools, taking a tremendous burden off my schedule and enhancing the quality of the book. Again, thank you very
much Lou.
Eugene McSheffrey works at Popkin Software with Lou Varveris. Eugene took precious time out of his incredibly
busy schedule to author the chapter on Action Semantics, relieving another burden from the schedule and
providing excellent primers for both subjects.
Maryann Steinhart took on a great deal of the editing responsibility. Knowing nothing about UML, she faithfully
labored through the morass of my technical jargon and cryptic examples to offer insights and alternatives so that
people could actually read the book. Her comments were always offered in a professional and understanding
manner, underscoring her commitment to the quality of the book and to the readers. Thank you very much for your
perseverance, Maryann.
Jim Minatel ran interference and politely, but steadfastly, worked to keep me on track. Jim could have played the
bully project manager, but he chose just the right balance of accountability and understanding.
My thanks to the Graphic Techs at Wiley who spent hours making faithful reproductions of my original art for the
book: Karl Brandt, Kelly Emkow, Lauren Goddard, Lynsey Osborn, Rashell Smith, and Mary Virgin. They did an
incredible job and never complained (at least, within my hearing) about the continual revisions I submitted.
Finally, thank you to all my students who have offered countless suggestions and feedback as I grappled with ways
to communicate the features and benefits of modeling. Their honesty and enthusiasm were at once an inspiration
and a motivation to keep trying. Thank you, to all of you, for speaking up, for asking questions, for challenging me,
and for earnestly seeking to understand.
<Day Day Up>
<Day Day Up>
Preface
In more than 20 years on projects and five years in the classroom, I've seen a lot of things change and a lot of
things stay the same. I've watched people get thrown in every direction by the speed and impact of changes in
technology, and I've listened to the same unchanging list of complaints:
Poorly defined requirements
Rapidly changing requirements
Difficulties among IT and business team members and clients
Estimates that can't be trusted because they are actually individualized guesses because no one has kept any
development metrics
The overwhelming challenge of maintaining existing systems with no documentation
So how can the Unified Modeling Language help solve these problems? UML has become an increasingly popular
and powerful component of software development strategies around the world. More than 90 percent of the
Fortune 500 companies use it in some form. Why? Because UML supplies some essential tools that support a
professional response to these challenges. UML provides
A consistent form of communication that works equally well in analysis and design
A visual presentation that works equally well for technical and non technical team members
A formal yet flexible standard to ensure consistency and clarity
An extensible language that may be tailored to any industry or application type
A programming language independent way to specify software
A rigorous means to specify software structure and behavior to generate code or even generate complete
applications (executable UML)
Regardless of the method you use to apply it, UML supports the development of precise, consistent, and traceable
communication that will survive the chaotic and rapid pace of change.
The goal of every book in the Bible series is to provide you with a comprehensive explanation of a topic, and in
UML Bible you learn all about the Unified Modeling Language (UML): diagramming notations and semantics, the
Object Constraint Language, Action Semantics, the UML Metamodel (2M), the XML Metamodel Interchange (XMI),
and the evolution of the standard from UML 1.4 to UML 2.0.
UML Bible presents each concept in the UML specification with an introduction that assumes no prior knowledge
and progresses through a complete description of its advanced application, while pointing out the changes from
UML 1.4 to UML 2.0. For example, the Class diagram includes a number of modeling elements. Each element is
explained from the basics to the complete specification. Then the entire Class diagram is explained, using the
individual modeling elements together to build a complete example.
In like manner, many concepts at times come together, as in the relationships between Class diagrams and
Sequence diagrams. Here, too, the book presents an introduction to the basic relationships and their
consequences and then proceeds with a complete description of how those relationships might play out in your
software modeling process.
This is unlike many other books that progress from beginning to end, using the first chapters as an introduction and
later chapters for the more advanced topics. But I believe that you will find the approach in UML Bible most
effective for this particular subject. You will quickly be able to recognize the presentation pattern. As you become
accustomed to the approach, you can choose to skip over sections that you might already be familiar with and
focus on the new material that is most useful to you.
It is my hope that UML Bible will provide you with both an appreciation for the usefulness of the software modeling
resources of UML and a working knowledge of the tremendous potential that these tools and concepts have for
improving the way you build software.
Who Should Read This Book
This book presents everything you need to know in order to become proficient and productive at modeling software
with UML. It includes my own experience, and insights from many of the authors and teachers with whom I've had
the pleasure of working, as well as the works of many of the industry leaders.
UML Bible is aimed primarily at those people responsible for the countless hours of communication between users
and IT staff and at those tasked with turning the user's wishes into code. Participants at every level of the software
development process stand to gain from this book:
People who are new to OO modeling will get a step-by-step introduction to everything from basic concepts
of object orientation that support the modeling notation and process to insights into the use and application of
the models. You will quickly obtain a working knowledge of the diagrams used by your teammates so that you
can become an active participant in the review and enhancement of the models.
Experienced modelers will be able to dig a little deeper and discover the relationships between the various
diagrams and how they may be used to test the quality and completeness of the whole model. If you want, you
will be able to exploit the rigors of OCL and Action Semantics as well.
Programmers will gain a working knowledge of the models that the analysts and designers are asking you to
implement. Communication will improve as you become comfortable with the vocabulary used by both
technical and non-technical team members to describe the software requirements. The models will become
your roadmap for understanding existing systems, new systems, and ideas for enhancements in a way that
code alone cannot, while leaving open the freedom to incorporate new techniques and technologies in your
implementation.
People evaluating modeling tools will gain a complete understanding of the features and benefits that you
should expect from such a tool.
Managers and project leaders will gain an appreciation for the power and value of the modeling process as
a means to solve many of the problems that plague the software development process. Hopefully, you will
also come to appreciate the value of having a rigorous and testable tool to understand and solve a problem
before committing to the expense and uncertainty of code. In short, I hope you come to see that "the model is
the code" (more of that sermon later ).
<Day Day Up>
<Day Day Up>
Why You Need This Book
To get the most out of this book, you need to appreciate the intense challenges inherent in today's software
development environment. Smarter people than I have worked long years at developing real-world strategies to
address these challenges. UML is the distillation of a key component of many of these road-tested strategies,
namely, communication.
Communication of needs and ideas is the substance of the software development process. The quality of
communication between analysts, developers, trainers, testers, managers, and users can make or break a project.
As a software professional, you are used to dealing with most, if not all, of these classic communication
challenges. See whether these examples sound familiar.
Poor communication leads to delays and extra cost
As systems change, all project participants must keep informed of the nature and impact of those changes on the
requirements and solutions already in progress or already implemented. Without a standard way to communicate,
everyone is left to his own creativity. You've probably seen teams where more time is spent in meetings than
actually working. The meetings use up valuable time in an effort to communicate. One person uses flowcharts;
another person uses screen layouts; others use volumes of written specifications. The project incurs the overhead
of becoming familiar with a variety of communication styles and techniques.
Meanwhile, individual developers who need to apply badly needed changes have to instead labor with widely
varied types of documentation to try to understand and repair complex systems. In a straw poll that I conduct in
each class, students are asked how they handle a request to change an existing system when the documentation
is difficult to understand or nonexistent. Almost without exception, the students say they simply rewrite the code.
For those of you managing the budget, that means that they are throwing away a corporate asset simply because
they can't understand it and didn't have the time to try. Then they are spending more time creating an entirely new
and untried solution than they would in making a simple correction-if they only knew where to make it.
Translation: Poor communication = slower projects and higher cost of maintenance
The volatile nature of the IT work environment
Between corporate restructuring, economic ups and downs, and team members' personal lives, teams are
constantly changing. The typical mode of each developer keeping everything in her head or in what she believes is
well-documented code produces a tremendous liability. As people move from project to project and as priorities
shift and budgets are cut, the knowledge of the system goes away with the well-meaning people who last worked
on it.
Many of you are living with this problem today. Two years ago, when companies were throwing money at IT, you
had plenty of staff to cover each system. Since the summer of 2001 the situation has changed substantially.
Where you once had people dedicated to each system, you now have one person covering five systems that he's
never seen before. Without a description of the workings of the system, the only way to know how to make
changes is to read thousands of lines of code. While the staff is reading, it isn't making the badly needed changes.
When changes are made, no one can be certain that they are the right changes.
A system is a corporate asset and as such it must live beyond the participation of any one individual, and it must do
so without incurring the overhead of rewriting with every change in personnel.
Lack of control over the development process and product quality
Another consequence of developers keeping everything in their heads or in the code itself is the complete trust
demanded of management. Unless a manager is willing to learn and read the code herself, she cannot assess the
quality of the product. Testing is the standard response to this problem. But any programmer knows that it is easy
to get an application to pass the test suite. After all, in many cases it is the developer who writes the tests.
Consequently, the application works "just like I said it would." But does it work like it really should?
Quality is more than passing a test. Quality implies durability, flexibility, maintainability, low cost of maintenance,
and much more. Unfortunately, because code is difficult to understand and poorly documented, if documented at
all, over time the code becomes a collage of patches and add-ons in response to change requests. I suspect that if
you would poll your team and evaluate your own experience, you'd find that most rewrites of systems result in
radically reduced amounts of code yet increased functionality specifically because rewriting enables you to
eliminate all of those patches and focus back on the real requirements.
The foremost lesson that I hope you take away from this book is that every participant on a project has to go
through the same thought process to decide what code to write. Modeling is simply a visual and standardized way
to step through that thought process of leveling in a way that all participants can understand, verify, and discuss.
With the current modeling tools available, there is every opportunity to keep your models in sync with your code, or
even generate and maintain your code from the models, while never actually touching the code.
Changing requirements
The longstanding rift between IT project members and clients nearly always centers on requirements. In fact,
Capers Jones of Software Productivity Research, and author of Software Systems Failure and Success, did a
study on litigation over software. Almost without exception, software litigation is based on a debate over
requirements. The clients claim that their requirements were not satisfied. IT says that the clients kept changing
their requirements. What is even more disturbing about the results of this study is the fact that all of the projects
studied were bound by contract. How much worse is the problem where there is no contract that formalizes the
requirements?
Without means to track requirements and means to trace those requirements into the finished product, there is no
way to find out where the problems crop up. Is the client really changing his mind? Did IT really fail to include
requirements? In my experience, I have found that when an analyst or designer does not have a disciplined
approach to gathering requirements, the project hinges on intangible and highly risky factors: the developer's
memory, work habits, personal life, communication skills, and his relationship with the client. If any of these factors
is less than ideal, the project is at risk.
Very often it is not true that the client changed her mind. Instead, the developer simply did not ask the right
questions, did not ask the right people, or simply did not challenge what the client was telling him. The developer
may be hurried and have no interview plan and no way to capture the client's knowledge except with notes and
nonstandard drawings, neither of which may be tested or traced.
A standardized approach to analysis and to capturing the work products of analysis can rapidly eliminate these
problems and just as rapidly elevate the skill level of the people using them. Using the same techniques over and
over, sharing the results with others using the same techniques, and using the work products to communicate with
all participants in the development effort fosters proficiency and facility and reduces the possibility of
misunderstandings and misrepresentations.
The debate over methods and tools
It is easy lately to get caught up in the feverish debate over development methodologies. Tool vendors know this
best because they have to support these warring factions. Every software development method has at least three
parts: a process, process management, and a vocabulary for expressing the work products of the process.
Process management follows many of the same principles used for managing other business processes. The
process itself is a still greater challenge. Software development is far too diversified to allow just one process.
Transaction-oriented systems simply are not the same as real-time systems, which are different still from game
software or e-commerce. Even the size of the specific project changes the process requirements.
What can be standardized is the vocabulary for expressing the work products of the process. UML offers a solution
for standardizing the way you describe your work products no matter what method you follow. It does not dictate
that you use all of the features or how you use them. But it does help ensure that we can all express our
knowledge and ideas in a consistent manner that we can all understand equally, which radically reduces the
learning curve and the time needed to share requirements and ideas about solutions.
This standardization has opened the door for a wealth of tools that automate the creation, maintenance, and
tracking of these work products. With the standard in place, the vendors have been able to focus more effort on
feature-rich development environments, customization, and integration with valuable technologies such as
database management systems, change management, integrated development environments (IDE), and
frameworks.
The demand for cost effective and high quality systems
A particular strength of modeling is that it reveals our assumptions. Without reading mountains of code we can
measure communication traffic, evaluate quality by assessing coupling and cohesion, and test our models before
we write faulty code. Modeling accomplishes these objectives by raising the level of abstraction. Years ago we
wrote Assembler code, just one level above machine language. Then we moved to third-generation languages
such as COBOL. The assembly programmers of the time thought COBOL just couldn't do what Assembler could
do and would eventually go away. They insisted that to write applications, you had to know how the machine really
works. How many of you (other than game programmers) write any Assembler today, let alone develop systems
with it? In contrast, how many hundreds of millions of lines of COBOL code are in production today?
The Assembler programmers were missing an essential fact in their machine-centric perspective. That is, the only
reason to write code is to solve a problem. The machine and the languages are tools to solve a problem, not the
end itself. Still today, when our focus is forced onto the technology (Java versus C++, JSP versus ASP, and so
forth) and away from the problem, we risk losing sight of our real purpose and the factors that define true success,
and that is not whether the code is finished, but does the application do what we need it to do and can it survive the
inevitable changes?
UML is an attempt to express in precise, familiar, and consistent language everything needed to generate
complete, stable, maintainable systems. UML is a level of abstraction above the current programming languages,
just like COBOL was a level above Assembler. People like Leon Starr and Stephen Mellor have been generating
complete systems from models since the mid-1980s. I'm not talking about code generators that belched out
bloated low-performance code, or CASE tools that generate Java declarations but not the method body. I'm
talking about customized generation of the complete application, even generating a single model in multiple
implementation environments.
The question is not whether this is possible. The question is, when will we adopt modeling as the next generation of
coding? Oops, I tripped over my soapbox again .
<Day Day Up>
<Day Day Up>
How This Book Is Organized
This book is organized into Parts, which are groups of chapters that deal with a common theme. Here's what you'll
find:
Part I: An Introduction to UML
UML is actually the culmination of years of effort to isolate and standardize the tools used to express business and
software concepts. Chapter 1 explains the development of UML so that you can understand what it looks like today
and why. Other chapters introduce you to UML architecture, the UML diagrams and extensions, and the basic
concepts of object orientation that provide the foundation for the modeling concepts captured in UML diagrams.
Part II: Modeling Object Structure
UML defines a number of diagrams suited to capturing unique aspects of software requirements. One such aspect
includes definitions of the resources used by the application and the resources that make up the application itself.
Part II covers the Class and Object diagrams, as well as the Composite Structure diagram and collaborations,
including their structure and usage. The modeling elements explained include classes, attributes, operations,
associations, objects, links, inheritance, and patterns.
Part III: Modeling Object Interactions
Once the resources have been identified and you have scoped their purpose and role within the design, you need
to put the resources to work. Work implies cooperation. Cooperation requires communication. Part III presents the
many different interaction diagrams used to model how objects talk to one another when you run the application. It
also explains the use of the Statechart diagram to model the changes in an object over its lifetime. The modeling
elements explained include messages, events, and states.
Part IV: Modeling Object Behavior
It is one thing to say that a system or object does something. It is another thing entirely to explain how it is
supposed to do that something. Part IV explains how the UML Use Case diagram models the behavior of a system
from the perspective of the users, while the Activity diagram can model behavior at any level of abstraction from
workflow to method implementation. The modeling elements explained in this part include use cases, actors,
dependencies, activities, decisions, object flow, and partitions.
Part V: Modeling the Application Architecture
When you are ready to implement your system, or understand an existing implementation, you'll need a way to
model the software and hardware elements that make up the system configuration. Part V illustrates the use of the
Component and Deployment diagrams for modeling the implementation environment. The modeling elements
explained include packages, components and artifacts, nodes, interfaces, and ports.
Part VI: Bringing Rigor to the Model
Part VI takes you beyond the diagrams of the UML standard to the syntax and semantics for implementing
requirements regarding rules and behavior. The Object Constraint Language enables you to model the rules that
define the correctness of the relationships between model elements and the validity of values for a model element.
Action Semantics enable you to specify, in an implementation-language-independent manner, behaviors that are
ultimately implemented in code.
Part VII: Automating the UML Modeling Process
The UML standard has made it easier for modeling tool vendors to support the diagramming process and code
generation. Part VII offers a description of the capabilities of today's modeling tools. Beyond the tools, or rather
beneath the tools, lie the infrastructure elements that make using the models and exchanging them possible. This
part presents the XML Model Interchange (XMI) standard that helps make it possible to share models between
modeling tools and other XMI-compatible applications. Finally, it explains how the UML can be customized using
Profiles that tailor the features of the UML diagramming standard to specific industries or application types.
<Day Day Up>
<Day Day Up>
The Companion Web Site
The companion Web site for this book, located at http://www.wiley.com/compbooks/pender, includes the following
elements:
A list of UML resources so that you can keep up with the latest news on UML developments, tools, vendors,
and forums.
Modeling tool vendor links so that you can investigate the available tools.
Links to online courses about using UML.
The complete set of diagrams for the Ticketing System in PDF format and the original modeling tool files.
<Day Day Up>
<Day Day Up>
Conventions Used in This Book
Every chapter in this book opens with a quick look at what's in the chapter and closes with a summary. Along the
way, you also find icons in the margins to draw your attention to specific topics and items of interest.
Here's what the icons mean:
Cross-Reference These icons point you to chapters or other sources for more information on the topic
under discussion.
NoteNotes provide extra information about a topic, perhaps some technical tidbit or background explanation.
TipExpert Tips offer ideas for the advanced user who wants to get the most out of UML.
CautionCautions point out how to avoid the pitfalls that beginners commonly encounter.
Since one purpose of this book is to highlight the changes between UML 1.4 and UML 2.0, I often use figures that
highlight the new or modified portions of the UML metamodel. Figure FM-1 is an example of a diagram that uses
gray shading to identify differences between the two versions of UML. The gray rounded rectangle is not part of the
UML notation. It is there only to help you quickly identify the details that have changed.
Figure FM-1: Using gray shaded rounded rectangles to highlight changes in the metamodel.
I use the same convention when I need to focus attention on a specific item in a diagram, especially when
explaining examples for concepts and notations, as shown in Figure FM-2. Here, as in the previous example, the
gray rounded rectangles are used only to help identify key elements of the figure. They are not part of the UML
notation.
Figure FM-2: Using gray shaded rounded rectangles to highlight elements of an illustration.
<Day Day Up>
<Day Day Up>
Part I: An Introduction to UML
In This Part
Chapter 1: What is UML?
Chapter 2: UML Architecture
Chapter 3: UML Diagrams and Extension Mechanisms
Chapter 4: Object-Oriented Concepts
<Day Day Up>
<Day Day Up>
Chapter 1: What Is UML?
Overview
The Unified Modeling Language (UML) has been formally under development since 1994. UML is a distillation of
three major notations and a number of modeling techniques drawn from widely diverse methodologies that have
been in practice over the previous two decades. During this time it has had an undeniable impact on the way we
view systems development. Despite early competition from existing modeling notations, UML has become the de
facto standard for modeling object-oriented software for nearly 70 percent of IT shops. UML has been adopted by
companies throughout the world, and today more than 50 commercial and academic modeling tools support
software and business modeling using UML.
UML enables system developers to specify, visualize, and document models in a manner that supports scalability,
security, and robust execution. Because UML modeling raises the level of abstraction throughout the analysis and
design process, it is easier to identify patterns of behavior and thus define opportunities for refactoring and reuse.
Consequently, UML modeling facilitates the creation of modular designs resulting in components and component
libraries that expedite development and help insure consistency across systems and implementations.
Unlike previous methodologies, you don't have to change the way you work just to suit the demands of a vendor or
methodologist. UML uses extension mechanisms to customize UML models to a particular application type or
technology. While the extension mechanisms are a bit limited today, they do provide substantial support for
tailoring UML to the needs of a specific project, whether the project's goal is a transaction-oriented application,
real-time or fault-tolerant system, or e-commerce or Web service, and regardless of the subject domain.
UML profiles collect predefined sets of extension mechanisms for a specific environment. For example, in the UML
specification itself you will find profiles for J2EE, COM, .NET, and CCM development. Each profile provides
customized modeling elements that map to the common elements and features in each of these architectures.
This approach enables the modeler to focus time and energy on the project content instead of the unique
modeling features of the implementation domain.
The standardized architecture of UML is based on the Meta-Object Facility (MOF). The MOF defines the
foundation for creating modeling languages used for object modeling, such as UML, and for data modeling, such
as the Common Warehouse Model (CWM). The MOF defines standard formats for the key elements of a model
so that they can be stored in a common repository and exchanged between modeling tools and languages. XML
Metadata Interchange (XMI) provides the mechanism to implement the sharing of these modeling elements
between modeling tool vendors and between repositories. This means, for example, that a project can use one
tool for developing a platform-independent model (PIM) using UML diagrams and switch to another tool to refine
the model into a platform-specific model (PSM) using a CWM model to generate the database schemas. This
standards-based approach places the choice of tools in the hands of the modelers instead of the tool vendors.
UML models can be precise enough to generate code or even the entire application. Automated test suites can
verify the accuracy of the model. When coupled with tools to compile the UML model, the model can even be
executed before any code exists. Vendors (for example, Kabira Technologies http://www.kabira.com and Project
Technology, Inc. http://www.projtech.com) are already providing compilers that are being used in projects today. A
fully executable UML model may be deployed to multiple platforms that each use different technologies. A model
might be deployed in one place using one language, middleware, and database configuration, and at another
location with an entirely different configuration. The mapping of the model to an implementation configuration is
accomplished using a profile, with a separate layer that maps the two requirements, the model and the
implementation environment. To use the model in other implementation environments, simply create a new profile.
Thus the UML profile represents a level of indirection between the model and the implementation environment,
freeing each to be created independently of the other.
All of these features didn't appear overnight. A great deal of collaborative effort was invested to create the current
standard, and not without conflict. You may have already heard people taking sides on a variety of modeling issues
and practices that arise when they try to use UML. To clarify some of the reasons behind these debates, I begin
with a brief history explaining how UML first came to be. If you can understand the process behind the ongoing
development of the standard, you will be better equipped to follow the changes between version 1.4 and the new
developments in version 2.0 described throughout the rest of this book. Even more important, you need to
understand how UML fits into the much larger plan by the Object Management Group (OMG) to standardize
systems development with Model-Driven Architecture (MDA).
Since UML 2.0 is pending as of the writing of this book, I have included both UML 1.4.1 and UML 2.0. I hope this
will help those of you who might be using modeling tools based on UML 1.4.1 until you are able to upgrade. At the
same time it should give you some insights for evaluating either your existing vendor's implementation of UML 2.0
or other new modeling products. For a more complete explanation of this approach, refer to "How to read this
book" in the Preface.
NoteWhen the OMG added Action Semantics to the 1.4 specification, it originally called it "UML 1.4 with
Action Semantics." It later appeared on the OMG site as UML 1.5. So don't be surprised if I accidentally
bounce between references to 1.4 and 1.5.
The rest of this chapter discusses
The history of the UML through version 1.4
The goals, scope, and features of the UML
The objectives of UML 2.0
The role of the Object Management Group (OMG)
How UML fits into the bigger picture: The OMG's Model-Driven Architecture (MDA) initiative
<Day Day Up>
<Day Day Up>
Understanding the History Behind UML
UML is designed specifically to represent object-oriented (OO) systems. Object-oriented development techniques
describe software as a set of cooperating blocks of information and behavior. For example, a performance at a
theater would be coded as a discrete module with its own data about dates and time, and behavior such as
schedule, cancel, or reschedule all rolled together. This was a stark departure from the old notion that data
resides in files and behavior lives in programs.
The effect of this simple idea, the combining of data and behavior into objects, had a profound effect on
application design. As early as the 1970s, a number of methods were developed to exploit the new object-oriented
(OO) programming concepts. Developers quickly recognized that object orientation made possible a development
process in which the way that they talk about the application corresponds directly to how they code it. They also
found that it was relatively easy to draw (model) the objects so that they could talk about the design. Each object
was represented as an element on a diagram. Because the model elements were almost identical to the code
elements, the transition from model to code was simple and efficient. Moving design discussions up to the models
instead of the code helped the developers deal with design issues at a high level of abstraction without getting
caught up in the coding syntax.
Early Modeling Methodologies
Software developers weren't the only people who discovered the benefit of modeling. Other engineering disciplines
such as database management and design were also creating modeling techniques such as Entity Relationship
modeling (ER diagrams) and Specification and Description Language (SDL). It quickly became clear that modeling
provided a way to cope with complexity, encourage collaboration, and generally improve design in all aspects of
software development.
The need for modeling solutions increased with the growth in numbers and sophistication of software systems.
Systems were growing rapidly in complexity and required more and more collaboration and solid, durable design
quality. Modeling had proven itself in exactly these circumstances. Literally hundreds of people sprang to work
developing modeling methodologies to solve the growing problem. But the resulting proliferation of solutions
caused some problems. The widely diverse efforts were inefficient in that they lacked the necessary collaboration
to produce results that could be widely applied by the IT community. In fact, the diversified approach resulted in
what were affectionately called the "method wars", battles between method authors with their loyal followers pitted
against one another over who had the best solution. Authors of each method vied for support for their methods.
Tool vendors labored to support many different notations in the same tool. Companies struggled to identify and
follow a single "best" method, train their people, and support the method only to find that no one method could
fully meet their needs.
The proliferation of isolated solutions and the associated battles were signals that the need for a comprehensive
solution for software modeling was a priority. The solution needed to be flexible, scalable, secure, and robust
enough to handle the diverse software and business environments of the present and the future.
The Creation of UML
By the early 1990s, a few leaders had emerged from the field of methods and notations. Object-Oriented Software
Engineering (OOSE), developed by Ivar Jacobson, is based around the use-case concept that proved itself by
achieving high levels of reuse by facilitating communication between projects and users, a key success factor for
IT projects. James Rumbaugh developed the Object-Modeling Technique (OMT) with an emphasis on the analysis
of business and data intensive systems for defining a target problem, a second key success factor for IT projects.
The Booch method, developed by Grady Booch, had particular strengths in design and implementation, defining
and mapping a solution to the target problem, a third key to successful IT projects. These significant contributions
are like the legs on a three-legged stool: the combination of the three methods and their notations supported the
entire range of requirements needed to create a single, comprehensive software-modeling standard.
It is important to point out that many other methods provided some of the same three key factors. The difference is
that they did not aggressively seek to combine their efforts to address the bigger picture, a standards-based
approach to modeling software. In October 1994, Grady Booch and Jim Rumbaugh, working at Rational Software
Corp., started merging their two methods. The independent evolution of their two products was bringing the
methods closer together anyway; Booch was adopting more of an analysis focus and Rumbaugh was assuming
more of a design focus. Now the deliberate reconciliation began in earnest. The effort resulted in a greatly
simplified notation and a deliberate effort to address the need for a true language architecture rather than simply a
notation. An architectural approach would bring the needed semantic integrity and consistency for a durable
standard.
A year later, in the fall of 1995, Booch and Rumbaugh had completed the first draft of the merged method referred
to as Unified Modeling Language version 0.8. About the time that the draft was completed, Ivar Jacobson and his
company, called Objectory, joined Rational Software Corp., and the "three amigos"-Booch, Rumbaugh, and
Jacobson-began integrating OOSE into the UML standard. The use-case concept brought to UML the essential
user-centric elements that completed the range of features to make UML the comprehensive standard that it
needed to be to gain wide acceptance.
Booch, Rumbaugh, and Jacobson established four goals for the Unified Modeling Language:
Enable the modeling of systems (not just software) using object-oriented concepts 1.
Establish an explicit coupling to conceptual as well as executable artifacts 2.
Address the issues of scale inherent in complex, mission-critical systems 3.
Create a modeling language usable by both humans and machines (UML 1.4, pgs. 1-12,13) 4.
The result of the collaborative effort of the three amigos was the release of UML versions 0.9 and 0.9.1 in the fall
of 1996. However, despite the fact that they sought feedback from the development community, they recognized
the need for broader involvement if the UML was truly to be a standard.
Enter the Object Management Group (OMG), the standards body that brought us CORBA, Interface Definition
Language (IDL), and the CORBA Internet Inter-ORB Protocol (IIOP). By this time UML was being recognized as
vital to the goals of many companies. It was in their best interest to see that the standard get the support it needed
to be completed. In response to this overwhelming need, the OMG published a Request for Proposal (RFP), and
then the Rational Software Corporation created the UML Partners consortium, which was committed to finishing
what the three amigos had started. Contributing members of the consortium included a mix of vendors and system
integrators: Digital Equipment Corporation, HP, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse,
Microsoft, Oracle, Rational Software, TI, and Unisys. The result of their efforts was published in January 1997 as
UML 1.0.
At the same time, another group of companies (IBM & ObjecTime, Platinum Technologies, Ptech, Taskon & Reich
Technologies, and Softteam) was working on and submitted another proposal for UML. And, exemplary of the
UML history, the alternative proposal was viewed not as competitive, but collaborative. The new team joined the
UML Partners consortium and the work of the two groups was merged to produce UML 1.1 in September 1997.
Since then, the OMG has assumed formal responsibility for the ongoing development of the standard, but most of
the original consortium members still participate.
In reading this brief history you've probably noticed that this all happened pretty fast. The drive to deliver the final
version so quickly had its consequences. While the architecture infrastructure and even the superstructure were
relatively well defined, some problems remained. For example, the Activity diagram did not have the ties to the
state machine semantics required to support all of the features and notations needed for real business modeling.
Also, many of the Standard Elements were added hastily and had not been fully defined. Most important, the
meta-modeling approach fell short of the desired implementation, making it difficult to align UML with the Meta-
Object Facility (MOF), a foundation technology in the OMG's MDA strategy. Fortunately, the standard is still
evolving.
The OMG set up a Revision Task Force (RTF) to oversee the ongoing evolution of the UML standard. The RTF is
responsible for addressing all questions, changes, and enhancements to UML and for publishing subsequent
releases. To date, the RTF has taken up more than 500 formal usage and implementation issues submitted to the
OMG for consideration. In fact, you can submit your own suggestions and comments on existing issues to uml -
rtf@omg.org.
The standard has since progressed through version 1.3 (1.2 was a purely editorial revision) and on to version 1.4.
The most recently adopted specification (September 2002) is version 1.4.1 with Action Semantics, which, as the
name implies, added action semantics to the 1.4 specification. Action Semantics is a critical element in the creation
of executable UML models.
Cross-Reference To learn more about Action Semantics, refer to Chapter 19.
<Day Day Up>
<Day Day Up>
The Goals and Features of UML
UML is designed to meet some very specific objectives so that it can truly be a standard that addresses the
practical needs of the software development community. Any effort to be all things to all people is doomed to fail,
so the UML authors have taken care to establish clear boundaries for the features of the UML.
The next section explains the objectives and the scope of the UML, the fundamental features provided by the UML,
and discusses the role of the OMG in the management and ongoing development of the UML as a part of its MDA
strategy.
The goals of UML
The OMG knows that the success of UML hinges on its ability to address the widely diverse real-world needs of
software developers. The standard will fail if it is too rigid or too relaxed, too narrow in scope or too all-
encompassing, too bound to a particular technology or so vague that it cannot be applied to real technologies. To
ensure that the standard will, in fact, be both practical and durable, the OMG established a list of goals.
UML will
Provide modelers with a ready-to-use, expressive, and visual modeling language to develop and exchange
meaningful models.
Furnish extensibility and specialization mechanisms to extend the core concepts.
Support specifications that are independent of particular programming languages and development
processes.
Provide a formal basis for understanding the modeling language.
Encourage the growth of the object tools market.
Support higher-level development concepts such as components, collaborations, frameworks, and patterns.
(UML1.4 specifications)
Each of these goals is discussed in detail in the following sections.
Goal 1: Provide modelers with a ready-to-use, expressive, and visual modeling
language to develop and exchange meaningful models
UML must be defined at a level that allows it to be used as-is off the shelf. Modelers should be able to start
building diagrams without first customizing the notation to their development environment, programming language,
or application. The modeling language should work equally well for Java and C++, for accounting and aviation.
To accomplish this, the standard has to define the semantics of the modeling language as well as the visual
representation of the language. Semantics provide the rigor that ensures the consistent application of the models
and model elements. A consistent visual representation of the model elements facilitates adoption and use of the
modeling technique.
The standard also must be comprehensive but not exhaustive. It must include all the core modeling elements
common to most, not all, software projects. If it is not complete, modelers will not be able to use it without
customization. If it is exhaustive-well, it just can't be. Instead, the OMG adopted the second goal.
Goal 2: Furnish extensibility and specialization mechanisms to extend the core
concepts
In overly simplified terms, the core concepts should represent the old 80/20 rule. We should be able to build 80
percent of the systems out there with 20 percent of the conceivable concepts. When these core concepts are not
enough, there should be a way to build on them to get what we need.
Wherever possible a modeler should not have to invent entirely new concepts. Users should be able to use
concepts already defined by UML. There are at least three ways that UML enables modelers to create new model
elements:
The core defines a number of fundamental concepts that may be combined to create the new concept.
The core provides multiple definitions for a concept.
UML supports the ability to customize a concept by specializing one or more of its definitions. (To specialize
means to use an existing definition and then override and/or add elements to it.)
A UML-defined solution for wholesale extensibility is a profile. A profile is basically an implementation of UML for a
specific domain, such as a particular technology platform or a specific line of business. A profile predefines a set of
model elements that are unique or simply common to the target environment. In this manner, profiles tailor the
modeling elements so that the modeler can represent his environment more accurately than is possible with
generic UML but without losing any of the semantic clarity of UML concepts.
Goal 3: Support specifications that are independent of particular programming
languages and development processes
One very valuable reason for modeling is to separate the requirements from the implementation. Tying UML to a
particular language automatically alienates everyone not using that language. An implementation also ties UML to
a point in time. For example, when the programming language changes, UML becomes obsolete until it can be
brought up to date.
However, UML must map to the common object-oriented design constructs defined in most OO languages. This
alignment will support code generation and reverse engineering, the integration of the modeling and coding
environments. But rather than alter UML to conform to languages, the mapping is accomplished through profiles
that define the relationships between the model elements and the implementation constructs. Using a separate
mapping layer effectively decouples, or separates, UML from the implementation languages, allowing both to
evolve at their own pace.
Goal 4: Provide a formal basis for understanding the modeling language
The language must be defined at a level that is precise yet accessible. Without precision, the models do not help
define a real solution. Without accessibility, no one will use it. The UML standard uses Class diagrams to represent
the formal definitions of objects and their relationships. Each Class diagram is supplemented with text detailing the
semantics and the notation options. The constraints that define the integrity of the model elements are expressed
using Object Constraint Language (OCL). (See Chapter 18.)
Goal 5: Encourage the growth of the object tools market
The modeling tool market is dependent on a unified standard for modeling, for the model repository, and for model
interchange. To the extent that vendors can rely on a stable standard, they can quickly and effectively implement
all three fundamental tool features. As the vendors cost to provide the core functionality decreases, vendors are
freed to pursue value-added modeling-environment enhancements such as integration with coding environments,
database management tools, syntax checking, model verification, and more.
We are seeing the effect of the standard today. The number of tools has mushroomed, and the feature sets
offered in the tools have exploded. Where tools used to focus almost exclusively on just being able to draw
diagrams, today they are performing syntax checking of OCL statements, diagram synchronization, code
generation and reverse engineering, importing from various other tools, exporting HTML or XML reports,
supporting integration with one or more coding environments, and much more.
Goal 6: Support higher-level development concepts such as components,
collaborations, frameworks, and patterns
The standard needs to support the modeling of higher-level concepts such as frameworks, patterns, and
collaborations. Doing so supports the advancement of modeling and systems development. By ensuring this future
potential, UML becomes an asset that facilitates technological evolution rather than being one more legacy that
has to be dragged into the future with all the other old technologies.
The scope of the UML
UML is designed to be the merging of best development practices and the leading modeling concepts of the past
30 years. There is also a deliberate effort to take into account the fact that development technologies and
techniques are always changing.
With such an ambitious goal, it would be easy to fall into the trap of making UML define everything-modeling,
development methodology, project management, systems integration, and so forth-about the software
development process. So the first and most visible boundary established by the OMG was to define only the
modeling language, including the semantics and the notation for creating models. Therefore, UML defines only the
modeling elements used to describe the artifacts of software development. It does not describe any process for
creating those artifacts. In fact, the intent of the standard is to create a language that may be used with any
process, much like you could hand someone a hammer and say, "Hang this picture" or "Build a house." The same
tool may be used for very different tasks. In the same manner, UML might be (and is) used with the Rational
Unified Process, Shlaer/Mellor, Agile Modeling, or any number of proprietary methodologies.
UML also says nothing about programming languages. The object-oriented concepts applied in modeling are the
same concepts applied in OO programming languages, but the relationship begins and ends with this common
foundation. For example, Java does not support multiple inheritance but UML does. Neither Java nor UML is going
to change because of this inconsistency. They each have their own goals and audiences that drive their choices
regarding how to support OO concepts. Again, the UML standard cannot be tied to a particular technology without
losing its ability to keep pace with advancements in technology.
Finally, UML does not seek to usurp other modeling techniques such as Business Process Re-engineering (BPR)
flowcharts or entity-relationship modeling. However, it has proven itself to be robust enough to bring added
precision, comprehensiveness, and flexibility to the same modeling domains. The infrastructure of UML (covered
later in this chapter) is actually designed to be the basis for defining any number of modeling languages. In the
event, and to the extent that, these other modeling techniques conform to the infrastructure, it will be possible to
exchange model elements between the various techniques. For example, a UML model could be input to an entity-
relationship model and vice versa. In fact, this is already implemented in some tools.
Features of UML
In addition to the set of diagrams defined in the UML specification, UML provides a set of features that derive from
a variety of sources but have all proven valuable in real-world modeling:
Extensibility mechanisms (stereotypes, tagged values, and constraints): No standard, language, or tool
will ever be able to address 100 percent of the users' needs. Trying to deliver such a tool would result in a
never-ending project without any product. Instead, UML authors focused on a core set of functionality and
features. Then they added a set of mechanisms-stereotypes, tagged values, and constraints-that may be used
to augment or tailor the core concepts without corrupting the integrity of those core concepts. Applying a
stereotype to a model element is like getting dressed up for a special occasion. You remain the same person
regardless of what you wear, but the attire helps you fit into the particular situation.
Stereotypes help identify the role of an element within the model without defining or altering its fundamental
purpose or function. Stereotypes for model elements work much the same as stereotypes for business
descriptions; that is, you might point out a company and identify it as an accounting firm, a shoe distributor, or
a grocery store. But it is still a company. Tagged values provide the means to add new model elements that
hold values-for example, author="Tom Pender". Constraints allow you to define rules regarding the
integrity or use of a model element, such as the attribute "name" must be between 1 and 40 characters
including spaces and punctuation, but no special characters. UML added OCL (see Chapter 18) for formally
specifying constraints.
Threads and processes: Threads and processes are an increasingly common aspect of applications. UML
supports the modeling of threads and processes in all of the behavioral models, including the enhanced
Activity diagram. (See Chapters 8 through 13.)
Patterns and collaborations: In recent years developers have come to appreciate more and more the value
of designs based on proven solutions. Patterns and collaborations allow the modelers to define standard
approaches to solving common problems. A pattern may then be applied to a variety of specific situations,
bringing with it a combination of predefined roles and interactions. Patterns and collaborations may be
identified and defined at many levels of abstraction, cataloged, and documented for others to use. This
approach brings reuse out of the realm of pure code and into every phase of the modeling effort, from
requirements and architecture through implementation.
Activity diagrams (for business process modeling): For years business and technical staff have relied on
the flowchart. UML renamed the flowchart to Activity diagram. The Activity diagram is a simple yet effective
tool to model logic. Logic appears throughout the development process in workflow, method design, screen
navigation, calculations, and more. The value of the Activity diagram cannot be overlooked so it has been
incorporated into the UML standard since the earliest versions. To bring it up to date, it has been enhanced
most recently with its own semantics, distinct from state machines, to represent control flow and/or object flow.
Refinement (to handle relationships between levels of abstraction): Many concepts, such as classifiers
and relationships, permeate all layers of systems development, and the semantics for these concepts hold
true regardless of the business or technical environment. Each abstraction layer adds to, customizes, and
otherwise refines the original definition. This approach supports and in some ways encourages the
development of varying applications of the concepts at each new level of abstraction. The result of this
approach has been the development of an increasingly holistic set of models for systems development, all
founded on the same conceptual standard, but each tailored to a unique perspective.
Interfaces and components: One advantage of modeling is the ability to work at different levels of
abstraction instead of always working at the code level.
Interfaces and components allow the modeler to work on a problem by focusing on the connectivity and
communication issues that can help solve that problem. The implementation or even the internal design of a
component can be ignored temporarily until the bigger issues of policy, protocol, interface, and communication
requirements are resolved. Working at this higher level of abstraction produces a model that later can be, and
often is, implemented in multiple environments.
Constraint language: The Object Constraint Language (OCL) provides the syntax to define rules that insure
the integrity of the model. Much of the constraint concept is borrowed from programming by contract, in which
relationships between model elements are defined in terms of the rules that govern an interaction. When two
parties enter into a contract, the terms of the contract place obligations on the client (the person asking for a
product or service) and the supplier (the one providing the product or service). Constraints called pre-
conditions define what the client must do in order to have the right to receive the product or service.
Constraints also define the obligations the supplier must fulfill if the client fulfills her part. These constraints are
called post-conditions or guarantees. Constraints can also apply to individual elements to define the domain of
valid values. (See Chapter 18.)
Action semantics: The goal of UML has always been to model software as accurately as possible. Modeling
software means modeling behavior. The action semantics extensions enable you to express discrete behaviors
as actions. Actions can transform information and/or change the system. Furthermore, UML models actions as
individual objects. As such, actions may execute concurrently. In fact, that is their normal mode of execution
unless chained together to enforce sequential execution. Settling on concurrent execution as the norm better
supports today's distributed environments. Action semantics is also a major contribution toward executable
UML. (See Chapter 19.)
<Day Day Up>
<Day Day Up>
Introducing UML 2.0
The next version of UML, 2.0, is due to be released sometime in 2003. Three proposals have been submitted. I
have based the content of this book on those submissions and my expectation that they will be adopted in whole or
in part. Version 2.0 is a substantial improvement of the underlying architecture, cleaning up many of the
fundamental definitions and improving the alignment with the other key technologies sponsored by the OMG.
I've outlined some of the specific objectives for version 2.0 set forth in the RFP. I don't expect beginners to UML to
understand them from these very brief descriptions. The rest of this chapter explains many of the new terms. The
rest of the book is devoted to explaining how these concepts have been addressed in the diagrams and in the
semantics that support the diagrams. For those of you who have been working with UML for a while, these items
should demonstrate the OMG's commitment to the long-term success of UML.
Improve the architecture: Rework the physical metamodel so that it is more tightly aligned with the MOF meta-
metamodel. Improve the guidelines that establish what constructs should be defined in the kernel language and
what constructs should be defined in UML profiles or standard model libraries. (See Chapter 2.)
Provide improved extensibility: Enhance the extensibility mechanisms to align them more closely to a true "four-
layer architecture." Profiles provide much of the customization support, at least in concept. But the extensibility
features used to create them (stereotypes, tagged values, and constraints) are still rather low-level. UML
extensibility features should align more closely with the MOF extensibility features, that is, metaclasses. (See
Chapters 2 and 3.)
Improve support for component-based development: Current technologies such as EJB and COM+ require a
means to model and manage component-based designs. The current semantics and notation are not quite up to
the task. (See Chapters 15 through 17.)
Improve the modeling of relationships: Improve the semantics for refinement and trace
dependencies. Today it is difficult to support refinement of the models through the life cycle of a project, that is,
analysis to design or design to implementation. (See Chapter 6.)
Separate the semantics of statecharts and activity graphs: The initial UML specification tried to define activity
graphs as a specialization of a statechart. The overlap has created obstacles to business modeling and has
prevented the addition of valuable business modeling features. Support more relaxed concurrency in both
diagrams. Support specialization of state machines. (See Chapters 11 and 13.)
Improve model management: Update the notation and semantics for models and subsystems to improve support
for enterprise architecture views.
General mechanisms: Define support for model versioning.
<Day Day Up>
<Day Day Up>
The Object Management Group
The organization responsible for developing the UML goals described previously is the Object Management Group
(OMG). The OMG is the official steward of the UML standard. This is not simply because the OMG likes standards
or likes to take on work, but because it is the driving force behind a much larger plan for software development
called Model-Driven Architecture (MDA). MDA is a genuinely ambitious effort to standardize systems development.
The goal is to create a complete standard for the creation of implementation-independent models that may be
mapped to any platform, present or future. Did I say it was ambitious?
UML plays an integral role in the development and use of the MDA approach. UML is the language used to
describe the key standards of MDA, namely UML itself, the Meta-Object Facility (MOF), and the Common
Warehouse Model (CWM). UML is also used to create the work products of the MDA process, specifically the
business and implementation models.
Model-Driven Architecture (MDA)
Developers usually find that there is a division in most applications between the business logic and the
implementation mechanisms to support that logic. For example, selling tickets to a performance is a business
practice that could be implemented using any of dozens of technologies and techniques. But no matter how it is
implemented, there are fundamental rules that must hold true. If the rules for conducting the business transaction
are bound to specific implementation technologies, then changes in those technologies require changes to the
rules of the transaction. Such changes incur the risk either of corrupting the transaction or of causing delays while
you untangle the business from the technology. This makes even changing the application to take advantage of
technological advancements a risk to the business.
Model-Driven Architecture (MDA) separates the two fundamental elements of an application into two distinct
models. The platform-independent model (PIM) defines business functionality and behavior, the essence of the
system apart from implementation technologies. The platform-specific model (PSM) maps the PIM to a specific
technology without altering the PIM. That last phrase is critical. Defining a PIM is like defining the job description
"bookkeeper". We can define the purpose, responsibilities, qualifications, and skills for the job, that is, the PIM,
without knowing who will actually do the job. The PSM corresponds to hiring someone to do the job defined by the
bookkeeper job description.
This example highlights the power of the MDA approach. I can hire different people over time. I can even hire
multiple people at the same time to perform the book-keeping duties. I can even take the job description to another
company and use it there. In the same manner, I should be able to take the same PIM and deploy it in many
technologies or even in different businesses.
The division of the two models also supports interoperability. A business function does not need to know the
implementation of another business function in order to access it. The interface is defined in PIM fashion. The PSM
takes care of the mapping to the implementation. So the calling function is unaffected by changes to the
implementation of the called function. In the bookkeeper example, the bookkeeper PIM/job description can define
an interface to the general ledger. Where or how the general ledger is implemented is irrelevant. The interface is
always the same. Whether I implement the bookkeeping system at a department store, software consulting firm, or
insurance company, and whether the system is implemented in .NET or Java One, the interaction between the
bookkeeper and the general ledger is the same. So, as technologies change over time, as they inevitably will, the
business remains stable and relatively unaffected by the changes.
This same concept applies to functions that should be globally available to systems such as transaction
management, domain specific services, and application services. Having learned from its experience with the
CORBA-based Object Management Architecture, OMG recognizes the need for three levels of MDA-based
specifications built on the standardized technologies already defined by the OMG (see Figure 1-1):
Pervasive Services include security, transaction management, directory support, and event generation and
handling common to most systems.
Domain Facilities include standardized models for subject areas such as telecom, space sciences,
biotechnology, and finance.
Applications are within a domain, such as a heart monitor in the biotechnology domain or a funds transfer
application in a financial domain.
Figure 1-1: The Model-Driven Architecture.
The core of the MDA is the set of standards (MOF, UML, CWM, and XMI) and technologies (CORBA, .NET, Java,
and so on). The pervasive services are built on that core. Then based on these standards and services, businesses
can build domain specific profiles for finance, e-commerce and so on. Within each domain, businesses may then
build specific applications that conform to the supporting standards.
The Pervasive Services
The features included in the Pervasive Services level are those commonly found in the existing list of CORBA
services:
Directory services
Transactions
Event handling/notification
Security
The list is sure to grow in time with additions from the OMG itself, based on CORBA, and from CMG members.
Work has already started on mapping these services to PIMs so that they can be applied to all platforms through
the MDA development approach.
Domain Facilities
A domain is simply a subject area, such as warehousing and distribution, or biotechnology. Each domain has its
own peculiar set of problems and concepts. For example, there are many banks but they all conduct the same
type of business. The resources they use, the behaviors they support, and even many of the regulations that
govern their performance are the same. The differences arise in how they choose to embellish the basic business
to appeal to their customers and to improve profitability. A domain is the description of the fundamental elements
common to all systems in the same subject area. The uses of those fundamental elements define the applications
within the domain. These applications are covered in the next section.
Work has already begun on a number of domain models. Even though MDA-based standards for specific domains
are still under development, OMG Domain Task Forces (DTF) have started to apply MDA to existing projects. For
example, OMG's Life Science Research DTF, working in biotechnology, has already modified its Mission and
Goals Statement to reflect its work in MDA. In mid-2000, even before MDA, OMG's Healthcare DTF (formerly
know by its nickname, CORBAmed) published its Clinical Image Access Service (CIAS) (http://www.omg.org/cgi-
bin/doc?dtc/01-07-01) including a nonstandard UML model that describes the specification written in OMG IDL.
The document provides a good example of what a future MDA specification might look like.
NoteIn a true MDA specification, the model follows the UML standard and is fully developed, defining all
interfaces and operations including parameters and types, and specifying pre- and post-conditions in
OCL.
MDA Success Stories
Companies who have applied/are applying MDA include:
Regions Bank of Birmingham, Alabama
Swedish Parliament
Deutsche Bank Bauspar AG
U.S. Government Intelligence Agency
The Open System Architecture for Condition Based Monitoring (OSA-CBM) Project
CGI
ff-eCommerce
Swisslog Software AG
Adaptive; Adaptive Framework
Financial Systems Architects
Headway Software; Headway review
IKV++ GmbH; m2c(tm)
Applications
For years, businesses have started projects by modeling the business application requirements. As the projects
proceeded, they fell deeper and deeper into implementation-dependent modeling, often losing sight of the original
business requirements in the midst of the overwhelming task of working with ever-changing implementation
technologies. As MDA-based development tools become more widely available, projects can be focused more on
the platform independent model of the business requirements. In fact, the focus throughout the project will remain
on the original requirements while the implementation becomes more and more automated through the
application of platform specific models.
Lest you think that this is a pipe dream, take a look at the list of companies in the sidebar who are already using
this technique successfully. Many more companies are listed at http://www.omg.org/mda/products_success.htm.
Meta-Object Facility (MOF)
The Meta-Object Facility (MOF) is at the heart of the MDA strategy along with the UML, CWM, CORBA, and XMI. It
is the starting point, the standard that defines the languages used to describe systems and MDA itself. The MOF is
a metamodel (often called M2), a model defining the concepts required to build a model and to store the model in
a repository. The model is stored by representing the metadata as CORBA objects.
Cross-Reference Models, metamodels, and meta-metamodels are more fully explained in Chapter 2.
Currently the MOF defines all the foundation concepts needed to build the two modeling languages UML and
CWM. Now just to make this a little more confusing, both UML and CWM are themselves metamodels. They are
models that define modeling languages. When a metamodel like MOF is used to define another metamodel, it
becomes a meta-metamodel, or M3 for short. Since all elements defined by UML or CWM conform to the MOF
standard, it is possible to define a standardized repository for all data generated in UML or CWM or, in the future,
any other languages derived from MOF.
The model elements in the UML are created, or instantiated, from model elements defined in the MOF. For
example, the MOF defines the concept "Classifier." UML defines a concept called "Classifier" that inherits the
description in the MOF and then adds to it for the purpose of modeling objects. CWM also inherits "Classifier" but
for a different reason: CWM adds to the "Classifier" definition to support modeling data. Figure 1-2 illustrates this
relationship between the three models.
Figure 1-2: The relationship between the MOF and the UML and CWM languages.
MOF is also part of the long-term OMG strategy to support the creation and exchange of a variety of metamodels
across diverse repositories. For example, using the MOF, a UML model might be transmitted between tools by
different vendors. Likewise, a UML object model might be ported to a data-modeling tool in order to derive a logical
data model from the object model.
MOF supports this long-term strategy by providing
The infrastructure for implementing CORBA-based design and reuse repositories
The definition for a set of CORBA IDL interfaces to define and manipulate metamodels and the models
created using them
The rules for automatically generating the CORBA interfaces for metamodels, thus insuring consistency
Common Warehouse Metamodel (CWM)
The Common Warehouse Model (CWM) was developed in cooperation with the Meta-Data Coalition (MDC). The
goal of CWM was to provide to the data modeling community the same type of solution that UML provided to the
object modeling community. In the same way that UML describes a common modeling language for building
systems, CWM describes metadata interchange among data warehousing, business intelligence, knowledge
management, and portal technologies. Like UML, CWM is a language derived from the MOF. CWM provides the
mapping from MDA PIMs to database schemas. CWM covers the full life cycle of designing, building, and
managing data warehouse applications and supports management of the life cycle.
You can find the specifications for CWM at http://www.omg.org/technology/documents/formal/cwm.htm. Two other
specifications to extend CWM to the Internet are also currently under way: CWM Web Services
(http://www.omg.org/techprocess/meetings/schedule/CWM_Web_Services_RFP.html) and CWM Metadata
Interchange Patterns (MIP) (http://www.omg.org/techprocess/meetings/schedule/CWM_MIP_RFP.html).
XML Metadata Interchange (XMI)
At its simplest level, XMI defines a mapping from UML to XML. It defines standard formats and Document Type
Definitions (DTD) to capture UML models (and metamodels). This makes it possible to then convert a UML model
into XML, distribute it pretty much anywhere, and then convert it back to UML. The mapping also makes it possible
to exchange UML models between tools and across platforms.
Cross-Reference You can read more about XMI in Chapter 22.
Technically, XMI mapping uses MOF metadata, not UML. But since UML is based on the MOF metadata, anything
defined by UML is compatible with XMI mapping features. Additional work is being done to extend XMI to support
W3C-standard XML schema.
<Day Day Up>
<Day Day Up>
Summary
UML grew out of the increasingly complex challenge to build systems that not only met users' requirements but
that could withstand the ever-changing technological environment. Change, complexity, and speed conspired to
focus critical attention on how to build robust, durable systems. One result was a standard language for modeling
systems, the Unified Modeling Language (UML).
But the desire for truly industry-capable tools to build systems did not stop there. The OMG has continued to
spearhead the effort to build a comprehensive strategy in the form of Model-Driven Architecture (MDA).
There are a lot of languages involved in these strategies. Here's how they all relate:
The Meta Object Facility (MOF) defines a common meta-language for building other languages.
UML defines a meta-language, derived from the MOF, for describing object-oriented systems.
The Common Warehouse Metamodel defines a meta-language, derived from the MOF, for describing data
warehousing and related systems.
XML Metadata Interchange defines the means to share models derived from the MOF.
<Day Day Up>
<Day Day Up>
Chapter 2: UML Architecture
In every version of the UML, the authors have applied a four-layer metamodel architecture. Although time
pressures kept the original specification's implementation from being all it needed to be for the long term, UML 1.4
successfully adheres to the four-layer concept. The authors of 2.0 have taken great pains to expand on the four-
layer approach, and their effort results in an improved implementation of it. I'll step through both UML 1.4 and 2.0
versions after I discuss the significance of the four-layer metamodel architecture.
The Four-Layer Metamodel Architecture
Understanding the four-layer model will be easier if we start with an example using two layers and build up. To do
this, though, I need to use Class diagram notation. If you are unfamiliar with this Class diagram notation, you may
want to read Chapters 5 and 6 first, and then come back here.
Chapter 1 explained that the MOF is a metamodel, a model that defines the concepts used to build models. When
you show the relationship between the metamodel and the model, as in Figure 2-1, you get two layers, the
metamodel and the model. The metamodel layer defines what a Class is. It tells us that a class may contain
attributes and operations and that it may participate in associations. The Class in the metamodel is a metaclass, a
concept that describes what a class is and how to use it. An instance of the Class metaclass is a class that you can
see on a diagram. It contains attributes about a type of object, operations that the type of object can support, and
information about the associations that the type of object participates in. Different instances of the metaclass Class
describe different types of objects. In Figure 2-1, Person and Car are both model-level classes that are instances
of the metaclass Class.
Figure 2-1: A metamodel defining Class and Association instantiated in a model containing two instances of
class and an instance of association (the arrow between Person and Car).
The metamodel also defines an Association and how to represent it; that is, structures and relationships that
describe any association. The Association in the metamodel is a metaclass just like Class. An instance of the
metaclass Association is an association on a class diagram, modeled as the arrow between Person and Car in
Figure 2-1.
In this two-layer example, the metamodel layer defines the symbols-such as classes and associations-that can be
used to create a model. The model layer describes information such as people and cars and their relationships,
using the symbols defined in the metamodel. The model layer is where all UML diagrams drawn by developers
exist. The UML (metamodel) defines the rules that govern how modelers draw the diagrams and define the
elements of the diagram.
Earlier I said that a model element is an instance of a metamodel element. But that seems to conflict with the
common object-oriented terminology that says that an object is an instance of a class. The concept of instantiation
can become confusing in this context. To instantiate a metamodel means to create a model, like creating a Person
class from the Class metaclass. Instantiating a model class means creating an object of that type. In Figure 2-2
the object Mike is an instance of the class Person. Both are model level elements.
Figure 2-2: A metamodel defining a Class and an Instance Specification instantiated by a diagram containing
a class and an object.
But in order to model the object Mike we need a definition for modeling an object. Figure 2-2 illustrates that it is
valid and useful to define a metamodel for instances, in this case a metaclass called InstanceSpecification.
InstanceSpecification defines the needed modeling elements for describing an instance. To instantiate the
InstanceSpecification, model an object like Mike:Person, that is, an instance called Mike of type Person. Note that
Mike: Person is still a model element, not the actual object Mike. That would be yet a third layer.
Using the layering concepts similar to those illustrated in the previous examples, the UML authors set out to
employ a multi-layered architecture like the one shown in Table 2-1.
Table 2-1: The Four-Layer Architecture (OMG 1.4)
Layer Description Example
Meta-
metamodel
(M3)
The infrastructure for a metamodeling
architecture. Defines the language for
specifying metamodels.
MetaClass, MetaAttribute, MetaOperation
Metamodel
(M2)
An instance of a meta-metamodel.
Defines the language for specifying a
model.
Class Property, Operation, Component
Model (M1) An instance of a metamodel. Defines
a language to describe an information
domain.
StockShare, askPrice, sellLimitOrder,
StockQuoteServer
User object
(user data)
(MO)
An instance of a model. Defines the
values of a specific domain.
<Acme_SW_Share_98789>, <654.56,
sell_limit_order, <Stock_Quote_Svr_32123>
Layer M3 (meta-metamodel) is a model that describes the artifacts of and rules for a metamodel. In Table 2-1, the
M3 layer defines the rules for defining a metaclass. This level of abstraction supports the creation of many different
models from the same set of basic concepts. For example, both UML and CWM derive from the same MOF
model. MOF exemplifies M3, and UML exemplifies M2.
Layer M2 (metamodel) is a model that describes the artifacts of and rules for a model. In the context of this book,
it is UML that defines the model for elements like attributes, classes, and instances. (These are just samples. The
actual specification includes many more model elements.) The UML definition of a class extends the core
definition of the Class metaclass found in the M3 layer. The UML definition for an attribute also extends the MOF
Class definition. It is valid, and useful, to allow a class at one level to inherit from multiple classes in the level
above. This encourages a model in which the higher layers are extremely cohesive and loosely coupled to support
the widest range of application.
Layer M1 (model) is the model that describes the artifacts and rules for the problem domain. This is the level at
which we draw Class diagrams, Sequence diagrams, and so forth. Classes and objects, associations, attributes,
and all other elements of the model layer depend on the M2 layer definitions.
Layer MO consists of the runtime elements created by executing the model.
To sum up, layer M0 represents the actual artifacts of the problem domain, consisting of the elements created and
used at runtime. Layer M1 is a model of layer M0, layer M2 is a model of layer M1, and finally, layer M3 is a model
of M2.
NoteThis layered approach to defining concepts leads to the possibility that the same concept (class name)
may appear at multiple levels. Each lower level inherits the concept from the layer above and adds to or
overrides the definition. For example, Classifier appears in both M3 and M2. The definition in M2 adds
new features not defined in M3.
Although this is as far as the UML architecture goes, multilayer architecture may actually have an infinite number
of layers. Successive higher layers come from the process of abstraction, a natural process of refining a set of
rules. It is a bit like mathematics in the sense that as we progress through our education in math, we discover first
the basic concepts like adding and subtracting. Then we learn that there are rules that govern why addition and
subtraction actually work. As we continue our math studies we encounter higher and higher level principles that
govern broader principles that can be applied to many different types of math.
Moving to lower levels of abstraction, the application of the principles can be layered to define rules for converting
a visual model to a programming language model. That language can be mapped to other lower-level languages,
and finally to ones and zeros in computer memory.
This layering approach is at the heart of MDA (Model Driven Architecture). You could think of it as the old divide-
and-conquer approach. As we isolate the different levels of problems to solve and abstract the principles further
away from the implementation, we create the ability to mix and match solutions and principles. We have already
done something similar for years, separating interface from implementation in object-oriented design. A business
problem solved at one layer may be implemented in any number of solution environments while preserving
consistent definitions throughout by mapping each layer to the next.
<Day Day Up>
<Day Day Up>
UML Version 1.4
UML 1.4 was published in September of 2001. UML 1.4 with Action Semantics (also known as UML 1.5) was
published a year later. UML 1.4 was developed alongside MOF and OMG's CORBA technologies. The complete
integration of these three standards would later be realized by UML 2.0. By striving to align MOF, UML, and
CORBA, the authors were trying hard to pave the way for future extensibility. The 1.4 specification includes
Formal definition of a common Object-Oriented Analysis and Design (OOA&D) metamodel semantics
Graphic notation for OOA&D
Model interchange using XMI
Model interchange using CORBA IDL (this feature might be dropped in UML 2.0 due to lack of interest)
Language architecture
UML 1.4 consists of three top-level packages and additional specifications for Action Semantics and the Object
Constraint Language. The three top-level packages each contain a unique set of resources needed to define a
UML model. Figure 2-3 represents the three packages: Behavioral Elements and Model Management packages,
which depend on the Foundation package (in UML, the dashed arrow represents a dependency).
Figure 2-3: Top-level packages of UML 1.4.
OMG 1.4
Cross-Reference Packages are UML's way of organizing information, much like directories. Packages are
fully explained in Chapter 14.
A dependency arrow between packages simply means that the thing at the source of the arrow needs something
that is owned by the thing at the target end of the arrow. For example, the Behavioral Elements package contains
the Instance class that inherits from the Classifier class in the Foundation package. Without access to the
Classifier class, the Instance class would be incomplete. Because Classifier is required by many classes in both
Behavioral Elements and Model Management packages, it makes sense to put it in a common package, namely
the Foundation package.
Foundation package
The Foundation package provides those model elements that are required throughout the metamodel in the
construction of other elements. Figure 2-4 identifies three sub-packages: Core elements, Extension Mechanisms,
and Data Types.
Figure 2-4: UML 1.4 Foundation packages.
OMG 1.4
Nearly all of the diagram elements in UML derive their basic features from the elements defined in these three
packages. So it is important that you be familiar with their basic features. You don't need to memorize the
descriptions that follow, but you will probably want to mark these pages so that you can refresh you memory when
these elements are used later to explain the features of each diagram notation.
The Core package
The Core package provides the bulk of the fundamental constructs of the UML metamodel. It contains some
classes that cannot be instantiated but which define a fundamental set of features. A class that cannot be
instantiated is called abstract. Some abstract classes are ModelElement, GeneralizableElement, and Classifier. I'll
explain these classes in more depth in just a moment. These abstract classes serve as the basis for a number of
other, more specialized classes that can be instantiated.
A class that can be instantiated is called concrete. Core concrete classes include Class, Property, and Association.
Other concrete classes include Instance, Operation, Link, and many more. These are the classes that define the
concepts that appear either as notation on UML diagrams or as description elements for notations on the
diagrams.
Take a brief look at three Core abstract classes:
ModelElement: ModelElement is the most basic definition of a modeling entity. It is the definition from which
all other modeling metaclasses derive. A model element may have constraints, may be derived, has an
associated set of zero or more presentation options, may be stereotyped, and may contain any number of
tagged values. Hence, any other metaclass deriving from ModelElement already possesses all of these same
features.
GeneralizableElement: A GeneralizableElement may be specialized into any number of other elements. For
example, a Classifier may be specialized into Class, Property, and Association. When specialized like this, the
GeneralizableElement contains the features that all the specialized elements have in common. It may also be
a specialization of another GeneralizableElement. This concept makes it possible to construct a hierarchy of
elements in which each element above contains shared or generalized properties, and each element below in
the hierarchy contains only those properties unique to that new type of element.
Classifier: A classifier describes a named element with features. As a subclass of ModelElement, a classifier
may have constraints, may be derived, has an associated set of zero or more presentation options, may be
stereotyped, and may contain any number of tagged values. It describes an element that may be named
uniquely within a namespace like a package.
A classifier is itself a namespace. As such, it can contain other, nested classifiers. A classifier declares a collection
of features, both structural and behavioral, like attributes and operations, respectively. It may be generalizable, that
is, it may inherit from GeneralizableElement. A classifier may own behavioral models such as state machines, and
collaborations that are used to explain the classifier's lifecycle and behaviors.
The classifier metaclass is specialized to define many other metaclasses such as Class, Object, Association, Link,
Use Case, Collaboration, and many more common UML model elements. So in some of the book narrative I refer
to "classifier" instead of the specific sub-metaclass, to make it clear that I am describing a concept that applies to
all classifiers.
The Extension Mechanisms package
The Extension Mechanisms package provides a means to tailor the use and appearance of existing elements for
specific application domains or technologies. Extension mechanisms include stereotypes, constraints, and tagged
values. (A complete description of these mechanisms is provided in Chapter 3.)
The Data Types package
The Data Types package defines a common set of valid data types and enumerations for use in defining the
metamodel. They are the data types used in the diagrams that describe the UML metamodel, not the data types
that are used in UML modeling. The available data types are defined in the following list. You might want to skip
this section for now and refer back to it when you encounter the terms in the chapters that describe the diagrams
that use the data types.
AggregationKind: Defines the end of an association.
none: The association end is not an aggregate.
aggregate: The association end is an aggregate so the object on the other end is part of it. The part must
have the aggregate value of "none."
composite: The association end is a composite so the other end is part of it. The part must have the
aggregate value of "none." The distinction between aggregation and composition is covered fully in
Chapter 6.
ArgListsExpression: In the metamodel an ArgListsExpression defines a statement that evaluates to a set of
object lists.
Boolean: A set of logical alternatives.
true: The condition is satisfied.
false: The condition is not satisfied.
BooleanExpression: A statement that evaluates to a Boolean value.
CallConcurrencyKind: Used to describe how calls may be made to an instance and how they will be
processed when received.
sequential: Calls to the instance must be coordinated so that no more than one call is handled at a time.
Attempts to do otherwise put the integrity of the system at risk.
guarded: Multiple calls are allowed but only one is processed at a time.
concurrent: Multiple calls may occur simultaneously and all may proceed simultaneously.
ChangeableKind: Defines the allowed modifications for an attribute value (via an AttributeLink) or the end of a
link (LinkEnd).
changeable: No restrictions. All modifications are allowed.
frozen: Once values have been initialized, they may not be altered.
addOnly: Once the values have been initialized, new values may be added but values may not be
deleted.
Expression: A statement that evaluates elements of the environment but does not alter the environment.
Evaluation of the statement results in a set of instances. It is valid to get an empty result set. (Compare with
ProcedureExpression.)
name: An identifier for the expression.
language: The name of the language used to write the expression. The predefined languages are Object
Constraint Language (OCL) and the default signified by a blank. A blank language is interpreted to mean
that the language is natural language intended for human use. In other words the expression is written in
free-form text. The language may be any programming language or specification language.
body: The text of the expression.
Geometry: Geometry is defined outside the UML in vendor tools. The attribute is used to hold the values
defined by the vendor to describe the shape of the icon associated with a model element like a class or
decision node.
Integer: integer in the metamodel is a classifier that is an instance of the Primitive class representing the set of
integers.
LocationReference: A means to identify where to make a reference to another element during a behavior
sequence, such as an extension use case.
Mapping: (Identified but not actually defined in UML 1.4.) A text string that describes how elements in one
model map to elements in another model.
MappingExpression: A statement that evaluates to a mapping.
MultiplicityRange: An upper and lower limit on the cardinality that may be assigned to an element. The lower
limit may be zero but not negative. The upper limit must be equal to or greater than the lower limit and may be
infinity.
Name: A token that is assigned to a model element.
OrderingKind: Used in conjunction with elements that may have a multiplicity of greater than one. The values
designate the sequencing requirements for the members of the set.
unordered: The members of the set are maintained in no particular order.
ordered: The members of the set are kept in order as created.
Other options (sorted, for example) may be created using stereotypes.
ParameterDirectionKind: Defines the usage of a parameter on behavioral features such as an operation.
in: The value is for input only and may not be modified.
out: The value is for output and may be modified.
inout: The value is provided as input to the behavior and may be modified as part of the output.
return: The return value of a call.
ProcedureExpression: A statement that can modify the environment when it is evaluated. (Compare with
Expression.)
PseudostateKind: Within a Statechart diagram, states define the condition of an object. Pseudostates define
mechanisms that support navigation through the Statechart diagram.
choice: A decision point from which there may be any number of alternative transitions.
deepHistory: When a transition ends in a deepHistory pseudostate, the state of the object is fully restored
to the state it was in before it last exited. (Contrast with shallowHistory.)
shallowHistory: When a transition ends in a shallowHistory pseudostate, the state of the object is restored
to the state it was in before it last exited, but without resetting any substates that might have applied.
(Contrast with deepHistory.)
fork: Identifies a point where a single transition generates multiple concurrent transitions. (See join.)
join: Identifies a point where multiple concurrent transitions end and become a single transition. (See
fork.)
initial: The default transition when entering a composite state or the starting transition on a Statechart
diagram.
junction: Defines a focal point at which many incoming and outgoing transitions intersect. Only one
combination of one incoming and one outgoing path fire at any one execution.
ScopeKind: Defines the governing boundaries for the definition of an element.
instance: The element is contained within an instance of a classifier, that is, an attribute value is
contained within an object.
classifier. The element is contained within a classifier, that is, an attribute value is contained within a
class, common to all instances of the class.
String: A classifier element that contains text.
TimeExpression: A statement that defines the occurrence of an event. However, UML does not define the
format for the expression. Instead, it defers to the constraints of the implementation environment.
TypeExpression: The encoding of programming language data type, like Java short, long, or float, used with
an instance of ProgrammingLanguageDataType.
UnlimitedInteger: A reference to the symbol used to mean that there is no upper limit to a value-for example,
the asterisk (*) used in multiplicity ranges.
Uninterpreted: In the UML metamodel, an Uninterpreted element is a blob, a domain specific concept that is
not defined within the UML. The designation is interpreted by the domain into which the model is mapped.
VisibilityKind: Defines the allowed access to a model element such as an attribute or operation. The types of
visibility are private, public, package, and protected. The meaning of each visibility is fully explained in Chapter
5.
Behavioral Elements package
The Behavioral Elements package contains the model elements used to represent how the system works in terms
of controlling actions and interactions between elements. As Figure 2-5 shows, behavior is described from a
number of perspectives using different diagrams, namely Collaboration diagram, Use Case diagram, State
Machine, and Activity graph. But all of these diagrams depend on the same set of core-behavior-related concepts
to build their unique description of system behavior. The Use Case diagram models user interactions. The State
Machines model object lifecycles. Activity graphs model logic sequences. Collaboration diagrams model standard
patterns of interactions that appear through the system design. All describe behavior but for a different audience
and to reveal a different aspect of the system's behavior.
Figure 2-5: UML 1.4 Behavioral Elements packages.
OMG 1.4
Collaborations
Collaborations explain how classifiers work together to perform an operation or an interaction between elements.
Collaborations include two key concepts: the structure of the participating elements and the pattern of messages
exchanged between the elements. Collaboration may be modeled at the classifier or instance level. In fact, it may
be modeled at just about any level of abstraction all the way up to systems.
Collaboration is also a common way to model design and analysis level patterns. Patterns define common ways
that model elements may be configured to accomplish a type of work. Work requires interaction, and a
collaboration provides the needed concepts to appropriately represent the pattern requirements.
Collaborations are defined fully in Chapter 7.
Use cases
Use cases represent how clients interact with the system. A Use Case diagram is like an encapsulated view of the
entire system in that the client can only see and interact with the interface provided by the system. The internal
workings, the implementations, are inaccessible to the client except through the published interfaces, the use
cases.
Use cases are defined fully in Chapter 12.
State Machines
State Machines model the transformations that take place within an object over time. The transformations are
responses to stimuli from outside the object. State is described by the values of the properties of an object at a
point in time. Transformations in the values redefine the state of the object. A State Machine reveals that two key
elements are needed to understand and manage the life of the object: the events that trigger the changes, and the
behaviors that accompany the events and actually make the changes.
State Machines are defined fully in Chapter 11.
NoteState Machines are formally implemented in UML 1.4 as Statechart diagrams. In UML 1.4, the State
Machine package is the parent package for both Statecharts and Activity graphs.
Activity graph
An Activity graph is basically the old flowchart. It models logic, any logic, from workflow to the sequence of
behaviors in a single method. The authors of UML 1.4 tried to fit the Activity graph into the State Machine
metamodel as a refinement of a state machine. UML 2.0 has chosen to separate the two to more fully support the
business modeling potential of the Activity graph.
Activity graphs are defined fully in Chapter 13.
Model Management package
Model Management refers to the means to model the organization of modeling artifacts. Artifacts may be
organized along very general lines such as project phases, application incremental builds, subject matter, and
utility versus business models, using packages. Packages may also be specialized to represent more refined
views. For example, artifacts may be organized to represent the partitioning of a system into subsystems at any
number of levels. Finally, the artifacts may represent a physical system such as a billing or receiving system. Views
of the physical system are called models.
Packages, subsystems, and models are fully defined in Chapter 14.
Object Constraint Language
Object Constraint Language (OCL) provides the semantics for declaring static requirements for attributes and
operations. A constraint on an attribute is called an invariant, which is a rule that must never be violated during the
life of the system. For example, a phone number must always have 10 digits (not including country code).
Constraints on an operation define what must be true in order to invoke the operation, called a pre-condition, and
what must be true when the operation is completed, called a post-condition. For example, to place an order you
must provide a valid customer account number. When the order is placed, all items are reserved in inventory and
the order value is posted to the customer account. Together these constraints ensure that an operation is always
used properly and always yields a proper result. Constraints define the static requirements of the system. Contrast
this with the dynamic requirements defined by the Action Semantics discussed next.
Action Semantics
Action Semantics define the rules that govern the dynamic aspects of a system. An action is a class that defines a
behavior. For example, the instance of CreateObjectAction in Figure 2-6 defines how to create an object. An action
also defines the classes that participate in a behavior. In Figure 2-6 the participants include six instances of Action
metaclasses and one of the Class metaclass.
Figure 2-6: UML 1.4 Action example.
OMG 1.4
Here's an explanation of the roles of each element:
The CreateObjectAction object generates an instance, labeled customer, of the Class metaclass. 1.
This new customer object is attached to an OutputPin object that holds the result of the action. 2.
A Dataflow object connects the OutputPin object to an InputPin object so that the "customer" object can be
passed through it to another action.
3.
InputPin provides the customer object as an input value to the next action called WriteVariableAction. 4.
WriteVariableAction assigns the customer object to the variable called newCustomer. 5.
Actions can be used to define method implementations, handling of calls and signals between objects, and all
other behaviors that define the proper operation of a system. Action Semantics combined with Object Constraint
Language provide all of the precision needed to generate a complete platform independent model of a system.
Diagrams of UML 1.4
UML 1.4 defines nine diagrams for describing a system and one for organizing the various artifacts of the
development process. The diagrams may be categorized in a variety of ways. For description purposes I find the
following groupings helpful. There is nothing standard about the groupings but it has helped many of my students
grasp the different types of diagrams and their relationships to one another. Figure 2-7 shows the organization of
the UML diagrams into three categories.
Figure 2-7: Three complementary sets of diagramming tools.
Static (or structural) view
The static view includes those diagrams that model resources used in the construction of the system. Class
diagrams define the resources in terms of their allowed features and relationships. Object diagrams model facts or
examples about resources. The Object diagram may be used either to figure out what the Class diagram should
look like or to verify that the Class diagram is correct.
The Component diagram models the physical pieces of software in a system, including applications, files, user
interfaces, and pretty much anything that can execute on a processor, be stored in memory, or performed by a
person.
The Deployment diagram models the hardware environment, namely processors where components may run. The
UML's loose definition of processor allows for human beings to be processors so that manual processes can be
modeled as well.
Dynamic view
The dynamic view includes diagrams that model the behavior of objects in terms of interactions. The Sequence
diagram and Collaboration diagram use slightly different means to model objects passing messages back and
forth to accomplish a task. The dynamic view is particularly useful for discovering the interface requirements to
support the interactions. The interactions also reveal the data that is passed and that has to be owned and
managed by the objects. Both the interfaces and the data reveal updates to the structure of the objects defined in
the Class diagram.
The Statechart diagram examines the effect of the interaction in terms of the inner workings of a single object. It
tracks the changes in an object's state and the reasons for the changes. The reasons for the changes are often
messages from other objects seen clearly on the interaction diagrams. Here again, the changes to an object's
state reveal changes in data within the object, which can reveal changes for the Class diagram.
Functional view
Functionality drives the requirements for most applications. The users want the system to provide information or
behavior to support the business process or goals. The Use Case diagram specifically models what the users
expect to see when they interact with the system. A use case captures the dialog between a user and the system in
performing a specific task. For example, a user at an ATM requesting a withdrawal will answer a series of
questions in response to prompts from the system. The end result is already defined to be either one of a number
of predefined error messages or money and optionally a receipt.
The Activity diagram (also referred to as an Activity graph) models logic. Since logic appears throughout the
design of a system, the Activity diagram has broad application. Workflow, use cases, collaborations, and
operations all involve logic and may be represented in an Activity diagram.
<Day Day Up>
<Day Day Up>
UML 2.0
UML 1.4 was the culmination of a concerted effort to create a practical tool for modeling systems. The focus was
on "practical." The tool had to be useful for a broad spectrum of projects and easily implemented by users and tool
vendors alike.
UML 2.0 provided the opportunity to go back over the tool and fine-tune the definitions, clean up the architecture,
and generally refine the tool to ensure its long-term success. Also, while UML was gaining acceptance, OMG was
hard at work promoting Model Driven Architecture (MDA). UML is a major component of MDA, so complete
alignment with the other elements of MDA is essential.
UML 2.0 is comprised of two libraries, the Infrastructure and the Superstructure. The Infrastructure defines the
core metamodel used to define the MOF, UML, CWM, and Profiles. Now that probably sounds strange. Didn't I say
earlier that UML derived from the MOF? Well, yes. But one of the requirements for UML 2.0 was to go back and
improve the alignment of MDA components. The Infrastructure is now the top metamodel. The MOF, UML, and
CWM all derive from the Infrastructure. But the UML also still derives from the MOF. Confused? Well, read on and
it should become clearer.
The Superstructure extends and customizes the Infrastructure to define the UML metamodel. The Superstructure
defines the elements that make up the modeling notations of the UML, created by extending and adding to the
basic elements defined in the Infrastructure.
As part of the effort to fine-tune the standard and align it more closely with MDA, the authors established a set of
design principles to guide their work. The principles reflect some of the objectives set forth by the RFP but they
apply beyond specific corrections to the whole approach to the revision process. The design principles include
modularity, layering, and extensibility. These principles were chosen specifically (though not exclusively) because
they yield a language structure that facilitates reuse.
Modularity/Partitioning: To maximize reuse, the modeling elements are isolated into highly cohesive and
loosely coupled packages. The use of small, well-defined units enables a "cookbook" approach to assembling
new model elements at each successive layer of the architecture, taking from separate modules as needed to
build a new concept. For example, the Infrastructure defines the model elements Classifier and Relationship,
among others. The Superstructure combines these two metaclasses and three others from five separate
packages to put together all of the features needed to define an Association.
Layering: Layering refers to two means of separating concerns in the way the models are organized. The first
type is seen in the four-layer architecture explained earlier. The second type is within each layer. The
packages in each layer may also separate model elements to define levels of abstraction within the layer. For
example, within the Infrastructure, the Abstractions package provides the foundation for the concepts defined
in the Constructs package. You might call them layers within layers, providing successive refinements of the
model elements in each new layer.
A layer may use different degrees of modularity or partitioning to coincide with the purpose of the layer. For
instance, the Infrastructure uses very fine-grained partitioning to maximize reuse across diverse
implementations, and the Superstructure uses more coarse-grained partitioning to support the use of the
modeling concepts in context. In the Superstructure, for example, a partition might correspond to a type of
diagram, so the partition contains all of the elements that support the diagram, but those concepts have been
constructed from metaclasses defined in many different Infrastructure partitions.
Extensibility: The specification must support two types of extension. One type uses profiles. Profiles use
adornments to customize UML for use with a specific platform or domain. Second, the Infrastructure may be
specialized to create a new language like UML, as has been done to create the CWM. (Technically CWM
existed before the Infrastructure but it is currently being aligned with the Infrastructure.)
All three of these principles were chosen to support high reuse. Modularity provides small, well-defined, easy-to-
use units. Layering organizes the units for ease of use. Extensibility supports customization of existing model
elements so that new elements do not have to be created to solve new problems.
Links to the UML 2.0 RFPs
The four UML 2.0 RFPs are available at the following locations:
UML Infrastructure:
http://www.omg.org/techprocess/meetings/schedule/UML_2.0_Infrastructure_RFP.html
UML Superstructure:
http://www.omg.org/techprocess/meetings/schedule/UML_2.0_Superstructure_RFP.html
Object Constraint Language:
http://www.omg.org/techprocess/meetings/schedule/UML_2.0_OCL_RFP.html
UML Diagram Interchange:
http://www.omg.org/techprocess/meetings/schedule/UML_2.0_Diagram_Interchange_RFP.html
Many of the issues that came out of the development of UML 1.4 were simply too large to be addressed in UML
1.4 or even small revisions. So in mid-2001, even as UML 1.4 was being released, OMG members started work on
a major upgrade from UML 1.4 to UML 2.0. The OMG sent out separate RFPs for the Infrastructure, the
Superstructure, the Object Constraint Language, and Diagram Interchange.
Infrastructure library
The Infrastructure library contains the Core and Profiles packages. The Core package is the metamodel at the
heart of the MDA architecture. The Profiles package defines UML extension mechanisms for creating a UML
dialect, variations on the basic language that are customized to specific environments or application subject areas.
Core package
The Core package provides the foundation on which to build the MOF, UML, CWM, profiles, and future languages.
The common metamodel makes possible model interchange via XML Model Interchange (XMI). It also makes it
possible to customize UML variations using profiles and to create other languages like UML, but for other domains.
Common Warehouse Model (CWM) is one of another language. The same Infrastructure that supports UML is
used to define a language for specifying data structures for database design. Figure 2-8 models the relationship
between the Core package and the other major components of the MDA. The dependency arrows represent the
fact that each of the four packages, UML, CWM, MOF, and Profiles, need help from the Core package. They each
use information defined in the Core. So they depend on the contents of the Core in order to complete their own
sets of definitions.
Figure 2-8: UML 2.0 Infrastructure defines the core metamodel for the rest of the MDA components.
The Core package contains three other packages: Abstractions, Basic, and Constructs, that all depend on the data
types defined in the PrimitiveTypes package (see Figure 2-9).
Figure 2-9: UML 2.0 Core package.
The Primitive Types package defines a small set of data types that are used to specify the core metamodel. These
are not data types used for modeling application domains. They are used to create the models that express the
core metamodel. The three types are Integer, Boolean, and String. An instance of an Integer is any valid integer
value. An instance of a Boolean is either true or false. An instance of a String is some text.
The Abstractions package defines the common concepts needed to build modeling elements such as classifiers,
behavioral elements, comments, generalizations, and visibilities. Nearly all of these metaclasses are abstract,
meaning that they may not be instantiated. The purpose of the metaclasses is to define the fundamental concepts
common to most modeling languages. The metaclasses are generalizations of concepts used throughout the
language and in many different ways. Defining them in this generalized form makes them available to any package
that chooses to build on the concepts and customize them for use in a specific setting.
The Basic package defines the common characteristics of classifiers, classes, data types, and packages. The
Constructs package refines contents of the Abstractions and Basic packages, merging and refining abstract
concepts to create a set of common modeling elements. The sub-packages under the Constructs package reflect
the progressive refinement from abstract concepts to concrete; they are implementable concepts with package
names like Classes, Attributes, Associations, and Packages. All of these package names reflect notation elements
for diagramming languages rather than abstract concepts.
Now, to clarify my earlier statement about how the MOF uses the concepts defined by the Infrastructure, refer to
Figure 2-10. The MOF defines a set of concepts needed to define the elements of the MDA, for example, models,
primitive data types, and the means to provide identity for elements in a model. These concepts are created by
utilizing and extending the abstract concepts defined within the Infrastructure.
Figure 2-10: The relationship between MOF and the Infrastructure Core package.
Profiles package
The Profiles package contains mechanisms to adapt existing metaclasses to a specific subject or platform. Profiles
are fully explained in Chapter 21, including some profiles that have already been created and standardized.
Superstructure library: The UML package
The Superstructure library, shown in Figure 2-11, is really the UML package, containing all the elements used to
construct the UML diagrams.
Figure 2-11: The SuperstructureLibrary package.
The Superstructure (or UML) defines all the diagramming elements of the UML. Within the specification document,
the elements are organized by the type of diagram that they support. The three categories are structure, behavior,
and supplemental.
The Structure section defines Class, Object, Composite Structure, Component, Deployment, and Package
diagrams that model various elements and the relationships between them.
The Behavioral section defines Sequence, Interaction Overview, Timing, Communication, and State Machine
diagrams, as well as Action Semantics.
The Supplemental section defines auxiliary concepts like information flows and class templates, and profiles
as defined within the UML (versus profiles as defined in a more general way by the Infrastructure).
Diagrams of UML 2.0
UML 2.0 kept most of the diagrams of UML 1.4 and added some of its own. Table 2-2 lists the old and the new with
a few notes to identify the differences.
Table 2-2: Comparison of UML 1.4 and 2.0 Diagrams
UML 1.4 UML 2.0 Changes
Class diagram Class diagram

Object diagram Object diagram The Object diagram is drawn in the Class diagram
canvas, not in its own diagram space. (See Composite
Structure diagram.)
Composite Object
diagram

(See the UML 2.0 Composite Structure diagram.)

UML 1.4 UML 2.0 Changes
diagram
Packages Package diagram UML 1.4 didn't technically refer to a Package diagram
even though it was used throughout the specification to
illustrate the organization of the spec. Note: the Package
diagram is drawn in the Class diagram canvas, not in its
own diagram space.
Component
diagram
Component diagram

Deployment
diagram
Deployment diagram

Combined
Deployment and
Component
diagram
Combined
Deployment and
Component diagram

Use Case diagram Use Case diagram

Statechart diagram State Machine

diagram
Technically these are the same, just with different names.

Protocol State
Machine diagram
This is a State Machine at a higher level of abstraction.
Activity graph Activity diagram The Activity diagram has been substantially refined and
improved with its own metamodel, independent of the
state machine.

Composite Structure
diagram
This is kind of a combination of an Object diagram and a
Composite Object diagram.

Interaction diagrams This is a group title that includes the Communication,

Interaction Overview, Timing, and Sequence diagrams.
Collaboration
diagram

The functionality was redistributed among the new

Interaction diagrams.
Sequence diagram Sequence diagram (See Interaction diagrams.)

Communication
diagram
(See Interaction diagrams.)

Interaction Overview
diagram
(See Interaction diagrams.)

Timing diagram (See Interaction diagrams.)

<Day Day Up>
diagram
Packages Package diagram UML 1.4 didn't technically refer to a Package diagram
even though it was used throughout the specification to
illustrate the organization of the spec. Note: the Package
diagram is drawn in the Class diagram canvas, not in its
own diagram space.
Component
diagram
Component diagram

Deployment
diagram
Deployment diagram

Combined
Deployment and
Component
diagram
Combined
Deployment and
Component diagram

Use Case diagram Use Case diagram

Statechart diagram State Machine

diagram
Technically these are the same, just with different names.

Protocol State
Machine diagram
This is a State Machine at a higher level of abstraction.
Activity graph Activity diagram The Activity diagram has been substantially refined and
improved with its own metamodel, independent of the
state machine.

Composite Structure
diagram
This is kind of a combination of an Object diagram and a
Composite Object diagram.

Interaction diagrams This is a group title that includes the Communication,

Interaction Overview, Timing, and Sequence diagrams.
Collaboration
diagram

The functionality was redistributed among the new

Interaction diagrams.
Sequence diagram Sequence diagram (See Interaction diagrams.)

Communication
diagram
(See Interaction diagrams.)

Interaction Overview
diagram
(See Interaction diagrams.)

Timing diagram (See Interaction diagrams.)

<Day Day Up>
<Day Day Up>
Summary
The UML authors of both 1.4 and 2.0 endeavored to uphold the four-layer metamodel architecture, an approach
that supports the distribution of concepts across many levels of abstraction. The layering supports the
specialization of concepts for different purposes such as object modeling (UML) and data modeling (CWM),
customization for different domains, and ultimately for different implementations.
In the UML 1.4 architecture:
The MOF provides the foundation for the UML.
The UML defines a Foundation package as well as the Behavioral and Model Management features.
Together these packages define all of the essential features needed to create the modeling elements
used to build UML diagrams.
In the UML 2.0 architecture: The new architecture defines an Infrastructure and a Superstructure.
The Infrastructure redefines the highest level of the architecture used to create the MOF and all other
MDA components.
The Superstructure is the UML portion of the architecture. The Superstructure derives all of its
components from both the Infrastructure and the MOF.
The superstructure is organized according to the three types of diagrams defined by UML, that is
structural (Class, Object, and so on), behavioral (Sequence, Timing, State Machine, and the like), and
supplemental (information flows, profiles, and templates).
A summary of the diagram changes between 1.4 and 2.0 includes:
UML 2.0 replaced the Collaboration diagram with a more limited Communication diagram.
UML 2.0 added two new interaction diagrams: the Interaction Overview diagram and the Timing diagram.
UML 2.0 added the Protocol State Machine.
UML 2.0 added the Composite Structure diagram.
UML 2.0 isolated the Activity diagram with its own semantics separate from the State Machine.
<Day Day Up>
<Day Day Up>
Chapter 3: UML Diagrams and Extension Mechanisms
Overview
UML was designed to be the distillation of best practices in software development. To accomplish this ambitious
goal, UML provides an extensive set of diagramming tools. Because UML is such a big subject and the
diagramming tools are so diverse I thought it would be helpful to give you an overview of the diagrams themselves.
This chapter presents some samples of each diagram with a brief introduction describing the purpose and benefits
of each diagram.
As a kind of roadmap I'll use the UML groupings that divide the diagrams into packages based on their roles in the
Model Management, Structural, and Behavioral aspects of system design.
Model Management diagrams include Packages, which are used to represent Subsystems, Models, and more.
Structural diagrams include the Class diagram, Object diagram, Composite Structure diagram, Component
diagram, Deployment diagram, and the Combined Component and Deployment diagram.
Behavioral diagrams include the Use Case diagram, Activity diagram, Interaction diagrams (two diagrams in UML
1.4; four diagrams in UML 2.0), State Machine diagram, and Protocol State Machine diagram.
<Day Day Up>
<Day Day Up>
UML Diagrams and Work Products
Each diagram reveals a unique yet overlapping view of a system. That sounds a bit strange. How can a diagram
be unique yet overlap other diagrams? The uniqueness comes from the different perspective taken by each
diagram. The overlap comes from the fact that all of the diagrams are looking at the same problem.
The big question that usually crops up about now is, "Why do I have to use all these diagrams? Joe and Susan
have always just drawn Class diagrams." This question is valid. For small, simple projects you may not need to
create all these diagrams. But I suspect that one reason you're reading this book is that you don't work on small
projects, and the projects you do work on get pretty complicated.
When the projects become large and complicated, you often move from one piece of the project to another in
rapid succession. Coming back to something you worked on a few days ago often means hours of getting your
head back into a pile of notes and/or mountains of code, much of it not your own. It also means that there is no
realistic way to know how right you are until you build enough code to run tests. By then you have used up a large
part of the project schedule, and if you find problems it is difficult to justify the extra time to do a lot of rewriting. If
only we got paid by the hour.
So how does a diverse set of diagrams help? Consider a common example from everyday life. Suppose you're in
a car accident at an intersection. Someone runs a red light and broadsides your car. A police officer shows up,
walks over to a witness, and takes her story. She says that you ran the red light, not the other person. Then the
officer leaves assuming he has the truth. How do you feel? Outraged, I imagine. But the officer talked to a "client"
and captured the facts just like we typically gather requirements from our clients. So what's the problem?
The problem is that the officer did nothing to verify his facts. He should have asked the other witnesses for their
perspectives. After he got information from a variety of sources he would have a set of accounts looking at the
same set of facts but from different perspectives. If he compared the stories, he would discover two things. First,
some of the information from different testimonies will agree. He could reasonably assume that those portions of
the accounts are true. Second, the portions that didn't line up could not be trusted until he could find corroborating
evidence.
Dealing with many different views of a software or business problem works the same. Each diagram describes the
problem in a different way, just like different witnesses describe an incident. The diagrams will overlap because
they describe the same body of facts. If they agree where they overlap, you can relax knowing you've probably got
it right. If they don't agree, then you have some homework to do to reconcile the differences. Now here are the two
really-great benefits:
When the viewpoints disagree, you've pinpointed where you need to invest your effort.
When all the viewpoints agree, you know you're done.
How many times have you sat in a status meeting trying to come up with a way to describe how much progress
you've made and what remains to be done? Often we get stuck "guesstimating" a percentage of completion. The
question is, "a percentage of what?"
Instead, wouldn't it be nice to be able to say something like, "We have 28 business requirements so far. Seventeen
have been completely reviewed and approved with clients. The clients tell us that we've identified all of the critical
business requirements but there are maybe five more low-priority requirements that we need to document. Of the
17, we have fully modeled 12. Based on the time we have invested so far, we estimate another week to finish the
remaining five, and three weeks to finish the other eleven."
Even better, the more practice you get and the more metrics you keep on each modeling effort, the more reliable
your estimates become.
As a point of reference, Figure 3-1 shows a modeling tool used to draw UML diagrams. Most modeling tools
provide a similar set of features.
Figure 3-1: A screen shot of a typical modeling tool with menu, navigation area, thumbnail view, canvas, and
diagram-specific toolbar.
The top row of menu options provides the project-level features such as editing, setting preferences, help, layout,
and tools, including code generation and reverse engineering. The section on the top left is a navigation area that
displays all of the diagrams and model elements you've created. Below it is a viewing area with a thumbnail version
of the diagram currently being worked on. The large canvas area on the right side is the drawing area. Between
the navigation area on the left and the drawing canvas is a drawing toolbar that is customized for the type of
diagram displayed on the canvas.
As I describe the diagrams, I will make reference to where they are drawn, because the drawing canvas and
drawing toolbar are different for different diagrams. The rest of this chapter provides examples of all of the UML
diagrams, their purposes, and their benefits. This should give you a solid introduction to the role that each diagram
plays in the overall system design.
<Day Day Up>
<Day Day Up>
Model Management Diagrams
Packages have been used through the lifetime of UML as a means to organize artifacts of the development
process. A package is the UML equivalent of a directory or folder. It is a place to store diagrams. In UML 1.4 and
earlier, the packages were not defined specifically as a diagram, but they were and are used consistently
throughout the UML (and MDA) to represent visually the organization of modeling concepts. In UML 2.0, packages
are officially part of a Package diagram. This change doesn't alter Package functionality. It just brings a little clarity
to the rules for how to model packages.
To support model management, Package diagrams are customized to illustrate different aspects of systems. For
example, a package diagram can model the structure of systems and subsystems. An Accounting System
package, for instance, might contain packages for the Accounts Receivable subsystem, the Accounts Payable
subsystem, the General Ledger subsystem, and so on. A Package diagram can also represent the organization of
the various types of models used to describe a system. A Package diagram used in this way might contain a set of
packages that describes a billing system including the Use Case model, the Analysis model (Class diagrams), and
the Deployment model. In a similar manner, an Analysis model package could contain packages that represent
just the analysis-level models for a set of subsystems.
A package is represented in a Package or Class diagram as a folder icon, as shown in Figure 3-2.
Figure 3-2: Package icon.
When packages are combined in a diagram, it is expressly to model the relationships between the packages. The
specific type of relationship is called a dependency. A dependency simply states that one element needs help from
another element. The help may be in the form of functionality or data provided by the other element. Between
packages, a dependency states that something inside of one package needs help from something inside the other
package. The dashed arrows in Figure 3-3 model the packages for the theater system. Notice, for example, the
dependency between the two packages at the top of the diagram, VenueManagement and Scheduling. This
dependency states that something inside the Scheduling package needs help from something inside the
VenueManagement package.
Figure 3-3: Package dependency.
Package diagrams are valuable because they
Identify the data and functional dependencies between parts of a system.
Identify the partitioning of a system into subsystems.
Identify phases in a project.
Separate utilities from system-specific components.
Isolate layers of an architecture.
Packages are your tool for organizing all of the work products of the modeling process. In a modeling tool, the
Package diagram is typically accessed within the Class diagram facility/canvas. For a complete explanation of the
Package diagram and its many additional features, see Chapter 14.
<Day Day Up>
<Day Day Up>
Structural Diagrams
Structural diagrams illustrate the static features of a model. Static features include classes and association,
objects and links, and collaborations. These static features provide the framework in which the dynamic elements
of the model execute. For example, a Class defines the behaviors that types of objects can provide. An association
defines the type of relationship that objects can participate in. A Deployment diagram models pieces of hardware
(and people) that can perform work. Components define pieces of software and procedures that need to be
deployed to processors.
The structural diagrams function much like a blueprint for building a house or a piece of equipment. They show the
parts and how they can be assembled, but they cannot show how the finished product will behave.
Class diagram
The Class diagram is at the heart of the object modeling process. It models the definitions of resources essential
to the proper operation of the system. All of the other modeling diagrams discover information about these
resources (such as attribute values, state, and constraints on behavior) that ultimately must make its way onto the
Class diagram. The Class diagram is the source for code generation (converting a model to code) and the target
for reverse engineering (converting code to a model).
The Class diagram models the resources used to build and operate the system. Resources represent people,
materials, information, and behaviors. Class diagrams model each resource in terms of its structure, relationships,
and behaviors. The notation is surprisingly simple. Figure 3-4 models a class with the three predefined
compartments found in nearly every class: name, attribute, and operations. The notation used in this figure is fully
explained in Chapter 5.
Figure 3-4: A class with the three predefined compartments.
But I said that the Class diagram models resources and relationships between resources. Figure 3-5 models two
classes and the relationship between them. In the theater system a venue manager authorizes agents to sell
tickets. Over time an agent may be authorized by any number of different venue managers. The model defines
how many objects may participate in the relationship and may even set rules defining which objects can
participate.
Figure 3-5: A Class diagram with a relationship called "authorizes."
You will likely have a number of Class diagrams on a project. Each will focus on the resources for a specific
subject area. This is one example of where Package diagrams come into play. A Class diagram for the resources
required to manage a venue can be placed in one package. A Class diagram for the resources to manage agents
can be in another package. Because all the diagram elements for a project are stored in the same repository,
regardless of package, you can reference any of these resources on any diagram merely by using the proper
naming convention (explained in Chapter 5) or using the import concept (discussed in Chapter 14).
Class diagrams are valuable because they
Define the essential resources of a system.
Define relationships between resources.
Generate code.
Model code (reverse engineering).
Provide a focus for all the other diagrams.
The Class diagram includes a number of other modeling constructs to cover the range of resources and design
mechanisms common to systems. Interfaces, template classes, association, aggregation, composition, realization,
generalization, specialization, and dependency are among the concepts you will learn in Chapters 5 and 6.
Object diagram
While the Class diagram models the definitions of resources, the Object diagram models facts or examples. Figure
3-5 shows a Class diagram that defines venue managers, agents, and their relationship. Figure 3-6 presents an
Object diagram that models one specific agent, Mike, and two specific venue managers, Susan and Bill, and the
relationships between the three people. In most modeling tools you draw an Object diagram in the same
facility/canvas as the Class diagram.
Figure 3-6: Object diagram.
An Object diagram is most useful in the early phases of a project for modeling examples. Examples often can
uncover the rules that need to be part of the definitions of the resources and their relationships. Later in the project
the Object diagram is useful for modeling test cases to see whether the Class diagram is correct and complete.
Object diagrams are valuable because they
Support the investigation of requirements by modeling examples from the problem domain (that may later be
used as test cases).
Model test cases to validate the Class diagram.
The Object diagram is explained in Chapter 7.
Composite Structure diagram
The Composite Structure diagram is new in UML 2.0. It represents the functionality formerly described using
Composite Context diagrams and collaborations (not the same as Collaboration diagrams). The concept of the
Composite Structure diagram is to visually represent the parts of a class, component, or collaboration, including
the interaction points (called ports) used to access features of the structure.
Figure 3-7 models a simple Composite Structure diagram of a pricing strategy from the theater system. A pricing
strategy is built using a discount and a set of price tiers.
Figure 3-7: Composite Structure diagram of a pricing strategy.
The Composite Structure diagrams also model collaborations. A collaboration describes a behavior, the resources
used to perform the behavior, and the roles the participating resources assume during the behavior. Figure 3-8
models a collaboration in which a venue manager secures the services of an agent.
Figure 3-8: A Composite Structure diagram representing a collaboration.
Composite Structure diagrams are valuable because they
Reveal the design of a complex component.
Reveal the interface to a component separate from its structure.
Describe the roles that elements play in the structure to fulfill the purpose of the structure and to satisfy the
required interactions.
The Composite Structure diagram is described in Chapter 7, in the section titled "Modeling the Composite
Structure Diagram."
Component diagram
The Component diagram represents pieces of software in the implementation environment. Where the Class and
Package diagrams model the logical design of the software, the Component diagram models the implementation
view. For example, an Order class could be generated as an EJB component. An OrderEntry class could be
generated as an HTML page. Figure 3-9 uses the component notation of UML 1.4 to represent browsers,
JavaBeans, JSPs, and HTML. You can also use components to represent source code, XML, ASP, or virtually any
piece of software.
Note that the Component diagram uses dependencies in the same manner that the Package diagram uses them.
The successful operation of one component depends on its ability to communicate with the other component.
UML 2.0 changed the notation slightly. Figure 3-10 shows the same diagram from Figure 3-9 using UML 2.0
notation. Note the change in the icon. The component symbol is now placed in the top right corner of the
rectangle.
Figure 3-9: UML 1.4 Component diagram using components and dependencies.
Figure 3-10: UML 2.0 Component diagram using components and dependencies.
Component diagrams are valuable because they
Model the real software in the implementation environment.
They reveal software configuration issues through the dependency relationships.
They can provide an accurate picture of existing systems prior to making changes or enhancements.
They can reveal bottlenecks in an implementation without forcing you to read all of the code.
The Component diagram is fully described in Chapter 15.
Deployment diagram
The Deployment diagram models the hardware of the implementation environment. Each node on a Deployment
diagram typically represents one type of hardware, such as a disk drive, a client PC, a server, or a processor. A
node may also represent a human being or organizational unit, or more precisely, the function that a person can
perform. Nodes are like classes in that respect. They represent a type of device, not a specific device, and the
features of each device. Like classes they are related using associations that explain how the nodes may be
connected. Figure 3-11 models a Deployment diagram with four nodes: a database server, a middleware server,
and two types of client devices.
Figure 3-11: Deployment diagram with four nodes and their connections.
Class diagrams are valuable because they
Model the hardware platform for a system.
Identify hardware capabilities that affect performance planning and software configuration.
The Deployment diagram is discussed in Chapter 16.
Combined Component/Deployment diagram
By far the most common application of the Component and Deployment diagrams is to use them in a combined
view that shows components installed on nodes. This view provides insights about the mapping of the
communication requirements of the software to the physical properties of the nodes and connections of the
implementation platform. Figure 3-12 shows the two diagrams combined into one, revealing components installed
on each node and the dependencies that cross the hardware boundaries.
Figure 3-12: Combined Component and Deployment diagram.
Combined Deployment and Component diagrams are valuable because they
Provide a view of the performance issues of an implementation, that is, software running on devices,
communication requirements across physical connections, and software migration across nodes.
Provide a visual check on the complexity of an implementation that aids partitioning and reconfiguration.
The Combined Component/Deployment diagram is described in Chapter 17.
<Day Day Up>
<Day Day Up>
Behavioral Diagrams
Behavioral diagrams describe how the resources modeled in the Structural diagrams interact and how they each
execute their capabilities. The behavioral diagram puts the resources in motion, in contrast to the structural view,
which provides a static definition of the resources.
Use Case diagram
The Use Case diagram models the users' expectation for using the system. The people and systems that interact
with the target system are called actors. The features of the system that the actors use are called use cases.
Some use cases interact with other use cases, a relationship modeled using dependency arrows.
The goal of the Use Case diagram is to identify all the features that the clients expect the system to support, but it
does not reveal any details about the implementation of these features. Use cases can be written many different
ways but the most common is to represent a view of the system from outside the system. For example, when a
customer approaches the sales portion of the theater systems, he might expect to see features that let him place
an order by selecting a performance, selecting seats at the performance, and paying for the order. Figure 3-13
models the customer's view of the system features.
Figure 3-13: Use Case diagram showing the customer's expectations for using the sales system.
Use Case diagrams are valuable because they
Identify the clients' expectations for the system.
Identify specific features of the system.
Identify shared behavior among system features.
Provide a simple and easily understood way for clients to view their requirements.
The Use Case diagram is described in Chapter 12.
Activity diagram
The Activity diagram models logic-any logic-from workflow to use cases to methods. It borrows most of its notation
from flowcharts, but has added the concept of concurrency to support many modern applications. Figure 3-14
models the use case "Select Performance" from Figure 3-13. The arrows trace the flow from beginning to end
through decisions and loops, while identifying each logic step in the process.
Figure 3-14: Activity diagram for selecting a theater performance.
Activity diagrams are valuable because they
Represent the logic required to implement system behaviors.
Represent logic at any level the design needs, from system workflow to individual method implementations.
Are simple enough to learn quickly.
Are relatively familiar to users since they are often used in business training and procedures manuals.
The Activity diagram is described in Chapter 13, "How to Model the Behavior of a System or Object Using an
Activity Diagram."
Interaction diagrams
Through UML 1.4, the phrase interaction diagrams referred to Sequence and Collaboration diagrams. These two
diagrams described the communication between objects to accomplish some task such as placing an order or
finalizing a contract. In UML 2.0, the phrase interaction diagrams includes the Sequence, Communication,
Interaction Overview, and Timing diagrams. The Collaboration diagram has been replaced by the Communication
diagram, a slightly simpler version of the same diagram.
The goal is still the same, though. Each of these diagrams represents some aspect of the communication between
objects to perform a task, and each diagram provides a unique perspective.
Sequence diagram
The Sequence diagram originated with James Rumbaugh and the Object Modeling Technique (OMT). The focus
of the diagram is on identifying interactions between objects over time. The major benefit of the diagram is that it
helps identify the messages exchanged between objects. Exchanging messages requires a sender and receiver. A
receiver must have an interface in order to receive a message. Hence, if a message must be sent from one object
to another, the receiver must define an interface that conforms to the message. An interface is an operation
signature on the class to which the receiving object belongs. The Sequence diagram helps us find and document
new operations on-the Class diagram.
Figure 3-15 models three objects: a customer actor, a theater system, and a venue, and three messages. The
theater system asks the venue for a set of events taking place in a specified date range. The venue returns the set
of events. The theater system then sends the events to the customer actor (user interface) to be displayed. The
types of arrows describe the type of interaction. The messages become operation signatures. The returns help
validate the interaction.
Figure 3-15: Sequence diagram of a portion of the "Select a Performance" use case.
Another benefit of the Sequence diagram is that it has a very narrow scope, typically, one scenario for one use
case. A scenario describes one possible sequence of interactions when a use case executes. For example, when
you attempt to pay for your order at the theater, your credit card is approved and you get your tickets, or your card
is rejected and you don't get your tickets. These are two scenarios; each scenario is represented by one Sequence
diagram.
Sequence diagrams are valuable because they
Have a narrow focus that helps you see the specific questions, commands, and data being communicated
during the execution of a specific task. It is not very easy to gloss over the details when the express design of
the diagram reveals those details.
Explicitly identify the communication required to fulfill an interaction. This helps validate or discover the
interfaces required by a class.
Explicitly identify the objects that participate in an interaction. This helps validate or even discover the features
of a class.
Explicitly identify the data that are passed as part of the interactions. The data have to belong to a class
somewhere in the design. Tracking down the source of the data often reveals new interactions.
The UML 1.4 version of the Sequence diagram is described fully in Chapter 8. The UML 2.0 version is discussed in
Chapter 9.
Collaboration diagram (UML 1.4 and previous versions)
The Collaboration diagram is almost exactly the same as the Sequence diagram. The difference is the
perspective. Both diagrams model interactions between objects for a specific task, but while the Sequence
diagram emphasizes the sequencing of interactions over time, the Collaboration diagram models how the
interactions utilize the structure of the participating objects and their relationships.
Figure 3-16 presents the Collaboration diagram of the sequence of messages shown in the Sequence diagram
segment in Figure 3-15.
Figure 3-16: A Collaboration diagram version of the "Select a Performance" sequence from Figure 3-15.
Collaboration diagrams are valuable because they
Reveal the structural requirements for completing a task. They explicitly identify the objects that participate in
an interaction. This helps validate or even discover the features of a class.
Reveal the interface requirements of the participating classes.
Identify the structural changes required to satisfy an interaction.
Explicitly identify the data that is passed as part of the interactions. The data have to belong to a class
somewhere in the design. Tracking down the source of the data often reveals new interactions.
The Collaboration diagram is explained in Chapter 8. See also the following section. "Communication diagram."
Communication diagram
The Communication diagram is the UML 2.0 version of the Collaboration diagram. The focus is still on
communication as it relates to the structure of the objects involved in a task. One very significant improvement over
the older Collaboration diagram is the ability to nest interactions. This saves a good deal of time because it enables
reuse of behavior in much the same way that other diagrams reuse objects and collaborations. Figure 3-17
models a collaboration that references an existing collaboration called "get performances."
Figure 3-17: A Communication diagram modeling an interaction that includes another interaction, the sd
(Collaboration diagram) "get performances."
Communication diagrams are valuable because they
Reveal the structural requirements for completing a task. They explicitly identify the objects that participate in
an interaction. This helps validate or even discover the features of a class.
Reveal the interface requirements of the participating classes.
Identify the structural changes required to satisfy an interaction.
Explicitly identify the data that is passed as part of the interactions. The data have to belong to a class
somewhere in the design. Tracking down the source of the data often reveals new interactions.
The Communication diagram is fully described in Chapter 9.
Interaction Overview diagram
The Interaction Overview diagram uses the layout of an Activity diagram to model the flow of logic in a series of
interactions. In other words, instead of modeling a series of discrete behaviors (activities), the Interaction Overview
uses blocks of interactions called Interaction Occurrences, and individual interactions (expressed in the form of a
Sequence diagram). Figure 3-18 models the set of interactions needed to set up the initial display for the theater
system sales application. It steps through the logic of displaying the default list of events, then facing the user with
the choice to use the default set of performances or enter a date range to find the desired performances.
Figure 3-18: An Interaction Overview diagram modeling the logical progression through a series of
interactions.
The interactions for displaying events, displaying performance, and so forth are defined elsewhere and referenced
here. Using this technique facilitates reuse of individual interactions across different applications.
Interaction Overview diagrams are valuable because they
Provide a high-level view of the logical progression through a set of interactions.
Keep the focus on the "big picture" and away from implementation details until the bigger issues are resolved.
Support working on an interaction independent of where it might be used.
Encourage the reuse of interactions as easily as classes and interfaces are.
Provide a good check after implementation to make certain that the individual low-level design decisions did
not corrupt the original goal or logic of a process.
The Interaction Overview diagram is fully described in Chapter 9.
Timing diagram
The Timing diagram provides a view of state change that emphasizes the importance of time and timing. The
diagram layout is a grid with time and states as the axes. Figure 3-19 provides a sample Timing diagram. Each
event in it is matched to a point in time - there is even a timing constraint, {20 ms +/- 2 ms}, on the duration of one
state. Everything is about time in a Timing diagram.
Figure 3-19: A sample Timing diagram, showing the different states of a heartbeat over time. OMG 2.0
Time is a critical element of many designs for embedded applications. Timing diagrams are valuable because they
Clearly document the timing requirements that govern state change.
Provide a great complement to the State Machine diagram (discussed in the following section) when the timing
of events is a critical requirement of the successful operation of the system.
The Timing diagram is described in Chapter 9.
State Machine diagram
The State Machine diagram represents a single object. The diagram shows how external stimuli cause changes in
the object over its lifetime. Figure 3-20 shows a partial State Machine diagram that models how a seat at a show (a
"ShowSeat") in the theater system changes each time someone attempts to make a change to it. Each attempt,
called an event, can change the seat's condition, called a state. The select event caused the seat to change from
a state in which it is "Not Priced, Not Selected, and Not Sold" to a state in which it is "Not Priced, Selected, Not
Sold". The select event is not recognized in this new state so it has no effect. The diagram illustrates this by
showing that there is no arrow with the select event leaving this state. The price() event is recognized (an outgoing
arrow labeled price ()) and causes the object to change to yet a third state.
Figure 3-20: Partial State Machine diagram for a seat at a performance.
State Machine diagrams are valuable because they
Identify the specific responses of an object to everything that can happen to the object.
Identify what events an object will and will not respond to depending on its current state.
Discover or validate the data needed to define the state of the object and the attributes affected by the change.
Help discover the internal effects of behaviors that cannot be seen using interaction-based diagrams.
The State Machine diagram includes a number of other notations that explain the behavior of the object as it
transitions from state to state, and while it is in a specified state. The State Machine diagram is described fully in
Chapters 10 and 11.
Protocol State Machine diagram
A Protocol State Machine diagram is like a more narrowly defined State Machine diagram, in that it limits the scope
of the diagram to show only the transitions that trigger the state changes. The Protocol State Machine focuses on
conditions that govern the transitions (called pre- and post-conditions), and state invariants, which define
conditions that must be true whenever the object is in that state.
Figure 3-21 shows an example of a Protocol State Machine diagram. Notice that the notation for State Machines
and Protocol State Machines is very similar. The difference in the purposes of the two diagrams drives the
differences in the notations. The State Machine diagram simply documents that an event causes a change. The
Protocol State Machine documents when such an event is permitted to cause a change and what must be true
when the change finishes. The State Machine defines what is possible. The Protocol State Machine defines what is
legal.
Figure 3-21: Protocol State Machine for a seat at the theater.
Protocol State Machine diagrams are valuable because they
Place the focus on what it takes to legally change an object.
Reveal conditions that ensure the integrity of the object while it is being manipulated by other objects in the
system.
Keep the designer from drilling down to the implementation details before resolving the integrity issues.
The Protocol State Machine is explained fully in Chapter 11.
<Day Day Up>
<Day Day Up>
Extensibility mechanisms
UML formally uses the expression extensibility mechanisms to refer to stereotypes, tagged values, and constraints.
These three constructs provide the ability to customize UML diagrams for a specific subject and/or platform. These
constructs appear as adornments to standard UML notation. Work is also being done for subsequent UML
versions to provide extensibility through the use of metaclasses, an approach that can handle the bigger
challenges of frameworks and distributed business components.
Stereotypes, tagged values, and constraints will appear on nearly every diagram type described in this book.
Stereotypes identify a set of qualities that may appear on a number of diagram elements. Tagged values allow you
to add new features to an element of the diagram. Constraints define rules to protect the integrity of a diagram
element. All three mechanisms are defined here and applied throughout the diagram descriptions.
Stereotypes
The UML 2.0 specification defines stereotype as
A new type of modeling element that extends the semantics of the metamodel. Stereotypes must be based
on certain existing types or classes in the metamodel. Stereotypes may extend the semantics, but not the
structure of pre-existing types and classes. Certain stereotypes are predefined in the UML, others may be
user defined. Stereotypes are one of three extensibility mechanisms in UML. (UML 2.0)
A stereotype is a common concept used in ordinary conversation. For example, on entering a meeting, I might
point out to a colleague that the three people on the right side of the room are accounting folk, the four to our left
are sales, and so on. My colleague understands that these labels identify a set of qualities like skill sets,
knowledge about the project, and so forth. The labels do not explain or define their specific jobs. One of the
accounting people might be a CPA, another a bookkeeper, and the other a manager.
In the same manner, within a software design, I might designate some classes as user interface classes, others as
controllers, and still others as utilities. The interface classes might be as diverse as buttons, frames, drop-down
lists, or graphics. But all these classes are still tools for building a user interface.
Stereotype notation encloses the label in guillemets (French quotes) as in user interface or controller. The
stereotype is then added to the description of the model elements, the icons containing the name, and other
features. Figure 3-22 provides three examples of the application of stereotypes. The first is a stereotype on a
dependency between two use cases, the second is a stereotype on a class, and the third is a stereotype on the
dependency between two packages.
Figure 3-22: Three examples of the application of stereotypes.
A number of stereotypes have already been defined within UML. They are called Standard Elements because they
are provided as part of the UML standard. Appendix C provides a complete list of the UML 2.0 standard elements.
While these existing stereotypes are useful, they do not prevent you from creating your own. By definition a
stereotype is a means to extend UML, to add new concepts that augment and customize its standard modeling
elements. The goal of providing this mechanism is to allow users to tailor their use of UML without having to create
new model elements or even a new language that fits their particular domain or platform.
In my earlier description of a stereotype, I said that a stereotype brings with it some information about the entities
that share the stereotype. For example, the accounting folks bring specific knowledge to the project about how the
accounting processes and policies work. This stereotype-related information is attached to a stereotype using
tagged values, the next topic in the description of extension mechanisms.
Tagged Values
The UML 2.0 specification defines tagged value as
The explicit definition of a property as a name-value pair. In a tagged value, the name is referred to as the
tag. Certain tags are predefined in the UML; others may be user defined. Tagged values are one of three
extensibility mechanisms in UML. (UML 2.0)
In UML 1.4, tagged values first appear as features of a stereotype-a tagged value is paired with a tag definition, a
label that describes the type of value that may be assigned to the tag. The tag definition was a bit redundant
because the TaggedValue metaclass inherits from the ModelElement metaclass, which already has a name
attribute. So in 2.0, tag definition is dropped but tagged values are retained.
The purpose of a tagged value is to assign a feature to a model element in addition to those features already
defined in the metamodel. This enables you to tailor or enhance the description of a model element while still
adhering to the UML metamodel. Tagged values must not alter or contradict the existing definition of a metaclass.
They may only add to it.
You may add tagged values to any model element. Some common places to use tagged values include the name
compartment of a class, and attribute descriptions. Some tagged values are even predefined, such as the
persistence tagged value on a class that identifies whether the class is stored or transient.
Tagged values are expressed in the form name=value, for example author="Tom", project_phase=2, or
last_update="1-07-02". In some diagram locations they are also enclosed within curly braces, {author="Tom",
last_update="1-07-02"}.
Constraints
The UML 2.0 specification defines constraint as
A semantic condition or restriction. Certain constraints are predefined in the UML, others may be user
defined. Constraints are one of three extensibility mechanisms in UML. (UML 2.0)
Like stereotypes, constraints appear throughout UML diagrams. Constraints define the invariants that preserve the
integrity of the system.
A constraint defines a condition that must hold true for the duration of the context in which it is defined. A constraint
on an attribute value for an object holds true for the life of the object. A constraint on an object state holds true as
long as the object is that state. A constraint on an operation holds true for the duration of the attempt to execute
the operation.
A constraint is enclosed within curly braces {}. For example, an attribute called name on a theater performance
might limit the length to 50 alpha characters, including spaces and punctuation but no special characters. The
constraint may be expressed by placing the preceding text inside curly brackets, as in {up to 50 alpha characters,
including spaces and punctuation but no special characters}. Figure 3-23 models the Sales Agreement class with
a constraint on the attribute endDate. The end date must be no less than the start date. The constraint on the
relationship states that there may be any number (zero or more) sales agreements for each contract but the dates
for the sales agreements must not overlap.
Figure 3-23: Constraints on attributes and associations.
NoteCurly braces are also used for properties.
Constraints are often expressed more formally using the UML Object Constraint Language (OCL). For example,
the endDate constraint could be expressed in OCL as
context SalesAgreement inv: - - definition of an invariant
endDate =< startDate.
The first line is a definition statement that establishes the context for the statement as being within the
SalesAgreement class. The double dash designates a comment. The second line is the actual constraint stating
that the end date of the sales agreement must always be equal to or greater than the start date.
Constraints support traversing links, working with groups of items, and enumerations. Constraints are most often
applied to attributes and associations, but may also apply to stereotypes, messages, and actions.
For more information about the UML Object Constraint Language, see Chapter 19, "Action Semantics", and
Chapter 20, "Using a Modeling Tool."
<Day Day Up>
<Day Day Up>
Comments
Since it is impossible to provide a notation for everything that could be expressed in a project, UML provides the
capability to attach freeform text to any element in the model. Comments may be attached to individual attributes,
operations, associations, messages, objects, anything in a UML model.
Figure 3-24 models a comment attached to a class. Comments are enclosed in a box with a "folded" top right
corner.
Figure 3-24: A comment attached to a class.
<Day Day Up>
<Day Day Up>
Profiles
A profile is a means to customize the use of UML for a specific domain or platform. Profiles use a combination of
extension mechanisms to tailor UML notation. For example, in Chapter 4 of the UML 1.4 specification you can find
two sample profiles. One defines software development processes, and the other defines the use of UML for
business modeling.
A profile may provide stereotypes for organizing the artifacts of a project into packages. For example, the software
development profile uses stereotypes to identify analysis models versus design models. A profile may also define
class-level stereotypes such as entity, control, and boundary that explain how groups of classes should be
used within an architecture.
The goal of a profile is to expedite modeling in a domain by predefining a set of common concepts and constructs.
Chapter 21 provides a complete explanation of some example profiles so that you can see how you might use
profiles to customize your projects.
<Day Day Up>
<Day Day Up>
Summary
UML provides a variety of diagrams to support the wide range of requirements and design details needed to define
and build software systems.
Model Management diagrams
Model Management diagrams provide a means to organize the work products of the software development
process.
The Package diagram is a general purpose tool for organizing like products in much the same way that
directories and file systems do.
The Subsystem diagram is a stereotypes version of the Package diagram that partitions the work products of a
project according to the parts of a system that they describe.
The Model diagram is a stereotyped version of the Package diagram used to partition the work products
according to type of diagram used to describe the system, such as Use Case diagrams and Class diagrams.
Structural diagrams
The structural diagrams provide a static view of the resources available to the system.
The Class diagram provides the definitions of resources essential to the proper operation of the system, and
the rules for the relationships between them.
The Object diagram provides a means to evaluate facts in the real world in order to support the development
of the Class diagram. It also provides a means to test the Class diagram by representing test data.
The Component diagram represents physical pieces of software used by the implemented system.
The Deployment diagram represents the processing environment of the implemented system, including both
machine and human processing units and their connections.
Together the Component and Deployment diagrams describe how a software system is installed and runs on
the processing environment.
Behavioral diagrams
The behavioral diagrams represent how the system resources work when they execute.
Interaction diagrams of UML 1.4 describe how objects work together to accomplish the tasks of the system.
The Sequence diagram models the sequence of messages between objects during the execution of a
behavior such as a use case.
The Collaboration diagram models how objects use the links between them to pass messages during the
execution of a behavior.
Interaction diagrams of UML 2.0 have been enhanced to facilitate reuse.
The Sequence diagram still models the sequence of messages between objects during the execution of
a behavior such as a use case.
The Communication diagram is a simplified version of the Collaboration diagram.
The Interaction Overview diagram combines logical flow with interaction occurrences (pre-defined
interaction sets) to model the behavior of the system.
The Timing diagram provides a precise tool for working out the exact time constraints for a behavior of
the system.
<Day Day Up>
<Day Day Up>
Chapter 4: Object-Oriented Concepts
Overview
Object-oriented concepts have been around since the 1970s. A variety of programming languages, including C++,
Smalltalk, Java, and Eiffel, implement object-oriented principles. Object-oriented modeling languages followed
close behind, built on earlier modeling environments based on basic drawing tools and procedural modeling
techniques like structured analysis. By the early 1990s formal object-oriented methods such as the Object
Modeling Technique, Booch '93, and OOSE came into common use.
Unfortunately, many companies did not reap the real benefits of these languages and techniques because they did
not understand what makes them work. Because object-oriented principles guided the design of these tools,
understanding these principles has a direct impact on the application of the tools. Shortly after the start of the
transition from procedural to object-oriented development, studies showed that most companies were seeing less
than 20 percent improvement in development time. This hardly warranted the cost and effort to switch over.
The big question still is, "Why didn't they achieve the big gains promised by the new object-oriented techniques?"
The answer in large part is that people tried to use the new technique without changing the way they thought about
the problem. They didn't really grasp what it means to approach a problem from an object-oriented perspective.
The rest of this chapter is an attempt to explain the key concepts that together define an object-oriented approach
to software development.
So what does the phrase object-oriented mean? The phrase itself sheds some light on the answer. It has
something to do with viewing the things in the world as objects.
<Day Day Up>
<Day Day Up>
Objects and Classes
An object can be a physical entity, such as a chair or this book. You can describe the chair, repair it, and sell it. You
can buy this book, read this book, and mark this book (or even provide a great review of the book).
An object may also be intangible, such as a job or class attendance. Even though a job is not something you can
touch, it is something you can describe, discuss, assign, and complete. Class attendance can be described,
monitored, and reported. Anything that you can describe can be represented as an object, and that representation
can be created, manipulated, and destroyed to represent how you use the real object that it models.
An object is the representation of a specific entity in the real world, such as a specific person or a specific order. A
class is the rules that define the object. For example, this book is real. It is made of paper, has dimensions, pages,
colors, and ISBN and title. In the real world we move the book from the printer, to inventory, to stores, and finally
into the hands of customers. To track the physical book we would have to physically follow it through all these
movements. For one book that might be possible, though a bit costly. For a publisher who wants to track
thousands of books, the physical approach would be impossible and impractical. Instead, the publisher creates a
representation of the book, a description that contains enough information to accurately track what the publisher
needs to know about the book and its movements to support the publisher's business objectives. Then, for every
relevant change that happens to the book, the publisher alters the representation.
Since the individual representation for all books tracked by the publisher need to have the same information, the
publisher creates a single set of rules that apply to all books. The set of rules is called a class. A class is a
definition, a template, that describes how to build an accurate representation of a specific type of object. Each
object is instantiated (created, made real) by using the class definition as a template. Yet each object, each
instance of the class, can be described using unique values for each of the rules that the class defines. For
example, the class says that each book needs an ISBN. But each book object is assigned a different ISBN.
<Day Day Up>
<Day Day Up>
Creating Abstractions of Objects
To use objects, we first need to distinguish between a real object and the representation of an object. In software
projects we are nearly always working with representations of objects. The system needs to manage the
representation to reflect how you are managing the real objects. For example, an order-processing system needs
to manage customers, orders, and products. The software does not directly manipulate customers, orders, or
products. Instead the software creates representations called abstractions, a general term referring to the use of
objects and classes. The software then manages the abstractions to coincide with changes occurring to the real
world objects. Figure 4-1 shows that when a real customer places an order for a product, the software creates an
order object (abstraction) that associates the customer (abstraction) with the product (abstraction).
Figure 4-1: Real objects versus abstractions.
The quality and value of the abstraction are defined by how well it represents the real-world objects in terms of the
information we need to maintain about them and the things we need to do with them.
Figure 4-1 actually poses a problem with what I've just said because all of the images in Figure 4-1 are
abstractions, that is, the pictures of the people and the products are abstractions, representations of real people
and products. But since I can't ship a real person and real products along with the book, this will have to do. It
does, however, make my point about the quality of an abstraction. If the image is good enough to convey the
needed information for the example, then it is a successful abstraction.
So an abstraction represents something in the real world. An abstraction describes that "something" using only the
information that supports how we plan to use it. When I need to contact my tech editor, for example, I don't need to
know everything about him. I could contact him using just his name and phone number. It does not add anything to
my ability to contact him if I also record his eating habits, his genealogy, and his music preferences. All that other
information is valid and does in fact describe him, but it does not help me contact him. Figure 4-2 shows my tech
editor on the left hard at work, and an object icon, an abstraction, on the right containing the information needed to
contact him; his name and phone number.
Figure 4-2: Victor (on the left) and an abstraction of Victor (on the right, an object icon).
The reason we create abstractions is get work done. We need to create, manipulate, and dispose of information to
reflect how we create, manipulate, and dispose of real things. So to create an appropriate abstraction, I must
understand the real-world problem that the abstraction represents. If I want to sell shirts, then my shirt abstraction
must include at least some kind of identifying features, size, cost, and price. Knowing the person who assembled
the shirt, the machine(s) it was made on, or the box it was shipped in from the factory don't affect my ability to sell
it, so that information isn't needed.
It is tempting at times to pick up a dictionary or some other objective reference source to create the abstraction.
But, keeping with the shirt example, the question is not "What is the generally accepted definition of a shirt in the
English language?" The question is, "What information do we need to have about a shirt in order to sell it
effectively?" Using this approach to define an abstraction results in a different solution if the problem changes, for
example, if I need to represent shirts because I design them, or wash them, or tailor them. There is bound to be
some overlap because all four problems are using the same real world entity, the shirt. But each problem focuses
on different features of the shirt.
<Day Day Up>
<Day Day Up>
Defining an object
Defining an object has to take into account information and behavior. Each object defines three basic types of
information and two types of behavior.
Information
First, an object has to describe the features of an entity that will allow users of the object to distinguish it from other
objects. It needs to have an identity. In fact, identity was given significant clarification in the latest versions of MOF
and UML. But even if an object does not own a unique identification number, it still has a unique identity. Even if
two objects share the same features, each object has a unique identity.
Second, an object must be able to describe itself. This book has a title, author, ISBN, and a price, and contains
pages and a cover. This type of information is often called its structure, the information used to create it.
Third, each object must be able to describe its current condition, called its state. Object state is sometimes
represented by the values of each of its features. For example, the cover of this book could be new or very worn.
Other times, the state is represented by the presence or absence of key relationships with other objects. For
example, a book can be reserved or ordered. A reserved book has a relationship with the person who reserved it.
An ordered book has a relationship with an order. Sometimes a single status code represents an object's state. But
more often than not, that status code represents a unique combination of feature and relationship values that
together define the current condition of the object.
In some cases, an object may even contain a fourth type of information. Some objects are created simply to hold
and protect information generated by the system. The object does not create or even really own the information. It
is simply a steward to information, a repository. For example, log files record events that occur during the execution
of an application. The log file does not create the information. The information does not describe either the log file
or its state. The log file simply provides a place to store the information until someone asks for it.
Not every feature of an object defines its state. For example, the author name of this book does not affect its
condition. It is simply a fact about the book.
So in order for an object to be useful, it must know
Its unique identity.
How to describe itself.
Its current condition, or state.
Behavior
We create objects to represent real world entities because we need to do something. For example, Wiley
Publishing hires employees. Wiley maintains records about these employees so that it can track progress and
compensate the employees lavishly for their efforts. Wiley also wants to publish, distribute, and sell books. To
manage the employees, Wiley must know what the employees can do. Employees can work, apply for posted
jobs, edit books, acquire new authors, market new books, hire contract editors, take assignments, use a work
space, take vacation, and do many more things that are important to the success of the company. A definition for
each behavior becomes part of the complete definition of an employee object, that is, the class Employee.
The books are a bit different though. Books don't actually do anything themselves. Wiley wants to do things to the
book. Wiley wants to acquire books, edit books, print books, distribute books, review books, and sell books. In
reality, someone is doing these things to the books. So why does object-orientation tell us to assign these
behaviors to the book instead of assigning them to the person who actually performs the behavior?
This approach is the hallmark of the object-oriented approach. For years software systems were designed with the
information about an object separate from the behavior that uses the object. For each use of the object in a
different context there was typically a different program. Unfortunately, this approach led to some serious and
costly problems. Namely, because many programs could use the same object, it was common for them to require
some of the same behaviors. So the same behavior was coded into a number of programs with no guarantee that
each program wrote the behavior in the same way. Maintaining the object meant maintaining all the code spread
across all the programs that use the object. The separation of the behavior from the information about the object
resulted in redundant descriptions of behavior, lack of integrity among the many definitions, and high cost to
maintain the redundant program code.
Object-orientation proposed that the behavior should be defined once, regardless of who uses the behavior, and
that the behavior should be stored with the object. Using this approach to organizing the code, anyone who wants
to know how to use the object correctly simply looks at the behaviors defined in the object itself. The added benefit
to this approach is simpler code in the programs that use the object. Instead of writing the behaviors in the
programs, the programs simply invoke behaviors already defined in the object.
So in order for an object to be useful, the object must know
What it can do.
What can be done to it.
<Day Day Up>
<Day Day Up>
Encapsulation
Encapsulation is another concept that sets the object-oriented approach to software apart from its predecessors.
Encapsulation is a way to organize the many types of information and behavior described earlier so that objects
can be used as efficiently and effectively as possible. Encapsulation states that when designing an object we
should separate what we know about the object according to two concepts:
The minimum information needed to use the object.
The information required to make the object work properly.
These two concepts direct us to look at the object from two perspectives: an external view that asks only, "What
can I do with this object?" and an internal view that asks, "How does this thing work?"
To use an object
A few years ago, I taught my daughter how to drive. My first challenge was to identify for her the minimum
knowledge she had to have in order to use the car to drive.
I decided that she needed to know about the ignition, the steering, the brake, the gas pedal, the gearshift, the
mirrors, the gauges, and so on.
Should I have included the universal joints, the spark plugs, and the radiator on the list? No, because she didn't
need to know about those things in order to use the car to drive. Remember that an abstraction should only contain
the information needed to address a specific problem, which in this case is driving. In fact, she has been driving for
a few years and still doesn't know about many of those other parts.
The information that the car (object) exposes so that someone can use it is called the car's (object's) interface.
The interface is how you communicate to the car (object) that you want to use one or more of its behaviors. For
example, when you press on the gas pedal, you're telling the car to go faster.
An interface can also allow you to access some of the object's knowledge. For example, the fuel gauge interface
presents information about the level of gasoline in the gas tank.
So in order to use an object, you need to expose the interface of the object, much like the car interface in Figure 4-
3.
Figure 4-3: The interface for a car enables us to use the car by accessing its behaviors and its knowledge.
CautionThe term interface is used in a few different ways within OO. It may mean a single operation signature
that provides the means to access a behavior. It may also mean a set of behaviors offered by an
object, as in a Product interface class. In this discussion I am using the single operation meaning only.
(For more on interfaces, see the descriptions interface classes, as well as provided and required
interfaces, in Chapter 5).
To make the object work properly
I remember as a kid our neighbors had the old shell of a car in a field behind the house. It had brake and gas
pedals, a steering wheel, a gearshift, and so on. But no matter how I pushed on that gas pedal or turned the wheel,
the car never responded. An interface without an implementation doesn't do much. I could communicate with the
object, but the object didn't have any way to respond.
To make the object work, you need to provide the mechanisms that respond to the interface. Here is where it all
starts to come together. Remember the part about what an object knows? When you press the gas pedal, the
behavior behind that interface needs to know how the car is put together, its structure. An object knows about itself,
so the car would know how it is put together. For example, when the gas pedal is pressed, the behavior behind that
interface is supposed to move more gas to the engine, causing the car to accelerate. If the behavior does not know
how the gas tank is connected to the engine, or that the fuel pump is the mechanism it should use to move the gas
from the tank to the engine, then the accelerate behavior cannot achieve its purpose. A behavior without the
means to make it work is little more than a good intention.
Encapsulation tells us that in order to support an interface, the information about the structure has to be inside the
object along with the behavior, so that the behavior can access and manipulate it when needed. The
implementation is the combination of the behavior and the resources to satisfy the goal of the behavior.
Furthermore, you want to ensure that no one can incorrectly alter the information that the behavior is depending
on. This is why encapsulation is often called information hiding-it enables an object to protect the integrity of its
parts. You hide the information inside the object, where the object has complete control. For example, Figure 4-4
illustrates the hidden, internal mechanisms that make an engine work properly. The interface only exposes the gas
pedal, brake, ignition, and so forth; it does not provide direct access to any of these internal mechanisms.
Figure 4-4: Defining the internal design of an object so that it will work properly.
So encapsulation has two reasons to declare that all information that an object owns should be kept hidden inside
the object, away from unauthorized access: The object must know the structure in order to implement its
behaviors, and the information that describes the structure must be protected so that it cannot be corrupted and
break the implementation.
Now the gas pedal interface has an associated implementation that is aware of the engine and all the other parts
of the car. So what really happens when you press the gas pedal? Well, that depends, doesn't it? It depends on
whether the car is turned on and what gear the transmission is in. This reveals something else that the
implementation depends upon in order to work properly: the state of the car (object), the current condition of all of
its parts.
In summary, in order to make an object work properly, you need to place inside the object
The behaviors that implement for each interface.
The data that describes the object's structure.
The data that describes the object's current state.
Giving an object purpose
It sounds like we have everything we need to use an object and make it work properly. But we need something
else to fully define encapsulation: purpose. Many objects can have the same set of interfaces. Just think for a
minute about all the objects you know of that share the interfaces accelerate, decelerate, turn, start, and stop.
Figure 4-5 models just two examples, a luxury car and a go-cart.
Figure 4-5: Purpose drives the design and use of an object.
They share both the same interfaces. But you would never use them both in the same way (hopefully). If the set of
interfaces alone doesn't adequately distinguish objects, then what else do you need in order to define an object?
Purpose. You need to know why that type of object exists - what it was designed for. The interface is designed to
satisfy the purpose. Purpose drives not only the choice of interfaces but of every other aspect of an object. In fact,
purpose drives the measures of quality for the design of an object, which are covered later in this chapter.
Applying encapsulation
Encapsulation of an object requires you to expose
Its purpose, so you can select the proper object for the application you have in mind.
Its interfaces, so you know how to use the object.
Encapsulation of an object requires you to hide.
The implementation that provides the behavior requested through the interfaces.
The data within the object that defines the structure that supports its behavior.
The data within the object that tracks the state of the object, its condition at any given point in time.
Encapsulation provides a number of substantial benefits for the design of applications. Probably the most
significant is the separation of each interface from its implementation. Because the implementation is a separate
concept from the interface, it becomes possible to replace one implementation with another as new designs, new
programming features, new requirements, or anything else changes in the development environment. The
interface remains unchanged so other objects that interact with the interface don't need to be altered.
In UML terms, the interface is an operation, short for operation signature. The implementation is called the method.
Many objects may share the same operation, but each may provide its own unique method to implement the
operation. So whether I am driving the luxury car or the go-cart, I can say "accelerate" and each vehicle will satisfy
my request to go faster, even though each vehicle is built differently, fueled differently, and used for a different
purpose.
This ability to have many classes with the same operation, but their own methods, is called polymorphism, and I'll
explain a bit more about it later in the chapter.
Encapsulation ensures that the data associated with an object cannot be corrupted by other objects. The only way
to access the data is through an interface provided by the owning object. If, for example, you want to change the
price of a ticket, you have to ask the ticket, "May I please set the price to another value?" The ticket then invokes its
implementation for price changes, tests your request, and decides to let you change the price. Of course, it is up to
the designer to provide adequate tests in the implementation to guarantee the integrity of the data.
Figure 4-6 shows a Ticket object. On the left are two interfaces to set the value of the price feature. Each
provides a value of a different type. Encapsulation supports the ability to store information internally in one format,
even though it is provided to the object in another format. For example, I could input a price as $10.00, but the
object could convert it from a string (with the dollar sign and decimal point) to store it as a float value or even as an
integer (without the dollar sign and decimal point). It is up to the implementation for each interface to do the correct
conversion, validate the input value, and allow or disallow the change.
Figure 4-6: Separation of interface from implementation supports a difference between the internal storage of
data and the external use of data.
The same is true for getting data from an object. When I ask for a value, the object converts the stored value into
the format I ask for. In fact, it might provide interfaces to return it in many different formats. Figure 4-6 also shows
two interfaces that allow you to get the value from the price field. Each interface asks for a different type of
output value; a string, and a decimal. It is up to the implementation for each interface to validate access to the
value, and to perform the needed conversion.
In both cases, providing values to an object and asking for values from an object, the object's users do not need to
know how the value is stored. They only need to know what the interfaces support or require, depending on the
type of interface.
<Day Day Up>
<Day Day Up>
Defining associations and links
Defining individual objects is just the beginning of object modeling. In order for software objects to get work done,
they need to work together the way the objects they represent work together. When a customer orders tickets, the
customer has to create an order and add tickets to that order. The software objects that represent the customer,
order, and tickets need to exactly replicate the relationships between the real-world objects.
A link is a relationship between two objects. An association is a relationship between two classes. An association is
the definition of a type of link in the same way that a class is a definition of a type of object. Just as an object is an
instance of a class, a link is an instance of an association.
Associations (and links) take on three different forms, association, aggregation, and composition. The simplest
form, association, is a peer-to-peer relationship. One object simply knows about another object in much the same
way that one person might know about another person. That knowledge is typically stored in the object as a
reference, like a person who keeps a phone number or address of another person he wants to contact. An
association is most commonly modeled as a named line between two classes, as shown in Figure 4-7. The
association between the customer and order models a relationship in which a customer places an order. The
existence of this association means that it is valid for individual customer and order objects to participate in this type
of relationship. The association between order and ticket models a relationship in which an order reserves tickets.
The existence of this association means that it is valid for individual order and ticket objects to participate in this
type of relationship.
Figure 4-7: Modeling an association.
Also, like human associations, software class associations may require a set of rules that govern the relationship.
Who can participate in the relationship? How many objects can participate? How do the participants behave in the
relationship? Which direction should the association name be read? When does the relationship begin and end?
Chapters 5 and 6 explain the means to model these rules - multiplicity, constraints, direction indicators, association
classes, roles, and comments.
Associations can be refined to model a more restrictive type of relationship called aggregation. Aggregation may
also be refined to model an even more restrictive relationship called composition. Figure 4-8 models the
relationships between these three types of associations.
Figure 4-8: The relationship between association, aggregation, and composition.
The purpose of Figure 4-8 is to emphasize the relationship between these three class relationships:
Every aggregation relationship is a type of association. Every aggregation relationship has all the properties of
an association relationship, plus some new rules of its own.
Every composition relationship is a form of aggregation. Every composition relationship has all the properties
of an aggregation, plus some new rules of its own.
Defining aggregation
Aggregation is a special type of association used to indicate that the participating objects are not just independent
objects that know about each other. Instead, they are assembled or configured together to create a new, more
complex object. For example, a number of different parts can be combined to create a physical assembly such as
a car, a boat, or a plane. You could also create a logical assembly such as a team where the parts are not
physically connected to one another but they still operate as a unit.
To model aggregation on a Class diagram:
Draw an association (a line) between the class that represents the member or part of the assembly and the
class that represents the aggregation, the assembly. In Figure 4-9, that would mean a line between the
Engine class (the member or part) and the Car class (the assembly).
1.
Draw a hollow diamond on the end of the association that is attached to the aggregate class. In Figure 4-9,
the diamond is next to the Car class that represents an assembly that includes an engine. This model
shows that a car is built using an engine as one part of its configuration.
Figure 4-9: How to represent an aggregation relationship in UML.
2.
What makes aggregation unique? More importantly, what makes aggregation beneficial? Aggregation describes a
group of objects in a way that changes how you interact with them. The concept is aimed at protecting the integrity
of an assembly or configuration of objects in two specific ways.
First, aggregation defines a single point of control in the object that represents the assembly, like the car in Figure
4-9. That object becomes the boss, so to speak, directing the activities of all the other objects in the assembly. This
ensures that no matter what objects outside the assembly might want to do to the parts of the assembly, the
control object has the final word on whether the actions are allowed. In Figure 4-9, the car controls what can be
done to its engine. If you want to tune its engine, you talk to the car's "tune engine" interface. If you want to replace
an engine, you talk to the car's "replace engine" interface. This assignment of control may be at many levels within
the assembly. For example, a car might control its engine, but an engine controls its parts, such as the pistons and
plugs.
If the application did not enforce this design choice then it would be possible to alter the engine without first
validating that it was legitimate or even safe to do so. For example, attempting to tune the engine while the car is
being driven down the freeway could be dangerous.
Second, when an instruction is given that might affect the entire collection of objects, the control object dictates
how the members will respond. So for all intentions the assembly appears to function like a single object. When I
push the gas pedal, telling the car I want to accelerate, the entire car assembly (with its thousands of parts)
accelerates, not just the gas pedal. Without this point of control, I would have to manually manipulate each part in
the assembly directly, risking a mistake or leaving out an important item. The more the assembly is used, the
bigger the payback in time savings and reduced risk when using or altering the aggregate object.
As the number of objects and behaviors in the configuration increases, the point of control and making the entire
assembly of objects act as a single unit can drastically reduce the complexity of the application and the cost of
maintenance. In fact, designers often model an aggregation in one Class diagram, fully describing all the parts and
the rules for propagating instructions throughout the assembly. Then whenever they need to use the assembly in
another Class diagram, they only include the one class that represents the control point, understanding that the
entire configuration lies behind that class.
Defining composition
Composition is used for aggregations in which the life span of the part depends on the life span of the aggregate
object. The aggregate has control over the creation and destruction of the part. In short, the member object cannot
exist apart from the assembly. The part object would never exist on its own, in inventory or in a parts store, for
example.
Draw this stronger form of aggregation simply by making the aggregation diamond solid (black). In Figure 4-10, the
car example uses aggregation, the hollow diamond. A car contains an engine as part of its assembly. The order
example uses composition, the solid diamond. An order is composed of line items. A line item is simply a place on
an order that records the fact that you want a product, along with the quantity, price, and possible discount.
Whether the order is ever placed, or the order is deleted, the product still exists. But a line item only exists as part
of an order. The line items would not continue to exist elsewhere on their own if the order was deleted. If the order
containing the line items is deleted, the line items cease to exist along with the order.
Figure 4-10: How to represent composition.
TipIn database applications this type of relationship is reflected in "cascading deletions". In a composition
relationship, when the master record is deleted, all the related records are deleted. The related records
have no meaning independent of their participation in the assembly represented by the master record, so it
is pointless to keep them around without the master record.
CautionThe UML definition of composition does allow a part to be moved to another composite. In the middle
of the behavior that moves it, the composite member is not part of the assembly. But by the end of the
behavior it has to be part of an assembly. For example, if I define the car/engine as a composite
relationship, then the engine must always be part of a car. UML allows me to move it to another car.
But I could never uninstall it and leave it sitting in my garage.
Java's inner class construct is a coding equivalent to composition. Although the UML and Java implementations
differ slightly, they are close enough to perhaps help you understand the concept if you are already familiar with
Java. But this observation brings up an important issue: aggregation, for the most part, does not have any coding
equivalents. Aggregation and composition are design, not implementation, concepts. In other words, there is
nothing in the syntax of a programming language that enforces the unique qualities of aggregation, that is, point of
control or having the assembly behave as a unit. It is up to the designer to adhere to these principles when
designing the interactions between the aggregation and other objects in the application.
For example, when a customer object places an order, each line item should be added by accessing an
interface/operation on the order object to add the line item. When a customer deletes an order, he should call an
interface/operation on the order. The order deletes the line items and then completes its own deletion.
From a programming syntax perspective, it is valid to communicate directly with a line item. But to do so risks
corrupting the integrity of the order. The order needs to know what is happening to its parts so that it has the
opportunity to protect the integrity of its configuration and properly coordinate the behavior of its members.
<Day Day Up>
<Day Day Up>
Defining inheritance/generalization
The term generalization is used in two ways. Creating a generalization is the process of organizing the features of
different types of objects that share the same purpose. A generalization is a description of the features shared by a
set of objects. We use the generalization process to create generalizations routinely to organize large amounts of
information. Walk through a grocery store and you find foods located in areas of the store according to their
properties - dry goods are located in one area, fruits and vegetables in another, meat in yet another. All of these
items are foods, but they are different kinds or types of foods. Phrases like "kind of" or "type of" are often used to
describe a generalization relationship between classes (for example, an apple is a type of fruit that is in turn a kind
of food and so on).
You might also hear this type of relationship referred to as inheritance. Many times the terms generalization and
inheritance are used synonymously. This is because if an apple, for example, is a kind of fruit, then it inherits all of
the properties of fruit. Likewise, an apple is a specialization of fruit because it inherits all of the generalized
properties of fruit and adds some unique properties that make apples special or unique within the larger group of
fruits. In the reverse, I could say that the concept "fruit" is a generalization of the facts that are true for
watermelons, apples, peaches, and all types of objects in the group.
A generalization is not an association. That is worth repeating. A generalization is not an association. In fact,
association and generalization are treated as separate model elements in the UML metamodel, two distinct
specializations of the Relationship metaclass. Associations define the rules for how objects may relate to one
another. Generalization relates classes together where each class contains only a subset of the properties needed
to define a type of object.
In Figure 4-11, the large category Fruit is specialized into three categories. Apple, Watermelon, and Orange. Apple
is then specialized into RedDelicious and GrannySmith. Apple defines those features that make apples distinct
from all other fruits. RedDelicious defines those features that make red delicious apples distinct from all other
apples. To instantiate a Red Delicious apple, I need to combine the RedDelicious class, the Apple class, and the
Fruit class to get all the features that define a red delicious apple. From the combination of all three classes, I can
create (instantiate) an object of type RedDelicious.
Figure 4-11: Modeling generalization.
To express the same thing in words, I might say, "A red delicious is a type of apple, and an apple is a type fruit."
For this reason, you sometimes hear generalization called the "is a" relationship. That is, every red delicious object
"is an" apple object and every apple object "is a" fruit object.
Because the generalization relationship is not a form of association, generalization does not use any of the rules or
other features found on associations, such as multiplicity, role, and constraints. These features are simply
irrelevant.
To understand the concept of generalization, we also need to define superclass, subclass, abstract class, concrete
class, and discriminator. A superclass is a class that contains features that are common to two or more types of
objects that share the same purpose. In Figure 4-11, the Fruit class and Apple class are examples of
superclasses. The Apple class contains features that Red Delicious, Granny Smith, and all other apples have in
common. The term superclass borrows from the concept of superset. The superset, or superclass in this case,
contains the traits that are common to every object in the set. The difference between superclass and superset is
that a superclass only contains the features that all of the members have in common. A superset would include
everything they have in common, but could also include properties unique to itself.
A subclass is a class that contains some combination of features that are unique to a type of object that is partially
defined by a superclass. In Figure 4-11, Apple, Watermelon, Orange, RedDelicious, and GrannySmith are all
examples of subclasses. Note that a class-the Apple class, for example-may be both a superclass and a subclass.
The term subclass borrows from the concept of subset. The subset, or subclass, contains a unique set of features
for only certain objects within the set. The GrannySmith class in Figure 4-11 would contain only the features that
are unique to GrannySmith apples. A GrannySmith object would get the rest of the information about the features it
shares with all apples from the Apple superclass, and all the features it has in common with all fruits from the Fruit
superclass. In other words, it actually takes three classes to generate a single object representing a GrannySmith
apple.
An abstract class is a class that lacks a complete definition. If a class defines an operation or operations that do
not have a method, it is said to be abstract. Since an abstract class is not fully implemented, it cannot create
objects (cannot be instantiated). Abstract classes must have subclasses that provide methods for any
unimplemented operations. As such, only a superclass can be abstract. In Figure 4-11 the Fruit and Apple classes
may be abstract but they don't have to be, since it is valid and common to create objects from a superclass. For
example, your store might do a high volume of Red Delicious and Granny Smith apples, so creating new classes is
justified to track the performance of these individual products. But you also sell other miscellaneous varieties as
they become available. You still need to track that sale of apples but it is not worth your time to track the
differences between the small lots of different varieties. So you just lump them under generic apples by creating
an instance of the Apple class.
A concrete class is a class that has a method for every operation so that it can create objects. The methods may
be defined in the class or inherited from a superclass. All classes at the bottom of a generalization hierarchy are
called leaf nodes. These classes are not specialized by any other class that could provide the missing method, so
these classes must be concrete. But as the previous example of the miscellaneous apple varieties showed, any
superclass also may be concrete.
A discriminator is an attribute or rule that describes how you choose the set of subclasses for a superclass. If I
want to organize the information about types of cars, for example, I could discriminate based on a feature that all
the objects share such as price range, manufacturer, engine size, fuel type, usage, or any number of other criteria.
The discriminator I choose depends on the problem I am trying to solve.
In Figure 4-12, I use another very common practice: I identify a set of predefined designations (that is, types of fruit
and varieties within types), which UML calls PowerTypes. A PowerType is an enumeration of values that exist apart
from, but which describe sets of objects within a group. For example, cars may be distinguished as economy and
luxury, or as compact, intermediate and full-size.
Figure 4-12: Modeling generalization with discriminators.
The composition of a class reveals the possible discriminating features. Classes define features of objects
including attributes, operations, and association. These are the first three possible discriminating properties. If
objects of the class share the same attributes, such as age and address, they might be in the same subgroup.
However, objects might have the same attribute (such as age) but the values allowed for age in some of the
objects are different from those allowed in others. For example, every Person might have an age value assigned.
However, minors would have age values less than 21 (in some states) and adults would have ages greater than
20. If the application needs to distinguish between people based on the value of the age attribute, then the value
range of the age attribute is the discriminator, not the age attribute.
The same concept applies to operations. Objects might have the same operation, that is, the same interface, such
as "accelerate." But different objects might implement that operation in very different ways. A car accelerates very
differently from a rocket. Even different cars accelerate using different combinations of parts and fuels. If the
application needs to distinguish objects based on the differences in their methods, then methods become the
discriminator for organizing the objects into classes.
In summary, there are at least five objective criteria we can use to discriminate between objects within the same
class (superclass):
Attribute type
Attribute values allowed
Operation (interface)
Method (implementation)
Associations
<Day Day Up>
<Day Day Up>
Defining Polymorphism
Polymorphism is the ability to dynamically choose the method for an operation at runtime, depending on the type of
object responding to the request. Keeping with the car and rocket example, my application can invoke the
accelerate operation on any car, without having to first know how the individual car will implement the operation.
Polymorphism is made possible by two principles: encapsulation and generalization. Encapsulation defines a
means of organizing the information about an object so that the interface/operation is separate from the
implementation/method. Generalization defines a means of organizing class features so that shared features
reside in one class and unique features reside in another class. Applied together, these concepts say that an
operation could be shared and defined in a superclass, but that the method for that operation might be unique
within each subclass.
Polymorphism simply means many ways to accomplish the same thing. A polymorphic operation has a different
method in each class in which it is implemented. For example, Figure 4-13 models discounts. All discounts can
calculate an applied discount amount. But not all discounts implement the calculation the same way. In this model,
the subclasses GroupDiscount, ValueDiscount, And QuantityDiscount each inherit the "calculate applied discount"
operation defined in the Discount class. Then each subclass provides its own method. It is also valid to provide
some or all of the implementation logic in the superclass and have the subclasses inherit, and then override or
extend the logic.
Figure 4-13: Polymorphic behavior: calcAppliedDiscount() is implemented differently by each subclass of
Discount.
CautionRegarding Figure 4-13: In code I would need to declare the operation calcAppliedDiscount in
each subclass so that I could override the method. In a modeling tool, the inherited operation can be
automatically generated in the subclasses so I usually don't bother to put it directly into the model
when the tools can do it for me.
Generalization is one way to accomplish polymorphism. Another way is to define a special kind of abstract class
called an interface class. An interface class follows some simple rules that prevent it from being used as a regular
class. An interface may only declare operation signatures-the operation details that tell other objects how to invoke
the behavior. This typically consists of the name, parameters (if any), and the result (if any). In other words, an
interface class is an abstract class with no methods at all.
Note I use the expression interface class, not just interface. The usage of the term interface so far referred to a
single operation, a way to invoke a single behavior. An interface class is a collection of operations in a single class.
Implementing an interface class is called realizing the interface class. That is to say, the rules established by the
interface class are made real by adding an implementation. Realization allows a class to inherit from an interface
class without being a subclass of the interface class. But the only features that the class can inherit are the
operations-no methods, no attributes, and no associations.
NoteActually, UML does allow attributes in interface classes. The rules are explained fully in Chapter 5.
Realization is also used in other contexts such as collaborations (which I discuss in Chapter 6), use cases (Chapter
12), and packages (Chapter 14).
NoteProgramming correlations: Java explicitly supports an interface class. The Java realization relationship
uses the key word "implements". In C++, you can use a pure virtual class to mimic an interface.
For example, the classes that define shirts, perfumes, and lawn mowers do not have much in common, so they
would not have a common superclass. But a department store uses all of these items as products. As products,
the store wants to buy them, price them, and sell them. But the process for buying each item is different - the store
buys them through different buyers, from different distributors, and under different terms - so one implementation
won't support the store's requirements for all the different types of products.
An alternative is to define a Product interface class, like the one shown in Figure 4-14, which declares the
operations buy, price, and sell. Then when the Shirt, Perfume, and LawnMower classes realize the Product
interface class, they each must provide their own method for each operation.
Figure 4-14: Unrelated classes realizing the same interface class.
The implementing class is obligated to provide a method for every operation declared in the interface class. So
every class that implements the same interface class presents the same set of behaviors to the world whether or
not the realizing classes are in the same generalization family of classes.
<Day Day Up>
<Day Day Up>
Measuring Quality
As we have seen so far, object orientation is built on a number of valuable concepts. But these concepts alone do
not ensure a quality object-oriented model. We still need some principles to guide the use of these concepts.
Cohesion and coupling are two common principles that have been in use for a long time and are to some extent
responsible for the development of the object-oriented concepts.
Cohesion
Cohesion is a measure of how well the parts of an object support the same purpose. Cohesion measures two
factors: how well-defined the purpose of the object is, and whether every part of the object contributes directly to
fulfilling the purpose. High cohesion means that an object has one well-defined purpose and everything in the
object contributes directly to that purpose. Low cohesion means that either the purpose of the object is ambiguous
(as when an object has multiple jobs or a poorly defined job) or not all the parts of the object contribute directly to
the object's purpose, or both.
To describe how objects work, I often refer to the way people work. The similarities are strong and the principles
work very much the same. So I will use the example of an employee's job description and then compare it with a
class description to illustrate the significance of these two factors in measuring cohesion.
When you hire a person to do a job, it is very important that the job be clearly defined. When the job is not clear, a
lot of time is wasted trying to figure out what the person is supposed to do. Many of us have been in this position
and know how frustrating and inefficient it can be. To avoid this problem we often write a job description-"software
developer", for example. The job description starts with a few lines about the purpose of the job, such as, "A
software developer is responsible for creating quality software solutions to company needs on time and within
budget". Next, the job description lists duties that a person in that position must perform to fulfill the purpose of the
job. The list might include gathering requirements, researching those requirements, designing and constructing a
solution to those requirements, testing the solution, and putting it into production.
Cohesion asks whether each of those duties directly contributes to the fulfillment of the job's purpose. For
instance, does gathering requirements contribute to creating a quality software solution? Does testing the solution
contribute to creating a quality software solution? In this example the answers are all yes, and the job description is
said to have high cohesion. The purpose is well defined and all the parts of the job description contribute directly
toward fulfilling that purpose.
What happens to the job if I add a new, unrelated duty to the list? For example, I am the vice president of
operations and I have been told by the board that I have to institute a safety program. So I go to each project team
and I pick some poor software developer to be in charge of the safety procedures for her team. I have only added
one duty to her job. But what is the effect of that one change? Does the new duty directly support creating a quality
software solution? No. And notice the effect it has on her job. Is she now more productive or less productive? The
duty added not only the new responsibility, but also the need to decide when to work on safety duties and when to
work on software duties. It added a requirement to keep track of information related to safety separate from
information related to software development as well. Now whenever she wants to start a task, she needs to first
evaluate the effect that it might have on the other duties. During the time that she is evaluating a plan of action, no
work is getting done. In short, behavior becomes more complicated and different, unrelated data are managed
within the same job, creating overhead and loss of productivity.
A class works much the same way. When the behaviors, data, and associations assigned to a class directly
support its purpose, it can do its job any time another object makes a demand on it. When I assign unrelated
behaviors to the same class, I also need to assign the corresponding unrelated data to the same class. When I
invoke a behavior on an object of that class, the behavior might first have to check whether it can perform that
behavior. The class has to build in the overhead to manage unrelated behavior, data, and associations. The
easiest way to spot this problem is to look at the volume and type of decision logic in the class behaviors. If the
decisions have more to do with deciding what to do than how to do it, you might have a cohesion problem, like the
software developer who has to decide whether to attend a safety meeting or a design walkthrough scheduled at
the same time.
This happens a lot in user interface designs. One object is designed to handle everything that can happen on the
screen. But often a user can select multiple items, check boxes, and fill in text fields, all of which might affect the
response of the application to an action like hitting the Enter key. So when the object receives the Enter key
request, the first thing it has to do is run through a long list of questions about what happened on the screen before
it can figure out what to do. During the time that it is evaluating a plan of action, no work is getting done.
Compromise: In the job description example, we see that cohesion is a matter of degree that might involve trade-
offs. It would be ideal to have a separate person who could handle the safety issues. Unfortunately, that's not
always practical. The same is true of a class. It is desirable to seek the highest possible cohesion, but it isn't always
practical. The important thing is to make the decision to compromise explicit. Recognize the cohesion issues and
choose to compromise based on conscious, well-informed cost-benefit trade-offs.
Coupling
Coupling is a measure of the degree of dependency between objects. Loose coupling means that an object is
pretty much free to do its job without a lot of interaction with other objects. Ultimate loose coupling would be
complete independence, no dependency at all. Tight coupling is kind of like being on a short leash: you can't move
because the connections to other objects are too binding.
Coupling looks at the relationships and the interactions between objects to see whether one object requires the
help of another object to do its job. A dependency often reveals itself when a change in one object requires a
change in another object.
Again, an illustration using people might help. Our software developer needs to work with the database
administrator (DBA) to set up the tables for her application. Whenever the DBA changes one of the tables, the
developer needs to at least check her application to see whether she needs to make any corresponding changes.
Likewise, a server-side object provides services to any number of user interface applications. When a service
changes all of the dependent applications need to evaluate the effect and make any needed changes.
Dependency can be measured by looking at four aspects of the relationships between classes:
The number of associations. Each association in which a class participates requires maintenance. The
connection has to be created, maintained, and deleted over time. That maintenance is overhead. As the
number of connections increases, the time spent maintaining the connections increases. Any time an object
on the other end of any of the connections changes, the object needs to evaluate the impact of the change.
Consider your job. If you are accountable to one project leader, the overhead to keep in touch and function
properly is limited. If you are accountable to not only the project leader but the user manager, the DBA, the
technical lead, the reuse library manager, the design review committee, the standards committee, and the
legal department, you are going to spend more time trying to keep everyone happy than getting work done.
Objects have the same problems.
The volume of communication. Communication also requires overhead. While an object is communicating,
it is not getting work done, much like an employee stuck in meetings all the time. Communication is vital, but
how much is really necessary? Every piece of communication requires a response, even if it is only an internal
acknowledgement that I have the information. As the volume of information increases, more of the object's
time is spent interpreting the information and deciding how to respond.
Consider for a moment why it is so difficult for teams to institute design and code walkthroughs. Most often, it is
the sheer volume of information that chokes the process. No one has sufficient time to critically evaluate and
respond to the material, so the review meetings (the downstream processes) are hindered.
Objects can choke on volumes of information, too. Throughput can max out, and objects can create
bottlenecks in the system. Also when one object is responsible for channeling large volumes of data, it can be
very difficult to replace or enhance that object without a cascading set of changes to all of the objects
downstream.
The complexity of the communication. Even when the volume of communication is low, the complexity can
create tight coupling. When the communication is complex then the objects on both the sending and receiving
ends have to know and maintain the rules for properly interpreting the information. If one object changes the
rules and the other does not, the communication breaks down.
Complexity is seen most easily in the parameter lists in operations. An object might require a long list of data
items or a large object packed with information. If the calling object incorrectly passes even one item then the
entire message can be in error. The overhead exists in keeping all parties up to date on the rules for the
communication. Once again the effort in maintaining the system is diverted from the work the application was
designed to perform and onto coordination.
Whether an object requires knowledge of the internal structure or state of another object. Perhaps the
worst form of coupling is also a violation of encapsulation; when an object needs to know the state of another
object before it can communicate. An object should not depend on another object's state and it certainly
should not be able to interrogate the other object's state.
An alternative is to simply invoke a behavior on the object and let it tell you whether it can support the request.
Interestingly, the answer to many coupling problems is better cohesion, and identifying coupling challenges creates
opportunities to improve cohesion. Other times, cohesion and coupling have to be balanced. Figure 4-15 illustrates
the balancing act between cohesion and coupling. Cohesion is an internal measure of object quality. The goal is to
create each object with a single well-defined purpose. But if you make the purpose too small, you end up with
objects so small that they cannot get any significant work done without lots and lots of connections and
communication with other objects, thus creating very tight coupling.
Figure 4-15: Balancing cohesion and coupling.
Likewise, the goal of coupling is to make each object as independent as possible. If you push this to the extreme,
every object would be completely independent. Independence means that there are no connections and no
communication. In other words, each object would have to do everything itself, thus creating very low cohesion.
The real goal is balance. Cohesion and coupling have a direct impact on your ability to change an application
easily. If your need for change is low, then you can afford to compromise. For example, if you have more than
sufficient bandwidth, high volumes of communication may not be a problem. If the application is very stable, that is,
there are very few change requests, low cohesion would not increase your maintenance cost significantly.
The point of this section is to know what to look for when you measure quality and to know how to make conscious
decisions about where to compromise to achieve the best solution for the specific circumstances.
Recommended Reading on Design Principles
Meilir Page-Jones wrote a very good book, Fundamentals of Object-Oriented Design in UML (Addison-Wesley
Publishing, 1999), that probes at length the specific characteristics of quality in software design. He breaks
them down much more than I have here, providing many specific examples of problems and solutions in a
design.
Capers Jones is probably the nation's foremost authority on software metrics. He has conducted a number of
studies on what makes a quality software project or application. His book, Patterns of Software Systems
Success and Failure (International Thomson Publishing, 1996), documents the specific practices that define
success and failure in a variety of different types of applications. He then offers strategies for improving our
practices.
Martin Fowler wrote Refactoring - Improving the Design of Existing Code (Addison-Wesley Publishing, 1999),
in which he provides specific examples of how to spot problems with the quality of a design. It is an extremely
practical book, filled with concrete examples and practical help to restructure a design.
<Day Day Up>
<Day Day Up>
Summary
Abstraction: An abstraction is a representation of something real, such as a picture of this book. Even though
there is an almost infinite amount of information about any real entity, a useful software abstraction contains
just enough information about the entity to support the purpose of the software application.
Encapsulation: Encapsulation describes a way to organize the information in an abstraction so that it can be
used efficiently in a software application. Encapsulation separates the facts needed in order to use the object,
from the facts needed to make it work properly. To use an object, the object needs to expose its purpose and
interfaces. To make the object work properly, the object needs to contain the data and behavior that satisfy the
services offered by the interfaces.
Classes and objects: A class is a definition for a type of entity in much the same way that an entry in a
dictionary is a description of a type of entity, such as a car. An object is an abstraction for a single entity, such
as my car. A class defines rules. An object defines facts. An object is instantiated (created) according to the
rules defined by its class.
Associations and links: An association defines a type of relationship in the same way that a class defines a
type of entity. A link is an abstraction of a specific relationship that conforms to the rules set forth by an
association in the same way that an object is an abstraction of an entity that conforms to the rules set forth by
a class.
Aggregation: Aggregation is a type of association that states that one of the participating objects must play the
role of the controller of the other object. All interactions with the pair are directed to the controlling object, the
aggregate object. The aggregate class defines how an aggregate object must behave. The aggregate object
propagates the required instructions to the member object. A member class defines how the member object
must behave.
The two defining characteristics of aggregation are that one object plays the controlling role (and the other the
member or subordinate role), and the two (or more) objects behave as one. An instruction directed at the
aggregate object results in the set of objects working together to satisfy the request.
Composition: Composition is a type of aggregation that states that a member object may only be a member of
one aggregation. The life-span of the member is dependent on the life-span of the composite object.
Generalization, specialization, and inheritance: To generalize is to gather all the common features from a set
of classes and define them in a single class. A generalization is the class that contains the shared features. To
specialize is to isolate the features of a class that only apply to a subset of the object of that class. A
specialization is a class that contains the features unique to the subset of objects. Inheritance is the principle
that allows a specialization to have access to the features in a generalization. An object instantiated by a
specialized class is built from the features of the specialized class and all of its generalized classes.
PowerTypes and discriminators: Specialization may be performed by evaluating the features of the objects
represented by a class. When the values of these features define the criteria for sub-setting/specializing the
class, the value is called the discriminating value or discriminator. When an external set of criteria is used to
sub-set the objects, the enumeration of types is called a PowerType.
Polymorphism: Polymorphism states that because the interface/operation for a behavior is separate from the
implementation/method for a behavior, an operation may have any number of methods. Each class that
supports the same operation may define a different method. The method that executes when an operation is
invoked depends on the object that is satisfying the request.
Interface class: An interface class defines a set of operations without specifying any methods.
Cohesion: Cohesion is a measure of how well the parts of an object support the single purpose of the object.
Coupling: Coupling is a measure of the degree of dependency between objects.
<Day Day Up>
<Day Day Up>
Part II: Modeling Object Structure
In This Part
Chapter 5: Capturing Rules about Objects in a Class Diagram
Chapter 6: Capturing Rules about Object Relationships
Chapter 7: Testing with Objects
<Day Day Up>
<Day Day Up>
Chapter 5: Capturing Rules about Objects in a Class
Diagram
Overview
The Class diagram stands at the center of the object-modeling process. It is the primary diagram for capturing all
the rules that govern the definition and use of objects. As the repository for all the rules it is also the primary source
for forward engineering (turning a model into code), and the target for reverse engineering (turning code into a
model).
The Class diagram is described in this chapter and in Chapter 6. This chapter covers classes and all the features
used to describe them. Attributes and operations describe the knowledge and behavior of a class. Additional
embellishments such as stereotypes, tagged values, and constraints describe how you can customize classes to
facilitate development in a particular domain. Chapter 6 describes how to model relationships between classes.
I cover the UML 1.4 description of classes, attributes, and operations, and step through the UML 2.0 specification
to explain the current definitions for classes, attributes, and operations, and the key definition elements such as
visibility, changeability, multiplicity, default values, and properties.
<Day Day Up>
<Day Day Up>
Defining the Purpose and Function of the Class Diagram
The Class diagram is probably the most widely used diagram of the UML. In fact, the Class diagram is the primary
modeling tool for describing UML itself.
NoteWhen I discuss UML 2.0 elements, I refer to the Class diagrams in the UML 2.0 specification to explain
the features. This gives you some practice reading and interpreting the diagrams while you familiarize
yourself with the specifications.
The Class diagram is also the primary diagram for generating code. While there have been valuable applications
that support code generation from State and Sequence diagrams, these tools are not in the mainstream. This
ability to generate code places the Class diagram in a unique position relative to all the other diagrams. Figure 5-1
shows all of the UML diagrams, with the Class diagram at the center. It illustrates that even though each of the
other diagrams help modelers discover valuable information about a subject, everything they uncover must
somehow make its way onto the Class diagram.
Figure 5-1: All other diagrams feed information to the Class diagram.
Chapter 3 describes the purpose and function of each of the UML diagrams. Apart from the Component and
Deployment diagrams, which are used to describe the implementation environment, all the diagrams model facts
at the object level. These facts come from test cases and examples that help us understand how things work.
Facts are invaluable resources, but to build a software application the modeler has to create a set of abstractions,
rules, and concepts that describe how these facts may be used. The abstraction needs to define what each
resource is, the information it owns, what it can do, and the other types of resources with which it needs to interact
to do its job correctly. Figure 5-2 represents how the UML diagrams uncover facts that support the creation of the
Class diagram. The Class diagram models the facts so that the model represents reality as closely as possible.
The Class diagram defines the code that generates the objects. The objects conform to the Class diagram.
Figure 5-2: The relationships between the Class diagram, other diagrams, and the application code.
The other UML diagrams model facts as objects. These objects either conform to the rules set forth in the Class
diagram, or they reveal the need for corrections to the rules.
The rules in the Class diagram are used to generate code. The code generates objects, while the application is
running, that behave according to the rules defined by the Class diagram.
Systems may be fairly complex and may require more than one Class diagram. In fact, it is very common to break
a subject area down into a set of smaller Class diagrams. Smaller diagrams are easier to work with and easier to
verify. But no matter how many diagrams you use for the system, each class has only one definition. A class
represents the same concept no matter where or how often it appears in the diagrams. In a modeling tool, this is
accomplished by using a repository. A repository is a shared dictionary, usually built into the modeling tool, of all of
the information defined during the modeling process. The first time you add a class to a diagram, a definition is
placed into the repository by the tool. Each subsequent time that the class is referenced on a new diagram, the
new reference is associated with the existing definition. Consequently, a change made to a class on one diagram is
also made to the class definition in the repository, and is reflected in all diagrams that include that class.
Defining all of these rules sounds quite complicated. In truth, the notations of the Class diagram provide a
surprisingly simple yet powerful means to specify everything needed to generate code. With rigor and the proper
software support, the Class diagram can even become fully executable. This means that the model can be tested
by executing scenarios and can even generate the complete application in a variety of implementation
environments. But I'm getting ahead of myself.
Figure 5-3 illustrates how the Class diagram uses simple rectangles and lines to represent the resources that
make up a system (rectangles) and the relationships between the resources (lines). It has been my experience
that, even without prior experience, most participants on a team can quickly learn to read the basic notations of the
Class diagram. The portion of a Class diagram shown in Figure 5-3 models some relationships in a theater
system. The Class diagram represents the resources needed to support scheduling events at a venue and selling
access to the seats in the venue that hosts the events. The numbers and all other notations are explained later in
this chapter.
Figure 5-3: A simple Class diagram of the relationships between the resources Venue, Event, and Seat.
The simplicity of the Class diagram can be a bit deceiving. The Class diagram can be used to model a surprisingly
wide variety of systems, such as airplane navigation, monthly invoicing, real-time embedded devices such as
medical equipment, and human-machine interface systems used to automate factories. But all of these
applications rely on the same small set of descriptive elements: classes and relationships. With the addition of the
standard UML extension mechanisms (covered in Chapter 3), the Class diagram can model pretty much anything
you need in a business or technical environment.
<Day Day Up>
<Day Day Up>
Modeling a Class
Classes form the foundation of the Class diagram. So to work with the Class diagram, you need to be clear on the
difference between classes and objects. A class is a definition for a resource. It includes information that describes
the features of an entity and how it can be used. In contrast, an object is a uniquely identifiable entity that conforms
to the rules defined by the class. In software terms, code is written as a set of classes and references to behaviors
defined by the classes. The information actually created and manipulated is owned by objects that conform to the
class descriptions. Objects are represented by rows in a database, records in files, or areas of memory in a
computer.
Cross-Reference Chapter 4 explains the concepts of classes and objects fully.
A class is very much like a dictionary entry. If our theater application has to manipulate information about events,
then we first need to explain what we mean by the term event using a class definition. A UML Class definition
describes a type of object. In fact, the term "type" is often used as a synonym for "class" (even though there is a
subtle difference that will be covered when we get to inheritance in Chapter 6). One class definition describes
many objects of the same type. Each class definition contains at least a unique name. This name defines the class
in the repository so that any time the same name is referenced it is associated with the same repository definition.
A class can also contain attributes and operations that describe everything necessary to create (instantiate) an
object of the defined type.
To support definitions for identity, attributes, and operations, a UML class definition provides an icon with three
predefined compartments to contain and organize this information: name, attributes, and operations. These
compartments (see Figure 5-4) correspond to the common elements of a class definition. In addition, UML
supports user-defined compartments so that the modeler can add project-related information or anything else that
she finds useful.
Figure 5-4: Three predefined class compartments.
When a class is presented on a Class diagram, the name compartment is the only compartment that must be
visible. The attributes, operations, and user-defined compartments may or may not be displayed, depending on the
purpose and goals for presenting the diagram. Figure 5-5 illustrates the available options for presenting the class
compartments.
Figure 5-5: Valid presentation options for classes.
Hiding the other compartments does not change the fact that they exist. It merely enables you to keep the people
who are reviewing your Class diagram focused on the elements about which you need their insights. Many
modeling tools offer this flexibility with simple settings to display or hide compartments and elements as you wish.
The compartments other than the name compartment are simply lists. In fact, the attributes compartment, the
operations compartment, and user-defined compartments all derive from the ListCompartment metaclass. In all
list compartments, the name of the compartment may be placed at the top of the compartment, but since the
attributes and operations compartments are standard, we usually leave off the name and rely on position within the
class icon as illustrated in Figure 5-5. The name compartment is at the top. The attributes compartment is directly
below the name compartment, and the operations compartment is directly below the attributes compartment.
<Day Day Up>
<Day Day Up>
Modeling the Name Compartment
The name compartment provides a means to uniquely identify a class using a noun or noun phrase like Venue,
Event, or PricingStrategy. Figure 5-6 shows three classes. Each class rectangle is divided into three
compartments. The name always resides in the topmost compartment. But remember that you may display the
name compartment by itself.
Figure 5-6: Classes with names only.
Class name
The name of a class is very important. The name is the primary means for people to recognize a fundamental
resource in the model. The name should be an accurate and concise descriptor for the type of object represented
by the class. The name is nearly always a singular noun or noun phrase such as Venue, Event, or PricingStrategy.
The exceptions to this rule include classes that represent collections of objects, such as Agents, where an instance
or object of this type is in fact a list or collection of people-type objects who are associated with a Venue as its
"agents". You could think of it like a list that you keep on file with the Venue so that when you schedule a new
Event you can easily contact all the agents.
The capitalization rules for a class name typically correspond to the standards established by your organization for
the targeted programming language, that is, the language that will be used to code the application. Since the code
generated from these names usually does not support spaces in the name, it is a good idea to use underscores or
hyphens or simply no spaces between the words, whichever method is dictated by your programming standards.
Every modeling tool that I know of will generate class names (and attributes and operations) exactly the way you
type them into the Class diagram. Sticking to the standards early in the modeling effort prevents reworking the
model later on.
Although it is not a part of UML notation, a written definition of the class can be very valuable. A written definition
can quickly put to rest much of the debate regarding what properties should be included in the class definition.
Much of the confusion in modeling comes from the fact that participants in the project each have different
preconceived ideas about the meaning of each model element. In the theater example, for instance, one person
could assume that an event means a one-time performance. Another modeler assumes that an event is like a play
or concert with many performances. Still another assumes that an event refers to a marketing campaign.
As an illustration, I heard once that Eskimos have more than a dozen different words for what we call "snow". My
immediate reaction was to ask "Why so many words?" The answer lies in their need to understand snow. Their
survival depends on their ability to adapt to and use the snow effectively. They need to understand the differences
between snow that they can walk on, snow that they will sink into, snow that hides ice beneath, snow that can be
used to build shelters, snow that foretells a serious storm, and much more.
This is true for people who work with the same concepts every day. I once went to work for an insurance company
thinking that I knew what an insurance policy was; foolish man that I am. During the rewrite of the insurance
system, I had to collaborate with people from the sales, billing, and claims areas of the company. I never dreamed
that there were so many unique ways to view an insurance policy. More than that, all of the perspectives were
completely reasonable given the purpose that each participant had in mind. Therein lies the key. Purpose drives
the definition of an object. The purpose of an object may be different within different systems or applications.
An accurate definition of the purpose of the class drives every decision about the class during the modeling
process. The purpose explains why the object is part of the subject area and why it is important to the project. An
accurate definition of the purpose reduces or eliminates debate. In practical terms, an accurate definition can
guide the selection of properties that support the purpose of the class. This approach, that is, using the definition
as the scale on which to weigh the value of each property, helps ensure high cohesion in the class, a primary
measure of quality for the model. (Cohesion is discussed in Chapter 4.)
A little care in this early stage of modeling can pay large dividends throughout the rest of the modeling process.
Alternatively, poor naming and definition breed needless debate and wasted time.
The following are some examples of poor class names:
Scheduled_Show
Cancelled_Show
Event_with_no_Shows
Exempt_Employee
Non-exempt_Employee
These names embed attributes of the objects in the name. A better way to name them would be to refer to the
object Event and provide access to the attributes that can be used to distinguish events from one another. In other
words, separate the identity of the type of object (Event) from attributes that describe it (Show.status,
Event.nbr_of_shows, and Employee.exempt_status), as illustrated by the classes in Figure 5-7.
Figure 5-7: Separating identity from attributes in a class description.
I explain the entire notation to define the attributes in the "Modeling the Attributes Compartment" section later in
this chapter. For now, simply note the difference between defining what an object is and identifying what you know
about it. The name defines identity and purpose. The attributes and operations define knowledge and capabilities.
Now you might want to challenge me regarding the class names Exempt_Employee and Non-
Exempt_Employee. You would be right to do so. They could actually be valid in the right context. In fact, UML
provides a mechanism called specialization to handle exactly this type of situation. The rules for when and how to
apply specialization are very well defined. I'll cover the UML definition of specialization and the associated rules for
handling this situation in Chapter 6 when I explain inheritance.
A class name must be unique within a package. But the same class name may occur in multiple packages. To
clarify which class you mean to reference you must qualify the class name with the name of the package that owns
it. The format for a fully qualified class name is Package_Name :: Class_Name, as shown in Figure 5-8 in the fully
qualified names Scheduling :: Event, Sales :: Event, and Contract_Admin :: Event. The two names are separated
by double colons. The phrase "class path" is also used to mean a fully qualified class name. "Path" refers to the
path through one or more nested packages to access the class. In Figure 5-8 the package names are Scheduling,
Sales, and Contract_Admin.
The three classes in Figure 5-8 are three distinct definitions even though they all share the class name, Event. This
redundancy often happens when systems are worked on by different teams or developed as parts of different
projects, or when integrating in-house and vendor products.
Figure 5-8: Fully qualified class names.
An unqualified class name, for example, Event, is interpreted to mean a class defined in the current package or a
class that has been imported.
If the class is imported, you do not need its path (package name), because the import action defines the package
name (access path) for all classes in the package. For example, the theater sales application needs access to the
seating arrangements defined in the VenueManagement package. The sales application can simply import the
entire VenueManagement package and have access to any or all of the classes defined in it.
The fully qualified name is needed only if the current package and the imported package both have a class by the
same name. For example, the Sales and VenueManagement packages both define a Seat class. Classes within
the Sales package would then need to fully qualify the VenueManagement Seat class as VenueManagement ::
Seat.
If the class is referenced but not imported, you must use the path name. A reference does not first establish the
access as an import action does, so the path must be explicitly defined. For example, the Scheduling system just
needs access to the Venue class. So the scheduling application references the Venue class using the fully
qualified name VenueManagement :: Venue.
Stereotype
UML enables you to further define a class using a UML stereotype, which is yet another way to identify how a class
is used in a design. For example, when modeling a business application it is common to draw a distinction between
classes that describe entity elements and those that describe control elements. An entity element describes
objects that are part of the subject matter represented by the Class diagram, such as venues, events, and seats.
Control elements typically represent specialized pieces of software that manage the behavior of some part of the
application, such as screen navigation or scheduling. UML models a stereotype by enclosing the name in
guillemets (French quotation marks) as in entity or control. If you can't map the specific keyboard characters it
is acceptable to use two less than (<) and two greater than (>) symbols, such as entity.
Cross-Reference Stereotypes are covered fully in Chapter 3 under "UML Extension Mechanisms."
A class stereotype is not part of the class name and does not generate any code for the class. The intent of a
stereotype is to bring consistency to the treatment of common elements in UML diagrams. Stereotypes do so by
defining a purpose and a limited number of expected properties for the set of model elements (in this discussion
that means classes) that share the same stereotype.
For example, every class with the entity stereotype is understood to play a very specific role within the system
design. That is, each entity class represents a resource in the real world, outside of the software. An entity class
contains properties that describe its features and their current condition (their state). To protect its integrity, an
entity type of class also contains behaviors that control access to those properties. Finally, entity classes typically
have little or no knowledge of their surroundings other than their immediate relationships. This limited knowledge is
part of what makes them so highly reusable. For example, a venue is an entity, a resource used by the theater
system. No matter what the theater system uses a venue for, a venue object provides all of the same features and
capabilities like capacity, seating, lighting and sound support, and so on.
In contrast, a class with a control stereotype owns almost no information about itself. It represents a behavior
rather than a resource. Further, a control-stereotyped class is more concerned with directing the behavior of other
objects and has almost no behavior of its own. The contrast between entity and control stereotypes is
summarized in Table 5-1.
Table 5-1: Comparison of entity and control Stereotypes
Stereotype Knowledge Responsibilities
Entity Knows only about itself and its immediate
relationships.
Must preserve its own integrity regardless of
where or when it is used.
Control Knows only about the resources (other
types of objects) that it needs to
manipulate or direct.
Directs the use and behavior of the
resources and other software elements at its
disposal.
To apply this additional level of definition to the class, the UML places the stereotype notation at the top of the
name compartment above the name. The stereotype may be applied in either of two forms: the stereotype name
in guillemets (), or a graphical symbol. The symbols, also called icons, are a circle on a straight line,
representing the entity stereotype, and a circle "arrow", representing the control stereotype. In Figure 5-9, the
Scheduler class is designated as a control element and the Event as an entity element. Notice how in the leftmost
version of each class the words entity and control are enclosed in guillemets at the top of the name
compartment.
Figure 5-9: Four ways to model classes with stereotypes.
The two circular icons are alternative notations for entity and control stereotypes. The icons can be used with or in
place of the stereotype labels. The icons may even be used by themselves, replacing the class rectangle symbol
altogether.
NoteThese icons were absorbed from the Object-Oriented Software Engineering method by Jacobson,
Christerson, Jonsson, and vergaard.
The following examples using the utility and enumeration stereotypes further illustrate the versatility and
timesaving aspects of the stereotype concept for modeling systems.
Utility class
A utility class has no instances. Instead, it represents a named collection of static (class-scoped) attributes and
operations. In other words, a utility acts a bit like a dictionary on your desk. There is only one copy and everyone
references that one copy. A common use for utility classes is to hold common functionality used throughout the
system. For example, the Math class in Figure 5-10 provides basic mathematical functions that could be used
virtually anywhere in a system.
Figure 5-10: Utility classes have no instances and contain only static operations.
Enumeration
An enumeration is a user-defined datatype that defines a set of values that don't change (constants). Figure 5-11
shows the UML VisibilityKind enumeration used to define visibility throughout the UML specification. It defines the
valid set of values for setting the scope of access on attributes, operations, and other model elements. Each entry
is a literal, a static string of text like "public" that represents a valid option for some value.
Figure 5-11: An enumeration class defines a set of literal values, usually used for validation.
Properties
Below the name inside the name compartment, UML also allows you to add properties. Properties are simply
pieces of information about the class that do not fit easily into one of the predefined compartments or elements.
For example, you might want to add a "development status" to let team members know whether the class
description is complete, under revision, finalized, and so on. You could also add audit details such as who last
worked on the class, history of changes, and a version number.
TipIf there is a lot of this type of information about the class, you can also create a user-defined compartment
to hold the properties. User-defined compartments are described fully in the "Modeling User-Defined
Compartments" section later in this chapter.
Properties are expressed as a tag-definition/tagged-value pair, such as author="Tom", and enclosed in a single
pair of braces ({}). If there are multiple properties, simply string them together, separated by commas, inside the
same pair of braces.
Cross-Reference Tagged values are described fully in Chapter 3.
Figure 5-12 adds the properties Author="Tom", Last_updated="09-18-02", and Approved to the Event class.
Author, Last_updated, and Approved are tag definitions, names of properties. "Tom" and "09-18-02" are tag values
associated with the tag names. The Approved property is a Boolean tagged value, which is expressed using the
presence of the tag name to indicate true, and the absence of the tag name to indicate false. So the Approved tag
in Figure 5-12 is visible to reflect a true value. The word Approved would not appear if the Boolean value were
false.
Figure 5-12: Examples of properties using tagged values.
UML 2.0
UML 2.0 has reorganized the definition of a class to align it more closely with the MOF. The UML 2.0 portions of
this chapter step through the UML 2.0 specification identifying the key elements of the class definition and
highlighting significant changes from UML 1.4. I use this same approach in each chapter on UML diagrams, and
often for individual topics within a chapter.
If your goal is to learn the UML diagrams quickly so that you can get busy modeling, I recommend that you skip the
UML 2.0 sections. The differences between the UML 1.4 and 2.0 notations are fairly straightforward, but the 2.0
sections provide a lot of specification detail that goes beyond the nuts and bolts of drawing the diagrams. Once you
become familiar with the diagrams, the notations, and the vocabulary, then return to these sections and tackle
them one at a time.
To give the following discourse a context, I'll quickly review the UML 2.0 architecture. (For an in-depth review of the
architecture read Chapters 2 and 3.) UML 2.0 has two distinct layers, the Infrastructure and the Superstructure.
The Infrastructure provides the foundation for all of the MDA components. The Superstructure defines the UML
language and notation.
The Infrastructure is divided into four packages: Abstractions, Basic, Constructs, and PrimitiveTypes. Most of the
elements used for modeling first appear in the Constructs package. But the Constructs package relies on the
PrimitiveTypes, Abstractions, and Basic packages in much the same way that a book relies on rules of grammar
and an alphabet.
The Superstructure relies on the essential concepts defined by the Infrastructure to build the concepts for
constructing UML diagrams. The Superstructure is divided into packages for structural, behavioral, and
supplemental diagrams. These three packages break down into packages for each UML diagram or concept, as in
the Actions package. Each package provides a metamodel and definitions for each class in the metamodel.
In these UML 2.0 sections, I reference the packages within the Superstructure to review how classes are defined.
As you walk through the Superstructure a few times, you will become increasingly familiar with the structure and
the concepts. This particular UML 2.0 section covers only the concept of a class as a container for other model
elements. Subsequent sections in this chapter will add attributes and operations.
The formal definition for a class in the UML glossary states that:
A class describes a set of objects that share the same specifications of features, constraints, and semantics.
(UML 2.0)
This is a good working definition. But for modeling purposes this definition needs to be a bit more rigorous. The
definition must work not only in conversation, but also for representing a class in a diagram. Classes are first
defined in the Superstructure::Kernel ::Classes package (note the use of the fully qualified class name to describe
the location of the class definition within the specification). In Figure 5-13, the hollow triangle on the end of the
connecting lines is the UML inheritance symbol. So by looking over the diagram in Figure 5-13 we see that the
class Class inherits from the class Classifier, which inherits features from Namespace, PackageableElement, and
RedefinableElement.
Figure 5-13: The ancestry of the definition for Class.
This definition is almost the same as in UML 1.4. But UML 2.0 adds the rule that a classifier may be a member of a
package. While this was assumed in UML 1.4, it has been made explicit in UML 2.0. By inheriting from Classifier,
Class incorporates a number of features already defined by other elements of the specification.
As a subtype of Namespace, a class may contain NamedElements. Since a class is also a NamedElement, a
class can be a member of another class. For example, a class may be declared within the scope of another
class as are inner classes in Java.
As a subtype of PackageableElement, a class may be a member of a package.
As a subtype of RedefineableElement, a class may be specialized, just as Class specializes Classifier. For
example, an AssociationClass inherits and specializes the features of both a class and an association to
create a new type of model element for capturing information about a relationship. See Chapter 6 for a
complete description of association classes.
In UML 1.4, some of the key features, attributes, operations, and associations that are generally associated with a
class were actually defined for classifiers and then inherited by a class. In UML 2.0, these features are assigned
directly to the class. Specifically, a class may possess structural features (attributes), and behavioral features
(operations). Attributes and operations become owned features of a class in that they reside within (are
encapsulated within), and travel with the class. Figure 5-14 illustrates this relationship using the lines (associations)
connecting the Class icon to the Property and Operation icons. I'll explain the terms property and attribute in just a
moment.
Figure 5-14: A class may contain nested classes, attributes, and operations.
OMG 2.0 (modified)
This chapter covers attributes and operation in the sections titled "Modeling the Attributes Compartment" and
"Modeling the Operations Compartment."
Figure 5-14 also states that a class can contain classifiers. In other words, a class can contain interfaces,
associations, signals, enumerations and more. For a complete list of classifiers, see "Appendix E, Classifiers
Taxonomy" in the UML 2.0 specification.
One significant structural change in the definition of a class is the addition of the concept of a Property. UML 1.4
used the Attribute class to define data owned by a class. But since data may be used to describe a variety of model
elements other than classes, it made sense to define a concept, Property, that contains information, and then use
that same concept wherever it is needed. When a property is owned by a class it is interpreted as an
ownedAttribute (see Figure 5-14).
UML 2.0 does add a new concept called a Port, found in the Superstructure :: CompositeStructures :: Ports
package, and illustrated in Figure 5-15. A port is both a ConnectableElement and a Feature. As a Feature, a port
can become part of a class definition. As a ConnectableElement, a port provides the means to connect two
elements of the model. Compare this idea of a port to something like airlocks on submarines or spacecraft. When
two ships need to connect, they only need to know whether the airlocks on the two ships are compatible. How big
the craft is or what technology or design is involved in each craft is completely irrelevant. If the connectors can
attach properly, the ships can dock.
Figure 5-15: Adding ports to the class definition. OMG 2.0
In a similar manner, ports provide the "airlocks" to connect objects. A port is a class' gateway to the outside world.
The addition of ports is an attempt to encapsulate a class from the technology in which it is implemented. By using
ports, a modeler is able to create a class definition that may be implemented in any programming environment, as
long as the connections conform to the definitions of the ports.
So whether one object is coded in Java and the other in C++ should not matter. Obviously, we are not quite there
yet, but that is the goal of adding ports to the class definition, to create opportunities to reuse a software
specification by rethinking how we define software requirements like connectivity.
The next section of this chapter continues the description of the UML 1.4 specification for classes. Each new topic
in this chapter is followed by a description of UML 2.0 specification for the same subject area.
<Day Day Up>
<Day Day Up>
Modeling Visibility
Visibility is applied to both attributes and operations in a class. Since this concept applies equally to attributes and
operations, I'll cover the concept here, and then demonstrate how to apply it in the descriptions of attributes and
operations that follow.
Visibility refers to the scope of access allowed for a member of a class. Scope refers to specific regions within the
total system. UML visibility or access levels map to similar visibility designations in most OO programming
languages as follows:
Private scope: Within a class
Package scope: Within the same package
Public scope: Within a system
Protected scope: Within an inheritance tree
To understand visibility it is helpful to comprehend the concept of a UML namespace. A namespace is a UML
element that can be named (inherits from NamedElement), and can contain other NamedElements. A UML class
is a namespace that can contain NamedElements in the forms of attributes and operations. A package is a
namespace that can contain classes and other packages. As namespaces, both classes and packages can
control access to contained elements by assigning a visibility value.
As I explain each visibility in the following pages, note the symbols used to designate each visibility level, displayed
in Table 5-2.
Table 5-2: Visibility Symbols
Visibility Level Symbol
Private -
Package ~
Public +
Protected #
As with most UML concepts, there is latitude in how you choose to represent visibility. The UML suggested
character symbols for each visibility type are included in the following explanations. Some vendors have chosen to
use colors or images, such as a closed padlock to identify private access.
Private visibility
UML definition: "A private element is only visible inside the namespace that owns it." (UML 2.0)
In the context of classes, private (-) visibility limits access to objects of the same class. For example, private
attributes of Class B in Figure 5-16 can only be accessed by operations performed by objects of Class B. They
would not be accessible to Class A, other classes in the same package, or to any classes in Package 2, or
elsewhere in the system. Contrast this with the other visibility values described later in this section.
Figure 5-16: Private elements of Class B are visible/accessible only to objects of Class B.
TipIf you adhere strictly to encapsulation, all attributes should use private visibility because all of the data that
an object owns should be hidden within the object, accessible only through operations. The exceptions to
this are inherited attributes that are covered by the protected visibility value (covered later in this section).
Package visibility
UML Definition: "A package element is owned by a namespace that is not a package, and is visible to elements
that are in the same package as its owning namespace." (UML 2.0)
That is, package (~) visibility allows access by other objects in the same package, regardless of the class they
belong to. For example, in Figure 5-17, let's say that Class B defines an operation with package visibility. Package
visibility allows an operation in Class A, and objects of any other class in Package 1, to invoke the package-level
operation in Class B. But the operation remains inaccessible to objects in Package 2, or any other part of the
system.
Figure 5-17: The package-visible elements of Class B are visible/accessible to all objects in Package 1.
Public visibility
UML Definition: "A public element is visible to all elements that can access the contents of the namespace that
owns it." (UML 2.0)
Public (+) visibility allows access by objects of all other classes in the defined namespace anywhere in the system.
As Figure 5-18 shows, as long as an object can "see" the package that contains the public element (an attribute or
operation), it can access that element.
Figure 5-18: The public elements of Class B are visible/accessible to objects in the same system regardless
of the package they reside in.
Protected visibility
UML Definition: "A protected element is visible to elements that have a generalization relationship to the
namespace that owns it." (UML 2.0)
Protected (#) visibility allows access by subclasses. In generalizations (inheritance), subclasses must have access
to the attributes and operations of the superclass so that they can inherit these features. This is true whether or not
the subclasses reside in the same package. For example, in Figure 5-19, objects of Class D are allowed access to
the protected attributes and operations of Class B because Class D is a subclass (specialization) of Class B.
Figure 5-19: The protected elements of Class B are visible/accessible to subclasses of Class B regardless of
where they reside.
NoteCheck your programming language implementations for protected visibility because the definition varies
across languages. For example, in Java protected also allows access by objects in the same package.
The net effect of Java's implementation is a blend of package and subclass level visibility.
NoteIn circumstances where a named element ends up with multiple visibilities, for example by being
imported multiple times, public visibility overrides private visibility.
Protected access is especially valuable when you consider that a great deal of object-oriented programming is
accomplished by extending existing libraries. For example, while writing an accounts receivable application, I might
define an Account class that contains my customer's personal billing information. Later, while working on a
marketing application, I am asked to enhance the system to handle different classifications of accounts for
marketing purposes. To do so I need to specialize the Account class. But marketing and accounts receivable are
in two different domains.
One solution is to make the features of the Account class public. But that means that any object in the system can
access the features without using an operation that can validate the access. I could make the Account features
private to prevent access but that would also prevent inheritance, since inheritance is a form of access. The only
solution is a compromise. Allow access outside the class, but only to the classes that need to inherit from it.
To standardize these visibility definitions the UML 1.4 authors created a class called VisibilityKind. The VisibilityKind
class pictured on the right in Figure 5-20 is a set of the valid values for visibility. In addition, UML 2.0 assigns a
visibility to every NamedElement. So every model element that extends NamedElement, such as classes,
attributes, and operations, has a visibility designation.
Figure 5-20: VisibilityKind and NamedElement classes.
OMG 2.0
<Day Day Up>
<Day Day Up>
Modeling Multiplicity
Multiplicity, like visibility is a concept used with a number of UML model elements, most notably with attributes and
associations. Multiplicity specifies the number of values that may be associated with a model element.
Multiplicity is modeled as a value expression. When multiplicity is used in a text string like an attribute, the value
expression is enclosed within square brackets ([]). When multiplicity is used to adorn a diagram notation like an
association, it has no enclosing brackets. Multiplicity can express a range of values, a specific value, a range
without limit, or a set of discrete values.
Range of values
A range of values includes a lower and an upper value separated by two periods, as in [0..5] or 0..5, zero
through five inclusively, and [6..10] or 6..10, six through 10 inclusively. Figure 5-21 represents an attribute
called performer that may contain values for 1 to 20 performers.
Figure 5-21: Modeling a range for the number of values associated with an attribute.
Specific value
When the upper and lower values in a range are the same, the UML allows the use of the upper value by itself. So
the multiplicity [2..2] can be displayed instead as [2], as shown in Figure 5-22 where the manager attribute can
hold exactly two Venue_Manager references.
Figure 5-22: Using the upper value when the lower and upper range values are the same.
Note that while this abbreviated form is valid, you should be careful when replacing [1..1] with [1]. One of the
most common errors in modeling is forgetting to ask whether the lower value should be zero. A lower value of zero
as in [0..1] indicates that the item is optional. A lower value of 1 as in [1..1] or [1] indicates that the value is always
present and required. In my experience the lower bound is zero the vast majority of the time.
Range without limit
When the upper value is unknown or unspecified, the UML uses the asterisk (*) in place of a number value. The
asterisk appears as the upper value as in [1..*], which means one or more. The range [0..*] means zero or
more. The asterisk by itself [*] also means zero or more. Figure 5-23 shows the price_tiers attribute set to one or
more.
Figure 5-23: Use an asterisk to signify "or more", meaning no upper limit.
Set of discrete values
In UML 1.4, a set of discrete values is separated by commas, as in [2, 4, 6]. To date, UML 2.0 submissions
seem to have left out this option, but it will likely be included in the final version.
Ordering
UML also supports the option to specify the ordering of the elements counted by the multiplicity. The ordering is
placed within curly braces ({}) after the multiplicity value, as shown in Figure 5-24. Ordering is actually defined as
a Boolean property called isOrdered, so if the set of values is not ordered, the property is not shown.
Figure 5-24: Multiplicity ordering.
In the specification and other places you will also see {ordered}. Technically, a Boolean positive value is
represented by the name of the Boolean tag, in this case, isOrdered. The other form appears to be a carryover
from previous versions of the UML. Since most modeling is done using a tool, you will get whatever form the tool
vendor decided to provide when you select the ordered option.
UML 2.0
The Superstructure :: Kernel::Multiplicities package defines a MultiplicityElement as having an optional lower value
and an optional upper value, as well as two attributes, isOrdered and isUnique, pictured in Figure 5-25. The
isUnique attribute is new in UML 2.0. Uniqueness in this instance refers to the values that the multiplicity refers
to. For example, a multiplicity might be that there may be zero to 5 values associated with this attribute or
association. A value of true (the default) for the attribute isUnique states that there are no duplicates in the set of
values. A value of false for the attribute isUnique states that there can be duplicates in the set of values.
Figure 5-25: Multiplicity associated with any TypeElement.
OMG 2.0
UML 2.0 specifies the following syntax for declaring the multiplicity for a model element:
multiplicity_range ::= [lower '..'] upper
lower ::= integer | value_specification
upper ::= integer | '*' | value_specification
The lower and upper values may be any value specification, including expressions, literals, and instance values
(references to objects). The upper value is always required. The lower value is required when it is different from
the upper value. When no specific upper value can be defined, the asterisk may be used to indicate that there is no
upper limit to the value.
Along with the multiplicity values, multiplicity can designate the ordering and the uniqueness of the values in the set
bounded by the multiplicity values. The syntax for ordering and uniqueness is as follows:
[ '{' <order_designator> [, <uniqueness_designator>]'}' ]
<order_designator> ::= ordered | unordered
<uniqueness_designator> ::= unique | nonunique
The isOrdered attribute is a Boolean value used in conjunction with a multi-valued multiplicity. It specifies
whether the values in an instantiation of this element are sequentially ordered. The default value is false.
The isUnique attribute is a Boolean value used in conjunction with a multi-valued multiplicity. It specifies whether
the values in an instantiation of this element are unique. The default value is true.
The isOrdered and isUnique attributes are modeled as properties inside curly brackets ({ }). Figure 5-26
illustrates the use of both ordering and uniqueness where both values are true. In an attribute declaration these
properties follow immediately after the multiplicity value.
Figure 5-26: Modeling ordering and uniqueness with multiplicity.
The isUnique and isOrdered attributes describe the structure of a collection. For example, the multiplicity can
describe a set of values for an attribute or a set of references in an association. The implementations for these sets
must conform to the rules for the set defined by the values of isUnique and isOrdered. The unique combinations
of these two attributes define the types of collections that may be used to implement the sets following the rules
illustrated in Table 5-3. The exact implementation mechanism for the collection will depend on the resources
available through the implementing programming language.
Table 5-3: The Use of Properties for Collection Types
isOrdered isUnique Collection type
false true Set
true true OrderedSet
false false Bag
true false Sequence
<Day Day Up>
<Day Day Up>
Modeling the attributes compartment
The attributes compartment contains definitions for all the information that an object owns. Like the other
compartments, it is simply a list of like items, a list compartment. It differs from other compartments in two ways. It
may only contain attributes and it always appears in the same relative location within the class icon, just below the
name compartment. The attribute compartment contains all the information that an object can own.
Modeling an Attribute
An object can own three types of information. First, an object must know about itself, namely its own structure and
its own current condition, called its state. Second, an object is aware of its immediate relationships. Third, an object
is sometimes made responsible for overseeing specific information, much like a steward or custodian.
An object can tell you about itself. In Figure 5-27, Venue can tell you its seating capacity and its current status, that
is, open, closed for holiday, closed for repairs, or reserved for private engagement. Event can tell you its start and
end dates, the number of shows that have been scheduled so far for the event, the number of shows that the
contract states may be scheduled, and its current status, that is, tentative, contracted but not scheduled,
scheduled, completed, or cancelled. Seat can tell you its location within the venue and its current condition
(disabled or available for use).
Figure 5-27: What an object knows about itself.
In order for an object to do work, it typically needs to interact with other objects. To do so, a class must define the
valid set of relationships and the rules for establishing and breaking those relationships. For example, when a
project team is first established, the members are assigned tasks. Often those tasks are interrelated. Members of
the team record the contact information of other members, like phone numbers and e-mail addresses, so that they
can collaborate.
Likewise, classes need to define a means for each object to contact other objects so that they can collaborate.
The class defines an attribute that can contain a reference to another object. Each type of reference requires a
different attribute. Keeping with the team member example, a developer might keep references for a project
leader and for a database administrator. Each attribute points to an employee, but each attribute refers to an
employee for a unique purpose.
Alternatively, a reference may be to a collection of objects, all for the same reason. For example, a member of the
team may keep a reference to the list of fellow team members. In this case, a single attribute holds multiple
references. In UML, this is modeled using multiplicity. In a programming language, this is accomplished with an
array or some type of container class like a Java Collection, such as a Vector.
Today most modeling tools provide some help for setting up these reference attributes. They do it based on
associations (discussed in Chapter 6). For example, when an event is scheduled at a venue, the event needs to
know where it will be held. In a manual system, the manager might write the venue name on the contract for the
event. In a similar manner, the Event class needs to include a place to "write" the reference to the venue so that it
can collaborate with the venue to set up the performances. For each relationship on the class diagram, the
modeler (or the modeling tool) must generate a reference attribute like the one shown in Figure 5-28.
Figure 5-28: Add the reference attribute so that the event can collaborate with the venue.
An object can also own information that the object is not directly responsible for either creating or maintaining. For
example, a System Event Log has to track error conditions encountered during the execution of the system. The
log does not generate these system events or have any control over them. It simply provides a place to record
them.
Regardless of the type of attribute, each attribute needs to be defined to the level at which the application can
insure the integrity of the attribute and of the system in which it is used. To accomplish this, a UML attribute
definition includes the following elements:
Visibility
Derived (true/false)
Name
Data type
Multiplicity
Default value
Property string
Class-level versus instance level designation
Attribute notation
These attribute definition elements are commonly expressed in a single text string using the following syntax:
[visibility] [/] name [: type] [multiplicity] [=default]
[{property-string}]
The attribute definition string is a handy way to document the features of an attribute. However, tools typically also
offer a form containing a separate field for each feature. Using this form, the tools can offer help in the form of
drop-down lists and defaults to ease and speed up the modeling process. Figure 5-29 shows an attribute definition
screen from MagicDraw 6.0.
Figure 5-29: Sample attribute-entry form in a modeling tool.
No Magic
Software only works if it has all the information it needs. By definition, all the information in an object-oriented
system is contained within objects as attributes. The elements of an attribute definition help insure that all of the
facts have been evaluated and explained. The rest of this section defines and describes the use of each of these
elements.
Visibility
[visibility] [/] name [: type] [multiplicity] [= default] [{property-string}]
Earlier in this chapter I explained the various levels of visibility. I also reinforced the concept that encapsulation
states that all of the attributes of an object should be private. Figure 5-30 models seven attributes for an event. All
the attributes are set to private using the minus sign symbol (-) in front of the attribute name.
Figure 5-30: Assigning private visibility (- ) to attributes to enforce encapsulation.
In the initial stages of analysis, it is usually easiest to simply default all attributes to private (- ) visibility. Later, if you
find a compelling reason to change it you can always do so.
Derived
[visibility] [/] name [: type] [multiplicity] [= default] [{ property-string }]
A slash (/) in front of an attribute name identifies the attribute as containing a derived value. The absence of the
slash indicates a base value. A derived value is one that's computed, or figured out, using other data and a rule or
formula. A base value must be provided because there is no other way to obtain the value. When an attribute is
determined to be derived, there are more design decisions that need to be addressed regarding the handling of the
data, so the derived flag is used as a reminder to the modeler until there is time to resolve the handling of the data.
Base values are designated by the absence of the derived symbol.
For example, a theater employee might need to create a report detailing events that are scheduled. The report
needs to provide the name of each event as well as the start and end dates of the events. The name attribute
defines a base value because the name cannot be calculated or figured out by any rules. It must be provided by a
user. The start_date is also a base value. The end_date however, can be calculated using the event duration and
the start date. So in Figure 5-31, a slash is placed after the visibility symbol and before the attribute name to
indicate that end_date represents a derived value.
Figure 5-31: Identifying base and derived attributes.
Depending on factors like frequency of access and cost to calculate the derived value, you might choose not to
store the end_date value at all because you can calculate it at a lower cost than storing it.
In some cases, the calculation is very costly, access is frequent, and timeliness is critical, while the values don't
change very often or not at all. Then it might very well be cheaper to store the derived value than to calculate it
every time it is needed. For example, I worked with a team responsible for distilling all of the weather data from
NASA weather satellites each day. The distillations were then distributed to universities and researchers around
the country. The data shipped was derived from more than a terabyte of raw data. The team had to define a
derivation strategy for virtually every attribute of the final product. When it was finished, the derived values had to
be stored and the raw data erased.
Use the slash (derived) symbol to remind you that more work needs to be done to decide on the handling of the
derived value. Once a decision is made, you can always delete the attribute if it is not stored and use only a
corresponding operation to calculate it when needed.
Name
[visibility] [/] name [: type] [multiplicity] [= default] [{property-string}]
The attribute name is required. The name must be unique within the class. Attribute names should be as
descriptive as possible to avoid confusion. Names are one place where brevity is not a virtue. Always remember
that other people may need to read and understand your code long after you are gone. Frankly, even while you
are still around, do you really want to be hounded with questions about cryptic names?
If the same name appears in multiple classes and you need to refer to both values in the same context, the
attribute name must be qualified with the class name in the form class_name.attribute_name. For example,
when the attribute status appears in both Venue and Event you would need to specify them as Venue.status
and Event.status, respectively.
Data type
[visibility] [/] name [: type] [multiplicity] [= default] [{property-string}]
An attribute type identifies a classifier (not class) that explains the kind of information that can be stored in the
attribute. A classifier may be:
A reference to a UML primitive Data Type (Integer, UnlimitedInteger, or String)
An enumeration such as Boolean
A reference to a language-specific type such as float, long, short in Java
A reference to another class in your system
For example, in Figure 5-32 the name attribute is assigned the UML Data Type String using the format name :
String. End_date is assigned a class called Date from a library of classes provided by the Java programming
language. The Date data type actually holds a reference to an object designed to represent information about a
date and time. status is assigned a reference to an application-specific enumeration called Event_Status,
which defines a set of valid literal values for event status, such as scheduled and cancelled.
Figure 5-32: Each attribute is assigned a data type.
The UML attribute definition only allows for one data type. But remember that system development is a series of
tasks encompassing gathering requirements and converting those requirements to a solution. During requirements
gathering, the data type should reflect how the client sees the data, such as dollar signs and commas, and
parentheses for negative values - ($12,345.67), for example. You could call this the external view, the way the
values look outside of the software application. During design, however, the data type needs to correspond to the
programming language and database data types for the environment in which the class will be coded, such as
float. This is the internal view, the way the information looks inside the software application. These two different
views of the required data type can give the programmer some very specific insights for coding the operations used
to capture and retrieve the attribute value/s.
The external view identifies the form that the value takes as input and output. The design-level definition defines
the internal storage requirements. The accessor methods, the operations used to put the data into the object and
take it back out of the object, are responsible for the translation between the two forms. In some instances there
may even be many external forms, as in Figure 5-33. The Ticket class defines an internal data type of float, to
match the desired programming language type, to contain a price value. But the clients want to use the value of
the price attribute in three different formats.
Figure 5-33: Internal and external data types.
So during requirements gathering, the data type captured in the attribute definition should reflect the clients'
expectations, external view. The design-level version of the model should replace the external view with the
internal representation. This is one reason the version control is so important for the modeling process.
Multiplicity
[visibility] [/] name [: type] [multiplicity] [= default] [{property-string}]
When an attribute may have only one value, you can use a multiplicity range of [1..1], the abbreviated form
[1], or even let the attribute assume a default multiplicity of 1. In Figure 5-34, I used the [1] notation, although it
is very common to use the default. An attribute may also contain more than one value. Referring to the multiplicity
notation defined earlier in this chapter, you can express, for example, that a venue contains references to two
managers, a primary and an alternate. The venue could define a manager attribute as either manager :
Venue_Manager [2] or manager [2] : Venue_Manager. The multiplicity expression may appear by the
attribute name or the data type. Technically it just needs to be somewhere in the attribute definition text string.
These expressions tell us that the attribute called "manager" is of-data type "Manager" (a reference to a Manager
object), and that the attribute may contain two [2] references.
Figure 5-34: Attribute multiplicity.
As I mentioned earlier, when an attribute contains multiple values it is usually implemented with some type of array
or container class reference. For modeling purposes, however, it can be handy to simply capture the requirement
that the reference needs to support a set of values, not just one. Once you are certain that the attribute is defined
correctly, you can resolve the design alternatives for handling the set of values.
Default value
[visibility] [/] name [: type] [multiplicity] [= default] [{property-string}]
Default values serve two very valuable purposes:
To protect the integrity of the system from being corrupted by missing or invalid values. 1.
To provide significant ease-of-use improvements for the client. 2.
For example, it is common practice to let the programming language syntax default numeric attributes to zero.
However, if the application ever attempts to divide using one of these values, you will have to handle the resulting
errors that could have been avoided easily with the use of an explicitly specified default value.
UML adds the default value to the attribute definition string using an assignment operator (=) followed by the
default value expression. The default value expression may be a single value or a string expressed in some
language like the Object Constraint Language or an implementation language. During modeling it can work
equally well to use free-form text in the default to capture what you want to do. Then return later to iron out the
specific language. However, UML does not provide any mechanism for resolving the expression language. So it is
up to the designer to provide the code to implement the rule defined in the default expression.
Default values are applied to the attribute when an object is created. They may appear in the constructor as hard-
coded values. They may be defined as class-level or static values that can be referenced in the constructor. They
may even be stored elsewhere and loaded using a static operation when the class is loaded. The concept of static
attributes is covered a little later in this same section. (The static concept applies to operations as well.)
In Figure 5-35 default values have been added to the Event attributes following the assignment operator (=). The
descriptions follow the figure.
Figure 5-35: A default value assigned to each attribute can help prevent errors and improve ease of use for
your clients.
name and start_date: There are no default values, but a value is required for both attributes. This
combination tells us that the value must be supplied (no default) and it must be supplied immediately when an
event object is created (required). Consequently, it must be an input parameter on the constructor (operation)
that creates the object.
end_date: end_date is a derived value so the default expression describes how to derive the value.
(Technically, it could also simply refer to the properties value covered next in this chapter.)
duration_in_days, nbr_of_shows_allowed, and nbr_of_shows_sched: All three attributes default
to a value of 1.
status: The event status defaults to the Scheduled value defined by the Event_Status enumeration.
venue: The venue reference defaults to whatever the primary venue is at the time. The default here is
expressed in freeform text, assuming that the designer can find a way to determine the primary Venue and
insert that logic into the Event to set this value.
To recap, a default expression may be a value or a String expressed in some language. This is one more place
where the Object Constraints Language may be used to formalize an expression. In fact, the expression
"Event.status" is actually a very simple OCL statement.
Property string
[visibility] [/] name [: type] [multiplicity] [= default] [{property-string}]
The property string is like a catchall for anything you might want to include in the definition but for which there is no
designated location. The most common use of the property string is to express the rules required to guarantee the
integrity of the attribute value whenever another object attempts to change it. Any time another object tries to alter
the attribute value, it must pass the rules established in the property string. These rules may be expressed as
constraints on the value and may even use the Object Constraint Language (OCL) defined by UML and covered in
Chapter 18. The constraints are implemented/enforced in any method that attempts to change the attribute value.
Figure 5-36 models the Event class with the properties added to the end of each attribute definition string,
enclosed in a pair of braces ({ }). Properties may be expressed as free form text, a standardized language, or
tagged values. Multiple properties are separated by commas.
Figure 5-36: Attribute properties enable you to define constraints and other facts to ensure the integrity of the
attribute value.
In Figure 5-36, the following properties are added to the Event attributes:
name: The name value must be 1 to 30 characters long. It may include spaces and punctuation (but no other
special characters).
start_date: The start date value must be later than today, that is, the system will not allow retroactive event
setups. We must also make certain that the venue is actually open when the event starts. This reveals one of
the benefits of researching the properties and constraints for an attribute. The research often exposes the
need for other information. In this case, the constraint on the start_date reveals the need for a calendar of
operation that identifies when the venue is open for operation.
end_date: Since the end_date is a derived attribute, the constraint is the same as the default. That is, they
are both the rule for deriving the value.
duration_in_days and nbr_of_shows_allowed: Both attributes simply need to have a non-zero value,
although you might want to find out whether there is a reasonable limit to either value.
nbr_of_shows_sched: This attribute must conform to the limitation established by
nbr_of_shows_allowed.nbr_of_shows_allowed is established in the contract with the performer and
cannot be exceeded without revising the contract. The lower limit is zero to allow for the fact that when the
event is entered into the system you might not yet know when you want to schedule the shows. The zero lower
limit enables you to set up the event, go home for the evening, and come back the next day to do the
scheduling.
status: The valid set of status values have been defined within a class called Event_Status. The status
attribute may only refer to one of the predefined values.
venue: It would not make much sense to schedule the event to take place in a venue that will not be open.
This constraint helps the clients make certain that everything is ready before they start scheduling.
To recap, properties enable you to define any information about the attribute that does not fit into one of the
predefined fields for an attribute. The most common use of properties is to hold the constraints that guarantee the
integrity of the attribute value throughout the object's lifetime.
Class-level attribute
Most attribute values are owned by a specific object, an instance of a class. They are called instance-level
attributes. A class-level attribute refers to an attribute that is accessible within the class. Class-level attributes are
also referred to as static attributes in some languages. Because the value is defined and stored at the class level,
every object of the class may access the value. Literally, all of the objects of the same type share the same value.
One example of the use of a static attribute is the ticket in the theater application. The ticket class needs to
sequentially number the ticket objects to ensure that there are no duplicates. The ticket class could define a static
attribute next_ticket_nbr as shown in Figure 5-37. Each time a ticket object is created, the value in
next_ticket_nbr is assigned to the ticket's ticket_nbr attribute. Then the next_ticket_nbr is
incremented on the ticket class.
Figure 5-37: A static attribute is modeled by underlining the attribute definition.
UML 1.4 stated that a static or class scoped attribute is designated by underlining the entire definition text string, for
example: next_invoice_nbr : int = 1.
As of this writing, UML 2.0 does not explicitly say that a static attribute is underlined. However, it does define all
features, such as attributes, as having a Boolean attribute called isStatic. This would allow you to define an
attribute as static. The notation will probably be updated in the final version.
UML 2.0
This section reviews the UML 2.0 specification for any changes, enhancements, or clarifications with regard to
defining attributes. Apart from the name change from Attribute to Property, most of the changes regarding
attributes are changes to the structure of the metamodel. Figure 5-38 summarizes the metamodel elements that
affect the definition of a property. The highlighted areas indicate the sources of the information that defines a
property.
Figure 5-38: A property inherits many of its features from other metaclasses.
OMG 2.0
That information includes all the items in the attribute declaration syntax:
[visibility] [/] name [: type] [multiplicity] [=default]
[{property-string}]
visibility (from NamedElement): As a subclass of NamedElement, a property inherits both name and
visibility. The valid options for specifying visibility are defined by the enumeration called VisibilityKind.
derived (/): (See Figure 5-39 and the subsequent description.)
Figure 5-39: A property describes a class, may be subsetted, and may have a default value.
OMG 2.0
name (from NamedElement): As a subclass of NamedElement, a property inherits both name and visibility.
Type (from TypedElement): As a subclass of TypedElement, a property inherits an association with a
classifier that provides its type. That is, a property may be a UML DataType (Primitive or Enumeration), a
class, signal, or any other classifier or subclass of classifier.
multiplicity (from MultiplicityElement): As a subclass of MultiplicityElement, a property may own an upper
and a lower limit for the number of values that may be contained in the property.
default (/): (See Figure 5-39 and the subsequent description.)
property-string (from Element): As a subclass of Element, a property may own other elements. These
other elements may be used to augment the description of the property. The most common additional
element is a constraint or set of constraints on the domain of values for the property.
isStatic (from Feature): As a subclass of Feature, a property owns the attribute isStatic. If isStatic is true,
then the property applies to the classifier that owns the property, not to instances associated with the classifier.
The default value is false. The attribute was formerly defined by the enumeration ScopeKind, which included
the values instance and classifier.
isReadOnly (from StructuredFeature): As a subclass of StructuredFeature, a property owns the attribute
isReadOnly. If isReadOnly is true, then the property may only be read, not written/changed. Once the property
value is set it may not be changed. This feature was formerly defined by the enumeration ChangeableKind,
which included the values changeable, frozen, and addOnly.
In addition to the features already identified, a property may define whether it is derived, whether the values of the
property is the union of other values, and how the property is associated with the classifier that owns it. Figure 5-39
introduces the property class itself with three new features, isDerived, isDerivedUnion, and aggregation, as well as
an optional association with a value specification, and other properties that subset the property.
isDerived: Specifies whether the property's value or values can be computed from other information. The
default value is false. The slash (/) in front of the attribute name designates that the attribute's value is derived
from other properties. The absence of the slash designates that the attribute represents a base value.
isDerivedUnion: Specifies whether the property is derived as the combination of all of the properties that
defined subsets of the property. For example, in the class Company the model might define an attribute,
employees. It might also define two other attributes, full-timeEmployees and part-timeEmployees. A
true value for the isDerivedUnion attribute of the employees property defines the value of the employees
attribute to be the combination of all the values of full-timeEmployees and part-timeEmployees. The
default value is false.
aggregation: Specifies the kind of aggregation that applies to the property, that is, none, aggregation, or
composition. The default value is none. The kinds of aggregation are explained fully in Chapter 6.
default: A property can be associated with a value, defined by a ValueSpecification. This value is assigned
to the property if no explicit assignment is made at the time that the property is created. In the case of a
property that represents an attribute of a class, the default value is assigned to the property when an instance
of the class is created.
subsettedProperty: This association points to other properties for which the source property defines a
subset. In the example described under the isDerivedUnion attribute, the property full-timeEmployees
would point to the property employees. (See the example that follows the next paragraph.)
The isDerivedUnion and subsettedProperties attributes may be added to the attribute declaration string using the
optional {property-string}. Each feature added to the property string is a separate tagged value in the
property string. For example:
full-timeEmployee : Vector = null {union, subsets employee}
<Day Day Up>
<Day Day Up>
Modeling the operations compartment
The operations compartment is a list-compartment containing all of the behaviors defined for a class of objects.
The default location of the operations compartment is below the attributes compartment and above any user-
defined compartments. The compartment may be suppressed. Often, modeling tools also allow suppression of
specific elements of the operation declarations within the compartment.
Within the operations compartment, it is valid to use stereotypes to label groups of operations according to their
usage (or whatever criteria are useful to the maintenance of the class). The stereotype applies to all operations
below it in the list until another stereotype appears or until you reach the end of the compartment, as shown in
Figure 5-40.
Figure 5-40: Operations compartment with stereotypes.
NoteIn all the figures in this section, the attributes compartment has been suppressed to keep the focus on
the discussion of operations.
Modeling operations
Operations define behaviors, the services that an object can provide. UML makes a distinction between the
interface to a behavior and the implementation of a behavior. The interface to a behavior is called an operation. An
operation declares the information needed to invoke a behavior. The operation is the only part of a behavior
modeled in the Class diagram.
The implementation, which is not modeled in the Class diagram, is referred to as the method. This can be a source
of confusion because many programming languages use the terms operation and method interchangeably.
Operation notation
The UML operation notation defines the elements of a class behavior modeled using the syntax:
[visibility] name ([parameter-list]) ':' [return-result] [{properties}]
In addition, UML supports the use of exceptions, pre-conditions, and post-conditions. I'll cover the notation
elements first, and then these additional operation elements.
Visibility
[Visibility] name ([parameter-list]) : [return-result] [{properties}]
Operation visibility follows the same visibility concepts covered earlier in this chapter. In the context of operations,
visibility applies as follows:
private (- ): Only objects of the same class may call/invoke a private operation.
package (~): Only objects owned by the same package may call a package-level operation.
public (+): Any object may call a public operation, as long as the calling object can access the package in
which the operation resides.
protected (#): Only objects defined within subclasses of the owning class may call a protected operation.
Name
[Visibility] name ([parameter-list]) : [return-result] [{properties}]
The name of an operation identifies a specific behavioral feature of a class of objects. To be effective, the name
should be as meaningful and expressive as possible. For example, an operation named update with a long string
of parameters would be more difficult to interpret properly than operations named reschedule, addPerformance, or
cancel.
The name does not have to be unique within a class. However, the combination of the name, parameter list, and
return result, often called the signature, must be unique within the class. (Note that this rule is not the same for all
programming-languages. Some languages do not consider the return result to be part of the signature.)
Figure 5-41 contains operation names for the Event class. Each operation definition in the figure includes the
operation visibility, an operation name, and an empty parameter list. Each operation models a behavior that an
event object supports. The listed behaviors enable us to cancel the event, reschedule the event to a new time
period, or change the duration of the event. I'll explain the Event and check_For_Conflicts operations in a
moment.
Figure 5-41: Each operation identifies a behavioral feature of the class.
Also, remember that the operations in the Class diagram will generate the operation code in your target language,
so be certain to follow the naming standards for the target language because the code will be generated exactly as
it is written in the diagram. For example, constructors are typically identified by the fact that the operation name is
the same as the class name, like the Event() operation in Figure 5-41.
Note the visibility designations in front of each operation. Whenever a class needs to make a behavior available to
other types of objects, the visibility cannot be private. Often the visibility is set to public until and unless there is a
compelling reason to limit it to package, protected, or private.
When a class behavior is only used internally, the visibility may be private or protected. Internal behaviors may be
functions shared by more than one class behavior. For example, the event needs to check for scheduling conflicts
when it is created and whenever someone tries to change its duration or start date. Rather than define the behavior
twice, once within each operation, it is easier to isolate the behavior in its own operation and call it from the other
two. Figure 5-41 models the check_For_Conflicts operation as private to restrict access to operations within
the same class.
Parameter-list
[Visibility] name ([parameter-list]) : [return-result] [{properties}]
The parameter-list is an ordered list of attributes that together define the input to an operation. The parameter-list
is optional, that is, an operation does not have to have parameters. For example, if I ask an event object to cancel
itself using the cancel() operation in Figure 5-42, it does not require any additional information. It can satisfy the
request with the knowledge it already has. However, to change the duration of the event, I have to tell the event
what the new duration value should be. I do this by adding a parameter that can hold the new value in the
parameter-list of the operation. Now when I invoke the operation, I can assign a new duration value to the
parameter value and pass the parameter along with the request. The event object receives the parameter and
uses the value to complete the operation.
In Figure 5-42, parameters are added to two of the operations. The reschedule() operation needs to know the
new date on which you want to schedule the event. This new date will replace the current value for the attribute
start_date. The setDuration() operation needs to know the new duration value that will be used to
replace the existing value in the duration_in_days attribute.
Figure 5-42: Operation parameters define the required input for the class behavior.
Each parameter is defined in the same manner used to define attributes, a name and a data type in the format
name:datatype. When using more than one parameter, simply separate the "name : datatype" pairs with
commas, for example (new_start_date : Date, new_duration : int).
CautionIf you are a Java programmer, don't let the name:datatype syntax throw you. It is the opposite of what
you are used to, namely datatype name, but it accomplishes the same purpose.
When an operation does not require parameters you still need to include the empty parentheses. Again this is
largely because the operation definition will be used to generate code and needs the correct syntax.
Return-result
[Visibility] name ([parameter-list]) : [return-result] [{properties}]
The return-result is the output of the operation. For example, when I ask the event for its name, I want it to give me
a string containing the name of the event, like the getName() operation in Figure 5-43. When I ask for the
duration, I want the event to return an integer as in the getDuration() operation.
Figure 5-43: Operation return-results define the output of an operation.
Note how different the return is from the parameters. The return specifies only the return data type. No name is
required. Also note that there is only one return, whereas there are potentially many parameters. Technically, UML
2.0 supports many return values. However, most if not all programming languages support only one return value. If
you need to return more than one result value, you will need to wrap the values up in another object and ship the
entire object back as a reference.
CautionIt is valid to have no return value. But again, your programming language might require you to say so
by using a keyword like void in the return.
The return value may be any primitive type or object (or object reference). The getDuration() operation in
Figure 5-43 returns a primitive integer value. The getStartDate() operation returns a Date object.
Properties
[Visibility] name ([parameter-list]) : [return-result] [{properties}]
The properties element allows you to add pretty much any additional information about the operation that does not
fit into one of the other predefined elements. One common use for the properties is as a description of the
implementation for the operation, as shown in the following syntax for an operation declaration:
setDuration(new_duration: int): void {the new duration may
not cause overlap with another scheduled event}
The property text describes the constraints on the performance of the operation. This is yet another occasion when
the Object Constraint Language (OCL) might be applied to lend precision to the specification. Since properties
may be defined with any language, not just OCL, it is valid to use free-form text. Ultimately the contents of the
properties become part or all the implementation logic for the behavior.
Class-level operation
Most operations are owned by a specific object, an instance of a class. They are called instance-level operations.
In contrast, a class-level operation refers to an operation that is accessible within the class rather than within an
object of the class. Class-level operations are also referred to as static operations in some languages. Because
the operation is defined and stored at the class level, every object of the class may access the operation. In fact,
objects of other classes may access the operation without referring to an instance of the class.
One example of the use of a static operation from the theater system is the operation getNextTicketNbr():
int, which returns the value of the next_ticket_nbr attribute, which also happens to be defined as static.
UML 1.4 states that a static or class scoped operation is designated by underlining the entire definition text string,
as illustrated in Figure 5-44.
Figure 5-44: A static operation is modeled by underlining the operation definition.
As of this writing UML 2.0 does not explicitly say that a static operation is underlined. However, it does define all
features, such as operations, as having a Boolean attribute called isStatic. This attribute enables you to define an
operation as static. The notation will probably be updated in the final version.
Exceptions
Those of you with a programming background might be asking, "What about exceptions?" One way to handle
exceptions is to return a value to the calling object and let it interpret that value to decide how to respond to
success or failure. The more common approach implemented by most OO languages is to throw (generate) an
exception. An exception in this technique is an object. Exception objects may be specialized into almost any form to
handle any type of error. Some languages even come with a predefined set of standard error types.
When a method throws an exception, that method is terminated and each successive method in the call stack is
terminated until the exception is caught by an exception-handling code block. That code, specifically designed to
capture exception objects, may then be enhanced to interrogate the exception object and decide how to respond.
The advantage to this approach is that it isolates error handling from the normal execution of the behavior that
generated the exception. This separation makes the code easier to understand and maintain. It also helps make
the error handling more reusable since all exceptions of the same type can be handled by common logic.
UML 1.4 does not have a notation for exceptions. It does, however, support the definition of exceptions as a type of
signal that can be passed between objects. To provide the exception information you need to use the specification
window provided by your modeling tool. Figure 5-45 shows portions of the screens used in MagicDraw 6.0 to
specify exceptions in Java and C++.
Figure 5-45: Tools support the definition of operation exceptions. No Magic
Preconditions
The term precondition is borrowed from the concept programming by contract. In a conventional contract, one
party agrees to do something or provide something if and only if the other party fulfills his part of the contract. For
example, I will give you a pair of shoes if you give me $50. If you come to me with $40 I am not obligated to give
you the shoes.
In the same manner, an operation may specify a precondition or a set of preconditions. The preconditions define
the terms that the invoking object must meet before the operation is obligated to perform its behavior. A common
example of this type of agreement can be seen in the use of parameters. An operation specifies that certain
parameters must be supplied. It may further specify constraints on the values of those parameters.
Testing of the preconditions is the first task of the invoked behavior. Keeping with the previous example, if any
parameter is not supplied or the value for any of the parameters does not satisfy the associated constraints, the
operation is not obligated to perform its behavior.
TipThis concept is also applied to Use Cases.
As was the case with exceptions, the preconditions are typically captured in a form provided by a modeling tool.
There is no corresponding notation.
Post conditions
Post conditions also come from the concept of programming by contract. As the prefix implies however, the
condition specifies something that must be true after the behavior finishes. Post conditions provide the other half of
the contract, the obligation of the invoked behavior.
To keep with the precondition example, if you give me $50 (satisfy the precondition) then I am obligated to give you
the shoes to satisfy the post condition.
In short, a post condition is a condition that must be true at the conclusion of the behavior. The process to satisfy
the post condition is implemented in the method of the operation. The method can be as simple as a request and a
response, as shown in Table 5-4, or as complicated as the example illustrated in Table 5-5:
Table 5-4: Pre- and Post Conditions in a Simple Request/Response
Step Action
Request "What is the event name?"
Precondition None
Processing Get the value of the event name attribute
Post condition The event name: "The Sound of Music"
Table 5-5: Pre- and Post Conditions in a Complex Request/Response
Step Action
Request "How much is the car insurance premium?"
Precondition Provide the make, model, year, and mileage, options included, and driving record of
drivers.
Processing Calculate the car insurance premium using the current state mandated factors (15),
historical factors (7), manufacturers' repair costs, actuarial tables for drivers in our state
Post
condition
"The car insurance premium will be $215.00 per month."
In both cases the pre- and post conditions set the boundaries that define the successful fulfillment of the operation.
In a very real sense the preconditions and post conditions encapsulate the operation, defining its correct function
without dictating any particular implementation.
TipThe method does not appear in a UML diagram, although the logic can be modeled using an Activity
diagram. Most modeling tools provide a comment or description area in the specification forms. Whatever
is entered here - freeform text, pseudo-code, or actual code - can be generated as a comment in the code
generated from the Class diagram.
UML 2.0
As was the case with attributes, the changes in the specification regarding operations are largely refinements to the
metamodel. Figure 5-46 brings together all the classes that contribute to the features of an operation. Many of
them you already encountered in the description of the UML 2.0 model for attributes, including NamedElement,
MultiplicityElement, and Feature. The highlighted areas indicate the sources of the information that defines a
property.
Figure 5-46: UML operation metamodel, part 1 of 2.
OMG 2.0
The information used to define an operation is specified in the operation declaration syntax:
[visibility] name ([parameter-list]) ':' [return-result]
[{properties}]
parameter-list:= name [':' data-type ] ['[' multiplicity ']']
visibility (from NamedElement): As a subclass of NamedElement, an operation inherits both name and
visibility. The valid options for specifying visibility are defined by the enumeration called VisibilityKind.
name (from NamedElement): As a subclass of NamedElement, a property inherits both name and visibility.
Name is simply a String. The combination of the name, parameter-list, and return-result must be unique within
a class.
parameter-list: A parameter may define information passed into and out of an operation. An operation
may use any number of input parameters and may produce any number of output parameters. Though not
supported by all programming languages, UML offers parameter direction types of in, out, inout, and return.
These options are defined by the enumeration ParameterDirectionKind.
name (from NamedElement): As a subclass of NamedElement, a property inherits both name and
visibility.
data-type (from TypeElement): Each parameter obtains its type from a classifier. For example, in
order to define a parameter that can pass in a list of show seats, I need to associate the parameter with a
classifier designed to contain a set of objects such as the Vector class in Java. The operation would look
like select (showseats:Vector).
>multiplicity (from MultiplicityElement): As a subclass of MultiplicityElement, a parameter may own
an upper and a lower limit for the number of values that may be contained in the parameter. For
example, a parameter can contain a set of one or more show seats that a customer wants to purchase.
The operation would look like select (showseats:Vector [1..10]).
return-result: Each operation may return one or more values. Each value is a parameter, so each value
is associated with a data type and a multiplicity. Technically, a parameter can have a name as well. But most
programming languages specify a return using only the data type.
CautionUML supports multiple return results. But many programming languages limit an operation return
to a single value. During analysis determine what the operation needs to return. During design
you can combine multiple values into an object and pass the one object as the return.
properties (from Element): As a subclass of Element, a property may own other elements. These
other elements may be used to augment the description of the operation. The most common additional
element is a constraint or set of constraints on the behavior of the operation.
isStatic (from Feature): As a subclass of Feature, a property owns the attribute isStatic. If
isStatic is true, then the property applies to the classifier that owns the property, not to instances
associated with the classifier. The default value is false. The attribute was formerly defined by the
enumeration ScopeKind, which included the values instance and classifier. An operation is
modeled as static by underlining the operation.
Many programming languages also support the concept of exceptions as objects generated by an operation when
something happens outside the normal execution of the operation. For example, a file might not be available, or
the operation data types don't match the required object data types. Generating an exception is also called raising
an exception or throwing an exception. UML accounts for this ability by associating an operation with any number of
raised exceptions.
In addition, an operation may be declared as a query, and be assigned pre-and post conditions that govern the
proper execution of the operation. Figure 5-47 models the unique features of an operation.
Figure 5-47: UML operation metamodel, part 2 of 2.
isQuery: When the isQuery attribute is true, then the operation cannot alter the state of the system. A false
value means that the operation can change one or more attribute values in the system.
An operation may have any number (*) of preconditions and post conditions. Pre- and post conditions are
expressed as constraints. Each pre- and post condition applies only to the operation that defines it. Technically, a
pre- or post condition may be defined apart from an operation (note the 0..1 multiplicity), but without the
association to an operation, it has no meaning. Each type of condition affects a different aspect of the execution of
an operation as follows:
pre-condition: A pre-condition defines a state of the system that must be true when the operation is
invoked. The most common types of pre-conditions are tests on the valid parameters values that may be
passed to the operation. If any of the parameters values do not satisfy the pre-conditions then the operation is
not obligated to execute.
post-condition: A post condition defines that state of the system at the end of the execution of the
operation. Post conditions have to take into account both successful and unsuccessful completion of the
operation.
bodyCondition: bodyCondition refers to the minimum expected result of invoking the operation, regardless
of pre- and post conditions. bodyCondition is also sometimes referred to as the minimum guarantee.
<Day Day Up>
<Day Day Up>
Modeling User-Defined Compartments
You've already encountered three types of class compartments - name, attributes, and operations. These
compartments are so common that they are predefined by the UML. But the UML also supports user-defined
compartments. User-defined compartments provide a place to put any information that does not readily fit into any
of the pre-defined compartments. A user-defined compartment is simply another list compartment like the
attributes and operations compartments, with a name, properties, stereotypes, and sorting.
Name
A list compartment may have a name. In Figure 5-48, the name Project Info appears at the top of the user-defined
compartment. (The compartment name does not appear in the name, attributes, or operations compartments
because those compartments are predefined by UML and rely on their position within the class to indicate their
type.)
Figure 5-48: User-defined compartment with a name and tagged values (attributes and operations
compartments are suppressed).
Properties
Because the information in a user-defined compartment does not fit into the already defined elements, UML gives
you the ability to make up your own elements using tagged values. To make your own tagged values, simply
create a tag-definition/name and a corresponding tag-value, such as the team="alpha" and deadline="08-
01-02" items in Figure 5-48.
UML supports less formal properties in the form of strings, that is, simple free-form text. You can literally write
anything you want to in each string within the compartment including rules, responsibilities, exceptions raised, and
exceptions that need to be handled.
Stereotypes and sorting
The fact that you can include a lot of varied information in a compartment begs for a way to organize that
information. A UML stereotype may be assigned to each string in the compartment. The stereotype can be used to
sort the strings into a meaningful arrangement.
For example, exceptions could be grouped together, rules and responsibilities together, and behaviors that have
yet to be fully defined could be in yet another group, as shown in Figure 5-49.
Figure 5-49: User-defined compartment with properties sorted by stereotype.
UML 2.0
UML 2.0 has not changed the specification regarding user-defined compartments.
<Day Day Up>
<Day Day Up>
Modeling Advanced Class Features
So far this chapter has described the most common use of classes. UML provides some additional capabilities. A
template class, for example, supports the creation of a variety of classes using parameters to describe the specific
type of class. An interface supports the definition of a common way to interact with classes that might not be
related.
Modeling a class template
A template is not actually a class in the sense that we have used class throughout this chapter. Instead, it provides
a means of customizing a type of class using parameters, hence the alternative name parameterized class. A
template defines a type of class such as an array that may be used to store a specified type of object.
TipTemplates are commonly used in C++. Java plans to add them in JDK 1.5.
In order to actually create a usable class from a template, you must supply values for the parameters. For
example, a simple array template might require a data type for the type of object that you want to store, and the
maximum number of objects you want to store. Figure 5-50 shows a template class, TemplateArray, with two
parameters, type and qty defined in the top right corner within the dashed box. Each parameter follows the now
familiar format name : datatype. Actually I threw you a curve. The parameter type is actually a shorthand form.
Whenever the name of the parameter appears without a corresponding data type, the name of the parameter is
assumed to be the data type.
Figure 5-50: Template notation with parameters.
So if I want to store references to a group of people interested in getting a group discount to a show at my theater, I
supply the values Customer and 20. To create a useable class, I bind the parameters to the template. The result is
a class defined by the combination of the two parameters. In the example in Figure 5-51 get an array class called
Group that can hold up to 20 Customer objects.
Figure 5-51: Interface notation alternatives.
UML 2.0
UML 2.0 has not changed the specification regarding template classes.
Modeling an interface
When I defined an operation earlier in this chapter, I pointed out that UML draws a distinction between the means
to invoke a behavior and the implementation of a behavior. The means to invoke a behavior is called the operation
or operation signature. An operation signature includes the name, parameters, and return-result. The unique
combination of these elements defines an interface. The implementation of a behavior, the method, is not modeled
in a Class diagram.
Since the interface and implementation are separate, it is possible to define an interface and map it to any number
of implementations. In general terms this one-to-many type of mapping between interface and implementations is
called polymorphism. Polymorphism can be a powerful tool for building flexibility into an application's design.
TipThe formal definition of polymorphism differs slightly between languages. For example, in C++ if you don't
define your method as virtual, you can have multiple implementations in subclasses, but not have them be
called polymorphically. In Java, polymorphism is offered by default. To be precise, polymorphism is the
ability to dynamically choose which implementation should be called at runtime according to the type of
the invoked object.
An interface is a declaration rather than an actual class. As a declaration, an interface has some constraints that
classes do not, namely, the operations defined by an interface cannot have any implementation, and interfaces
cannot have attributes. The implementation is provided by the class that realizes or implements the interface.
For example, the classes shirt and perfume don't really have anything in common. In a system supporting a retail
store, however, the users want to treat both of these different types of objects as products. That is, they want to buy
them, inventory them, price them, and sell them. One solution is to add all of these operations to each class. But
as the number of different items increases, so does the likelihood that the operations might be defined differently.
The code becomes more and more complex as I try to support many different items with many different product-
related operations. What I really want is the ability to define once the set of operations that I want to use on all the
items that I view as products.
One solution is to isolate the operation signatures in a class by themselves, without any methods, that is, without
specifying how the operations must be implemented. This class that only contains the operation signatures is
called an interface. Each class that implements this interface is obligated to override all the interface operations to
provide their own methods, their own way to satisfy the operation.
Those of you who have programmed in an OO language are probably thinking that an interface sounds a lot like
an abstract class. Abstract classes are explained fully in Chapter 6. But it is important to explain here the distinction
between an interface and an abstract class.
An abstract class is a class that cannot be instantiated. What prevents it from being instantiated is one of two
things. The class is labeled as abstract to explicitly prevent anyone from instantiating it, or at least one operation in
the class has no corresponding method. In the second case, if an object was created using this class, the object
would not know how to behave when that operation is invoked.
The second case alludes to the most significant difference between an interface and an abstract class. An
interface cannot have any methods. An abstract class can have methods for all operations (when explicitly defined
as abstract), or for some but not all operations.
Another distinction between abstract classes and interfaces is the fact that abstract classes can define attributes
while interfaces cannot. In short, interfaces only define common services that must be supported by implementing
classes. Abstract classes can contain any information that is true for all classes that specialize the abstract
classes, including attributes, operations, and methods.
Interface notation
One way to accomplish this is to create a quasi class that contains only the operation signatures, like the interface
shown in Figure 5-50. I can then apply this interface to each of the classes. Now every class that implements the
interface has the same set of operations. Then the implementing classes, shirt and perfume, have to be updated
to override the operations and provide their own methods.
UML 1.4 provides two presentation options for interfaces. The first appears in the top right portion of Figure 5-51. It
looks like a class with the stereotype interface. The Shirt class realizes (implements) the interface. This
relationship is modeled with the realization symbol, a dashed line with a hollow triangle at the interface end. The
diagram is read as "The Shirt class realizes the Product interface."
The second option is modeled in the bottom of Figure 5-52. The interface is the circle attached to the
realizing/implementing Perfume class by a solid line. The size of the circle varies among tools and documents.
The important element is the circle and a solid line. Label the circle with the name of the interface.
Figure 5-52: Structure::Classes::Interfaces interface definition - Part 1 of 2.
UML 2.0
Interfaces are defined in the Superstructure::Classes::Interfaces package. Figure 5-52 shows that an interface is a
specialization of classifier, so it is a Namespace. It may be generalized and may itself be a specialization of
another interface. It can contain other elements, namely attributes and operations. An interface may also nest
other interface declarations.
Figure 5-53 shows that an interface may contain any number of attributes and operations. UML 2.0 states that the
attributes must be abstract; that is, they cannot be implemented except by the class that realizes the interface.
When an interface defines attributes, it is stating a requirement that the instantiating class should maintain that type
of information. How it does so is entirely up to the implementing class. At a minimum, the implementing class must
define an operation that provides access to the information described by the attribute, even if the attribute itself
does not exist. This is very much like the implementation of a derived attribute that the designer chooses not to
store.
Figure 5-53: Structure::Classes:: Interfaces interface definition - Part 2 of 2.
CautionCheck the syntax of the implementation language to find out whether the language supports the use
of attributes in an interface. Java, for example, does not allow instance-level attributes in an interface
class.
UML 2.0 enhances the definition of interface class to say that the operations of an interface class can define two
types of interfaces: provided and required. A provided interface is a service that the object makes available to other
objects. The MarketingPlan, in Figure 5-54, provides the price() operation which can assign a price to a product.
Provided interfaces may be modeled as a circle attached to the implementing class by a solid line as in Figure 5-
54. (This is sometimes called the lollipop notation.) An interface class can still be modeled as a class with the
interface stereotype just as was done in UML 1.4.
Figure 5-54: Provided interface - the MarketingPlan provides an interface to price products.
When an object requires access to a service, the object is said to have a required interface. In other words, the
object needs to find another object that provides the required interface. A required interface can be modeled as a
crescent or half circle, as shown in the example in Figure 5-55. The Shirt class requires the Price interface.
Figure 5-55: Required interface - the shirt needs to be priced.
When you put the two together, you get a kind of ball and socket configuration, as illustrated in Figure 5-56. The
shirt is a product that needs to be priced and the MarketingPlan provides the ability to price a product.
Figure 5-56: Interconnected provided and required interfaces.
<Day Day Up>
<Day Day Up>
Summary
Chapters 5 and 6 cover the notation for the Class diagram. The focus of Chapter 5 is on the class itself. Chapter 6
explains relationships between classes.
Class: A class is modeled as a rectangle with three standard compartments for name, attributes, and
operations, in that order, and optional user-defined compartments. The name of the class must be unique
within a package. When referring to classes with the same name but different owning packages, use the fully
qualified name in the format package-name::class-name.
Attribute: Attributes define the type of information that can be owned and managed by the type of object
defined by the class that owns the attributes. Attributes are declared using the syntax:
[visibility] [/] name [: type] [multiplicity] [=default]
[{property-string}]
Operation (and method): An operation defines how a behavior can be invoked on an object. The operation is
distinct from the method that provides the implementation for the operation. In fact, more than one method
may be defined for the same operation in different classes:
[visibility] name ([parameter-list]) ':' [return-result]
[{properties}]
parameter-list:= name [':' data-type] ['['multiplicity'
]']
Template class: A template class provides a means to define the structure of a class without specifying the
type. This technique is useful for container classes such as arrays and Vectors that may contain any type of
object. To instantiate a template class you must provide the type.
Interface: An interface class defines a set of behaviors that an implementing class must support. The
operations of an interface class cannot have any methods. The attributes of an interface class must be
abstract. That is, the attributes do not have to be declared by the implementing class as long as the
implementing class can provide access to the same information through an operation.
Visibility: Visibility defines the level of access allowed to a model element such as a class, an attribute, or an
operation. The allowed visibility values are defined in the enumeration VisibilityKind as private, public,
protected, and package.
Multiplicity: Multiplicity defines the number of values that may be assigned to a model element such as an
attribute or a parameter. The number may be expressed as a range, and enumeration, a fixed number, or an
undefined limit (*). The syntax for declaring multiplicity is:
multiplicity_range ::= [ lower '..'] upper
lower ::= integer | value_specification
upper ::= integer | '*' | value_specification
Multiplicity ordering and uniqueness: Along with the multiplicity values, multiplicity can designate the ordering
and the uniqueness of the values in the set bounded by the multiplicity values. The syntax for ordering and
uniqueness is as follows:
[ '{' <order_designator> [, <uniqueness_designator>]'}' ]
<order_designator> ::= ordered | unordered
<uniqueness_designator> ::= unique | nonunique
<Day Day Up>
<Day Day Up>
Chapter 6: How to Capture Rules about Object
Relationships
Overview
A software application requires a set of resources. To use them you need to describe each resource using a class
definition. Classes describe the types of resources, their purpose, and the features that they provide, including
attributes and operations.
But to coordinate the interaction of these resources, you need to explain how they can communicate. To
communicate, they need to be aware of one another. Just as people use various means to communicate like
phone calls and mail or e-mail, objects also need to define a means to communicate. They need to define a type
of relationship. UML relationships come in three different types: association, generalization, and dependency.
An association is a semantic relationship between two model elements. In a Class diagram, an association defines
the rules that apply to relationships between the objects defined by the participating classes. Each association
includes the rules to establish and maintain the integrity of the relationships as the relationships are created and
used by the application.
The same concept may be refined to account for objects that are actually assemblies of other objects. This
assembly type of association, called aggregation, greatly facilitates the use of complex configurations of objects.
Aggregation can also be refined to model assemblies where the parts have a more restricted association with the
assembly. In this refinement of aggregation, called composition, the lives of the parts of the assembly depend
wholly on their participation in the assembly.
CautionThere is considerable debate about the definition of composition. I'll describe the alternative views
later in this chapter.
A dependency relationship does not require direct communication. In this relationship, an object relies on the fact
that another object exists and is doing, or has done, its job. For example, a business transaction may depend on
the security system to insure that no unauthorized person can access the business transaction. The
implementation of this relationship is handled in the workflow, the technology, or other design options in the
application.
Generalization is used in the context of inheritance. A generalization relationship is very different from an
association. In fact, generalization does not require any of the rules established for associations. Instead,
generalization defines the organization of information about objects that share the same semantic meaning but
which vary in their individual features. For example, the term "car" refers to a broad range of vehicles. For a car
manufacturer, it is important to differentiate cars based on their unique features. So a manufacturer might draw
distinctions between passenger cars, SUVs, trucks, and so on, based on their differentiating features.
This chapter covers all three types of relationships-association (including aggregation and composition),
dependency, and generalization-and provides examples of the features used to fully define each type of
relationship.
<Day Day Up>
<Day Day Up>
Defining the Purpose and Function of an Association
The purpose of an association is to establish the reason why two classes of objects need to know about one
another, and the rules that govern the relationship. For example, an event may be held at a venue. The event
needs to know where it is to take place, and the venue needs to know what is taking place within it. These are two
perspectives on the same association.
Some associations, like the event and venue example, are very simple. Other associations can be more complex.
For example, a person may have many different reasons to know about a car-he might own a car, drive a car,
insure a car, or wreck a car, and there are many more possibilities. Each reason defines one association, one
reason why one type of object needs to know about the other type of object.
Regardless of the complexity, each association has to define its own rules to establish and maintain the integrity of
the relationship. These rules include
A way to uniquely and meaningfully identify the association.
The number of objects that may participate in the association.
The restrictions on the objects that are allowed to participate in the association.
The role that each type of object plays when it participates in the association.
A means to identify which objects may gain access across the association.
Information about the association, such as when it started, the terms of the association, when it ended, and its
current status.
Together, these rules define how the objects in an application can come into contact and collaborate with one
another.
<Day Day Up>
<Day Day Up>
Modeling an Association
Modeling an association begins by identifying the participating classes. The first examples we'll discuss use a pair
of classes, called a binary association, since this is the most common type of association. We'll cover associations
that use more than two participating classes, called n-ary associations, later in the chapter.
Binary association notation
In a Class diagram, a binary association documents the rules that govern one relationship between two classes of
objects. The association is a rule that explains what is allowed. In an Object diagram, an actual relationship is
called a link. An association is a rule. A link is a fact.
NoteThere is a situation in which the participating objects are defined by the same class. See the description
of a reflexive association later in this chapter.
Figure 6-1 shows an association connecting the Venue class and the Event class. The Venue class defines what a
venue object is and what it can do. The Event class defines what an event is and what it can do. The association
defines a single type of relationship that can be established between venues and events, one reason why these
types of objects need to communicate.
Figure 6-1: Association is a type of relationship. A link is an instance, or implementation, of an association.
The object myTheater:Venue in Figure 6-1 describes a Venue object named myTheater that conforms to the
Venue class definition. The object Phantom of the Opera:Event describes an Event object named Phantom of the
Opera that conforms to the Event class definition. The link defines a single relationship between the venue
myTheater and the event Phantom of the Opera.
However, as shown in Figure 6-2, a complete association definition is built with three parts: an association line
between the classes and two association ends. The association line and its name define the identity and the
purpose of the relationship. The association ends each define the rules about how the objects of the classes at
each end may participate.
Figure 6-2: An Association is made up of a connection and two AssociationEnds.
NoteAssociationEnd is a metaclass in the UML language. As such it owns attributes such as multiplicity,
constraints, and roles.
Association name
The naming of classes, attributes, and operations is very important, as you know. The name of an association also
is important, because it expresses to the reader the intent of the relationship. Each association represents an
investment of time and effort to establish the relationship, preserve its integrity, and ensure its proper usage. When
the name is vague, it introduces confusion and debate, increasing cost and reducing effectiveness in the modeling
process.
The usual way to name an association is with a verb or verb phrase. Figure 6-3 shows the same association
modeled with two different names, using a verb "hosts" and a verb phrase "is hosted by". The position of the name
is not critical. The name only needs to be somewhere in the middle of the line between the two classes. Keep it
near enough to the line so that the reader of the diagram clearly understands what the name is referring to. Also,
keep the name away from the association ends, where you will be adding a lot of information.
Figure 6-3: An association's name uses a verb or verb phrase.
UML assigns one association name with the understanding that the relationship can be read in the opposite
direction by reversing the meaning. In other words, the top association name in Figure 6-3 is read with the
understanding that if a "venue hosts an event" then the reverse must be true, that is "an event is hosted by a
venue." So you would model one or the other of the associations in Figure 6-3, not both.
NoteAssociation Name Controversy: Advocates of executable UML make a strong case for naming both
directions. The bottom line for me rests on two facts. First, the name does not generate code so its
primary purpose is to foster understanding of the model (The exception is in executable UML (xUML). But
xUML is not in widespread use yet.). Second, asking the reader to reverse the meaning does not pose a
particular challenge. In fact, the opposite is true: if the modeler assigns two names, he runs the risk of
unintentionally introducing multiple relationships in the same association.
Figure 6-3 also introduced a useful device called a directional indicator. At least in western culture we tend to read
from left to right, so when the drawing requires us to label something reading from right to left, we need a way to
let the reader know our intent. The solution to this problem is pretty simple: place a directional indicator, like an
arrow, next to the association name to show the reader how to interpret the meaning of the association name. In
Figure 6-3, an arrow is placed next to both association names for clarity. Often the directional indicator is only used
when the association name reads in some direction other than the typical left-to-right direction. In short, do what is
necessary to help ensure that the diagram is understood correctly.
TipIn some tools the directional indicator is simply a feature of each association name that can be turned on
or off. In other tools you set the direction within the association specification. In still other tools you may
have to actually draw the symbol.
The association name becomes even more important when two classes have more than one reason for
collaborating. In the venue and event example, for instance, a venue may sponsor an event while others host the
event. At other times a venue may be both the host and the sponsor. Figure 6-4 uses two associations to represent
the fact that rules for hosting an event are different from the rules for sponsoring an event. The two associations
need to be defined and maintained separately.
Figure 6-4: Each association represents a separate set of rules.
The goal of an association name is to clearly and concisely define the purpose of the relationship between the two
types of objects. That purpose will guide the definition of the actual communication between the objects and drive
the definition of the roles that each object plays in the communication.
Association end
To define those roles, UML treats each association end as a separate and distinct entity with its own rules. That is,
a venue's participation in the "hosts" association is different from the event's participation in the "hosts" association
as modeled in Figure 6-5.
Figure 6-5: Association ends define the participation of each type of object.
Each end of the association needs to explain, for instance, what role the object at that end plays in the relationship,
how many objects of that type may participate in the relationship, and if there may be many participating objects,
whether they have to be in some order. The association end also specifies whether there's some feature of the
object that could be used to access it, and whether the object on one end can even access the object/s on the
other end. Each end of the association includes some or all of these defining features:
Roles
Interface specifier
Visibility (required)
Multiplicity (required)
Ordering
Constraints
Qualifier
Navigability
Changeability
The following sections discuss these features and their notations.
Roles
A role name explains how an object participates in the relationship. Unlike the association name, the role name at
the association end can generate code. Each object needs to hold a reference to the associated object or objects.
The reference is held in an attribute value within the object. When there is only one association then there is only
one attribute holding a reference. In the generated code, the attribute will be named using the role name of the
referenced object.
For example, in Figure 6-1, the Phantom of the Opera event is hosted by myTheater. The event object Phantom of
the Opera contains an attribute with an object reference to myTheater. So far it doesn't really matter what we call
the attribute because there is only one reference. It is possible for an event not only to be hosted by a venue but
also to be sponsored by a venue. This means that there are two possible references to a venue in the same event
object. One venue negotiates to bring the theater troop to town, but the performance will be spread across three
different host venues. Now we need multiple venue references and we need to be able to tell the difference
between the sponsoring venue and the hosting venues. To represent two distinct references, the role names are
often used to name the attributes that hold the references.
Role names describe the association in terms of how each type of object (venue and event, in our example)
participates in the association. Because both association names and role names help describe the nature of the
relationship, the role names may be used with or in place of the association name. Figure 6-6 models both
alternatives for the venue and event relationships. The top model uses an association name and roles only on the
event ends. The bottom model uses only the roles name throughout.
Figure 6-6: Role names assigned to association ends.
Place the role name at the end of the association line and next to the class that it describes. The exact position is
not critical. Just keep it near the end of the association near the class. There are other model elements that will
need to fit at the association end as well, so don't be surprised if you have to move things around a little for
readability.
Interface specifier
A class defines a set of operations called an interface. In any given association only one or a few of those
operations might be needed. For example, the theater system performance class is used for a variety of reasons.
The marketing subsystem accesses the features of a performance that support assigning prices. The sales
subsystem accesses the features that support finding and choosing available seats at the performance. The
interface specifier is paired with the role name in the format "role name : Interface", as in "performance : IPricing",
and "performance : IAvailability."
The interface specifier is a way to define the required features without dictating either the class that provides them
or the implementation. It simply states that for the relationship to work there are specific features that must be
supported. (See Chapter 4 for more on interfaces.)
Visibility
Figure 6-6 also illustrates the visibility notation for role names. Visibility was covered fully in Chapter 4, and here we
are using the exact same concepts, except that the visibility refers to who can access the role name. Reading
Figure 6-6, the Event class has a reference to a role name "-host" (at the opposite association end). The minus
sign (-) in front of the role name is the UML-suggested shorthand for private visibility. This means that an event
contains a private attribute that holds a reference to a venue that plays the role of host to the event. If you want
access to the value in that attribute, you need to request it through an operation that has a visibility of something
other than private access.
NoteVisibility has been dropped from the association end in UML 2.0. I am guessing that it was for the simple
reason that encapsulation dictates that all attributes should be private.
Multiplicity
Association multiplicity refers to the valid number of objects that may be related under the rules of the association.
Multiplicity may express a range of values, a specific value, a range without limit, or a set of discrete values. For a
complete explanation of multiplicity, see Chapter 5.
There is one significant difference between the attribute multiplicity notation presented in Chapter 5 and the
multiplicity notation used with association ends: attribute multiplicity is enclosed in square braces ([]), and
association multiplicity stands by itself (see Figure 6-7).
Figure 6-7: Assigning multiplicity to each association end.
The multiplicity assigned to an association end defines the number of objects at one end of the association that
may be associated with a single object on the other end of the association. For example, Figure 6-7 states that one
and only one (1..1) venue sponsors each event. The multiplicity value goes beside the type of object that it is
counting. In this case the multiplicity value is counting the number of venues, so the value goes next to the Venue
class. At the other end of the "sponsors" association in Figure 6-7, the association end states that zero or more
(0..*) event may be sponsored by each venue.
In Figure 6-7 there are two associations, sponsors and hosts, and each end of each association is assigned its own
value for a total of four values. Even if the values happen to be the same, they are not saying the same thing about
the model. In Figure 6-7, on the "sponsors" association at the end near event you see the multiplicity 0..*. The
same multiplicity is on the event end of the "hosts" association. The first association defines how many events may
be sponsored by each venue. The second association defines how many events may be hosted by each venue.
NoteThis example emphasizes again the importance of meaningful association names. I have actually seen a
lot of modelers simply draw the association line, not name it, and proceed to assign multiplicity and other
values. The inevitable result is a lot of debate over the multiplicities and other values because discussion
participants are confusing and combining information about different relationships that have not been
isolated and defined individually.
In the explanation of visibility, I said that each association would be implemented as an attribute that holds a
reference to the object at the other end of the association. Multiplicity allows us to identify relationships with more
than one object, like a venue that may sponsor many events. In this case the single object reference becomes a
group of object references. Thus multiplicity alerts the programmer (or the modeling tool) charged with
implementing this requirement that she will need to use some type of container class or array syntax to hold the
group of references. The next topic, ordering, enables you to be even more specific about the implementation
requirements.
Ordering
Whenever multiplicity allows for more than one object, UML supports the ability to specify ordering. Ordering
simply means that the objects in the group need to be arranged in a sequence. Ordered is a predefined Boolean
tag value used to specify the need to arrange the objects in the group. To show that the group of objects that
participate in the relationship needs to be preserved in some sequence, simply place the keyword {ordered}
enclosed in curly braces at the end of the association. The curly braces identify constraints on the association end.
Ordering is one type of constraint. More examples are provided later in this chapter.
Figure 6-8 represents the fact that when a venue hosts a number of events, the list of events needs to be arranged
in a specified sequence.
Figure 6-8: The ordered constraint for an association end.
If the objects in the group do not have to be in any sequence, the default is to leave off the {ordered} property. For
example, when a venue sponsors a number of events, it does not need to keep track of the group of events in any
particular sequence so the ordered property is left off (refer to Figure 6-7).
What is the significance of specifying ordering? Earlier I stated that each association is implemented as an attribute
that holds a reference to the group of objects. The {ordered} property now adds the requirement that the objects
need to be maintained in a specified order. They are no longer simply a random set of values. The implementation
for the association end will need to consider things like the sort criteria and adding and removing objects from the
list (add at the top or at the bottom, insert into the sequence, and so forth) in order to maintain the correct
sequence within the group of references.
Avoiding Dangerous Notation Defaults
In some respects, using the absence of a value on the diagram as a default value is a dangerous practice. It
may save a few seconds and a bit of clutter in the short run but you always run the risk of simply forgetting to
address the question until late in the project or not at all. To avoid this problem, you might instead display the
UML-supported default property {unordered}. The trade-off is clarity versus clutter. Remember, the purpose of
modeling is to reveal information, not hide it.
Given this new requirement it sounds like we need something more to help specify not only whether the group is
ordered but also by what sort criteria. That is one reason why the UML provides the constraint notation.
Constraints
A constraint defines a restriction that needs to be enforced on a modeling element to insure its integrity throughout
the life of the system. For example, in the preceding section we found the need to specify the sort sequence for a
group of objects that participate in an association. When a venue hosts a series of events, the venue manager
might want to keep track of the events according to the dates they are scheduled to start. But the {ordered}
property is merely a Boolean and cannot help us with the sequencing details. Additionally you may want to set a
limit on the cost of an event or restrict how an event may be scheduled at a venue.
UML defines three extension mechanisms: tagged values, stereotypes, and constraints. A constraint is used to
define rules, and can help us with this new set of requirements. The format of a constraint is really just a string of
text (in a specific language) that can be attached to almost any element in your model. The language of the
constraint may be OCL, a programming language, or even your own written language, such as English, German,
or French.
On an association end, the constraint may be added to the {ordered} property string to specify the maximum cost
of an event association with a venue to be $100,000. Figure 6-9 illustrates the addition of the constraint within the
same pair of braces used to contain the ordered property.
Figure 6-9: Adding constraint language to an association end.
Since constraints are really just strings, you can add as many constraints as you need between the pairs of braces
{}. Figure 6-10 shows the addition of another constraint, this time in free-form text, stating that the group of events
should be sorted by the event start date. The maximum cost was specified using OCL. The sorting was specified
using free form text.
Figure 6-10: Concatenating constraints.
Some tools enforce some rigor on the specification of constraints, that is, you may have to specify each constraint
individually. The tool may also provide support to test the syntax of the constraint against the Object Constraint
Language (OCL) specification. The tool then concatenates the list of constraints into the braces for you. Figure 6-
11 shows the Magic Draw 6.0 dialog box for entering constraints in an association end.
Figure 6-11: Using a tool to enter association end constraints.
No Magic
Constraints document the implementation requirements for the end of the association. They are implemented in
the methods that create and alter the object references that represent the relationship. In the event example, every
time a new event is scheduled, the corresponding venue must update its set of references to events hosted at the
venue. The new event references is added to the list by inserting it into the existing list of event references using
the start date of the new event to find the correct location. Moreover, whenever an event is rescheduled, the list
must be altered to maintain the correct order.
Constraints may be used for many other reasons. A very common application of a constraint on an association end
is to define which objects are allowed to participate in an association. In the theater application, scheduling is
centralized for all of the venues owned by the company. The schedulers cannot commit a venue to host an event if
that event has not been authorized by the venue's manager. This is a safeguard to insure that the schedulers have
the approval of the venue manager before committing the venue.
Figure 6-12 adds the vm_approved Boolean constraint requiring authorization by a venue manager.
Figure 6-12: Using constraints to restrict object participation.
A constraint applies to the objects of the class at the end of the association next to the constraint, so be careful to
place the constraint in an unambiguous place at the end of the association and near the class it applies to.
In Chapter 18, we will apply the formal Object Constraint Language to the constraints used in the modeling
examples throughout the book. If you don't know OCL, you can use free form text to specify the requirements on
your diagram.
Qualifier
A qualifier works very much like a key on an indexed file. It provides a means to go directly to the object you want.
Now consider the venue. When a venue needs to find an event, it can take advantage of the sorting by start_date
already defined using the {ordered} property and the sort constraint. But that still requires the venue to read
through the list of references until it finds the one it needs, which could be the last event on the list. After a few
years of events at a venue, this list could get rather long. Finding one specific event could take a long time.
The qualifier defines an attribute of the referenced objects and uses it as a key to get direct access to a specific
object. From a modeling standpoint, this simply specifies the desire or the requirement to have this type for access.
The goal is to then to find an implementation that can satisfy the desired direct access with the specified key.
To model a qualifier you must identify the type of object that wants to use the access, and the type of object that
provides the access. The qualifier is placed next to the type of object that wants to use it. For example, the venue
wants to use a qualifier value to access an event. Figure 6-13 shows how the qualifier is placed in a small
rectangle at the end of the association next to the Venue class.
Figure 6-13: Using a qualifier to get direct access to an object.
The rectangle containing the qualifier is inserted between the class and the end of the association so that all the
other association end notation (such as multiplicity and constraints) remains intact. Observe two changes in the
model:
The qualifier is placed in a small rectangle on the venue end of the "hosts" association because the venue
uses the qualifier. The rectangle contains the attribute type used to look up the objects on the other end of
the association. In this case the venue looks up events using the id attribute of the event. You can see the
specification of the corresponding "id" attribute in the Event class on the right.
1.
The multiplicity on the event end of the host association has changed from zero or more (0..*) to one and
only one (1). That is because if a venue object uses a unique event id to access events, it will only get one
event that matches the look-up value.
2.
If the qualifier were a non-unique value, the result would be a set of events so the multiplicity would remain zero or
more (0..*). However, the result would still most likely be a subset of events, not the entire list. When using a
unique qualifier, a good case could be made for using a multiplicity of zero or one (0..1). This allows for the
possibility that the venue would try to use a unique qualifier value that does not match any of the events.
What does a qualifier imply for the implementation? A qualifier states that the Venue class needs a set of
references that can be keyed on a value. Most OO languages provide a variety of predefined classes for just this
purpose. For example, in Java you might use a HashTable or a Map that supports key-value pairs, so every time
the venue adds a reference to an event, it adds the object reference to the Map along with a corresponding
qualifier or key value.
CautionA qualifier sounds a lot like a key on a database. The function is very much the same, but the usage
is significantly different. A key on a database is used to facilitate access to physical storage. A qualifier
works on objects in memory. By the time data has been retrieved from a database into memory, the
key selection has already taken place. There is no need to replicate the same keyed access in the
object model. The qualifier's value is for manipulating objects in memory. For example, you have
pulled up all of the events taking place this year to generate a report. Now the application needs to
find the best selling events to highlight them on the report. The database access may be keyed on
start date. The qualified access may be keyed on net sales.
Navigability
Navigability describes the need for an object to access another object by "navigating across the link." In other
words, setting the navigability attribute of an association end determines whether the object at the other end of the
link can access the object on the navigable end of the link. Navigability is modeled with an arrow on the end of the
association. If the arrow is present, that end of the association is navigable. If the arrow is absent then that end of
the association is not navigable.
Figure 6-14 shows that the navigability on the event end of the hosts association is true. We know this because the
navigation arrow is visible on the end of the association pointing to and touching the Event class. This means that
the events are visible to the venue at the other end of the link.
Figure 6-14: Specify navigation by placing an arrow at the end of the association.
Now for the twist: Based on my description so far, when both ends of the association are navigable, you might
expect both ends to have arrows on them. Unfortunately this is another place where default reasoning can cause
confusion. When both ends are navigable, most tools use the default that does not show any arrows. The
reasoning is that most associations are bi-directional. The exception is unidirectional navigation. To save time and
effort, it can be easier to assume that all associations are bi-directional unless otherwise modeled.
The danger here is that there is no way to tell whether anyone even investigated the navigation requirements.
Remember that navigation requires object references.
Object references are attributes. Attributes need to be managed using operations. Attributes and operations are
code that someone has to write and maintain. If navigation is not required, you can avoid that extra coding and
maintenance. Defaulting the navigation results in navigation implementations on both ends whether they are
needed or not.
CautionDo not confuse navigation arrows with directional indicators on association names. Navigation arrows
are modeled on the end of the association line. Directional indicators appear to the left or right of the
text of the association name.
Changeability
The changeability property enables you to specify the operations that are allowed on the links defined by an
association. The default changeability is to allow any type of edit-add, change, delete, and move. As has been the
case with other default values, you do not have to model the default.
If, however, the changeability needs to be restricted, the changeability value is represented in the property string
along with ordering and constraints. The predefined options include {frozen}, which means that once the link has
been established, it cannot be changed or moved. If the application only allows new links to be created (no
deletions), use the {addOnly} property.
Figure 6-15 models a new association example between the Contract and Vendor classes. The theater company
sets up contracts with vendors who provide services and supplies to the venues. The contracts represent legal
documents that must not be deleted from the vendors file. To prevent unwanted deletions, they set the {frozen}
property on the contract end of the association.
Figure 6-15: Modeling the non-default changeability property {frozen}.
The changeability property applies only to the link, the connection between a vendor object and a contract object. It
does not say anything about the ability to change the contract itself.
Constraints between associations
Given the modeling options covered so far, how would you handle a situation where two associations are mutually
exclusive? For example, let's say that a venue manager may either oversee an event or audit an event, but not
both.
Figure 6-16 models the "exclusive or"-{xor}-constraint notation used when the model needs to specify that two
associations are mutually exclusive. Draw a dashed line between the two associations. Place the {xor} near the
dashed line. The predefined {xor} constraint states that only one of the two associations may be instantiated
between the pair of objects. In the Figure 6-16 diagram, a venue may have an "oversees" link to an event or it may
have an "audits" link, but the same pair of objects can never have both links.
Figure 6-16: Exclusive or constraint on two associations {xor}.
When the constraint involves more than two associations, you need to fall back on one of the other general-
purpose tools of the UML: comments (called notes in UML 2.0). The comment looks like a page with a folded
corner. The text of the constraint goes inside the comment. Attach the comment to the constrained associations
using a dashed line, called an anchor, from the note to each association, as shown in Figure 6-17.
Figure 6-17: Constraint notation involving more than two elements uses a comment (or note) with anchor lines
to the constrained elements.
According to the Class diagram in Figure 6-17 a venue manager now has to choose whether to contract, audit, or
coordinate an event. She must choose one of the three.
Reflexive association
All of the association examples so far have modeled relationships between objects of two different classes, such
as Event and Venue. There are times, however, when the participating objects belong to the same class. For
example, one venue manager might provide backup for another venue manager. When the participating objects
are in two different classes, the association line comes out of one class and into another class. When the objects
all belong to the same class the association has to come out of the class and return back to the same class, as
shown in Figure 6-18.
Figure 6-18: A reflexive association models relationships between objects in the same class.
A reflexive association is a very common place to use role names. In a binary association, the association reads
almost like a sentence using the class names. For example, "VenueManager audits Event" or "Contract binds
Agent". In a reflexive association the meaning may not be quite as clear. Without the role names in the Figure 6-18
diagram, the association would read, "one VenueManager is associated with zero or more VenueManagers." With
the role names it reads, "VenueManagers functioning as coordinators always work with a VenueManager
functioning as an auditor."
Derived associations
A derived association is much like a derived attribute in that it is not really needed. That is, the same information
could be figured out by looking at other associations. Derived associations, like derived attributes, are used quite
often for performance reasons, because when a model becomes large or complex, it can become difficult to
navigate to the information you need.
For example, Figure 6-19 represents a portion of the theater system. An agent has a contract with the venue. The
venue hosts an event that is made up of a number of performances for which it sells tickets. In order to find out
how many tickets an agent sold the application would need to traverse all of these associations, filtering out
unwanted objects along the way. Given that agents always want to know how much money they are making, this
process could be a real burden on the system.
Figure 6-19: Finding information in a large or complex model.
One derived association is added in Figure 6-20 to solve the problem. The new association is added between the
Agent and Ticket classes. A slash mark is placed in front of the association name to mark the association as
derived. The slash is the same symbol we used for derived attributes.
Figure 6-20: The highlighted ellipse shows the derived association notation using a forward slash in front of
the association name.
How does the new derived association work? Each time a ticket is sold by an agent, the ticket is updated with a
reference to the selling agent and the agent is updated with a reference to the ticket that he sold. (These two
references depend, of course, on the specified navigation.) When it comes time to look up the agent's sales, the
application only needs to read one of the two references, that is, look up the tickets to see who sold them or look
up the agent to see what tickets she sold.
Using a derived association incurs the same overhead as using a derived attribute. You need to store the additional
references and maintain them. So the trade off is between the cost of maintaining the additional references and
the value of the improved performance.
UML 2.0
This chapter has covered the fundamental association as defined in UML 1.4. UML 2.0 supports all of these
notation concepts except interface specifiers. Interface specifiers have been dropped from the notation. The
changes in UML 2.0 are primarily changes to the metamodel. The changes highlighted in Figure 6-21 are identified
in the following list and explained in the text that follows Figure 6-21:
Figure 6-21: The metamodel for associations.
OMG 2.0
An association end is now defined by the Property metaclass. The UML 1.4 AssociationEnd metaclass has
been deleted. Instead, an association end is defined by the role name memberEnd assigned to the Property
end of the relationship between a Property and an Association.
The default value for a memberEnd property is defined using a Value Specification instead of the Attribute
metaclass.
Associations and Properties may be explicitly defined as being derived. The default is not derived, also called
base. Formerly this was a feature of every instance of the ModelElement metaclass. But ModelElement has
been removed from the metamodel.
Many features formerly assigned specifically to the AssociationEnd metaclass are now inherited from more
general metaclasses like StructuralFeature, MultiplicityElement, TypedElement, and Element. For example,
formerly, an association end was typed by a direct association with a classifier. In UML 2.0 the association
between a memberEnd property and a type is a relationship inherited from TypedElement.
UML 1.4 specified navigability using an attribute of AssociationEnd. UML 2.0 defines navigability using two
associations between the Association and Property metaclasses, distinguished by the role names memberEnd
and ownedEnd.
A qualifier is now defined by the Property metaclass instead of the Attribute metaclass.
The notation for navigability has been improved to remove some of the ambiguity in the UML 1.4 notation.
The derived attribute opposite in Property simply states that a property can find out what property is on the
opposite end of the association (as long as the other end is navigable).
The vocabulary for the aggregation options has changed from none, aggregation, and composite, to none,
shared, and composite. (Aggregation will be covered later in this chapter.)
In UML 1.4 the ends of an association were defined with a unique metaclass called AssociationEnd, a subclass of
ModelElement. Two or more AssociationEnds were associated with an association. UML 2.0 simplifies this model
by reusing the metaclass Property as a means to describe the features of each end of an association. Even the
term association end has been replaced with memberEnd.
The term memberEnd is a role played by a property when it is used to define an association. The properties that
function as memberEnds of an association define all of the classifiers referenced by the association.
An association can also own properties. That is, the Association metaclass is associated with zero or more
properties in the role ownedEnd. An ownedEnd property is owned by the association itself and as such is not
navigable by other properties that participate in the same association.
In other words, if the Contract end of the binds association in Figure 6-22 is navigable (is a memberEnd property),
an agent can, so to speak, see the end of the association next to the Contract class. It can see the end of the
association because it is implemented as an attribute of type Contract in the Agent class. If the Contract end of the
association is an ownedEnd property, an agent cannot see the Contract end of the association because the end of
the association is not navigable.
Figure 6-22: Agent inherits from Vendor so Agent inherits the binds association with Contract.
A default value may be assigned to a memberEnd property using a ValueSpecification in the same way that a
default value may be assigned to an attribute of a class. This is because both memberEnds and attributes are
properties.
The isDerived attribute is now part of the Property and Association metaclasses. So a memberEnd property may
be derived from other associations just as in UML 1.4.
The Property metaclass brings with it a number of features inherited from the ancestor classes (superclasses)
pictured in Figure 6-21. The inherited features are listed following according to the superclass that defines the
feature.
As a subclass of ModelElement, a property may own other properties. Hence, a memberEnd of an association
may be described using other properties like role names, multiplicity, visibility, and so forth.
As a subclass of TypedElement, a property is associated with a Classifier that defines the type of the property.
So a memberEnd identifies the type of class that participates in the association.
As a subclass of Feature, a property may be defined as applying to an instance or to a classifier. This means
that the implementation for a memberEnd may be an instance-level or static/class-level attribute. The default
for the isStatic attribute is false, meaning that the property has a unique value for each instance of the
referenced class/classifier. A true value for isStatic means that the attribute is declared as static, that there is
only one value that is owned by the class/classifier and shared by all instances of the class/classifier.
As a subclass of MultiplicityElement, a property can be defined as having some number of values. When a
property has more than one value, the values may be ordered and may be constrained to make certain that
every value is different. Ordering is specified using the isOrdered attribute, which defaults to false (unordered).
The uniqueness of the values is specified using the isUnique attribute, which defaults to true (unique).
As a subclass of StructuralFeature, a property may be designated as read only or changeable. The default for
the isReadOnly attribute is false, meaning that a property may be modified.
As a subclass of StructuralFeature, a property is also redefineable. That is, a general property may be
specialized by another property that overrides and/or adds to the features of the general property through
inheritance.
The concept of a redefineable element refers to inheritance between model elements such as classes. Since I
haven't yet covered inheritance, you might want to come back to this topic after reading the section on
generalization later in this chapter.
A redefineable element is a reference to an inherited model element. For example, in Figure 6-22 the Agent class
inherits from the Vendor class. That means that an agent is a type of vendor and as such the agent inherits all of
the features of a vendor, including the association with the Contract class.
Whenever a feature is inherited, the inherited feature is considered to be redefineable, that is it can be overridden
or extended. In Figure 6-23, the binds association between the Vendor and the Contract is inherited by the Agent
class. The inherited association is redefined to describe the relationship between an agent (a specialized type of
Vendor) and the Contract class. The new association changes the inherited association in two ways:
Figure 6-23: Redefining the end of an association.
The first change is to the multiplicity on the Contract end of the association. The contract multiplicity
changed from zero or more (0..*) to one or more (1..*). The 0..* multiplicity on the Contract end of the
Contract-Vendor association states that the theater company wants to keep track of vendors whether they
have zero contracts or many contracts with the theater company. But the multiplicity on the Agent end of the
Contract-Agent association states that the theater company tracks agents only if they have at least one
(1..*) contract with the theater company.
Cross-Reference Multiplicity notation (such as 1, 0..* and 1..*) is covered in Chapter 5.
When redefining multiplicity, the rules state that the lower bound may increase, that is, it may become more
restrictive. In this example, the lower bound changed from zero (0..*) to one (1..*). In like manner, the upper
bound may not be higher, or less restrictive than the redefined/original value.
1.
The second change is to the changeability value. In Figure 6-23 the changeability of the memberEnd next to
Contract allowed any type of change to the memberEnd because the isReadOnly attribute is set to the
default value of false. The redefined memberEnd states that the link has to remain unchanged,
isReadOnly=true, once it has been established. The UML 2.0 {readOnly} attribute of the memberEnd
corresponds to the UML 1.4 changeability value {frozen}.
2.
Ordering is also defined by an attribute of property that is inherited from MultiplicityElement. If the isOrdered value
is false (unordered) in the redefined memberEnd, the redefining memberEnd may set it to true (ordered).
However, if the original value is true, the redefining memberEnd property may not change it to false. In other
words, a specialized memberEnd property may not make an ordered memberEnd property become unordered.
As a subclass of Element a memberEnd property can have a name. To indicate that a memberEnd property
redefines another memberEnd property, use the keyword redefined and the name of the redefined memberEnd
property in the following syntax:
{redefined <end-name>}
In Figure 6-24 the Contract end of the Contract-Agent association redefines the memberEnd called contract on the
Contract-Vendor association.
Figure 6-24: Modeling the redefined memberEnd property called contract.
The memberEnd name in UML 2.0 replaces the role name in UML 1.4. When there is no memberEnd/role name,
the memberEnd gets its name from the name of classifier that gives it its type.
Since inheritance may encompass any number of levels, there may be any number of redefined memberEnd
properties. At each level of inheritance, there is a potential to redefine the inherited elements. To represent
multiple redefined elements, simply list them together inside a single pair of curly braces separated by commas,
such as {redefined class, classifier, namespace}.
A qualified association defines a memberEnd property that owns another property in the role of a qualifier of the
memberEnd property. This replaces the UML 1.4 scheme that defined a qualifier as an attribute associated with an
association end since in UML 1.4 both attributes and association ends are defined as properties.
As you can see, a memberEnd property can utilize a number of descriptive attributes. Table 6-1 provides a
summary of the features of a memberEnd property and how they are depicted at the end of an association in a
Class diagram. When more than one of these features appears together they are enclosed in a single pair of curly
braces and separated by commas. For example, you could write {subsets propertyA, redefines propertyA, union,
bag}. If the end of the association is navigable (is a memberEnd, not an ownedEnd), you can also add any property
strings that apply to an attribute, in addition to the features listed in Table 6-1.
Table 6-1: Summary of Notations for memberEnd Features
Feature notation Explanation
{subsets<property-
name>}
The memberEnd property is a subset of the other memberEnd property
referenced by <property-name>.
{redefined<end-name>} The memberEnd property redefines the other memberEnd property
referenced by <end-name>.
{union} The memberEnd property is derived by being the union of all memberEnds
that subset it.
{ordered} The memberEnd property represents an ordered set, the default.
{bag} The memberEnd property represents a collection that permits the same
element to appear more than once.
{sequence} or {seq} The memberEnd property represents a sequence (an ordered bag).
UML 2.0 does introduce one change to the association notation for navigability. In UML 1.4 it was impossible to tell
the difference between an association that was not navigable, one that was undefined, and an association end that
was part of a bi-directional association. UML 2.0 solves this problem with the addition of a simple X' on an
association end that is not navigable. The resulting navigability options are illustrated in Figure 6-25.
Figure 6-25: Notation for the allowed navigability options in UML 2.0.
The following is brief description of the meaning of each example association illustrated in Figure 6-25.
Example 1 models an association in which navigability is undefined on both ends.
Example 2 models an association in which an agent can access (navigate to) the contracts but navigation from
a contract to an associated agent is undefined. Notice that the absence of navigation notation is an undefined
value.
Example 3 models an association in which an agent can access the associated contracts and a contract can
access the associated agent. This combination of navigation notation is called bi-directional navigation.
Example 4 models an association in which an agent can access the contracts but a contract cannot access
the associated agent. The X' on the end of the association indicates that the association end is not navigable.
This combination of navigation notation is called unidirectional navigation.
Example 5 models an association in which an agent can access the contracts and a contract cannot access
the associated agent. This is a rather useless notation but it illustrates the use of the X' as a way to distinguish
non-navigable relationships from undefined relationships.
<Day Day Up>
<Day Day Up>
Modeling an Association Class
An association between two types of objects often requires information not just about the participating objects but
also about the association itself. For example, when did the association begin? When did it end? Were there terms
or conditions applied to the association?
Association class notation
In an object oriented model all information is modeled as attributes. Attributes reside within classes. So information
about an association must be defined as attributes in a class. But how do we model the fact that the information
describes an association, and not an entity like a venue or an event? Figure 6-26 models the association between
agents and the theater company. The association is described in terms of start, end, terms and conditions, and
authorization. The descriptive attributes are encapsulated within a class called Contract. The Contract class is then
connected to the authorizes association that it describes using a dashed line. The dashed line does not have an
arrow.
Figure 6-26: Association class captures information about an association.
An association class is much like any other class. The only real difference is in how you found the need for the
class. Where most classes describe an entity, something that you can see or touch, an association class describes
a relationship. Because an association class is just another class, it can participate in other associations. Figure 6-
27 shows how the Contract class may also be associated with a SalesAgreement class. The contract provides the
legal right to do business. The sales agreement details the scheduling of services within the terms defined by the
contract.
Figure 6-27: An association class may participate in other associations.
Association class promotion
The association class notation is valuable in that it reveals why the new class was added. But it also poses
challenges for implementation. By default, an association class defines a type of link between the two classes. So
an instance of the association class, one contract in the example, refers to a single connection between one
theater company and one agent. But what happens when a contract can apply to more than one agent? For
example, a contract might apply to an agency that employs a number of agents who will all be bound by the same
contract.
In this situation, the default multiplicity will not work. In order to correct the problem, the diagram needs to change
to reveal the association ends so that they can be modified. Figures 6-28 through 6-30 show the steps to transition
the implied associations to explicit associations that can be updated.
Step 1, shown in Figure 6-28, adds and names two new associations based on the implied associations from the
association class. That is, the association class defines a link that connects exactly one theater company and one
agent. Note the multiplicity on the new associations: a contract refers to exactly one theater company and one
agent.
Figure 6-28: Add the explicit associations to replace the associations implied by the association class.
Step 2, shown in Figure 6-29, assigns the multiplicity on the contract end of each association. The multiplicity of the
original association read, "Each theater company authorizes zero or more agents", and "Each agent is authorized
by exactly one theater company". The new associations read, "Each theater company approves zero or more
contracts", and "Each agent is authorized by one contract".
Figure 6-29: Map the original multiplicities to the two new associations.
This translation of the original association into two new associations reveals two problems. First, we need the
contract to apply to one or more agents. To correct this problem, change the multiplicity next to agent from one (1)
to one or more (1..*). Second, if contracts only last a year, an agent might have many contracts over time. To
correct this problem, change the multiplicity near the contract end of the authorizes association from one (1) to one
or more (1..*).
Step 3 incorporates these changes, as shown in Figure 6-30. Once the two new associations have been fully
defined and updated, the original association may be deleted.
Figure 6-30: Update the new (exposed) association multiplicity as needed.
Not every association class needs to be expanded in this manner. The only time it is necessary is when the implied
associations are not accurate. Then the implied associations need to be made explicit so that the association ends
are exposed and may be modified.
UML 2.0
The UML 2.0 definition for an association class is the same as in UML 1.4. An association class is a subclass of
both the Class and Association metaclasses.
<Day Day Up>
<Day Day Up>
Modeling N-ary Associations
So far all the association examples have involved at most two classes. On rare occasions you might find it
necessary to associate more classes. Such associations are considered n-ary as opposed to binary. For example,
in order to define a schedule there must be an event, a coordinating venue manager, and a location to host the
event. An event may only be added to the schedule when all three elements are in place. Figure 6-31 models the
three participating classes and the diamond symbol in the middle is used to merge the three association ends into
one association. The Schedule class is an association class that describes the combination as a scheduled item.
Figure 6-31: An n-ary association using the diamond symbol.
An n-ary association may include any number of classes, but be careful to avoid creating an overly complex
model. In most cases an n-ary association can be broken down into a set of binary associations. In fact, depending
on the features of your programming environment, you may have no choice but to break it down into a set of binary
associations in order to implement the associations.
The UML 2.0 definition for n-ary associations is consistent with the definition in UML 1.4.
<Day Day Up>
<Day Day Up>
Modeling Aggregation
Aggregation describes a special type of association designed to help us cope with complexity. In a typical
association the participating classes are peers. Each class remains independent of the other and neither class is
superior to the other. They simply communicate. Aggregation, on the other hand, defines a definite hierarchical
relationship. It defines an assembly or configuration of elements to make a larger more complex unit. The saying
"The whole is greater than the sum of the parts" is true with aggregation. Furthermore, in an aggregation of objects
there has to be a point of control, a boss, one object that represents the interface to the assembly and assumes
responsibility for coordinating the behavior of the aggregation.
Figure 6-32 summarizes the relationships between association and aggregation. The diagram illustrates that
aggregations are a subset of all associations. The aggregation subset is a specialization that introduces a new set
of characteristics that regular associations do not have:
Figure 6-32: The unique characteristics of an aggregation association.
An aggregation is used primarily to define and protect the integrity of a configuration of objects.
An aggregation defines a configuration so that the collection of objects can be managed as a single unit, as
though the collection was one large object.
An aggregation defines a focus of control in one object in the configuration that provides the interface to the
configuration. The control object then propagates instructions to objects within the configuration to satisfy the
interface.
Aggregation may represent both physical and logical assemblies. For example, aggregation can model the
configuration of a desktop computer as easily as the configuration of a project team. In a model of a desktop, the
classes represent hardware devices that have physical connections in the forms of wires, cables, and even
soldered contacts. In the model of a project team, the classes represent people who are "connected" by
agreements and assignments. The associations in the project team model represent intangible relationships.
Yet the same rules can be applied to the logical model as to the physical model. The team can have a point of
control, a project leader or manager for instance, who directs the activities of the team. If the team is assigned to a
new location or to work on a new assignment, every member of the team participates in the relocation or the work
on the assignment. They function together as a unit as directed by the project leader.
If aggregation is just another type of association then why is it so important to define aggregation as something
different? What is the value for the added notation? The answer is that aggregation describes a group of objects in
a way that changes how you interact with them. The concept is aimed at protecting the integrity of a configuration
of objects in two specific ways.
First, aggregation defines a single point of control in one object, the aggregate, that represents the entire
configuration. This ensures that no matter what others might want to do to the members of the assembly, the
aggregate has the final word on whether the actions are allowed. This assignment of control may be at many
levels within the aggregation hierarchy. For example, an engine might be the controller of its parts, but the car is
the controller of the engine, and the other parts of the car.
It is important to note, however, that this model of control is a design choice. There is no syntax either in UML or in
programming languages to enforce this design choice. There is no code construct that prevents a programmer
from calling an operation on a member object. The intent of aggregation notation is to inform the programmer of
the designer's intent to work through the designated point of control, the aggregate object.
Second, when an instruction is given that might affect the entire collection of objects, the aggregate object dictates
how the members will respond, so the assembly appears to function like a single object. For example, when I push
the gas pedal on my car to tell the car I want to accelerate, the entire car assembly (with its thousands of parts)
accelerates, not just the gas pedal.
Once this pattern of propagation from aggregate to members is defined at every level of the assembly, no one
outside the assembly needs to be aware of it. They need only invoke the aggregate object's interface. The rest is
handled within the assembly. This is what I meant at the beginning of the chapter when I said that aggregation
helps us control complexity.
It is common practice to model an aggregation in one diagram. Then everywhere the aggregation is used, only the
aggregate class appears. This is because we know that all interaction with the assembly goes through the
aggregate and that the behavior of the assembly has already been defined on the other diagram and doesn't need
to be modeled again.
Aggregation models a relationship just like an association, so the same rules apply to defining aggregations as to
associations, namely roles, multiplicity, qualifiers, changeability, constraints, and derivation.
To model aggregation on a class diagram:
Draw an association (a line) between the class that represents the member and the class that represents
the assembly. In Figure 6-33 there is an association line between the Agency class and Agent class.
Figure 6-33: How to model an aggregation relationship.
1.
Draw a hollow diamond on the end of the association that touches the assembly class. In Figure 6-33 the
diamond is next to the Agency class that represents the organizations that employ the agents who work for
the theater company.
2.
Assign the appropriate multiplicities to each end of the association, and add any roles and/or constraints that
might be needed to define the rules for the relationship as in Figure 6-33.
3.
Figure 6-33 reads as follows:
An agent may be a part of no more than one agency, but an agent does not have to be part of an agency
(0..1), that is an agent may be independent.
a.
The agency is always comprised of at least one agent but there may be any number of agents (1..*). b.
c.
d.
b.
An agent is considered an employee (role name) of an agency. c.
Every agent is constrained by the fact that she must have a current contract in order to be an employee of
the agency.
d.
<Day Day Up>
<Day Day Up>
Modeling Composition
Composition is used for aggregations where the life span of the member object depends on the life span of the
aggregate. The aggregate not only has control over the behavior of the member, but also has control over the
creation and destruction of the member. In other words, the member object cannot exist apart from the aggregate.
This greater responsibility is why composition is sometimes referred to as strong aggregation. Figure 6-34 shows
that composition is a subset of aggregation, just as aggregation is a subset of association.
Figure 6-34: How to model an aggregation relationship.
Draw this stronger form of aggregation simply by filling in the aggregation diamond. In Figure 6-35, the project
team example uses aggregation, the hollow diamond; employees are assembled into a project team. But if the
team is disbanded, the employees live on (depending, of course, on how well they performed on the project). The
theater event example uses composition, the solid diamond; an event is composed of one or more performances.
The performances would not continue to exist elsewhere on their own. If the event were deleted, the performances
would cease to exist along with the event. In a database environment this is called cascading deletions.
Figure 6-35: How to represent a composition relationship in UML.
The multiplicity provides some clues about the distinction between aggregation and composition. On the project
team example in Figure 6-35, each employee may or may not be a member of a project team (0..*). This tells me
that employees may exist independent from project teams. In fact, an employee may simultaneously participate in
many project teams. Aggregation is a weak association in that it allows the members to participate or not
participate or even participate in other aggregations at the same time.
Composition is exemplified by the event example that says that a performance must be associated with one and
only one event (1..1). This tells me that a performance cannot exist independent of the event. Composition does
allow a member object to be moved to another composite before the original composite is destroyed. But the
member object must always end up inside a composite by the end of the change transaction.
TipAs a point of reference for Java programmers, composition does have a coding equivalent in Java using
the private inner class construct. Private inner classes in Java are inaccessible to any classes other than
the outer class they are created within. As a result, they only serve that outer class and would generally be
garbage collected when the object of the outer class is garbage collected. Although UML and Java
implementations differ slightly, they are close enough to perhaps help you understand composition if you
are already familiar with Java.
Alternative notation in UML 1.4
UML 1.4 provides an alternative notation for composition using a composite object with nested objects. (UML 2.0
offers similar capabilities in the Composite Structure diagram.) A composite object provides the context for
modeling the elements used to construct it. The member elements are drawn inside the context to indicate
containment. Nested containment simply continues the context approach to as many levels as are needed, that is,
you could place objects within one of the performance objects in the same manner that the performances are
placed within the event context. Figure 6-36 provides an example using the event/performance relationship.
Figure 6-36: A composite object.
The composite object is modeled as a rectangle with a name compartment and containment area. The name
appears in the name compartment at the top of the symbol. The name of the object is the name of the class that it
represents-Event, in this example.
The member objects are represented inside the border of the composite object. The member names use the
format role name : classifier, where role name comes from an association end in which the class participates.
Notice that there are three member objects of Event. But all three are of the same class, Performance, each with a
different role name.
The number in the top right corner of the member icons is the multiplicity. According to the multiplicities on the
member objects, we see that creating an event may imply scheduling at the very least one (1..1) premier
performance, and possibly any number (0..*) of "regular" performances, and possibly (0..1) a "closing night"
performance.
In a composite object, as in any type of aggregation, the members of the aggregation may be associated with one
another. For example, for the event in Figure 6-36, the premier performance precedes the regular performances,
which precede the closing night performance.
UML 2.0
UML 2.0 alters the definitions for aggregation and composition just slightly from UML 1.4. The enumeration
AggregationKind and the definitions are summarized in Table 6-2.
Table 6-2: AggregationKind in UML 1.4 and 2.0
UML 1.4 UML 2.0

none none The relationship is a simple association.

aggregate shared Defines a whole/part relationship that implies propagation from the aggregate
object to the part object. If one end is aggregate, the other end must have an
AggregationKind of none. Part objects function as a unit with the aggregate
object. But the part objects may exist independent of the relationship. Part
objects may participate simultaneously in multiple aggregate relationships.
composite composite A strong form of aggregation in which a part object may be a member of no
more than one composite object at any time. "The composite object has the
responsibility for the existence and storage of the composed objects (parts)."
(UML 2.0)
CautionThere is significant debate about the interpretation of composition. The UML 2.0 specification allows a
part object to be removed from a composite and live independently. But it also states that "the
composite object has the responsibility for the existence and storage of the composed objects
(parts)." The debate centers on the question, "If a part exists outside of a composite then how can the
composite be responsible for the existence and storage of the parts?" Some argue that it is a bit like
saying that composition is composition unless it is aggregation and that an object can switch between
the two at will.
<Day Day Up>
<Day Day Up>
Modeling Generalization
Generalization is the process of organizing the properties of a set of objects that share the same purpose. People
use this process routinely to organize large amounts of information. Walk through a grocery store and you will find
foods located in areas of the store depending upon their properties. Dry goods are located in one area, fruits and
vegetables in another, meat in yet another. All of these items are foods, but they are different kinds of foods or
types of foods. Phrases like "kind of" and "type of" are often used to describe a generalization relationship between
classes. For example, a play is a type of event and an agent is a kind of vendor.
You might also hear this type of relationship called inheritance. Many times the terms generalization and
inheritance are used synonymously. That is, if a play is a kind of event, then a play inherits all of the features of an
event. A play is also a specialization of an event because it inherits all of the generalized features of an event and
adds some unique features, or overrides/redefines existing features, which only apply to plays. In the reverse, I
could say that the concept "event" is a generalization of the facts that are true for all plays, concerts, lectures
series, movies, and corporate meetings.
There are six fundamental criteria for specializing or generalizing classes:
Attribute definitions
Attribute domain of values
Operations (signature)
Methods
Associations
Links
We'll cover more about these when we get to discriminators.
Distinguishing generalization from association
A generalization is not an association. In fact, association and generalization are treated as separate types of
relationships in the UML metamodel. The metamodel class Relationship is specialized into associations,
generalizations, flows, and dependencies. Associations define the rules for how objects may relate to one another.
Generalization relates classes to one another where each class contains a subset of the features needed to define
one type of object. Instantiating all the feature subsets from each of the classes in a single inheritance/vertical path
of the generalization results in one object.
For example, take a look at the event generalization in Figure 6-37. To create a Musical object, you would need to
combine the Musical class, the Play class, and the Event class to get all the features - the attributes, operations,
and associations - that define a Musical object. From the combined set of features, you could create (instantiate)
one object of type Musical.
Figure 6-37: Generalization structure with two levels of specialization.
To express the same thing in words, you might say, "A musical is a type of play, and a play is a type of event." For
this reason, you sometimes hear generalization called the "is a" relationship. That is to say, every musical object
"is a" play object and every play object "is an" event object. Note that a musical is not associated with a play. A
musical is a play.
This unique relationship between classes in a generalization raises an interesting problem. In Chapter 4, I
described the concept of visibility. Visibility determines which other objects can see an attribute or operation.
Normally, attributes are set to private so that only objects of the same class may see them. But what would happen
to the Musical class in Figure 6-37 if the attributes of the Play class were set as private? Objects of the Musical
class would not have access to them so inheritance, in essence, is short-circuited. Another visibility, called
protected visibility, is defined to handle just this situation. The protected visibility allows only objects of the same
class and subclasses of that class to see the element.
Note, however, that using protected attributes compromises encapsulation since more classes can now access
those attributes. Thus, in some cases it might be better to keep the data private and let the subclasses use public
get/set operations, or to have private data and protected get/set operations so that only subclasses can affect
those attributes at all, and they still have to use the operations to do so.
Generalization notation
Because the generalization relationship is not a form of association, there is no need for multiplicity, roles, and
constraints. These elements are simply irrelevant.
To explain the notation for a generalization relationship, I first need to define superclass, subclass, abstract class,
and concrete class. A superclass is a class that contains some combination of attributes, operations, and
associations that are common to two or more types of objects that share the same purpose. The Event class and
Play class in Figure 6-38 are examples of superclasses. The term superclass borrows from the superset concept.
A superclass contains only the features that are common to every object in the set.
Figure 6-38: Superclasses and subclasses in a generalization hierarchy.
A subclass is a class that contains some combination of the features that are unique to a subset of the objects
defined by a superclass. In Figure 6-38, all classes except the Event class are examples of subclasses. The Play
subclass contains features that other types of events do not have. The LectureSeries class defines features that
other types of events do not have. Note that a class may be both a superclass and a subclass, as is illustrated by
the Play class.
The term subclass reflects the subset concept. A subclass contains a set of features that is unique among the
objects that make up the set of events. The Musical class in Figure 6-38 contains only features that are unique to
Musical events. A Musical object would get the rest of the information about the features it shares with all other
plays from the Play superclass, and all the features it has in common with all events from the Event superclass. In
other words, it actually takes three classes to generate a single object representing a musical type of event.
To model the relationship between a superclass and a subclass draw a line between them and place a hollow
closed triangle at the end of the line that touches the superclass. The effect is a kind of arrow pointing from the
subclass to the superclass, as modeled in Figure 6-38.
Another way to model the generalization relationship is to merge all of the lines that lead to the same superclass
as shown in Figure 6-39. This is called the shared target style. The previous figures used the separate target style.
Both notations are accepted and commonly used.
Figure 6-39: Shared target style notation for generalizations.
In Figure 6-39 you also see the use of an ellipse () to indicate that there are more subclasses modeled that are
not shown on the diagram. This convention can be useful when working with large diagrams.
An abstract class is a class that cannot be used to create objects, a class that cannot be instantiated. This can be
because the class is explicitly designated as abstract, or because the class defines at least one operation for which
it does not define a method. Without a method, the class does not provide a complete definition for an object. To
create an object, the method must then be provided by a subclass that inherits and overrides the operation. For
this reason only a superclass, a class that is subclassed, can be abstract. Model an abstract class by italicizing the
name of the class, by providing the {abstract} property in the name compartment, or by adding the {abstract}
property to the operation that does not have a method, as shown in Figure 6-40.
Figure 6-40: Alternatives for modeling an abstract class.
A concrete class is a class that has a method for every operation so that it can create objects. The methods may
be defined in the class itself or inherited from a superclass. For this reason all classes at the bottom of a
generalization hierarchy, called leaf nodes or leaf classes, must be concrete. That is because there are no
subclasses beneath them that could provide the missing method/s. Since a superclass can provide its own
implementations for all of its operations any superclass may also be concrete.
Figure 6-41 summarizes the abstract and concrete options for the event generalization hierarchy.
Figure 6-41: Abstract and concrete classes.
CautionFigure 6-41 is incorrect in one respect. In the generalization hierarchy in a framework such as the
Java SDK, a leaf class is only the bottom of the framework. The classes at the bottom of the
generalization hierarchy in a framework are not actually leaf classes because the framework
hierarchy does not include classes that extend the framework. We don't see the classes that
specialize the framework until a developer builds an application using the framework classes. So leaf
classes in a framework can be, and usually are, abstract.
Powertype and discriminator
When modeling generalization you need to describe how you choose to identify the set of subclasses for a
superclass. If, for example, you want to organize the information about types of cars, you could distinguish different
types of cars based on price range, manufacturer, engine size, fuel type, usage, or any number of other criteria.
The discriminator you choose depends on the problem you are trying to solve. In Figures 6-38 through 6-41, the
event concept is partitioned into types of events. This form of subclassing utilizes a powertype. A powertype is a
standard stereotype applied to classes and dependencies. It is a metaclass that overlays the subclass in the sense
that it redefines the superclass into a set of subclasses that correspond to its own instances. Those powertype
instances/subclasses together define all possible objects of the superclass. In the event example we defined a set
of subclasses for all possible event types.
Figure 6-42 shows the powertype documented as a class with the powertype stereotype (a UML standard
element). To represent that the powertype explains the subclassing of the Event class, draw a dashed line across
the three generalization arrows to the powertype class.
Figure 6-42: Identifying subclasses using a powertype.
Powertypes are one way to define the subclasses. Another way is to use one or more properties of the objects
themselves like size, price range, capacity, or age. For example, concerts might be partitioned based on the size of
the performance, such as a solo performing with no band, a solo with a band size less than 10, a group with
backup size less than 10, and group with backup size greater than 10. Using properties of the class utilizes a
discriminator. A discriminator identifies features of the superclass itself that are used to distinguish the subclasses.
The effect is the same as with powertypes, a set of subclasses that together define all possible objects of the
superclass.
Figure 6-43 models the generalizations for Event with a discriminator on each generalization. Since I used the
shared target style of generalization lines and the same discriminator for all subclasses on the same branch (Solo
and Group both subclass Concert), the discriminator appears once on the branch. In the same manner Solo and
Group are each subclassed using the backupsize as the discriminator.
Figure 6-43: Applying a discriminator to define subclasses.
Classes define a set of features, and these features are the possible discriminating properties. If objects of the
class share the same attributes such as age and address, for example, they might be in the same subgroup.
However, objects might have the same attribute (such as age) but the values allowed for age in some of the
objects are different from those allowed in others. For example, every Person has an age value assigned.
However, minors would have age values of less than, say, 21 and adults would have ages greater than 20.
The same concept applies to operations. Objects might have the same operation, that is, the same interface, like
"accelerate." But different objects might implement that interface in very different ways. For example, different cars
accelerate using different combinations of parts and fuels.
In summary there are at least six objective criteria to use to discriminate between objects within the same class
(superclass):
Attribute type
Attribute values allowed (domain)
Operation (interface)
Method (implementation)
Associations
Links
Modeling multiple generalization
Figure 6-44 depicts multiple generalizations on a single superclass. The model shows that the same superclass
may be subclassed using multiple criteria. Using two discriminators results in two sets of subclasses for the same
superclass. This approach allows there to be two representations of the same object, one from each
discriminator's perspective. In other words, the same solo performer might be represented by an instance of the
Solo class and an instance of the SmallBackup class. That is why all of the classes in a multiple generalization
must be abstract.
Figure 6-44: Modeling multiple discriminators.
To get concrete classes that can generate objects you have two options: you can combine the discriminators to get
four subclasses of Event that represent all of the possible combinations, or you can use multiple-inheritance to
bring the separate class definitions together into one new class. Figure 6-44 models multiple-inheritance with the
Solo-SmallBackup class, which inherits from both the Solo and SmallBackup classes.
NoteWhether or not multiple-inheritance may be used as an implementation depends on the programming
language used to implement the model, and the local development standards. For example, C++ does
allow multiple inheritance, but Java does not allow multiple inheritance of classes.
Constraints
The generalization example shown in Figure 6-44 begs for some clarifying notation. Specifically, how do we know
when the subclasses are allowed to overlap and when they must not overlap? If we can find a way to document
these rules, then could we also document other rules? Yes, you can use UML constraint notation to model these
rules. UML predefines four constraints for use on generalization relationships:
Overlapping
Disjoint
Complete
Incomplete
Figure 6-45 models the {overlapping} constraint as an example of the use of the notation. A dashed line crosses
the generalization lines affected by the {overlapping} constraint. In this example there are two sets of overlapping
generalizations, performersize overlaps backupsize.
Figure 6-45: Modeling generalization constraints.
The overlapping and disjoint constraints refer to whether or not an instance may be represented by more than one
subclass.
The overlapping constraint applies to generalizations that are based on multiple discriminators or powertypes, like
the diagram in Figure 6-45. The overlapping constraint allows an instance to derive from multiple classes that are
specializations based on different discriminators or powertypes. In the Event example, the same performer may be
an instance of both the Solo class and the SmallBackup class.
The disjoint constraint prevents any overlap. An instance may not be represented by more than one subclass at
the constrained level of the hierarchy. In the Event example, use of the disjoint constraint (instead of the
overlapping constraint) would mean that the same performer cannot be represented by the Solo class and the
SmallBackup class.
The complete and incomplete constraints document the status of the diagram.
The complete constraint documents the fact that every possible subclass of a generalization has been identified
and modeled. That is not to say that they have to be illustrated in the current view of the diagram. The ellipse may
be used to indicate that other classes are defined but not shown.
The incomplete constraint documents the fact that the research on the possible subclasses (specializations) is not
finished. We know that there are probably more but they are not yet modeled.
Figure 6-46 shows an example using both types of constraints, overlapping/disjoint and complete/incomplete,
together. Whenever you have to model more than one constraint on the same generalization, use commas to
separate them within the same pair of curly braces.
Figure 6-46: Applying constraints to a generalization.
UML 2.0
Most of the changes in UML 2.0 are changes to the metamodel. UML 2.0 has introduced two new concepts; the
attribute isSubstitutable and the GeneralizationSet.
The metamodel has eliminated the isRoot attribute and moved the isLeaf attribute to the RedefineableElement
metaclass. The role names for the classifiers that participate in a generalization relationship have changed
from child and parent to specific and general to more closely parallel the concepts of specialization and
generalization. Also, the attributes for defining abstract classes and for designating classes as the leaf or root
in a generalization hierarchy have been moved.
The isSubstitutable attribute indicates whether the specific classifier can be used wherever the general
classifier can be used.
The GeneralizationSet is a new metaclass that simplifies the specification of discriminators, powertypes, and
constraints. The complete/incomplete constraint is renamed and assigned an attribute called isCovering.
A Generalization is a type of directed relationship as modeled by the diagram in Figure 6-47. Every directed
relationship has a target classifier and a source classifier. For a generalization, the target is the superclass,
identified by the role name general. The source is the subclass, identified by the role name specific.
Figure 6-47: The Generalization metamodel.
OMG 2.0
As in UML 1.4, a general class may be designated as abstract. UML 2.0 defines an abstract class setting the
isAbstract attribute in the classifier to true. A leaf or terminating class (a class that cannot be subclassed) is defined
by setting the isLeaf attribute inherited from the RedefineableElement metaclass. The isRoot attribute has been
dropped in UML 2.0.
Cross-Reference For a complete explanation of abstract, concrete, and leaf classes refer to the earlier
sections in this chapter that covered generalization.
The isSubstitutable attribute of the Generalization metaclass is a Boolean value that defaults to true. If true, an
instance of the specific classifier can be used wherever a reference is made to the general classifier. However,
when doing so the substituted classifier conforms to the interface of the general classifier. Specialized features of
the specific instance cannot be accessed without explicitly redefining the specific classifier into its specific type.
Cross-Reference See also the Substitution dependency in the UML 2.0 Superstructure :: Structure ::
Classes :: Dependencies package.
To support discriminators, powertypes, and constraints UML 2.0 adds the concept of a generalization set shown in
Figure 6-48. A generalization set may be applied to many generalizations. A generalization set may use a classifier
as a powertype.
Figure 6-48: Defining a generalization set as a collection of generalizations on the same classifier.
OMG 2.0
The new GeneralizationSet class represents what used to be accomplished by assigning the same discriminator or
powertype to groups of generalizations on the same superclass. Now instead of labeling each generalization you
will name the set of generalizations once. (The generalization set can be named because it is a specialization of
PackageableElement which is a type of NamedElement.) The discriminator name in UML 1.4 is now the name of
the generalization set in UML 2.0. Optionally, a generalization set can be associated with a classifier as the
powertype for a set of generalizations.
The UML 2.0 notation adds a colon in front of the powertype name. The constraint notation is the same except that
the generalization set name may also appear as the first item within the curly braces. Figure 6-49 shows the
revised notation.
Figure 6-49: UML 2.0 notation for powertype associated with a generalization set with constraints.
The new GeneralizationSet class also contains the attributes isDisjoint and isCovering. Setting these attributes
replaces what used to be modeled as disjoint/overlapping and complete/incomplete and constraints in UML 1.4.
isDisjoint is a Boolean value. When isDisjoint is true then each instance of the superclass can be instantiated
by exactly one instance of one of the subclasses of the generalization set. This corresponds to the UML 1.4
{disjoint} constraint. When isDisjoint is false then instances of the superclass can be instantiated by multiple
subclasses of the generalization set. This corresponds to the UML 1.4 {overlapping} constraint.
isCovering is a Boolean value. When isCovering is true every possible instance of the superclass can be
instantiated as an instance of at least one of the subclasses of the generalization set. This corresponds to the
UML 1.4 {complete} constraint. When isCovering is false there may be instances of the superclass that cannot
be instantiated by any of the subclasses of the generalization set. This corresponds to the UML 1.4
{incomplete} constraint.
Now this is where it gets really confusing. UML 2.0 has replaced the standard constraints complete and incomplete
with the Boolean attribute isCovering. But for modeling the values for the isCovering attribute, UML 2.0 still uses
the terms complete and incomplete. Table 6-3 lists the allowed combinations of isCovering and isDisjoint and a
brief explanation of their meanings.
Table 6-3: Using isCovering and isDisjoint Together
Valid
combinations
Interpretation
{complete, disjoint} Every instance of the general class of the generalization set can be instantiated by
at least one of its subclasses, and its subclasses have no common instances.
{incomplete,
disjoint}
Not every instance of the general class of the generalization set can be instantiated
by at least one of its subclasses, and its subclasses have no common instances.
{complete,
overlapping}
Every instance of the general class of the generalization set can be instantiated by
at least one of its subclasses, and its subclasses do share common instances.
{incomplete,
overlapping}
Not every instance of the general class of the generalization set can be instantiated
by at least one of its subclasses, and its subclasses do share common instances.
<Day Day Up>
<Day Day Up>
Modeling Dependency
There are times in modeling when it is appropriate to address a higher level of abstraction than classes and
associations. For example, before you ever get to the details of how to design the marketing portion of the theater
system, you might need to document the fact that marketing depends on facts captured by the sales portion of the
theater system.
Dependency represents a client-supplier relationship in which a change to the supplier requires a change to the
client. Using the marketing/sales example, a change to the sales portion of the system would require changes to
the marketing portion of the system. In practical terms this means that the marketing system needs to access
specific interfaces provided by sales. If and when those interfaces change, marketing can no longer access sales.
Dependency may also represent precedence. The ticket payment screen in the theater application requires the list
of tickets that the customer wants to purchase before it can work properly. But the tickets are selected on a screen
that provides access to the seating chart for the performance. The dependency here represents the fact that the
seating chart screen needs to precede the ticket payment screen in the workflow.
Dependency notation
A dependency is modeled using a dashed arrow between model elements, one or more clients, and one or more
suppliers. Figure 6-50 models a package dependency (on the left) between the Marketing package and the Sales
package and a class dependency (on the right) between the TicketSelectionScreen class and the
TicketPaymentScreen class.
Figure 6-50: Modeling dependency notation.
UML predefines four general types of dependency: abstraction, binding, permission, and usage. These four
general types are refined into more specific types. Abstraction, for example, models a difference in the level of
abstraction between the two model elements. The migration from one level of abstraction to another level may be
achieved through refinement or realization (implementation). For example, a project involves phases, and the
models created during the analysis phase are refined in the design phase and finally realized or implemented in
the coding phases. Figure 6-51 models the type of dependency between the Analysis and Design packages as
refinement. That is, the contents of the Design package represent a refinement of the contents of the Analysis
package. Likewise, the contents of the Implementation package represent a realization or implementation of the
contents of the Design package.
Figure 6-51: Modeling refines and realizes dependencies.
The dependency arrows may also merge, as modeled in Figure 6-52. ClassC is a refinement of ClassD and
ClassE. The comment attached to the dependency explains the meaning of the merge, that ClassC combines
ClassD and ClassE.
Figure 6-52: Merging dependency lines.
Cross-Reference UML provides a specific notation for the realization dependency when used in the
context of interface classes and components. These notations and their usage are
explained in Chapters 5 and 15.
Predefined dependency types
UML has predefined a set of stereotypes for use with dependencies between packages, classes, and other
classifiers. Table 6-4 lists these predefined stereotypes along with an explanation of where they are used and how
to interpret them.
Table 6-4: Predefined Dependency Types
General
Type
Specific
Stereotype
Description
Permission access The supplier package grants permission to the client package to
access its member. Access is limited by the visibility of each
member.
Binding bind Refers to binding template parameters to actual values to create a
non-parameterized element. (Template classes are covered in
Chapter 4.)
Abstraction derive Similar in use to derived attributes. The client is computed or figured
out using the supplier/s.
Permission import The supplier package grants permission to the client package to
access public members and to make those members' names part of
the client package.
Abstraction refinement The client represents enhancements, merging, alterations, and other
such improvements to the contents of the supplier/s.
Abstraction trace An historical relationship representing the evolution of members over
time as in the tracing of requirements through the models and finally
into the implementation.
Usage use, call,
instantiate,
send
Represents the requirement of the client to have access to the
supplier member/s in order to function properly. The nature of the
usage may be qualified with any of the usage stereotypes to further
explain the nature of the requirement.
UML 2.0
UML 2.0 adds one new concept called a substitution dependency. As modeled in Figure 6-53, substitution is a type
realization. That is to say, substitution is another way that a classifier might be implemented. The client in a
substitution dependency takes the place of the supplier classifier.
Figure 6-53: Adding the concept of substitution. $OMG 2.0.
This concept could be especially useful for modeling customizations. For example a retail system designed to sell
lines of sporting goods could be customized to sell music and videos. One set of products might be substituted for
another while the rest of the system design remains the same.
Figure 6-54 illustrates the use of the substitution dependency in an example where a system designed to create
reservations is implemented to reserve seats at shows. The ShowSeat class is substituted for the Reservation
class everywhere in the application where reservation is referenced. To do so, the ShowSeat has to conform to the
contract or interface established by the Reservation class.
Figure 6-54: Using the substitution dependency.
<Day Day Up>
<Day Day Up>
Summary
UML supports four distinct types of relationships; association, generalization, dependency, and flow (flow is
covered with Activity diagrams in Chapter 13).
Associations and links: A link is the simplest form of relationship that supports communication between
objects. Two objects are aware of one another because they own references to one another. An association
defines a type of link that may exist between types of objects. A link is an instance of an association in the
same way that an object is an instance of a class.
Multiplicity: Each end of an association must define the number of objects that may participate in the
association. Multiplicity can be expressed as a range (min. max) or an enumeration of values (value, value,).
An asterisk (*) used by itself designates zero or more objects. An asterisk used as the maximum value in a
range means "more", or no upper limit.
Constraints: A constraint is a rule that must be enforced for the association to be valid. A constraint is placed
at the end of an association to dictate the conditions that have to be satisfied before objects (of the type at the
association end) can participate in the relationship. Constraints are enclosed in curly braces ({ }).
Role names: A role name explains how an object participates in a link. The role name is placed at the end of
an association next to the class (type of object) that plays the role.
Association class: An association class encapsulates information about an association; for example when
the relationship started, ended, terms and conditions, and status. An association class is a class that is needed
or discovered because it explains an association. The association class is attached to an association by a
dashed line.
Reflexive association: A reflexive association defines a type of relationship that may exist between
objects of the same type/class.
Aggregation: Aggregation is a type of association in which one class defines the objects that participate
as parts in an assembly or configuration and objects of the other class represent the whole, the entire
assembly.
Composition: Composition is a type of aggregation in which a member object may only be a part object
of at most one aggregate object.
Navigability: Each end of an association is designated as undefined (no notation), navigable (an arrow
on the end of the association), or not navigable (an X' on the end of the association).
Generalization, superclass, and subclass: Generalization provides a means for organizing similarities and
differences among a set of objects that share the same purpose. Generalization is a relationship between
classes in which one class called the superclass, contains features shared by all objects of the class, and the
other class, called the subclass, contains only the features that make a subset of objects different from all
other objects represented by the superclass. Generalization is modeled as a line between classes with a
closed and hollow triangle at the end near the superclass.
Specialization: Specialization describes the process of identifying the features that make objects unique
within a superclass. "A specialization" refers to an individual subclass.
Inheritance: Inheritance describes the fact that a subclass has access to the features of a superclass at
the time that it is used to instantiate an object. Inheritance can be compromised by the use of visibility
restrictions.
Abstract, concrete, and leaf classes: An abstract class cannot be instantiated either because it is
designated as abstract using a property in the name compartment, or because at least one operation in
the class does not have a method.
Powertype and discriminator: Subclasses may be identified by the use of a powertype or a
discriminator. A powertype is a class whose instances are subclasses of a superclass. A discriminator
identifies the criteria used to differentiate the subclasses from one another. UML 2.0 uses a
generalization set to encapsulate the discriminator name, optional powertype and constraints for a set of
generalization relationships for the same superclass.
Generalization constraints (isCovering and isDisjoint): Generalization constraints describe the use of
subclasses in a generalization. The isCovering constraint (formerly called complete/incomplete)
describes whether every possible object of the superclass can be described using at least one subclass.
The isDisjoint constraint describes whether an object can be an instance of more than one subclass of
the same superclass.
Dependencies (refinement, realization, etc.): A dependency represents a high-level abstraction of the
relationship between model entities such as classes or packages. A dependency defines only the
existence of some kind of relationship without specifying the type of relationship. The general nature of
the dependency can be described using a stereotype such as include, extend, realization, or
refinement.
<Day Day Up>
<Day Day Up>
Chapter 7: Testing with Objects
Overview
The Object diagram provides the means to explore specific facts. The Class diagram models definitions and rules.
The contrast of these two diagrams is a great benefit to modelers. Most often we talk about a problem using
concepts and general rules about how things work. When there is a dispute over the interpretation of a concept or
a rule, we often apply examples, specific data, and circumstances that either prove or disprove our interpretation.
The Object diagram is the UML tool for modeling an example.
Throughout a project we want to verify that what we have modeled is accurate. Verification requires test cases that
exercise the definitions and rules we've captured in our Class diagram. Modeling a test case requires the means to
represent specific data, relationships, and behaviors. The Object diagram is ideally suited to model the data and
relationships of the test cases, while the Interaction diagrams model the behavior. Interaction diagrams (covered in
Chapters 8 through 10) describe how objects use one another's services. Together they can represent a complete
view of a test case.
In UML 1.4, the Object diagram is described as distinct from the Class diagram. In UML 2.0, it is included with the
Class diagram. This is not really a change. In modeling tools, the Object diagram has always been drawn in the
same canvas with the Class diagram. Figure 7-1 shows an example of classes and objects on the same canvas in
the Magic Draw 6.0 modeling tool. The Customer and Venue classes are on the left. The objects-an instance of
Customer called Kevin and an instance of Venue called Luxury Theater-are on the right.
Figure 7-1: Drawing classes and objects in a modeling tool.
No Magic
UML 2.0 has added another tool, the Composite Structure diagram, which blends the UML 1.4 Composite Context
diagram, pattern structure notation, and collaboration roles. The goal of the Composite Structure diagram is to
model the parts of a configuration, explaining the roles of each part in terms of how they work together to fulfill the
purpose of the configuration.
This might sound familiar after reading about aggregation and composition in Chapter 5. The Composite Structure
diagram supports modeling of any type of aggregation. An aggregate object contains parts. The parts are linked
together and play specific roles in the configuration. One significant difference between the old Composite Context
diagram and the new Composite Structure diagram is the addition of ports, which are much like interfaces. Ports
add a description of the communication links between objects that was not present in UML 1.4. The added value is
that it is now easier to verify the need for a specific interface by associating it with a pattern of behavior in which it is
required. Mapping the port to an object also helps verify that the correct resource is given responsibility for the
communication. (Note that this is an overlap with the features of the Interaction diagrams. Overlap can be another
aid in verification).
<Day Day Up>
<Day Day Up>
Modeling Objects and Links
To begin modeling an Object diagram we need objects. Objects represent real things such as a specific customer,
a specific venue, or a specific performance. Contrast this with a class, which represents a definition of real things
such as customers, venues, or performances in the theater system.
Object notation
Object notation requires two elements: the name of the object and the name of the class that describes the object.
The format for the object name notation is
object-name : class-name
NoteThroughout the book I often include spaces in the expression syntax. The spaces are not part of the
syntax. They simply make the expression syntax easier to read.
The object name is often the value of the "name" or other identifying attribute of the object. The class name helps
remove the ambiguity caused by the fact that objects of different types may have the same name. For example,
Tom Pender might be the name of a customer and an employee. The class name also brings with it the class
definition, which defines what attributes the object can possess. Also note that the object name expression is
always underlined.
Examples of object notation include Kevin : Customer, Jackie : Customer, "Pender's Luxury Theater" : Venue, and
73865 : Performance.
The format ": class name"-without the object name - is called an anonymous object. It simply means that what you
are modeling applies in the same way for any instance of the named class, and that providing a specific example
adds no new information. This is actually a very common technique.
One other naming option is valid, and that is to omit the colon and class name (in other words, to use only the
name of the particular object without telling what kind of class it is an instance of) if the context makes it obvious.
NoteThe same object name notation is used in all the Interaction diagrams.
The object name notation is enclosed in a rectangle just like a class. Figure 7-2 models customers named Kevin
and Jackie, and an anonymous object of the Venue class. The entity stereotype symbols are optional. If a class is
stereotyped, the tool will often automatically include the stereotype along with the name when modeling objects of
the stereotyped class.
Figure 7-2: Two objects of type Customer, Kevin and Jackie, and one anonymous Venue object.
Cross-Reference The entity stereotype symbol is explained in Chapter 3.
An instance of a class may possess its own unique values for each class attribute. Taken together, these attributes
represent the state of the instance, and often play a valuable role in examples and test cases. Showing them in the
diagram facilitates verification of the Class diagram and evaluation of the test cases and examples. Like attributes
of a class, Object attributes are modeled in a second compartment, below the name compartment.
An Object diagram does not include the attribute definition (type, visibility, and so forth). It shows the attribute
names and values in an assignment statement, like, name = "Kevin". The diagram simply lists the attribute names
and values in the second compartment, as shown in Figure 7-3. The attribute definition defines the set of valid
values for each attribute. In some cases, a blank or null value for an attribute is valid.
Figure 7-3: Modeling object attributes.
Link notation
Objects not only have their own data, but they also participate in relationships, called links. The associations on a
Class diagram define the types of links that objects are allowed to participate in. Just as a class defines a type of
object, an association defines a type of link. Just as an object is an instance of a class, a link is an instance of an
association.
When two objects enter into the type of relationship specified by an association, they are said to be linked. A link is
modeled as a line between two objects. A link may be named in three ways: it may bear the same name as the
association that describes it, or it may be described using the role names defined at the ends of the association, or
role names that coincide with the participating class names. Figure 7-4 models a venue that "holds" an event,
where "holds" is the association name. Figure 7-4 also shows two performances scheduled for the event. The
performance-event links use role names that coincide with the class names.
Figure 7-4: Modeling links.
<Day Day Up>
<Day Day Up>
UML 2.0
UML 2.0 defines objects as instances using the InstanceSpecification metaclass. Figure 7-5 represents an
InstanceSpecification as a model element that can be part of a package and may be associated with any number
of classifiers. A classifier may be a class, an association, a data type, and so forth. So an InstanceSpecification
may describe an object of a class, a link of an association, or an instance of a data type. This means that the
instance concept explains both objects and links on an Object diagram.
Figure 7-5: The relationship between instances and slots.
OMG 2.0
UML 1.4 defines a slot as a role played by a metaclass that represents a connection between an attribute and an
instance, the Attribute Link metaclass. UML 2.0 changed the name of the metaclass from AttributeLink to Slot. A
slot is a place that holds a value. Each slot corresponds to a structural feature of the classifier. For a class, a
StructuralFeature refers to an attribute. For an association, this means the isDerived attribute. An
InstanceSpecification may have as many slots as it needs; for example an object could have no slots or 50 slots or
more, as long as they correspond to structural features defined by the associated classifier.
When modeling an instance you do not need to represent every known attribute. Object diagrams represent test
cases and examples; they only need to model the information relevant for the particular exercise. The class
definition maintains the definitive list of attributes.
Figure 7-6 adds the metamodel elements that explain how to capture the values for the slots on an
InstanceSpecification. Each slot has zero or more ordered values that describe the instance. A slot may be empty,
meaning there is no value for the instance at the point in time that is represented by the Object diagram. A slot may
have many values-for example, as in an array of references to seats reserved on an order.
Figure 7-6: Adding the ValueSpecification to store values for each slot.
No Magic
The relationship between InstanceSpecification and ValueSpecification supports the idea that an instance may be
derived or computed. The ValueSpecification, if needed, provides the details about how to perform the derivation
or computation. For example, an order can make reference to the discount used to compute its net price. The
choice of discount is based on a set of rules that qualify the order for a specific discount.
<Day Day Up>
<Day Day Up>
Comparing Class and Object Diagrams
Figure 7-7 shows a Class diagram containing the rules regarding Customer and Order and the relationship
between the two types of objects (one customer places zero or more orders and each order is placed by exactly
one customer). The Class diagram defines the attributes that must be used to define each type of object and the
behaviors that each type of object must support.
Figure 7-7: UML Class notation for an association between two classes.
The Object diagram in Figure 7-8 shows that object Kevin of type Customer has placed two orders. Although each
attribute for the three objects in this example is assigned a value, remember that it is valid for attributes to be blank
or null if the attribute definition in the class allows it.
Figure 7-8: UML object notation for one customer who has placed two orders.
Note that the Object diagram is missing part of the information that is required in every Class diagram: the third
compartment, containing the operations. In the Class diagram, you must include the attributes because each
object potentially possesses different values for the attributes defined by the class. But the class defines an
operation that does not have multiple interpretations or values. Every object of the same class possesses the
same operations. To model, the operations again on the Object diagram would add redundancy without adding
new information. So the operations do not appear on the Object diagram.
Table 7-1 shows a side-by-side comparison of the features of Class and Object diagrams. A working knowledge of
the relationship between these two types of diagrams will help you understand how to use them both to facilitate
analysis and to test the results of your analysis and design efforts.
Table 7-1: Comparison of the Class and Object Diagrams
Class Diagram Object Diagram
The class has three compartments: name,
attribute, and operation.
The object has only two compartments: name and
attribute.
The class name stands alone in the class name
compartment.
The format for an object name is object name, colon,
class-name (1234 : Order), with the entire expression
underlined. You will encounter this notation in other
diagrams that model objects. An anonymous object
uses only the colon and class-name (: Order).
The class attribute compartment defines the
properties of the attributes.
The object defines only the current value of each
attribute for the test or example being modeled.
Operations are listed in the class. Operations are not included in the object because
they would be identical for every object of the same
class.
The classes are connected with an association
that is defined with a name and/or roles,
multiplicity, and constraints. A class represents a
"classification" of objects, so it is necessary to
specify how many may participate in the
association.
The objects are connected with a link that has a
name, and/or roles, and no multiplicity. An object
represents a single entity. All links are one to one, so
multiplicity is irrelevant.
<Day Day Up>
<Day Day Up>
Using the Object Diagram to Test the Class Diagram
Drawing a Class diagram and incorrectly assuming that it's right is very easy to do. That's why you need to use
additional diagrams to test the Class diagram. For example, if I brought you the Class diagram in Figure 7-9, which
models the sales agreements and seats in the theater application (sure that it's too simple to be wrong), you could
test my diagram with an Object diagram. If you did, you might find some problems and be able to provide objective
proof that the Class diagram needs to be changed.
Figure 7-9: Initial Class diagram for sales agreements and seats.
Sales agreements define the seats that are assigned to an agent for a specified period of time. These seats
comprise the agent's sales territory within the venue. Figure 7-9 tells you that each sales agreement may assign
one or more (1..*) seats and that each seat is assigned to one (1 or 1..1) sales agreement.
The rest of this section steps through the construction of a set of Object diagrams that model the test cases for the
sales agreement Class diagram in Figure 7-9. The construction process demonstrates the model elements of the
Object diagram and how the Object diagram illustrates test cases.
As I explain each test case you might spot more problems with the original Class diagram than the current test
case reveals. By the time we finish all of the test cases, we will have found all the problems.
Test case 1
First, I create a new sales agreement (6475) and assign two seats (2875 and 2876). Figure 7-10 shows the three
new objects. The Object diagram tells us that the sales agreement assigns two seats. The Class diagram allows
this. The Object diagram tells us that each seat is assigned by one sales agreement. This also agrees with the
Class diagram. So far so good.
Figure 7-10: The Object diagram for test case 1 confirms the Class diagram.
Test case 2
Does every seat have to be assigned by a sales agreement? After reviewing all the test data obtained from
interviews with clients, we find that some seats have never been assigned to an agent. They have always been
available for direct sale to the public. Figure 7-11 adds a seat (1450) that is not assigned by any sales agreement.
Figure 7-11: The Object diagram with an unassigned seat.
The Class diagram said that every seat had to be assigned, using a multiplicity of 1 (short for 1..1). If this test data
is correct, we need to update the Class diagram to allow the possibility that a seat might never be assigned by a
sale agreement. Figure 7-12 shows the updated Class diagram, which says that a seat may be assigned by zero
or one sales agreement (0..1).
Figure 7-12: The updated Class diagram.
Test case 3
Is there evidence that a seat could be assigned by more than one sales agreement? A review of the test data and
the current system reveals that this is possible. In fact, many seats are assigned and reassigned repeatedly over
the life of the system. Figure 7-13 shows that the two original seats (2875 and 2876) have been assigned by two
different sales agreements (6475 and 6494).
Figure 7-13: Seats assigned by two different sales agreements.
But note the attribute values for the sales agreements. The dates do not overlap. A brief conversation with the
clients confirms that it would violate the theater-agent contracts to assign the same seat to two different agents for
the same period of time.
This one test case has revealed two problems with the original Class diagram:
A seat may be assigned by any number of sales agreements, not just one. 1.
The time periods for the sales agreements that assign the same seat may not overlap one another. 2.
Figure 7-14 models the revised Class diagram with modified multiplicity and a new constraint. Zero or more (0..*)
sales agreements may assign the same seat, but for time periods that do not overlap.
Figure 7-14: Updated Class diagram with revised multiplicity and a new constraint.
Test case 4
Interviews with the clients reveal that our model needs to support their ability to define groups of seats for
assignments. For example, they want to be able to select a predefined block of 200 seats from the west side and
another predefined 200-seat block from the east side of the venue quickly. The current model requires that they
choose each of the 200 seats separately each time. Figure 7-15 models a new kind of object called SeatGroup
that identifies a set of seats. The venue manager may now assign either groups of seats or individual seats.
Figure 7-15: Adding the new SeatGroup to facilitate seat assignments.
This approach also supports common grouping mechanisms such as grouping seats into rows and rows into
sections. In other words, you can make groups from other groups, as in making sections out of rows.
The addition of the seat groups requires a change to the Class diagram. Figure 7-16 shows that a sales agreement
may be set up with groups of seats as well as individual seats.
Figure 7-16: Revised Class diagram with seat groups.
Note the changes revealed by this test case:
A seat group defines an aggregation of 2 or more (2..*) seats, modeled by the aggregation type of association
between SeatGroup and Seat, where SeatGroup is the aggregate and Seat is the member/part.
Now a sales agreement may assign either individual seats or seat groups. Also, any given sales agreement
might not assign any individual seats (0..*) or any groups (0..*) so the minimum multiplicity drops to zero for
both association ends. But this poses a problem because we need to make certain that at least one seat or
seat group is assigned. The current Class diagram (Figure 7-16) allows a sales agreement with zero seats
and zero seat groups. Hold that thought (we'll call it the "zero" problem) while we refine the Class diagram
based on what we have learned.
There is also a problem with the composition of seat groups. The revised Class diagram says that every seat
group must contain at least two (2..*) seats and at least two (2..*) seat groups. We'll call it the "two minimum"
problem. This still isn't quite what the clients want.
Class diagram refinement
The new model provides the flexibility that the clients want and need, but it leaves us with the "zero" and the "two
minimum" problems, and requires the users to consciously choose between working with groups of seats and
working with individual seats.
Further examination tells us that seats and seat groups have a lot in common:
They are both assigned by sales agreements.
They both designate locations within the venue.
They both may be a member of a group.
Perhaps generalizing the two types of objects could help solve the "zero" and the "two minimum" problems, and
provide a means to help the clients use both objects in exactly the same manner thereby simplifying their work.
Figure 7-17 adds a new superclass, called Location, which embodies the common properties of seats and groups
of seats. That is, they both can be assigned by a sales agreement, and they both can be a member of a group.
Location is specialized into individual seats and seat groups. Now a sales agreement may assign any type of
location in the same manner, whether the location is a single seat or 500 seats organized into a section composed
of 10 rows that are each composed of 50 seats. Both are simply locations.
Figure 7-17: Revised Class diagram with the Location generalization.
How does this new Class diagram solve the problems identified earlier?
The revised Class diagram says that a sales agreement must have at least one (1..*) location. It doesn't matter
what type of location; any type, a seat or a seat group, will do. This solves the "zero" problem.
The revised Class diagram solves the "two minimum" problem of needing two seats and two seat groups to
form a seat group by saying that a seat group is formed from two locations. Again, any type of location will do.
The group may be formed using at least two seats, two seat groups, or a seat and a seat group.
NoteBy the way, the Location generalization combined with the aggregation between the subclass SeatGroup
and the superclass Location is an example of the "Composite" design pattern (not to be confused with
composition).
In summary, use the Object diagram on an as-needed basis to model specific examples or test cases. Use
examples to discover how to draw the Class diagram. Use representation of the facts (test cases) in the Object
diagram to test the representation of the rules set forth in the Class diagram. Adjust the Class diagram to address
errors and missed requirements.
<Day Day Up>
<Day Day Up>
Modeling the Composite Structure diagram (UML 2.0)
A Composite Structure diagram models the parts of a class, component, or collaboration, including the interaction
points (ports) used to access features of the structure. The visual concept comes from the old Composite Context
diagram of earlier UML versions.
Figure 7-18 models a simple Composite Structure diagram of a pricing strategy from the theater system. A pricing
strategy is built using a discount and a set of price tiers.
Figure 7-18: Composite Structure diagram of a pricing strategy.
The Composite Structure diagrams also model collaborations. A collaboration describes a behavior, the resources
used to perform the behavior, and the roles the resources assume during the behavior. Figure 7-19 models a
collaboration in which a venue manager secures the services of an agent.
Figure 7-19: A Composite Structure diagram representing a collaboration.
Modeling a class and its parts
The Composite Structure diagram models a class as a large rectangle with the class name in a compartment at
the top of the rectangle, as the two examples in Figure 7-20 show. The classes that define the parts of the
containing class reside within the body of the class rectangle. The classes (whether containers or parts) play
various roles depending on the purpose of the specific test case. Pay particular attention to the instances of the
SeatGroup class depicted in the figure.
Figure 7-20: Class notation in a Composite Structure diagram.
On the left is a SeatGroup class taken from the example in Figure 7-17. The seat group is playing the role of a row
(/Row), which is made up of a set of seats. The seats are modeled as an instance with a multiplicity value enclosed
in square braces [ ] stating how many parts are contained in the class. In this example, a row is made up of 20
seats. In the middle example in Figure 7-20, a seat group playing the role of a section (/ Section) contains 10 seat
groups, each playing the role of a row.
On the right in Figure 7-20, the section contains rows that contain seats. As of this writing, UML 2.0 does not
explicitly allow nesting of StructuredClassifiers. In UML 2.0 the / Row : SeatGroup instance on the right cannot be
broken down to show the member Seat instances in the same diagram so the seat group on the right would be
invalid.
Modeling connectors and ports
The Composite Structure diagram also models the way the parts of an aggregate object are connected to function
properly. For example (departing from the theater system momentarily), a car is constructed with an engine, a
transmission, and a fuel pump (and many other parts). The engine must receive fuel to run, and it must be
connected to the transmission in order to power the car. Figure 7-21 models the Car class and three part objects:
the engine, the transmission, and the fuel pump. The connectors are the lines between each pair of parts.
Figure 7-21: Connectors and ports.
The small squares at the ends of the connectors model ports, the points of contact between the connector and the
object. A port defines a distinct interaction point on the object. A port may specify the types of interactions in terms
of required interfaces and provided interfaces. A required interface describes the object's need for a service
provided by some other object. All requests for services through a required interface are outbound, meaning that
the object seeks help from some other object. For example, the engine requires a fuel source, so the engine
needs to look outside itself to find a source, like a fuel pump, and obtain its help. A provided interface describes a
service that the object offers to other objects, such as when the engine provides power to the transmission or when
the fuel pump provides fuel to the engine.
Cross Reference Chapter 4 provides a complete description of required and provided interfaces and the
relevant notation.
The port is modeled as a square on the boundary of the object. The default visibility is public. It is possible
however, to draw the square inside the object boundary and declare it as private in cases where the interface is
only used internally by the object.
A port may specify any number of interfaces. The set of interfaces defines the port. In Figure 7-21, the engine
defines a port that requires a fuel interface. The fuel pump defines a port that provides a fuel interface. Likewise,
the transmission defines a port that requires a power interface, and the engine provides a power interface. The
sum of the ports and associated services defines the boundary of the object. In other words, the object is
encapsulated within the set of interfaces. Encapsulation encourages reuse. For example, the fuel pump in our
example could be used with any engine that requires the same type of interface provided by the fuel pump.
You do not need to use ports to connect parts. The transmission end of the connector between engine and
transmission in our example does not have a port. Ports simply provide a means to encapsulate a part so that
features of the part are hidden and the interfaces to the part take priority in the design discussion. It is the
designer's decision whether this level of encapsulation aids or hinders the design process.
Finally, ports come in two types, signal and service. The two types are mutually exclusive. If the port is defined as
isSignal, and the isSignal attribute is true, it may only relay signals. If the port is defined as isService, and the
isService attribute is true, it defines the services provided by the classifier, like the fuel and power services in the
car example. If isService is false, the port is not part of the externally published features of the classifier, and it may
be changed or deleted without altering the definition of the classifier. For example, the engine also has gaskets
and mounting bolts but they do not provide services to the engine or other parts of the car. They may be replaced
or even deleted in favor of other technologies without affecting the car's fundamental design. The same cannot be
said for the fuel pump, which provides an essential service. Deleting or replacing it requires that we first address
the replacement of the service that it was providing.
Modeling a collaboration
A collaboration represents how elements of the model cooperate to perform some essential behavior. The
participating elements may include classes and objects, associations and links, attributes and operations,
interfaces, use cases, components, and nodes. The behavior may be a use case, an operation, a collection of
operations, or a general mechanism of the system. In other words, a collaboration may be modeled at many
different levels of abstraction.
When a collaboration describes the implementation of a single operation, it includes the classes, associations,
interactions, and roles that each class plays in the behavior. The collaboration may be modeled from two
perspectives. First, the structure may be modeled with a class diagram that shows only the classes, associations,
attributes, and operations relevant to the realization of that specific collaboration. Second, the behavioral
perspective may be modeled with an interaction diagram: a Sequence or Collaboration diagram (or both).
One common use for collaborations is to model design patterns. A pattern models a common behavior that
requires a standard set of interactions among a set of objects that fit the roles defined by the pattern. For example,
the Composite design pattern defines a way to organize objects of varying complexity so that they can be used in
the same manner regardless of their complexity. A collaboration is modeled as a dashed oval with the
collaboration name inside. Figure 7-22 shows Composite (for the design pattern) modeled as a collaboration.
Figure 7-22: Modeling a collaboration icon.
A collaboration does not specify particular classes, but it defines the roles that classes have to play in order to
accomplish the goal of collaboration. A role, formally called a ClassifierRole, defines the set of features that a
classifier needs to possess in order to fulfill a particular responsibility in the collaboration. This is much like defining
player positions on a sports team. We can define the roles of the pitcher, catcher, and first baseman on a baseball
team without knowing any specific people who might play these positions.
The ClassifierRole also may define attribute values and behaviors that an instance must possess in order to play
the role. For example, a pitcher must be able to throw specific pitches and meet specific criteria for speed and
accuracy.
The notation for a ClassifierRole uses the following syntax:
ObjectName '/' ClassifierRoleName ':' ClassifierName [',' ClassifierName]
The entire name is underlined when referring to an instance. When only a role name is needed and no instance
reference is implied, do not underline the name. Table 7-2 provides a complete description of alternative object
and role names.
Table 7-2: Examples of ClassifierRole Name Variations
Syntax Interpretation
: Class1- instance
name
An anonymous instance of type Class 1.
: Class1- role name Used to model the fact that any instance of type Class1 could fulfill the
requirements of the specified part in the collaboration.
Object1 : Class1 An instance called Object1 of type Class1.
Used to model the fact that a particular instance, of type Class1, fulfills the
requirements of the specified part in the collaboration.
Object1 / RoleA :
Class1
An instance called Object1 of type Class1 playing RoleA.
Used to model the fact that a specific instance, of a specific type, behaving in a
specific manner, fulfills the requirements of the specified part in the collaboration.
Object1 / RoleA An instance called Object1 of an unknown type playing RoleA (we know the name
of the object but not the type).
Used to model the fact that a specific instance, behaving in a specific manner,
fulfills the requirements of the specified part in the collaboration.
Syntax Interpretation
fulfills the requirements of the specified part in the collaboration.
/ RoleA - instance
name
An unspecified instance of an unknown type playing RoleA.
/ RoleA - role name Used to model the fact that the solution requires that any type of object may fulfill
the role as long as it conforms to the rules for the role.
Object1 An instance called Object1 of an unknown type.
Used to model the fact that this specific object exemplifies the required behavior.
/ RoleA : Class1 -
instance name
An anonymous instance of type Class1 playing RoleA.
/ RoleA : Class1 -
role name
Used to model the fact that the solution will work with any instance of this type
playing this role.
The role names for the composite design pattern are "component", "composite", and "leaf". Figure 7-23 is a Class
diagram within a collaboration, using role names instead of class names. The format for the ClassifierRole used in
Figure 7-23 is "/ RoleName". This is typical of design patterns that may be applied to many different types of
objects. The leaf role describes an individual object. The composite role describes an object that is actually an
assembly of other objects. The component is basically the interface, the view that other classes and applications
see. Since both a leaf and a composite object are types of components (specializations), the user views and
manipulates both types of objects as though they are components. So single objects and complex aggregate
objects are handled in the same manner without requiring the user to first understand their structure.
Figure 7-23: Applying role names to classes.
Figure 7-23 represents the pattern abstraction, the concept. It tells us that we can apply the pattern to our design if
we can assemble a set of classes that will assume the defined roles and associations. The next section addresses
the application of the pattern to a set of classes that fulfill the pattern within a specific context.
Modeling a collaboration occurrence
UML 2.0 continues with the fundamental concept that a collaboration describes the essential structure and
behavior to accomplish a standard system task. A collaboration may specify the required attributes and operations,
communication between objects, and the needed relationships. But all of these requirements are stated in a way
that does not mandate or presuppose any particular classes.
fulfills the requirements of the specified part in the collaboration.
/ RoleA - instance
name
An unspecified instance of an unknown type playing RoleA.
/ RoleA - role name Used to model the fact that the solution requires that any type of object may fulfill
the role as long as it conforms to the rules for the role.
Object1 An instance called Object1 of an unknown type.
Used to model the fact that this specific object exemplifies the required behavior.
/ RoleA : Class1 -
instance name
An anonymous instance of type Class1 playing RoleA.
/ RoleA : Class1 -
role name
Used to model the fact that the solution will work with any instance of this type
playing this role.
The role names for the composite design pattern are "component", "composite", and "leaf". Figure 7-23 is a Class
diagram within a collaboration, using role names instead of class names. The format for the ClassifierRole used in
Figure 7-23 is "/ RoleName". This is typical of design patterns that may be applied to many different types of
objects. The leaf role describes an individual object. The composite role describes an object that is actually an
assembly of other objects. The component is basically the interface, the view that other classes and applications
see. Since both a leaf and a composite object are types of components (specializations), the user views and
manipulates both types of objects as though they are components. So single objects and complex aggregate
objects are handled in the same manner without requiring the user to first understand their structure.
Figure 7-23: Applying role names to classes.
Figure 7-23 represents the pattern abstraction, the concept. It tells us that we can apply the pattern to our design if
we can assemble a set of classes that will assume the defined roles and associations. The next section addresses
the application of the pattern to a set of classes that fulfill the pattern within a specific context.
Modeling a collaboration occurrence
UML 2.0 continues with the fundamental concept that a collaboration describes the essential structure and
behavior to accomplish a standard system task. A collaboration may specify the required attributes and operations,
communication between objects, and the needed relationships. But all of these requirements are stated in a way
that does not mandate or presuppose any particular classes.
In fact, a collaboration is often expressed in terms of interfaces rather than classes for this very reason. Any
classes that can support the needed interfaces may participate in the collaboration.
To exploit this approach, UML 2.0 introduces the concept of a collaboration occurrence. A collaboration
occurrence is a single instance of the collaboration that is bound to a specific set of elements, that is, classes and
associations. So there may be any number of collaboration occurrences for any collaboration. In the theater
application, I might use the composite collaboration for seating arrangements, events, pricing strategies, and so
forth. The roles, rules, and requirements for the participants are identical in each case even though the actual
classes and applications vary substantially.
Figure 7-24 presents a portion of the UML 2.0 metamodel for collaboration occurrences, showing that they can be
bound to any type of classifier.
Figure 7-24: A collaboration occurrence is bound to either operations or classes.
No Magic
Apart from collaboration occurrence, the only change in UML 2.0 is that it uses the Composite Structure diagram
to model collaboration structure. Also, since the collaboration is itself a classifier, it can use any kind of behavioral
diagram to represent its behavioral requirements such as a State Machine or Sequence diagram.
As an example of a collaboration occurrence, Figure 7-25 applies a set of classes from the theater system to
exploit the benefits of the composite design pattern from Figure 7-23 to work with various seating arrangements.
Figure 7-25: Applying the collaboration structure to the theater system.
To apply a pattern to actual classes, each class assumes one of the collaboration roles. The dependency arrow
that points to the class takes on the role name played by the class. Figure 7-25 models the applied pattern using
three theater system classes used to define seating arrangements. An individual seat is a leaf. A grouping of seats
such as a row composed of seats or a section composed of rows is a composite object. A location is a component
that may be either an individual seat or a seat group. Using this pattern, a user can book an entire section as easily
as booking a single seat.
Within a collaboration, the dependency arrow is a called a connector. The connector binds a role to a model
element. For example, in Figure 7-25 the component role is bound to the Location class. The collaboration defines
the roles. The collaboration occurrence binds or maps the roles to specific classes that fulfill the purpose of the
collaboration. In the preceding example, the Composite design pattern / collaboration is fulfilled by the Location
collaboration occurrence. All the collaboration roles are accounted for by a set of classes, associations, and
generalizations.
A collaboration may also model the implementation of an individual operation. Figure 7-26 shows how to associate
a collaboration with the operation that it realizes/implements.
Figure 7-26: Modeling collaborations that realize an operation.
This representation is most valuable when the implementation is complex. The collaboration may include both
structural and behavior diagrams to explain the collaboration. The benefit of using a collaboration to describe the
requirements is the separation of the implementation from the requirements. This separation permits the design,
review, and maintenance of the implementation without altering or losing sight of the original requirement. In the
Order example, that means never losing sight of the need to compute the total price of the order even if you need
to change the algorithm that does so a dozen times over the life of the application.
<Day Day Up>
<Day Day Up>
Summary
UML supports the description of objects as well as classes. Objects are modeled using an Object diagram, a
specialized Class diagram that contains only objects and links. To model objects that are constructed by
assembling other objects, UML defines the Composite Structure diagram that models assemblies using visual
containment of one object within another.
Object diagram, objects, and links: The Object diagram models facts about specific objects and their links. A
link represents a relationship between two objects. A link is an instance of an association in the same way that
an object is an instance of a class. The Object diagram is used primarily to discover facts in order to build a
Class diagram, or to model test data to test a Class diagram.
Composite Structure, parts, and ports: The Composite Structure diagram is an alternative for modeling
aggregation and composition relationships. Classes that represent types of part objects are placed inside the
border of the aggregate class icon to represent physical containment. Ports define the interfaces between
parts within a Composite Structure diagram.
UML models the behavior of objects in specific situations using Interaction diagrams. But UML also supports a
collaboration, which defines a pattern of interactions between objects and the interfaces needed to make the
interaction work. Collaborations may be used within any of the UML diagrams to define a predictable pattern of
classifiers and interactions without identifying the specific types of classifiers that will fulfill the collaboration
requirements effectively separating the specification of the system from the implementation.
Collaborations, roles, and realization: A collaboration models a standard type of behavior within a system. The
behavior is modeled as a set of cooperating classifiers, their relationships, and the interactions between them.
A collaboration is defined in terms of the roles that participating classifiers must conform to in order to
participate in the collaboration. A collaboration may be realized/implemented by a set of classifiers that
conform to the types and interactions defined by the collaboration. Each classifier assumes a role defined by
the collaboration and implements the interactions specified for that role.
<Day Day Up>
<Day Day Up>
Part III: Modeling Object Interactions
In This Part
Chapter 08: Modeling Interactions in UML 1.4
Chapter 09: Modeling Interactions in UML 2.0
Chapter 10: Modeling an Object's Lifecycle in UML 1.4
Chapter 11: Modeling an Object's Lifecycle in UML 2.0
<Day Day Up>
<Day Day Up>
Chapter 8: Modeling Interactions in UML 1.4
Overview
In Chapter 3, I provided an overview of the UML diagrams. I distinguished their use around three general headings:
structural diagrams, behavioral diagrams, and model management diagrams. The structural diagrams (class,
object, component, and so forth) represent how the objects are defined and how they are related to one another.
They do not represent how the objects behave when you put them to work. In contrast, the behavioral diagrams
represent how the objects work using the structure already defined in the other diagrams. This dynamic view
contains diagrams specifically designed to model how the objects communicate in order to accomplish tasks within
the operation of the system. They can represent how the system responds to actions from the users, how it
maintains internal integrity, how data is moved from storage to a user view, how objects are created and
manipulated, and much more.
Because system behaviors can be large and complex, the behavioral diagrams tend to look at small, discrete
pieces of the system such as individual scenarios or operations. You might not see the behavioral diagrams used
for all system behaviors simply because not all behaviors are complex enough to warrant a visual explanation of
the communication required to accomplish them. Even so, the Class diagram and the various behavioral diagrams
are the most often-used diagrams because they most directly reveal the specific features required to generate
code.
Table 8-1 shows the three behavioral diagrams in UML 1.4 (Sequence, Collaboration, and Statechart) compared
to UML 2.0's five. UML 2.0 renames two diagrams and adds the Timing diagram and the Interaction Overview
diagram.
Table 8-1: Comparison of Behavioral Diagrams Between UML 1.4 and UML 2.0
UML 1.4

UML 2.0
Sequence diagram remains Sequence diagram
Collaboration diagram becomes Communication diagram
Statechart diagram becomes State Machine

new Interaction Overview diagram

new Timing diagram

This chapter covers the Sequence and Collaboration diagrams of the UML 1.4 specification. Chapter 9 discusses
the UML 2.0 Sequence, Communication, Interaction Overview diagrams, and Timing diagrams. Chapter 10
explains the UML 1.4 Statechart diagram. Chapter 11 explains the UML 2.0 State Machine.
<Day Day Up>
<Day Day Up>
Modeling a Sequence Diagram
The Sequence and Collaboration diagrams are most often used to illustrate interactions between objects. As such,
they both model objects and messages between objects.
TipThe diagrams can also be used to model interactions between classifiers, as is done to model the
interactions for a collaboration.
The Sequence diagram uses a time-oriented visualization. It uses a set of object icons and associated timelines,
together called an object lifeline, for each object. In contrast, the Collaboration diagram presents a structure-
oriented visualization. In fact, the Collaboration diagram's notation is based on the Object diagram notation that
models objects and links.
NoteYou might think it's odd that the UML has two diagrams that do the same thing. In a way, you're right. The
reason is that they come from different methodologies and each offers a slightly different perspective
that can be quite valuable. The two diagrams are compared later in this chapter.
The common feature of both diagrams is the ability to represent interactions. Interactions show us how objects
send messages to each other. When one object wants to send a message to another object, the second object
has to have a way to receive the message. The message must match an interface provided by the second object.
It is kind of like receiving a phone call. The person receiving the call has to own the number being called in order to
receive the call. The number is the interface. So interactions, messages sent between objects, reveal interface
requirements. The interface is literally an operation.
Cross-Reference See Chapter 5 for an explanation of operations.
This pairing of messages and interfaces is helpful in two ways for building and testing your model:
It can point to existing model elements. If one object needs to send a message to a target object, you
should check to see if the second object already provides the needed interface. When using a modeling
tool, this is as simple as pulling up a list of the defined interfaces for the target object and then picking the
matching interface to complete the interaction. In a modeling tool, you might accomplish this either by
accessing the list from within the Sequence or Collaboration diagram, or by checking the object's
corresponding class specification in the Class diagram. This ability to choose existing interfaces makes
adding new features to a system very quick and easy, which can, in turn, facilitate the development work in
subsequent project phases and later maintenance activities.
1.
It can aid in discovering the need for new model elements. If you find that you need to send a message to a
target object, but that object does not have a corresponding interface, then you have discovered a new
interface requirement. Similarly, if you do not already have an appropriate target object to take responsibility
for receiving and responding to the message, then you have discovered a requirement for a new type of
object, a new class definition.
2.
Figure 8-1 shows a clip from the MagicDraw Sequence diagram menu for an event object. Note the two options in
the bottom right corner, <new operation> and Call Action. While the actual labels may differ between tools, the
same two concepts are commonly supported. The Call Action is an example of approach 1; it provides the list
displayed on the left side of the figure containing all the operations already defined on the event class. The <new
operation> option is an example of approach 2; it enables you to define a new operation (big surprise). The new
operation is added to the specification for the class that the current object belongs to, that is, the Event class.
Figure 8-1: An example of the automated support for finding operations, and for adding new operations based
on messaging requirements. $No Magic
Sequence and Collaboration diagrams are based entirely on messaging requirements. Messaging requirements
come from the fact that objects are required to perform behaviors. So where do you find the behaviors you need to
model? In many projects the use cases are created first because they model the behaviors of the system expected
by the clients. These behaviors provide the basis for building scenarios. Each scenario describes in text form how
the system should behave under a specific set of circumstances, such as using the system to select a show to
attend. The Sequence and Collaboration diagrams provide a pathway from the textual descriptions of behaviors in
the scenarios to the operations/interfaces required by the Class diagram in order to generate code.
TipThe scenarios also provide a basis for developing test cases and an acceptance-level test plan. Chapter
12 explains use cases and scenarios.
Modeling an object lifeline
While classes define the types of behaviors that objects can perform, all behavior in the object-oriented system is
performed by objects, not classes. Objects take on the responsibility for editing data, storing data, moving data
around in the system, responding to queries, protecting the system, and more. Objects work together to perform
these tasks by communicating with one another. Examining how specific objects work under specific
circumstances reveals the exact nature of the communication.
Consequently, Sequence (and Collaboration) diagrams are most often modeled at the object level rather than the
class level. This approach also supports scenarios in which multiple objects of the same class work together as,
for example, when one employee object collaborates with another employee object. It also allows the Sequence
diagram to model facts in the forms of concrete test data and examples, instead of more general concepts or rules
captured in the class specifications. The Sequence diagram uses two fundamental notation elements: object
lifelines and messages or stimuli.
The object lifeline notation combines the object icon notation and a timeline. The object notation is the same icon
used in the Object diagram in Chapter 7: a rectangle containing the object name. In this example, I use the
common anonymous object notation :classname. Figure 8-2 drafts a scenario in which a customer selects seats to
purchase at a performance in the theater. You see the five participating objects lined up across the top of the
diagram. The top of the diagram is the default location for all objects in a Sequence diagram. Positioning an object
at the top of the diagram indicates that the object already exists at the outset of the scenario. This implies that
positioning an object lower in the diagram models the creation of the object during the scenario.
Figure 8-2: Object lifelines for five objects..
The object lifeline includes the rectangular object icon and the vertical dashed line below each object. The line is a
timeline that runs from the beginning of a scenario at the top of the diagram, to the end of the scenario at the
bottom of the diagram. The amount of time represented by the timeline depends on the length of the interaction
you are modeling.
Note that an object lifeline, that is, an object icon and its associated timeline, may actually represent a set of
objects such as an application, a pattern, a subsystem, or simply a collection of objects of the same type. This
high-level view can sometimes help you work out the "big picture" behavior before digging deeper to work out the
details. For example, the SelectShowSeat object in Figure 8-2 represents a collection of objects that together
manage the behavior of the application. The ShowSeat object represents all of the ShowSeats in the application.
Modeling a message or stimulus
A message is the formal specification of a stimulus. A message is a definition of some type of communication
between objects. As such it may invoke an operation, raise a signal, or cause the creation or destruction of the
target object. A stimulus is an instance of a message. The message explains the roles of the sender and the
receiver of the stimulus, as well as the procedure that generates the stimulus. For practical purposes, we can think
of a message and a stimulus as the same thing, that is, as a unit of communication between objects, so I will use
the term message in the rest of this book. (Details about the distinctions between messages and stimuli are
provided in the "Stimulus, message, operation, and signal" section later in this chapter.)
A message is modeled as an arrow. The type of arrow visually describes the type of message. Perhaps the most
common type of arrow is a solid line with a solid arrow-head, representing a message that requires a response,
called a simple or synchronous message. The dashed arrow with a stick arrowhead represents a response or
return. I cover more arrow/message types later in this chapter. Messages are placed horizontally between the
object lifelines, as shown in Figure 8-3. The horizontal placement indicates that transmission of the message is
considered to be instantaneous, that is, the message is received as soon as it is sent. The relative vertical position
on the timelines represents the order in which the messages happen. This arrangement means that you can read
the diagram from beginning to end by reading the messages from top to bottom.
Figure 8-3: Messages are placed on the object lifelines to model object interactions. Relative vertical position
indicates the order of execution from top to bottom.
CautionThe placement of the arrows on the timeline does not imply any specific measurement of time. Only
the relative position matters, that is, if one message is placed on the timeline above a second
message, then the first message is sent before the second message.
The tail of the message arrow identifies the sender. The head of the message arrow identifies the receiver.
Reading from top to bottom, the Sequence diagram in Figure 8-3 reads as follows:
The customer selects the show seat she wants to purchase, presumably from a user interface, passing the
identifier for the show seat to a control object, an instance of SelectShowSeat. The control object is
basically an event handler in this scenario.
1.
The control object, SelectShowSeat, asks the performance object for a reference to the show seat that
matches the provided identifier.
2.
The performance returns a reference to a show seat object based on the showSeatID passed to it. 3.
The control object tells the order object to add the selected show seat to its list of ordered show seats. 4.
The order returns a Boolean value of True saying that everything worked properly. 5.
The control object then tells the show seat object that it has been successfully selected. This causes the
show seat to change its status from not sold to sold.
6.
The show seat returns void, that is, nothing. (In some cases you would return some values but this
provides an example of how you can use a void return.)
7.
NoteBuilding the Sequence diagram is easier if you have completed at least a first draft of the Use Case
model - the diagram and associated use case descriptions (see Chapter 12) and the Class diagram.
From these two resources, you can find sets of interactions (scenarios) and a pool of candidate objects
to take responsibility for those interactions.
The sequence numbers at the beginning of each of the messages are optional but they are very helpful when you
need to discuss the diagram or make changes. Later, I explain the full message description that can make use of
message numbering. The numbers are also useful when working with multiple scenarios that use some of the
same messages. For example, if the first 7 steps of scenario #1 are the same in scenario #2, then scenario #2
could simply refer to the first seven steps by number in a comment icon rather than have them redrawn.
Fortunately, many modeling tools simply take care of the numbering for you.
TipReusing common interactions is a significant addition to the features of UML 2.0.
Each solid arrow describes a message using formal operation notation. The operation defines the interface
required by the receiving object, the object whose timeline the arrow is pointing to. In order to be received, the
message must conform exactly to an interface (an operation signature) defined on the class to which the receiving
object belongs. The syntax for a message is as follows:
predecessors '/' sequence-term iteration [condition] return ':=' operation
The expression predecessors, followed by a slash (/), refers to a list of comma-separated sequence numbers
of messages that must come before the current message. The list implies synchronization, that is, the
predecessors must be completed before the current message may proceed. Immediate predecessors on the
diagram are assumed so they don't need to be included. In a simple sequential flow of control, the predecessors
are not needed because each message follows immediately after the previous message.
The sequence-term may be either a number or a name. Numbers are far more common. Specific schemes for
numbering vary widely. Most use the dot notation to model nested levels for calls, for example, 3.1, 3.1.1, 3.1.2,
3.1.3, and so forth.
Iteration and conditions are explained a bit later in this chapter.
The return may include a list of values sent back to the sender by the receiver. For example, message 4,
addShowSeat(showSeat):Boolean, in Figure 8-3 defines a return type of Boolean. Message 5 returns the Boolean
value true. Another scenario would return a Boolean value of false. Note that the return arrow is drawn using a
dashed line and a stick arrow to distinguish it from the synchronous message arrow. The choice whether to show
the return varies among UML practitioners. Some place a priority on saving steps so they leave the returns off of
the diagram. Others focus on clarity so they always include them. When modeling scenarios, it is useful to reveal
the values that cause the scenario to execute in a specific manner, like the True and False paths mentioned in the
last example. There are also times when not showing the returns causes some ambiguity in the interpretation of
the interactions. I provide an example of how the lack of returns can cause ambiguity in the interpretation of the
diagram a bit later in the "Self-reference message" section.
The operation defines the name of the operation, optionally the parameters, and optionally a return.
Parameters are not required; when used, they follow the attribute definition format of name :' type, and may even
specify defaults and constraints.
Cross-Reference Chapter 5 provides a complete description of the operation syntax.
NoteCreating all these arrows, messages, and returns might sound like a lot of work, but consider two things.
First, you have to define all of this information anyway to write an application. This way you have a visual
record of how you decided that the way you wrote the code was the best way to write it. Second, consider
the process. You define a class. Then you create a few Sequence diagrams. Each adds some new
operations to the class. Soon, building additional Sequence diagrams becomes a process of drawing
message arrows and simply choosing from a list of existing operations on the class. The process starts
slowly but quickly picks up speed as the class definitions become more complete.
Having explained the full message syntax, I have to say that most Sequence diagrams depict only the operation
portion of the message.
Stimulus, message, operation, and signal
To understand the various message types and notations that can be used on a Sequence diagram you need some
basic definitions. Stimulus, message, operation, and signal make up the vocabulary for working with interactions
between objects in both Sequence and Collaboration diagrams. A stimulus is an item of communication between
two objects, and has the following characteristics:
A stimulus is associated with both a sending and a receiving object.
A stimulus normally travels across a link. However, when the stimulus is sent and received by the same object,
there is no link. This kind of stimulus is called a self-reference.
A stimulus may invoke an operation, raise a signal, or even cause an object to be created or destroyed.
A stimulus may include parameters/arguments in the form of either primitive values or object references.
A stimulus is associated with the procedure that causes it to be sent.
In contrast, a message is the specification of a stimulus. The specification includes the roles that the sender object
and the receiver object play in the interaction, and the procedure that dispatches the stimulus. So technically
speaking, a stimulus is an instance of a message. In the parts of the UML specification that cover Sequence and
Collaboration diagrams, the two terms stimulus and message are almost always used synonymously (note that I
did say almost).
When using a tool to model the Sequence and Class diagrams, you only need to define the features required to
generate the code. Namely, for each message you need to define either the operation signature (as described in
Chapter 5) or the information returned from a message. The operation explains the procedure that the message
invokes on the receiving object. The return contains the information passed back from the receiver to the sender.
An empty return is valid.
A message may raise a signal. This means that the message may be no more than an alert like a doorbell, an
alarm, or a message box on a computer screen. It does not require a return message. The implications of this type
of message are explained more fully in the "Asynchronous message" section of this chapter. A signal is a type of
class associated with an event that can trigger a procedure within the receiving class. In this respect it is just like a
message. The fundamental difference is that it does not require a return from the receiving object.
An exception is a type of signal. Throwing an exception means sending out a message containing an object that
describes the error condition. This means that throwing an exception is a behavior that may be modeled using a
Sequence diagram, or any other behavior diagram. For example, in Figure 8-3, message 5 returned a Boolean
value of true. In another scenario for the same process, we might need to return a value of false, but that value
would not tell us what actually happened that made it fail. Since exceptions may be user-defined, an exception
object could encapsulate any information you want to capture about an error condition. So an alternative approach
would be to throw an exception that could be caught by either the calling object or another object higher up the call
sequence (stack).
TipThe throw/catch approach to exceptions is common to most object-oriented languages. It allows errors to
be defined as objects that encapsulate any and all information needed to fully describe the problem,
instead of limiting errors to a simple true or false value or an error code. This approach also separates the
problem of where to trap errors from where and how to handle them.
A message may also indicate the creation or destruction of an object. How a message does so is explained later in
the "Modeling object creation and destruction" section.
Synchronous message
So far I have used only synchronous messages in the examples. A synchronous message assumes that a return is
needed, so the sender waits for the return before proceeding with any other activity. Messages 1, 2, 4, and 6 in
Figure 8-3 are all synchronous messages.
The dashed return arrows marked as sequence numbers 3, 5, and 7 in Figure 8-3 each represent only the reply to
a message, called a return. The return value is placed on the return message arrow. For code generation, a return
may only have one value such as a Boolean True or False value, a numeric value, an object (reference), or a
string. Technically, UML allows a list of values.
TipWhen creating your initial model, don't be concerned that the return ultimately needs to be limited to a
single value. Focus on discovering the information that needs to be passed. Put as many values as you
need in the return. Once you are sure that you have the right information, you can always
package/encapsulate the multiple values into an object such as a transaction.
Some folks leave the returns off of synchronous messages, choosing to assume the return. But showing the
returns can help ensure that what you're getting back is consistent with what the test case required and what the
message/operation requires. Remember that a primary value of models is the ability to review them with other
people to solicit observations regarding the accuracy, completeness, and efficiency of an approach to a problem.
People can't make observations about what they can't see and often make different assumptions than you might
have made.
Self-reference message
In a self-reference message, the sender and the receiver for the message are the same object. For example, a
user object might send a "cancel" message to a theater event object. The event must change its own status and
the status of each performance within the event. Since an event might have to cancel an individual performance
for other reasons, it makes sense to make the ability to cancel a performance a separate operation that could be
called under either circumstance. Doing so enables the same event operation, cancelPerformance(), to be called
once to cancel one performance for the event, or called multiple times to cancel all performances for the event, or
even for a time frame within the event.
Figure 8-4 models a portion of the Sequence diagram that calls cancel() on the event object, which in turn causes
the event to call the cancelPerformance() operation on itself. Note that the message arrow leaves and comes back
to the same lifeline. This is called a self-reference - the event object is referring to itself when it makes the call.
Note too that message 2 is only the invocation. The return is a separate message (5) drawn the same way. It
leaves the event lifeline and comes back to the same event lifeline. In other words, messages 2 and 5 say that the
event object is telling itself to start the cancelPerformance() process, and then telling itself when it has finished.
The event object initiates and responds to the message.
Figure 8-4: Self-reference.
NoteIn message 3, the asterisk indicates iteration and the expression [for each performance whose date is =>
today] is a condition. Both concepts are explained later in this chapter.
A common mistake is to think that the self-reference is a send and return in one message, that is, the portion of the
arrow leaving the lifeline is the invocation message and the portion of the arrow returning to the lifeline is the return
from the message. But each arrow is a single message from one sender to one receiver. The send and return
cannot be combined into one message.
When a message appears only as a self-reference, it says that the operation is only invoked from within the
object's own behaviors. This is a good indication that the operation might be set to private access to ensure that
the use of the operation is limited to within objects of the same class. Be sure to check all of the Sequence
diagrams where the operation is called to be certain it never needs to be called by another object directly.
Figure 8-4 is also a good example of why showing returns can remove ambiguity. It is obvious from the model that
message 3 returns before message 2 finishes. But if I remove the returns, there is no way to know whether
message 2 must finish before sending message 3.
Asynchronous message
Earlier I referred to signals as messages that do not have a return. Another name for this type of message is an
asynchronous message. An asynchronous message says something about the responsibilities of the sender and
receiver. The sender is responsible only to get the message to the receiver. It has no responsibility or obligation to
wait to find out if or how the receiver will respond. The sender may simply go about its business. The receiver may
decide to do nothing or to process the received message.
In these respects an asynchronous message resembles the way you receive mail. The postman delivers the mail
without any regard for what you do with it once you get it. You can choose to throw away the junk mail, keep and
pay the bills, respond to letters from people you like, and ignore the mail from those you don't like. Regardless of
your choice, the postman continues delivering mail to other people. In contrast, a synchronous message is like a
letter sent by messenger requiring a signature. The messenger waits on your doorstep until she gets a reply from
you.
An asynchronous message is modeled using a solid line and a stick arrowhead to distinguish it from the solid
arrowhead of the synchronous message. (You might also see half arrowheads in some tools. This was the notation
from UML 1.3 and earlier). The content of the message is an operation, the same as for a synchronous message.
The only difference is that there is no return (in many languages this means the return is specified as void).
In Figure 8-5, message 3, the theater system obtains a list of events from a venue object. It then tells the boundary
object CustomerActor that represents the user interface to display the events. It does not wait to find out if or how
the user interface displays the events. Contrast this with message 1, getEvents(start, end). This is a synchronous
message that requires a specific response. The theater system actually stops whatever else it might be doing until
it receives the list of events or an error.
Figure 8-5: Asynchronous event..
Another way to understand the asynchronous concept is that nothing else the sending object does is contingent on
the reaction of the receiver. This approach can actually make an application a bit easier to design. For example,
the theater system can continue with other work while assuming that the user interface is working just fine. The
theater system only gets involved if it receives a thrown exception or other signal from the user interface. The
alternative would be to design the theater system object to wait for a response for every message it sends to the
user interface.
Comment
Sometimes you might want or need to provide some explanation for the diagram or elements within diagram, but
UML notation does not provide the specific means to do so. What you really need is the chance to simply write
some freeform text to get your point across. Figure 8-6 shows how you might use a UML comment icon (a
rectangle with a folded corner) to add information that is not explicitly part of the notation. A comment may be
placed anywhere on or around the diagram. Optionally, the comment may be attached to an element of the
diagram using a dashed line called an anchor.
Figure 8-6: A comment on a Sequence diagram.
TipUML 2.0 changed the name from comment to note.
Timed message
Often there is also a condition or a constraint on a message that expresses the timing parameters for the
message, for example, {if you don't get a response from the event object within 2 seconds, bypass the request and
send an error to the user interface}. In order to evaluate this constraint, you first need a means to measure time. A
message may have any number of user-defined time attributes, such as sentTime, receivedTime, and
elapsedTime. But to access these values you need to identify the message that owns the value by using either a
message number or a message name. For example Figure 8-7 uses message names instead of numbers.
Figure 8-7: Timed messages using constraint notation.
OMG 1.4
Figure 8-7 models a phone connection from the time a person picks up the receiver to make a call until the time
someone picks up to answer the call. Each message is assigned a name: a, b, c, and d. The caller lifts the
receiver; this sends message a (lift receiver) to the exchange. The exchange sends message b (dial tone) to the
caller's phone. To the left of messages a and b is a constraint, {(b.receiveTime - a.sendTime) < 1 sec.}. The
constraints tells us the design must provide a response time of less than 1 second between the time the lift
receiver message is sent (the tail of the a:lift receiver arrow) until the dial tone message is received (the head of
the b:dial tone arrow).
Place the constraint in the left margin of the Sequence diagram next to the period of time that it constrains.
In most Sequence diagrams you model the arrows horizontally as though the messages are instantaneous.
Message d:route illustrates a way to model a message that requires a significant amount of time, and that you want
everyone reading the model to be very aware of it. Simply slant the arrow from the tail down to the head. Again,
place the time constraint in the left margin. The arrow is simply a visual cue; it doesn't designate any specific
amount of time. This is why you must use a constraint to provide the timing requirement.
Not every tool supports the left-margin approach. You might need to use comments and type the constraint into
the comment. Other tools support constraints in the specification of the message, an approach that is not as
flexible or visible but is more precise.
The timed message is an example of the use of a UML extension mechanism, namely the constraint. A timed
message is not a part of the core UML notation but it represents a valid usage of the UML constraint notation to
extend the features of the basic Sequence diagram.
Iteration
Iteration refers to the need to execute one or more messages in a sequence more than once. Iteration on a single
message is molded using iteration symbol, an asterisk (*), and a condition to control the number of iterations.
Figure 8-8 shows how you can indicate that an operation should be performed repeatedly.
Figure 8-8: Modeling iteration on a message.
There are actually two components of the iteration notation that are placed in front of the message text. An asterisk
(*) indicates that the message will execute repeatedly. If you want to explain how to control the iteration you can
enclose a conditional statement in square braces ([ ]). Message 3 in Figure 8-8 reads, "*[for each show seat],"
meaning that the same message is sent by the performance object to a show seat object for every show seat
object in the location (the set of show seats) passed to the performance in message 2. The conditional expression
may be a Boolean expression or freeform text.
Executing a message repeatedly implies executing all of the subordinate messages repeatedly as well. In other
words, if message 3 in this example required sending a message to three related objects as well, the block of
messages would be executed repeatedly. Another technique commonly used in this case is to enclose the set of
repeated messages in a box and place the condition in the box. This approach might not be supported by every
tool.
Conditions
Conditions are used to specify the control of the iteration. However, conditions may be used pretty much anywhere
in the sequence of messages. In fact, if a Sequence diagram models a single scenario, it is almost certain that
there are conditions that drive the use of the messages in the scenario. A condition is expressed as text enclosed
within square braces [].
For example, when a customer selects a show seat that he wants to purchase, it only becomes part of his order if it
has not already been selected by someone else. Figure 8-9 models the successful scenario. Message 3 adds the
condition [show seat not selected], between the sequence number and the colon, to convey that the performance
returns a show seat reference only if the show seat has not been previously selected.
Figure 8-9: Modeling conditions to explain the flow of messages. Message 3 states that if the show seat that is
being selected in message 2 has not already been selected, then message 3 will return a reference to the
selected show seat object.
Figure 8-10 models the failed scenario. Message 3 adds the condition [show seat selected] meaning that the
performance returns an error because the show seat has been selected. Message 4 is a completely different
message than in the first scenario, because the different condition in message 3 caused an alteration in the flow of
events.
Figure 8-10: Modeling an alternative scenario using a condition to explain the variation.
Technically, UML supports the ability to model branching on a decision. This involves drawing a diamond (decision
point) and multiple arrows from the same point on the timeline to multiple destinations. But since the subsequent
messages could vary widely, you end up with multiple overlapping sets of messages on the same diagram. The
diagram quickly becomes indecipherable. It is simpler to stick to the rule that one Sequence diagram represents
one logical path or one scenario, and avoid branching altogether.
Modeling activation/focus of control
Sequence diagrams can be enhanced to illustrate object activation and object deactivation. Activation means that
an object is occupied performing a task. Deactivation means that the object is idle, waiting for a message. To show
that an object is active, widen the vertical object lifeline to a narrow rectangle, as shown in Figure 8-11. The narrow
rectangle is called an activation bar or focus of control. An object becomes active at the top of the rectangle. Note
that the venue object lifeline becomes active when it begins to do work when the message arrow labeled
getEvents points to the venue object lifeline. An object is deactivated when it finishes its work. This is usually
illustrated as a message arrow leaving the object lifeline, as when the return events message leaves the venue
object lifeline in message 2.
Figure 8-11: Object activation and deactivation.
Sometimes a distinction is made between an activation and a focus of control, although this distinction is not
directly supported by the UML specification. It is sometimes useful to recognize that some object remains in control
of the entire process modeled by the Sequence diagram. Such an object does more than respond to messages; it
oversees the entire interaction set. For example, the theater system object remains active from the time it starts up
and sends the first message. It remains active while overseeing the results of the call to the venue and continues to
work based on the response it gets from the venue. An object that represents the focus of control has an activation
rectangle along the entire length of its object lifeline.
CautionThere is an odd practice in modeling tools that is not consistent with the UML specification. Tool
vendors tend to put a "tail" on the end of the activation that extends beyond the point at which the
activity actually ends. I've yet to find out why.
Recursion
An object might also need to call a message recursively, that is, call the same message from within the message.
For example, in Figure 8-8 the priceShowSeat message requires the performance to price every seat in the
location passed to it. In the Class diagram for the theater, a location is defined as a set of one or more seats or
groups of seats. So a location could mean a section composed of rows, composed of seats. We could modify
Figure 8-8 to use a recursive call to the location object instead of separate calls from the performance to each
individual show seat.
Figure 8-12 models the recursive call in message 4 utilizing a combination of a self-reference and overlapping
activation notation.
Figure 8-12: Recursive message calls.
The larger of the two overlapping activations indicates that the object is busy performing a task (in its duty cycle),
that is, the task invoked by message 3. That task then calls itself, so there is another activation on top of the first,
offset to the right. For example, if a location is a section in the theater, then the location object calls priceLocation
on all of its rows. Each row in turn calls priceLocation on all of its seats. Seats contain no other locations so the
calls stop. This technique is common when performing a task against hierarchies or nested collections such as the
theater locations, or sales territories within regions, within countries, within global divisions, and so forth.
Modeling object creation and destruction
Finally, to model object creation you have a few options. When I explained the object lifeline notation, I said that
the default location for the object icon is at the top of the page. If an object is in this position, it means that the
object exists when the sequence starts. If the object is created during the execution of the scenario, it should
appear somewhere below the top of the diagram. Some tools do not support this visually accurate approach, so
you might see any one of the three variations modeled in Figures 8-13 and 8-14. All three examples model the
event object that calls the constructor Performance(event), the operation that creates an instance of the
Performance class.
Figure 8-13: Two UML standard visualizations for object creation.
Figure 8-14: Object creation with the created object at the top of the page.
The example on the left is the form explicitly defined by UML 1.4. The creation message/constructor, called
Performance(event), points directly at the performance object icon. This means that the object icon has to be
placed somewhere below the top of the page indicating when the constructor is actually called.
The example on the right is a minor variation where the constructor points to the object lifeline just below the
object, but the object is still placed on the diagram at (or at least near) the point in time when it is created, rather
than at the top.
The goal of the notation is to represent the fact that the object did not exist prior to the creation message. The
object lifeline literally comes into existence when the creation message is sent, so there is no object lifeline before
(above) the creation message. The figure on the left indicates this most clearly.
Some modeling tools can only place objects at the top of the page. Figure 8-14 models the object icon at the top
of the page, and must depend on the message description to convey when the object is created.
In contrast, to show that an object is terminated, place an X at the point in the object lifeline when the termination
occurs. This is usually in response to a message such as delete or cancel. Figure 8-15 models the fact that the
performance has been deleted from the system. The absence of the X on an object lifeline means that the object
lives on after this sequence of events is ended.
Figure 8-15: Object termination.
Not all tools support this notation. As was true for object creation, you might need to depend on the message
description alone to know that the object has been terminated.
Applying the Sequence diagram to the Theater System
Figure 8-16 shows a Sequence diagram for the process of selecting a performance. The TheaterSystem object
represents the application that might actually be implemented as a group of objects that control the screen/s,
access to the business objects, and so forth. The CustomerActor object represents the user interface that the
customer uses when viewing and selecting a performance. The interactions are derived from the interactions that
the user expects of the system as documented in the use case. That is, the user expects the system to provide a
list of events and a list of performances. The complete use case also supports the ability to request a list of
performances by date range, a list of performances for a particular event, and canceling without selecting
anything.
Figure 8-16: Sequence diagram for a scenario where a valid selection is made and saved.
A Sequence diagram is most often used to model a single series of interactions, one scenario. Figure 8-16 models
a scenario in which the user selects a performance from the initial display of events and performances.
NoteThis example does not show the returns on the operations. This is a common option in modeling tools
shown here simply to illustrate another of the available options.
In this figure:
Message 1 is a synchronous message that requests the set of events for a date range. The date range is
established by the application. Message 2 returns the set of events.
Message 3 is an asynchronous message that asks the user interface to display the set of events.
Message 4 is a synchronous self-reference that initiates the process of accumulating all the performances for
all the events selected in message 1.
Message 5 is an iterative synchronous message to retrieve all the performances for each event.
Message 8 is an asynchronous message to the user interface to display the performances.
Message 9 is an asynchronous message from the user interface telling the theater system that the user
selected the specified performance.
Message 10 is a synchronous message to the user interface to get a response from the user to confirm his
selection.
Message 12 is an asynchronous message to save the selected performance.
Message 13 is an asynchronous message to close the screen.
<Day Day Up>
<Day Day Up>
Modeling a Collaboration Diagram
The Collaboration diagram offers an alternative to the Sequence diagram. Instead of modeling messages over
time like the Sequence diagram, the Collaboration diagram models the messages relative to object structure. The
Collaboration diagram uses this approach in order to emphasize the effect of the objects and their links on the
pattern of interactions. Consequently, the advantage of the Collaboration diagram is that it can help you validate
the associations between classes or even discover the need for new associations.
Figure 8-17 is a Collaboration diagram that models the same set of interactions modeled in Figure 8-4 using a
Sequence diagram. On a Sequence diagram, the sequence numbers are optional. On a Collaboration diagram,
the numbers are essential, since there is no other way to determine the order in which the messages are passed.
To read the Collaboration diagram, follow the numbered messages to step through the scenario. Messages 1, 2,
and 3 are synchronous messages. Message 2 is a self-reference. Messages 4, 5, and 6 are returns.
Figure 8-17: Collaboration diagram of cancel event scenario modeled in Figure 8-4.
The "Comparing the Sequence and Collaboration Diagrams" section later in this chapter provides more detail
about the similarities and differences between Sequence and Collaboration diagrams so that you can choose the
diagram that will help you the most with a particular problem in your project.
The Collaboration diagram is built on top of an Object diagram, as follows:
Place the participating objects on the diagram. 1.
Draw the links between the objects using the Class diagram as your guide. 2.
Add a message by placing the message arrow parallel to the link between the two objects. Position the
arrow to point from the sender to the receiver. Place the message text on the arrow.
3.
Number the message in its order of execution. 4.
Repeat steps 3 and 4 until the entire scenario has been modeled. 5.
Modeling objects and links
The Collaboration diagram uses an Object diagram as its foundation. First, determine which objects will participate
in the scenario. Draw the objects with only the name compartment, not the attributes. Then draw the links between
them. Any pair of classes may have more than one type of association, for example a person can own a car and
drive a car. You need to use the Class diagram as your guide to identify the valid types of links that apply to the
current sequence of messages.
Figure 8-18 shows objects and their links. You may leave the link names off of the links when there is only one
type of association between the related classes. Add the names if there is more than one kind of link possible
between the two objects and there is a need to clarify which type of relationship supports the interaction.
Figure 8-18: Objects and links.
Note that the self-reference in messages 2 and 5 requires a link on the Collaboration diagram even though
technically there is no link. A message in general does not require a link when the same object is invoking and
responding to the message. This is simply a limitation of the Collaboration diagram notation.
Modeling messages and stimuli
For each step of the scenario, draw the message arrow from the sending object to the receiving object, and
parallel to the link between them. Having many messages (arrows) placed on the same link is valid and, in fact,
common. With a lot of arrows the link can become crowded and difficult to read so be careful to lay out the
diagram so that it can be read and understood. Number the messages in the order in which they occur.
The format for specifying a message is the same as on the Sequence diagram:
predecessors / seq-term iteration [condition] return ':=' operation
Most often however, the message displays only the operation portion of the message syntax. Figure 18-19 models
the scenario from the Sequence diagram in Figure 8-16.
The Collaboration diagram provides one other valuable feature. A link may be stereotyped to make it clear
whether the link is persistent or transient. The links based on the Class diagram are typically references that
persist between executions of the application. A transient link is a reference that only exists during the execution of
a task or an application. For example, the link between the TheaterSystem object and the Event objects only exists
because the theater system obtained the object references from the Venue. The stereotype transient may be
placed next to the link between the TheaterSystem and Event objects to make this clear.
Active objects
An active object refers to an object that initiates controls or directs other objects. Contrast this with passive objects
that simply respond to requests. In Figure 8-19 the Theater System represents an active object, while the Venue
and Events objects are passive. To identify an active object, the border of the object is highlighted or thickened. In
addition, the property keyword {active} may be placed in the object icon. Figure 8-20 shows both techniques.
Figure 8-19: Messages on a Collaboration diagram.
Figure 8-20: An active object.
In many instances the active object is actually a collection of objects, as is the case with the TheaterSystem object.
If you want, you may also expand the TheaterSystem object to a large rectangle, and then model the objects that
make up the TheaterSystem inside the rectangle.
Multi-objects
A multi-object is a set of objects of the same type. When you need to perform the same operation on all objects in
a set, you can represent the set as an object icon on top of another object icon, offset enough to make it appear as
one of a number of objects. The Performance object in the top right corner of Figure 8-21 is a multi-object icon.
Figure 8-21: Multi-object..
Figure 8-21 illustrates a common usage of the multi-object. In order to perform an operation on all members of the
set, you typically need to gain access to each member. Message 1 in Figure 8-21 asks for each performance by a
unique ID number. Note the iteration symbol on message 1. Then the event invokes message 3, cancel(), on each
performance.
<Day Day Up>
<Day Day Up>
Comparing the Sequence and Collaboration Diagrams
Sequence and collaboration diagrams model the same two elements: messages and objects. In fact, the two
diagrams are so similar that some modeling tools, such as System Architect and Rational Rose, provide a toggle
feature to switch back and forth between the two views.
Like the Sequence diagram, the Collaboration diagram provides a tool for visually assigning responsibilities to
objects for sending and receiving messages. By identifying an object as the receiver of a message, you are in
effect assigning an interface to that object. The message description becomes an operation signature on the
receiving object. The sending object invokes the operation.
All of the message types are supported on both diagrams.
Both diagrams are also excellent tools for evaluating coupling. Coupling is a measure of quality that tests the
degree of dependency between model elements. Dependency is clearly seen in the need for communication
between objects. If you review all of the diagrams in which a pair of objects participate, you can see how many
messages and what type of messages they use to work together. This provides the opportunity to evaluate
opportunities to reduce or simplify the communication and improve the design. This is very difficult to do when the
only resources you have are the Class diagram or code.
Despite their similarities, the diagrams also have important differences. The Collaboration diagram places a priority
on mapping the object interactions to the object links. That is, the Collaboration diagram draws the participating
objects in an Object diagram format, laying the messages parallel to the object links. This perspective helps
validate the Class diagram by providing evidence of the need for each association as the means of passing
messages. In contrast, the Sequence diagram does not illustrate the links at all.
This highlights an advantage of the Collaboration diagram. You cannot draw a message where there is no link,
because there is no physical path across which the message can travel. On a Sequence diagram, there is nothing
stopping you from drawing an arrow between two objects when there is no corresponding link, but doing so would
model a logical interaction that cannot physically take place.
You can also see this as an advantage of the Sequence diagram, in that drawing a message where there is no link
reveals the requirement for a new link. Just make certain that you actually update your Class diagram or you won't
be able to implement the message illustrated on the diagram.
Another advantage of the Sequence diagram is its ability to show the creation and destruction of objects. Newly
created objects can be placed on the object lifeline at the point where they are created. The large X at the end of a
timeline shows that the object is no longer available for use. On the Collaboration diagram, the object is either
there or it is not. There is no way to indicate creation or termination apart from the description of the message and
a constraint. However, since the structure is represented in a static Object diagram layout, it is difficult to be certain
when the constraint becomes relevant.
Sequence diagrams also have the advantage of showing object activation. Because the Collaboration diagram
does not illustrate time, it is impossible to indicate explicitly when an object becomes active or inactive without
interpreting the types of messages.
<Day Day Up>
<Day Day Up>
Integrating the Sequence and Collaboration Diagrams with the Class
Diagram
Because the Class diagram is the source for code generation in object-oriented development, you need to map
what you find in the interaction diagrams back to the Class diagram. Each message becomes an operation on the
class of the receiving object. In the classes in Table 8-2, you can see each of the messages from Figure 8-19
declared as an operation on the receiving objects.
Table 8-2: Updated Class Operations
Message Class Operation
1: getEvent (start, end) Venue getEvents(start:Date, end:Date):Vector
2: return Venue See return type on message 1
3: dislayEvents(events) CustomerActor displayEvents(events:Vector):void
4: getPerformances(events) TheaterSystem getPerformances(events:Vector):Vector
5 *[for each
event]:getPerformances (start,
end)
Event getPerformances(start:Date, end:Date): Vector (See
the list following Table 8-2)
6: return performances Event See return type on message 5
7: return performances TheaterSystem See return type on message 4
8: displayPerformances
(performances)
CustomerActor displayPerformance(performances: Vector):void
9: selectPerformance
(performance)
TheaterSystem selectPerformance(performance:int):void
10: display Confirmation() CustomerActor displayConfirmation():void
11: return yes CustomerActor See return type on message 10
12: savePerformance() TheaterSystem savePerformance():void
13: closeSelect
PerformanceWindow()
TheaterSystem closeSelectPerformanceWindow()
Note the following in reference to Table 8-2:
Messages map to operations. 1.
Conditions are placed in the implementation logic of the calling object. 2.
Iteration logic is placed in the implementation logic for the calling object. 3.
Parameters and return value identify attributes that need to be defined in a class. 4.
For each new attribute discovered, the owning class must provide accessor operations to maintain the value 5.
4.
and to read the value.
5.
<Day Day Up>
<Day Day Up>
Summary
The Sequence and Collaboration diagrams illustrate communication between objects. The scope of the
interactions is typically one scenario, but the diagrams may be used to model interactions at any level of
abstraction in the design of a system.
The Sequence diagram models messages between objects on a timeline. The timeline aids in describing the
relative order of execution and the addition of time and duration constraints.
Object lifeline: The object lifeline uses an object icon at the top and a vertical dashed line below the object
icon to represent a timeline. The timeline represents the total duration of the interaction.
Messages: Some messages are predefined by UML; synchronous (solid line with solid arrowhead),
asynchronous (solid line with open arrowhead), and returns (dashed line with open arrowhead). Messages are
considered to be instantaneous when appearing on a Sequence diagram so they are placed horizontally
between object lifelines.
Activation and Focus of Control: An object is considered active while performing work in response to a
message or signal. The dashed line of the lifeline can be widened into a rectangle to represent the active
period in its life. An object that oversees an interaction remains active throughout the exchange. This object is
the focus of control for the interaction.
Object creation and Termination: Objects created during the interaction have a lifeline that starts at the point in
the vertical timeline of the interaction when the object constructor is called. When an object is deleted or
destroyed the lifeline is terminated with a large "X".
The Collaboration diagram model interactions between objects by illustrating the links that provide the
communication paths between the participating objects. The messages must be numbered to define the order of
execution.
Objects and links: Objects and links are represented with the same notation as on an Object diagram.
Messages: Messages use the same syntax as for Sequence diagrams.
Active objects: Active objects are modeled with a thick border. Active objects correspond to the focus of
control objects on a Sequence diagram. They Initiate the interaction and govern its execution.
Multi-objects: Interaction diagrams can model the use of a set of objects using a multi-object, an icon that
represents a set instead of a single instance.
The information discovered on the interaction diagrams identifies changes to the Class diagram. Reconciling the
interaction diagrams with the Class diagram includes the following:
Messages become operations.
Parameters and returns become attributes or operations to obtain derived attributes. The owning class must
provide accessor operations.
Conditions become implementation logic.
Iteration becomes implementation logic.
<Day Day Up>
<Day Day Up>
Chapter 9: Modeling Interactions in UML 2.0
Overview
UML 2.0 models object interactions using the following four different, but related diagrams. The diversity of the
diagrams reflects the many reasons for evaluating interactions in a system design.
A Sequence diagram is a time-oriented view of the interaction between objects to accomplish a behavioral
goal of the system. An interaction may be modeled at any level of abstraction within the system design, from
subsystem interactions to instance-level interaction for a single operation or activity.
A Communication diagram is a structural view of the messaging between objects, taken from the Collaboration
diagram concept of UML 1.4 and earlier versions.
An Interaction Overview diagram is a high-level view of sets of interactions combined into a logic sequence,
including flow-control logic to navigate between the interactions.
A Timing diagram is an optional diagram designed to specify the time constraints on messages sent and
received in the course of an interaction.
NoteThe UML 2.0 specification also describes a tabular alternative to the interaction diagrams that is not
covered in this text because there is no tool support for it, which effectively removes it from the
mainstream.
The focus of all these diagrams is messaging between objects, that is, how objects ask and answer questions, tell
one another to do things, and notify one another of events within the system. The interaction diagrams do not
explain how objects manipulate information in order to answer questions, interpret events, or determine the need
for information from another object. Data manipulation may be modeled using Activity diagrams that model control
and object flow in the fulfillment of a behavior. State Machine diagrams may be used to understand when and why
an object initiates and responds to specific behaviors.
The interaction diagrams simply model the fact that the messaging does take place, in what order, and under what
constraints. The focus on messaging reveals the interface requirements for the objects that participate in the
messaging. Simply put, in order for an object to receive a message it must have an interface that matches the
message. The interface defines the fact that the object is prepared to receive and respond to the message. An
object interface is defined as an operation signature. Having an operation signature on an object implies that the
object has a corresponding method that defines how the object will respond to the message.
For example, in Figure 9-1, when a customer wants to select a seat at a show, she needs to be able to tell the
ShowSeat object that it has been selected. The customer sends the message "select" to the ShowSeat object.
The ShowSeat object has a matching operation signature that enables it to receive the message. The operation
has a method to implement the response to the message. (Note that the method is not modeled on a Class
diagram.)
Figure 9-1: A customer selects a seat at a show (a ShowSeat).
Operation signatures may include parameters and return types. Both parameters and returns represent data that is
passed during the interaction. Data in an object-oriented system is always encapsulated within an object, which
means that interactions not only reveal operations, but they also reveal vital information about the attributes that
need to be included in classes. Tracking down the classes that own the data values can help identify new classes
and new accessor operations.
<Day Day Up>
<Day Day Up>
Modeling a Sequence Diagram
Let's begin with the Sequence diagram. The core of the notation for the Sequence diagram remains almost
unchanged, that is, it still includes object lifelines and messages. The changes in UML 2.0 are primarily additions
to the features of Sequence diagrams.
Table 9-1 identifies the complete list of new and existing features of the Sequence diagram defined in UML 2.0.
Table 9-1: Features of the UML 2.0 Sequence Diagram
Concept New/Existing
Object lifeline Existing
Stimulus (Message) Existing, but called Message. (UML 2.0 does not define a distinction between
message and stimulus as prior UML versions did.)
Time observation and
constraint
Existing
Activation Existing
Suspension New
Frame New
Interaction New
Interaction occurrence New
Event occurrence New
Interaction fragment New
Combined fragment New
Interaction operator New
Duration observation and
constraint
New
The main purpose of the new features is to add the capability to partition and to reuse interactions. The Sequence
diagrams defined in UML 1.4 and earlier were basically standalone diagrams. In prior UML versions, if you wanted
to reuse a portion of a diagram, or even an entire diagram, you had to use comments. UML 2.0 supports the
explicit definition of an interaction occurrence as a set of object lifelines and messages (and all other applicable
notations such as timing constraints). Interaction occurrences may be combined (combined fragment), and/or
modeled in a flow of control (Interaction Overview diagram).
New features such as interaction operators and duration constraints provide the means to model more complex
and more precise definitions for interactions than were possible in previous versions of the Sequence diagram.
Modeling a frame
The first new concept for Sequence diagrams, and for UML diagrams in general, is a frame. Frame is a concept
borrowed from the general UML 2.0 notations for diagrams, found in Appendix A of the specification. A frame
provides a portable context for a diagram.
Once enclosed in a frame, a diagram may be nested inside another frame/diagram. By nesting a frame inside of
another frame, the enclosing diagram effectively reuses the entire enclosed diagram inside the new context. For
example, a test suite for the theater system would include many test cases. Many of the test cases might start by
looking up the seats available at a given performance. The set of interactions for looking up the seats at a
performance may be defined once and referenced in many test cases.
A diagram is enclosed in a frame, a boundary that consists of a heading and a context area as shown in Figure 9-
2.
Figure 9-2: UML diagram frame.
The <heading> is a string contained in a name tag, a rectangle with a cutoff corner. The <heading> is placed in the
upper left corner of the frame and uses the following syntax:
[<kind>]<name>[<parameters>]
Kind is optional and refers to the type of diagram; for example, the keyword sd represents a Sequence diagram,
and cd represents a Class diagram. Parameters are also optional. They list the data values passed into the frame
context area when the frame is invoked. The <contents area> contains the diagram.
Figure 9-3 shows a frame that contains a Class diagram, named cd 12.1, with no parameters.
Figure 9-3: A frame for a Class diagram.
NoteThe naming convention for the diagram is entirely up to the modeler.
Figure 9-4 shows nested frames. Frame cd 12.1 from Figure 9-3 is nested within frame package 12. The package
on the left is the elided form of the package. The package diagram on the right reveals the contents of the
package as being one Class diagram and one Sequence diagram. The nesting feature of frames is used to great
advantage in the Interaction Overview diagram where a number of diagrams are linked together in a flow of
control.
Figure 9-4: Nested frames.
Modeling interactions
In Sequence diagrams, frames provide the means to isolate a reusable set of interactions. To exploit this new
feature, however, we must first understand basic interactions. Simply stated, an interaction is a sequence of
messages passed between objects to accomplish a task. Objects may be created and terminated. They may ask
questions or make demands on other objects by invoking operations, or they may notify one another of events
using signals.
Lifeline
A lifeline represents an object. Each object in an interaction is modeled using object notation, that is, a rectangle
containing the object name.
NoteUML 2.0 draws a distinction between interactions between objects and interactions between parts of a
collaboration or an internal structure. The following text addresses the use of objects first. The use of
parts is covered in the context of working with aggregate objects. Object names are underlined. Part
names are not underlined. Interaction diagrams can be used to depict both types of lifelines.
The object icon is placed atop a vertical dashed line (as seen in the following figures), which represents time as a
lifeline for the object. The lifeline runs from the beginning of the interaction, at the top of the diagram, to the end of
the interaction at the bottom of the line. The length of time represented by the lifeline is however long it takes to
complete the interaction. The exact time is irrelevant in a Sequence diagram. Instead, an interaction concerns itself
with the ordering of messages within the interaction.
The relative placement of messages on the lifeline reflects the relative ordering of the messages from top to
bottom as executing from beginning to end. Again, the amount of space between messages on the lifeline does
not reflect a measurement of time. Only the relative position matters, that is, one message takes place before or
after another message. In fact, for all practical purposes, when reviewing a Sequence diagram, all messages are
considered to take no time at all. The only relevant time values on a Sequence diagram are expressed as
constraints on the amount of time to send and receive events during the course of the interaction. These features
are covered in the "Modeling duration and timing" section later in this chapter.
The vertical line illustrates the life span of an object within the context of a single interaction. That is to say, when
an object exists prior to the beginning of an interaction, the object icon is placed at the top of the interaction
diagram. If the object is created during the execution of the interaction, the object icon appears at a relative vertical
position within the diagram coinciding with the point in time when it is created.
Figure 9-5 shows the object placement for pre-existing objects and objects created during an interaction. In both
examples, the event object, : Event, exists before the interaction begins, so it is placed at the top of the diagram.
The performance object, : Performance, is created midway through the interaction, so it is placed below the top,
level with the message that creates it. Both forms are valid.
Figure 9-5: Object placement within a Sequence diagram interaction.
The object name within the object icon uses the following format:
[name ['[' selector ']']] [' : ' class_name] [decomposition] self
The name is an optional object identifier, that is, the name of a specific instance. For example, Figure 9-5 could
have used Chicago: Event or 74856: Event to identify a particular event object used in a test case.
However, it is also common to use the anonymous form of the object name, that is, : classname, underlined.
The :classname notation identifies the type of the object. The anonymous form indicates that the interaction works
the same for any instance of the specified object type.
The anonymous form also may reflect a collection of objects of the specified type. For instance, the interaction in
Figure 9-5 could represent the creation of a series for performances for the same event. In this case, the same
interaction would be repeated for every performance scheduled for the same event. It would not be practical, or
add any information, to try to create and name every individual test value for each performance scheduled in the
test. (Looping and iteration are covered later in this chapter.) Instead, a single object icon represents the set of
created performance objects.
The selector is an optional expression that identifies a single instance in a collection of instances of the same
type. For example, midway through an event's scheduled set of performances the event might be cancelled. An
interaction may be specified to cancel all performances whose scheduled dates are equal to or greater than today.
The selector expression would evaluate the date of the performance against the selection criteria to find only those
performances that have not yet taken place.
Modeling part decomposition
So far, I've talked about interactions between objects. UML 2.0 also supports interactions between parts of an
aggregate object. Here I use the term part as defined in the context of internal structures described in Chapter 7.
When using an aggregate object in an interaction, most messages are directed at that object. There are two
means of directing messages at the parts of the aggregate. Both types of interactions require that the parts be
represented as individual lifelines.
The aggregate grants access to a part object so that another object may manipulate it directly. 1.
2.
1.
The interaction specifically models the propagation of messages from the aggregate to its parts. 2.
In the first case, once the aggregate object provides a reference to the part object, other objects may interact with
the part directly. So the part object is modeled like any other object with messages directed at its lifeline.
In the second case, other objects make requests of the aggregate. The aggregate interprets and propagates the
request down through its structure until the request reaches the part or parts that can satisfy the request. The
response to the requestor is then coordinated by the aggregate.
The interaction between the aggregate object and its parts is often modeled in a separate interaction, on its own
Sequence diagram. To refer to this other Sequence diagram, the object lifeline name may include a reference to
the name of the other Sequence diagram. This notation option utilizes the decomposition parameter of the lifeline
name and is called a PartDecomposition. The decomposition value in the lifeline name is a reference to an
interaction that is broken into a set of interactions defined elsewhere against the parts of the object whose lifeline
contains the reference. This is the first example of how UML 2.0 supports reuse of object interactions.
Figure 9-6 models a Sequence diagram in which the venue manager cancels an event. This action involves a
reference to a series of behaviors to perform the Cancel operation on the event object, which includes a
predictable interaction between the event and its performances when the event is cancelled.
Figure 9-6: A draft of the interaction for canceling an event.
NoteI have referred to performances in Figure 9-6 using object notation. In the preceding text I referred to the
performances as parts of an event. UML 2.0 notation for parts does not underline the lifeline name. I
chose to continue to use object notation (underlined names) throughout this chapter rather than mix the
examples.
However, an event may be cancelled in a variety of circumstances, such as closure of the venue due to weather,
illness of a performer, or poor attendance. In each situation, the event would perform the same set of interactions
to cancel all the appropriate performances. UML 2.0 enables us to model the interaction between the aggregate
event object and its parts, the performances, separate from all of the interactions in which that same set of
behaviors might be required. Figure 9-7 models a reference to the reused interaction within the context of another
interaction that cancels an event.
Figure 9-7: Modeling a reference to an existing interaction between parts and their aggregate.
The reference to Event_Cancel is a reference to the name of the interaction that defines the messaging between
an event and its parts, the performances. The naming convention is up to you as the modeler, just as coding
conventions are up to the programming staff.
NoteUsing a reference (ref) only applies to objects defined with internal structures.
The entire name may be replaced with the keyword self, which refers to the classifier that owns the interaction.
The classifier defines the set of interfaces that provide access to the behaviors modeled in the interaction. In the
previous examples, the owning classifier could be the scheduling system, which supports a number of features
including canceling, scheduling, and rescheduling events. Using self allows the owning classifier to participate in
the interaction.
Modeling object termination
When an object is destroyed during the execution of an interaction, the lifeline is terminated using the stop notation,
a large X at the point in the lifeline when the object is destroyed.
Figure 9-8 models the destruction of a performance object during the event cancellation interaction. An X is placed
on the lifeline at the end of the delete operation (after the return) and the lifeline stops. The absence of the lifeline
from the diagram after this point prevents any messages from being directed at the deleted object.
Figure 9-8: Stop notation for a Sequence diagram.
The absence of any stop on a lifeline indicates that the object continues to exist beyond the end of the interaction.
Modeling object activation and suspension
When a message is sent to an object it invokes a behavior on that object and the object is said to be activated. The
activation of an object is depicted as the start/top of a gray rectangle on the lifeline as shown in Figure 9-9. The
rectangle itself is called the focus of control. The focus of control depicts the period of time when an object is
performing an action, either directly or through a subordinate procedure.
Figure 9-9: Modeling object activation.
The typical start/top of the focus of control icon is at the point that a message hits the lifeline, placing a demand on
the resources of the object. The end/bottom of the focus of control icon is usually when either the behavior is
completed (for asynchronous messages or signals) or control is returned to the requesting object (for synchronous
messages).
TipTechnically UML 2.0 allows both gray and white rectangles.
Object activation is covered in more detail in the "Execution occurrence and event occurrence" section later in the
chapter.
Execution of a behavior may also be suspended temporarily. This most often happens when a behavior includes
sending a synchronous message to another object. The sending object stops execution and must wait for a
response from the receiving object before it can proceed. For example, in Figure 9-10, the event object sends a
message to each performance object. Each time the event object sends a cancel message to a performance
object, the event object suspends execution until it receives control back from the invoked performance object.
Figure 9-10: Modeling object suspension.
Object suspension is modeled as a white rectangle with a dashed border. The start/top of the rectangle is placed
on the lifeline where the event sends the cancel message to the performance object. In Figure 9-10 the start/top of
the suspension icon is positioned at the base of message #3, the point in the interaction when control is passed
from the event to the performance. The end/bottom of the suspension symbol is at the point in the lifeline where
the performance returns control to the invoking event object. In Figure 9-10 the end/bottom of the suspension icon
is positioned at the arrowhead of message #4, when control returns from the performance to the event.
The suspension icon is typically placed over and a little to the right of the activation icon to identify periods of time
during the execution of a behavior when execution is halted in order to request help from other objects.
The focus of control may also be used to depict an object that oversees an interaction. An object playing this role
of overseer is active throughout the interaction. In the previous examples, the customer actor initiates the
interaction and has the option to cancel the interaction and decide what to do with the results of the interaction at
any time. To designate the role of the overseer, use the focus of control icon for the entire length of the object's
lifeline, as shown in Figure 9-11.
Figure 9-11: Modeling a focus of control using the activation icon.
In some modeling tools, the activation icon routinely extends beyond the return point in the lifeline to indicate that
an object might be active for a short time after receiving control so that it can respond to the return and complete
the requesting behavior. Figure 9-12 shows this alternative presentation, which does not substantively alter the
meaning of the diagram.
Figure 9-12: Alternative activation presentation.
State invariant
Sometimes the response of an object to a message depends on the condition or state of the object at the time that
the message is received. UML 2.0 adds constraint notation to the lifeline to support modeling of the required state.
State describes the condition of the object in terms of the values of its attributes at a point in time. The state of an
object may be depicted using either of two notations:
Curly braces enclosing a constraint expression. Figure 9-13 shows a constraint specifying that the event
object must be in the state ACTIVE if the subsequent interaction is to be a valid sequence of events.
1.
Figure 9-13: Modeling a lifeline constraint using curly brace notation.
1.
A state icon as defined in the State Machine diagram specification. Figure 9-14 shows a state icon
identifying the ACTIVE state of the event object.
Figure 9-14: Modeling a lifeline constraint using a state icon.
2.
The use of a state invariant on a lifeline assumes that all messages prior to the state invariant have been
completed. For testing purposes, if the state invariant is true, then the messaging following the state invariant
specification is considered a valid sequence of events. If the state invariant tests false, the subsequent messaging
is characterized as an invalid sequence of events.
A state invariant may be specified before an interaction to define the conditions under which the set of messages
may be passed. A state invariant may also be used following a series of messages to define the required condition
of an object after the completion of the series. Figure 9-15 models the state invariant Event::CANCELLED at the
end of the cancel interaction, meaning that when the interaction is completed the event object must be in the
CANCELLED state.
Figure 9-15: Modeling a state invariant as a requirement after the execution of an interaction.
Modeling messages
In the previous object lifeline examples, each figure included horizontal arrows between lifelines. These arrows
contained text that described a message passed from one object to another. A message is the basic form of
communication in a Sequence diagram interaction. It defines one specific kind of communication. Communication
can raise a signal, invoke an operation, and create or destroy an instance. The message specifies not only the kind
of communication, but also the sender and the receiver.
NoteUML 2.0 no longer defines a distinction between message and stimulus as UML 1.4 did.
A message is described as either a signal or an operation message. The format for a message uses the following
syntax:
[attribute =]
signal or-operation-name [ ( arguments ) ] [: return-value] |
'*'
arguments ::= argument [ , arguments]
argument ::= [parameter-name=] argument-value |
attribute= out-parameter-name [:argument-value] |
Note the difference between message syntax and the attribute and operation parameter syntax used in Class
diagrams. Messages specify values, and attribute and operation parameter declarations specify data types. The
class is a specification of a type of information. A message specifies a unique set of values sent as the content of a
unit of communication in a test case or example. So a message refers to argument values and return values
instead of attribute and parameter definitions.
Both signal and operation messages may add argument values and return values. Arguments are simply data
values that can be addressed by name by the receiving object's method. Each parameter is either specified as a
name/value pair or as a dash (-). The dash represents an empty parameter value.
Any number of parameters may be used in a message. Multiple parameters are separated by commas.
Arguments of a message are restricted to
Attributes of the sending object (lifeline)
Constants
Symbolic values (wildcard values representing any legal value)
Explicit parameters of the enclosing interaction (described later in the "Arguments and gates" section)
Attributes of the class owning the interaction
Figure 9-16 redrafts the example in Figure 9-11 to add parameters to the cancel messages on the event and
performance objects (messages 1 and 3). The two new parameters define the date on which the cancellation is to
take affect, and the person who authorized the cancellation. A void return value is used to indicate that the
operation will likely throw exceptions rather than return any explicit values.
Figure 9-16: Declaring messages with parameters.
For examples' sake, message 3 uses a dash (-) for the auth parameter value to illustrate the use of an unknown
value for one of the parameters.
NoteAll the examples in this chapter use a sequence number in front of each message. This is not a notation
defined by the UML 2.0 standard, but it is a practical aid that is implemented in many modeling tools. The
sequence numbers significantly aid discussions of the diagram during modeling and review sessions.
Execution and event occurrences
A message defines a unit of communication between two objects. Each unit of communication implies a behavior
that manages that communication and performs the work invoked by the operation call or the response to the
receipt of a signal. Earlier in this chapter, the period of time on an object lifeline when it was busy doing this work
was designated as the focus of control. This terminology is a carryover from UML 1.4.
UML 2.0 expands on the description of this behavior. Each behavior is normally associated with two events, as
shown in Figure 9-17. An event is formally defined as an EventOccurrence. The sendEvent is an EventOccurrence
at the base of the message arrow where the message departs from the lifeline of the sending object. The
receiveEvent is an EventOccurrence at the point of the message arrow where the arrow hits the lifeline of the
receiving object.
Figure 9-17: A message with sending and receiving EventOccurrences.
The previous description of activation defined start and end points. Using this new event vocabulary, the start of a
behavior is defined by what UML 2.0 now calls receiveEvent. The end of a focus of control is defined by a
sendEvent. An ExecutionOccurrence defines the behavior performed (executed) between the moment when the
object experiences the receiveEvent and the moment when the object experiences the sendEvent. Figure 9-18
adds the new definitions to the example from Figure 9-11.
Figure 9-18: Modeling an ExecutionOccurrence (activation) and the bounding receiveEvent and sendEvent
(EventOccurrences).
Message sorts
UML 2.0 defines different varieties of messages. Actually, there are two forms of two basic varieties. The two forms
are operation calls, and signals. The two varieties, or sorts as UML 2.0 calls them, are synchronous and
asynchronous. Operation calls express the invocation of an operation on the receiving object. A signal represents a
message object sent out by one object and handled by other objects that are equipped to respond to it. But a
signal does not refer to any operation defined on an object. In contrast, a call must match the signature of an
operation on an object.
The sorts of messages supported by the notation are defined in an enumeration called MessageSort.
Synchcall: A synchcall invokes an operation on an object and waits for a response. The parameters of the call
must match the parameters of the invoked operation signature.
Asynchcall: An asynchcall invokes an operation on an object but does not wait for a response. The
parameters of the call must match the parameters of the invoked operation signature.
SynchSignal: A synchsignal is issued without any reference to a specific operation on any object, but it requires
the issuing object to wait for a response before continuing with the behavior that issued the signal. The
parameters of the signal match attributes of the signal object.
AsynchSignal: An asynchsignal is issued without any reference to a specific operation on any object. It does
not require the issuing object to wait for a response before continuing with the behavior that issued the signal.
The parameters of the signal match attributes of the signal object.
A synchronous message is represented by a solid arrowhead. The reply message from an operation uses a
dashed line and a solid arrowhead, as Figure 9-19 shows.
Figure 9-19: A synchronous message and return.
CautionNote that the diagram summary in the spec conflicts with the message notation in the body of the
spec. I used the notation from the body of the spec.
An asynchronous message is represented by an open arrow head, as shown in Figure 9-20.
Figure 9-20: An asynchronous message.
A message that creates an object, often called a constructor, is represented by a dashed line with an open
arrowhead, as Figure 9-21 shows.
Figure 9-21: A message that creates an object.
Message kinds
UML 2.0 also adds some new descriptive qualities for messages to help discriminate between the many kinds of
messages. At the most basic level, a message may be either "complete" or "unknown".
Complete: Both the sendEvent and receiveEvent are present. A complete message is fully defined with a
signature, a sender, and a receiver. It is modeled using the arrow types described in the previous section
"Message sorts."
Unknown: Both the sendEvent and receiveEvent are absent. An unknown message refers to a message that
can be described in terms of a signature but no decision has been made about who should send or receive it.
This can happen during the modeling process. For example, when translating information from an Activity
diagram to a Sequence diagram, a given activity describes a behavior. The modeler knows what the behavior
is supposed to do, but has not yet determined which objects should be responsible for initiating the behavior or
for executing the behavior.
NoteThe concept of unknown messages poses a problem in a modeling tool because there is no place to
document an unknown message.
UML 2.0 makes an attempt to provide a means to deal with messages in test cases that address a problem with
message delivery. Some messages may be sent but never received. Other messages, likely signals, may be
picked up without knowing exactly what object generated the messages. The term lost is used for messages that
never reach their destination. The term found is used for messages that are picked up without knowing their
source.
In lost messages, the sendEvent is present and the receiveEvent is absent, visually suggesting that the
message was sent but not received. It implies that the Sequence diagram modeling this situation will address
what the system should do when a message does not arrive as expected. For example, the Sequence
diagram might address what happens if you submit an order to purchase tickets at the theater (from the user
interface application) but the order processing system never receives your request. A lost message is modeled
as a small black circle at the arrow end of the message, as shown in Figure 9-22.
Figure 9-22: A lost message.
In a found message, the sendEvent is absent and receiveEvent is present. A found message is used when the
source of the message is outside the scope of the current model, so how and by what object the message is
generated simply don't matter to the model. The only relevant information is that the message needs to be
received and handled by the modeled application or system. A found message is modeled as a small black
circle at the starting end of the message, as shown in Figure 9-23.
Figure 9-23: A found message.
Modeling duration and timing
Earlier the statement was made that interactions are considered to be instantaneous, that time is irrelevant. While
that is true, the Sequence diagram does support the ability to specify constraints on the allowed time between
events. This is needed in order to identify interactions that cope with system performance level failures. For
example, when a customer submits an order for theater tickets, we need to know that the transaction will not take
more than 2 seconds. If it does, we might need to reset the system, recycle the transaction, and/or notify the
customer to retry his transaction. The point is that by specifying the constraint on the performance of the
interaction, the model identifies the opportunity to proactively address problems related to performance.
UML 2.0 provides two types of constraints on the performance characteristics of interactions: duration and time.
Duration refers to the amount of time it takes for something to happen. A duration constraint is a restriction on the
length of time it takes to complete a task. Time refers to a point or period in time when something must happen. A
time constraint defines a specific time when a task must be completed. For example, the duration of the task of
writing this page can be specified as between 1 and 2 hours. The time constraint for writing this page may be
specified as between Friday at 9:00 AM and Friday at 11:00 AM.
Figure 9-24 models three examples of duration constraints. The first, at the top, shows a duration constraint that
restricts the amount of time between a sendEvent and a subsequent receiveEvent on the same lifeline.
Specifically, the constraint defines a requirement that the application must take between 0 and 3 seconds to go
from the sendEvent of the placeOrder() message to the receiveEvent of the return message.
Figure 9-24: Defining duration constraints between EventOccurrences.
In the second example, at the bottom of Figure 9-24, the duration constraint states that the return from the
placeOrder message must be received no more than 3 seconds after the sendEvent of the return. The duration
constraint may be placed along the margin of the diagram (as shown on the left side of the bottom diagram) or as
a constraint on the message, in this case message #2 the return.
A time constraint is expressed in terms of specific moments in time, such as 3:00 PM. Figure 9-25 shows two
examples of time constraints. The top example uses a TimeObservationAction (time=now) when Customer sends
message #1. The time constraint {time..time+3 seconds} requires that message #2 be received no more than 3
seconds after the time established by the TimeObservationAction. This use of a time constraint is essentially the
same as a duration constraint.
Figure 9-25: Defining time constraints.
The example in the bottom half of Figure 9-25 establishes the time using some event within the system outside the
interaction illustrated in this Sequence diagram. The time constraint requires message #2 to be received no more
than 3 seconds after this event. The time event could be a signal, a system event, or a selected point in time such
as 3:00 PM.
Use duration constraints when the timing of the constrained interactions is relative. Use time constraints when the
timing of the constrained interactions is imposed by external events or requirements.
Reusing interactions as interaction occurrences
One of the substantial enhancements to the Sequence diagram in UML 2.0 is the capability to reuse interactions.
An interaction defined in one context may be isolated into a reusable unit called an InteractionOccurrence. Put
simply, an interaction occurrence is a symbol that refers to an interaction that is used within another interaction. An
interaction occurrence may be used in any number of other contexts. (Earlier in this chapter, an interaction was
reused by specifying a reference in the object lifeline. The reference pointed to an interaction between an
aggregate and its parts, which had been defined in another Sequence diagram.)
In modeling, problems can be represented at many different levels of abstraction. One model may define one
atomic level interaction. Another model may combine two or more interactions to perform a more complex task.
For example, the theater system has to provide the means to schedule a performance and to cancel a
performance. Each task may be performed independently in a meaningful way. But to reschedule performances,
one possible implementation would be to cancel the original performance and schedule a new one. Regardless of
whether this makes good business sense, it provides a good example of how to use interaction occurrences to
construct new system behavior.
To model the use of interaction occurrences we need to use the frame concept. Each interaction occurrence is
represented by a frame with the name of the interaction. In fact, for the example shown in Figure 9-26, I enclose
the entire Sequence diagram sd Reschedule Performance, which consists of two consecutive interaction
occurrences, in a frame. That is, in order to reschedule a performance, the system first cancels the performance,
and then schedules a new performance.
Figure 9-26: Using two interaction occurrences to construct a larger interaction/Sequence diagram.
Using this technique, the modeler could build a number of scenarios very quickly by reusing common portions of
scenarios to build other scenarios. For example, in many use cases, the exception or alternative paths/scenarios
are merely offshoots from the main flow of events. One or more interaction occurrences may be defined for those
portions of the use case logic that remain the same throughout some or all of the exception scenarios, so the
Sequence diagrams that model the exception processing can focus entirely on the interactions that are unique to
the exception processing instead of redrafting the same interactions or using comments that cannot be checked
without interpreting the text.
NoteThe referencing Sequence diagram must include all the object lifelines that are used by any of the
referenced interaction occurrences.
Reference (Ref) operator
In Figure 9-26, the keyword ref is placed in the top left name area of the frame. This alerts the reader that the
content of the frame is defined elsewhere, that is, in the diagram named in the content area. The keyword ref is
one of many InteractionOperators. The complete list of interaction operators is covered later in the "Modeling
behavior structures using combined fragments" section.
Arguments and gates
In the example modeled in Figure 9-26, rescheduling a performance requires the venue manager to specify the
performance and the new date and time for the performance. To do so, the interaction has to provide the means to
pass these values, these arguments, into the interaction.
The complete description for an interaction uses the syntax
interactionname [ ' ( 'arguments' ) ' ] [ ' : 'returnvalue]
arguments : := argument [ , arguments]
argument : := [parameter-name= ] argument - value |
attribute= out-parameter-name [ :argument - value] |
The arguments are declared as name/value pairs using the same syntax used in messages. For the reschedule
example, the interaction name might read:
reschedulePerformance(performance=12345, newDate = 12/12/04, newTime=7:00 PM)
When the arguments are received from a message that originated from a source outside the interaction, the
arguments are received through a gate. On an interaction, the gate is called a formal gate. On an interaction
occurrence, the gate is called an actual gate. (Try not to waste too much time wondering why these names were
chosen.) In the reschedule performance example, a venue manager initiates the interaction by sending the
message reschedulePerformance (performance:12345, newDate: 12/12/04, newTime: 7:00
PM). The message is modeled in Figure 9-27 as coming from the edge of the Reschedule Performance frame to
the Event object lifeline. A gate corresponds to an input pin on the edge of the frame, so in this example there are
technically three formal gates on the interaction, one for each parameter value.
Figure 9-27: An interaction with three formal gates to receive and pass on three parameters from a message
from an external source.
Note that the expressions in the content area of each interaction occurrence are not an operation signature-they
are interaction occurrence names with parameters. The actual gate of each interaction occurrence is the
mechanism that passes these parameters from the frame of the interaction occurrence, to the referenced
interaction. The Cancel Performance interaction occurrence would pass on the performance, newDate, and
newTime values to the formal gate of the Cancel Performance interaction. The Schedule Performance interaction
occurrence would pass on the newDate and newTime values to the formal gate of the Schedule Performance
interaction.
Modeling behavior structures using combined fragments
An InteractionFragment is a generalized reference to nearly all the elements that make up a Sequence diagram.
The word "fragment" refers to elements that describe some aspect of the communication between objects,
including interactions, interaction occurrences, interaction operands and combined fragments. An
InteractionOperand describes a grouping mechanism for interaction fragments. A CombinedFragment is a
reference to a set of one or more interaction operands. Each combined fragment is governed by rules that define
how to execute its contained set of interaction operands. Combined fragments and interaction operands support
nesting of interactions. Together they provide a compact and concise means for defining complex interactions.
A CombinedFragment consists of one or more InteractionOperands.
Each CombinedFragment possesses an InteractionOperator that defines how to use the interaction operands
within the context of the combined fragment.
Figures 9-26 and 9-27 showed the use of combined fragments and the ref (reference) operator to point to
interactions defined elsewhere in the model. Cancel Performance and Schedule Performance are both combined
fragments with the interaction operator ref. In both cases the combined fragments each contain only one
interaction operand.
Figure 9-28 shows a frame for the Sequence diagram (sd) called example. The rectangle inside the frame labeled
alt is a combined fragment. The combined fragment contains two interaction operands, one above and one below
the dashed line. Each interaction operand contains an interaction occurrence, a series of messages passed
between objects. The alt operator in the top left corner of the combined fragment explains how the combined
fragment should manage the execution of the interaction operands.
Figure 9-28: Modeling a combined fragment within a Sequence diagram frame.
Using interaction operands within a combined fragment
An interaction operand represents an interaction with an optional guard expression. The interaction operand is
executed only if the guard expression tests true at runtime. The guard is placed at the very start of the interaction.
The values tested in the guard condition may refer only to values owned by the lifeline at which the first event
occurrence of the interaction is located. In other words, the object that starts the interaction requires all the
information necessary to make the decision about whether to proceed. The absence of any guard condition means
that the interaction is always executed.
A combined fragment separates the contained interaction operands with a dashed horizontal line between each
operand within the frame of the combined fragment. When the combined fragment contains only one operand the
dashed line is unnecessary. Examples of combined fragments are provided in the next section, "Interaction
operators."
Interaction operators
The InteractionOperator is modeled as text in a small compartment in the upper left corner of the
CombinedFragment frame. The set of valid interaction operators is defined in an enumeration called (oddly
enough) InteractionOperator. The following section provides descriptions for the set of valid interaction operators,
and brief explanations of their use.
Alternatives
The alt (alternatives) interaction operator identifies a set of behaviors from which the interaction can choose
based on specified criteria. Only one of the offered alternatives will execute on any one pass through the
interaction. However, as is true of any operand, the selected operand in the alt structure executes only if the guard
condition tests true. If there is no guard, the operand always executes when selected. The else clause of the alt
combined fragment executes whenever none of the other options is selected.
Figure 9-28, shown earlier, provides an example in which a combined fragment resides within the example
interaction. The alt combined fragment offers one option, and an else clause. If the guard [x>0] tests true, the
first fragment will execute. If it tests false, the interaction specified by the else fragment will execute.
An alt combined fragment may offer any number of alternatives.
Option
The opt (option) interaction operator represents a behavior that may or may not be used as part of the interaction.
To be used, the guard condition must be satisfied. If the guard condition fails, the behavior is simply skipped. The
model for an opt combined fragment looks like an alt that offers only one interaction.
Break
The break interaction operator provides a mechanism similar to the break syntax in many programming
languages. In the course of executing an interaction, if the guard of the break is satisfied, then the containing
interaction abandons its normal execution and instead performs the clause specified by the break fragment.
Parallel
The par (parallel) interaction operator supports parallel execution of a set of interaction fragments. The integrity of
each interaction fragment is preserved while allowing the exact execution of the events within each interaction
fragment to be interwoven in any way supported by the processing environment. Figure 9-29 is an example of a
combined fragment with three parallel interactions. All three may execute at the same time, and the individual
events within each interaction fragment may execute in any order within the constraints of the individual interaction
fragments without regard for other events on the same lifelines.
Figure 9-29: Parallel combined fragments.
Weak Sequence
The seq (weak sequence) interaction operator forces the interactions to follow a certain order. The order is based
on the placement of the interaction fragments within the combined fragment in the same way that events
messages are ordered by their placement on the vertical lifeline. If two events occur on the same lifeline, the event
on the uppermost interaction executes first. The complete rules for maintaining the order of execution are as
follows (UML 2.0):
The ordering of event occurrences within each of the operands is maintained in the result. 1.
Event occurrences on different lifelines from different operands may come in any order. 2.
Event occurrences on the same lifeline from different operands are ordered such that an event occurrence
of the first operand comes before that of the second operand.
3.
Contrast this description to the strict interaction operator described next.
Strict Sequence
The strict (strict sequence) interaction operator explicitly defines the order of execution for a set of interaction
fragments. The ordering is limited to the interactions on the first level of a nested interaction fragment, so no
evaluation is made of events within any nested interaction fragments. The effect of strict is to force the
completion of one interaction before proceeding to the next interaction. Contrast this with seq, which allows partial
parallel execution, but forces sequencing of the execution of events on the same lifeline from different interactions.
Negative
The neg (negative) interaction operator is used to identify interactions that should not be allowed to happen. That
is, these interactions are explicitly described as invalid. The neg operator can provide a convenient shorthand
when any number of options is valid but only one or a small number of options are not allowed-it might be easier
and less time consuming to identify the exceptions.
Critical Region
The region (critical region) interaction operator identifies an interaction that takes precedence over all other
interaction fragments within the context of the combined fragment. In Figure 9-30, all the interaction fragments may
execute in any order, unless the critical region is invoked, and then it must execute before any of the other
fragments may execute. So if the operation c() is invoked, it will run to completion before any new calls to a() or b()
are allowed to execute.
Figure 9-30: Modeling a critical region.
Ignore/consider
The ignore interaction operator explicitly identifies messages to which the interaction fragment should not
respond. The consider interaction operator explicitly identifies messages that should be handled, and is the
equivalent to labeling every other message to be ignored. The two operators enhance ease of modeling in that
they enable the modeler to focus on the most relevant behavior without specifying every exception. The syntax for
the ignore/consider operator is as follows:
(ignore | consider ) { <message name> [ ,<message name>]* }
Both operators use a comma-separated list of messages. For example:
ignore {a, b}: Although messages a and b might be directed at the objects in this interaction, they are
considered insignificant and so do not appear in the body of the interaction fragment.
consider {c, d}: Only the messages c and d are considered significant. No other messages are addressed
by the interaction fragment, even if those messages are directed at objects within the interaction fragment.
The ignore and consider operations are usually combined with other operations, as shown in Figure 9-31.
Figure 9-31: Modeling the interaction operators ignore, consider, and assert.
Assertion
The assert (assertion) interaction operator identifies an operand as the only valid continuation of events in an
interaction fragment. Alternative scenarios often are modeled using other Sequence diagrams. Using an assertion
tells those reading the model that what they see is the only valid sequence of events. There is no other place to
look.
Loop
The loop interaction operator indicates that the interaction fragment will be executed repeatedly. The number of
times it is executed is determined by the minint and maxint parameters of the operator. The syntax of the loop
operator is:
loop(minint, maxint)
where maxint may also be infinity (*).
Once the minimum number of iterations has been satisfied, a Boolean expression is tested on each pass. When
the Boolean expression tests false, the loop ends.
Using the syntax loop (integer) is a convention used for multiplicity throughout the UML to mean that the
minimum and maximum values are the same.
Using the syntax loop means the loop has no upper bound, or the same as zero to infinity. The only way out of the
loop is for the Boolean expression to test false.
<Day Day Up>
<Day Day Up>
Modeling collaborations
Collaborations provide a means to define common interactions between objects (and other classifiers). A
collaboration is specified as a set of messages passed between a set of objects playing predefined roles in the
interaction.
TipA collaboration does not refer to the UML 1.4 Collaboration diagram. They are two distinct concepts. To
help resolve the confusion over these two names, UML 2.0 has renamed the Collaboration diagram from
UML 1.4 to the Communication diagram (explained in the next section of this chapter).
Consequently, a collaboration can be defined as a class with attributes (objects playing roles) and behavior (the
set of interactions). User-defined compartments on the collaboration class may be used for interactions (Sequence
diagrams) and the structural elements (Composite Structure diagram). For example, Figure 9-32 models the
Observer design pattern as a collaboration between an object in the role of an observable item and any number of
objects as the observers.
Figure 9-32: Modeling a collaboration that utilizes a composite structure and an interaction occurrence (sd
Observe).
Figure 9-33 is the Sequence diagram (sd Observe) that explains the interaction between an observable object and
observers. The observer asks the observable object to add it to the list of observers. When an event impacts that
observable object, part of its response is to notify all of the observers currently on the list. The observer then
queries the observable item to find out what happened (or to respond in whatever other manner is defined for the
observer).
Figure 9-33: The model for the interaction referenced by the interaction occurrence called sd Observe.
The next step is to map the collaboration/pattern to a set of objects that will implement the pattern. Figure 9-34
shows how the collaboration is mapped to the implementation elements : ShowSeat and : Show. A
dependency arrow points from the collaboration to each implementation element. The dependency arrow is
labeled with the role that the element will play in the implementation. An instance of the ShowSeat class plays the
observable role. An instance of the Show class plays the role of the observer.
Figure 9-34: Applying the Observer pattern collaboration to a show and its internal structure.
Finally, Figure 9-35 models the Sequence diagram sd SelectShowSeat as containing an interaction occurrence
called O1.Observe. This illustrates how the interaction SelectShowSeat can be specified as an instance of the
observer pattern class (01) implementing its Sequence diagram (Observe).
Figure 9-35: Modeling the application of an interaction occurrence to implement the observer pattern
collaboration in the SelectShowSeat interaction.
<Day Day Up>
<Day Day Up>
Modeling a Communication Diagram
The Communication diagram is actually a slightly scaled back version of the Collaboration diagram of UML 1.4
and earlier versions. The strength of the Communication diagram is that it combines messaging with a visual layout
of the links between objects, something that is missing in the Sequence diagram.
On a Sequence diagram it is possible (although a tool could prevent this with a relatively simple check) to draw a
message from one object lifeline to another object lifeline even if those two objects have no link. The diagram is
still valid. (In fact, this might reveal that the model needs to be updated to link the two objects so that the message
will work.) The Communication diagram helps prevent the modeler from making this mistake by using an Object
diagram format as the basis for messaging. Figure 9-36 shows an Object diagram with three objects and two links
that form the basis for the Communication diagram. Each object on a Communication diagram is called an object
lifeline. (This is a bit forced to keep it in line with other interaction diagrams. Just think of it as an object.)
Figure 9-36: Start a Communication diagram by using an Object diagram format showing links between
objects.
The message types in a Communication diagram are the same as in a Sequence diagram. A Communication
diagram may model synchronous, asynchronous, return, lost, found, and object-creation messages.
The message syntax for the Communication diagram does, however, add a sequence expression in front of each
message to identify the order of message execution.
The sequence expression is a dot-separated list of sequence-terms followed by a colon (:').
sequence-term [ ' . ' sequence-term] ... ' : ' messagesignature
where
sequence-term := integer [ name ]
Each sequence term is an integer with an optional name. For example, 1.1, 3.2.4a, 3.2.4b, and 3 are all
valid sequence expressions.
Figure 9-37 models the successful scenario for the Use Case "Select a Performance." Follow the sequence
numbers of the messages to determine the order of execution. Each sequence term represents a level of
procedural nesting. If message sequence numbers are at the same dot-level-1.1 and 1.2 in Figure 9-37, for
example-the messages are considered to be sequential. There is no nesting. If the model adds steps 1.1.1 and
1.1.2, then these new steps are understood to execute after step 1.1 and before step 1.2. In other words, they are
nested beneath/within step 1.1.
Figure 9-37: Modeling a Communication diagram with sequence numbers to guide the execute order of the
messages.
Using the name portion of the term supports concurrent threads of control at the same sequence level. For
example, 1.1a and 1.1b can execute as concurrent threads.
Iteration expression
A message may be executed repeatedly. When repeated execution is required, add the optional recurrence
portion of the sequence term expression as follows:
sequence-term := integer [ name ] [ recurrence ]
where recurrence is an iteration expression in the following form:
'*' ' [ ' iteration-clause ' ] '
The asterisk (*) indicates that what follows is an iteration clause (not to be confused with a guard expression, which
is described later in this chapter). The iteration clause may be expressed in pseudo code or a programming
language. For example, in Figure 9-38, the interaction needs to retrieve all the performances for each event. The
iteration expression reads *[ For each event ].
Figure 9-38: Modeling an iteration expression.
Parallel execution
The iteration expression assumes that the messages in the iteration will be executed sequentially. But this is not
always true. To model the fact that the messages may execute concurrently (in parallel), use a pair of vertical lines
(| |) after the iteration indicator (*). For example, in Figure 9-38, message 3.1.1 retrieves the performances for each
event, one at a time. But we could change it to retrieve the performances for all events concurrently by adding the
concurrency notation to the sequence term, as shown in Figure 9-39.
Figure 9-39: Modeling parallel execution with an iteration expression.
Guard expression
A guard expression determines whether a message may execute. The guard is expressed as a Boolean constraint
on values available to test at the time of the message sendEvent. The guard syntax is
' [ ' guard ' ] '
Note the absence of the * ', which distinguishes the guard expression from the iteration expression.
In Figure 9-40, message 7 will execute only if the condition [return=yes] is satisfied. In most cases, a Sequence or
Communication diagram models a single scenario, one path through a logical sequence. The guard is used to
identify the path taken by the scenario illustrated by the diagram.
Figure 9-40: Modeling a guard expression.
<Day Day Up>
<Day Day Up>
Modeling an Interaction Overview Diagram
In practical application it is usually simplest to limit a Sequence diagram to a single scenario, a single logical path
through a Use Case. By doing so, it is easy to lose sight of the big picture, the complete process. UML 2.0 offers
the Interaction Overview diagram as a means to combine the flow of control from an Activity diagram with the
messaging specification from the Sequence diagram.
Where an Activity diagram uses activities and object flows to describe a process, the Interaction Overview diagram
uses interactions and interaction occurrences. The lifelines and messages found in Sequence diagrams appear
only within the interactions or interaction occurrences. However, the lifelines (objects) that participate in the
Interaction Overview diagram may be listed along with the diagram name.
Modeling interactions and interaction occurrences
The notation for interaction and interaction occurrences is the same for an Interaction Overview diagram as for a
Sequence diagram. Figure 9-41 shows the notation for interactions.
Figure 9-41: Interaction notation.
Figure 9-42 models the notation for interaction occurrences.
Figure 9-42: Interaction occurrence notation.
Both interactions and interaction occurrences are allowed on the Interaction Overview diagram, but for simplicity's
sake, I use only-interaction occurrences in the remaining examples.
Modeling the sequencing of interactions
Interactions may be sequenced just like activities. Use the flow of control arrows to model the flow from one
interaction to the next. Use the following rules to construct the flow of interactions:
Initial and final nodes begin and end the flow.
Decision and merge nodes guide the flow through branching logic and back together for common sequences.
Fork and join nodes support concurrent behavior.
Fork and join nodes
The rest of the examples in this section build an Interaction Overview diagram of the process for selecting a
performance at the theater. At the beginning of the process the user is presented with a list of the currently
scheduled events and another list containing the performances that are playing in the next 20 days. There is no
real sequential dependency between these two behaviors, so we can use the fork and join notation to allow for
concurrent execution of the two interaction occurrences. Figure 9-43 shows the fork and join notation, and the
positioning of the two interaction occurrences.
Figure 9-43: Fork and join notation to allow concurrency in an Interaction Overview diagram.
Decision and merge nodes
The next step in selecting a performance is to decide which of the offered options to take. The user may
Select one of the events and see only the performances for that event.
Enter a data range and see a list of performances that play during that period.
Select one of the performances already displayed.
Cancel out of the transaction.
The first decision point must allow for all of these options. Figure 9-44 adds the decision point and the sequences
of interactions that follow each choice.
Figure 9-44: The use of a combined decision and merge point.
Initial and activity final nodes
The starting point is an initial node. The end of the flow is an activity final node shown in completed diagram in
Figure 9-45.
Figure 9-45: A complete Interaction Overview diagram.
<Day Day Up>
<Day Day Up>
Modeling a Timing Diagram
A Timing diagram is a special-purpose interaction diagram that focuses on the timing of events over the life of an
object. It is a blend of state machine and interaction diagram, with time and duration constraints. The Timing
diagram uses two forms, a state timeline and a general value timeline.
Modeling a lifeline
A lifeline in a Timing diagram forms a rectangular space within the content area of a frame. It is typically aligned
horizontally to read from left to right. Multiple lifelines may be stacked within the same frame to model the
interaction between them. Figure 9-46 shows a single lifeline within a frame on the left, and two lifelines within a
frame on the right.
Figure 9-46: Modeling object lifelines in a Timing diagram.
Modeling a state timeline
A state or condition timeline represents the set of valid states and time. The states are stacked on the left margin
of the lifeline from top to bottom. In Figure 9-47, the states are approved, scheduled, over, and cancelled. The
lifeline marks time using notches along the bottom of the lifeline region. The time increment is specific to the
modeled problem.
Figure 9-47: Modeling a state timeline.
Changes from one state to another are represented by a change in the level of the line. For the period of time
when the object is a given state, the timeline runs parallel to that state. A change in state appears as a vertical
change from one level to another. The cause of the change, as is the case in a state machine, is the receipt of a
message, an event that causes a change, a condition within the system, or even just the passage of time. The
name in the message is placed at the point where the timeline changes levels to signify that the message is the
reason for the change. Figure 9-48 adds the message names at each change vertex from Figure 9-47. (The
circles have been added for emphasis only. They are not part of the UML notation.)
Figure 9-48: Adding messages to a state timeline.
Like the Sequence diagram, the Timing diagram can document time and duration constraints. Figure 9-49 adds a
time constraint on the scheduling of the performances for the event. It states that the performances must be
scheduled within the timeframe specified in the performance contract, which in this case is between the event
approval date' and the event required scheduled date'. (Again, the time constraint is encircled only to highlight the
change in the example.)
Figure 9-49: Adding a time constraint to a state timeline.
In like manner, a duration constraint may be added to restrict the length of time between events. In Figure 9-50, the
duration constraint states that time between when the event is scheduled and when the event is over equals the
time between the event start and end dates.
Figure 9-50: Adding a duration constraint to a state timeline.
Modeling multiple lifelines
Interaction implies more than one object. To model multiple objects participating in the interaction, simply stack the
lifelines, and then show the interaction as arrows passing between the lifelines to the contained timelines. For
example, in Figure 9-51, event e1 causes a change in the state of b:ClassB. The object b:ClassB responds by
sending the message start() to a:ClassA. Later, event e2 causes a change in the state of a:ClassA, which then
sends the message done() to b:ClassB, causing it to change state again.
Figure 9-51: Modeling interactions between multiple lifelines.
Modeling a general value timeline
The general value timeline offers an alternative presentation. It aligns the states horizontally and shows the
transition between each state as shown in Figure 9-52 using the states approved, scheduled, in progress, and over.
The event that causes the change is aligned next to the change point. Duration and time constraints are lined-up
alongside the general value timeline, as shown in Figure 9-52.
Figure 9-52: A general value timeline.
The general value timeline can also model the attribute values that define each state instead of using state names.
Using attribute values shows the state changes in terms of the changes in the attribute values that define each
state.
Modeling a stop
If a timeline is terminated during the interaction, use the stop icon, a large X at the point in the timeline when it
becomes no longer available.
<Day Day Up>
<Day Day Up>
Summary
UML 2.0 offers four interaction diagrams, the Sequence diagram, Communication diagram, Interaction Overview
diagram, and an optional Timing diagram. All four diagrams utilize the frame notation to enclose an interaction.
The use of frames supports the reuse of interactions as interaction occurrences. Each interaction occurrence is a
reference to an interaction that is fully defined in its own diagram.
An interaction is a series of messages passed between objects in order to accomplish a task.
A lifeline provides a means to identify the order of events that affect the condition and behavior of an object
during the execution of an interaction.
The end of an object lifeline, the object termination, is signified by a large X on the end of the lifeline.
Object activation models the period of time when an object is busy with a task and cannot respond to other
requests.
Object suspension refers to a period of time in which an object has stopped working because it is waiting for a
response from another object.
State invariant is a condition, defined by the values of the attributes of an object, at a point in time during an
interaction.
A message is the basic form of communication in a Sequence diagram interaction.
ExecutionOccurrence defines the behavior performed (executed) between the moment when the object
experiences the receiveEvent and the moment when the object experiences the sendEvent.
Event occurrence defines the point in an interaction when a message or signal is sent or is received.
Message sorts describe the varieties of messages defined by UML:
Synchcall-Invokes an operation on an object and waits for a response.
Asynchcall - Invokes an operation on an object but does not wait for a response.
SynchSignal - Is issued without any reference to a specific operation on any object.
AsynchSignal - Is issued without any reference to a specific operation on any object.
Message types describe what we know about the execution of a message as:
Complete: Both the sendEvent and receiveEvent are present.
Unknown: Both the sendEvent and receiveEvent are absent.
Lost: The sendEvent is present and the receiveEvent is absent.
Found: The sendEvent is absent and the receiveEvent is present.
A duration constraint is a restriction on the length of time it takes to complete a task.
A time constraint sets a specific time when a task must be completed.
A CombinedFragment consists of one or more InteractionOperands.
Each InteractionOperand contained within a combined fragment possesses an InteractionOperator that
defines how to use the operand within the context of the combined fragment. An interaction operand
represents an interaction and an optional guard expression.
Interaction operators govern the execution of interaction operands within a combined fragment. The UML-
defined interaction operators are as follows:
ref - Alerts the reader that the content of the frame is defined elsewhere, such as in the diagram named
in the content area.
alt - Identifies a set of behaviors from which the interaction can choose based on specified criteria.
opt - Represents a behavior that may or may not be used as part of the interaction.
break - Provides a mechanism similar to the break syntax in many programming languages.
par - Supports parallel execution of a set of interaction fragments.
seq - Forces the interactions to follow a certain order.
strict - Explicitly defines the order of execution for a set of interaction fragments.
neg - Used to identify interactions that should not be allowed to happen.
region - Identifies an interaction that takes precedence over all other interaction fragments within the
context of the combined fragment.
ignore - Explicitly identifies messages to which the interaction fragment should not respond.
consider - Explicitly identifies messages that should be handled.
assert - Identifies an operand as the only valid continuation of events in an interaction fragment.
loop - Indicates that the interaction fragment will be repeatedly executed.
A collaboration may be modeled using a combination of a Composite Structure and a Sequence diagram.
The Communication diagram replaced the Collaboration diagram from UML 1.4. Messaging on a
Communication diagram supports iteration, parallel execution, and guard expressions.
An Interaction Overview Diagram combines the flow of control from an Activity diagram with interactions and
interaction occurrences. It supports all the Activity diagram flow-of-control mechanisms, such as fork and join
nodes, decision and merge nodes, and initial and activity final nodes.
The Timing diagram models changes in state over a timeline for each object in an interaction. It effectively
combines a state machine and an interaction diagram.
<Day Day Up>
<Day Day Up>
Chapter 10: Modeling an Object's Lifecycle in UML 1.4
Overview
As objects participate in the behavior of a system they can be affected by the behavior. For example, when I use
my car to drive to work, the tires wear out and the car accumulates miles. The condition of the car is constantly
changing while it is being used. Changes in the condition of the car can affect how the car behaves. As the tires
wear down the car handles less effectively in turns and while stopping than it did when the tires were new. When
the gas tank is empty turning the ignition key fails to get the usual response. The same use of the object (turning
the key) results in a very different result because of a change in the state of the object.
The Statechart diagram defines a notation for state machines. State machines capture the changes in an object
throughout its lifecycle in response to external events. Events place demands on an object. The demands can
cause changes in the object that in turn affect how the object behaves. The Statechart diagram models the unique
conditions of an object at distinct periods in its lifecycle and the events that trigger the changes.
Where the interaction UML diagrams focus on discrete behaviors, the Statechart provides a holistic view of
everything that could possibly happen to an object throughout its lifetime. This chapter describes how to model a
Statechart diagram and how to exploit the relationship between the Sequence and Statechart diagrams to facilitate
the development of the Statechart diagram.
<Day Day Up>
<Day Day Up>
Modeling a Statechart Diagram
So far you have seen the dynamic view represented by the Sequence and Collaboration diagrams. Both of these
diagrams model the interactions between objects. The Statechart diagram models the effect that these
interactions have on the internal makeup of each object. The messages modeled in interaction diagrams are the
external events place demands on objects. The objects' internal responses to these events cause the changes to
the objects' states. Drawing on the relationship between the messages on the interaction diagram and the events
that trigger changes in an object, we can derive a Statechart diagram from the interactions on a Sequence
diagram.
The relationship between interactions and events that cause state changes can also help us identify the objects
that warrant a Statechart. Frankly, very few objects need to be modeled at this level. Many objects are simply
created, referenced, and later deleted. But in many applications there are a few fundamental objects that are the
focus of the application. For example, in theater system a price type is defined, used, and sometimes deleted. All
these changes are performed by a venue manager and are pretty straightforward. The seats at a show (show
seats), however, are created when a performance is schedule, priced by a venue manager, selected by customers
(or by agents on behalf f customers) interested in buying them, released when the customer decides not to go
through with the transaction, purchased, and possibly refunded. With each change to the seats the rules change
regarding what can be done with the seat. If a seat is held by one customer, it cannot be selected by another
customer. If a seat is not yet priced, then it can't even be selected.
The price type does not warrant a Statechart. A seat at a show does warrant a Statechart. I know this because I
know the problem. But how could you discover this by evaluating my models? When you review the Sequence
diagrams you would see the show seats in many of the Sequence diagrams. In each Sequence diagram you would
see a number of arrows (messages) directed at the show seats. Every arrow places a demand on the show seat
object. That demand could trigger a change. The objects that appear in many of the interactions and are the target
of many of the interactions are good candidates for a Statechart diagram. I call it looking for the "most wounded
objects", that is, looking for the objects with the most incoming arrows.
The Statechart diagram is based on David Harel's Statecharts and includes much of the notation and concepts
from both Moore and Mealy state machines that have been in use for quite some time. This emphasizes again that
UML is not so much a new concept as it is the gathering together of many tried and true modeling techniques from
mature development methods.
TipThe concepts modeled by a Statechart diagram have been around a long time, in other diagrams such as
the State diagram, state machine, and state transition diagram.
Each Statechart diagram describes the life of one object in terms of the events that trigger changes in the object's
state. The Statechart diagram identifies both the external events and internal events that can change the object's
state. But what does it mean to change an object's state? The state of an object is simply its current condition. That
condition is reflected in the values of the attributes that describe the object. Behaviors in the system alter those
attribute values, thus redefining, or changing, the object's state.
Earlier in the book, I suggested that you notice how parts of speech reflect model elements. A state describes an
object, so it typically appears as an adjective or gerund (present participle of a verb used as an adjective) in the
problem description; for example, a checking account is open (an open account) or a performance that is playing
(a currently playing performance).
Changes in the condition of an object can dictate changes in its behavior. For example, when the current
condition/state of a checking account is overdrawn, the checking account responds in a different manner than
when the checking account has a credit balance, that is, checks are rejected rather than paid, or the bank might
cover the check and charge you an exorbitant fee for its kindness.
Contrast the scope of the Statechart with that of the Sequence diagram. The scope of the Statechart is the entire
life of one object. The scope of the Sequence diagram is typically a single scenario or behavior, such as an
operation or workflow, and may involve any number of objects. Consequently, it is possible to derive a Statechart
from the set of Sequence diagrams that use the object in question. I discuss this in the "Deriving a Statechart from
Sequence diagrams" section later in this chapter.
The Statechart models the events that trigger a transition (change) from one state to another state. An event
corresponds to a message sent to the object asking or telling it to do something. That something is called an
action, or more accurately an action expression. Actions alter the object's attribute values, redefining the object's
state. Note that not all messages imply an action that alters the object. A message such as getName(), for
example, makes no change to the object so it would appear as an internal transition. The name is a bit misleading,
given the definition of a transition. "Internal event" might have been more accurate, but
While an object is in a state, it may also perform work associated with that state. Such work is called an activity
and does not alter the state of the object. For example, while a performance is open, it might keep track of the
seats sold.
The Statechart can also aggregate states into superstates, providing a higher-level view of the transitions in the life
of an object. The states thus aggregated then become substates of the superstate. Substates may also represent
concurrent behaviors within a state by creating parallel substates within a superstate. Using the substate and
superstate notation, you can explicitly identify split and merge (synchronization) of control for concurrency, as you'll
see later in this chapter.
State attributes
Although not explicitly defined by UML 1.4, state attributes are a common addition to a state definition. State
attributes are features that only apply to the object while the object is in the named state. These attributes are
initialized on entry to the state, and are deleted upon exit from the state.
For example, an object might set a timer to keep track of how long it has been in the state. If a specified time limit
is exceeded, the object automatically resets itself to the previous state. In another example, while a login screen is
in the state of receiving input of the user-name and password, it might keep track of the number of unsuccessful
attempts. If the number of attempts exceeds the security threshold, the screen locks and displays an appropriate
message.
Modeling object states and events
The foundation for the Statechart is the relationship between states and events. The examples in this section
illustrate the Statechart notation using a Seat object from the theater system. A simple state (or regular state) is
modeled as a rounded rectangle with the state name inside. The name may also appear in a tab attached to the
top edge of the state icon. Figure 10-1 shows both models. The icon on the left is by far the most common, so I will
use it throughout the rest of the book.
Figure 10-1: State icon with the name compartment shown (minimum configuration).
In addition to simple states, the UML defines two special states: the initial state and the final state. Each has its
own unique notation. The initial state of an object is modeled as a solid dot with an arrow pointing to the first state,
as shown in Figure 10-2. It is referred to as a pseudo state because it does not really have all the features of an
actual state but it helps clarify the unique purpose of another state on the diagram. The initial state identifies (points
to) the state in which an object is created, or constructed. For example, Figure 10-2 says that a seat is created in
the Allocated state. In other words, the seat comes into existence within the system when a Venue Manager
informs the system that it has been allocated to the floor plan.
Figure 10-2: Initial state notation.
Technically the initial state is just the dot. However, in practice, the phrase initial state refers to the entire image
shown in Figure 10-2: the dot, the arrow, and the state icon, as if to say, "Start at the dot and follow the arrow to the
initial state, called Allocated".
At the end of its life an object may reach a final state from which it may never leave. The final state is a subclass of
state. So it has all the properties of a state, with one exception: it cannot have any outgoing arrows (transitions). In
other words, once the object reaches this state it can never transition to another state. A final state is modeled as a
bull's-eye, a dot within a circle. The name of the final state is placed next to the final state icon. A common usage is
illustrated in Figure 10-3. Let's say we're modeling the state of a seat. According to the Statechart diagram notation
in this figure, the seat may be removed while it is in either the enabled state or the disabled state. This is illustrated
by the arrows from each of the two states, and directed toward the final state. (These arrows will be explained in
the next section.) But once the seat is in the Removed state, you may never change it (according to this diagram).
Figure 10-3: Final state notation.
In this example, the object still exists but it is frozen in a query-only state. You can access it, report on it, and
interrogate any of its attributes. You just can't change its state. In this sense, it is like archiving something. But the
final state may also mean that the object has actually been deleted and can no longer be accessed. However,
information in a system is a valuable asset, so it is rare that a system literally deletes data. It is equally rare to see
the final state on a Statechart diagram. Often, even if an object is flagged as deleted or archived, the system will
likely provide the option to undo the deletion or archive to recover from an error or simply to change your mind. In
this situation, the deleted or archived state would be a simple state, modeled as a rounded rectangle.
Modeling events
An event is a trigger that evokes a response in the form of one or more behaviors. An event on a Statechart
diagram corresponds to a message on a Sequence diagram. For example, in Figure 8-9, step 6, the
SelectShowSeat object sends a select () message to the ShowSeat object. Receiving the select ()
message is an event that triggers a state change in the ShowSeat from the Unsold state to the Sold state.
An event may be
The receipt of a signal, such as receiving an exception or a notice to cancel an action
The receipt of a call, that is, the invocation of an operation, such as pricing a seat or rescheduling a
performance
An event may also be the recognition of some condition in the environment or within the object itself such as
A predefined condition becoming true, called a change event. For example, when an agent's sales drop below
50% of his quota for two shows in a row (the change event), action is required by the venue manager who
oversees the agents.
The passage of a designated period of time, called an elapsed-time event. For example, after a ticket has
been held at will-call for three days (the elapsed time event), it is returned to inventory for sale.
Modeling events and transitions
The Statechart diagram event notation is a label on an arrow connecting one state to another state, using a solid
line with a stick arrowhead. The arrow is actually the transition associated with the event.
TipThe terms event and transition are often used interchangeably in the context of a Statechart diagram
because they always appear together.
The direction of the arrow shows the direction of the change. The base of the arrow identifies the state that the
object is in when the event is received (either from another object or from the object itself), and the arrowhead
identifies the state that the object changes to because of the event. Figure 10-4 shows that the event enable ()
causes the transition (the arrow) from the state Allocated to the state Enabled.
Figure 10-4: The State transition from Allocated to Enabled, caused by the event enable().
The event expression for signals and calls uses the format
event - name '(' [comma - separated - parameter - list] ')'
['['guard-condition']'] / [action-expression]
Event - name identifies the event.
The parameter - list defines the data values that are passed with the event for use by the receiving
object in its response to the event.
The guard - condition determines whether the receiving event should respond to the event.
The action - expression defines how the receiving object must respond to the event.
So far I have only used the event name with no parameters, but I cover all the other expression elements in this
chapter.
Most if not all the events on a Statechart diagram come from other objects. But the Statechart diagram does not
tell you what object they came from. Why? Because the Statechart diagram is concerned only with the effect that
the event has. The interaction diagrams model the sources and destinations of messages. It's like receiving a
phone call-you don't have to know who is calling in order to pick up the receiver and answer. Within a Statechart
diagram, an object doesn't need to know who sent the event. An object is only responsible for how it responds to
the event. So it is important to remember that the base of the arrow identifies the state that the object is in when it
receives the event and says nothing about where the event came from.
Keeping this rule in mind (that state objects in a Statechart diagram don't need to know where the events they
respond to come from), helps reduce coupling in your design. When a message is tied to the sender, then each
sender/message combination is a different event. For example, in the theater system there are at least three
different types of people who will at some time select a show seat for some reason (to price it, to purchase it, or to
refund it, for example). I can model these events as customerSelect(), agentSelect(), and
venueMgrSelect(). But if I later define new types of people such as Marketing and Schedulers who also need
to select a show seat, then I must add new events for each of the new types of people. If I instead focus on the
condition of the object and its response to the event, then who sent the message becomes irrelevant and the
model is simplified. There is only a select () event received under many different circumstances, but always for
the same reason, to hold the seat so that I can perform an action on it without someone else interfering with it.
Furthermore, the state of an object when it receives an event can affect the object's response. An event received in
one state may get one response, while the same event received under different conditions could get an entirely
different response. For example, if you press the accelerator on your car while the car is turned on, the engine
speeds up. If you press the accelerator when the car is turned off, the engine does nothing.
Figure 10-5 shows a toggle switch example. The same click() event causes different behaviors, depending on the
state of the switch. The first click occurs when the switch is in the Off state, so it changes the switch from Off to On.
The second click occurs when the switch is in the On state, so it changes the switch from On to Off. The same
event causes two different behaviors because the event is coupled with the state of the object at the time the event
is received. This relationship between events, state, and behavior can be described by the following formula:
Event + state = response.
Figure 10-5: The same event causes different responses based on the state of the object when it receives the
event.
Modeling elapsed-time events
Often a change is triggered because of the passage of time. For example, when a ticket has been held at the ticket
office will-call for three days, it is considered abandoned and is returned to the available pool of tickets. Elapsed-
time events use the keyword after followed by an expression, enclosed in parentheses, that evaluates to an
amount of time. Figure 10-6 models a portion of the Statechart diagram for a ticket object. The ticket starts in the
Sold state and transitions to the Unsold state after three days have elapsed.
Figure 10-6: An elapsed-time event.
Modeling change events
A transition can be based on a change in the object or a change in its environment. For example, when an agent's
sales drop below 50% of his quota for two shows in a row, we want to notify the venue manager in charge of
managing agent performance. The change event's event-name is the keyword when and takes a Boolean
expression as a parameter. The expression must be structured such that when it tests true, the change event
triggers the transition. Figure 10-7 models how the agent object transitions from active to under review if the
agent's quota drops below the established minimum.
Figure 10-7: Modeling a change event.
The change event's Boolean parameter may be as complex as the problem requires. However, complex
conditions are often a sign that the states are defined at too high a level and should be broken out into smaller,
more specific states. One way to decide is to examine the values you are testing. If the values describe the object's
condition, then combine these attributes with the other attributes that describe the state of the object to define new
states. For example, Figure 10-8 models part of a Statechart diagram for the Customer object. It tells us that a
customer transitions from the Active state to the Delinquent state. Regular customers change when they are 30
days late. Preferred customers change when they are 60 days late.
Figure 10-8: Deriving new states from the event parameters.
But the parameter values "regular" and "preferred" actually describe the customer. If I include the feature
customer type with the values regular and preferred in the state definition, I get a much simpler Statechart
diagram, as modeled in Figure 10-9. The redefined state definitions improve the cohesion of the design, while the
simplified parameters also reduce the coupling in the design.
Figure 10-9: Revised Statechart diagram that improves cohesion and coupling.
NoteThe example revising Figure 10-8 to the form seen in Figure 10-9 reinforces the benefit of modeling.
Modeling reveals design issues in a way that text cannot. It provides a unique, easy-to-use opportunity to
review and improve a design.
Modeling a guard condition
Typically an event is received and responded to unconditionally. Sometimes, however, receipt of the event is
conditional. For example, when an order is entered into the theater system, it is considered tentative until the
payment has been received. When the payment is received, the order transitions to the Placed state. The problem
is that not just any payment will do. I have to test to make certain that the payment actually covers the cost of the
order. This test is called a guard condition.
As shown in Figure 10-10, the guard condition is placed within square braces after the event name and before the
slash and actions in the event expression (represented here as a reference).
Figure 10-10: Modeling a guard condition.
event-name '(' [comma-separated-parameter-list] ')'
['['guard-condition']' ] / [action-expression]
receivePmt() [amount=totalPrice]
Modeling event actions
In each of the preceding examples, I identified why the transition is made but not how. An event is only a trigger.
The receiving object must know how to respond to the trigger. At the very least, the response has to explain how to
change the attribute values that redefine the object's state. The behavior associated with an event is defined in an
action expression. An action expression is the set of one or more actions triggered by an event.
If you think of the event as the operation signature, then the action expression corresponds to the implementation
of that operation, the method. And just as there may be many lines of code in an operation implementation, there
may be any number of actions in an action expression.
Even though an action expression may consist of a set of actions, it is still considered an atomic task (in other
words, it cannot be broken into component tasks, nor can it be interrupted). There is a good reason for this. An
action expression is part of a transition event; it is a part of the change from one state to another. If the transition is
stopped for any reason, then the object is potentially left in an undefined state, meaning that some of the attributes
used to define the new state may have been altered while others were not. This atomic model of execution is
referred to as run-to-completion semantics.
To model the action expression, place a forward slash after the event name followed by the name of the action or
actions you want performed, as in Figure 10-11 where allocating a seat requires notifying the marketing team that
the new seat is available. The allocate () event uses the event syntax:
Figure 10-11: Modeling an event/action pair.
event-name '(' [comma-separated-parameter-list] ')'
[' ['guard-condition']' ] / [action-expression]
When there is more than one action, simply separate them with commas. For example, the allocate() event
could require the object to send a notification and enable the seat. The updated event expression would read as:
allocate()/ notify(), enable()
Technically, the format for the action is
result:=action - name (parameter - list)
However, I have encountered few tools that use this format, so all my examples simply use the format:
action-name (parameter-list)
Introducing the internal transitions compartment
Let's revisit the state icon for a moment. So far you know that the state icon accommodates the name
compartment. Like the class icon, the state icon can also be expanded. The purpose of the expanded form is to
reveal what the object can do while it is in a given state. The notation simply splits the state icon into two
compartments: the name compartment and the internal transitions compartment, as illustrated in Figure 10-12.
Figure 10-12: The expanded state icon.
The internal transitions compartment contains information about actions, activities, and internal transitions specific
to that state. You've seen actions associated with events. Here I'm talking about the same actions, only
documented as entry and exit actions within a state. I'll explain entry and exit actions first, then activities, and finally
internal transitions.
Defining entry and exit actions
Modeling state transitions often results in more than one event that changes the object to the same state. Each of
these events may have a corresponding action (action expression), or even the same action. For example, in
Figure 10-13 the Statechart diagram for the Order object says that you can transition the order from the Tentative
state to the Placed state by either receiving the payment for the order or getting an override authorization. But both
events require the same action: issue an order confirmation, or issueConf().
Figure 10-13: Redundant actions entering and exiting the Placed state of the Order.
Earlier, you discovered that the state icon can be expanded to reveal the internal transitions compartment. In that
compartment you can model something called entry actions. Entry actions provide a means to eliminate the
redundancy in Figure 10-13. Whenever you discover an action that must take place with every event that
transitions into the state, you can write the action once as an entry action. Figure 10-14 shows the entry action
notation, using the keyword entry followed by a slash and the action or actions that need to be performed every
time you enter the Placed state. When the redundant action is replaced by the entry action, you can remove it from
the individual transition arrows. This simplifies the diagram while preserving the same meaning. Figure 10-14
reads, "Every time you enter the Placed state, issue an order confirmation."
Figure 10-14: Consolidating the entry actions.
The same simplification may be used for actions associated with events that trigger a transition out of a state.
These are called exit actions and are modeled in the same manner as entry actions. Figure 10-13 and 10-14 show
two events leaving the Placed state. Both events have the same associated action, issueCustomerStmt().
Figure 10-15 shows the exit/ action notation added to the internal transitions compartment of the Placed state and
the actions removed from the outgoing event arrows. Compare Figure 10-13 with Figure 10-15 to appreciate the
simplification from the original diagram.
Figure 10-15: Consolidating the exit actions.
Entry and exit action notations provide a nice simplification for the Statechart diagram. Just remember that they
may only be used when the action takes place every time you enter (for entry actions) or every time you exit (for
exit actions) the state. If there is even one exception, the notation may not be used for that action.
Modeling activities
Activities are processes performed within a state. Unlike action expressions, an activity tends not to be atomic, that
is, an activity may be a group of separate tasks. Activities may be interrupted because they do not affect the state
of the object. Contrast this with the earlier definition of an action expression, which said that you must not interrupt
action expressions because they alter the state of the object. Stopping an action midway could leave the object in
an undefined state. Activities just do work. They do not change the state of the object.
For example, Figure 10-16 models the Active state of the Customer object. While in that state, the Customer
object generates a monthly invoice for the customer's purchasing activity and generates monthly promotions
tailored to the customer. To model activities within a state use the keyword Do followed by a colon and one or
more activities.
Figure 10-16: The expanded state icon with activities.
These activities will be performed from the time the object enters the state until the object leaves the state or the
activity/ies finish. If an event occurs that triggers a transition out of the active state, the object must shut down the
activities (preferably gracefully) and exit the state.
Modeling internal transitions
While an object is in a given state it may receive events that do not trigger a change in state, yet do trigger a
response. An event that can be handled completely without a change in state is called an internal transition. Like
other transitions, it can specify related guard conditions and actions. The format for an internal transition is the
same as for an event:
event-name '(' [comma-separated-parameter-list] ')'
['['guard-condition']'] / [action-expression]
For example, while a customer (represented by a Customer object) is in the Active state, she might receive a
signal event notifying her that her tickets have been set aside for her at will-call. Receiving the notification does not
alter her state. But it is important to capture the ability of a Customer object to receive the notification and respond
by generating a mailing to the real customer. Figure 10-17 models the internal transition ticketsReady().
Since the internal transition (event) does not cause a change in state, it is modeled inside the internal transitions
compartment of the state instead of on a transition arrow entering or existing the state.
Figure 10-17: Internal transition.
A state can potentially include entry actions, exit actions, activities, and internal transitions. When this happens, all
the elements are listed within the internal transitions compartment as follows:
Entry/action, action...
Do/activity, activity...
Exit/action, action...
Internal transition/action, action...
Internal transition/action, action...
There may be any number of internal transitions in a state. Each may have associated action expressions. Simply
list them within the internal transitions compartment.
Order of events
With all these events, you could end up with a tangled mess of event actions, entry actions, exit actions, and
activities. So how do you process all this behavior in a sane fashion? Well, there is an order to these things. When
an event occurs that is associated with a transition, the order of execution runs like this:
If an activity is in progress in the current state, interrupt it (gracefully if possible). 1.
Execute the exit/action(s). 2.
Execute the actions associated with the event that triggered the transition. 3.
Execute the entry/action(s) of the new state. 4.
Begin executing the activity or activities of the new state. 5.
More about transitions
To wrap up this description of transition types, I need to explain a few more options including self-transitions, send
events, and factored state transitions.
Modeling a self transition
There are times when an object receives an event that does not change the state of the object, but causes an
interruption of the state. A self-transition is an event that is sufficiently significant to interrupt what the object is
doing. It forces the object to actually exit the current state, and return to the same state.
The result of the self-transition is to stop any activity within the object, exit the current state, and re-enter the state,
effectively restarting the state. Figure 10-18 models an order in the Tentative state. In the process of adding items
to an order, for example, a customer may choose to simply start over by issuing the reset command. The effect is
to erase any items added to the order (basically wiping out anything done to the order) while it was in the Tentative
state.
Figure 10-18: Modeling a self-transition.
1.
Referring to the earlier section titled "Order of events", you can trace the impact of a self-transition.
If an activity is in progress in the current state, interrupt it (gracefully if possible). 1.
Execute the exit/action(s). 2.
Execute the actions associated with the event that triggered the transition. In this case, we have to perform
the removeItems() operation on the order.
3.
Execute the entry/action(s) of the new state. 4.
Begin executing the activity or activities of the new state. 5.
Defining send events
Sometimes the object modeled by the Statechart diagram needs to communicate with another object. On a
Statechart diagram, the source of the incoming events is not shown because the same event may come from any
number of other objects and the response must be the same. But an outgoing event must define the receiving
object. It works in the same way you use your phone. You can receive calls without knowing who is calling. But you
cannot place a call without the number of the person you want to call. When the object in the Statechart diagram
sends a message to another object it is called a send event.
Recall the example in Figure 10-15: when the order is cancelled, the order is to issue a customer statement before
leaving the Placed state. But the customer statement is another object that takes care of issuing itself. The order
needs to tell the customer statement that it's time to do so. All the actions modeled so far were actions on the
same object. To show that the action is invoked on a different object, simply provide the object name before the
action expression, with a period separating the two. This is often referred to as the dot notation, because of the dot
(period) separating the entries in the expression. In Figure 10-19, the exit action notation now shows the issue()
action is being sent to the CustomerStmt object, using the expression CustomerStmt.issue().
Figure 10-19: Modeling an action invoked on another object.
Compound transitions and factored paths
One goal of modeling in general and of UML in particular is to make modeling alternatives visible. Working with
text and/or code to design an application almost forces a linear approach to the way we see and understand a
problem. But many problems require a broader perspective that examines a number of design elements together.
For example, follow along as I document the transitions I discover and then model them using a Statechart
diagram.
First I find the following transitions:
The transition from State0 to State2 is triggered by event e2, guarded by the condition [b<0 and a<5].
The transition from State0 to State3 is triggered by event e2, guarded by the condition [b<0 and a=5].
The transition from State0 to State4 is triggered by event e2, guarded by the condition [b<0 and a>5].
The transition from State1 to State2 is triggered by event el, guarded by the condition [b<0 and a<5].
The transition from State1 to State3 is triggered by event el, guarded by the condition [b<0 and a=5].
The transition from State0 to State4 is triggered by event el, guarded by the condition [b<0 and a>5].
Figure 10-20 models the transitions listed above exactly as I documented them in a Statechart diagram.
Figure 10-20: The original problem definition found by following one requirement after another in linear
fashion.
Doubtless you already see a lot of redundancy. The el and e2 events each appear three times. Also, since the
guard conditions are combined into unique pairs, the individual conditions have to be repeated to account for every
possible combination. Now that the diagram has made it easier to see these redundancies, you can begin to factor
out the duplication and simplify the design.
Let's start with State0. All three transitions from State0 are triggered by the same event and share one of the guard
conditions ([b<0]) in common. The differences are in the second halves of the guard conditions.
UML provides another pseudo state (like the initial state) called the static branch point that allows a transition arrow
to split into two or more paths. Figure 10-21 models this notation as a small solid circle. One transition is drawn
from State0 to the static branch point, using the common transition elements, e2[b<0]. Then at the static branch
point the Statechart diagram shows three separate transition arrows, one to each destination state. Each arrow
contains one of the unique elements of the transition, [a<5], [a=5], and [a>5].
Figure 10-21: Modeling a static branch point to re-factor compound conditions.
Examination of the transitions out of State1 reveals that the second guard condition on each transition is identical to
the second guard condition on the e1 transitions from State0. Factoring out the redundant second half leaves the
unique first half of the transition, e1[b<0]. In Figure 10-22, this new transition is drawn from State1 to the static
branch point. Since the second half guard conditions are already modeled they can be reused to satisfy the
requirements for event e1.
Figure 10-22: Combining the transitions into a single model.
NoteThe UML 1.4 also allows the use of a diamond as the static branch point. The diamond has typically
been used in modeling notations to represent a decision point. UML 2.0 uses only the diamond.
In yet other transitions, the destination of the transition isn't known until the associated action has been completed.
In these cases you literally need to provide a temporary stopping point to evaluate the outcome of the action before
moving on to the final destination. This stopping point is called a dynamic choice point.
For example, once every quarter the theater system automatically upgrades the status of customers based on how
much they spend at the theater. Figure 10-23 models a set of upgrade transitions. The event is
upgradeStatus(). The guard condition evaluates the amount of the customer's purchases. The amount is
calculated by the action, totalPurchases (start, end). The guard condition cannot be evaluated until
after the action is completed. So the action is the same on all three transitions.
Figure 10-23: Modeling transition contingent on the result of the event action.
If we again factor out the common elements, we get a simplified diagram as modeled in Figure 10-24. It shows a
single transition segment from the ActiveDefault state based on the event upgradeStatus() followed by the
action totalPurchases(start, end). The transition hits the small hollow circle called a dynamic choice
point, where the split takes place. Literally, this is the stopping point where the result of the action on the preceding
transition segment is evaluated and a path is chosen. The choice depends on the result of the action.
Figure 10-24: Modeling a dynamic choice point.
In summary, the static branch point provides a means to simplify compound guard conditions by combining the like
portions into a single transition segment, then branching based on the portions of the guard that are unique. The
dynamic choice point provides a means to isolate a behavior from the effect of the behavior. The behavior forms
the first segment of the transition, before the dynamic choice point. The alternatives, based on the result of the
behavior, form the outgoing segments after the dynamic choice point.
<Day Day Up>
<Day Day Up>
Relating the Sequence and Statechart diagrams
Those who use UML diagrams often miss the benefit of comparing and contrasting the different diagrams. Each
diagram provides a unique view of the same problem. Comparing and contrasting these views can function much
like reconciling your checkbook. That is, comparing multiple views of the same information makes it much easier
to find and correct errors.
Earlier in this chapter, I made the point that events on the Statechart diagram correspond to messages on the
Sequence diagram. The Sequence diagram views a behavior from the perspective of time. States describe the
condition of an object during a period of time. There is enough overlap of the two diagrams to provide the means to
do some comparison, or even derivation.
Deriving a Statechart diagram from Sequence diagrams
The dynamic model provides two diagrams that model changes over time: the Statechart diagram and the
Sequence diagram. The key to understanding the relationship between these diagrams is in understanding states
and events. Events trigger transitions between states. States capture the condition of an object during the period of
time between events.
Using this understanding, look at the Sequence diagram shown in Figure 10-25.
Figure 10-25: A basic Sequence diagram with events and transitions.
Each vertical column represents a portion of the total lifeline for one object.
Each event directed at a lifeline represents an event that might trigger a change in that object.
The space between events on the object lifeline represents a period of time when the object remains in the
same state. Because not every event causes a state transition, these periods are referred to as candidate
states until it's proven that a change, in fact, occurs.
The events pointing outward from the object lifeline represent either return values sent to other objects or send
events.
The challenging part of mapping the Sequence diagram to the Statechart diagram is determining the condition of
the object between the events and naming it as accurately as possible. The state of the object is defined by the
values of one or more of its attributes. Use these values to find adjectives that describe the object's condition. For
example, if one of the attributes indicates whether the object has been sold or not, then you might use sold and
unsold as part or all of the state name.
The same state may appear in many Sequence diagrams, so accurate naming can prevent confusion when you
merge the states from the Sequence diagrams. Adjectives and gerunds make very good state names, but you
might need more than one descriptor to fully describe the current condition of the object.
Figure 10-26 shows how to map the events and corresponding gaps on the lifeline of the Sequence diagram to
candidate states and events on the Statechart diagram.
Figure 10-26: Mapping a Sequence diagram to a Statechart diagram.
Understanding these concepts is a lot easier when you can see an example, so I'm going to derive a Statechart
diagram for the ShowSeat object. I'll work through the same series of steps for each scenario:
Identify the events directed at the lifeline of the ShowSeat object. 1.
Identify candidate states by isolating the segments of the lifeline between the incoming events. 2.
Name the candidate states using adjectives that describe the condition of the object during the period of
time represented by the segment.
3.
Add the new states and events to the ShowSeat Statechart diagram. 4.
I've substantially simplified the Sequence diagrams for the purpose of the example, but the mechanics of the
derivation process are appropriate for a larger example, too.
I'll use two scenarios each from four use cases to create the final, consolidated Statechart diagram for the
ShowSeat object. The first pair is represented in Figure 10-27. Each pair of use cases follows the same pattern.
The first scenario represents a user selecting a showseat in order to perform some action. The select event has
the effect of putting a hold on the showseat so that no one else can access it while the user completes the action.
(If you are familiar with databases, you could think of it as a record lock.) Once the showseat is held, the user can
proceed with the action supported by the use case. The second scenario starts the same as the first (the user
selects the showseat), but then the user changes her mind and cancels the hold. The effect of this action is to
release the hold on the showseat.
Figure 10-27: A standardized pair of scenarios for the first use case, Purchase ShowSeat.
To find the candidate states, identify the segments of the object lifeline between the start, end, and incoming
events. Figure 10-28 marks the candidates and maps them onto a draft Statechart diagram. The challenging part
is to find appropriate names for the states. First ask, what condition would a show seat need to be in to allow it to
be purchased? It would need to be priced, not held by anyone else, and not already purchased. When the
scenario begins the show seat is priced, not held, and not sold. After the select event it is still priced and not sold,
but now it is held. After the purchase event, the show seat is still priced, but it is now sold, and, since, the action is
completed, the hold is released.
Figure 10-28: Finding the transition events and candidate states for scenario 1 of the Purchase ShowSeat use
case.
In this example, I name the states using three specific word/word phrases that reflect the three attributes of the
object that together define its condition. You could also choose to use a single word to describe each state as long
as you document somewhere the fact that the name reflects the unique combination of these attributes. These
three attributes ultimately need to become part of the ShowSeat class specification.
The second scenario, shown in Figure 10-29, models the cancel action. Note that the first event is the same as in
scenario 1, indicating that there is significant overlap between the two scenarios. This is confirmed when we
examine the condition of the object at each state. Compare the state names from Figure 10-29 with those in the
previous scenario in Figure 10-28.
Figure 10-29: Scenario 2 from the Purchase ShowSeat use case.
Remember that the scope of a Sequence diagram is one scenario, and that the scope of a Statechart diagram is
the entire life of one object (limited, of course, by the scope of the current project or modeling effort). So the next
step is to merge the redundant states and reconcile the events to create a single, consolidated Statechart diagram
for both scenarios as modeled in Figure 10-30.
Figure 10-30: Consolidated Statechart diagram for the first two scenarios.
To gather all the possible events that could affect the showseat object, I must also evaluate the other three use
cases that reference the showseat namely, Price a ShowSeat, remove the Price from a ShowSeat, and Refund a
ShowSeat. Continuing the derivation process for the remaining six scenarios (two per use case) results in a
consolidated Statechart diagram for all four use cases.
Examination of the attributes that together define the states of the object reveals the initial state. You have to ask
what the initial value of each attribute should be. The combination of these initial values identifies the condition of
the object at the time it is constructed. In Figure 10-31, the initial state is Not Priced, Not Held, Not Sold. Basically I
haven't done anything to the show seat yet.
Figure 10-31: The final, consolidated Statechart diagram for the ShowSeat object.
This is just one simple technique for taking advantage of the Sequence diagram to help you build a Statechart
diagram. You will very likely encounter others. In fact, there are more formal methods for mapping the two
diagrams in a manner that is supported by software. Some modeling tools enable you to work on a Statechart
diagram and then automatically generate or update your Sequence diagrams. Likewise, you can create Sequence
diagrams and generate a Statechart diagram. There are also tools such as Together Control Center by
TogetherSoft that generate Statecharts and Sequence diagrams from code.
The Statechart and Sequence diagrams can help you a great deal when you're trying to design the behavior of
your objects, especially those few objects that are at the heart of your application. For business applications, this
typically means about five percent of the objects at the heart of your business, like products and transactions.
Within the application itself, the objects that manage the behavior of the application, that is, control-type objects,
often warrant a Statechart diagram since they are exclusively devoted to managing the state of the system.
Complex, event-driven interfaces can also benefit from a Statechart diagram. Often the complex processing in
these interfaces is handled with elaborate conditional statements that evaluate the values of the various screen
elements. These values define the state of the interface. Modeling the interface behavior in the context of unique
states can achieve simplification similar to that illustrated in Figures 10-8 and 10-9.
Evaluating the significance of each event on the state of the object
One footnote needs to be added to the description of translating a Sequence diagram to a Statechart diagram. A
transition event is an occurrence that alters the state of an object. Not all messages alter the state of an object. For
example, common getAn AttributeValue() message simply returns a value. It does not change the state of the
object. At most, such a message might appear as an internal transition. More often than not, you would not model
them at all on a Statechart.
If you identify two candidate states, as in the model on the left of Figure 10-32, then later realize that the triggering
event does not cause a transition, simply combine the two candidate states into one candidate state, as in the
model on the right of Figure 10-32.
Figure 10-32: Eliminating insignificant events.
<Day Day Up>
<Day Day Up>
Modeling Composite States
Modeling often requires different views of a problem. High-level views simplify the model. Low-level views focus on
details of a problem. The UML Statechart diagram supports the concept of nested states, allowing both high- and
low-level views of object behavior and states. The higher-level view defines the concepts of composite state,
superstate, and substate.
A Composite state is simply a state that contains one or more Statechart diagrams. Composite states may contain
either a set of mutually exclusive states or a set of concurrent states. The first, a state containing mutually
exclusive states, is literally like embedding a Statechart diagram inside of a state. The second, a state containing
concurrent states, divides a state into two or more regions. A region is simply a space within the state. Each region
contains a Statechart diagram. The concurrent aspect comes from the fact that each region executes
independently and at the same time as the other regions. Any given state may only be decomposed into one of
these two varieties.
A composite state is also called a superstate, a generalized state that contains a set of specialized states called
substates. A superstate may be modeled as a state icon with one additional feature, a composite icon that consists
of two small horizontally aligned rounded-rectangles connected by a line as pictured in the superstate icon on the
left side of Figure 10-33. The icon indicates that the state can be expanded to reveal more details. The expanded
form is shown in the right side of Figure 10-33. Eliding and expanding the state icon is used in the same way as
hiding and showing the compartments on a class. The purpose of the diagram is to provide a context for discussion
and review. Use the form that is appropriate for the level of discussion.
Figure 10-33: An elided superstate icon (left) and the expanded superstate icon (right).
Substates are states within a superstate, the states that make up the Statechart diagram contained within the
superstate. For example, Figure 10-33 models the fact that a car can be in the superstate MovingForward. Within
the MovingForward superstate are substates of moving forward in first gear, moving forward in second gear, and
so on. The substates explain in finer detail what it means to be moving forward. This detailed view enables you to
highlight concurrent substates or decide how to control the splitting and merging of the transitions between
mutually exclusive substates. These two uses of substates (concurrent and mutually exclusive substates) are
explained in the next two sections.
Modeling mutually exclusive substates
A composite state (superstate) may be decomposed into two or more lower-level states (substates). All the rules
and notation are the same for the contained substates as for any Statechart diagram. The substates reside within a
graphic compartment below the name and the internal transitions compartments, as illustrated in Figure 10-34.
Figure 10-34: Mutually exclusive substates displayed in a graphic compartment within a superstate.
States may be decomposed into substates as many levels as the problem requires. For example, moving forward
could be a substate of "driving", along with other substates such as "moving in reverse", "in neutral", and "in park".
Too many levels can become difficult to understand, so be careful not to overdo it.
Modeling concurrent substates
Modeling concurrent substates implies that you have many things occurring at the same time. To isolate these
different sets of activity, the composite state is divided into regions, and each region contains a distinct Statechart
diagram. In the simplest application the different regions support activities that simply do not have any sequential
dependency. For example, finalizing a ticket sale implies printing the ticket and marking the show seat as reserved.
It really doesn't matter which task is performed first so they can be done at the same time. Figure 10-35 models
the FinalizingSale state of an order object with two concurrent substates, each in its own region. The regions are
divided using a dashed line within the graphic compartment.
Figure 10-35: Composite state with concurrent regions.
I'll explain the use of the initial and final states, as well as other transitions for composite states, in the "Transitions
to and from composite states" section later in this chapter.
Submachine States
A submachine state is a kind of shorthand for referring to an existing Statechart diagram. In fact, the Submachine
State metaclass is a subclass of the Composite State metaclass.
Earlier you saw the simple icon for the composite state that indicates there is more to the state than is being shown
at the time. The submachine is more explicit. Within a composite state, the submachine state may be referenced in
the same manner that a class would call a subroutine or a function on another class. In fact, a composite state
may reference the same submachine any number of times.
For purposes of identification, the composite state that calls the submachine is called the containing state
machine. The submachine is called the referenced state machine. Access to submachine states is through entry
and exit points that are specified by stub states.
The containing state icon models the reference to the submachine state by adding the keyword include followed by
a slash and the name of the submachine state, as shown in Figure 10-36. The stub states use a line with the state
name placed near the line. The stub states sub1 and sub1: :sub12 represent the entry points into the
submachine state. The stub states subEnd represents an exit point from the submachine state. The use of entry
and exit points is explained in the next section.
Figure 10-36: State containing a submachine state with stub states designating the available entry and exit
points.
OMG 1.4
Transitions and composite states
As in any Statechart diagram, the two fundamental elements in composite Statechart diagrams are states and
events. The movement between states is defined by the transitions. Movement into and out of composite states
presents an added layer of complexity, because now the transition isn't simply between states at the same level. A
single transition might move from a superstate to a substate, to a substate of the substate .
The following sections lay out the rules for using transitions in and out of composite and concurrent states.
Transitions to and from composite substates
A composite state is simply a state that contains a Statechart diagram. A Statechart diagram has an initial state
and possibly a final state. There are two ways into a composite state. The first method is to transition to the
composite state itself. This is modeled by drawing the transition pointing to the edge of the composite state icon.
This notation is interpreted to mean that the composite state starts in the default initial state. The default initial state
is the substate associated with the initial state icon in the contained Statechart diagram. That is to say, if no other
entry point is specified by the transition, then the initial state is the assumed entry point for the transition into the
superstate.
In Figure 10-37 models part of the Statechart diagram for the ShowSeat object. The shorthand composite state is
on the left, and the expanded composite state is on the right. On the left, the initial state points to the edge of the
composite state Active. This means that the initial state of the ShowSeat object is the default initial state within the
Active superstate, that is, "Not Priced, Not Held, Not Sold".
Figure 10-37: Transition to the default initial state.
Note that the initial state icon on the left specifies the start of the Statechart diagram that contains the Active
superstate. The initial state on the right is the starting point for the Statechart diagram contained within the
superstate.
It is also valid to show that transition is directed to a specific substate. In this case, the transition points through the
edge of the superstate to the edge of the specific substate. In Figure 10-38 the transition arrow (starting from the
initial state icon outside the superstate) points from outside the superstate "Active" to the substate "Not Priced, Not
Held, Not Sold". The effect of this example is the same as in Figure 10-37 because both transitions are directed to
the same substate. But using this second technique, where the transition arrow crosses the superstate edge and
points directly to a substate enables the modeler to direct the transition to any substate.
Figure 10-38: Initial state refers to a specific substate.
As with entering a superstate, exiting the superstate can be accomplished in multiple ways. An object may leave
the superstate regardless of the current substate, leave from a specific substate, or exit at the completion of all
activities within the superstate.
To show that an event would cause the object to leave the superstate, regardless of the current substate, draw the
transition from the edge of the superstate to the new state. For example, all the show seats are archived at the end
of a show regardless of whether they were priced, or sold. Figure 10-39 models two ways (the elided and
expanded views) to represent how the archive event causes the show seat to transition from active to archived, no
matter which of the six substates the show seat might be in at the time it is archived.
Figure 10-39: Leaving a superstate.
It is also possible to exit the superstate directly from a specific substate. Modeling this situation implies that the exit
event may only happen while the object is in the designated substate. For example, we could specify the rule that
while a show seat has not yet been priced, it may be deactivated, or made ineligible for sale, but once it is priced, it
cannot be deactivated. Figure 10-40 models the way to indicate that a transition is only valid from a specific state.
The transition is drawn from the edge of the substate, through the edge of the superstate, and pointing to the
InActive state.
Figure 10-40: Exiting a superstate from a specific substate.
Note that if the transition applies to more than one, but not all substates, then the transition has to be drawn
multiple times, once for each applicable substate. If the transition applies to all substates, use the notation in
Figure 10-39. But if there is even one exception, one substate to which the transition does not apply, you must draw
the transition from each substate as in Figure 10-40.
Finally, an object may leave a superstate simply because all of the activity of the state and its substates has been
completed. For example, you are currently in the state of reading this book. If you receive an event such as a
phone ringing, a doorbell, or a time event like "It's time for dinner", you will exit the reading state. This is like the
transitions already described. But you will also exit the reading state when you finish reading the book. This is
sometimes called an automatic transition because nothing external caused the transition, it happened
automatically when the work of the state was completed. Automatic transition is modeled by starting the transition
arrow at the edge of the superstate and directing it to the new state. But the transition has no event label.
Stubbed transitions
Stub states provide yet another shorthand for moving in and out of a state machine while avoiding the need to
describe the entire state machine. Stub states represent only the entry and exit points for a submachine state.
Each stub is drawn as a line with the substate name as the label. The name just needs to be near the line. A stub
state can be used for both entry into a submachine and exit from a submachine. A stub used as an entry point is a
stub with one or more transition arrows pointing to it. A stub used as an exit point is a stub state with one or more
arrows coming out of it.
Since substates can themselves have substates (nested states), the stub notation follows the double-colon (::)
path notation used elsewhere in UML (see class paths in Chapter 5). For example, substate1 :: substate2 ::
substate3 refers to substate3 that resides within substate2, which resides within substatel.
Figure 10-41 provides two stub states, sub1 and sub1 :: sub12. The event error1 causes a transition from outside
the Handle Failure state directly to the sub1 substate of FailureSubmachine. The event error2 causes a transition
from outside the Handle Failure state directly to the sub12 substate within the sub1 substate of the
FailureSubmachine.
Figure 10-41: Stub states provide entry points for a submachine state while hiding the complete design of the
submachine. $OMG 1.4
Similarly, events can cause the object to exit a state. Figure 10-42 adds the stub state subEnd. The stub state
subEnd provides an exit point from the FailureSubmachine state. The event fixed1 forces the object out of the sub
machine FailureSubmachine and out of the Handle Failure composite state.
Figure 10-42: Modeling an exit stub state.
OMG 1.4
History indicator
The history pseudo state is a shorthand notation for a complex modeling problem. It is common to want to undo
one or more actions in an application, effectively returning the application to a previous state. Returning to a simple
state is easy. Returning to a composite state means having to find the specific substate that was active when the
object left the composite state. If the Statechart diagram had to account for every possible transition back into the
layers of substates, the diagram would quickly become too complex to be useful. The history pseudo state
provides a simple alternative.
The history pseudo state may refer to either shallow history or deep history. The terms shallow and deep refer to
how far down in the layers of substates the object should be restored. Shallow history means that the object
should return to the last substate on the topmost layer of substates. Deep history means that the object needs to
be returned to the exact substate from which it left, no matter how many layers down that is.
TipFor both shallow and deep history, there can be a default that points to an initial state either at the topmost
layer, for the shallow history default, or an initial state at a lower layer, for the deep history default. These
defaults are applied if and when the state is entered for the first time via the historical pseudo state.
Figure 10-43 models the historical pseudo state for the show seat. In the event that the show seats are restored
from archive, we want them to be returned to their former substate. The notation for a history pseudo state is a
small circle. For shallow history, the circle contains the letter H. For deep history, the circle contains H*, the letter H
with an asterisk. The transition arrow returning from the Archived state points to the circle to show that the
transition changes the state of the show seat back to whatever substate is dictated by the type of history pseudo
state.
Figure 10-43: Historical pseudo state.
Transitions to and from concurrent states
A composite state may contain concurrent states. Each set of concurrent states resides in a separate region. Each
region abides by all the rules we've defined so far for transitions in and out of superstate and for submachines. In
addition, concurrent states introduce the need to coordinate simultaneous behaviors, including synchronization,
split of control, and merge of control.
Split of control and merge of control
Split of control means that based on a single transition, you want to proceed with many tasks concurrently. Split of
control is shown by a single transition dividing into multiple arrows, each pointing to different substates. The divide
is accomplished with the synchronization bar used as a forking mechanism, as shown in Figure 10-44.
Figure 10-44: Split of control and merge of control using the synchronization bar.
Event T1 targets a synchronization bar. At the bar, the transition splits into two paths, each pointing to a different
substate, one in each region within the composite state. The transition splits into one transition for each region in
the composite state. Once the split takes place, there may be any number of substates and transitions in each
region. The regions execute independently of one another.
Merge of control means that based on the completion of a number of transitions, you want to proceed with a single
task. Basically, a merge is the opposite of a split. On the right end of Figure 10-44, there is a second
synchronization bar that illustrates the merge of control. There are two transitions hitting the bar (T2 and T3) and
one exiting the bar. The completion of the two transitions merge at the bar indicating a merge point. Once both the
T2 and T3 events occur, a single merged transition continues on out of the composite state. T2 might happen ten
minutes after T3, at the same time, or long before T3. It doesn't matter. Both events have to occur before the
merge is complete and the transition can be completed. A merge point may merge any number of transitions into a
single transition.
Synch states
Sync states extend the split and merge of control across regions to coordinate the behavior of concurrent states.
Such coordination is sometimes necessary even between relatively autonomous activities. For example, we could
compare separate regions within a composite state to the behavior of different components in a car, such as the
transmission stick and the clutch. While driving, I can move the stick on my manual transmission any time I like.
But if I move it without first pressing in the clutch I get a very unpleasant noise.
Figure 10-45 models two concurrent regions within a composite state. Reading from left to right, when state B1 is
completed, it transitions to a split point. At the split point a transition is sent to a sync state, modeled as a circle
containing an asterisk (*). In the meantime, when C1 completes, it transitions to a merge point. In order for the
transition from C1 to C2 to finish, it must wait for the transition from B1. In other words, the transition to C2 has to
wait for the completion of both B1 and C1, even though B1 is not in the same region.
Figure 10-45: Using sync states to coordinate behaviors across regions.
In like manner, B3 cannot proceed until both C2 and B2 have completed.
Multiple transitions out of a superstate
As with any composite state, there are many ways to exit a composite state with concurrent substates. Figure 10-
46 models a composite state that contains three concurrent regions. There are three ways that the object can exit
the composite state.
Figure 10-46: Multiple ways to exit a composite state with concurrent substates.
1.
Some type of interrupt event, such as T1, could take the object out of any and all substates and out of the
composite state entirely.
1.
All three substate regions could run to completion. In this case the object would automatically transition to
the next state, assuming one has been defined.
2.
A specific event, such as T2, could take the object out of a specific substate and out of the composite state
entirely.
3.
<Day Day Up>
<Day Day Up>
Summary
The Statechart diagram models the life of a single object. The fundamental elements of a Statechart diagram are
states and events. The following are the key points discussed in this chapter:
A state represents the condition of the object. The state is recorded in the values of one or more of the
attributes of the object.
An event triggers a change in state, a transition.
An action expression is a behavior triggered by an event, the behavior that actually makes the changes to the
attribute values that redefine the state of the object.
The Statechart diagram allows many events to transition to the same state. Each event may trigger an action.
When all the actions associated with the transitions into a state are the same, you can model them as a single
entry action. Place the entry action description in the internal transitions compartment of the state.
Likewise, the Statechart diagram allows many events to transition out of the same state. Each event may
trigger an action. When all the actions associated with the transitions out of a state are the same, you can
model them as a single exit action. Place the exit action description in the internal transition compartment of
the state.
When an action is directed at an object other than one modeled by the Statechart diagram, use the dot
notation to describe the send event. Place the object name and a period in front of the action expression.
When an event takes place it sets off a series of responses in the form of actions and activities. The order of
execution for the actions and activities is:
If an activity is in progress in the current state, interrupt it. 1.
Execute the exit: action(s). 2.
Execute the actions associated with the event that started it all. 3.
Execute the entry: action(s) of the new state. 4.
Execute the activity or activities. 5.
A number of different types of events can trigger a transformation in an object:
Call events are basically messages from other objects telling the modeled object what to do. They are
explicit calls to an operation on the object.
The elapsed-time event triggers a transition based on an amount of time that has passed. Elapsed-time
events use the keyword after followed by a time expression.
Change events monitor the object and/or its environment for some change. Change events use the
keyword when followed by a Boolean expression.
Signal events are asynchronous invocations, much like call events but without requiring a reply.
Guard conditions may qualify the execution of an event. The event only executes when the guard condition is
true.
The UML supports the ability to open up a state and break it into smaller pieces. The smaller pieces are
substates, states within a state. The larger containing state is referred to as the superstate or composite state.
The substates are modeled as a Statechart diagram within a state. All the normal notation of a Statechart is
available within a state. When there is more than one concurrent substate, simply split the superstate icon with
dashed lines separating the superstate into regions.
Split and merge of control use the synchronization bar to represent forking or synchronization or both.
The Sequence diagram provides the events that can affect an object's condition. It also helps to identify the
periods of time between the changes caused by the events. These periods of time when the object remains
unchanged may represent states on the Statechart diagram. To derive the Statechart diagram from the
Sequence diagrams use the following steps:
Identify the events directed at the lifeline of the object you're modeling. 1.
Identify candidate states by isolating the portions of the lifeline between the incoming events. 2.
Name the candidate states using adjectives that describe the condition of the object during the period of
time represented by the gap.
3.
Add the new states and events to the Statechart diagram. 4.
The scope of the Sequence diagram is only one scenario. The scope of the Statechart diagram is the entire
life of the object, so it might take many Sequence diagrams to build one Statechart.
<Day Day Up>
<Day Day Up>
Chapter 11: Modeling an Object's Lifecycle in UML 2.0
Overview
The single greatest change between UML 1.4 and 2.0 state diagrams (apart from the ongoing name changes) is
the effort to separate the semantics of the Activity diagram from that of the state machine semantics. In UML 1.4
there was an attempt to treat the Activity diagram as a subset of the state machine semantics. This resulted in a
kind of forced fit that limited the features of the Activity diagram and drew attention away from some of the features
that could be valuable in a state machine, such as deferred events, the description of the logic of transitions in
terms of sending and receiving signals, and making decisions during the transition. UML 2.0 draws a clear
distinction between the semantics of the two types of diagrams and remedies many of these artificially imposed
limitations.
CautionThe expression "state machine" is used with three different meanings in the UML 1.4 and 2.0
specifications. It can mean a State Machine diagram (the topmost state machine description of a
behavior), a general reference to the concept of states and transitions, or a reference to the State
Machine metaclass.
Be aware that the specification does not standardize rules that would aid in drawing a distinction in the
usage. Throughout the chapter I capitalize references to the metaclasses and the diagram. All other
references are lowercase. But to be certain of the usage you have to depend on the context.
Apart from the separation of the semantics for the State Machine and Activity diagrams, you will find the following
changes:
The State class used to be sub-classed to create simple, composite, and submachine states. These state
types are now represented by Boolean attributes within the State class.
A State may now own a Constraint that defines a state invariant.
Entry and exit actions are now defined as Activities rather than Procedures.
A Guard is now defined as a Constraint specified by a Transition.
The State and State Machine classes may now contain Regions.
Three new pseudo states have been added to the PseudostateKind enumeration: entrypoint, exitpoint, and
terminate.
UML 2.0 has dropped the concept of a sync state.
The distinction between actions and activities has been replaced with a single definition for Activity.
UML 2.0 adds the ConnectionPoint, a type of PseudoState (specified by a PseudoStateKind) that defines
navigation between, as well as into and out of states.
Events are now called Triggers.
A State Machine may extend/specialize another State Machine.
The introduction of the Protocol State Machine diagram as a subclass of a State Machine diagram.
Figure 11-1 shows the Class diagram of the state machine metamodel. The highlighted areas indicate the
changes since UML 1.4. For each new element described here, there are also associations to existing classes in
the metamodel. The new classes, their associations, and their impact on the use of the State Machine diagram are
explained in this chapter along with a complete description of the notation and use of the State Machine diagram
and the new Protocol State Machine diagram.
Figure 11-1: The UML 2.0 State diagram metamodel, with the changes from UML 1.4 highlighted.
OMG 2.0
The UML 2.0 State Machine diagram replaces the UML 1.4 Statechart diagram. A State Machine diagram contains
a variety of states, events, and transitions, initial and final states, and a variety of pseudo states (connectors), used
to model behaviors.
For those of you who have jumped directly to this chapter, skipping Chapter 10's description of UML 1.4, I have
included all of the diagram semantics and notation, but with abbreviated descriptions where UML 2.0 did not alter
the specification from 1.4. If the description leaves some unanswered questions, simply look at Chapter 10 for a
more detailed explanation. I draw special attention to the differences between UML 1.4 and UML 2.0 as they
become relevant to the current topic.
<Day Day Up>
<Day Day Up>
Defining a State Machine
A State Machine diagram describes a classifier. Most often a State Machine diagram describes the lifecycle of a
type of object. But a state machine may also describe a behavior such as a procedure or operation, or a
behaviored feature such as a use case. The object described by the State Machine diagram provides the context
for the State Machine diagram and all that it contains. The context scopes the triggers and attributes available to
the State Machine diagram. For example, the State Machine diagram for a seat in the theater has access only to
those operations and attributes defined for theater seats. In the case of a behavioral feature, the parameters of the
State Machine diagram match those of the behavior it models. For example, the State Machine diagram for an
operation models the method for that operation - receiving and editing the arguments, processing the request, and
formulating the return values.
A State Machine diagram contains a series of states, the transitions connecting the states, the trigger for the
transitions, the activities performed in the execution of the transitions, and the activities performed throughout the
duration of each state.
State machines and states in a State Machine diagram may own one or more regions. Each region contains a
series of states and transitions that is independent of the states and transitions in other regions. This feature
supports concurrency within a state machine or state.
In UML 2.0, the addition of the ConnectionPointReference metaclass allows a state machine to be a reusable
component within other state machines. A reusable state machine is called a submachine state. The connection
point references identify entry and exit channels that may be referenced much like interfaces on a class.
UML 2.0 also adds the ability to extend a State Machine diagram in the same way that you can extend a class. This
allows a State Machine diagram to parallel the classifiers that they describe. That is, when the State Machine
diagram describes a subclass, the State Machine diagram of the subclass can extend the State Machine diagram
of the superclass, saving substantial effort reworking models for specialized classes while ensuring consistent
definitions.
<Day Day Up>
<Day Day Up>
Modeling an Object State
A state describes the condition of an object. That condition may be expressed in any of the following ways:
In terms of the object's attributes:
The state is described by the values of the attributes that define the object's structure. For example, a
theater seating location may be enabled or disabled. These values (enabled and disabled) are recorded
in an attribute.
The state is described by the values of the attributes that define the object's relationships. A ticket may be
sold or not sold. Whether it is sold is captured in the presence or absence of a link to an order (recorded
as a null or non-null value in an attribute holding the reference to the object).
In terms of a behavior that the object is engaged in:
Performing an action. An object may perform work while in a given state. In fact, a state may itself be
decomposed into a series of states. The completion of all the work in a given state, including all the work
of all substates within the state, triggers a transition out of that state. While performing the work, the
object is in the "occupied doing something" state.
Waiting for an event. An object may also simply stop doing anything until it receives a trigger to continue.
In this case the object is the state of "doing nothing until something happens."
In formal terms, a state models a period of time in which an invariant condition holds true. That invariant may be a
set of attribute values, the condition of waiting for (not having received) an event, or working on (not yet having
completed) an activity.
The State metaclass itself distinguishes three types of states:
Simple - a state that does not contain any other states.
Composite - a state that contains one or more state machines within separate regions.
Submachine - a state that contains the specification of the entry and exit points for a reusable state machine.
This too can be confusing. The containing state is called a submachine state. The contained state machine is
called a submachine.
The rest of this section is devoted to simple states. Composite and submachine states are covered later in this
chapter.
As Figure 11-2 shows, UML 1.4 defined these various types of states as subclasses of the State class. UML 2.0
chose to simplify the model by defining the state types using the Boolean attributes isSimple, isComposite, and
isSubmachineState (I'll cover isOrthogonal in the section on regions). The benefit here is simplicity for modeling-
tool vendors who need to support this model. Functionally it makes no difference in the use of the three types of
states.
Figure 11-2: The change in the definition of state types from UML 1.4 to UML 2.0.
OMG 1.4 OMG 2.0 modified
A simple state is just that-simple. There can be no substates and no regions; hence no submachine states (see
what I meant about the terminology). The notation is like UML 1.4's: a rounded rectangle with two compartments,
for the name and internal transitions, as illustrated in Figure 11-3. The name may appear in the name
compartment or in a tab on top of the state icon. The first option is by far the most commonly used form. The
internal transitions compartment may define entry and exit actions, activities, internal transitions, and deferred
events.
Figure 11-3: Simple state notation.
Entry actions are activities that always execute, and run to completion, before the state begins any activities or
responds to any internal transitions. The entry actions execute regardless of the specific event that triggered a
transition into the state. Entry actions are modeled by writing Entry/ followed by the name of the action.
Exit actions are activities that always execute, and run to completion, before the state responds to events that
trigger a transition out of the state, regardless of what that event might be. Exit actions are modeled by writing Exit/
followed by the name of the action.
Neither entry nor exit actions may be interrupted. Entry and exit actions are unique types of activities that make the
changes to an object's attributes that redefine the state of the object. Interrupting them might leave the object in an
undefined state.
Activities are behaviors that an object performs while in the state that owns the activity. Activities begin execution
after all entry actions have completed. If an event triggers a change to another state, the activity may be
interrupted. Unlike actions, activities, by definition, cannot change the state of the object, so interrupting them will
not corrupt the state of the object. That is not to say that they are insignificant, so care should be taken in how the
interruption is handled.
Internal transitions are events that trigger a response from the object, but not a state change. For example, the
event changeName(nameText:String) on an active regular customer does not change the state of the
customer, but it does need to make the requested change to the name attribute of the customer. Modeling an
internal transition makes it clear under what circumstances such a modification is possible.
While an object is in a state, it may receive events that it cannot respond to, but which need a response some time
in the life of the object. In the current state, the event needs to be set aside, or deferred, for late consideration.
Events that can be deferred are identified in advance using the notation, "Event-name / defer." A deferred event is
passed to the next state along with the next transition. The event may be deferred as many times as the model
allows. The last state to receive the event without deferring it must implement the procedure(s) triggered by the
event.
The isFinal attribute refers to the ability to extend a state. A state may override features of an inherited state as
long as the isFinal attribute of the feature is set to false. A state may be extended in any of the following ways:
A simple state can be extended to become a composite state by:
Adding one or more regions
Adding states and transitions
A composite state can be extended by:
Adding regions
Adding states and transitions
Adding entry or exit actions, or activities
Defining triggers and ports
The trigger used in a state machine is an extension of the basic definition found within the behavioral and structural
portions of the specification (the Superstructure :: Behavior :: CommonBehaviors and Superstructure :: Structure ::
CompositeStructure packages). A trigger defines the types of events that can initiate a transition between states.
An event is anything that can happen in a system, such as a signal sent by some behavior, a call to a specific
operation, reaching a point in time, or a change in values within the system. Accordingly, a trigger can be typed as
any of the following four trigger types depicted in Figure 11-4.
Figure 11-4: Trigger metamodel.
OMG 2.0
SignalTrigger: (replaces SignalEvent in UML 1.4) A trigger that will allow an asynchronous signal to start a
transition.
CallTrigger: (replaces CallEvent in UML 1.4) A trigger that will allow a transition to be initiated by the invocation
of an operation (called a call event).
TimeTrigger: (replaces TimeEvent in UML 1.4 and adds the attribute isRelative) A trigger that specifies a
deadline at which a transition must take place. The time expression of the time trigger may be relative (10
minutes from now) or absolute (5:00 PM).
ChangeTrigger: (replaces ChangeEvent in UML 1.4) A trigger that recognizes a change in the values of one or
more attributes evaluated by a Boolean expression. The change does not have to be the result of a specific
action.
A transition is shown as a solid line originating from the source vertex and terminated by an arrow on the target
vertex. A vertex is any type of node within a state machine (initial, final, state, decision, and so forth). The transition
may be labeled by a transition string that has the following general format:
trigger-signature ['['guard']'] '/' activity-expression
The trigger-signature is a list of names of the triggering events, followed by an assignment specification:
event-name-list ['('assignment-specification')']
where the assignment-specification is a comma separated list of items. Each item in the assignment-specification
may take one of two forms.
In the first form the attr-name is an implicit assignment of the corresponding parameter of the event to an
attribute (with the same name) of the state machine instance or of the context object.
attr-name:
In the second form, the attr-name is an implicit declaration of a local attribute within the effect activity and an
implicit assignment of the corresponding event parameter to this local attribute. (Like methods for an operation, an
instance of an activity invoked by a transition can have local attribute, attributes that are only available during the
execution of the activity.)
attr-name ':' type-name:
Example transition, with a guard and activity expression:
right-mouse-down (location) [location is within the window]
/ object := pick-object (location); object.highlight ()
The transition will only be allowed if the guard (location is within the window) is satisfied.
The activity-expression (object := pick-object (location); object.highlight ()) is executed if
and when the transition fires. It may be written in terms of operations, attributes, and links of the context object and
the parameters of the triggering event, or any other features visible within its scope. The activity expression may be
an action sequence comprising a number of distinct actions including actions that explicitly generate events, such
as sending signals or invoking operations. The details of this expression are dependent on the action language
chosen for the model.
A port defines an entry point to a trigger, a kind of gate between a state or transition and a trigger. A port is
described using two qualifying attributes, isSignal and isService. A true value for isSignal defines the port
as only able to send signals, not calls, time, or change events. The default value is false.
The default value of true for isService indicates that the port is used to offer the functionality (services) provided
by the classifier. If the isService attribute is false, then the port is part of the implementation of the classifier, not
part of its externally available interface. Instead, it is a means to access internal transitions. As such, it may be
altered or deleted along with the other implementation features of the classifier, in this case a trigger. The ports
portion of the transition string conforms to the following syntax:
'via ('comma-separated-port-list')'
Figure 11-5 models a trigger that causes the transition between the Complete and ApprovingPayment states for an
order object using the entire event signature notation. The diagram tells us:
Figure 11-5: Modeling transitions with the complete event signature.
The pmtReceived() event may come through either the creditCardPmt port or the cashPmt port. 1.
As long as the amount received as payment is greater than or equal to the total value of the order. 2.
then the approvePayment activity will be invoked 3.
and the order will transition from the Complete state to the ApprovingPayment state. 4.
Modeling transitions
Transitions model the movement from one state vertex to another. A state vertex may be a state, or pseudo state.
For now I will discuss only states. Later, I will explain the use of pseudo states.
A transition is modeled as an arrow and is triggered by an event. Each transition is associated with an event that is
the trigger or cause for the transition. The base of the transition arrow defines the source, the state the transition
leaves when the trigger occurs. The arrowhead defines the target, the state to which the object changes at the end
of the transition.
Figure 11-6 models the transition of an order object from the Complete state to the ApprovingPayment state,
triggered by the pmtReceived event.
Figure 11-6: State transition from Complete to ApprovingPayment.
Note the second transition on top of the ApprovingPayment state. It points out of and back to the same state. This
is called a self-transition, and is most often used as a form of reset for the state. The effect of the self-transition is
to cause the object to take all the necessary steps to leave the state, namely interrupting any activities in progress
and completing all exit actions. The object then re-enters the state, completing all the entry actions once again,
and then kicking off any activities defined for the state.
So Figure 11-6 says that, if the order receives the pmtReceived event while it is in the Complete state, it will
transition to the ApprovingPayment state. If the order receives the same event while in the ApprovingPayment state
it will stop what it is doing and restart.
Figure 11-7 shows part of the UML 2.0 metamodel for transitions. In it you see the source and target state vertices
and the constraints described so far.
Figure 11-7: Metamodel of a transition.
OMG 2.0
A transition may also have an associated activity, a behavior that executes when the transition is activated. The
behavior is described using a language-natural language or OCL. Typically an activity takes a set of input values
from the object sending the event that triggered the transition. The activity may create a set of return values. The
actions that the activity performs may be actions associated with other parts of the model. In short, an activity maps
to an operation that may perform any number of behaviors, including calls to operations on other objects.
An activity may also specify the language in which it is written. This is often left blank since the language is often
obvious from the procedure expression.
A transition may be guarded by a condition that defines whether or not the transition may take place. The guard
should be a Boolean expression with no output values or invocations on other objects. In a simple transition, the
guard is evaluated after the triggering event and before the transition. UML 2.0 has formally replaced the guard
with a constraint. Now "guard" is simply the role that a Constraint object plays in relation to the transition. The
effect is the same but the formal definitions are now more consistent.
A constraint contains a ValueSpecification, a set of zero or more values in the forms of data values or object
references. In most cases, a constraint is written as a Boolean expression, making reference to objects and/or
values relevant to the transition. For example, pmtReceived() may not cause a transition if the payment amount is
less than the amount owed. The notation for guards was illustrated earlier as part of the transition string.
Adding initial and final states
Since a State Machine diagram models the entire life of an object or of a behavior, there needs to be a way to
specify the beginning and the end. The initial state marks the starting point of a behavior or object lifecycle. It is
actually a kind of pseudo state defined by the enumeration PseudostateKind. It does not have the features or
relationships of a real state. It is merely a marker as modeled at the far left in Figure 11-8. The initial state icon, the
small solid circle with an arrow pointing to a state, identifies the state that an object is in when it is first created, or
the first step in a behavior like a use case or method.
Figure 11-8: Initial and final states for a seat in the theater.
The final state icon, the bull's eye at the far right of Figure 11-8, represents a state from which the object may no
longer change. There may be only one initial state, but there may be any number of final states, including no final
state at all.
The end of an object's life, or the end of a behavior, is identified by the final state. Final state is a real state. In fact,
FinalState is a subclass of State in the metamodel. As such, a final state has all the features of a simple state, with
one exception: A final state may never have any outgoing transitions. In other words, once the object or behavior
hits the final state, it may never change.
One misconception is that the final state means that the object has been deleted. It may mean that. But it may also
mean that the object has been flagged for deletion, archived, or otherwise frozen. It can still exist. Furthermore, as
a real state, it may still be interrogated, reported on, tested, and so forth. It just can't transition to another state any
more. In Figure 11-8, for example, the seat may be removed, but we can still run reports on the removed seats to
find out why they were removed-damaged, a change in the floor plan, or upgraded, for example.
Completion transitions and completion events
An object may transition out of a state in response to an explicit event. An object may also transition out of a state
simply because it has completed every behavior assigned to it while in that state. For example, you are currently in
the state of reading. The activity is to read this book. When you finish reading the book you simply move on to
another state (like entering a great review in Amazon.com, thank you very much).
Completing all internal activities generates a completion event that triggers a completion transition. In the past this
has also been called an automatic transition, because the object automatically transitions, without help from any
external event. Figure 11-9 illustrates the use of a completion transition. A completion transition arrow has no
transition string.
Figure 11-9: An automatic transition does not have an associated event description.
Modeling transition details
Sometimes a transition may be complex, involving the receiving and sending of signals, decisions, and multiple
actions. In UML 1.4, the Activity diagram included notation for sending and receiving signals. These notations are
now part of the UML 2.0 State Machine diagram notation.
A simple transition might include a series of actions in the action expression. To model the actions graphically,
each action is described within a rectangle. The actions are strung together as portions of the total transition.
Figure 11-10 models the transition from the Complete state to the ApprovingPayment state. The associated action
is to approve the payment. The image on the left in Figure 11-10 is the original version of the transition (which is
still perfectly correct notation in version 2.0). The image on the right is expanded to model the action that occurs as
part of the transition.
Figure 11-10: Adding action sequences to a transition.
This example transforms the transition from a parameterized arrow to a logical model that might include not only
actions, but also decisions, and sending and receiving events. For example, approving the payment might require
different procedures depending upon whether the payment was by cash or credit card. The actions could tailor the
entry point to the ApprovingPayment state depending on the payment type.
Figure 11-11 adds a choice pseudo state diamond, previously called a decision diamond, to evaluate the payment
type parameter and select the right action. The paths leading out of the decision are each labeled with mutually
exclusive conditions so that only one path may be chosen.
Figure 11-11: Adding a decision into the action sequence of the transition.
NoteWhen using a choice pseudo state, it is usually good practice to include a path that covers all other
options not explicitly specified. This is often expressed as an else path, the path taken when no other
condition is satisfied.
Sending and receiving signals
During the execution of the transition and the associated actions, the actions receive values from the invoking
event. The action sequence may manipulate or evaluate these values and provide them as input to subsequent
actions. In Figure 11-12, the pmtReceived trigger receives the pType value that is used to test the guard. Later,
the pType value is used to decide to which type of payment approval action should send the amt value.
Figure 11-12: Adding send and receive signals to the action sequence.
<Day Day Up>
<Day Day Up>
Modeling a composite state
A state may also be decomposed to provide a finer-grained description of the transformations in an object. The
decomposition provides opportunities to model not only more detailed states but also concurrent states. It even
opens the door to reuse entire state machines in much the same way that we reuse classes on Class diagrams.
No matter how many Class diagrams a class appears on, it is always the same class. The same is true of states
machines appearing in many states on State Machine diagrams and within composite states.
A composite state contains one or more regions. The simplest composite state contains only one region. Within the
region is a set of two or more states, called substates, because they describe states within a state. States may be
nested in any number of layers within a state. Substates that reside on the topmost layer of the decomposition are
called direct substates. Substates of successively lower layers of decomposition are referred to as transitively
nested states, which simply means that these states abide by the behavior of the states that they are contained
within.
A composite state with a single region looks like a State Machine diagram nested inside a state. For example, a
theater show seat may be considered either active or archived. But while it is active it goes through a number of
lesser changes, from not priced to priced, from not sold to sold, and so forth. Figure 11-13 shows the higher-level
view on the left, with only two states, active and archived. The lower-level view on the right models six direct
substates within the composite Active state.
Figure 11-13: Modeling a composite state with one region and six direct substates.
Note the composite state notation in the lower right corner of the expanded state on the right in Figure 11-13. The
composite state icon consists of two horizontally aligned rounded rectangles connected by a line.
Region
A composite state may have any number of regions. A region contains a state machine (lower case state machine-
not a State Machine diagram). The states in each region are mutually exclusive of states in other regions. If the
composite state contains two or more regions it is said to be orthogonal, and the isOrthogonal attribute is set to
true.
If each region operates independently, then it is possible to run regions contained within the same state
concurrently. A region is defined as active if any state within the region is active. Since any state may be a
composite state and own regions, it is possible to construct hierarchies of states within states. A mapping of the
active states at each level of such a hierarchy is called a state configuration.
TipA state can be active or inactive. A state becomes active when it is entered as a result of a transition, and
becomes inactive when it is exited as a result of a transition.
Figure 11-14 models a composite state with two concurrent regions. The regions are separated by a dashed line
through the composite state icon. Each region has its own state machine with an initial state, two states, and a final
state. Virtually all notations for a State Machine diagram are valid within a region. It is also possible to draw
transitions from outside the regions or even the state, and from within a region to locations outside the region or
even outside the state. I'll cover these other possibilities in the next section.
Figure 11-14: Composite state with two regions divided by a dashed line.
Modeling transitions, types of transitions
Fork, join, junction, and choice pseudo states provide a variety of configuration options for managing complex
transitions with composite states and multiple regions. All four pseudo state types are defined in the
PseudostateKind enumeration and may be assigned to an instance of Pseudostate.
Fork
The fork pseudo state applies to transitions between states within different regions of a composite state. It allows a
single transition to split into multiple paths, aimed at multiple target states in different regions. Figure 11-15 shows
how a single transition from one state splits and triggers transitions to states in two different regions within a
composite state. The effect of the fork is to simultaneously trigger concurrent behaviors in different regions.
Figure 11-15: Initiating concurrent states from single transition using a fork pseudo state.
Figure 11-15 models a transition from outside the composite state. The forking transition may come from another
region within the composite state as well. In Figure 11-16, for example, the fork uses a transition in the upper
region to fire a transition to another state in the same region and a state in the bottom region.
Figure 11-16: Initiating transitions in two regions from within one of the regions.
NoteThe one restriction on using a fork state vertex is that none of the outgoing transitions may have
constraints. Semantically it would not make sense to have conditions on these segments that were not
part of the transition segment going into the fork.
Join
A join pseudo state forms the other half of the example in Figure 11-16. Figure 11-17 highlights the notation for the
join. The join models multiple transitions coming into the symbol and one going out. The effect of the join is to
create a kind of stopping place where the state machine waits for all of the incoming transitions to arrive before
triggering the outgoing transition.
Figure 11-17: Using the join pseudo state to manage multiple triggering transitions.
The same technique may be used to trigger a transition to a state outside the composite state. Figure 11-18
models two transitions from within a composite state triggering the transition to a single simple state.
Figure 11-18: Triggering an external transition from within a composite state.
Junction and choice pseudo states
The junction and choice pseudo states correspond directly to concepts explained fully in Chapter 10, in the section
titled, "Compound transitions and factored paths". The junction pseudo state corresponds to the merge and the
static conditional branch. The choice pseudo state corresponds to the dynamic conditional branch.
UML 2.0 provides some alternative presentation options for the choice and junction pseudo states. In UML 1.4, the
choice pseudo state was modeled as a small hollow circle, with the option to use a diamond. In UML 2.0, the
diamond is the standard notation. You have two options for displaying the choice pseudo state. Figure 11-19
presents both options. The example on the left models the complete Boolean expression on each outgoing
transition segment. The example on the right places the common element of the two expressions inside the
diamond and uses only the unique portion of the Boolean expressions on each segment.
Figure 11-19: Alternatives for modeling the choice pseudo state, with a diamond and with a circle.
A junction provides a common point on a transition path for multiple objects transitioning to the same target/s. UML
2.0 supports the same simplification for modeling junctions as in UML 1.4. Figure 11-20 models a junction pseudo
state where the three states (State1, State2, and State3) all transition to State4.
Figure 11-20: Basic junction notation.
Figure 11-21 models an alternative. If all the states transition to the junction in response to the same event, with no
side effects such as constraints or event actions, the states may be combined into a state list, which is a state
representing a set of states, listed in the state name.
Figure 11-21: State list alternative notation for a junction.
The terminate pseudo state
When a classifier is terminated, any state machine for the classifier is terminated. The terminate pseudo state is
modeled as a large "X" on the State Machine diagram, as shown in Figure 11-22. When the delete operation is
invoked on the classifier that owns the state machine, the classifier completes the behavior associated with the
delete operation (such as deleting the object from the database) and terminates the state machine.
Figure 11-22: Modeling the terminate pseudo state.
Entering and exiting states and regions
Any region may have an initial state (pseudo state) and a final state, but it does not require either. So it is important
to know how to enter and exit a region and how the state machine will behave. A region has a boundary and a
contained set of states and transitions.
There are a number of ways to enter a state:
Default entry
Explicit entry
Shallow history entry
Deep history entry
Default entry says that the incoming transition stops at the edge of the composite state. Stopping at the edge
implies that the composite state will determine how to handle the transition, because the transition does not know
the specific target substate. Figure 11-23 models a transition from a state outside the composite to the edge of the
composite state. The composite state starts at the initial state of the contained state machine.
Figure 11-23: Default entry to a composite state with one region.
This approach provides a degree of encapsulation when using the state because the internal structure of the
composite state is not exposed to other states. The internal structure can be modified over time without affecting
the interactions with other states in the state machine.
Entering a composite state with multiple regions is basically the same. Figure 11-24 models a composite state with
two regions in which both initial states are triggered by the incoming transition. The effect of the transition ending at
the edge of the composite state is the same as if the transition forked to the two initial states, but it provides the
added benefit of encapsulation.
Figure 11-24: Default entry to a composite state with two (multiple) regions.
Explicit entry means that the transition is targeted at a specific substate within the composite state. If there are
nested states, the entry rules apply to each successively nested state. Figure 11-25 models an explicit entry into a
composite state with one region (non-orthogonal composite) and a composite state with two regions (orthogonal
composite).
Figure 11-25: Explicit entry into a composite state, both non-orthogonal and orthogonal.
Sometimes a composite state transitions to some other state or states, and then needs to return to the same
substate it was in when it left. This is done by using history entry points. Returning to the right substate has to take
into account the fact that there may be many layers of nested substates involved. Sometimes it is necessary to
return to the exact same substate that was active when the composite state was exited. This is called deep history.
Other times it is only important that the composite return to the topmost state that contained the actual nested
substate. This is called shallow history.
The shallow history notation is a small circle with the letter "H" inside. The incoming transition points to the shallow
history icon rather than to an actual state. This mechanism is used because the incoming transition can't know the
substate that the composite was in when it left the last time. It could potentially have been in any of the composite's
substates. The top portion of Figure 11-26 models a return to the shallow history state. The bottom portion of
Figure 11-26 illustrates that the transition returning from the archived state could potentially return to any of the six
substates, but it does not know which one.
Figure 11-26: Returning the shallow history of a composite state.
The deep history notation is the circle with an H* inside, as shown in Figure 11-27. The effect of the deep history
return is the same as for the shallow history return, except that the entry is repeated at each level of nested
regions/state machines until it reaches the right substate. For example, shallow history could require the transition
to return to the state Price, Not Held, Sold, a substate of the Active state on the first level of its decomposition into
substates. Deep history could require that the transition return to one of three substates within Priced, Not Held,
Sold (if there was one), a substate two levels down from the Active composite state.
Figure 11-27: Deep history pseudo state icon.
UML 2.0 changes the definition of deep history to say that the containing state need not have been exited in order
to define deep history. This means that deep history can be the target of transitions within the containing state, not
just from states outside the composite. This change makes the definition of deep history consistent with the
definition of shallow history.
It is valid to use a mix of default entry and explicit entry. For example, a fork might transition to one substate in one
region and to the edge of the second region. The first region uses explicit entry. The second region uses default
entry.
Leaving a composite state may also occur via a number of methods. Basically when a region completes all of its
activities it triggers a completion event. For a non-orthogonal composite state this means that a completion
transition is triggered. For an orthogonal composite state, a state with two or more regions, every region has to
complete before the completion transition is triggered. In both cases the transition is automatic. There is no explicit
event that causes the transition.
When nested regions/state machines are involved, the exit takes place from the innermost state to the outermost
state, until all activities have been completed.
In Figure 11-28, the state Studying may exit on any of the following conditions:
Figure 11-28: Exiting a composite state.
OMG 2.0
Explicit event
An exit from a specific substate (the student fails the Final Test, for example).
An exit from the composite state Studying (the student quits school, for example).
Completion of all activities in all regions (which causes an automatic transition to Passed):
Labs are done and
Term Project is done and
Final Test has been passed
An exit resulting from completion of all activities does not have a transition name because there is not a specific
event. All other exits must have a name to explain why the exit occurred.
<Day Day Up>
<Day Day Up>
Modeling a Submachine State
When modeling behavior, it is common to reuse portions of the functionality. For example, operations call other
operations, operations call utility objects, and use cases reference other use cases. State machines are no
different. When a state machine or part of a state machine is found to be used in multiple contexts, it can be
defined as a reusable state machine, called a submachine.
The terminology regarding submachines can be confusing. There are three key terms:
State Machine diagram: A State Machine diagram is the top-level graph of states and transitions that describes
a behavior. Lowercase state machine is a general reference to any type of graph that represents movement
between states. The general meaning of state machine is used to describe any nested graphs within regions.
Submachine (also known as submachine state machine): A reusable state machine specification. The details
of the state machine are defined independently, in their own State Machine diagram. The (submachine) state
machine is then included within a submachine state.
Submachine state: A state that contains (includes) a submachine using the include statement within the
internal transitions compartment:
Include / submachine-name
Semantically a submachine state is the same as a composite state. The naming difference describes the unique
way that a submachine is used. A submachine may have entry and exit actions, activities, and initial and final states
just like any other state. The difference is that a submachine state can provide entry and exit points.
Entry and exit points are new to the submachine in UML 2.0. They were added specifically to enhance reuse
through encapsulation of a state machine.
The features of the submachine are not presented on the diagram at all. Instead, the containing submachine state
channels access to the features through connection point references on the edge of the submachine. The
connection point references provide both entry points into the submachine and exit points from the submachine. In
short, the connection point references define the interface to the submachine in much the same way that operation
signatures provide the interface to an object. So a containing composite state does not need to know the internal
structure of the submachine in order to benefit from its design.
An entry point is an initial pseudo state associated with a connection point. In fact, a connection point reference
may be associated with a number of entry points. An exit point is one or more named FinalStates associated with a
connection point reference.
Figure 11-29 models the state machine that is included as a submachine in Figure 11-30.
Figure 11-29: Reused state machine.
Figure 11-30: Include statement and entry/exit points for a submachine state.
Note that the default entry is into Sub1, and the normal termination is through Sub5.
Figure 11-30 provides an example of the submachine notation. The outermost state is a composite state that
contains a submachine state called SubmachineState, which contains a submachine called Submachine, the state
machine modeled in Figure 11-29.
Transition T1 transitions to an entry point labeled Sub3 on the edge of the submachine state. This entry point
functions like a junction in a simple state, or a fork to concurrent regions. It may redirect the transition to one or
more entry substates. The specific substates are modeled on the State Machine diagram for the submachine. In
this case, Sub3 corresponds to the third state in the State Machine diagram in Figure 11-29.
Transition T2 transitions to the edge of the submachine state. This means that the transition is directed to the
default initial state(s) defined within the submachine. (Refer to Figures 11-23 and 11-24 for examples of default
entry.) Referring to Figure 11-29, the default initial state is Sub1.
Transition T3 transitions from exit point Sub4. This exit point may represent one or more explicit exits from the
submachine that yield the same effect. All exits through exit point Sub4 are directed to State3. The exit point
functions like a junction in a simple state or a join from concurrent regions. In this case, the exit point is a transition
from state Sub4 in the State Machine diagram on Figure 11-29.
Transition T4 transitions from the edge of the submachine state to State4. This means that when the submachine
completes all of its activities it automatically exits. No explicit exit event is required. Referring to Figure 11-29, this
means that the submachine exits when state Sub5 is completed.
NoteIt is valid to model any number of submachine states invoking the same submachine any number of
times in the same State Machine diagram. However, each use of the submachine can and should model
the use of different entry and exit points.
<Day Day Up>
<Day Day Up>
Modeling a Protocol State Machine Diagram
UML 2.0 draws a distinction between a state machine that describes behavior and a state machine defines the
valid use of a classifier:
The state machine focuses on modeling behavior, any behavior within a system, from operations to use cases
(although it is also used for modeling the lifecycles of classifiers).
The protocol state machine describes the transitions that are allowed in each state and under what conditions.
Because of this focus, the protocol state machine is particularly well suited for defining the lifecycle of a classifier
instance. That is, it defines how and in what order the classifier instance progresses from state to state, and how it
may behave while in each state. Much of what the protocol state machine adds is drawn from the concept of
programming by contract. This is seen most readily in the description of a transition using pre- and post conditions.
Because the protocol state machine focuses on rules for using features, it is also well suited for describing
interfaces and ports, the access points to features of a classifier. Consequently, UML 2.0 now allows interfaces
and ports to identify a protocol state machine that explains their use.
Figure 11-31 is the metamodel for the protocol state machine. On the left side are the associations between port
and protocol state machine and between interface and protocol state machine. Any number of ports may
reference the same protocol state machine because a port provides access to interfaces. Many ports might access
the same interfaces and so share the same protocol. But an interface can have either zero or one protocol state
machines, and no more.
Figure 11-31: Metamodel for the protocol state machine.
OMG 2.0
A protocol state machine is modeled as a state with the keyword {protocol} enclosed in curly braces next to its
name, as shown in Figure 11-32.
Figure 11-32: Protocol state machine identification.
Defining a state in a protocol state machine
A state used in a protocol state machine has all the features of a state in a state machine, with one significant
difference. Normally the state of an instance of a classifier is encapsulated (hidden) within the instance and not
directly visible to a user of the instance. But states of protocol state machines are exposed to the users so when an
instance of the classifier is not processing any operation, the user can always know its current state.
Defining protocol transition
As I said before, in a protocol state machine the focus is on defining what is legal, as opposed to what is possible.
Where a regular state machine might try to account for anything that could happen, the protocol state machine
defines rules about the state of the object at the time that someone attempts to trigger a change and the condition
of the object after the change.
The rules are expressed as constraints enforced before and after a protocol transition. The precondition states
when an operation may be called in the source state. The post condition defines the rules that the target state
must conform to at the end of the protocol transition.
The operation referred to by the protocol transition is the operation associated with the call event that triggers the
transition. So, the precondition of the protocol transition is very much like the guard constraint on a regular
transition. That is, the event may not fire if the guard constraint/precondition is not first satisfied.
In fact, the pre- and post conditions of the protocol transition map directly to the pre- and post conditions of the
operation that triggers the transition.
Figure 11-33 provides an example of the protocol transition notation.
Figure 11-33: Protocol transition notation.
Defining protocol conformance
A common theme in the enhancements introduced by UML 2.0 is the ability to specialize model elements. In a
Class diagram, a class may implement an interface. The interface defines the rules for accessing features. The
implementing class is obligated to abide by those rules when it provides the implementation for the interface. In like
manner, a state machine may specialize/implement a protocol state machine. The protocol state machine defines
the rules to which the implementing State Machine diagram must conform.
UML 2.0 explicitly defines a metaclass, ProtocolComformance, which maps the relationship between the general
and the specialized state machine. The one constraint on the specialization relationship defined by
ProtocolConformance is that the general state machine must always be a protocol state machine. This implies that
it is valid to extend a protocol state machine with yet another protocol state machine. Figure 11-34 is the
metamodel that shows these relationships between the protocol conformance, the state machine, and protocol
state machine.
Figure 11-34: Metamodel for ProtocolConformance.
OMG 2.0
Since a protocol state machine is always associated with a classifier, the specialization of a protocol state machine
typically corresponds to the specialization of the associated classifier. Figure 11-35 illustrates this relationship
using the Contract and PremiumContract classes from the theater system. In this example, the protocol
conformance instance refers to the ContractStateMachine (a protocol state machine) as the generalMachine and
the PremiumContractStateMachine (a specialization of ContractStateMachine) as the specificMachine.
Figure 11-35: Conformance mirrors the relationship between classifiers and their state machines. (The
association between the protocol state machines and their corresponding classes is for illustration only. A
modeling tool would maintain this relationship but it would never appear on any diagram.)
<Day Day Up>
<Day Day Up>
Summary
UML 2.0 provides two levels of state machine diagrams, the State Machine diagram and the Protocol State
Machine diagram. The State Machine diagram corresponds to the UML 1.4 Statechart diagram and supports the
description of behaviors as diverse as operations and use cases, or the life cycle of a classifier. The Protocol State
Machine diagram is new in UML 2.0 and provides an encapsulated view of states and transitions that reinforces the
legal requirements for the state machine in much the same way that interface classes define the legal use of a
class.
A State Machine diagram uses four different types of state:
Simple: A state with no substates or regions
Composite: A state that may contain states (called substates) and transitions, and may contain regions, which
in turn contain states and transitions
Submachine: A reusable state machine, defined independently but referenced within other state machines
through the use of a containing submachine state
Submachine State: The container for a submachine, that specifies the entry and exit points to the submachine.
Events and transitions are basically unchanged from UML 1.4, except that UML 2.0 provides support for
inheritance of states and transitions, and state machines in general.
Regions are new in UML 2.0. A region is a kind of name space, within a composite state, that contains a state
machine. Multiple regions within a composite state run concurrently.
ConnectionPoints, also new in UML 2.0, provide a level of encapsulation for states by separating the transitions
into and out of the state machine from the actual states they reference. The entry and exit point function much like
fork and join pseudo states, mapping external transitions to and from the internal states.
Pseudo states are notations used to link elements of the state machine graph.
Initial state identifies the first state that an object assumes when it is created.
Deep history refers to a return to a composite state in which the return must be directed to the actual substate,
no matter how many layers down in the nested states the object was in when it left the composite state.
Shallow history refers to a return to a composite state in which the return is directed to the topmost substate
that was active when the object left the composite state.
Fork provides the means to split a transition into multiple transition paths, such as to transition to states in
concurrent regions within a composite state.
Join provides the means to bring together multiple transition paths and continue as a single transition path,
such as to transition from states in concurrent regions within a composite state to a single state outside the
composite.
Junction provides a simplification mechanism for factoring complex sets of transitions.
Choice is a decision point in the execution of a transition. The icon has changed in UML 2.0 from a hollow
circle to a diamond.
Entry point is new in UML 2.0. The entry point is used to encapsulate a submachine by hiding the internal state
machine elements from external state transitions.
Terminate identifies the point at which the classifier that provides the context for the state machine no longer
exists.
Ports are new in UML 2.0. Ports define the types of services supported by a state. Services may be required or
provided. A provided service equates to a behavior that the state can perform upon request. A required service
defines a behavior that the state needs to be performed by some other element in the environment.
The Protocol State Machine is new in UML 2.0. It functions much like an interface definition. Instead of defining
anything that might happen to a classifier, it defines only what will be allowed. It does not however define how the
classifier will support the rules, only that it must.
States in a protocol state machine are exposed to the users so when an instance of the classifier is not processing
any operation, the user can always know its current state.
The protocol transition defines the parameters for the proper execution of the transition. It does so by defining pre-
and post conditions. A precondition is a constraint on the condition of the source state at the time the transition is
triggered. The constraint must test positive in order for the transition to execute. The post condition defines a
constraint on the target state. The constraint must also test positive in order for the transition to complete. Both
sides of the transition must succeed for the transition to run to completion.
UML 2.0 supports the ability to extend a protocol state machine and enforce compliance with the rules defined in
the protocol state machine. The ProtocolConformance class identifies the generalMachine, a Protocol State
Machine, and defines the rules and the specificMachine (another Protocol State Machine) that must conform to the
rules.
<Day Day Up>
<Day Day Up>
Part IV: Modeling Object Behavior
In This Part
Chapter 12: Modeling the Use of a System with the Use Case Diagram
Chapter 13: Modeling Behavior Using an Activity Diagram
<Day Day Up>
<Day Day Up>
Chapter 12: Modeling the Use of a System with the Use
Case Diagram
Overview
The Use Case diagram is a unique graphical element, in that it is a diagram used to model how people expect to
use a system. The diagram describes who the relevant users will be, the services they require of the system, and
the services they need to provide to the system.
NoteThe Use Case diagram can be applied to many types of development, including manual systems, but it
is most commonly used for systems and subsystems.
The Use Case diagram is the key element of the Object-Oriented Software Engineering (OOSE) method, also
known as Objectory (short for object factory), published in 1992 by Ivar Jacobson and his associates. The
technique had a proven track record with large-scale object-oriented projects at Ericsson, HP, and other
companies. Its success garnered the attention of authors of other popular methods that lacked a means to
document system requirements from the viewpoint of clients and other systems. Soon, many of the leading
methodologists like Grady Booch and James Rumbaugh, sought to find ways to merge their methods with this use-
case-driven approach. As a result, the Use Case diagram was formally incorporated into UML 0.9, released in
June 1996.
The Use Case diagram is often used as part of a more comprehensive use-case-driven approach that also
includes a textual description of individual use cases and the extraction of scenarios. The textual description
addresses the detailed requirements for a use case. Scenarios address the need to explore options in the
execution of the use case, to test the requirements, and to provide a high-level test plan for subsequent
development phases. Figure 12-1 illustrates the elements of the use case approach-the Use Case diagram, the
use case narrative or description, and the use case scenario (using an Activity diagram).
Figure 12-1: Resources of the use case approach.
To define the requirements for a project, it is necessary to consider both the scope (the range of functionality) and
the level of requirements.
The scope of the use case approach may encompass a range of subjects:
An entire enterprise or line of business: This level of model is used to describe how all systems in an
enterprise fit together.
An individual system: This is the most common level of use case approach.
A single subsystem or component: This level describes the mechanics of the implementation of an element of
the model.
TipBecause the scope of a Use Case diagram may vary so widely, the target of the diagram is often referred
to simply as the subject. This convention proved awkward for a book, so I have elected to use the most
common level, the system-level Use Case diagram, for the examples in this text. When I depart from this
convention, I will make it clear in advance.
Why Is It This Way?
While I was teaching at Thiokol Propulsion, where the rockets for the space shuttle are built, a student shared
this story with me. (The story also circulated on the Web for a while so you might have heard it already. If you
have, please bear with me. It is a fun way to make an important point.)
He said, "My friend asked whether I knew why the space shuttle rockets are built to their current dimensions. I
assumed it was because of some principles of rocket design. He said that the diameter of the rockets is
actually determined, or rather limited, by the fact that the rockets have to be shipped by train from Utah to the
launch sites. So the rockets have to fit on rail cars."
But the story doesn't stop there. Why are the rail cars built to the current dimensions? "Well", the student said,
"the train tracks in the U.S. were built by English engineers who used the rail standards they had learned in
England." The next question, as I'm sure you've guessed, was why the English standard had been set at that
particular measurement. "Trains came along after wagons, so the train engineers simply stuck to the standard
wheelbase measurements for wagons."
To shorten the story, the student told me that the wheelbase for the then-modern-day wagons was based on
the wheelbase of Roman chariots common in Britain 1,600 years earlier. The wheelbase for Roman chariots
was based on the fact that a chariot was pulled by two horses. So, just as the wheelbase of a chariot is based
on the width of two horses' behinds, so too is one of the leading technologies of our day, the space shuttle
rocket.
The moral of this factoid is that requirements, standards, and constraints for a project come from a variety of
sources. Some of those sources have their roots in history (wagon wheelbase), some in personal preference
(the English engineers using a familiar standard), and some in imposed limitations (rail car width).
Unless we make a specific effort to uncover the real requirements and have a way to document them that
makes them visible and testable, we run the risk of translating historical limitations, personal preferences, and
implementation limitations into requirements.
The use case approach may also address different levels of requirements:
Pie-in-the-sky brainstorming of the ideal features of the system
The goals of the system defined in terms of what real users of the system need to accomplish
The mechanics of the implementation of a model element. I do not recommend this level because there are
other UML tools, such as the various interaction diagrams and state machines, better suited for this purpose.
At each level, the goal of the Use Case diagram is to identify the critical success factors of the system, the features
that will make or break the success of the finished product. By identifying the system's features, you create a set of
conceptual slots into which can be placed a wide range of requirements such as performance, costs, transaction
volumes, number of concurrent users, throughput, and so forth.
Features can be modeled, designed, tested, and implemented. Users who require or support a particular feature
become the audience for the modeling activities for that feature. Focusing on features provides a number of
benefits. The feature list
Defines the scope of the entire project, that is, which features will and will not be supported by the final
product.
May be used to define the scope of each increment of the system, that is, what features should become part of
each release.
Focuses discussions with clients on specific requirements for specific behaviors of the system.
Identifies system interfaces to other enterprises, systems, components, or people.
Provides a framework for developing test plans at the beginning of the project, rather than waiting until the
end.
Use cases are sometimes perceived as being equivalent to the functional specifications created using the
Structured Analysis and Design technique, a procedural approach developed in the 1980s. The key difference
between use cases and the artifacts of a functional approach to analysis and design is the focus. A functional
artifact focuses on a process, but a use case focuses on the goal of a process. This change in mindset is essential
for keeping us from jumping to solutions (processes) without first understanding what we are trying to accomplish
with the solution (the goal).
Furthermore, focusing on the process often leads to simply reproducing existing systems in a new technology. By
the time the analysts and designers get a handle on how the current system works, their entire frame of reference
is immersed in the current system's way of doing things. The goal of redesign is to re-evaluate why the system
should be built, that is, why it has to perform this task for the user and why it has to produce these specific results.
Most goals may be accomplished through a wide variety of processes and technologies. In fact, this is the source
of so much frustration on projects-the time and money invested in researching alternatives. Without an accurate
understanding of the purpose of the system it is difficult, if not impossible, to measure the value of an alternative.
Goal-focused modeling keeps the target foremost in the minds of the people performing the research and
analysis. It also helps keep the research away from discussions about the solutions to achieve the goal. This helps
keep us open to consider a variety of solutions, enabling us, and possibly even encouraging us, to take advantage
of new options and ideas.
For example, in the theater case study, the theater has always done business through ticket windows. It was a big
change when they delegated these ticket windows to offsite agents. But still the process of selling tickets was
fundamentally the same. As business became more competitive the theater needed to find ways to make ticket
purchases more accessible to more people. At the same time, costs were becoming an increasing concern and
agent commissions were cutting into profits. The theater could continue to focus on how it sells tickets and try a
variety of ways to modify the existing practices at ticket windows. Or, it could focus on its goals:
To make buying tickets as easy as possible for end-customers. 1.
To reduce the cost of selling tickets. 2.
With these goals in mind, a number of practices and technologies that provide opportunities to meet these goals
can be evaluated. Each practice and technology can be measured in terms of how well it can help the theater
achieve these goals.
The point of this example is that we cannot measure the effectiveness of a process or design without having
something to measure it against. The Use Case diagram, and the entire use case approach, provides that
measuring stick.
In the next section, I discuss the features of the Use Case diagram and its most recent evolution. The shaded
areas in Figure 12-2 show the changes between UML 1.4 and UML 2.0. For now, I simply identify the changes. The
rest of this chapter is devoted to explaining these features and the changes introduced by UML 2.0.
Figure 12-2: Use Case diagram metamodel.
The changes include
The addition of a Constraint on the extend relationship.
Tightening of the definitions of the extend and include relationships to clarify the responsibilities of the
participating use cases.
And some relatively minor cleanup of the definitions for
ExtensionPoint. ExtensionPoint dropped the attribute location because the change in the definition of an
extension point to now be a single reference, rather than one or more references, made it mute.
An extension point was redefined from a type of model Element to a type of RedefineableElement, a
minor adjustment in terminology to improve consistency in the metamodel.
Use case. A use case is now considered to be of the type BehavioredClassifier. A BehavioredClassifier is
a subclass of Classifier, so it may have attributes and behaviors, may be associated with other model
elements, and may be generalized.
A use case may now also be associated with a Classifier that provides the context for the use case. The
classifier is the subject that is explained by the use case.
<Day Day Up>
<Day Day Up>
Defining the Use Case Approach
One of the first tasks in a project is to set the context and the scope of the proposed application. You need to
answer questions such as the following:
What functionality do we need to include and exclude?
How does this system relate to other systems in our architecture?
Who will use the system?
Who or what does the system depend on?
What products and/or results does the system provide?
Why do the users/other systems need the specific set of features that this system provides?
Then think of the system in terms of encapsulation, which asserts that to use an object, you need know only its
purpose and its interfaces, not its internal implementation. As long as the purpose and the interfaces of the system
remain unchanged, the internal functionality of the object or system may be replaced or enhanced without
affecting the entities that access the functionality.
So, the priority in defining a system is to define its purpose and the required interfaces. The purpose is the target of
the project justification. The interfaces are the channels of communication between the actors outside the system
and the features of the system itself, the use cases. Working inward from these fundamental requirements, each
feature provides the context for all subsequent modeling of the system's internal behavior.
The Use Case diagram provides the means to model the system in precisely this manner. The diagram consists of
six very simple graphics that represent actors and use cases, and the different types of relationships between
them, namely associations, include and extend relationships, and generalization. The goal of the diagram is
to provide an external view of the relationship between the system and the outside world. It is a very flat diagram,
providing only a surface-level, or black-box, view of the system. In a very real sense, the Use Case diagram is an
encapsulated view of a system.
CautionTechnically a Use Case diagram can represent the decomposition of a single use case, yielding a
hierarchical model. Beware! This approach can be confused with functional decomposition, an
approach that focuses on describing processes, the inner workings of an element. Use cases do not
describe the internal workings of anything. They are always an external view of an element. So in a
decomposition view, the use case describes a sub-element in terms of the purpose and the interfaces
that make it important to the success of the containing element.
For example, a system-level Use Case diagram for an ATM application would correspond roughly to the main
screen of an ATM, the menu options available immediately after passing the security interface. The ATM offers the
user a set of choices such as withdraw, deposit, inquire on balance, and transfer funds. Each option would be
represented by a separate use case. The customer (an actor outside the system) is associated with each of the
use cases (within the system) that he could use.
The simplicity of the Use Case diagram engenders both weaknesses and strengths. One weakness is the lack of
explanation. On the Use Case diagram, a use case is simply an ellipse with a label such as "Transfer Funds." It is
easy to put names like "Withdraw Money" and "Deposit Money" on a set of use cases and call it a system. But
doing so does not make it an adequate system definition. To address this challenge, the Use Case diagram is
usually accompanied by a set of use case descriptions, also called use case narratives. While the form of the
narrative is not standard, there are many helpful templates available (Alistair Cockburn's excellent book, Writing
Effective Use Cases (Addison Wesley Publishing company, 2000), for example).
One major strength of the Use Case diagram is that it frames the issues that affect the development of the subject,
be it a system, a subsystem, or a single component. Ensuring the successful development of the subject requires
a test plan. Examination of the use case narratives can identify use case scenarios. A use case scenario is a
description of a single path of choices in the execution of a use case, and it can form the basis for a test plan.
Together, these three elements-the Use Case diagram, the narrative/description, and scenarios-are the artifacts of
the use case approach to modeling a system.
<Day Day Up>
<Day Day Up>
Modeling Using the Use Case Approach
For tracking all of the modeling efforts in an enterprise, UML provides the concept of packages, containers that are
much like directories or folders. Packages store artifacts of the modeling process such as Use Case diagrams,
Class diagrams, and so forth. Packages may be decomposed into subpackages to form a hierarchy. When
modeling systems, a system is contained in a top-level subsystem package. Subordinate levels of the system are
contained in subsystem packages.
Cross-Reference A complete description of packages is in Chapter 14.
When modeling use cases, the standard stereotype for the topmost subsystem package is $useCaseSystem$.
Member packages within the $useCaseSystem$ are stereotyped as $useCasePackage$. Figure 12-3 models an
example from the theater case study in which the enterprise consists of a number of subsystems, including, but not
limited to, Marketing, Sales, Contract Administration, and Scheduling.
Figure 12-3: Use case model illustrated using a system hierarchy of packages.
In addition, UML defines a package stereotype called $useCaseModel$. The distinction between this and the
$useCaseSystem$ stereotype is a bit foggy (even UML says that they are synonymous). The three use case
stereotypes are defined as follows:
$useCaseModel$ "A use case model specifies the services a system provides to its users, that is, the different
ways of using the system and whose top-level package is a use case system." (UML 1.4) In other words, the
model package can be viewed as the folder that holds your whole project, including all artifacts such as
requirements documents, the top-level system package, and anything else you want to keep with the project.
$useCaseSystem$ and $usecaseSubsystem$ "A use case system is a top-level package that may contain
use case packages, use cases, and relationships." (UML 1.4) In other words, system and subsystem
packages contain Use Case diagrams that describe the system.
$useCasePackage$ "A use case package contains use cases and relationships." (UML 1.4)
CautionThe use case package information I include here is from UML 1.4, and does not appear in UML 2.0
documentation. It is not clear whether it has been dropped or simply was not documented.
<Day Day Up>
<Day Day Up>
Modeling the Use Case Diagram
Six modeling elements make up the Use Case diagram: actors, use cases, associations, include and extend
relationships, and generalization. These elements are illustrated in Figure 12-4.
Figure 12-4: Use Case diagram elements.
Actor: A role played by a person, system, device, or even an enterprise, that has a stake in the successful
operation of the system.
Use case: Identifies a key behavior of the system. Without this behavior, the system will not fulfill the actor's
requirements. Each use case expresses a goal that the system must achieve and/or a result that it must
produce.
Association: Identifies an interaction between actors and use cases. Each association becomes a dialog that
should be explained in a use case narrative. Each narrative in turn provides a set of scenarios that can help in
the development of test cases when evaluating the analysis, design, and implementation artifacts of the use
case and the association.
Include relationship: Identifies a reusable use case that is unconditionally incorporated into the execution of
another use case. Responsibility for the decision about when and why to use the included use case lies with
the calling use case.
Extend relationship: Identifies a reusable use case that conditionally interrupts the execution of another use
case to augment its functionality. The responsibility for deciding when the extending use case should be used
lies with the extending use case.
Generalization: Identifies an inheritance relationship between actors or between use cases.
1.
The construction of a Use Case diagram employs the following steps:
Define the context of the system:
1.1Identify the actors and their responsibilities.

1.2Identify the use cases, the behaviors of the system, in terms of specific goals and/or results that must
be produced.
1.
Evaluate the actors and use cases to find opportunities for refinement, such as splitting or merging
definitions.
2.
Evaluate the use cases to find include type relationships. 3.
Evaluate the use cases to find extend type relationships. 4.
Evaluate the actors and use cases for generalization opportunities (shared properties). 5.
Modeling actors
In UML, the term actor refers to a type of user. Users, in the classic sense, are people who use the system. But
users may also be other systems, devices, or even businesses that trade information. In Use Case diagrams,
people, systems, devices, and even enterprises are all referred to as actors. The icons to model them may vary,
but the concept remains the same.
Figure 12-5 models the most common icons for actors. People are typically represented using stick figures. Other
types of actors are normally represented with a rectangle stereotyped as an actor and named for the type of actor.
Figure 12-5: UML suggested icons for actors.
Any icon may be used to replace these. Figure 12-6 offers some alternatives. A company logo might represent an
enterprise. A cartoon image might represent a device. A graphic may be used to represent a system. Often, using
alternative icons in a modeling tool is as simple as importing the graphics to a specific directory.
Figure 12-6: Alternative actor icon examples.
Actors in a low-level use case may even be elements of the physical system, such as a class or a component.
An actor is a role that an entity, external to the system, plays in relation to the system. An actor is not necessarily a
specific person or system. For example, a person may act in the role of a venue manager scheduling a new event.
Later that day the same person might work on setting up the pricing for a series of performances. The same
person can play two different roles, and therefore can function as two different actors when interacting with the
system. Likewise, many people can function in the same role. For example, many people function as agents for
the theater, all performing the same set of duties and having the same relationship with the theater's system.
Using roles helps keep you focused on how the system is being used rather than on the current organization of job
titles and responsibilities. The things that people do should be separated from their current job titles if the system is
to be able to cope with the changes that are inevitable in any organization. In fact, reevaluating roles in an
organization often provides valuable insights into improving job descriptions.
How do you identify actors? Listen to descriptions of the system. Listen for the ways in which people interact with
the system. Ask why they are using the system in that manner. The answer to the why question often describes a
duty they are performing that supports a function or the creation of some result. When multiple people perform the
same function, try to name the role that they all play while performing the particular function.
TipThroughout the modeling effort, the vocabulary of the users will reveal most of the key elements of the
model. Watch for how parts of speech translate into model elements; actor names often show up as the
subject in sentences describing how people use the systems.
Initially actors are modeled as communicating with the system behaviors, the use cases. As the project
progresses, use cases are realized or implemented by classes and later components. As the project progresses,
actors also evolve. Instead of representing roles that people perform, they transform into the user interfaces that
people playing these roles use to interact with the system. For example, in the system-level Use Case diagram, a
Customer actor buying seats to a performance at the theater interacts with the PlaceOrder use case. In the design-
level Use Case diagram, the actor becomes two elements: the role of customer, and a user interface used by a
customer. The use case becomes one or more objects that manage the behavior of the application to interact with
the user interface and the rest of the system.
This relationship between the high-level description in the use cases and the low-level description in the design
and implementation models provides traceability.
Traceability describes how a requirement can be identified in the beginning of the project and followed through its
evolution to its ultimate implementation. Traceability helps insure that requirements are not lost or corrupted during
the development.
Furthermore, project members working at the enterprise level can use the same tools to describe requirements as
the members who work on the detailed design of the system components. Changes made on one level more
easily translate to changes on other levels, improving communication and coordination of project tasks and
deliverables.
Actor descriptions may also be refined using generalization. Conceptually the process of refinement of actors is
the same as for classes. Actors have a purpose and one or more interfaces. Evaluation of the similarities and
differences between actors can identify opportunities to merge, and to specialize, their descriptions.
For example, in Figure 12-7, the VenueManager actor is responsible for scheduling. However, interviews with our
clients reveal that only certain venue managers have the authority to reschedule performances and events.
Rescheduling can influence customer relations, and may involve the decision whether or not to offer refunds. The
two roles have a lot of similarity, and few differences. So, a second actor, ExecutiveVenueManager, is defined to
describe the higher level of authority. An executive venue manager has (inherits) all of the responsibilities of a
regular venue manager, plus a few unique to the executive role.
Figure 12-7: Using generalization to refine the definitions of actors.
Generalization may be used for more than just a single specialization, as in the venue manager example. For
example, in the original system description a customer is defined as someone who is interested in purchasing
tickets for performances at the theater. The definition of a customer includes people who have already purchased
and those who simply want to browse but don't yet know if there is anything they want to buy.
While working on the purchasing rules, we discover that some customers have access to special pricing that other
customers do not, and that some customers are extended a line of credit, while others are not. The rules also draw
a distinction between customers who are individuals and customers who are companies (corporate customers).
Figure 12-8 models a generalization structure for customers. At the top is a basic definition of the customer actor.
Below that, and attached by generalization relationships, are the specializations of the customer actor (role).
Figure 12-8: Using generalization to refine the definitions of customers.
Modeling use cases
A use case defines a behavioral feature of a system (or enterprise, subsystem, and so on). Without these features,
the system cannot be used successfully. Each use case is named using a verb phrase that expresses a goal the
system must accomplish. For example, use cases for the theater system include Create Agent Contract,
Reschedule Show, and Schedule Event. Although each use case implies a supporting process, the focus is on the
goal, not the process. Figure 12-9 illustrates notations for use cases. The name may appear inside or outside of
the ellipse.
Figure 12-9: Use case notation alternatives.
One very common question about use cases is, "What requirements belong on the Use Case diagram and what
requirements should be explained elsewhere?" The simplest answer I've found is to model only the behavioral
features of the system that can be seen by an actor. For example, most systems must save data to a database, but
the actors can't actually see this happening. The most they typically see is a message indicating that the system
did, or did not, save their data. In this situation, the use case-level requirement is a message indicating the success
or failure of the save function, not a description of the save process. The implementers can use the success or
failure message as a requirement that defines the type of information that needs to be produced by the process
used for saving the data.
This applies even though use cases might describe different levels of detail. A use case drafted at the enterprise
level would describe interactions with people or other companies, while those drafted at the component level might
describe operations on a class, or a set of operations performed in sequence. Regardless of the level, the focus is
on the purpose and interfaces of the entity, not the implementation. The sequences of actions performed by a use
case are the interactions with the actors, not the internal processes.
By defining use cases in this manner, the model defines a set of requirements, not a solution. It does not describe
how the system must work. It describes what the system must be able to do. For example, when I decide that the
theater is going to contract with agents, I define what it means to successfully complete negotiations with an agent.
In our theater example, the result of this system feature is a complete contract (with the term "complete" fully
defined) and a set of zero or more sales agreements that define what seats they are allowed to sell for discrete
periods of time within the contract.
The solutions for achieving these results could include manual processes and a simple data-entry feature, support
for automated calculation of projected commissions (for the agent) and profitability (for the theater), or even
interactive, Internet-based collaboration between venue managers at the theater and agents at remote locations to
negotiate and finalize the terms of the contract. The merits of each of these alternatives would have to be
measured against
How well it satisfies the established objectives (the desired results of the use case). 1.
How well it can be supported within the constraints for the project (performance, cost, time to deliver,
quality, and maintainability).
2.
Keeping these two principles in mind (goal-oriented definitions and an actor-centered perspective) will help you
avoid functional decomposition, the breaking down of procedures and tasks into smaller and smaller processes
until you have described all the internal workings of the system.
CautionOne of the pitfalls of systems development is going over budget, which happens when we don't limit
the scope of each task or we make a model too inclusive. UML provides 12 other diagrams, in
addition to the Use Case diagram, for fully describing the solution for a system. You don't have to
explain everything in the Use Case diagram.
The complete set of use cases for an entity describes all of the behaviors of that entity. Such a list can be large. To
organize modeling information, UML provides packages, which function like directories. Use cases pertaining to a
category of behaviors may be grouped together within a package for ease of use. For example, within the theater
there are many functions, some related to marketing, others to scheduling, and still others to contract
administration and to sales. Packages provide a means to scope information and effort. Information of a given type
may be kept together, separated from other topics. This means that those who need the information to implement
the topic have a single, well-identified place to look for the information. Figure 12-10 models the subsystems of the
theater system in a Package diagram.
Figure 12-10: Package diagram for the theater example.
The packages here are the same packages modeled in Figure 12-3. In Figure 12-3, the packages are modeled
from the perspective of package containment. Here, the model emphasizes package dependencies rather than a
containment hierarchy.
Use cases may also be viewed much like the services provided by classes or states. That is, services may be
provided or required. A use case may provide or offer a service to an actor. An offered service is triggered by the
user and implemented by the use case. For example, a use case could query the scheduled performances at the
theater, or complete a ticket purchase. In an offered service the actor is making a request of the system. The
system is responsible for fulfilling the request by asking for input, enforcing integrity rules, and managing the
information.
A use case may also require a service from the actor. For example, a use case might support entering mailing or
contact information, or entering contract details. In this type of use case, the system depends on the actor to
provide all of the information. It functions a bit like a getSomeInfo() call from the system to the actor.
Both types of use cases may be implemented in the form of a dialogue between the actor and the system.
Finally, use cases often reflect a business entity's need to manage resources. Managing resources includes
acquiring, using, and disposing of those resources. The business often reports on the status and use of the
resource throughout the life of the resource. These tasks have been summed up in a humorous acronym CRUD,
for Create, Read, Update, and Delete. CRUD can be a checklist to remind you of the tasks to consider when
brainstorming use cases.
Since the CRUD behaviors are so common, you can save yourself a lot of work by combining them into one or a
few use cases that provide all the maintenance features related to the resource. You might also find that the
dependencies between resources require you to maintain them together in the same use case.
Be careful not to follow the CRUD checklist too literally. Consider that a resource might be acquired (created) in
many different ways. It might be queried (read) from a variety of perspectives. A resource can be altered (updated)
in many ways. A resource may be disposed of (deleted) in many ways, too. Each different way of interacting with
the resource might reveal the need for a different use case.
So, a good approach is to brainstorm the use cases with the CRUD checklist as a starting point. Then evaluate
what you find and consolidate where it makes sense from the users' perspective and where the rules that govern
the resource make it prudent to do so.
Adding classifiers
UML 2.0 adds an association, in the metamodel, between a use case and a classifier. Classifiers may be classes,
associations, collaborations, interfaces, and more. A classifier is basically an entity that can own behaviors. A use
case describes a behavior. Consequently, a classifier may own, or be described by, any number of use cases.
Figure 12-11 highlights the modification to the metamodel, making use cases an optional owned element of a
classifier. This relationship means that the classifier provides the context for the use case.
Figure 12-11: Metamodel update supporting classifier ownership of use cases. $OMG 2.0
An enterprise might own dozens of use cases organized into a hierarchy of subsystems. A class might have a use
case for each interface. A collaboration may be represented as a single use case or a hierarchy of use cases,
depending on the level of the collaboration description.
Alternately, a use case may be used to explain the behavior of more than one classifier. This highlights the UML
emphasis on encouraging reuse. Reuse is valuable not only in the code, but in every artifact of the development
cycle, from requirements through implementation.
Modeling associations
An association is a relationship between an actor and a use case. It is an instance of the same Association
metaclass used to model relationships between classes on a Class diagram. The relationship is represented by a
line between an actor and a use case. The association represents the fact that the actor communicates with the
use case. In fact, in earlier versions of the UML specification, the line was called a Communicates With
relationship. This is the only relationship that exists between an actor and a use case. Figures 12-12 and 12-13
model associations between the customer actor, the agent actor, and the use cases with which they each interact.
Figure 12-12: Modeling associations between agents and use cases.
Figure 12-13: Modeling associations between customers and use cases.
Notice that different actors may access the same use case. This typically means that they interact with the use
case in different ways. If their interactions are identical, it might mean that their roles are the same. I emphasize
might because the purpose of two interactions also has to be the same in order to merge them. For example, in
Figure 12-13, a person in the customer role uses the PlaceOrder use case because he wants to place an order for
himself. In Figure 12-12, the agent uses the PlaceOrder use case because she is helping a customer place an
order. The result is the same in both cases; an order is created for a customer. But the relationship to the result is
different. The completed order belongs to the customer in both cases, but the person who entered the order is
different.
TipSome tools, like Rational Rose, place a navigation arrow on one end of the association (depending on the
direction you draw it). All of the details of the interaction between an actor and a use case are explained
either in the use case description or in Sequence diagrams. So the navigation arrow does not provide any
additional information. Modeling tools typically provide the option to turn the navigation arrows on or off.
The important thing to remember is to identify what use cases the actors need to access. These
connections will form the basis for the interfaces of the system and subsequent modeling efforts.
Use case associations may also be adorned with multiplicity. Despite the many times I have seen multiplicity used
in Use Case diagrams, I have never seen a good explanation for why to use it or what it adds to the model. To
reiterate, all of the details of the relationship between the actor and the use case are explained in either the use
case description and/or a set of Sequence diagrams and/or collaborations modeled within Composite Structure
diagrams.
Modeling use case relationships
Use cases define discrete behaviors. It is possible for a system to use the same behavior under a variety of
circumstances and as part of many larger, more comprehensive behaviors. In other words, behaviors can be
reused; and we need some notation to show that use cases can be reused. UML defines two standard stereotypes
to represent two common use case relationships: include and extend.
The include relationship
While researching systems it is common to find a behavior that can be performed under many different
circumstances. In code, we tend to make reusable components such as class libraries, utility classes, subroutines,
and functions that we can simply reference or call from within other code. UML supports the same practice when
identifying common features in the use case approach.
The include relationship is analogous to a call between objects. One use case requires some type of behavior.
That behavior is already fully defined in another use case. Within the logic of the executing use case, there is a call
to the previously defined use case. The distinguishing characteristic of the include relationship is that the
decision to incorporate the second use case is in the calling use case. The called use case is unaware of the
calling use case and has no participation in the choice to execute.
Included use cases can be identified in at least two ways. Included use cases might be pre-existing. They are
defined for one purpose, but in the development of another use case, the same behavior is required. Rather than
define the behavior again within the new use case, the behavior can simply be included in the logic of the new use
case. Another way to identify included use cases is to pull functionality out of existing use cases to form a new use
case. This happens most often when merging use cases from the efforts of multiple developers. When comparing
their work, they find the same behaviors defined within a number of their use cases. One option is to pull those
behaviors out, encapsulate them as discrete use cases, and then replace their former location within the use case
description with a call to the new use case using the include relationship.
To use the include relationship, the use cases must conform to two constraints:
The calling use case may only depend on the result from the called use case. It can have no knowledge of the
internal structure of the use case.
The calling use case must always require the execution of the called use case. The use of the called use case
is unconditional.
Figure 12-14 models two include relationships:
Figure 12-14: include notation for the Use Case diagram.
Between PlaceOrder and SelectPerformance
Between PlaceOrder and SelectSeats
Figure 12-14 shows how the include relationship is modeled as a dashed open arrow pointing from the calling
use case to the called use case- from PlaceOrder to SelectPerformance, for example, where PlaceOrder calls the
SelectPerformance use case. The direction of the arrow helps to reinforce visually that the call is initiated by the
use case at the base of the arrow.
This example tells us that when a customer interacts with the PlaceOrder use case, he will always be asked to
select a performance and to select the seats at that performance that he wants to order. The diagram does not tell
us when, in the execution of use case, the calls will be made, or even the order of the calls. For those details we
need a use case narrative.
Note that both the SelectPerformance and SelectSeats use cases may be called independently of the PlaceOrder
use case. These are examples of using an existing use case in the context of another use case. A customer can
simply look up performances or seats at a performance without placing an order.
The extend relationship
The extend relationship says that one use case might augment the behavior of another use case. The extension
use case provides a discrete behavior that might need to insert itself into the base use case. The arrow is drawn
from the extension to the executing use case. Drawing the arrow with the base at the extension use case indicates
that the extension, not the executing use case, decides whether to impose itself on the executing use case. The
executing use case is unaware of the extension.
This might sound strange at first, but consider the impact on changes to the system. As the base use case evolves
and new extensions are developed, the base use case does not have to be changed with each new or revised
extension. In this respect, the extend relationship functions much like the observer pattern. That is, the extension
watches for circumstances that would require it to jump into the execution of the base use case. Using extensions
enables us to leave the base use case untouched while freely adding behaviors as the system evolves.
The extend relationship is modeled in Figure 12-15 as a dashed stick arrow from the extension use case to the
base use case. The direction of the arrow helps to reinforce visually that the call is initiated by the use case at the
base of the arrow. The extension use case decides when it is time to execute. The base use case has no part in
the decision.
Figure 12-15: Notation for the extend relationship.
Applying an extend relationship requires four elements:
The base use case: The use case that will be augmented by the extension use case (the RescheduleEvent
use case, for example).
The extension use case: The use case that provides the added behavior (CancelPerformance and
ReschedulePerformance are extension uses cases in this example).
The extend relationship: A dashed arrow with the base attached to the extension use case and the arrow
attached to the base use case.
Extension points: One or more locations in the base use case where a condition is evaluated to determine
whether the extension should interrupt the base use case to execute. The extension points may be listed within
the use case icon or simply identified within the use case narrative.
The extension point is a condition that determines whether the extension should be used. There is no such
condition in an include relationship. The extension point defines what the extension use case is watching for in
order to know when it needs to insert itself into the executing use case.
For example, an extension point may be an error condition. During a PayForOrder use case, for instance, the
connection to the credit card company could be down. The base use case would trigger an error to the system. It
would be up to the extension use case to watch for the error and to execute (that is, handle the error) when the
error occurs. Once it completes, the extension would notify the system and the base use case would be allowed to
resume execution from the point where it was suspended.
CautionThe extend relationship can be confusing for Java programmers who use the extends keyword on a
class declaration to define an inheritance relationship. These two concepts have nothing in common.
UML provides a separate notation for inheritance/generalization.
The extension point notation is added inside the use case ellipse in the following format:
<extension point> ::= <name> [: <explanation>]
(Note that not all tools use the recommended format, as can be seen in Figure 12-15 where only the explanation is
used.)
The name follows the normal rules for identifiers and describes a location within the logic of the use case. Since a
use case describes a behavior, the location is often a state of the object some time during the execution of the
behavior. The explanation, which is optional, may be any informal text adequate to describe the condition that
governs the execution of the extending use case. Figure 12-16 models the notation for an extend relationship,
adding the extension point explanation in a compartment below the name within the use case ellipse.
Figure 12-16: Extension point notation using a comment.
Extension points may also be documented in a comment attached to the extend relationship, as shown in Figure
12-16. The comment uses a page icon with the top right corner folded down. It contains the condition that the
extension is watching for and the label (extension point) that identifies the location in the base use case where the
decision would take place. In this example, the condition tests to see whether both the start and end dates
changed. It is possible that only one of the dates changed, in which case no performances would be rescheduled.
They would either be deleted (if the start date moved later or the end date moved earlier) or added (if the end date
moved out). The comment is attached with a binary constraint line, a fancy name for a dashed line connecting two
model elements.
Yet another approach to modeling extension points is to represent a use case as a class or object, as shown in
Figure 12-17. The extension points may then be listed in a user-defined compartment. The ellipse in the top right
corner of the name compartment identifies the class as a use case.
Figure 12-17: Using class notation to model a use case with extension points.
In this example, there are two extension points. The first was modeled in Figure 12-15 between
ReschedulePerformance and RescheduleEvent. The second extension refers to the relationship between
CancelPerformance and CancelEvent in Figure 12-15.
In addition to the condition that defines when an extension is needed, the extension use case may itself be
conditional. The condition attribute on the extension use case functions as a Constraint. If the constraint expression
is satisfied when the extension point condition is true, the extension use case will execute. For example, if the
extension point "event moved" is true, the extension use case will test its constraint "reschedule performances
authorized". If this further constraint is satisfied, the extension use case will execute, otherwise it will not.
The contrast between include and extend relationships is sometimes confusing. Table 12-1 sets them side by
side to highlight the similarities and differences.
Table 12-1: Include versus Extend
Include Extend
Augments the behavior of the base use case. Augments the behavior of the base use case.
The included use case is always used to
augment the executing use case.
The extension use case might be used to augment the
executing use case.
The executing use case decides when to call
the included use case. The included use case is
unaware of the base use case.
The extension use case decides when it will insert
itself into the execution of the base use case. The base
use case is unaware of the extension.
The relationship arrow is drawn from the
executing use case to the included use case.
The base of the arrow indicates that the base
use case directs the included use case to
execute.
The relationship arrow is drawn from the extension use
case to the executing use case. The base of the arrow
indicates that the extension use case is making the
decision whether to interrupt the executing use case.
<Day Day Up>
<Day Day Up>
Writing a Use Case Narrative
A Use Case diagram is very descriptive of the relationship between the actors and the features of the system, but it
lacks the details needed to support the system behaviors. A use case narrative is a written document that explains
a use case is a behavior of the system with a beginning (trigger), middle (dialog), and end (termination). To do so,
the use case narrative often includes the following elements.
Assumptions
Preconditions
Use case initiation/triggers
Dialog
Use case termination
Post conditions
And a couple of interesting alternative concepts:
Minimal guarantees
Successful guarantees
The names may be different in various methods but in general the same details are covered. In addition to these
main items, it is common to find audit details such as update logs, status, author, unique identifier and/or name,
open issues, future enhancements, and more. There is nothing standard about these items. Many people have
contributed to the concepts and many people use entirely different approaches. Here I present what I believe to be
the minimum concepts that can make or break the use case definition.
Much of this language is borrowed from the programming by contract concept developed and implemented by
Bertrand Meyer in the creation of the Eiffel programming language. One chief goal of the programming by contract
concept is that each relationship, whether between actors and use cases, or between different use cases, should
be described much like a contract. A contract states terms to which both parties must comply. If one party fails to
comply with its part of the contract, then the other party is not obligated to fulfill its part of the contract.
Each unit should remain as loosely coupled as possible. Loosely coupled entities are connected in such a way as
to minimize their dependence upon one another. Unit independence allows each unit to be maintained without
requiring corresponding changes in the other unit (or at least the fewest changes possible). Loose coupling
reduces the time and cost required to develop and maintain the system.
Assumptions
In order for a use case to work properly, certain conditions must be true within the system. The system agrees, or
contracts, never to invoke the use case unless it knows that all of the needed conditions have been met.
Assumptions describe a state of the system that must be true before the system may use the use case. These
conditions are not tested by the use case; the use case simply assumes them to be true. (Contrast this with
preconditions, which I take up later).
For example, consider authentication and authorization. A standard security feature typically handles these
functions. Each subsequent use case assumes that the user could not be accessing the use case had she not
made it past the security check. Consequently, you would rarely, if ever, include the security check in each use
case.
So how does this help you with the design of the system? Well, if one use case can't work, and should not even be
accessed, unless another use case has first done its job, then this condition dictates the order of execution. In
other words, the assumptions give you explicit clues about the sequence of execution, or the workflow, for use
cases.
An assumption for the Select Show Seats use case might read:
Assumption: The user must have authority to access this transaction.
TipThe Select Show Seats assumption provides a simple example that is almost too common. If an
assumption such as this one appears in many use cases, it can be redundant and tedious to document.
Instead, document it at the system level, in a document separate from the individual use cases.
Workflow is often established by interviewing users to find out how they do their jobs. A liability created by this
approach is that it brings the focus back to the process the users currently apply instead of the goals and the rules
that define success. In a very generic example, Figure 12-18 represents the assumptions for a set of use cases.
Use Case 3 assumes that use case 1 has completed its task. Use Case 4 assumes that Use Case 2 has
completed its task. The current workflow (shown on the left) dictates that the order of execution is 1, 2, 3, and 4.
But is that really the only option given the documented assumptions?
Figure 12-18: Evaluating assumptions to establish workflow options.
Would it not be equally valid to perform use cases 2 and 4 concurrent with 1 and 3 since they have no
dependencies? Or how about a workflow that executes in the order 1, 3, 2, and 4? The point of the example is that
workflow options are often more flexible than we might at first realize. Evaluate the true dependencies and
discover the available alternatives. It might open doors to more efficient work practices.
Granted there might be other factors involved in the final decision regarding workflow. But assumptions provide a
very specific and valuable insight into the hard dependencies that constrain workflow options.
Preconditions
Like assumptions, preconditions describe a state of the system that must be true before you can use the use case.
But unlike assumptions, these conditions are tested by the use case before doing anything else. If the conditions
are not true, the use case will not execute.
If you have a programming background, you have probably already encountered preconditions even if you didn't
call them by that name. Whenever you call a behavior (function or operation) that has parameters, the first section
of code in the behavior checks the values of the parameters. If any of the values fails to pass the validity checks,
the request for the behavior is rejected. Simply stated, the behavior cannot work with bad information.
The same is true of a use case. For example, when placing an order at the theater, you need to invoke the use
case to view the seating chart and select seats at a performance. If you don't first decide what show you want to
view, the use case cannot pull up the right seating chart. Furthermore, if you choose a performance that has
ended, or is not in the appropriate status, then the use case should not allow you to view the seating chart.
Preconditions for the Select Show Seats use case might read:
Precondition: The requestor must provide a valid Performance reference. A valid performance is defined as
a performance in Available for Sale status.
The preconditions need to be published along with the interface to your use case, and later to the interface of the
class or classes that implement the use case. This is because the implementation interface only tells the client to
send two integers and a character string. It can't tell them, for example, that the first integer must be a value
between 1 and 10, the second must be an integer greater than 100, and the character string can only be 30
characters in length. By publishing these preconditions, anyone who wants to use your use case (or object) is sure
of the correct set of values and is able to fulfill his part of the contract, providing good input values with his request.
TipNotice how rapidly we bring precision to the model from the simple beginnings of the Use Case diagram.
You'll find the analysis process akin to pulling a thread on an old sweater. If you keep tracking down each
new discovery, eventually you'll unravel the whole complex problem. Using simple checklists to remind you
of the questions to ask can expedite the process and build a successful pattern of thought for problem
solving. As you gain experience, modify the list of questions and tasks to improve the process and to make
it your own.
Remember, the goal is not to become a disciple of a particular technique, but to evolve a technique that
works for you.
Use case initiation/triggers
A use case has to start somehow. Use case initiation simply identifies how. For example, a use case might start
because
An actor selects an option on a menu.
A time alarm goes off.
A device or another system sends a signal.
A specific system condition occurs.
Any of these events would start (or trigger) the use case, so they are often called triggers. The use case triggers
for the Select Show Seats use case might read:
Trigger: The user selects the Select Show Seats option from the menu.
Trigger: PlaceOrder invokes SelectShowSeats.
In the first example, a user accesses the use case directly to see what seats are available. In the second example,
another use case invokes SelectShowSeats as part of the dialog for placing an order.
Use case initiation provides a place to think through all the possible triggers that could launch the use case. This is
critical when you start thinking about reusing use cases. If five actors and/or use cases plan to use the same use
case, you need to know how each user plans to kick it off. If each has different expectations, you could be creating
a problem. Multiple triggering mechanisms lead to tight coupling and low cohesion. In other words, every time you
change one of the triggers you need to change the corresponding use case and make certain that you haven't
created problems with the other triggering mechanisms. More triggers mean more complicated and more costly
maintenance.
Use case dialog
The use case dialog refers to a step-by-step description of the interaction between the user (an actor or another
use case) and the executing use case (the system implementing the use case). Very often, it is helpful to model
this sequence of events using an Activity diagram, or an Interaction Overview diagram, just as you might model a
procedure for communication between two business units.
Granted, some use cases are simple queries with a request as input and a response as output. In fact, a use case
may be triggered by an event within the system and simply send a signal to an actor. But for those use cases that
are a bit more complex (an online transaction, for example), the dialog helps to identify clearly the responsibilities
of each participant and the expectations the users have regarding how they interact with the system to accomplish
the goal/s defined by the use case.
For example, when an actor invokes the SelectShowSeat use case, the following dialog ensues.
NoteThe first step in the dialog is to test the preconditions because those preconditions are a responsibility of
the use case (as opposed to assumptions, which are the responsibility of some other use case).
The system verifies that the user provided a valid Performance reference. A valid performance is defined as
a performance in Available for Sale status. If the test fails, the actor is informed of the failed request and
directed back to the menu or to the option to select a performance (outstanding issue for the clients to
decide).
1.
The system provides default lists of all currently scheduled events and performances scheduled within the
next 20 days.
2.
The user may choose one of the following options:
Cancel out of the transaction. a.
Select an event. The system responds by replacing the existing list of performances with a list of
performances for the selected event.
b.
Select a performance. The system responds by asking the customer to confirm his request. The
actor may either confirm or reject the choice. Rejecting the choice allows him access to the original
list of options. If the actor confirms the choice, the system saves the selected performance. The
system provides confirmation before terminating the use case.
c.
Provide a date range. The system responds by replacing the existing list of performances with a list
of performances for the selected date range.
d.
3.
If the system is interrupted during the use case, no action is required of the use case. The system provides
confirmation before terminating the use case.
4.
When the dialog is defined separately from the implementation, you can evolve the implementation without
affecting the participants, because the interface (the way they communicate) remains stable. For example, this
conversation could just as easily have taken place between a customer and clerk at the theater ticket office,
between a customer and an agent over the phone, or between a customer and the system over the Internet. Also,
you begin to see that some of the steps don't necessarily have to happen in the sequence presented here. The
goal of the dialog is to uncover just what really must happen in a specific sequence. Based on those facts, it is
easier to determine what variations could be valid.
Use case termination
Although there is usually only one triggering event to start a use case, there are often many ways to end one. You
can pretty much count on some kind of normal termination where everything goes as planned and you get the
result you anticipated. There may even be more than one successful termination. But things do go wrong. This
could mean shutting down the use case with an error message, rolling back a transaction, or simply canceling the
transaction. Each termination mechanism in the list of termination options should be addressed in the use case
dialog. The list is separate from the dialog but part of the complete narrative.
The list of termination options is a bit redundant with the dialog, but as with preconditions, this redundancy provides
some good checks and balances. The termination options list for the SelectShowSeats use case would look like
this:
Success:
A performance is selected and saved. The transaction is logged.
The actor cancels without making a selection. The transaction is logged.
Failure:
The precondition tests false. The actor is informed of the failed request and directed back to the menu or
to the option to select a performance (outstanding issue for the clients to decide).
The system is interrupted. No action is required outside of the default behavior (resetting the application
to the menu).
Post conditions
Post conditions provide the system portion of the contract. Post conditions describe
What the system must do if the preconditions are satisfied.
The state that the system must be in when the use case ends.
Workflow Requirements
A common question about use cases is, "How do I show workflow or screen flow?" The short answer is that
you don't. A more appropriate question would be, "How do I use the use cases to determine screen flow and
workflow requirements?"
Workflow is often a difficult problem in system design. Personal opinion, personal preferences, and legacy
processes often get included as requirements (remember the rocket story)? Business practices are prone to
faulty assumptions and unquestioned repetition. New systems often contain the same deficiencies that the old
ones had because they were not critically evaluated.
To determine workflow, check out the preconditions and assumptions. If one use case requires the user to
provide data that is the result of a second use case, or even multiple use cases, or do something that another
use case is responsible for, then logically, the second use case must come first.
These clues are a tremendous help when you recognize that many workflows were designed based on user
preferences or experience and have not been checked against the rules and constraints that define the
successful operation of the system (assumptions and preconditions). Assumptions explicitly define the
precedence dependencies between use cases that ensure that all the rules and constraints will be enforced.
Quite often, screen flow and workflows are far more flexible than you might think. Let the use case
assumptions and preconditions tell you what the flow options are. Then design the workflows that are possible,
letting the users decide what works best for them.
You may never know what comes after the use case terminates, so you must guarantee that the system is in a
stable state when it does end. In fact, some people use the term guarantee for just this reason. You guarantee
certain things to be true when this use case completes its job. For instance, you might
Guarantee to give the user a confirmation at the end of the transaction, whether it succeeded or failed.
Promise to notify the user of the result of an attempted save to the database.
Log every transaction.
There is overlap between the post conditions and the dialog. Although this overlap is a bit redundant, the added
visibility of the post conditions has proven to be an excellent check-and-balance mechanism as well as very helpful
in reviews with clients who want to know how the system will behave under every situation. In fact, it can sometimes
work best to define the termination options first, and then address how the dialog would bring about each option.
Minimal guarantees
I have found two additional ways to look at use case requirements: minimal guarantees and successful
guarantees. Both concepts come from Alistair Cockburn's book, Writing Effective Use Cases, which brings this
important facet of analysis to the forefront. These methods are very comparable to post conditions except that they
break the conditions down a bit more and speak directly to the interests of the users. According to Cockburn.
The minimal guarantees are the fewest promises the system makes to the stakeholders, particularly when
the primary actor's goal cannot be delivered. They hold when the goal is delivered, of course, but they are of
real interest when the main goal is abandoned. Most of the time, two or more stakeholders have to be
addressed in the minimal guarantees, examples being the user, the company providing the system, and
possibly a government regulatory body.
He goes on to say that the most common minimal guarantees include activities such as logging the results of the
transaction. Logging is often a background task that can provide valuable information about why a transaction
failed, how the failure was handled, and how the system was restored to a stable condition to prevent cascading
effects on other transactions or on other parts of the system.
The proper use of minimal guarantees can be particularly valuable because it brings these important issues to the
front of the project where they can be handled strategically. When they are not addressed up front, they are often
addressed tactically by individual developers who encounter the issues when writing the code. As in nearly all
modeling concepts, the goal is to protect the integrity of the system at all times, and to protect the interests of the
users.
Here's an example of a minimal guarantee for the PlaceOrder use case:
Minimal guarantee: If the order is incomplete, all selected seats must be returned to available status, the
order deleted, and any charges to the customer's credit card reversed. The reason for the incomplete order
is recorded, such as the type of system interrupt (failure) or a user canceling the transaction.
Success guarantees
Success guarantees function like minimal guarantees but they have a different focus. Minimal guarantees focus
on the "no matter what happens" view of the use case. Success guarantees focus on what must be true when
everything works properly. Cockburn says of success guarantees:
The success guarantee states what interests of the stakeholders are satisfied after a successful conclusion of the
use case, either at the end of the main success scenarios or at the end of a successful alternative path. It is
generally written to be added to the minimal guarantees: The minimal guarantees are delivered, and some extra
conditions are true; those additional conditions include at least the goal stated in the use case title.
Here's an example of a successful guarantee for the PlaceOrder use case:
Minimal guarantee: If the order is completed successfully, then the order is saved, the seats at the show are
updated to Reserved status and associated with the order, the customer's credit card is charged for the total
order, and the credit card information is deleted. The transaction is logged with applicable stats for reporting
transaction duration and amount.
<Day Day Up>
<Day Day Up>
Describing Use Case Scenarios
Scenarios describe each possible outcome of an attempt to accomplish a use case goal. A use case identifies a
primary goal of the system. When an actor attempts to accomplish a goal using the system, there are usually
decisions and rules that influence the outcome of the use case. For example, the user may be able to choose from
a list of alternatives, or exception conditions may hinder the accomplishment of the goal.
A scenario is a single logical path through a use case. UML even defines a scenario as an instance of a use case
in that a scenario is one realization, or execution, of the conceptual use case. In other words, a use case defines
what could happen, and a scenario defines what does happen under a given set of conditions. A scenario may be
modeled using a Sequence diagram.
CautionThe word scenario is used a number of ways. In the context of UML use cases, scenarios have a very
specific meaning. Be careful not to confuse the more general usage of the term scenario, as an
example or situation, with the explicit definition used here.
There are many ways to work with scenarios. You can simply read the narrative and extract each logical path from
the text. You can draw out the logic with an Activity diagram so that the flow of logic can be visualized and more
easily segmented. Whatever the means, the scenarios start to reveal the inner workings of the system and the
expectations of the users in a way that the use case alone cannot. This closer look can open doors to further
analysis of the system and ultimately to the design.
Probably the key lesson in scenarios is the necessity of tackling the important questions and issues early, when
you have the best chance and the most time to come up with options and solutions. All too often, project teams
leave these questions until they're working on the code, when many of the big issues are easily lost in the mountain
of details. This causes the requirements to wind up being expressed only as code (rather than in prose), which is
alien to most users and difficult for them to evaluate.
Why you should care about use case scenarios
In some situations a use case is simple enough that the narrative is more than ample to explain all the issues that
define its proper execution. But in many other use cases, the logic can become troublesome. Many of the
applications we work on today are complex and require significant scrutiny.
In addition to addressing complexity, we need some way to test the accuracy and completeness of the use cases.
Unfortunately, for many projects, developers often hold off testing until the end of the project, when they're short
on time and focused on the solution rather than the requirements. Or worse yet, there is no time for testing at all,
so final testing happens in production.
Speaking of requirements, did you know that the overwhelming majority of litigation regarding software projects is
based on misunderstandings over requirements? In a recent abstract, Capers Jones, of Software Productivity
Research, had this to say:
The clients charge that the development group has failed to meet the terms of the contract and failed to
deliver the software on time, fully operational, or with acceptable quality. The vendors charge that the clients
have changed the terms of the agreement and expanded the original work requirements.
Furthermore, the problems that Jones refers to here are on projects where there i s a contract. Consider how much
worse the situation can become where the requirements process is less formal!
If you've ever worked in a quality-assurance group, or even worked with one, you know how frustrating the tester's
role can be. Think about how the tester's challenge changes when she's able to create a test plan at the beginning
of the project instead of waiting until the end. Then testing can take place in small increments throughout the
project instead of in a massive, difficult, and frustrating process at the end (if there is time to test at all).
This is why scenarios have taken on an increasingly important role in the requirements phase. What happened to
other tools such as screen layouts and prototypes? They are still valuable, and can provide a great way for users
to visualize what you are trying to express in words and diagrams. The challenge is that the layouts and prototypes
themselves don't explain how they'll be used and why.
Avoiding Analysis Paralysis
Having said this, I want to voice a caution: You can dissect use cases endlessly looking for anything and
everything possible. To avoid analysis paralysis, recognize that you won't get everything right the first time
through. It just isn't possible. Here are some tips to keep things moving:
Allow for a number of passes through the problem.
Set limited time frames for each pass (time boxes).
Move on to other diagrams, and then revisit the use cases and scenarios after looking at the problem from
the unique perspectives that the other diagrams provide. Let the diagrams reveal information and
inconsistencies, or prove you are right.
Above all, allow time for practice. Trial and error can be excellent teachers.
Another liability of prototypes is that they give the false impression that the application is nearly complete. This is
understandable because the user only works with the interface, and to users, the interface i s the application. But
you and I know that there is a lot more to it, including the logic expressed in the use case narrative and the
scenarios; the places where we grapple with business objectives; everything that can and probably will go wrong;
and our plans to cope with all of these issues to ensure the success of the system.
How to find use case scenarios
Reading a use case narrative and following every possible path can be difficult. One very simple and practical tool
to use to find scenarios visually is an Activity diagram. Visual models provide a valuable complement to text.
Together, the two perspectives can reveal insights not visible from only one of these perspectives. Given that
people learn in different ways, having different tools to explain the same problem can help everyone grasp the
important issues more easily.
One major benefit of an Activity diagram is its ability to quickly reveal dead-end segments and incomplete paths.
The Activity diagram is still grounded in textual description for each activity, so there is significant overlap with the
narrative that helps insure that the two representations, the narrative and the Activity diagram, are consistent.
To find a scenario, start at the beginning of the use case narrative. It usually works best to determine the path of
the successful scenario first, since it's usually the most commonly encountered path in practice. Trace the steps
until you come to a decision, represented by a diamond. Now you have to make a choice. Select one of the
possible paths leading out of the diamond, preferably the path that leads to the successful completion of the use
case, and continue to trace the steps. Continue the process until you reach an end point. That completes scenario
1. Now return to the top and retrace the first scenario to the first branching point (decision). Start identifying the
unique-portion of the second scenario at the branch by following a different path leading out of the decision.
Continue tracing the steps as before. If you loop back to a place you have already been, then stop. Avoid creating
redundant segments.
Repeat the process until you have traced a path through every segment of the diagram. You should now have a
set of traces that together account for every element of the Activity diagram. The set of use case scenarios is then
derived from a unique combination of these segments. For example, the successful path is one use case scenario.
The first three steps of the successful scenario and the first exception segment make up one exception scenario
for the use case.
The next section steps through the process of finding scenarios for a theater system use case.
Finding use case scenarios for the case study
Now that you have an understanding of what a scenario is and how to find one, this section provides an example of
the process for finding scenarios using the theater systems's SelectPerformance use case. Table 12-2 contains
the use case narrative that is the basis for the Activity diagram to follow. Please read through the narrative to get
familiar with how the use case works. Note the assumptions, preconditions, and post conditions, and how they are
integrated into the use case dialog.
Table 12-2: Use Case Narrative for SelectPerformance
Element Description
Use Case
Name
SelectPerformance
Use Case
Number
12
Author Jane Analyst and Joe Client
Last Updated April 1, 2003
Assumptions The actor has the appropriate authority to use this feature.
Preconditions None.
Use Case
Initiation
This use case starts on demand.
Use Case
Dialog
The user should be given a default set of information about the shows scheduled within
the next 20 days. The user should also be provided with all the events currently
scheduled at the venue.
When the user selects an event, the system should provide the set of shows scheduled
for that event (the event display should remain unchanged).
When the user selects a show, the system should prompt him for a confirmation of his
selection in order to avoid mistakes.
The user should also be able to request a list of shows for a date range and get a new
list of shows (the event display should remain unchanged).
The user may cancel out of this use case without making a selection.
Post conditions The selected show must be saved so that it can be passed on to the next step in the
workflow. One selected show is the net output from this use case.
Figure 12-19 models the Activity diagram for the dialog in Table 12-2 so that you can more easily see the logical
steps involved in the execution of the use case.
Element Description
workflow. One selected show is the net output from this use case.
Unresolved
issues
Should we allow the users to establish their own defaults? How many items should we
allow them to view at one time?
Figure 12-19 models the Activity diagram for the dialog in Table 12-2 so that you can more easily see the logical
steps involved in the execution of the use case.
Figure 12-19: Activity diagram for the SelectShow use case.
Figure 12-20 traces the logic for the successful scenario first. It traces each step, following the choices we make at
each decision point. On this-first pass we want the choices that will lead us through the successful scenario.
workflow. One selected show is the net output from this use case.
Unresolved
issues
Should we allow the users to establish their own defaults? How many items should we
allow them to view at one time?
Figure 12-19 models the Activity diagram for the dialog in Table 12-2 so that you can more easily see the logical
steps involved in the execution of the use case.
Figure 12-19: Activity diagram for the SelectShow use case.
Figure 12-20 traces the logic for the successful scenario first. It traces each step, following the choices we make at
each decision point. On this-first pass we want the choices that will lead us through the successful scenario.
Figure 12-20: Trace the successful scenario from beginning to end.
NoteNotice how the concurrent activities (between the two horizontal bars near the top of the diagram) are
treated as a single path.
Figure 12-21 selects the "No" path out of the confirm decision, representing the fact that the user decided not to go
with the show they selected (accidents happen). (This segment will reveal a unique path through the use case
narrative that we can use to build the second scenario.) This time the logic leaves the decision and loops back to
the merge point just before the first decision. The scenario segment stops here. We can later put it together with
the steps of scenario 1 that led up to the decision point to complete the definition of scenario 2.
Figure 12-21: In scenario 2, a performance is selected and the confirmation is declined.
Figure 12-22 selects the second path out of the first decision, representing the fact that the user selected an event.
This time the logic leaves the decision and loops back to the decision point again. The third scenario segment
stops here. We can later put it together with the steps of scenario 1 that led up to the decision point to complete the
definition of scenario 3.
Figure 12-22: Scenario 3.
Figure 12-23 identifies the fourth scenario by continuing from the first decision when the user chooses to get a new
list of performances based on a date range. Once again the scenario segment loops back to the decision point.
Figure 12-23: Scenario 4.
Figure 12-24 identifies the fifth scenario, in which the user chooses to cancel out of the use case without selecting
a performance.
Figure 12-24: Scenario 5.
The goal of developing scenarios is to account for every logical possibility in the flow of the use case. Every
segment identifies a unique line of logic within the total use case.
But you're not done yet.
Applying use case scenarios
Technically, the definition of a use case scenario says that each scenario describes a single logical path through a
use case, from start to finish. Using the Activity diagram, you can visually identify each path simply by following
lines in the diagram. But in the SelectPerformance use case example, each individual arrow traces a separate
logical segment, not necessarily a complete logical path, from the beginning of the use case to the end of the use
case. For example, alternative scenario 3 only identifies the steps that were unique from those already identified by
scenario 1. In fact, in this use case, a scenario could involve multiple loops through each segment in any order
before the user finally cancels or confirms a selection.
The diagram did not show repeated segments of paths already singled out by a previous scenario. This convention
is a common one employed to avoid redundancy and extra work. When writing the formal scenarios, or test cases,
simply build the test case from the scenario segments. By doing a little mixing and matching, you can provide
comprehensive coverage of every combination. For example, to fully specify scenario 2, include the first two steps
and the decision from scenario 1 plus the unique steps of scenario 2.
Note, too, that whenever you encounter a loop, the scenario maps out only a single pass through the loop. To test
the loop thoroughly, run the scenario segment multiple times remembering to test the boundary conditions.
The result of completing the description of all the scenarios should be a reasonably complete acceptance-level (or
user-level) test plan for each use case. Remember, though, that so far you have only modeled the system at the
use case level. That means that the test plan you have so far is really only an acceptance-level test plan, not full
system or integration testing. But the use case level test plan does provide the framework for all of the test plans
for successive phases in the project.
<Day Day Up>
<Day Day Up>
Summary
Use case diagrams, together with use case narratives and scenarios, define the goals of a system, or other
classifier, such as an enterprise, subsystem, or component. The concept came from the work of Ivar Jacobson
and his associates on a methodology called Object-Oriented Software Engineering (OOSE). The purpose of the
use case approach is to focus the development effort on the essential objectives of the system without getting lost
in, or driven by, particular implementations or practices.
The elements of a Use Case diagram include:
The Use Case diagram is complemented by the use case narrative and use case scenarios.
Actors define entities outside the system that will use the system in some way.
Associations indicate which actors will interact with features (use cases) of the system.
include and extend relationships describe the nature of the interactions between use cases.
Generalization defines inheritance relationships between use cases or between actors.
The goal of the Use Case diagram is to define the expectations of the external actors. Those actors may be
people, systems, or devices that need to interact with the system. Their interactions may be to provide input, to
receive output, or to dialog with the system in order to cooperate in the completion of a task. All of these
interactions are focused through a set of specific features of the system called use cases. Each use case defines
one specific goal that the system can achieve.
The construction of a Use Case diagram employs the following steps:
Define the context of the system:
1.1Identify the actors and their responsibilities.

1.2Identify the use cases, the features of the system, in terms of specific goals and/or results that must be
produced.
1.
Evaluate the actors and use cases to find opportunities for refinement (splitting or merging definitions). 2.
Evaluate the use cases to find include type relationships. 3.
Evaluate the use cases to find extend type relationships. 4.
Evaluate the actors and use cases for generalization opportunities (shared properties). 5.
The use case narrative describes what the actors expect from the use case. The use case is a behavior of the
system with a beginning (trigger), middle (dialog), and end (termination). As such, it needs to be explained in terms
plain enough for the actors to understand and verify, but precise enough for analysts and designers to rely on in
order to build the system.
The features of a use case narrative aren't standardized, but these are common elements in wide use:
Use case initiation, or trigger, describes how to start a use case.
Assumptions define conditions that must be true before the use case may execute, but are not tested by the
use case.
Preconditions define conditions that must be true before the use case may execute, and are tested by the use
case.
The use case dialog explains how the user (whether an actor or another use case) interacts with the system
during the execution of the use case.
Use case terminations define the different mechanisms that can cause the use case to stop execution.
Post conditions define the state of the system that must be true when the use case ends. This helps prevent
use cases from leaving the system in an unstable condition for other use cases that follow.
Minimum guarantees describe what the actors can expect from a use case, no matter what happens during
the execution of the use case.
Successful guarantees describe what the actors can expect from a use case when it completes successfully.
Although these elements are valuable, they are by no means exclusive. Definitely look into other books and online
resources on use cases, and augment the narrative to support your own method of development.
Use cases express what the users expect the system to provide. Use case narratives explain in detail how the
users expect to interact with the system when they invoke the use case. Scenarios break down the narrative
explanation to provide a detailed examination of every possible outcome of the use case; why each outcome
happens, and how the system is supposed to respond.
The Activity diagram provides a visual evaluation of the use case narrative. Although it isn't necessary to use an
Activity diagram, it can be very helpful, especially for complex use cases.
A scenario is a single logical path through a use case, expressing one possible outcome. Finding use case
scenarios requires that you follow each unique series of activities and decisions from the beginning of the use case
to a single end point. Together, the scenarios should account for every possible way that a use case could
execute.
When the scenarios have been identified, they may be used to develop a comprehensive acceptance-level test
plan. They may also be used to test the results of subsequent analysis and design efforts.
<Day Day Up>
<Day Day Up>
Chapter 13: Modeling Behavior Using an Activity Diagram
Overview
The Activity diagram is often seen as part of the functional view of a system because it describes logical processes,
or functions. Each process describes a sequence of tasks and the decisions that govern when and how they are
performed. You must understand a process in order to write or generate correct code for a behavior.
NoteSome authors lump functional and dynamic aspects of modeling together because they both express
behavior. However, in teaching these concepts, I find it useful to distinguish logic from interaction.
Interactions address net results of processes, that is, net input and output. Functional or logical models
address the mechanics of transforming input to output.
Also, functional modeling acquired a poor reputation with the onset of object-oriented (OO) modeling. After all,
object-orientation addresses the deficiencies of the earlier modeling approaches such as functional and data
modeling. But both functional modeling and data modeling still provide valuable insight into software development.
OO development methods do not eliminate the need for these valuable perspectives; they simply bring the two
concepts together to provide a more comprehensive and accurate model of how things work. Functional modeling
is still a very basic part of any application design.
So UML has preserved functional modeling in the form of the Activity diagram, which is designed to support the
description of behaviors that depend upon the results of internal processes, as opposed to external events as in
the interaction diagrams. The flow in an Activity diagram is driven by the completion of an action. In a state
machine, the flow is driven by external events or conditions in the associated classifier. Consequently, Activity
diagrams are useful for defining operations, use cases, and workflow that links a series of use cases.
<Day Day Up>
<Day Day Up>
Activity Diagram Changes from UML 1.4 to 2.0
The changes between UML 1.4 and UML 2.0 metamodels are substantial, although the net impact on the diagram
notation is not very dramatic. This chapter provides an explanation of the diagrams in both versions and more in-
depth coverage of the UML 2.0 metamodel for those who need to support the new concepts in a modeling tool, or
who want to define their own extensions to the model.
State Machine versus standalone model
In UML 1.4, the Activity diagram (ActivityGraph) was defined as a subclass of StateMachine. Thus, most of the
information needed to describe an Activity diagram was already defined as part of the state machine specification.
The Activity diagram simply added a few new classes, namely ActionState, ObjectFlowState, SubactivityState, and
Partition.
UML 2.0 views an Activity diagram as an entirely unique diagram from a State Machine. The metamodel is
substantially expanded and there is virtually no over lap with the state machine metamodel.
Even with this rather substantial change to the underlying metamodel, the notation is still remarkably similar. Table
13-1 identifies the notation from both versions, revealing the similarities and differences.
Table 13-1: Activity Diagram Notation in UML 1.4 and 2.0
UML 1.4 UML 2.0 Description
Action state Action with preconditions, post
conditions, and parameter set
UML 2.0 expands the description of
an action.
Subactivity state Activity, with preconditions and post
conditions. Can belong to an Activity
Groupprecondition
UML 2.0 expands the description of
an activity.
Decision and merge DecisionNode and MergeNode UML 2.0 also allows the two icons
to be consolidated into one.
Call state Simply another action

Swimlanes (called
Partition in the
metamodel)
Partitions (called ActivityPartition in the
metamodel)
New name. Same basic function.
ObjectFlowState ObjectNode and ObjectFlow

Signal Sending and

Receipt
Handled using ObjectNodes

Deferred events

Fork and join ForkNode and JoinNode UML 2.0 also allows the two icons
to be consolidated into one.
UML 1.4 UML 2.0 Description
to be consolidated into one.
Finalstate ActivityFinalNode and FlowFinalNode UML 2.0 refines the terminator
notation to support terminating an
individual flow versus the entire
Activity diagram.
Transition ActivityEdge

InterruptibleActivityRegion New in UML 2.0.

Datastore New in UML 2.0 (reminiscent of

Data Flow diagrams from
Structured Analysis and Design by
Ed Yourdon).
Action states and subactivity states versus actions and activities
In general, states have been replaced in UML 2.0 with unique metaclasses. The action states from UML 1.4 are
now actions in UML 2.0 defined by their own metaclass. The UML 1.4 subactivity states are simply a composition
form of an activity, an activity that can be broken into subactivities; UML 2.0 accomplishes the same thing with
activities and activity groups, also defined with their own metaclasses.
The changes in UML 2.0 address some of the problems that were introduced because the Activity diagram was put
into UML 1.0 at the last minute at the insistence of people who wanted a general-purpose workflow diagram in
UML. In order to negotiate its inclusion, however, it was presented as a limited kind of state diagram. As such, it
was always ill-suited for its original purpose, which was to model workflow. UML 2.0 finally corrects this problem by
providing a complete and unique definition for the Activity diagram as separate and distinct from the State Machine
diagram.
UML 2.0 levels of compliance
UML 2.0 offers some differentiation based on levels of compliance. The basic features are required for every
implementation of the metamodel in a modeling tool. The intermediate (common) and complete levels are
optional and extend the basic definitions with new features, sometimes adding entirely new concepts. For example,
the basic definition for activity is extended in the complete level to add the feature isSingleCopy. Likewise, the basic
definition for action is extended to add associations with constraints as defined in the Kernel. Still other classes add
new subclasses at the intermediate and complete levels.
UML 2.0 support for structured programming techniques
In addition, UML 2.0 provides three levels that stand roughly parallel to the three levels of compliance. The
StructuredActivities level supports modeling of traditional structured programming constructs, such as loops and
conditionals. It assumes the use of the basic activities level, but is also compatible with the intermediate and
complete levels.
The StructuredCompleteActivities level adds support for data flow output pins of conditionals and loops by
incorporating concepts from the Action Semantics portion of the UML 1.4 specification. It is intended to be used in
conjunction with the intermediate layer, which supports full concurrency, but there is no actual dependency
between the levels.
to be consolidated into one.
Finalstate ActivityFinalNode and FlowFinalNode UML 2.0 refines the terminator
notation to support terminating an
individual flow versus the entire
Activity diagram.
Transition ActivityEdge

InterruptibleActivityRegion New in UML 2.0.

Datastore New in UML 2.0 (reminiscent of

Data Flow diagrams from
Structured Analysis and Design by
Ed Yourdon).
Action states and subactivity states versus actions and activities
In general, states have been replaced in UML 2.0 with unique metaclasses. The action states from UML 1.4 are
now actions in UML 2.0 defined by their own metaclass. The UML 1.4 subactivity states are simply a composition
form of an activity, an activity that can be broken into subactivities; UML 2.0 accomplishes the same thing with
activities and activity groups, also defined with their own metaclasses.
The changes in UML 2.0 address some of the problems that were introduced because the Activity diagram was put
into UML 1.0 at the last minute at the insistence of people who wanted a general-purpose workflow diagram in
UML. In order to negotiate its inclusion, however, it was presented as a limited kind of state diagram. As such, it
was always ill-suited for its original purpose, which was to model workflow. UML 2.0 finally corrects this problem by
providing a complete and unique definition for the Activity diagram as separate and distinct from the State Machine
diagram.
UML 2.0 levels of compliance
UML 2.0 offers some differentiation based on levels of compliance. The basic features are required for every
implementation of the metamodel in a modeling tool. The intermediate (common) and complete levels are
optional and extend the basic definitions with new features, sometimes adding entirely new concepts. For example,
the basic definition for activity is extended in the complete level to add the feature isSingleCopy. Likewise, the basic
definition for action is extended to add associations with constraints as defined in the Kernel. Still other classes add
new subclasses at the intermediate and complete levels.
UML 2.0 support for structured programming techniques
In addition, UML 2.0 provides three levels that stand roughly parallel to the three levels of compliance. The
StructuredActivities level supports modeling of traditional structured programming constructs, such as loops and
conditionals. It assumes the use of the basic activities level, but is also compatible with the intermediate and
complete levels.
The StructuredCompleteActivities level adds support for data flow output pins of conditionals and loops by
incorporating concepts from the Action Semantics portion of the UML 1.4 specification. It is intended to be used in
conjunction with the intermediate layer, which supports full concurrency, but there is no actual dependency
between the levels.
The ExtraStructuredActivities level adds explicit support for exception handling as found in traditional programming
languages. It requires the StructuredActivities level.
<Day Day Up>
<Day Day Up>
Modeling the UML 1.4 Activity Diagram
In the past, business environments have used flowcharts to model processes for training and for expressing
behaviors. Processes as used here are logic sequences of tasks governed by clearly defined points of control such
as decisions, merges, forks, and joins. Flowcharting is a simple and practical technique with a wide range of
application. UML offers an enhanced version of flowcharts in the form of the Activity diagram, also called an
Activity Graph.
There are at least three places in a model where an Activity diagram provides valuable insight:
Modeling workflow
Describing use cases
Specifying operations
Modeling workflow and use cases
A use case models a goal that the system must achieve in order to be successful. The Activity diagram follows the
user through a procedure, noting the decisions made and tasks performed. The procedure may explain a single
use case, or only part of a use case, or even many use cases tied together to create a workflow. Modeling a use
casecase is part of the discovery and validation process for modeling a system. Each diagram lends a new
perspective on the features of the system.
An Activity diagram for one use case explains how the actor interacts with the system to accomplish the goal of the
use case, including rules, information exchanged, decisions made, and work products created.
A workflow-level Activity diagram represents the order and conditions under which use casecases are executed in
a series.
Modeling the user's work this way does not bind you to that particular version of the process. Each goal (use case)
might be satisfied by any number of valid processes. But creating such a model will likely reveal the essential
elements of the process in a way that is familiar to the users. Essential elements include work products created,
rules that must be enforced, decisions made based on work products and processes, and the state of specific
resources at each step in the process. The Activity diagram can facilitate the interview to clarify the tasks and the
decisions in order to find the reasons behind them. That is, this is your opportunity to ask those all-important "why"
questions to get at the goal of the process and each task required to make the process successful.
Once the essential rules for the process have been identified, it is then easier to evaluate alternative processes to
satisfy those rules. In the theater system, for example, customers want to find out what seats are available at a
specific show and at what prices. The basic goal is simple: show them what is available and enable them to select
what seats they would like to buy, if any. The essential rules include identifying the available seats and displaying
the information in a form the customers can understand. Then the customers have to be able to communicate to
the system the seats that they want.
This goal and the associated rules can be supported by many processes. For example, they may be satisfied by a
sales person talking with a customer, by a paper printout and purchase form, by a touch screen at a kiosk, or via
Web pages (and probably many other options). Even within these options there is a wide range of alternatives for
how to display the content and communicate the choices.
The point is that without a baseline requirement, it is impossible to critically and accurately evaluate the relative
value of each alternative. The Activity diagram is designed to provide an accurate definition of the baseline
requirements from a logical, sequential perspective.
Defining methods
The Activity diagram can also be used to model the implementation of complex methods. When defining the
implementation for an operation, you need to model the sequence of data manipulation and transformation,
looping, and decision logic. Modeling complex functions can prevent problems later when you write the code by
revealing all of the requirements explicitly in the diagram. Models make most, if not all, of your assumptions visible
and consequently easier to review and correct.
TipIt is very tempting to shortcut the modeling process, but the true value of modeling is in revealing what you
know so that it can be challenged and verified. Making assumptions visible and thus available for review
and correction is a very valuable benefit of modeling.
The Activity diagram contains all of the logical constructs you find in most programming languages. In fact, it
translates quite well into pseudo-code or even native code.
I offer one clarification here regarding the vocabulary of UML: the word operation refers to the declaration portion
of a behavior defined by a class. This typically means the name, parameters, and possibly the return type. The
declaration portion is also often called the interface of the object, the information you use to tell the object what
you want it to do. In contrast, the word method is used to refer to the implementation of an operation, the code that
is executed when you invoke the interface.
TipTo confuse things even more, the word interface has many meanings too, even within UML Interface may
refer to one operation, the set of operations for a class or component, a set of operations that support a
single purpose, and a unique type of class called an Interface class. You will have to depend on the
context to interpret the word in each situation.
The Activity diagram may be used to design the requirements for a method. Because UML does not provide for
modeling the methods in a Class diagram, the Activity diagram affords a place for that. Actually, the separation of
the specification of a behavior in an operation and the implementation logic of a behavior in an Activity diagram
supports the encapsulation principle of separation of interface and implementation. In fact, it is reasonable to
support many implementation alternatives (methods illustrated using Activity diagrams) for the same operation.
CautionNot everyone has accepted or uses the definitions for operation and method as they are applied in
UML.
To be sure, not every method is complicated enough to warrant drawing an Activity diagram. The point is that the
Activity diagram is well suited to the task when it is needed.
<Day Day Up>
<Day Day Up>
UML 1.4 Activity Diagram Notation
This section provides a quick tour of the notation, much of which may be familiar if you've used flowcharts, so feel
free to skim over the section until you spot something that looks new.
Activities and transitions
An activity is a step in a process where some work is getting done. It could be a calculation, finding some data,
manipulating information, or verifying data. The activity is represented by a rounded rectangle containing freeform
text. Technically, in UML 1.4 activities are called ActionStates. An ActionState is an atomic behavior. In other
words, an activity in UML 1.4 is a state with only one action, an entry action that is always performed when the state
is entered.
An Activity diagram is a series of activities linked by transitions, arrows connecting each activity. Typically the
transition takes place because the activity is completed. For example, you're currently in the activity "reading a
page." When you finish the activity, you switch to the activity "turning a page." When you are done turning the
pagewell, you get the idea. Figure 13-1 shows this concept graphically.
Figure 13-1: Activities and transitions.
This notation starts to show the overlap between the Activity diagram and the Statechart diagram. In fact, in UML
1.4 the Activity diagram is a subset of the Statechart diagram. Each activity is an action state in which the object is
busy doing something (including "waiting"). UML 1.4 views each transition as a change in state, a change from one
activity (action state) to the next.
Guard condition
Sometimes the transition should only be used when certain things have happened. A guard condition can be
assigned to a transition to restrict its use. Place the condition within square brackets somewhere near the transition
arrow. The condition must test true before you may follow the associated transition to the next activity. The Activity
diagram segment in Figure 13-2 tells you that you can't leave the dinner table unless you have finished your
vegetables.
Figure 13-2: A guard condition on a transition.
Decisions
The Activity diagram diamond is a decision icon, just as it is in flowcharts. One arrow exits the diamond for each
possible value of the tested condition. The decision may be as simple as a true/false test; the example on the left in
Figure 13-3 asks, "Are there sufficient funds in the customer's account to cover the withdrawal?" In other cases,
the decision may involve a choice among a set of options; the example on the right in Figure 13-3 asks, "Would
you like chocolate, vanilla, strawberry, or rocky road ice cream?"
Figure 13-3: Making a decision.
Each option is identified using a guard condition. Each guard condition must be mutually exclusive so that only one
option is possible at any decision point. The guard is placed on the transition that shows the direction that the logic
follows if that condition is true. This construct correlates to case statements or if-then-else structures in most
programming languages.
Using the same reasoning to specify each choice at a decision point, transitions out of an activity may be modeled
using guard conditions. For example, in Figure 13-4 the activity of computing the new account balance reveals
whether the account is overdrawn. All the information needed to make the choice is provided by the activity itself.
There is no external decision or additional information that is not already available. To show the choices resulting
from an activity, simply model the transitions exiting the activity, each with a different guard condition.
Figure 13-4: Making a decision in an activity.
When deciding which notation to use for decisions in the Activity diagram, consider the following:
Use the decision diamond form illustrated in Figure 13-3 when no processing is included in the step. This
usually means that the needed information has been accumulated from a number of previous steps or the
decision is an explicit choice by an actor.
Use the form in Figure 13-4 when the completion of the activity provides all the required information to support
the decision.
Merge point
The diamond icon is also used to model a merge point, the place where two alternative paths come together and
continue as one. For example, you and I might each walk from your house to the store. Leaving the house is
branch point, where we each leave from a common place, but I choose to walk down the left side of the street
while you walk down the right. But two blocks before the store we both have to turn right and walk on the right side
of that street to the store's front door. Neither of us could take both routes at the same time. But whichever route
we take, we have to walk the last two blocks in exactly the same manner. The merge point is the location where
our paths come together.
You can also think of the merge point as a labor-saving device. The alternative would be to model the same
sequence of steps for each of the paths that share them.
Figure 13-5 shows alternative paths merging and continuing along a single path. The diamond represents the point
at which the paths converge.
Figure 13-5: The diamond as a merge point.
Start and end
UML also provides icons to begin and end an Activity diagram. Figure 13-6 shows the solid dot that indicates the
beginning of the flow of activity and the bull's-eye that indicates the end point.
Figure 13-6: Begin and end notation for the activity diagram.
There may be more than one end point in an Activity diagram, because even the simplest Activity diagram typically
has some decision logic that results in alternative paths, each with their own unique outcome. If you want to, you
can draw all of your arrows to the same end point, but there is no need to do so. Every end point means the same
thing: "Stop all activities in this diagram now."
Concurrency
UML notation for the Activity diagram also supports concurrency, which enables you to model the features of
languages that have been introduced after the flowchart was invented, such as Java, C++, and Smalltalk, on
hardware capable of true concurrency. To show that a single process starts multiple concurrent threads or
processes, UML uses a simple bar called a fork, or split of control. Figure 13-7 shows examples of one transition
pointing at the fork, and multiple transitions pointing away from it. Each outgoing transition is a new thread or
process.
Figure 13-7: Initiating multiple threads or processes.
Synchronization or merging of the concurrent threads or processes is shown in much the same way. Figure 13-8
shows examples of multiple transitions pointing at the bar, this time called a synchronization bar, and one pointing
out of the bar, indicating that the concurrent processing has ended and the Activity diagram continues as a single
thread or process.
Figure 13-8: Merging control using the synchronization bar.
CautionTechnically, the bar used in a fork and in synchronization is called a synchronization bar. However, I
have found that using the same term in both instances causes confusion, so I choose to use fork and
synchronization to refer to the nature of the change in the flow.
Identifying a concurrency opportunity does not necessarily dictate a concurrency requirement. It simply models the
fact that sequential processing is not required, and if the implementation environment supports it, there might be a
chance to optimize the performance of the application by exploiting the concurrency opportunity.
<Day Day Up>
<Day Day Up>
Building an Activity Diagram
As an example of how to construct an Activity diagram, I've provided a sample use case for receiving a product into
a warehouse. Table 13-2 provides the use case text, the basis for the Activity diagram.
Table 13-2: A Use Case Narrative for Receive Product
Field Name Field Description
Use case Name Receive Product
Number 2.0
Author Joe Analyst
Last update 01/01/03 (working over New Year's Day to make points with the boss)
Assumptions The user has authority to use this transaction
Preconditions Shipment is from a valid shipping company
Use case initiation This use case starts on demand
Use case dialog The user enters the shipper identification number (ShipperID)
If not found, display the "Shipper not found" error message
Prompt to re-enter or cancel
Else (found) proceed
Display the Shipper details
Enter the Shipment details (date, sender, number of pieces)
For each product in the Shipment
Find the Purchase Order using the PO_nbr
If not found, display "invalid P.O." error message and set the item aside
Else (P.O. found)
Match the product to an item on the Purchase Order
If not matched, display "invalid item" error message and set the item aside
Else check off the item and qty on the Purchase Order
Notify Accounts Payable of the updated Purchase Order
Display the "Accounts Payable notified" message
And
Update inventory for the items Products received
Display "inventory updated successfully" message
Print the receiving confirmation
Use case
termination
This use case ends when:
The system displays the message that it could not find the Shipping company and
the user cancels
Accounts Payable has been notified and the inventory has been updated
The user cancels the transaction
Post conditions Upon successful completion of the transaction:
Update inventory
Field Name Field Description
Update inventory
Notify Accounts Payable
Print a confirmation to go with the receiving documents
Upon receiving the Cancel option:
Returns to its initial state prior to this use case
One way to proceed with the Activity diagram is to follow the use case narrative. First, identify the preconditions.
The preconditions must be tested before you allow the use case to execute. Table 13-2 identifies a precondition
that the "Shipment is from a valid shipping company." Testing this precondition is done in the first four lines of the
use case dialog. Figure 13-9 shows the start symbol followed by the activities to enter the Shipper_ID and find the
shipper in your system. The result of the find is either successful or not. The two possible results give you the
guard conditions to direct the flow to either of the next two activities: "Prompt to re-enter or cancel" or "Display
Shipper details."
Figure 13-9: Modeling the preconditions.
Figure 13-9 implies that you would let the user try again or cancel. To do that, you need to loop back to the
beginning and offer them a choice:
To loop back to a previous place in the logic, use a merge-point diamond. 1.
To provide a choice, use the decision diamond. Then-each path out of the decision diamond must be
labeled with a guard condition. In this case, you offer the user two choices: proceed to Enter Shipper_ID or
cancel.
2.
Figure 13-10 shows the needed changes.
Update inventory
Notify Accounts Payable
Print a confirmation to go with the receiving documents
Upon receiving the Cancel option:
Returns to its initial state prior to this use case
One way to proceed with the Activity diagram is to follow the use case narrative. First, identify the preconditions.
The preconditions must be tested before you allow the use case to execute. Table 13-2 identifies a precondition
that the "Shipment is from a valid shipping company." Testing this precondition is done in the first four lines of the
use case dialog. Figure 13-9 shows the start symbol followed by the activities to enter the Shipper_ID and find the
shipper in your system. The result of the find is either successful or not. The two possible results give you the
guard conditions to direct the flow to either of the next two activities: "Prompt to re-enter or cancel" or "Display
Shipper details."
Figure 13-9: Modeling the preconditions.
Figure 13-9 implies that you would let the user try again or cancel. To do that, you need to loop back to the
beginning and offer them a choice:
To loop back to a previous place in the logic, use a merge-point diamond. 1.
To provide a choice, use the decision diamond. Then-each path out of the decision diamond must be
labeled with a guard condition. In this case, you offer the user two choices: proceed to Enter Shipper_ID or
cancel.
2.
Figure 13-10 shows the needed changes.
Figure 13-10: Modeling a looping condition and merge point.
Next identify the post conditions and terminations. (I do these together because there is often a great deal of
overlap.) The use case narrative in Table 13-2 specifies that the use case terminates when:
The system displays the message that it could not find the shipping company and the user cancels
Accounts Payable has been notified and the inventory has been updated
The user cancels the transaction
The narrative post conditions say that the system must upon successful completion:
Update inventory
Notify Accounts Payable
Print a confirmation to go with the receiving documents
The narrative post conditions say that if the system receives the Cancel option it must:
Return to its initial state (prior to the use case)
Figure 13-11 shows the activities to notify accounts payable, update inventory, and print the confirmation. I added
an activity to display a message for each action so that the user knows that his requirement was met. Right now it
looks like we just have fragments, but we tie all of these pieces together later in this chapter.
Figure 13-11: Modeling post conditions.
Next, you need to model the processing for each piece in the shipment. Figure 13-12 sets up the loop "for each
product" with a decision diamond that asks whether there are "more pieces to receive." The loop is described in
the middle of the Use case dialog in Table 13-2.
Figure 13-12: Modeling the Use case dialog, "For each piece find the Purchase Order."
NoteThe label on the diamond is not an explicit part of the UML specification but it lends clarity to the
diagram.
For each product in the shipment:
Find the Purchase Order using the PO_nbr. 1.
If not found, display "Invalid P.O." error message and set the item aside. 2.
Else (P.O. found).
Figure 13-13 continues the flow for items where the P.O. was found.
3.
Figure 13-13: Modeling the use case dialog, "matching the items to the P.O."
Match the product to an item on the Purchase Order. 4.
If not matched, display "Invalid item" error message and set the item aside. 5.
Else check off the item and quantity on the Purchase Order. 6.
After these steps are completed, we loop back to the "more products to receive" decision.
Now you have all the pieces you need to do a bit of organizing. Look for concurrency opportunities by identifying
tasks that may be done at the same time because they don't depend on one another. For example, Figure 13-14
shows that notifying Accounts Payable and updating inventory don't overlap or depend on one another, so they can
be modeled as concurrent activities. Use the fork to show that you want to follow both logical paths at the same
time. Use the synchronization bar to show that you're done with the concurrent tasks and want to continue on a
single logical path. In this example, after all the updates and notifications are done, you can print the confirmation.
Figure 13-14: Modeling the concurrency opportunity.
Figure 13-15 puts all the segments together. Notice at the bottom left below the activity labeled Display
"invalid item" error message I added another merge point to bring together the segments shown in
Figures 13-12 and 13-13.
Figure 13-15: The complete Activity diagram.
As you can see from the example, all the old flowchart elements are still there. UML has added concurrency to
keep pace with technology. UML 2.0 extends the notation a bit further, but its greatest enhancements are to the
underlying definitions of the metamodel elements used to construct Activity diagrams (covered later in this
chapter).
<Day Day Up>
<Day Day Up>
Modeling the UML 2.0 Activity Diagram
The UML 2.0 Activity diagram is all about behavior. Where most other UML diagrams devote much of their notation
to assigning various types of responsibility to objects, the Activity diagram sets aside the responsibility for the
behavior in favor of focusing attention on what needs to be done to successfully perform the behavior. Once the
logic and the data manipulation issues have been resolved, the Activity diagram can add information about what
objects or portions of the system will take responsibility by allocating behaviors to partitions that may in turn be
assigned to classifiers. But the primary purpose of the tools that make up the Activity diagram notation is to define
the mechanisms of the behavior.
The Activity diagram follows a sequence of activities through decisions (branching), fork and join (for concurrency),
and loops, until all of the tasks (actions) in the behavior are successfully completed or an exception or interrupt
terminates the sequence. Activities themselves may be broken down into discrete actions.
The UML 2.0 specification provides two interrelated sets of three packages containing the features of Activity
diagrams. Figure 13-16 models the packages involved in the definition of the Activity diagram. The BasicActivities
package provides the core of the Activity diagram modeling artifacts, and the IntermediateActivities and
CompleteActivities packages provide further refinements to this package. These refinements are the core of the
Activity diagram artifacts that were in UML 1.4 and are familiar to most readers (or readers who have read the first
half of this chapter). The StructuredActivities package and its subpackages, provide completely new material to
Activity diagrams for UML 2.0.
Figure 13-16: Two sets of packages that together provide all the available features of the Activity diagram.
OMG 2.0 modified
The BasicActivities package supports simple sequences of activities similar to classic flowcharts, including but not
limited to:
Activities that may be broken down into sequences of actions with initial and final nodes
Activities that may be combined into activity groups
Activities that are connected using activity edges (formerly called transitions)
Decision nodes and merge notations that provide branching and merging of logical sequences
Input and output pins on actions that provide the means to specify values passed to and from actions
The IntermediateActivities package provides a number of additional features that may be used alone or with the
features of the BasicActivities package, including but not limited to:
Object nodes and object flows that provide the mechanisms to define objects passed between activities
Fork and join notations that provide the means to model concurrent behaviors
Central buffer nodes that consolidate data from multiple sources
Partitions that support the grouping of behaviors so that they may be assigned to a classifier that will be
responsible for implementing the behaviors
The FlowFinalNode that is a new terminator for individual flows (versus the basic ActivityFinalNode used to
terminate the entire behavior modeled by the Activity diagram)
The CompleteActivities package adds advanced features that build on the concepts of the previous packages by
providing:
An extended version of Activity to support single copy versus multiple copy execution of an activity
Constraints on actions
Behaviors associated with object flows to handle transformation and selection of data values
Object node state and behavior (for token selection or filtering), a value specification for the number of
instances that can be held in the object node, and an ordering option for the tokens held in the object node
Data stores for nontransient data
An extended parameter specification to support exceptions and streaming
A value specification for join nodes to support decision logic at the point where multiple threads or processes
synchronize
Interruptible activity regions that designate a set of activities whose flow may be terminated on a specified
event
The structured activities packages add features that support common structured programming constructs.
The StructuredActivities package introduces conditional notation and loop notation. Conditional notation
includes the ability to define a set of testable expressions and output values. Loop notation defines a set of
activities to be performed repeatedly, bounded by a test condition and an output value.
The CompleteStructuredActivities package adds more features to the loop and conditional structures to further
customize their behavior.
The ExtraStructuredActivities package adds exception handlers, and expansion regions that support multiple
execution of an activity in parallel, iterative, or streaming modes.
<Day Day Up>
<Day Day Up>
Exploring BasicActivities
BasicActivities defines the most fundamental features of the Activity diagram, which are those found in most
flowcharts, such as simple activities and action, flow from one activity or action to another, decisions, and input and
output values for actions. The intent of the package is to provide a set of tools that may be used for most essential
business processes without requiring knowledge of the extended features provided by the intermediate and
complete packages. Separation of the three packages (basic, intermediate, and complete activities) supports an
incremental learning curve for the application of the new Activity diagram concepts and notations.
Modeling activities and actions
Activities and actions are the two fundamental units of behavior in an Activity diagram. An activity is the highest-
level unit of behavior in an Activity diagram. An activity consists of a set of ActivityNodes and ActivityEdges
(connectors). An activity node may be
An ExecutableNode, or more specifically, an Action
A ControlNode (discussed later in this chapter)
An ObjectNode (discussed later in this chapter)
An action is generally an atomic unit of behavior executed in the context of an activity. The containing activity
directs the execution of one or more actions through a flow of control. The flow between actions is directed using a
series of connectors called activity edges, and control nodes. The control nodes provide the means to split and
merge the flow of control based on decision points. As part of the flow of control, actions may pass values in the
form of object flows, that is, objects containing the data produced (as output) by one action and consumed (as
input) by another action.
Activities, actions, activity edges, and control nodes combine to illustrate a single large (possibly parameterized)
behavior. This behavior is described as a series of discrete behaviors guided by decisions applied against the data
produced by the actions during the activity execution. Figure 13-17 depicts a simple activity containing four actions
and three activity edges, the arrows connecting the series of actions. (Control nodes will be added to subsequent
examples.)
Figure 13-17: An activity containing four actions and three activity edges.
There is more to the notation, but I want to start simple and add more details and alternatives until you have seen
the application of all the available notations.
The flow from one action to the next may be triggered by one of three circumstances:
Other actions or activities in the model complete execution. When one finishes, the next activity or action in the
flow starts.
Objects and data become available. If an activity or action is expecting input data, it waits until all required input
data is available.
An external event occurs, such as receiving notice of a state change in the system (for example, a
performance is scheduled and priced or an event is cancelled).
The example in Figure 13-17 models a use case, Select Performance. Note that the Activity diagram does not
identify who is responsible for the behaviors within the activity; its purpose is to figure out what needs to happen.
Only after the modeler understands what needs to happen does he have the facts needed to decide what
resources are best suited to take responsibility for each action or for the overall activity. When it is time to make this
decision, the Activity diagram provides the concept of partitions and association with classifiers described in the
IntermediateActivities package.
Modeling initial and activity final nodes
A sequence of actions has a beginning and an end. The Activity diagram defines two ControlNodes: InitialNode, to
designate the starting point in a sequence, and ActivityFinalNode, to designate the end of a sequence. There are
actually two types of end points, ActivityFinalNode and FlowFinalNode. FlowFinalNode is described later in the
section about the IntermediateActivities package.
The initial node is depicted as a solid dot connected to an action by an activity edge. When an activity is entered,
the flow of control begins at the initial node and proceeds to the activity final node. When an activity final node
(depicted as a solid dot with an activity edge-an arrow-connecting to the first action) is reached, the entire activity
stops, all tokens (data) are lost (unless saved using a DataStore), and the activity exits.
The initial node notation is highlighted in the top left corner of Figure 13-18. The activity final node is highlighted in
the bottom right corner of Figure 13-18.
Figure 13-18: An activity with InitialNode and ActivityFinalNode added.
Modeling activity edges
Modeling control flow requires a means to illustrate the movement from one action to the next. The Activity
diagram provides two types of ActivityEdge to model flow from one action to the next: a ControlFlow that simply
directs the flow of control from one action to another, and an ObjectFlow, which directs the flow but also passes
data (as output from an action) that is intended as input to a subsequent action. (The remainder of this section
focuses on control flow. Object flow is discussed later in the "Modeling object nodes and object flows" section.)
Both ActivityEdges use a simple arrow notation. An activity edge may be adorned with any of the following:
A name. A name is optional, but when used, it should be placed in close proximity to the arrow. In general, the
movement from one action (or activity) to the next is automatic. However, in the case of external events, the
name can reflect the specific event.
Data passed as objects (ObjectNodes). Passing objects is described in detail later in the "Modeling object
nodes and object flows" section.
Identifying an interruption. Interruption is discussed later in the "Modeling interruptible activity regions" section.
Connectors. Connectors provide a convenience for modeling large diagrams. Instead of wrapping activity
edges around and through a large diagram or across multiple pages, a connector uniquely identifies a point on
a diagram that maps to a second point somewhere else on the diagram, whether on the same page or some
other page. A connector is modeled as a circle with a letter (or number) inside to uniquely identify it. Matching
circles and letters on another page identify the connection between pages. The connectors are joined to the
sequence of actions by activity edges.
Figure 13-19 shows an activity example with a named control flow (Save) highlighted on the right side of the figure,
and connectors (labeled A) that map the movement from the action "Display default Performances" to the action
"Select Performance."
Figure 13-19: Adding a control flow name and connectors.
Modeling decision and merge points
A common part of a control flow is the need to make choices. The ControlNode subclass DecisionNode provides
the means to specify a point at which the logic must choose between a set of mutually exclusive alternatives. A
decision node may have only one incoming activity edge (the exception is covered later in this section). It may have
two or more outgoing activity edges, but any given pass through the decision node may follow only one of the
available outgoing paths.
A guard condition on each outgoing activity edge identifies the condition under which each path may be taken. The
guard is a Boolean expression enclosed in square braces, such as [amount > 100], or [eventSelected], where
"eventSelected" is a Boolean value.
TipBoolean conditions are typically named, such as eventSelected. When the value is true the name is
present. When the value is false the name does not appear. So when a guard condition is modeled using
the name, it means that the Boolean expression must be true.
Figure 13-20 enhances the description of the use case Select Performance by adding a decision point where the
user decides whether to view the list of performances by event or by date range, select a specific performance, or
simply cancel without making a selection. Each option is mapped to a separate outgoing activity edge that leads
the user through a different control flow.
Figure 13-20: Adding a decision node to the Activity diagram.
NoteThere is no limit to the number of outgoing activity edges on a decision node.
Branching of this sort often leads to repetition in the flow of control. For example, in Figure 13-20, once a user asks
to see a new list of performances for the selected event, he wants to be able to choose a performance. The
diagram could copy the choice to select a performance and the actions to confirm and save the performance, but
they already appear on the diagram. If we could return the flow of control to the already defined decision node,
then the user not only would be able to choose a performance, but would also be able to select a different event,
select a date range, or simply quit.
The MergeNode provides a point where a flow of control can return to an existing activity edge to take advantage of
the existing flow of control from that point forward. Figure 13-21 adds a merge node so that once a user makes
one of the provided choices, he is returned to the same initial decision point. Note that a merge node is the
opposite of a decision node, that is, the merge node has many incoming activity edges and only one outgoing
activity edge. To complete the logic, Figure 13-21 also adds a decision after the action "Display Confirmation".
Figure 13-21: Adding a merge node to the Activity diagram.
NoteSo far in this section, the notation is the same as in UML 1.4. From this point on, the notations represent
changes introduced by UML 2.0.
Figure 13-21 illustrates another common occurrence in Activity diagrams, a merge immediately followed by a
decision. UML 2.0 enables you to combine the merge and decision nodes to simplify the diagram. In short, the
combined symbol enables many incoming activity edges and many outgoing edges. Figure 13-22 redraws the
merge and decision using this simplification alternative.
Figure 13-22: Simplifying the merge and decision node combination.
Modeling fork and join nodes for concurrency
An Activity diagram may model a process in which parallel processing is available. In fact, any logic sequence that
does not require a specific sequence may potentially be executed in parallel. The Activity diagram uses fork and
join notation to model parallel, or concurrent, processes or threads. Note the change from UML 1.4, which called
both the fork and join notation "synchronization bars."
A ForkNode is represented as a bar with one incoming activity edge and two or more outgoing activity edges. The
incoming edge is split into multiple outgoing edges that may execute in any order, including simultaneously. Any
data passed along the incoming edge is duplicated and a copy is passed along each outgoing activity edge.
A JoinNode is represented as a bar with two or more incoming activity edges and one outgoing edge.
Figure 13-23 changes the Select Performance Activity diagram to show that the first two actions do not have to
happen sequentially. They may, in fact, happen at the same time. To show this, the initial control flow enters a
ForkNode and splits into two separate flows. Once the two actions have completed, the two flows of control
synchronize and continue as a single flow of control. The synchronization is modeled as a JoinNode.
Figure 13-23: Activity diagram fork and join notation.
Technically, the specification allows the modeler to combine the fork and join nodes to model a situation where the
synchronization of a set of threads or processes is immediately followed by spawning multiple new threads or
processes. Figure 13-24 models the combined notation.
Figure 13-24: Combined fork and join notation.
Modeling object nodes and object flows
A flow of control includes two types of flows (activity edges): ControlFlow, discussed earlier in the "Modeling activity
edges" section, and ObjectFlow. An ObjectFlow supports passing data (tokens) from one action to another. The
data is contained within an ObjectNode.
An object flow is represented as an arrow. An object node is simply a rectangle with the name of the classifier.
Figure 13-25 adds the object nodes and flows to show that that when a user selects an event at the venue, the
event that he selects is passed to the "Display Performances for selected Event" action. Likewise, when a user
selects a date range or a specific performance, the selected or entered data is passed on to the next action.
Figure 13-25: Adding object flows and nodes to the Activity diagram.
Figure 13-26 shows three different ways to represent an object node - to identify a single object (token), a set of
objects, or a signal. A set of objects uses the same rectangle icon. The name must describe it as a set.
Figure 13-26: Three icons for object nodes.
Modeling action input and output pins
Actions are behaviors that work with data. Actions create, transform, and delete data, and in doing so, they may
pass data produced by one action as input to another action. This process is reminiscent of the classic input-
process-output pattern of functional modeling.
Input and output may be explicitly modeled using InputPins and OutputPins. Pins are object nodes that contain
values. The pin concept is borrowed from Action Semantics. Each input pin receives a single value. Input pins
correspond to the parameters passed to an invocation action. As such, the model assumes that the pins are
ordered just as the parameters are ordered. Also, because of this pairing relationship, the pins must be of the
same data type as the corresponding parameters.
Output pins represent values produced as the result of an action. The values are passed along an object flow to
subsequent actions.
Both types of pins are subclasses of ObjectNode, which is an abstract class that represents an instance of a
classifier, such as a piece of data or an object containing a set of data.
The notation for pins is a small square on the outside edge of an action. The name is placed next to the pin icon.
Figure 13-27 shows examples of pin notation. The recommended notation is a separate icon for each pin.
Oftentimes, though, an output pin on one action corresponds to an input pin on the next action in the flow, and in
those situations, the two pins may be combined into a single icon in the middle of the flow between the two actions.
Figure 13-27: Notation for input and output pins on actions in an Activity diagram.
The alternative forms for a combined output/input pin in Figure 13-27 are the same as the notation for an object
node as modeled in Figure 13-25.
Modeling activity groups
An ActivityGroup is an abstract class that supports the identification of a set of activities and activity edges,
including possibly other activity groups, and actions. It is a simplification mechanism for working with large sets of
behaviors. It also facilitates reuse of sets of behaviors in multiple contexts by grouping already defined behaviors
as a unit that may be inserted wherever applicable. Since the metaclass ActivityGroup is abstract, modelers don't
actually use a symbol called an ActivityGroup when modeling an Activity diagram. Instead, they use subtypes of
this type, such as Partition (described in the next section). The UML specification is open to being extended, so that
other types of ActivityGroups may be introduced into UML via profiles.
For example, the behavior of selecting seats in a venue is part of many functions such as allocating seats to agents
in a sales agreement, predefining groupings of seats as rows and sections in a venue layout, selecting seats for
removal when remodeling the venue, or disabling seats for maintenance or repair. In all these situations the actor
needs to select a group of seats that is then passed on to the rest of the process.
Since an activity group is an abstract class, there is no notation for it. However, the IntermediateActivities package
adds the concept of a partition that implements the group concept and a few more valuable concepts.
<Day Day Up>
<Day Day Up>
Exploring IntermediateActivities
The IntermediateActivities package adds partitions, data buffering, and the capability to terminate a single flow of
control within an activity or activity diagram. The IntermediateActivities package sits alongside the
StructuredActivities package, that is, they may be used independent of one another, but they both support
concurrency and may be used together or separately.
Modeling central buffer nodes
In many processes the flow of data comes from many sources or continuously from a single source. Downstream
actions may not be able to process the data as quickly as it is generated. To support queuing of data during a
process, the Activity diagram provides a CentralBufferNode, a type of ObjectNode. Unlike other object nodes that
support buffering, a central buffer node stands apart from any specific activity or action as a place to store data.
Output pins and input pins may then hook up to the central buffer node to provide or extract data as required by the
associated actions.
A central buffer node may receive data from any number of output pins and may provide input to any number of
input pins. Figure 13-28 shows a central buffer node used to receive orders from multiple Place Order actions and
to channel them to input pins on the Fill Order action. The central buffer node is an object node with the stereotype
centralBuffer.
Figure 13-28: Central buffer node.
Modeling activity partitions
An ActivityPartition provides an organizational view of nodes and edges within an activity, much like packages
provide an organizational view of classes and associations within a system. For example, a high-level activity such
as processing an order might include work performed by both the order processing and accounting staffs.
Initially defining the activity focuses on sequencing the tasks regardless of who performs them. For the tasks to be
implemented, though, they need to be assigned to someone. The actions that make up the complete activity of
processing an order cross the responsibility boundaries between two types of employees, order processing and
accounting. Activity partitions provide the visual means to map the actions into groups for each type of employee
that will be responsible for performing the tasks. Each activity partition models part of an activity and represents the
participation of some classifier.
NoteEarly in the modeling process, partitions often refer to organizational units. But as the model is refined to
provide greater detail, partitions may be used to assign responsibilities to specific classifiers, instances,
parts, attributes, and even values.
An activity partition is modeled as an area in which to draw actions and edges. Multiple partitions are modeled side-
by-side so that the edges can illustrate how responsibility changes hands across partitions. Figure 13-29 models
two partitions for the activity of processing an order. Once order processing has filled the order, accounting can
generate the invoice. When the payment has been accepted and the order has been shipped, the order may be
closed. Order processing takes responsibility for the tasks that involve physically handling the products. Accounting
takes responsibility for the tasks that involve recording the financial aspects of the transaction.
Figure 13-29: Two activity partitions for a single activity.
NoteThere is no rule about whether to align the partitions horizontally or vertically. Use the layout that makes
the presentation as clear and useful as possible for your audience.
Alternatively, partitions may be modeled using a label, enclosed in parentheses, on the actions. For example, the
Receive Order action is performed by the Order Department. So name the action "(Order Department) Receive
Order", as shown in Figure 13-30.
Figure 13-30: Alternative notation for activity partitions.
When modeling high-level activities, it is common to break down the larger processes into smaller, component
parts of the process. This hierarchical approach to modeling processes may be modeled by nesting partitions
within partitions as shown in Figure 13-31. There is no limit to the number of sub-partitions other than prudence
and your ability to deal with the complexity.
Figure 13-31: Modeling nested partitions.
OMG 2.0
The activity partition represents the model element that constrains the behavior of the partition and provides the
context for the behavior. Earlier I stated that as the model becomes more detailed, partitions may reference
individual classifiers. In Figure 13-32, the stereotype class is added to indicate that the classes Order Processor
and Accounting Clerk implement the responsibilities for the actions documented in each partition. The addition of
the stereotype does not change the meaning of the partition. It simply explains to the reader that she can find a
complete definition of an Order Processor and an Accounting Clerk in the Class diagram.
Figure 13-32: Modeling participation by an external entity.
In some processes, one or more actions may be performed by parties that are outside the scope of the modeled
system. These parties correlate to actors in a Use Case diagram. Even though they are outside the system, their
behavior is an integral part of the workflow and needs to be modeled. To indicate that an action is performed by an
external entity use a partition stereotyped as external, as shown in Figure 13-32.
NoteWhen the internal resources refer to automated portions of the system, this relationship between internal
resources and external actors is sometimes called the man-machine boundary.
Alternatively, you may apply the external stereotype to the individual action, as shown in Figure 13-33.
Figure 13-33: Alternative for modeling participation by an external entity.
The external stereotype is also represented as a property of a partition in the isExternal Boolean property.
An activity partition may also represent a dimension of the problem. A dimension is a highest-level view of the
activity that may contain partitions. It addresses a perspective on the activity as opposed to an assignment of
responsibility. For example, the order processing activity described in the earlier examples is actually performed at
different locations. The tasks are still the responsibility of the order processing and accounting staffs, but they are
distributed between the Seattle and Reno locations. Location is a second dimension of the Activity diagram shown
in Figure 13-34.
Figure 13-34: Adding a second dimension to the activity partitions.
UML 2.0
A true value for the isDimension property of an activity partition identifies the activity partition as a dimension. As
such, it may not be contained in another activity partition.
Modeling the flow final node
Occasionally a flow in an activity may terminate but the activity does not terminate. Other, concurrent flows in the
activity may run to completion or until their own individual termination point. The ActivityFinalNode terminates the
entire activity. The FlowFinalNode only terminates a single flow. When the flow terminates, all data associated with
that flow is lost. Model the flow final node as a circle containing an X.
Figure 13-35 models an activity in which components are built and installed. As long as there are more
components to build, the process keeps looping back to the build action. When there are no more components to
build, the flow to loop back ends but the installation flow runs to completion.
Figure 13-35: FlowFinalNode.
<Day Day Up>
<Day Day Up>
Exploring CompleteActivities
The CompleteActivities package continues to enhance the features of the Activity diagram by adding to the
definitions of activities, constraints on actions, behaviors for object flows, exception handlers, and more.
The CompleteActivities package provides an extended definition of an Activity to say that an Activity diagram will
only use a single copy of the activity. By default, the isSingleCopy attribute of an activity is set to false, which means
that each time the activity is invoked a separate instance of the activity is invoked. If the isSingleCopy attribute is set
to true, all invocations of the activity actually reference the instance of the activity, and all data passed to the activity
actually goes through a single copy of the executing activity.
For example, the theater system has to process payments. The default interpretation for the Process Payment
activity (isSingleCopy is false) generates a separate copy of the Process Payment activity for each payment so the
payment information for each payment is handled by a different instance of the activity, Process Payment. This
approach avoids bottlenecks because each Process Payment activity executes independent of every other
Process Payment activity. However, it pays for this independence with the added overhead of multiple copies of the
process.
An alternative is to designate a single copy approach to processing payments by setting the isSingleCopy attribute
to true so that submitted payments are queued up and processed one at a time through a single copy of the
Process Payment activity. The benefit is less processor overhead. The price of this approach is a greater likelihood
of a bottleneck as one payment waits for the previous payment to make it through before it has its turn.
Modeling constraints on actions
The execution of an action may be made contingent upon conditions in the system at the time of execution. The
CompleteActivities package provides an extended definition of an action that supports the addition of local pre- and
post conditions. The term local refers to the fact that these conditions apply only at the point in the control flow
where they are declared. They don't even apply to other executions of the same action in other locations in the
control flow. Put another way, local pre- and post conditions must be declared at each place in the flow of control
where they are to be applied.
The definition of pre- and post conditions with actions is consistent with the general usage found with Behaviors in
the CommonBehaviors package. Preconditions define the required state of the system when the action is invoked.
If the condition is not satisfied, the implementation must decide how to handle it. For example, the flow of control
could throw an exception or specify an alternative path.
A post condition specifies the required state of the system at the completion of the action. The pre- and post
conditions describe only those conditions that are specifically relevant to the current action. All other state
information is considered irrelevant for purposes of guarding the current action execution.
Figure 13-36 provides a template format for modeling pre- and post conditions on the left, and a sample set of pre-
and post conditions on the right. The Authorize CC Payment action will execute only if the condition inAmt =
totalOrderAmt is satisfied. When the action is completed, the order status must be set to PAID or the action fails.
Figure 13-36: Appling local pre- and post conditions to an action.
This approach to modeling pre- and post conditions does not explicitly describe how the implementation of the
system should handle the system's failure to satisfy these conditions. That decision needs to be supported by
whoever takes responsibility for implementing these constraints.
Pre-and post conditions may also be applied to an activity, as shown in the highlighted area of Figure 13-37.
Figure 13-37: Pre- and post conditions on an activity.
Modeling behavior on object flows
Using the new features defined in the CompleteActivities package, an object flow may be described in terms of
how upstream and/or downstream actions affect the object - whether the upstream action can create, read,
update, or delete it, for example. These options (create, read, and so on) are defined in the ObjectFlowEffectKind
enumeration. The allowed effect depends on the relationship between the object flow and the connected actions.
For example, only object flows with actions on the target end may have a delete effect, and only object flows with
actions on the source end may have create effect.
In Figure 13-38, the top illustration demonstrates input and output pin notation to show that Action1 reads (or looks
up) an instance of Order and Action2 deletes that instance. The bottom illustration uses the alternative pin notation
to show an example in which Action3 creates an instance of Order and Action4 updates that same instance.
Figure 13-38: Adding effects to an object flow.
Some modern applications use a "publish-and-subscribe" approach to broadcast information to a wide audience
versus a direct invocation on a specific object. The CompleteActivities package provides a simple means to model
the fact that actions from different partitions in an activity may send information via a multicast method, and may
receive information via a multi-receive method.
In Figure 13-39, for example, the Customer generates a number of Requests for Seats at Shows (RSS) that are
targeted to a number of different agents using a multicast approach. The Agents then respond by generating a
number of Ticket Quotes, which are accumulated using a multi-receive mechanism. A single object flow may use
only one of these features, either multicast or multireceive, but not both.
Figure 13-39: Modeling multicast and multi-receive mechanisms across partitions.
Sometimes it is necessary to filter the objects generated by an action or the objects provided as input to an action.
The selection criteria may be assigned to an object flow to implement the filter. The selection criteria are attached
to the object flow as a comment as shown in Figure 13-40.
Figure 13-40: Adding selection criteria to an object flow.
A selection criterion attached to an output flow filters the objects provided to the output flow. Selection criteria
attached to an input flow filters the objects provided to the target action.
Customizing an object node
When objects are passed from one step in an activity to the next, they can be sequenced to facilitate processing.
The ordering is achieved through an ordering property on the object node. The specific types of allowed ordering,
which are defined in the ObjectNodeOrderingKind enumeration, are:
unordered: No sequencing is specified. Objects are passed as they are produced.
ordered: Objects are sequenced by criteria defined in the selection property.
FIFO (First In, First Out): Objects are sequenced so that they are delivered in the same order in which they
were received and in a manner that ensures that tokens do not overtake each other as they pass through the
node.
LIFO (Last In, First Out): Objects are re-sequenced as they are created and passed on in the flow of control
and in a manner that ensures that tokens do not overtake each other as they pass through the node.
Ordering is specified using property notation next to the object flow icon as shown in Figure 13-41.
Figure 13-41: Specifying ordering on an object flow.
The model can limit the number of objects passed in an object flow by specifying an upper bound, also specified
using the property notation next to the object flow icon (see Figure 13-42). The example states that the object flow
called name may contain no more than 2 instances at any time.
Figure 13-42: Specifying an upper limit on an object flow.
Finally, an object node may be defined as a specific object type. The CompleteActivities package adds the
capability to define the state of the object at the point in the flow where the object node is defined as input or output
of an action. Figure 13-43 models an object node and the states in which the object may reside in order to be part
of the flow of control for the containing activity. The state specification acts like a filter on the objects passed along
the object flow.
Figure 13-43: Specifying the valid states of an object.
Modeling data stores
During the life of an activity, data is created, manipulated, deleted, and accessed to support the products and
processes of the activity. Some of that data is transient, that is, it only exists to support the process and is lost once
the process is completed. But other data must persist from one execution of the activity to another. Some data is
even created by one activity and later used by another activity. In order to preserve the data between executions,
there has to be a place to put it.
The DataStoreNode is a type of central buffer node that acts essentially like a file. Data (tokens) can be sent to the
data store where they are saved. When the data is needed for a downstream process, the data store creates a
copy of the data and sends it along the outgoing object flow. If a new version of a stored object is sent to the data
store, it replaces the older one, effectively updating the stored data. Selection criteria on the outgoing object flow
can filter data from the data store.
Modeling a data store node utilizes the stereotype datastore on the object node icon as shown in Figure 13-44.
The object flows leaving and entering the actions provide the effects of each action on the object node. Add
Customer creates new Customer objects that are captured in the Customer data store. Mail Promotion reads the
Customers from the data store in order to get the mailing address information to send out promotions for
upcoming performances. Change Customer Address provides the means to read an existing Customer object and
update the values for the mailing address information.
Figure 13-44: Modeling a data store in an Activity diagram.
Enhancing parameter features
The Activity diagram utilizes the definition of parameters from the Kernel and adds to it three new features:
isException, isStream, and parameterSet. Parameters may be applied to both actions and activities. A parameter is
a type of object node called an ActivityParameterNode.
The isException attribute applies only to output parameters. A true value states that the parameter may provide a
value even if the other parameters have not. The output from an action normally waits until all output parameters
have been generated, but an exception output parameter always flows to the next action as soon as it is generated.
The most common use of this technique is to identify problems that require all flows to be aborted except handling
the problem just encountered.
An exception parameter is modeled with a small hollow triangle near the activity parameter node, as shown in
Figure 13-45.
Figure 13-45: Adding exception parameter notation to an activity parameter node.
OMG 2.0 modified
The CompleteActivities package adds the capability to specify stream parameter values. Streaming describes the
flow of multiple data values into or out of a behavior. I use the term behavior instead of action because
parameters, and specifically the streaming property, may apply to both actions and activities.
In the case of stream input parameters, once all the input parameters of a behavior have been received, the
behavior begins execution. During the execution, the behavior may continue to receive values for the parameter.
Likewise, once all of the output values have been generated, a behavior may start sending the output values.
Output streaming means that multiple data values may be sent as output until all values have been sent.
The isStream attribute of a parameter is modeled as a property - {stream} - on the activity parameter node as
shown in Figure 13-46.
Figure 13-46: Modeling the stream property on an activity parameter node.
OMG 2.0
UML sets some additional rules for using streams:
All non-stream inputs must arrive for the behavior to be invoked. If there are only stream inputs, then at least
one must arrive for the behavior to be invoked.
All inputs must arrive for the behavior to finish, that is, all inputs must arrive for non-stream outputs to be
posted and control edges traversed out of the invocation of the behavior.
Either all non-stream outputs must be posted when an activity is finished, or one of the exception outputs must
be. (UML 2.0)
A ParameterSet is a group of parameters, either all input or all output, that belong to a specific action or activity.
Each set offers an alternative group of values that may be passed to the action or activity. A parameter set is
modeled as a boundary surrounding two or more parameter nodes as shown in Figure 13-47. Parameter Set1
includes two parameters, parameter Set2 includes three parameters, and so on. The action or activity may receive
either parameter Set1 or parameter Set2. It may produce parameter Set3, Set4, or Set5. Note that parameter Set4
and Set5 share a common parameter.
Figure 13-47: Defining multiple parameter sets for an action or activity.
OMG 2.0
If a behavior has a parameter set, any inputs that are not in a parameter set must be streaming. The same is true
for output parameters.
Enhancing the join specification
Simple join notation does not allow the modeler to evaluate the results of the multiple threads or processes. The
CompleteActivities package adds this ability in the form of a join specification, which offers the keyword and to
specify a combination of thread results that must occur together. The specification also supports a Boolean
expression that evaluates any number of data values to determine whether the results of the join may be passed
on in the flow. The notation does not explicitly address what happens when the condition is not satisfied.
In Figure 13-48, both flows A and B must be completed (this is the default for a join specification), and the join
specification "the total coin value inserted is >= drink price" must be true.
Figure 13-48: Modeling a join specification.
Every time a new token arrives at the join, the join starts to evaluate the specification. Once the evaluation begins,
any new data arriving at the join is ignored until the evaluation is complete and the outgoing data is accepted by the
receiving object node (pin, parameter, central buffer node, or data store node). Accepting the outgoing data must
take into account the upper bound of the receiving object node. That is, if the upper bound has been reached, no
more objects can be passed to the receiving object node.
Modeling interruptible activity regions
One feature missing from the UML 1.4 Activity diagram was the capability to interrupt the flow of an activity or
portion of an activity without explicitly choosing a location to provide an exit option. UML 2.0 adds this feature in the
form of an InterruptibleActivityRegion. An interruptible region is like an overlay on the Activity diagram. It
encompasses a set of nodes and edges and enables the flow to exit the set of enclosed nodes and edges at any
time during their execution.
A region is interrupted when a token crosses the boundary of the InterruptibleActivityRegion. Even though the
token has left the region the token is not terminated.
NoteAn interruption should only be used if the intent is to stop all flows in the region.
The interruptible activity region is modeled as a dashed rounded rectangle surrounding the set of nodes and edges
(see Figure 13-49). Exit from the region is achieved by one or more activity edges leaving the interruptible activity
region. The edges may be modeled as either jagged arrows (to emphasize the effect of the edge on the region) or
straight arrow (the standard notation for an activity edge). Both forms are modeled in Figure 13-49.
Figure 13-49: Modeling an interruptible activity region.
OMG 2.0
<Day Day Up>
<Day Day Up>
Defining Structured Activities
A structured activity defines a unit of functionality that appears only once within the model, that is, a structured
activity may only be a part of one activity and its execution is independent of all other parts of the model. The name
"structured activities" refers to the constructs commonly found in structured programming languages including
loops, conditions, and exception handling. Support for these concepts is provided by extending the Activity diagram
metamodel in the contents of three packages; StructuredActivities, CompleteStructuredActivities, and
ExtraStructuredActivities.
The Structured Activities package provides the basic definitions for loops and conditions.
The CompleteStructuredActivities package adds input and output pins to the loops and conditions to align
structured activities with Action Semantics.
The ExtraStructuredActivities package adds exception handling.
Modeling a structured activity node
The new structured activity concept replaces the nesting strategy that UML 1.4 implemented with a set of rules. It
does this by combining and specializing features from activity groups and executable nodes. The features of a
structured activity are defined within two packages, StructuredActivities and CompleteStructuredActivities. Figure
13-50 shows the metamodel from StructuredActivities with the key features highlighted with gray shading.
Figure 13-50: UML 2.0 metamodel for a structured activity as defined within the StructuredActivities package.
OMG 2.0
Working clockwise from the bottom left of Figure 13-50, the features are as follows:
A structured activity may belong to at most one activity.
A structured activity may define any number of variables that are exclusively owned and used by the structured
activity during its execution. For example, a structured activity can define variables to hold intermediate values
that are products of actions contained within the structured activity, and that must be passed between
embedded actions, but are never used once the structured activity is finished (and are never used by other
activities).
A structured activity node is a specialized type of activity group. As such it can contain other nodes, as well as
activity edges, with the one constraint that the nodes and edges can only belong to one structured activity. This
constraint is enforced by the specialized association between a structured activity node and activity nodes, and
between structured activities and edges shown on the right side of Figure 13-50. In addition, the edges in a
structured activity must have their source and target within the same structured activity.
A structured activity node is a specialized type of executable activity node. As such it defines a process, a set
of actions to transform input data (objects) and generate output data (objects). The difference is that activity
nodes contained within the structured activity may not execute until all of the object and control tokens have
been received. In a basic executable activity node actions may execute as soon as they receive their own
required inputs, regardless of whether other actions within the activity have theirs.
As a type of activity group, a structured activity may contain actions that require input and generate output.
However, the execution of the embedded actions cannot begin until the structured activity node has received
all of its object and control tokens. In the same manner, output tokens are not available to other nodes until all
embedded actions have completed execution. (These restrictions reinforce the definition of a structured activity
as "a structured portion of the overall activity that is not shared with any other structured node." This concept is
further reinforced by the mustIsolate attribute defined in the CompleteActivities package.)
The CompleteStructuredActivities package adds the mustlsolate attribute, which addresses the potential problems
that arise from the use concurrent execution. Setting this attribute to true means that any object used by an action
within the structured activity cannot be accessed by any action outside the structured activity until the structured
activity has ended. If any external concurrent actions need access to objects being used by the structured activity,
their execution must be deferred until the structured activity has completed.
CautionThe UML 2.0 specification is careful to reinforce the distinction between isolation and atomicity.
Isolation refers to keeping everything within a structured activity separate from everything outside the
structured activity. Atomicity refers to the execution of the activity, that is, either the entire activity
completes or it does not. Atomicity states that there is no option for partial execution. This is why
atomicity often implies the need for rollback logic, the ability to reverse the effects of a failed or partial
execution.
UML 2.0 models a structured activity as a dashed and rounded rectangle with the keyword structured used as a
stereotype at the top of the rectangle as shown in Figure 13-51. It may be used anywhere in an Activity diagram
where an activity can be used.
Figure 13-51: The notation for an activity (left-solid rounded rectangle) and a structured activity (right - a
dashed and rounded rectangle with structured at the top).
Modeling expansion regions and expansion nodes
The ExtraStructuredActivities package extends the definition of a structured activity to create a new concept called
an expansion region, which supports multiple executions of the same structured activity. A structured activity
executes once each time a set of tokens is passed to it. An expansion region can received a collection of input
values and execute concurrently, once for each member of the collection.
The collection of input values is defined as an expansion node. An expansion node is a type of object node that
manages multiple values much like a central buffer node, but it is specialized for use on the boundary of an
expansion region. Each execution of the expansion region can also generate output. The output is placed into an
expansion node that stores the collection of output values. Figure 13-52 models the relationship between an
expansion region and the expansion nodes for input and output.
Figure 13-52: The metamodel for expansion regions and nodes.
An expansion region may execute in any of three modes defined by the enumeration ExpansionKind; parallel,
iterative, or stream modes.
Parallel mode means that every input element is processed independently and concurrently. For example, ten
input elements from the input expansion node are processed by ten independent executions of the expansion
region, all running at the same time but not interacting with one another.
Iterative mode requires the expansion region to execute once for each input element but sequentially rather
than concurrently. Each execution waits for the previous execution to run to completion. The order of execution
is defined by the ordering of the input elements in the collection. When there is no ordering the order of
execution is undefined, and the order of execution can be different each time the expansion region is invoked.
Stream mode means that the expansion region executes once and processes each element in the order that it
appears in the collection. Stream mode works like a loop within the execution of the expansion region, one
pass through the loop for each element of the expansion node.
Figures 13-53 through 13-55 depict the notation for an expansion region. Figure 13-53 models an expansion
region as a dashed rounded rectangle with one of the three ExpansionKind values (parallel, iterative, or stream)
used as a keyword in the top left corner. Note that an expansion region is a structured activity but it does not use
the structured stereotype. The expansion nodes are modeled as segmented boxes, also called "list box pin"
notation, on the border of the expansion region. The actions that define the behavior of the expansion region reside
within the dashed border of the expansion region Activity edges (the arrows) map the path of data from the
expansion nodes to the pins on the actions (the boxes on the border of each action). In the example, there are two
actions within the expansion region: Get Prices from Tier and Apply Discount. The name of the
expansion region, "PriceSeat" in this example, appears at the top of the region icon.
Figure 13-53: Notation for an expansion region with input (top) and output (bottom) expansion nodes.
Figure 13-54 models an alternative notation for expansion regions that have only one action. The expansion region
and action borders are merged, leaving only the action border. The expansion nodes are placed directly on the
border of the action itself. There is no dashed border to represent the expansion region. The figure on the left is the
general notation. The figure on the right is an example from the theater system.
Figure 13-54: Notation for an expansion region with only one action.
NoteThe region pictured on the right side of Figure 13-54 contains only one action and executes in parallel.
This means that the action reserveShowSeats executes multiple times concurrently. Each execution
processes a different set of input values.
UML 2.0 offers an even simpler notation for an expansion region with only one action, executed in parallel mode,
and for an unlimited number of executions. The unlimited number of executions is designated with an asterisk (
*
),
the unlimited multiplicity notation, in the top right corner of the action, as shown in Figure 13-55.
Figure 13-55: Alternative notation for an expansion region with only one action, executed in parallel mode, and
for an unlimited number of executions.
Modeling conditional nodes
A conditional node is a specialized type of structured activity node that represents a choice in which only one
alternative can be selected. A conditional node defines one or more clauses. Each clause specifies a test and a
body. Each test defines an alternative and corresponds to a body, an activity that produces a result. Passing a test
means that the alternative is a valid choice. But regardless of how many alternatives are valid, only one may be
chosen.
Figure 13-56 shows the metamodel for conditional nodes. A conditional node is defined by two additional Boolean
attributes, isDetermined and isAssured.
Figure 13-56: Metamodel for conditional nodes.
isDetermined: A true value means that at most one of the tests will pass. False means that more than one test
can pass. It is valid to have more than one test pass, but even then only one alternative may be chosen among
the resulting valid alternatives.
isAssured: A true value means that at least one test will pass. A false value means that it is possible that none
of the tests will pass. When using a false value for isAssured, you should take care to ensure that this does not
result in a logic error for the activity.
The order of execution for the clauses within a conditional node can be defined using predecessor and successor
clauses. Predecessor clauses precede the current clause, must all run to completion, and must all result in a false
value before the current clause can execute. Successor clauses follow the current clause and can only execute
when the current clause has run to completion and results in a false value. If no predecessors or successors are
defined, the order of execution for the clauses is undefined. They can execute in any order, in fact, in a different
order each time the conditional node is executed.
In the event that none of the clauses within a conditional node returns a true value, the model supports the use of
an "else" clause the results in a true value every time. An "else" clause is a successor clause to all other clauses in
the conditional node.
A clause may contain zero or more test/body pairs. The most common usage is one pair. Each test yields a value
that is used to decide whether to execute the body. The value is stored in an OutputPin called the decider. Each
body can yield a value that is stored in a result, an output pin that holds the values for all test/body pairs for the
conditional node.
NoteIt is valid to use values from tests or bodies outside the conditional node. But if you do, the values must
be created in every clause to prevent undefined values.
UML 2.0 has not yet defined a notation for a conditional node, so Figure 13-57 uses an activity node and the
stereotype conditional. The SelectPerformanceOption conditional node could be expanded to show the activity
nodes that comprise the test and body sections. Look at Figures 13-58 and 13-60 for examples of how the
expanded version might look.
Figure 13-57: Interim notation for a conditional node, an activity node with the stereotype conditional.
The CompleteStructuredActivities package adds one more feature to conditional nodes, the capability to yield
multiple clause results. For example, if the isDetermined attribute is false, it is possible for more than one test to be
true, so more than one body activity can be performed. Each body activity can produce a result. The results from
all executed body activities can be stored in a result output pin and passed along to downstream activities. The
result output pin is separate from and in addition to the decider pin. The sum of all clause results from the same
conditional node defines the conditional node result.
Modeling loop nodes
A loop node is a specialized structured activity that defines a set of features to manage functions that need to be
performed repeatedly. The loop node is made up of a setupPart, test and body pairs with a decider, and an output
value (result) used to decide when to exit the loop. Each of these elements is a separate sub-region within the loop
node. Each contains one or more activity nodes and edges.
The setupPart is executed once immediately upon entry into the loop node. It contains the nodes and edges
that initialize the objects used in the execution of the loop.
The test/body pairs execute after the setupPart and until the tests result in a false value. Each body executes
as long as the corresponding test is true. Each test contains the nodes and edges that perform the processes
or computations needed to determine whether the body should be executed again. Each body contains the
nodes and edges required to fulfill the objectives of the loop.
The decider contains the value resulting from the last test and body executed within the loop.
The isTestedFirst attribute defines whether the tests are executed before or after the body activities. A true value is
comparable to a "do while" loop, which might never enter the loop if the test does not result in a true value on the
first pass. A false value is comparable to a "do until" loop, which ensures that the loop will always execute at least
once.
Figure 13-58 shows the metamodel for the loop node as it appears in the StructuredActivities package, with the
setupPart, test, and body activity nodes, and the decider output pin.
Figure 13-58: The StructuredActivities metamodel for a loop node.
OMG 2.0 modified
The notation for the loop node is not defined yet in the UML 2.0 specification, so Figure 13-59 uses the notation for
a structured activity, using stereotypes for the loop, and the loop elements (loop setup, loop test, and loop
body). Note that each section within the loop is bounded by a front end node and a back end node. These nodes
represent the entry and exit points for each section. Although the example does not show it, a loop may contain
many test/body pairs.
Figure 13-59: Loop node notation with nested setup, test, and body activity nodes.
The CompleteStructuredActivities package adds loop variables and a result to manage the data moving into and
out of the loop, as pictured in Figure 13-60.
Figure 13-60: The metamodel for a loop node as extended in the CompleteStructuredActivities package.
OMG 2.0 modified
The loopVariableInput pins are optional. They contain values passed into the loop and stored in the loopVariable
pins. The values in the loopVariable pins are passed to the test and body activity nodes before the first iteration of
the loop. Each execution of a body activity node uses the loop variables and stores the resulting values in the
bodyOutput pins. Each execution of the body activity node overlays the values in the bodyOutput pins. When the
loop test fails, the values are copied into the result pins as the net output of the loop.
For example, a loop to compute the value of all the show seats on an order might receive input variable values,
including a set of show seat objects, and a loop counter set to zero. Each iteration of the loop tests to see whether
the set of show seats has any more entries. As long as the set is not empty the body executes and increments the
loop counter to indicate the number of show seats processed.
Figure 13-60 shows the metamodel for the loop node found in the CompleteStructuredActivities package.
UML 2.0 has not yet defined a notation for these addition features for the loop node so Figure 13-61 uses tagged
values for the variables and results.
Figure 13-61: Notation for a loop node with inputVariables and results.
<Day Day Up>
<Day Day Up>
Summary
The UML 1.4 Activity diagram is the UML version of the classic flowchart. It may be applied to any process, large or
small. Three common applications of Activity diagrams are to explain workflow (a series of Use cases), to explain a
single Use case, and to explain a method.
The Activity diagram represents a task as an activity drawn as a rounded rectangle containing a freeform text
description of the task. An activity represents an ActionState. The transition from one activity to the next is
shown as an arrow. The notation provides for start and end points, using a dot and a bull's-eye, respectively.
Model decisions with a diamond. Each transition exiting the decision must be labeled with a guard condition,
and the conditions must be mutually exclusive. The diamond may also be used to represent a merge point,
joining two or more alternative paths in the sequence.
Guard conditions may also be used on transitions leaving an activity, where the result of the activity provides all
the information needed to meet one of the conditions.
Concurrency describes multiple threads or processes executing simultaneously. The fork bar shows one
transition initiating multiple transitions. The synchronization bar shows multiple transitions coming to an end
and one new transition taking over.
Often, text can be a bit too ambiguous for defining a complex process. The UML 1.4 version of the Activity diagram
offers a visual alternative that also supports common programming constructs. As such, it bridges the gap nicely
between user requirements and programming requirements.
To translate the user description into an Activity diagram, isolate each task as an activity. Indicate the
sequence of the tasks by drawing a transition arrow from one activity to the next activity in the sequence.
Multiple processes may take place at the same time. Model them using the synchronization bar to either
initiate multiple processes or merge multiple process.
To model decisions in the process, you have two options. A decision that results from the completion of an
activity is drawn using guard conditions. Each transition out of the activity is labeled with a unique (mutually
exclusive) conditional expression enclosed in square brackets. For a decision that is not the result of one
specific activity, use the diamond icon. Each transition out of the diamond decision point is also labeled with a
unique conditional expression enclosed in square brackets.
When the logical flow of the process needs to return to a previous point in the flow, use the diamond icon as
the merge point diamond. There may be two or more arrows entering the merge point but only one exiting the
merge point.
End points are drawn using a bull's-eye symbol. There may be as many end points as the logic requires. In
practice, there should be one transition to an end point for each use case termination option.
The UML 2.0 specification includes the concepts defined in UML 1.4 but refines the metamodel to separate the
concepts from the state machine metamodel and to refine and clarify the concepts for an Activity diagram. UML
2.0 has also added new concepts to address limitations that no longer exist now that the Activity diagram
metamodel is distinct form the State Machine diagram metamodel. The new concepts include pins, flow final
nodes, combining decision and merge nodes, buffers and data stores, streaming parameters, and interruptible
regions.
Activity, Action, ActivityEdge, and Parameters: An activity is a set of one or more actions and the paths (edges)
that direct the flow from one action to the next. Parameters may be directed to an activity to customize the
behavior of the activity.
Action, InputPin, and OutputPin: An action is usually an atomic unit of work, except when it is used to invoke an
activity. Input and output pins define the data elements passed into and out of the action.
InitialNode: The initial node designates the start of an activity flow.
ActivityFinalNode and FlowFinalNode: A final node designates the end of activity. An activity final node ceases
all actions and flow of data in an activity. A flow final node designates the end of a single flow within an activity.
ActivityPartition: An activity partition identifies a set of nodes and edges within an activity that are assigned to a
classifier. The classifier is responsible for the implementation of the behavior described by the nodes and
edges. Partitions are sometimes referred to as swimlanes.
Decision: A decision node provides a branching mechanism in the activity flow. Each path out of a decision
node is mutually exclusive. UML 2.0 allows the decision and merge nodes to be combined in a single icon.
Object nodes and object flows: An object node identifies a type of object passed along a flow. An object flow
directs the delivery of an object node from an action or to an action.
ForkNode and JoinNode: Fork and join nodes model concurrent behaviors. The fork defines the point at which
multiple concurrent threads or processes are initiated. The join defines the point in the flow where the multiple
threads or processes are synchronized.
CentralBufferNode and DataStoreNode: A central buffer node queues up objects from one or more sources
and provides them to one or more actions. A data store node is a type of central buffer node that provides
persistence for objects in an object flow.
Constraints on actions and activities: An action or activity may be bounded by pre- and post conditions.
Preconditions must be satisfied before the action/activity can execute. Post conditions must be satisfied when
an action/activity is completed.
Behavior on ObjectFlow: An object flow may specify the effects of actions such as create, read, update, and
delete on the object flow. An object flow may also be designated as either multicast or multi-receive in a
publish-and-subscribe model.
Exceptions and streaming parameters: Exception and streaming properties refine the description of a
parameter. isException allows a parameter to be passed even though all of the other, non-exception
parameters have not been generated. The isStream property defines a parameter as a series of values
passed into or out of an action during the execution of the action.
InterruptibleActivityRegion: An interruptible region defines a set of nodes and edges that may be exited at any
time during their execution in response to an event.
Structured activity: A structured activity defines a unit of functionality that appears only once within the model,
that is, a structured activity may only be a part of one activity and its execution is independent of all other parts
of the model. Structured activities are specialized into expansion regions, conditional nodes and loop nodes.
Expansion node: An expansion node supports multiple executions of the same structured activity. Values are
passed into and out of the expansion region through expansion nodes. An expansion region may execute in
parallel, iterative, or stream modes.
Conditional node: A conditional node is a specialized type of structured activity node that represents a choice
in which only one alternative can be selected. A conditional node defines one or more clauses. Each clause
specifies a test and a body. A conditional node defines two additional Boolean attributes, isDetermined and
isAssured.
Loop node: A loop node is a specialized structured activity that defines a set of features to manage functions
that need to be performed repeatedly. The loop node is made up of a setupPart, test and body pairs, and an
output value (decider) used to decide when to exit the loop. Each of these elements is a separate sub-region
within the loop node. Each contains one or more activity nodes and edges.
<Day Day Up>
<Day Day Up>
Part V: Modeling the Application Architecture
In This Part
Chapter 14: Using Packages
Chapter 15: Modeling Software Using the Component Diagram
Chapter 16: Using Deployment Diagrams in UML 1.4
Chapter 17: Representing an Architecture in UML 2.0
<Day Day Up>
<Day Day Up>
Chapter 14: Modeling the Application Architecture
Organizing your work is one of the most important things that you do. There are a number of devices presented by
UML to help you organize packages, systems, subsystems, and models. This chapter introduces those devices
and provides an overview of the Rational Unified Process (RUP) approach to organizing your work.
Modeling Packages
The package is the main construct in UML for grouping model elements. A package provides exactly the same
functionality as a folder in Windows. It enables you to organize elements by grouping them and placing them into a
container. Packages can contain other packages, so you can create a hierarchy of packages.
Cross-Reference Chapter 3 provided a brief introduction to packages, so some of this material may sound
familiar. This chapter delves into the specifics of packages and organizing your work.
Namespaces
A package also provides a namespace for classifiers that you place in the package. The word namespace is
familiar to C++ programmers. It means that once you place an element of a certain type in a package, its name
becomes unique for an element of that type in that package. You may create an element of the same name in a
different package, and it will have a different definition. Again, think in terms of Windows Explorer: You can have a
word document named UML_Bible.doc in a folder named X that contains completely different contents than a
word document named UML_Bible.doc in a folder named Y, or in a folder named Z placed within the folder named
X. The two documents have the same name, but because they are in different folders, they are completely
independent of one another.
Each package has an associated namespace. Namespaces of packages at different levels of the containership
hierarchy can have the same name as well. For example, you can have a package named X placed within a
package named X. The two packages are distinct and contain different contents. A package cannot contain itself.
Figure 14-1 shows a package X contained within another (different) package X.
Figure 14-1: Folder structure in Windows.
Package notation
A package is represented by a folder symbol. The name of the package may be placed in the middle of the
symbol, or in the upper left-hand tab of the package, as shown in Figure 14-2. It is normally placed in the tab if you
are drawing the contents of the package within the package symbol itself.
Figure 14-2: Package notation.
A package may be stereotyped, in which case the stereotype is listed within guillemets above the package name. A
package may also be abstract, which is notated with the word {abstract}, including the curly brackets, placed below
the name.
What a package contains
A package is simply a general grouping mechanism in which you place UML classifiers such as class definitions,
Use Case definitions, state definitions, relationships between these classifiers, and the diagrams on which these
classifiers may be represented. There are three types of elements that you can put in a package-elements owned
by the package itself, elements merged or imported from another package, and elements accessed from another
package, which basically visit the current package. Merge and Access relationships between packages are
discussed in the next section.
Other packages may exist within a package, to an infinite nesting, each package providing a unique namespace to
all elements within it. A package may also contain multiple diagrams of any and all UML types.
Notation for showing elements of a package
To show that an element belongs to a package, you can create a hyperlink from it to another diagram, and show
the contents of the package on that diagram. This is typically how you represent the contents of packages in
modeling tools. Or, you may simply draw the elements within the large rectangular portion of the package symbol,
as shown in Figure 14-3. An alternative notation is to draw the elements outside the package symbol, and attach
them to it with lines that are grouped at the package end by a circle with a plus mark (+) inside, also shown in
Figure 14-3.
Figure 14-3: Various notations for drawing a package and elements (classes in this example) within it. The
package on the far left has a hyperlink to another diagram (not shown).
Most of the time you will use a modeling tool to draw elements on a diagram that belongs to the package.
Remember that some elements, such as requirements or class attributes or methods, are not represented
graphically on diagrams. Once drawn on a diagram that is within a package, those elements, including other
packages, become contained within the package. You are, in essence, creating hyperlinks from a package symbol
to diagrams created for the package that show the information in the package expressed graphically. As you build
diagrams and packages in this fashion, the modeling tool presents the structure of your packages in a Windows
Explorer-like browser, as shown in Figure 14-4. Each package contains UML elements or definitions, and diagrams
of various types on which these definitions may be represented.
Figure 14-4: Package structure shows the organization of the project.
Classifiers contained in a package have a property that establishes whether they are visible to classifiers in other
packages. This visibility can either be public or private:
Public (+): a public classifier is visible to classifiers in other packages that have an Access or Merge
relationship to the package containing the public classifier. It is, of course, visible to other classifiers in the
package in which it resides. Public visibility is denoted by a + (plus) symbol preceding the name of the
classifier.
Private (- ): a private classifier is visible only to classifiers in the package in which it resides. It is not visible to
classifiers in other packages. Private visibility is denoted by a - (minus) symbol preceding the name of the
classifier.
Some modeling tools enable you to show or hide classifiers of a package based on visibility. For example, a tool
may enable you to turn off display of private classifiers so that only public classifiers are shown in a package.
Modeling package dependency
As you model, you often build relationships between a classifier in one package and another classifier in a different
package. To model this on a diagram belonging to one of the packages, you need to either access or
import/merge the classifier from the second package.
Access
When you access a classifier in another package, that classifier stays in its package, and you simply build a
relationship to it. You draw a classifier in the package in which you are working and show that it belongs to a
different package by specifying the name of its package before its name, as PackageName::ClassifierName. As
you draw this relationship between the classifiers of the different packages, you are also modeling that the source
package has an Access relationship to the second, or target, package.
An Access relationship between two packages is drawn as a dependency line-a dashed arrow with open
arrowhead-labeled with the stereotype access. It establishes the fact that all classifiers in the source package
can legally reference public classifiers in the target package. It isn't mandatory to draw the Access relationship
between packages before you draw relationships between their classifiers-you can draw the relationship between
the classifiers first. Some modeling tools automatically draw the corresponding Access relationship between the
packages after the relationship between the classifiers is drawn.
In the example shown in Figure 14-5, a class Overnight_Shipment of the package Product Orders has an
association to the class Manager of the Human_Resources package. This association is allowed because an
Access relationship has been drawn from the Product Orders package to the Human_Resources package.
Figure 14-5: The Overnight_Shipment class has an association to the Manager class of the
Human_Resources package because its Product Orders package has an Access dependency relationship to
the Human_Resources package.
NoteIt's important to remember that for the relationship between the classifiers to be drawn, the access
(public or private) of the classifier in the target package must be sufficient. If it is in a different package, it
must have public access.
Merge and Import
UML 1.x enables you to specify an Import relationship between packages, meaning that you can bring a copy of a
classifier from another package into the package you are working in. The new copy of the imported classifier
belongs to the package that you imported it into, while its original version still exists in its original package.
In UML 2.0, the Import relationship between packages is subsumed in the Merge relationship. Merge takes into
account the fact that you need to resolve name conflicts when importing some classifiers. It specifies how to
handle a situation where you merge in a class named Customer from another package, but your package already
contains a class named Customer, with its own set of properties. Merging classifiers from other packages is an
advantageous thing to do. As you and others model, multiple elements of the same name that mean the same
thing may be created in different packages. Merge enables you to specify that these elements get merged into the
package that you are working.
For example, say you are working with the Manager class in the Product Orders package, and there is another
Manager class in the Human_Resources package with its own set of attributes and methods and values for other
properties. Yet the Manager class is really meant to be the same class in both cases. As you model in the Product
Orders package, you may opt to merge the other definition of the Manager class into the package in which you're
working, as shown in Figure 14-6.
Figure 14-6: Example shows packages before merge and after merge.
The Manager class in the Human_Resources package has the attributes Name, which is of type character and
length 26, and Employee_Number. The Manager class in Product Orders package has a Name attribute of type
character and length 52. When the Human_Resources package is merged into the Product Orders package, the
Manager class in Product Orders inherits the Position attribute from Human_Resources::Manager. Since it already
contains a Name attribute, it overrides the definition of the Name attribute from the Manager class of the
Human_Resources package, so its type remains character of length 52. Although not shown in the figure, each
class also has a description tagged value, for which Product Orders::Manager keeps its own value, overriding the
description value merged over from the Manager class in Human_Resources.
When this merge takes place, the Manager class in the Product Orders package can be considered to be a
specialization of the Manager class in the Human_Resources package. The Manager class inherits the other
class's attributes, and overrides the types and values of any common attributes. In fact, you can consider drawing
the Merge relationship between two packages as a shortcut way of drawing an inheritance relationship between
the classifier in one package and the classifier of the same name that you are merging in from another package.
A Merge relationship between two packages is drawn as a dependency line-a dashed arrow with open arrowhead-
labeled with the stereotype merge.
Deleting a package
When you delete a package, you delete all the elements contained by it that it owns, including nested packages
and their owned elements. Elements that are "visiting" from another package via an Access relationship are not
deleted; they still exist in their owning package. Elements that have been merged in from an outside package will
still exist in their original package. Elements of the deleted package that are being used in other packages, through
Access or Merge relationships, are deleted from those packages.
NoteDeleting a diagram does not delete the elements that are represented on the diagram. They will still exist
in the package.
The Package diagram
A package can contain any number of diagrams of any UML type. One particular diagram type that has caused
some confusion among UML modelers is the Package diagram. In UML 1.x, the Package diagram is not specified
as a diagram type. It is simply a static diagram, such as the Class diagram, on which you draw only packages.
UML 2.0 clarifies the issue, specifying a Structure diagram. If you draw mainly packages on it, you can call it a
Package diagram. If you draw mainly classes on it, you refer to it as a Class diagram. If you draw Objects on it, it is
an Object diagram. If you draw a combination of all three, then you can call it what you like.
Drawing a Package diagram is optional. You don't need to create a diagram that shows subpackages of a
package unless you explicitly wish to show their containment, or wish to draw relationships between the packages.
To express containment of subpackages within a package, you can also simply define these relationships and rely
on your modeling tool to reflect the hierarchy of your project's packages in its browser. Figure 14-7 shows a Class
diagram for the package Use Case Model. On the diagram workspace, the subpackages of the Use Case Model
package are drawn. Since only packages are drawn, you can consider this a Package diagram. The diagram
would not normally be necessary because the package hierarchy is shown in the browser at the left. However, in
this case, the diagram provides a value add, since it also shows an access relationship between the Product
Orders package and the Human Resources package.
Figure 14-7: Package diagram is drawn using a Class diagram. It shows all subpackages of a package.
<Day Day Up>
<Day Day Up>
Modeling Subsystems
While packages simply provide a general grouping mechanism, subsystems provide a very specific grouping
mechanism. During design, you use subsystems to break your models up into manageable pieces. Unlike
packages, each subsystem provides behavior that you can denote by specifying interfaces to the subsystem and
the operations that the subsystem performs to support those interfaces.
In UML 1.x, a subsystem is a type of package. In UML 2.0, a subsystem is changed to be a type of component. It is
generally modeled as a larger composition than a com-ponent. While a component is physically instantiable, a
subsystem is typically abstract (although you can make a subsystem instantiable). You can specify required and
provided interfaces for subsystems that enable you to piece them together. The subsystem stereotype is used
for the highest-level component representing a physical system; UML does not specify a system stereotype.
Examples of software systems are payroll, human resource, order-entry, and reservation systems. Each of these
systems is modeled as a component of stereotype subsystem and can be further divided into lower-
levelsubsystems-for example, subsystems for a reservations system might be Authorization, Credit, and Billing.
Subsystem notation
In UML 1.x, because the subsystem is considered a type of package, its symbol looks like a special type of
package symbol. In UML 2.0, the subsystem's definition is changed to that of a component, so its symbol is drawn
as a special type of component-a rectangle with stereotype subsystem, or a rectangle with a fork placed in the
upper right corner, as shown in Figure 14-8.
Figure 14-8: Alternative notations for subsystem grouping mechanism, which is a stereotype of a component
in UML 2.0.
Interface notation
Because a subsystem is a type of component, you can draw provided and required interfaces for it. This enables
you to connect subsystems together through a ball-and-socket manner. A provided interface is represented by
either drawing an interface lollipop symbol on the subsystem rectangle, or drawing the interface as a regular class
symbol with an instantiates line (dashed line with open arrowhead) from the subsystem to the class. A required
interface is drawn as a socket, or lollipop with an open half circle emanating from the subsystem rectangle. Figure
14-9 shows that the Product_Order_System subsystem provides an OrderEntry interface, and requires
Check_Product_Ship_Status and Check_Client_Credit interfaces.
Figure 14-9: Provided and required interfaces of subsystem components can be connected together in a ball-
and-socket-style manner.
Subsystem compartments
You may divide the rectangular subsystem symbol into two compartments, one for Specification elements (left
compartment), and one for Realization elements (right compartment).
Specification elements
In the specification compartment, you literally draw elements that specify what the subsystem provides to the
outside world in terms of behavior. This is the specification of the subsystem. You can draw any UML element in
this compartment. Typically, use cases and Activity diagram flows are drawn to show the specification for high-
level subsystems, and interface classes or State diagrams are drawn to show the specification for lower-level
subsystems. Place a specification stereotype at the top of the compartment.
Realization elements
In the realization compartment, you draw the internal elements that realize the specification elements. These
elements may be any UML classifiers. Typically you realize the subsystem with smaller subsystems, components,
classes, use case realizations, and so forth. You label the compartment at its top with a realization stereotype.
You may optionally draw realizes relationship lines between elements drawn in the realization compartment and
the specification compartment.
You may hide either or both compartments if you are presenting the subsystem symbol as an independent entity in
a drawing. You may also not show the compartments, and instead provide each element drawn in the subsystem
rectangle with a specification or realization stereotype.
Figure 14-10 shows a simple example of a subsystem for a product orders system. Use cases and an activity flow
are used to show the specification of what the subsystem provides. Portions of a Class diagram, and a Use Case
realization for Order Product (oval symbol with dashed outline) are part of the realization of the subsystem.
Provided and required interfaces are also shown.
Figure 14-10: Subsystem contains specification and realization compartments.
<Day Day Up>
<Day Day Up>
Modeling Models
The word model used in this section has a more specific meaning than the word normally does when discussing
UML models. Model is a stereotype that you apply to a package to signify that it is a complete view of the system
from a particular perspective. A package of stereotype model is an overall grouping of other packages and
subsystems used to represent a particular view of a real-world physical system. You can build many model views
of a physical system, each for a different stakeholder. For example, if you were to create models of a hotel
reservation system, you might have a business-model view for management, a logical-analysis view and a
physical-design view for programmers and database analysts, and an implementation view for the information
technology (IT) people. Your goal for modeling the business-model view would be to create a complete
representation of the business from a manager's perspective-it would detail the people involved and the business
process flows that occurred. However, the business-model view wouldn't detail the programming code that ran the
applications. That information would be provided in the physical-design view for programmers and database
analysts.
You could compare a model view with the various drawings used to architect a building. There are physical
building blueprints, electrical design schematics, plumbing schematics, and so forth, each providing a complete
model of the physical building, but a different view. Each view is created for a different stakeholder.
A model is drawn as a package symbol with either a model stereotype or a triangle icon in its upper right-hand
corner, as shown in Figure 14-11.
Figure 14-11: UML notation for a model is either the model stereotype for a package or the triangular icon
on a package.
A model can contain other models, packages, and subsystems. In Figure 14-11, the model for a Product
Company contains a Use Case model, an Analysis View model, a Design View model, and an Implementation
View model. Each of these models contains packages or subsystems, which are not shown in the figure.
<Day Day Up>
<Day Day Up>
How to Organize Your Packages
You categorize models of a real-life system with a combination of model packages, subpackages, subsystems,
and components. The ways to organize your work are limitless. The UML specification does not provide a method
for categorizing your work. There are a number of published methods you can follow such as the Rational Unified
Process (RUP), Catalysis, Shlaer/Mellor, the ICONIX Unified Object Modeling Approach, and others. In addition,
many organizations have developed their own approaches to categorizing and building models.
As a representative example, this section provides a high-level summarization of the RUP approach to organizing
your work with packages and subsystems. The RUP offers a step-by-step process for analyzing, designing,
implementing, and testing systems to support the processes of a business. This section focuses on creating
packages for the Use Case, Analysis, and Design models. Creating the Implementation and Testing models is
considered outside the scope of this book.
Establishing the Models and Views
At the highest level, you use models to categorize your business systems. According to RUP, you build models to
support the following views:
Use Case Model for the Requirements View. Presents the business analysis and contains all of the Use
Cases that describe the functional requirements of the business domains.
Analysis Model for the Analysis View. Includes packages containing a mixture of UML diagram types that
describe how the systems of the business are logically constructed.
Design and Deployment Models for the Design View. Contains subsystems, components, and design
classes that represent the design of the system. If you are following OMG's Model-Driven Architecture, the
Design Model does not provide platform-dependent details. It is a further refinement of the Analysis Model and
differs from it in how you name classes (for example, remove embedded spaces from less formal analysis
class names), and how you structure classes and components together to address design constraints.
Implementation Model for the Implementation View. Contains models representing the actual
implementation of the systems that support the business. This model also contains the actual code and
databases that comprise the systems, which means that some of this view is contained outside the modeling
tool.
Testing Model for the Testing View. Contains the test models for the systems that were built to support the
business. A test model is a collection of test cases, test procedures, and test components that describe how
the artifacts of the Implementation Model can be tested to see if they conform to the requirements put forth in
the Use Case Model. The Testing Model is generally housed outside of a modeling tool.
Step 1: Building the Use Case model
You begin the RUP by establishing all of the use cases for your business. The use cases represent the
functionality that the systems of the business provide to external customers. You model the use cases in terms of
how the customer, or other external actors, sees the system. You provide a description for each use case, and in
so doing use the language of the customer. This is typically a flat view of the system from the customer's
perspective. There is no real need for you to group the use cases into packages, since this would reflect how the
business is arranged, and the customer does not see this.
Step 2: Building the Analysis model
During analysis you look at the system in terms of how you will build it. Instead of using the language of the
customer, you use the language of the developer. You start analysis by categorizing your use cases into packages
that reflect the structure of your business. Reexamine the use cases to add details necessary to actually
implement them, and while you are doing so, you find the analysis classes of the system, and their relationships to
one another.
Perform architectural analysis
Begin with architectural analysis, wherein you group the use cases into packages. You can physically place a copy
of all use cases into the Analysis model. Put use cases that provide related functionality-those that are involved in
the same business process, or that communicate with the same actor, or that are related to one another through
extend or generalization relationships, for example-together in a package. Figure 14-12 shows example use cases
for a hotel business grouped into packages for Room Reservations, Conference Room Bookings, and Rewards
Program Administration.
Figure 14-12: Initial packaging of use cases during architectural analysis.
Once you establish a first cut of your packages, you refine those packages to make them strongly cohesive and
loosely coupled. There is a fine art to making a system properly cohesive and coupled. You componentize the
system so that you can replace functionality in the future by simply replacing a package. You build a set of
packages that are coupled together. At the same time, try to make each package strongly cohesive so that it
doesn't depend on too many other packages. Too many dependencies means that a change to one package will
ripple to any package that depends on it.
There are three techniques for refining packages. First, examine the packages to see if there are use cases or
classes that exist in multiple packages. If there are, think about reducing this commonality by breaking those use
cases out into their own package. This loosens the coupling of the packages and helps keep future changes
localized to one package.
Second, see if there are any packages with use cases that perform a basic service to other packages. These are
considered service packages. You may have a use case with associated classes in one package that works
together with a use case and associated classes in another package to perform a service. Group these use cases
together in one package and let other packages use its services. In the hotel example shown in Figure 14-3, the
Accounts Payable package includes the use cases Check Customer Credit and Invoice Corporate Client. It is a
service package. Creating service packages is another way to loosen the coupling of packages to provide reuse
and localize future changes.
Third, evaluate the dependencies between packages. Keep package dependencies at a minimum, so that a
change to the functionality of a package doesn't require that changes be made to dependent packages. If a
package has use cases that are more strongly related to use cases in another package than the ones in their own
package, move those use cases to that package. This improves cohesiveness. Aim for cohesive packages in
which the use cases are strongly related.
During architectural analysis, you also examine the system for special requirements, which encompass features
like on-line security, distribution of the application, persistence of classes, and transaction management. Create
packages for each of these special requirements. In Figure 14-13, packages for database access and on-line
security are added.
Figure 14-13: Regrouped packages. Analyze use cases.
During this stage of the RUP, examine each use case to determine how it will be realized. Examine each use case
description with an eye on modifying it to add details that are necessary to implement it, using the language of the
developer. A use case that has been modified in this way is referred to as a use case realization and is often
denoted by changing the use case's look to that of a dashed oval. Then "walk" each use case description, and
model the analysis classes necessary to make the scenario happen, developing boundary, entity, and control
classes on a class diagram for each use case. This is sometimes referred to as robustness analysis.
Cross-Reference Table 21-1 in Chapter 21 provides more information on the UML Profile for Business
Modeling, and use of boundary, control, and entity classes.
The ICONIX Unified Modeling Approach can be used in conjunction with RUP at this point. The ICONIX approach
adds some important constraints to remember during this analysis that will help you understand the problem at
hand: An actor (drawn as a stick figure) can only talk to a boundary class (drawn as a circle with a vertical bar
attached to its left side). A boundary class can only talk to an actor or control class (drawn as a circle with an arrow
drawn in its upper right corner), not directly to an entity class (drawn as a circle sitting on a horizontal bar). An entity
class can only talk to a control class. Figure 14-14 shows some of the analysis classes found by walking the use
cases in the Room Reservations, Conference Room Bookings, Rewards Program Administration, and Accounts
Payable packages.
Figure 14-14: Robustness analysis yields analysis classes.
Analyze classes
Analyze each class modeled to determine its responsibilities to the system, its attributes, and its relationships to
other classes. Refine your models by adding this information to them. Build associations between classes and add
generalization relationships.
Refine analysis packages
Finally, reanalyze your analysis packages to ensure they are as cohesive and loosely coupled as possible. If there
are any classes that perform most of their duties in a different package than the one they are in, move them to that
package. In the hotel example, the classes in the Conference Room Bookings package are highly dependent on
the Room Reservations package. There is no real reason why we need a Conference Room Bookings package.
To reduce dependencies and make the Room Reservations package more cohesive, we eliminate the Conference
Room Bookings package and move its classes to the Room Reservations package, as shown in Figure 14-15.
This figure shows the classes in their regular, rectangular form, rather than the iconized form based on their
stereotype shown in the previous figure.
Figure 14-15: Analysis packages for hotel.
Step 3: Building the Design model
After analysis, you move on to design, during which you group design use cases and classes into subsystems. The
design subsystems are grouped into a Design View model, which, as you saw earlier in this section, is a package
of stereotype model.
Perform architectural design
As a first step to architectural design, create a subsystem that corresponds to each analysis package. Then, refine
those subsystems.
One technique for refining the subsystems is to establish the physical machines, or nodes, and network
configurations on which the systems will run. Use UML Deployment diagrams to model a first cut of the
configurations, and then map subsystems against the nodes on which they will run.
In the hotel example, the Room Reservations system can be broken out onto the client machine and a dedicated
Web server, so break it into two subsystems: Reservations UI, which resides on the client, and Reservations
System, which resides on the Web server. This is shown in Figure 14-16. I also break up the Accounts Payable
subsystem, since it becomes obvious at this point that Credit_Card_Account and related classes will exist on
external bank servers, while Corporate_Account is located in a subsystem housed locally, probably on the Web
server.
Figure 14-16: Mapping subsystems against physical deployment nodes.
The Rewards Program Administration system will also reside on the Web server. The Database Access system
will reside on a Back Office server. We don't need to make specific decisions about the database brand, such as
SQL Server, Oracle, or DB2, or about the implementation language or middleware of the system, such as JDK or
.NET, at this point. These choices are made later during implementation. In following the MDA philosophy, analysis
and design models are kept independent of technology choices.
Once the first cut of subsystems is established, you loosely set up how the subsystems are connected together
using dependency lines.
You then add design details to each subsystem. Start by using UML notation to divide each subsystem into a
specification and a realization compartment. Fill in the specification compartment by modeling what the
subsystem should provide. You can use various UML artifacts, although Use Cases, Activity diagram flows, and
interfaces are typically used. Then denote how the specification is fulfilled by adding details to the realization
compartment.
Design use cases
Just as you walked the Use Cases during analysis to find analysis classes, now walk the Use Cases in each
subsystem to establish the design classes necessary for it to work. During this phase, pay particular attention to
how the Use Case will be implemented in a physical system. Use the classes established during analysis as a
guide to creating the design classes. Be sure to remove embedded spaces in class names, because most
programming languages do not support them (even though, at this point, you are not necessarily specifying a
programming language). Use Sequence and Collaboration diagrams to get a better understanding of how the
objects of classes interact. As you establish the design classes, place them in the realization compartment.
These are the classes that implement the subsystem specification.
A subsystem is a type of component. As such, it contains functionality that is presented to the outside world in the
form of one or more interfaces. Examine each subsystem to establish its interfaces.
For the hotel business example, I use Use Cases to show the specification of each subsystem, and the classes
that implement those specifications in each subsystem's realization compartment, as shown in Figure 14-17,
and begin establishing the interfaces of each subsystem as a lollipop symbol emanating from each subsystem
symbol.
Figure 14-17: Hotel reservation subsystem with specification and realization compartments and
interfaces.
Design classes
To continue with design, identify each class's operations, attributes, and relationships to other classes. During this
stage, model aggregations and inheritance. You may use State diagrams to model classes with interesting
dynamic behavior.
Refine subsystems
Toward the end of design, take another look at the subsystems to see if they can be refined, so that they are as
cohesive and loosely coupled as possible. Inspect each subsystem to see if it is as independent as possible of
other subsystems and that it provides the functionality denoted in its specification compartment.
Step 4: Building the Implementation model
After design, you move on to implementation, during which you specify platform-dependent details of the system.
You specify these details using Component and Deployment diagrams, and group the artifacts in an
Implementation model. (Chapters 15 and 16 provide more details on Component and Deployment diagrams.)
Step 5: Building the Testing model
You build the Testing model by creating test cases that specify what to test, and test procedures that specify how to
test the systems you are implementing. The test cases are derived from the use cases of the Use Case model and
use case realizations of the Design model. These test cases, test procedures, and corresponding test results are
performed and housed outside of a modeling tool, but can be traced back to the models. An in-depth discussion of
testing is outside the scope of this chapter.
Overall Hierarchy of Models
In the example in this section, I have presented all artifacts drawn within package or subsystem symbols. If I were
using a modeling tool, I would create my model, package, and subsystem hierarchy in a browser, and create
various diagrams for each package or subsystem. On each diagram's drawing space, I would create the models
shown earlier in this section. Figure 14-18 shows what the hierarchy of the hotel business would look like. I have
created four models-Use Case model, Analysis View model, Design View model, and Implementation View model.
Each model is a complete representation of the system from a different viewpoint. Within each model, the artifacts
are organized by packages or subsystems.
Figure 14-18: Overall model, package, and subsystem structure of the hotel example.
<Day Day Up>
<Day Day Up>
Summary
In this chapter, you learned that
The package is the main construct in UML for grouping model artifacts. It enables you to organize elements by
grouping them and placing them into a container.
A package provides exactly the same functionality as a folder in Windows Explorer.
A package provides a namespace for classifiers that you place in the package. This includes packages
themselves-a package can contain other packages in a nested hierarchy.
A package cannot contain itself.
A package may also contain multiple diagrams of any and all UML types.
A package is represented by a folder symbol. The name of the package may be placed in the middle of the
symbol, or in the upper-left tab of the package.
There are a number of ways to show that an element belongs to a package: draw the elements within the
large rectangular portion of the package symbol; draw the elements outside the package symbol and attach
them to it with lines that are grouped at the package end by a circle with a + mark inside it; or draw elements
on a diagram attached to a package symbol.
Classifiers have a visibility property that establishes whether they are visible to classifiers in other packages.
Visibility can either be public or private.
When you build relationships between a classifier in one package (the source) and a classifier in another
package (the target), the packages themselves have a relationship between them. This is either an Access or
a Merge dependency.
When you access a classifier in another package, that classifier stays in its package, and you simply build a
relationship to it. You draw the second classifier in the package in which you are working, and show that it
belongs to a different package by specifying the name of its package before its name:
PackageName::ClassifierName.
A merge relationship between one package (source) and another package (target) enables you to import a
copy of all classifiers in the target package into the source package. The new copy of an imported classifier in
the source package belongs to the source package (and has its namespace specified by it). The original
version still exists in the original, target package.
The import relationship between packages specified in UML 1.x is subsumed by the merge relationship
between packages in UML 2.0.
When you delete a package, you delete all the elements contained by it that it owns, including nested
packages and their owned elements.
A Package diagram is a static-type diagram, such as the Class diagram, on which you draw only packages.
Subsystems are a grouping mechanism used during design. A subsystem is drawn as a rectangle with a fork
icon in the upper-right corner.
In UML 1.x, a subsystem is a type of package. In UML 2.0, a subsystem is changed to be a type of component.
You may specify required and provided interfaces for it.
You may divide the rectangular subsystem symbol into two compartments, one for Specification elements (left
compartment), and one for Realization elements (right compartment).
A model is an overall grouping of packages and subsystems to represent a view of a physical system. A model
is drawn as a package with a triangle icon in the upper-right corner.
A model presents a complete view of a system.
There are an infinite number of ways to organize the material within packages. The UML specification does not
provide a method for categorizing your work. There are a number of published methods you can follow such
as the Rational Unified Process (RUP), Catalysis, Shlaer/Mellor, the ICONIX Unified Object Modeling
Approach, and others.
<Day Day Up>
<Day Day Up>
Chapter 15: Modeling Software Using the Component
Diagram
Overview
Once the logical design is completed using the Use Case, Class, and Interaction diagrams, the next step is to
define the physical implementation of your design. The physical implementation must address three issues:
The physical description of the software. The Component diagram models the physical implementation of
the software specified by the logical requirements in Class diagram.
1.
The layout of the hardware. The Deployment diagram (discussed in Chapter 16) models the physical
architecture of the hardware.
2.
The integration of the software and the hardware. The combined Deployment and Component diagrams
(covered in Chapter 17) model the integration and distribution of the software across the hardware.
3.
Classes describe the logical organization and intent of your software design. Components describe the physical
implementations of your software design.
The purpose of the Component diagram is to define physical software modules and their relationships to one
another. Doing so provides a means of defining software as a set of modular, and interchangeable, units that may
be assembled to create successively larger modular, and interchangeable, units. Components may represent
anything from a single class to applications, subsystems, and systems.
A Component diagram may be used to illustrate the relationship between the classes that specify the requirements
for the component, and the artifacts that implement the component. The artifacts may be any type of code that can
reside in any type of memory-source code, binary files, scripts, executable files, databases, or applications.
The relationship between a component and an artifact can be confusing. The component is a definition of a type of
physical implementation. An artifact is the actual implementation. The same component notation may be used to
represent the artifacts, too.
Cross-Reference Chapter 1 describes Model Driven Architecture (MDA), which attempts to describe a
system independent from its implementation. This enables the same set of
requirements, that is the same type of component, to be implemented in any number of
different technologies, that is, in any number of different physical artifacts.
Each component must define one or more interfaces that allow other components to communicate with it. The
requirements for the internal implementation of the component are specified by classes. The actual
implementation is encapsulated in the artifact that implements it-for example, Java classes, HTML, and XML.
Artifacts are sometimes grouped into three broad categories:
Deployment components, which are required to run the system. Examples include operating systems, Java
Virtual Machines (JVM), and Database Management Systems (DBMS).
Work product components, including models, source code, and data files used to create deployment
components. Examples include the UML diagrams, Java class and JAR files, dynamic link libraries (DLL), and
database tables.
Execution components, which are components created while running the application. Examples include
Enterprise Java Beans, Servlets, HTML and XML documents, COM+ and .NET components, and CORBA
components.
Dependencies represent the types of relationships that exist between components on a Component diagram. For
example,
A component depends on the classes that reside within it to specify the behavior of the component.
A component depends on the artifacts used to implement it.
Components depend on one another for functionality and for information.
The Component diagram components, component interfaces, and dependencies to specify the requirements for
the physical implementation of your system in terms of the software modules and the relationships among them.
Modeling Business Processes
Component and Deployment diagrams may also be used to model business systems, including completely
manual processes. When used for this purpose, the components represent business processes (such as
signing up a new agent, or placing an order) and the products of those processes (such as contracts, or
payments and receipts). The nodes from the Deployment diagram represent business units (departments,
teams, and subsidiaries, for example) or business resources (such as a warehouse, a manufacturing facility, or
an office in which the business departments reside).
Figures 15-1 and 15-2 contrast the metamodels from UML 1.4 and UML 2.0. Figure 15-1 shows that a component
specializes Classifier. In Figure 15-2, component specializes Class, which extensively redefines the properties of a
component. The significance of this change is addressed in the section "Modeling the Component Diagram in UML
2.0."
Figure 15-1: UML 1.4 metamodel for components. OMG 1.4
Figure 15-2: UML 2.0 metamodels for components.
In addition to refining the containment properties of a component, UML 2.0 adds some significant new details
regarding connectors and interfaces. The second portion of this chapter explains the new features highlighted in
Figure 15-2.
As you can see from the figures, the changes between UML 1.4 and UML 2.0 are significant. So this chapter starts
with an explanation of the Component diagram as defined and illustrated by UML 1.4. It then explains the UML 2.0
version while highlighting the changes. (If you prefer, you can skip straight to the latter portion to review the
descriptions of the changes.) The following is a summary of the changes that are covered.
UML 1.4 defined a component as a subclass of Classifier. UML 2.0 defines a component as a subclass of
Class. This means that a component may now have attributes and methods, as well an internal structure and
ports.
The addition of ports and connectors that formalize the interaction points on a component, as well as the
explicit mapping of published interfaces and internal implementation mechanisms.
A change in the component icon to resolve some longstanding difficulties.
The addition of the UML 2.0 definitions of interfaces and ports.
The addition of a white-box alternative notation for modeling components.
The addition of Realizations, which define a set of classifiers (behaviors, features, or classes, for example) that
provide the implementation for a component.
The addition of connectors, which map the relationships between interfaces.
The addition of PackagingComponents that more precisely define the relationship between the elements
within a component that provide the implementation for its interfaces. This concept replaces the UML 1.4
association with the generic ModelElement.
<Day Day Up>
<Day Day Up>
Modeling the Component Diagram in UML 1.4
A component is a type of container. As such it does not have features of its own, but contains classes that define
the features. A component provides an encapsulated view of the functionality defined by the contained classes.
The express purpose of such a representation is to support a component-based approach to constructing
software. That is, each unit of software should be able to stand in isolation, be reusable and replaceable.
In fact, since a component is defined as a container, a component may define more than one implementation. For
example, a component could represent an application to place an order at the theater. But over time the
configuration of classes within the component may change, as long as they still support the interfaces provided by
the component.
The key to the capability to replace components is following the rules for encapsulation, that is to say, limit the
definition of the component to an explanation of its purpose and interface. This technique is comparable to the
encapsulation of methods. While a method provides the means to receive input and generate output, the
mechanisms it uses to do so are hidden behind the object interface, that is, the operation signature. The interfaces
provided by the component expose one or more of the interfaces of the contained classes. The difference is that
other components do not have direct access to the contained interfaces, so developers have the freedom to alter
the internal design, including replacing internal classes, without disrupting the other components that depend on
the altered component.
TipA component does not necessarily expose all the interfaces of the contained classes. Some of the
interfaces are only used for communication between the contained classes.
TipThe way in which the component exposes the interfaces may vary. The component can aggregate class
level interfaces. For example, the contained classes can offer five interfaces to change and order, but the
component might offer a single interface called something like "ChangeOrder".
It is important to note that the Component diagram is only a specification. There are no instances on this diagram.
In this respect it is very much like a Class diagram. To model instances of components that represent the
execution of the application, use the combined Component and Deployment diagram, described in Chapter 17.
Modeling components
A UML 1.4 component icon is modeled as a rectangle with two smaller rectangles centered on the left edge. The
component name is placed inside the icon, as shown in Figure 15-3.
Figure 15-3: Component icon and name.
NoteThe component icon is one of the big changes between UML 1.4 and UML 2.0. The UML 2.0 icon is very
different. The two small rectangles are left over from an old notation that used to put the component
interfaces in the rectangles. They don't really serve any purpose any more other than to describe a
unique icon. This is the primary reason behind the change in UML 2.0.
Component stereotypes
Component stereotypes provide visual clues to the role that the component plays in the architecture. Component
stereotypes refer to types of artifacts (source code, binary files, databases, and so forth) used to implement the
features of the component, and to types of components-EJB, CORBA, COM+, and .NET, for example. Some
common general component stereotypes are listed here. Other more specific types that refine these more general
stereotypes are also frequently used. I'll use some of these more specific types in the examples that follow.
executable: A component that runs on a processor.
library: A set of resources referenced by an executable during runtime.
table: A database component accessed by an executable.
file: Typically represents data or source code.
document: A document such as a Web page.
Figure 15-4 adds yet another, more specific stereotype, EJBEntity, to the performance component.
Figure 15-4: Component stereotype.
Modeling component interfaces
A component interface may be modeled in either of two ways. One way is to use a class, with the stereotype
interface, attached to the component with a realization arrow, as shown in Figure 15-5. The realization arrow
looks like the generalization symbol, but with a dashed line instead of a solid line. To realize the interface means to
implement it as part of the component (or whatever is realizing the item). For example, in Figure 15-5, the
PerformanceEJB component incorporates the interface to display a seating chart into its design. This assumes that
the component contains the behaviors needed to support the interface. How these behaviors become part of the
component will be explained very shortly.
Figure 15-5: Interface notation using a class and stereotype.
A second, more common, technique is to use a "lollipop" attached to the component with a solid line. The UML
specification examples show a very small circle on the end of the lollipop. This is a bit distorted from the typical
notation employed by modeling tools. Figure 15-6 models two representations of the lollipop interface icon.
Figure 15-6: Interface notation using the lollipop.
The interface implemented by a component is actually defined by the classes within the component. So the
interface should already have been defined in your Class diagrams. Also, a component may implement as many
interfaces as it requires-the number and exact type are dictated by the classes implemented by the component.
Figure 15-7 adds the client application that manages the user interface for placing an order. PerformanceEJB
provides the DisplaySC interface. The user interface application, SeatingChartUI, accesses the PerformanceEJB
using the DisplaySC interface. This access is modeled as a dependency from SeatingChartUI to the DisplaySC
lollipop-style interface to illustrate that the SeatingChartUI will not work properly unless it can access the
performance through the DisplaySC interface.
Figure 15-7: Depending on access to a component's interface.
Modeling component dependencies
Dependencies between components are drawn with the dashed arrow from the dependent component, to the
component it needs help from. In Chapter 14, you learned that package dependencies could be stereotyped to
clarify the nature of the dependency. The same is true for component dependencies. In Figure 15-8, the
PerformanceJAR file depends on the PerformanceEJB component. The UML stereotype becomes means that
the PerformanceJAR file literally becomes the PerformanceEJB executable at runtime. PerformanceJAR is the
code sitting on a storage device. At runtime it is loaded into memory.
Figure 15-8: Component dependencies and dependency stereotypes.
The next section contains a few more examples of dependencies used to map the component design to the
classes that specify its behavior and the artifacts that it implements.
Mapping the logical design to the physical implementation
Specifying a component using classes involves choices about how to assemble these classes into cohesive units.
Figure 15-9 shows the component that describes a performance at the theater, PerformanceEJB, which
implements the classes that define a performance - Performance, SeatingChart, and ShowSeat - and their
associations.
Figure 15-9: A component implements artifacts and is specified by classes.
The reside dependency identifies the fact that the class resides within the component, and specifies the behavior
of the component. So, for example, when an interface is accessed on the component, the component actually
forwards the invocation to the corresponding interface on one of the resident classes.
This again emphasizes the benefit of defining components. External components do not need to know whether the
invocation was forwarded to the performance class or some other class within the component. The
PerformanceEJB component is responsible for delegating the invocation properly based on what it knows about
the resident classes and their interfaces.
The implement dependency identifies the artifact that is implemented when the component executes. In Figure
15-9, the JAR file called PerformanceJAR is unpacked and executed as PerformanceEJB.
The reside dependency may be modeled in another way that more explicitly illustrates that the residing classes
are encapsulated inside the component. Figure 15-10 models the Performance component containing the classes
SeatingChart, Performance, and ShowSeat.
Figure 15-10: A component containing classes.
In the same manner, the component may physically contain the artifacts that it implements. Note that the
PerformanceJAR file also resides within the component icon in Figure 15-10.
The interfaces of the classes in the component define the interface of the component. There need not be a one-to-
one correlation, but the component has to provide access to all of the functionality specified by the residing
classes. Figure 15-11 models the performance component's interfaces, DisplaySC, SelectSS, PriceSS, and
PurchaseSS. These interfaces are derived from the interfaces found on the seating chart and performance
classes. When the DisplaySC component interface is invoked from the user interface, the component delegates
the invocations to the SeatingChart interface DisplaySC, which in turn calls the GetPerf interface on the
performance class, and so on.
Figure 15-11: The relationship between component interfaces and the interfaces of resident classes.
NoteFigure 15-11 required me to use some implied relationships, specifically the delegation path. This is one
of the issues addressed by the addition of ports in UML 2.0. Ports allow you to explicitly model the
delegation paths from the external interface of the component to the internal interface of the resident
classes.
Finally, components can be organized into packages just like other diagrams and model elements. This can be
very helpful when managing application distribution. The result is a directory containing all the software elements
needed to implement the system or subsystem represented by the package.
<Day Day Up>
<Day Day Up>
Modeling the Component Diagram in UML 2.0
UML 2.0 changed the definition of the Component metaclass so that it is now a subclass of Class instead of
Classifier. As a subclass of Classifier, a component could not have attributes or methods of its own. Nesting of
elements within a component was rather nebulously defined using ModelElement. ModelElement is used as a
base class for just about any UML diagram element, including associations, classes, objects, messages, and
many more.
However, the purpose of a component is to explain the artifacts that are used to implement the logic design
expression in Use Case and Class diagrams. So, the UML 2.0 metamodel, seen in Figure 15-12, redefines a
component to show that it may contain any number of PackageableElements. PackageableElement is a subclass
of NamedElement, which supports a name for the component, a qualified name so that it may be identified within a
hierarchy of packages, and visibility. This approach helps to correlate more closely the relationship between the
logical organization of work products in a Package diagram with the physical implementation requirements defined
in a Component diagram.
Figure 15-12: UML 2.0 redefines Component as a subclass of Class.
In the following section you'll see additional benefits derived from defining a component as having its own features,
including the white-box view.
Modeling components
The most noticeable change in the Component diagram is the component icon. The older icon, pictured on the left
in Figure 15-13, had a long history. The two small rectangles on the left border had meaning at one time but fell
into disuse. UML 2.0 opted for a simple rectangle with the component stereotype, shown in the center of Figure
15-13. However, you can still use the old component icon as an adornment in the top right corner of the
component symbol as shorthand for the stereotype, shown on the right in the figure. This is similar to the use of
icons for the boundary, entity, and control stereotypes in the Class diagram.
Figure 15-13: Changes to the component icon.
Modeling dependencies
Early in the modeling process you might not have all the interface details for your components. Sometimes you
might simply want to ignore those details in order to focus on the purpose of each component and its basic
relationships. In either case, the focus shifts toward understanding basic dependencies. Figure 15-14 models a set
of components at an overview level. No interfaces appear in the diagram, only dependencies. In this example, the
order component depends on the discount and performance components. The performance component depends
on the event and venue components.
Figure 15-14: Component dependencies.
Modeling component realization
UML 2.0 adds the realization concept. As in other instances, UML 2.0 has worked to make the vocabulary
throughout the specification consistent. Realization refers to any implementation of a requirement. A component is
an abstraction, a representation of a requirement for the physical software. A realization is a concrete entity that
makes the requirement into a reality, or realizes the requirement. A component may be associated with any
number of realizations.
Each realization may refer to a classifier. A classifier is a superclass that describes anything that represents a set
of instances and may contain features. Classifiers include, but are not limited to classes, interfaces, behaviors, and
data types. Figure 15-15 illustrates the relationships between the Component, Realization, and Classifier
metaclasses.
Figure 15-15: A component is an abstraction associated with any number of realizations. Each realization is
defined by a classifier.
The extended definition of component, within PackagingComponents, defines an attribute, isIndirectlyInstantiated,
a Boolean flag. False means that the component is directly instantiated, that is, the component itself is a directly
addressable object in memory. For example, a component may represent a Java class, a Servlet, or EJB. In other
words, the component specification has a one-to-one relationship with its run-time counterpart, its realization (that
is, the component "is a" Servlet).
The default value of true for the isIndirectly Instantiated attribute describes a component that exists in
the design, but not at run-time. At run time, the component is implemented by its associated realizations, which in
turn define the classifiers that specify the implementation. This approach is helpful for large concepts like
subsystems, or general-purpose components like event handling, in which there may be a large number of
discrete elements. The component needs only to refer to the collection of elements. If, and when, the configuration
of classifiers changes, the component does not have to be altered, so long as the implementing classifiers
conform to the component purpose and interfaces.
Additionally, the UML specification provides two standard stereotypes for components (actually the stereotypes
may apply to any type of classifier), which define whether the component is used as a pure specification or as an
implementation. A realization component refers to one or more sets of implementation classifiers. For example,
the same component might be realized by a set of Java classes or by a set of COM+ and .NET components.
A specification component refers to one or more specification classifiers. For example, the same component
might have multiple sets of classes that define different specifications for fulfilling the requirements of the
component (alternative subsystems, applications, or event handling models), but do not provide an implementation
for the component.
In Figure 15-16, the realization for the order component is Order and LineItem classes. The order component is
implemented by instantiating the order and line item classes (and their association).
Figure 15-16: Modeling realization using dependencies.
Modeling component interfaces
A fundamental feature of components is the ability to define interfaces. The component must expose some means
for other components to communicate with it. UML 2.0 applies the same interface and port concepts to
components that it does to classes. This section covers interfaces first, and then adds the port concept.
Interfaces come in two types: required and provided. Components may define behaviors; for example, an order
component may offer the ability to add line items to the order, cancel the order, and pay for the order. The internal
design of the component defines the implementation of these behaviors. The order component is said to provide
these services. To do so it must also provide the means for other components to request these services. An
interface defines how another component must ask for access to a provided service. This type of interface is called
a provided interface.
A component may also need help from other components, and it has to define exactly what it needs. For example,
the order needs to be able to find out whether a discount applies to the items purchased using the order. But the
order itself does not have the resources to answer this question, so it defines an interface stating the type of help it
requires. Hence, the interface is called a required interface.
Interfaces appear as small icons, representing the type of interface, attached to the component by a solid line.
Figure 15-17 illustrates the order component with provided interfaces (on the left) to add line items to the order,
cancel the order, and pay for the order, and a required interface (on the right) to apply the discount.
Figure 15-17: Interface notation for provided and required interfaces.
Provided interfaces use the small circle icon. Required interfaces use a half circle icon. These symbols were
deliberately chosen so that when the diagram combines a set of interacting components, the provided interface fits
into the required interface to create a kind of ball-and-socket image as shown in Figure 15-18.
Figure 15-18: Connecting required and provided interfaces to form a partnership between components.
Interfaces, of course, may be more complicated than these examples, so UML 2.0 also supports the use of
classes to describe the interfaces. Using classes enables you to add the interface signatures explicitly on the
diagram. For example, Figure 15-19 models the order component again. An interface class called
OrderMaintenance is used to represent the provided interfaces. The order component realizes the interface
class. At the bottom of the figure is the applyDiscount operation within the Discount interface class. The order
component does not implement this interface, but simply uses, or accesses, it. So, the relationship is modeled with
a uses dependency arrow from the order component (client) to the Discount (supplier).
Figure 15-19: Alternative notation for interfaces.
UML 2.0 provides a way to represent all of the information defined so far for a component, including interfaces,
realizations, and artifacts. This representation is made possible because a component is now a type of class. A
class may have compartments and features. Figure 15-20 models the order class with all three provided
interfaces, the required interface, two realizations, and one artifact. This representation is called the white box view
because we can see through the box to see its internal properties.
Figure 15-20: Component white box view.
Now that we've discussed the basics of component interfaces, let's take a good look at the application of interfaces
using ports and connectors.
More on realizations using connectors and ports
UML 2.0 defines the relationship between components and realizations as composition. Composition means that
the lifespan of the members, the realizations in this case, are controlled by the composite, the component. In other
words, the realizations are encapsulated within the component and the component controls when they are
instantiated.
The white box view helps to identify the encapsulated realizations, but it doesn't help to explain their relationships to
one another or to the component. To overcome this limitation, the PackagingComponent extended definition for a
component icon enables the component to open up to reveal the contained realizations. Figure 15-21 models the
relationships from Figure 15-16 using a containment view.
Figure 15-21: Component containing realizations.
This representation is, so far, the same as in UML 1.4. Figure 15-22 represents the order component and its
interfaces to customer and discount. Notice that the interfaces merely touch the boundary of the order component.
In UML 1.4 there is no way to map the service supported by the component to the other components or its
realization classifiers.
Figure 15-22: Components and interfaces alone provide no means to map their internal and external
mechanisms.
UML 2.0 adds the capability to map the interfaces of the component to the realizations that support them. To do
so, however, the component needs a place to make the transition between its interfaces and its internal
realizations, and that place is a port.
A port appears as a small square in the edge of the component. A component interface attaches to a port.
(Actually, more than one interface may connect to the same port. I explain how to do that a bit later in this section.)
Dependencies then extend from the port to the realizations that fulfill the interface requirements. Figure 15-23
models the order and its interfaces. Note how the addition of the port further distances the component's
relationship with the outside world from its internal structure. For example, the customer component only knows
that the order component provides the addLineItem service because it exposes an interface for it. It cannot know
how the component delegates the request to add a line item to the order that realizes the request. This makes it
possible to change the definition of order or replace it with a different implementation element without altering the
relationship with customer.
Figure 15-23: Modeling ports as the intersection between external interfaces and internal realizations.
The relationship between customer and order is expressed using a connector. The relationship between a port and
a realization element is also a connector. The two types of connectors, assembly and delegation, are varieties
specified by the ConnectorKind enumeration.
A delegation connector maps a request from one port to either another port or to a realization that provides the
implementation for the request. A port-to-port connection effectively redirects the invocation. The only restriction is
that the two ports must be the same type, that is, both ports must support required interfaces only or provided
interfaces only.
In a port-to-realization connection, the realization has an implements relationship with the interface specification.
In other words, the external interface matches a signature on the realization. For example, the customer invokes
the addLineItem interface connected to a port on the component. The component port then delegates the
invocation to the addLineItem operation on the order class.
Figure 15-24 shows this relationship. On the left, the delegation connector is a dashed arrow from the port to the
realization. That the interface on the component and the interface on the realization are both implementations of
the same interface is modeled on the right side of Figure 15-24. The component implements the interface by
delegating the addLineItem request to the order class. The order class implements the interface by actually adding
the line item to the order.
Figure 15-24: In a delegation connector, the external interface must match the realization interface.
An assembly connector is used to map a required interface to a provided interface. For example, the customer in
Figure 15-25 requires the ability to add a line item to the order. The order component provides this service. The
assembly connector unites the two interfaces to form the ball-and-socket connection, or a kind of handshake
between the components.
Figure 15-25: An assembly connector example.
UML 2.0 offers shorthand notation for the assembly connector. If many components require or provide the same
interfaces, the connectors may be merged. Figure 15-26 models the fact that the backorder and order
components both require access to the person interface. Both the customer and organization components provide
the person interface. (This example might seem misleading, but it hides the fact that the client interface on the
organization component is a subclass of the person interface.)
Figure 15-26: Shorthand notation for assembly connectors.
The merged assembly connector conveys that some of the communication is resolved at runtime. This applies to
both the required and the provided interfaces. For example, Figure 15-26 shows that both the backorder and order
components may require the person interface. The application won't know until runtime which component
(customer or organization) will provide the service. In other words, the interaction is polymorphic.
In like manner, customer and organization will not know who is requesting the person interface until runtime. The
component specification merely states that either backorder or order may do so.
In my earlier explanation of interfaces and ports I said that an interface connects to a port. But UML 2.0 also allows
multiple interfaces to connect to the same port. Figure 15-27 is a redraft of Figure 15-23. The three provided
interfaces all connect to the same port.
Figure 15-27: One port supporting multiple interfaces.
Explaining ports and connectors with other UML diagrams
In some cases, the logic that describes access across a port is fairly complex. A port is a classifier, a resource, just
like a class. As such, it may possess states, conditions under which certain things may or may not happen. The
protocol state machine may be associated with a port to describe the conditions under which the port may be used
successfully, although it does not explain how the port behaves when it is traversed.
To provide this additional detail, a specification-level state machine may be associated with the port to explain the
sequence of behaviors, constraints, and overall logic involved in the transition across the port.
Cross-Reference State machines are covered in Chapters 10 and 11.
Activity and Interaction diagrams can help explain the logical sequence of events required to communicate across
a connection. The logic modeled in this manner becomes the implementation logic for the method that invokes the
interface that uses the connector.
Together, these specifications define the complete protocol for connecting components.
<Day Day Up>
<Day Day Up>
Summary
The purpose of the Component diagram is to define software modules and their relationships to one another. Each
component is a chunk of code that resides in memory on a piece of hardware.
Components may be grouped into three broad categories:
Deployment components, which are required to run the system.
Work product components including models, source code, and data files used to create deployment
components.
Execution components, which are components created while running the application.
UML 1.4
UML 1.4 defines components and the classes used to realize them. Components provide interfaces that define the
type of services and access they provide. Dependencies help define the relationships between components and
between components and the classes that realize them. Stereotypes help define how a component is used within
the model and the nature of the dependencies between components.
The component icon is a rectangle with two small rectangles on the left edge. The interface to the component
may be modeled two different ways:
The lollipop notation represents the interface as a small circle connected to the component by a solid line
and with the name of the interface near the circle.
The second method uses a class with the stereotype interface with a realizes relationship drawn
from the component to the interface class. A component may realize (implement) as many interfaces as
it requires.
Component dependencies provide a high-level view of component interactions without spelling out the exact
communication requirements. The dependency view is helpful for overviews and sequencing of development
efforts.
The list of common component stereotypes includes executable, library, table, file, and
document.
The implement dependency identifies artifacts used to deploy the component.
The resides dependency identifies the realization element/s used to implement the requirements of the
component.
UML 2.0
UML 2.0 has improved on the definitions for the terminology used to describe components. It has also added the
means to define a component as a container with ports that allow it to provide an encapsulated specification for
implementation artifacts without being bound to a specific set of realizations.
The following is a list of the UML 2.0 changes.
A change in the component icon resolves some longstanding difficulties.
UML 1.4 defined a component as a subclass of Classifier. UML 2.0 defines a component as a subclass of
Class. This means that a component may now have attributes and methods, as well as an internal structure
and ports. This provides an optional white box view of a component that contains compartments detailing
interfaces, realizations, and artifacts.
Ports and connectors formalize the interaction points on a component, and provide explicit mapping between
published interfaces and internal implementation mechanisms (realizations).
A realization identifies a classifier - behaviors, features, or classes, for example - that provides the
implementation for a component.
A component may be stereotyped as either specification or implementation to limit the nature of the
associated classifiers. The specification stereotype means that the classifiers associated with the
component provide only the specification details, no implementation. The implementation stereotype means
that classifiers associated with the component provide only the implementation details, no specification.
<Day Day Up>
<Day Day Up>
Chapter 16: Using Deployment Diagrams in UML 1.4
Overview
A Deployment diagram describes an execution architecture, that is, the configuration of hardware and software
that defines how the system will be set up and how it will operate. The purpose of a Deployment diagram is to
present a static view, or snapshot, of the implementation environment. A complete description of the system will
likely contain a number of different Deployment diagrams, each focused on a different aspect of system
management. For many of these views the Deployment diagram is combined with the Component diagram to
show the relationship between the hardware and the software. For example,
For a multi-tiered application, the Deployment diagram would model the distribution of the application layers,
their physical connections, and their logical paths of communication.
Another diagram might focus on how software components are distributed across the network resources, such
as where the source code resides and where it is shipped for implementation.
Another diagram might model how an executable is loaded from one node where it is stored to another node
where it actually runs.
The Deployment diagram consists of nodes and associations between nodes. It represents the same information
often modeled in network diagrams that represent the devices and connections of a computing architecture. UML
1.4 describes the Deployment diagram in two contexts:
A Deployment diagram can define node types, much like a Class diagram that defines object types.
A node represents a type of processing resource, such as a CPU performing calculations or a human
being performing a manual task.
An association defines the type of relationship that supports the communication between nodes.
A Deployment diagram may include component instances within node instances to illustrate the runtime
environment.
A node instance represents a specific processing resource of a designated type.
A node link represents a specific connection of a designated type (defined by an association between
nodes).
NoteAlthough the Component and Deployment diagrams have been part of the UML specification since its
inception, they are relatively new to most people and there are a lot of different ideas out there about
how to use them. These tools can be very helpful, but they will not make or break an implementation.
Use good judgment. Practice. Find out where the benefits lie for your project. Exploit the tool for your
success instead of just following a standard.
<Day Day Up>
<Day Day Up>
Modeling Nodes and Associations
The simplest form of the Deployment diagram models hardware only. The Deployment diagram is really just a
network diagram like those used for many years now by network management folks. The icons are much simpler,
which seems like a step backward, but remember that the UML does not limit how you represent an item or how
you extend the model, so you can still use the icons you are used to for disk drives, servers and clients, hubs and
routers, and so forth.
A node can represent just about anything that can perform work. Depending on the type of system you are
modeling, a node could represent a disk drive with long-term memory, a server with temporary memory and
processing capability, a mechanical device like an automated welder or conveyor belt, or even a human being or
organizational unit such as a department or team.
The UML 1.4 version of nodes is very simple. Figure 16-1 shows the portion of the UML 1.4 metamodel that
describes nodes and components. A node is simply a type of classifier that may contain components.
Figure 16-1: UML 1.4 node metamodel. OMG 1.4
NoteIn UML 1.4 nodes may not contain other nodes. Because it is quite common to have processing units
within other processing units, such as a server with multiple CPUs and disk drives, this limitation is
corrected in UML 2.0.
Because the node is a subclass of Classifier, it may have attributes and operations, and may participate in
associations. This means that a node may be defined in terms of its features, such as memory size, number of
processors, processing speed, and so forth, and its abilities, such as boot, shutdown, and restart. These details
can be valuable when you are specifying the equipment that you will need to support the implementation of the
system. For example, the specification of a desktop computer for graphic design can be very different from that of
a desktop computer used for business applications like spreadsheets and word processors.
Figure 16-2 illustrates a type-level server node with attributes, operations, and associations, and an instance-level
server node with attribute values and links.
Figure 16-2: Nodes described with features - attributes, operations, and associations.
I need to note, however, that many modeling tools do not provide the ability to model attributes and operations on a
node, so you might need to use the documentation area of the node specification to provide these details. This
area is typically a window accessed from the node icon within the modeling tool.
Figure 16-3 illustrates the two levels of Deployment diagram. On the left is a type-level diagram. On the right is an
instance-level diagram. In the type-level diagram, each node defines only a type of processing unit. A node type is
just like a class in that it provides a definition and can be instantiated. The node name uses the form
Figure 16-3: Node names on a Deployment diagram.
node-name ':-' node-type
The type name may be used by itself, such as "Server" or "AccountsPayable". The instance may use the complete
form, such as "SAN09 : Server", or just the name, such as "SAN09". When only the instance name is used, the
colon is omitted. Figure 16-3 shows all the instance names fully qualified with name and type.
The associations between nodes follow the same rules as associations between classes. Each association defines
the multiplicity at each end. But the association names for nodes pose a small problem. Because the diagram
deals exclusively with hardware, every association could wind up with the name "connects to". This wouldn't add
much meaning to the relationship.
What matters most when connecting hardware is how the nodes are connected-Ethernet, token ring, parallel,
TCP, USB, and so on. So typically, instead of a name, node associations use a stereotype, for example,
parallel, Ethernet, or TCP. Figure 16-4 adds the Ethernet stereotype to the association between the
database server and the middleware server.
Figure 16-4: Association stereotype between nodes.
<Day Day Up>
<Day Day Up>
Modeling the Runtime Environment with Components
The Deployment diagram can combine nodes and components to model the relationship between the processing
resources and the implementation of the software. When a component resides on a node, it can be modeled
within the node itself on the diagram. To show the logical communication between the components, draw a
dashed dependency arrow, the same as is used on the Component diagram, as illustrated in Figure 16-5. The
nodes, components, and dependencies in this figure describe the following relationships:
The database server contains the performance database.
The middleware server runs the performance EJB, which depends on the performance database.
The client runs the JSP pages, which depend on the performance EJB.
Figure 16-5: Modeling components contained within/residing on nodes.
Placing the component icon within a node explicity represents containment of the component within the node. The
same thing could be accomplished by drawing a dependency between the node and the component using the
deploy stereotype. Figure 16-6 says that the PerformanceEJB component is deployed on the SAN10:
MiddlewareServer.
Figure 16-6: Using the deploy dependency stereotype to model containment.
Note that the components drawn in a Deployment diagram are always component instances. The Component
diagram by itself models type-level components, that is, component definitions. The combined Deployment and
Component diagram models the runtime environment. Consequently, the components illustrated on nodes are the
resident instances of the components defined on the Component diagram.
Combined Deployment and Component diagrams can also illustrate software migration at runtime or during
distribution. For example, in Figure 16-7, the performance JSP file resides on the middleware server, but is loaded
onto the client at runtime. UML defines the stereotype become to represent the transformation, or migration, of a
piece of software from one location to another.
Figure 16-7: Migrating software using the become stereotype.
These examples make it obvious that the component notation alone does not clarify everything needed to describe
a system. For example, what exactly is the difference between the component on the server and the component
on the client? UML 2.0 expands the concept of implementation artifacts to clarify this relationship between the
requirements of a physical component and the description of the types of artifacts used to provide the physical
implementation. Artifacts are fully explained in Chapter 17.
<Day Day Up>
<Day Day Up>
Summary
The Deployment diagram models hardware architecture by identifying the processors. Processors are typically
computers or equipment, but may also be people who perform manual processing. Nodes, or processors, may
contain and run software components. Node connections are modeled as associations, complete with stereotypes
and multiplicity.
A node may be modeled like a class with attributes and behaviors. However, some modeling tools do not
support this view.
Associations between nodes typically use stereotypes instead of names to describe the nature of the
connection. Node associations represent the physical communication paths such as TCP or Ethernet.
Component and Deployment diagrams may be combined. Components reside on a node. Component icons
are placed inside the expanded node icon, or connected to the node icon using a deploy dependency
(dashed arrow), to model containment.
Communication between components on the nodes is modeled as a dependency (dashed arrow).
Dependencies model the logical communication requirements.
The become dependency stereotype describes the migration or movement of software from one location to
another.
<Day Day Up>
<Day Day Up>
Chapter 17: Representing an Architecture in UML 2.0
Overview
In UML 2.0, there is a significant change in the vocabulary for modeling runtime environments. UML 1.4 says that
components may be used to specify both the requirements for a physical software element and the physical
implementation of that element.
UML 2.0 instead opts for a parallel structure, using components and artifacts as represented in Figure 17-1. In this
structure, the component is used solely to define the requirements for each physical software element, while an
artifact defines the implementation properties for the component.
Figure 17-1: UML 2.0 metamodel defines a parallel structure for components and artifacts.
Each side of the parallel structure for components and artifacts follows the same pattern. A component is defined
using a set of one or more classifiers. The same classifier may be used to build any number of components. The
specialized dependency Realization maps the refinement of the logical specifications modeled by classifiers that
are used to build the component's specification for a physical piece of software.
An artifact is defined using a set of one or more model elements (that is, any PackageableElement). As with
classifiers and components, the same model element may be used to construct any number of artifacts.
Manifestation, a specialized version of the metaclass Abstraction, maps the evolution of a model element into an
artifact.
Figure 17-2 provides an example showing the relationship between these elements on a component diagram.
Figure 17-2: An example of the relationship between components and artifacts on a component diagram.
Consequently, in UML 2.0, components only appear in the Component diagram, and artifacts appear on the
Deployment diagram. (Technically, artifacts also appear on the Component diagram in order to show the
relationship between components and artifacts.) This is very similar to the relationship between objects and
classes. Classes form the specification. Objects describe the implementation, or instantiation, of the specification.
Likewise, components define the requirements, and artifacts define the implementation.
Table 17-1 summarizes the differences between the two UML releases.
Table 17-1: Deployment Diagram in UML 1.4 and UML 2.0
UML 1.4 UML 2.0
Components may be used to define both
the requirements for a physical software
element, and physical software instances.
Components define only the requirements for physical
software elements.
Components appear both on the
Component diagram and nested in nodes
on a Deployment diagram.
Components appear only on the Component diagram.

Components are built from a set of one or more

realizations. Each realization relationship identifies a
classifier that provides the detailed requirements for a
component.
Artifacts appear only on Component
diagrams to explain the implementation of
a component.
Artifacts are nested in nodes on a Deployment diagram as
the implementation of a component.
Artifacts describe the implementation of a
component.
Artifacts describe the implementation of a component.

Artifacts are built from a set of one or more manifestations

used to implement the requirements for a component.
Realizations describe the classifiers that
contain the logical specifications that make
up the component requirements.
Manifestations map the relationship between model
elements (PackageableElement) and the artifacts that they
implement.
In order to explain how a component is implemented, the model must include a description of the relationship
between the components and where they are installed. This relationship is illustrated by combining the Component
and Deployment diagrams.
The Component diagram models the software, or procedural elements. The Deployment diagram models the
hardware, or processing environment. The artifacts used to implement the component specifications are allocated
to processing units called nodes. The nodes are connected to one another to allow communication between the
artifacts that reside on them. For example, an HTML Web page, an artifact, might reside on a web server, a node
on the Deployment diagram. When a client machine, a second node on the Deployment diagram, wants access to
the Web page, it accesses the Web server and loads the page from the server to the client machine across the
Internet, the connection between the two nodes.
The combined Component and Deployment diagrams provides a single picture of how artifacts are allocated to
nodes, as well as the logical dependencies between the artifacts and the connections between the nodes that
support the dependencies. Different combined views can be created to illustrate the installation setup and runtime
interactions like loading of software and runtime communication between software artifacts.
The first half of this chapter explains the Deployment diagram. The second half adds artifacts to the Deployment
diagram.
<Day Day Up>
<Day Day Up>
Modeling Nodes and Communication Paths
UML 2.0 significantly expands and clarifies the definition of a node. Figure 17-3 is the UML 2.0 metamodel
illustrating the changes:
Node is now a subclass of Class, not Classifier.
A node may contain other nodes.
Node is subclassed into devices and execution environments.
Figure 17-3: Node metamodel.
OMG 2.0
The fact that a node is now a subclass of Class, not Classifier, brings a number of features to a node. Figure 17-4
consolidates the inheritance tree for a node to show the metaclasses from which it gathers all its features. The
following description of the node features makes reference to the classes found in this inheritance tree.
Figure 17-4: Node inheritance tree.
From this long and illustrious family tree, the node inherits an extensive list of new features not dealt with (at least
not explicitly) in UML 1.4. This makes sense when you recognize that in the early life of the UML the greatest
attention was given to the diagrams used to model business applications, that is, Class, Use Case, and
Sequence/Collaboration diagrams. Since the release of UML 1.4, the UML 2.0 submitters have had more time to
consider the features and usage of the Component and Deployment diagrams.
From Kernel :: Class, node inherits the ability to
Contain attributes and operations. Attributes may be used to describe the features of a node, such as
processor speed, memory capacity, and type of memory. Operations, though rarely used, can describe the
services provided by the node via the software contained within it.
Be specialized. A node, like any other entity, may be described in terms of its features. Servers, for example,
come in a variety of configurations and are designed for a variety of purposes. The features of servers may be
organized using generalization and specialization to define an inheritance hierarchy of server types thus
simplifying the work of defining new server designs.
From InternalStructures :: StructuredClassifier node inherits the ability to
Be connected to other nodes through associations. Using associations, nodes can be configured into
networks.
From BasicBehaviors :: BehavioredClassifier node inherits the ability to
Own and trigger behaviors. These behaviors are accessed by events received by the node, placed into a
queue, and processed if and when a trigger matches the event. Triggers are part of the behavioral
specification of the node.
Own a specification for its own behavior. This description of the operation of the node is in addition to the
behaviors housed in the contained components.
From Ports :: Encapsulated Classifier node inherits the ability to
Own ports. Ports are new to UML 2.0. Ports provide the capability to encapsulate the interfaces to a node.
Ports receive requests for the node and delegate those requests to internal parts, software components within
the node that supports the requested interface. Ports may also receive requests from within the node and
forward them to external interfaces.
Cross-Reference Ports are covered fully in Chapter 5 and Chapter 15.
From Communications :: Class node inherits the ability to
Be designated active or inactive. When modeling runtime instances of a node, it is possible to designate which
nodes are currently active in a scenario and which nodes remain dormant. This view potentially provides
insight regarding load balancing.
Define how it receives signals. In addition to receiving events, a node may receive signals, asynchronous
notifications from other nodes. The receipt of a signal does not obligate the node to respond. That decision
belongs to the behavior specification for the node. See BasicBehaviors :: BehavioredClassifier earlier.
From StructuredClassifiers :: Class as node inherits the ability to
Own an internal structure. That is, a node may contain parts.
Own ports. This extended definition of Class simply combines the features of Ports :: EncapsulatedClassifier
and Communications :: Class.
Because a node is a type of class, it may also be stereotyped. Stereotypes can help categorize the expected
structure and behavior of a node. Some typical examples of node stereotypes are
application server. A "backend" computer that executes applications remotely.
client workstation. A computer that executes the user interface portion of applications.
mobile device. A computing device that does not need to be connected to other computers, and is designed
to be portable.
embedded device. A computer that is part of a physical environment, like a piece of automated equipment.
Finally, a node, as defined within the Nodes package, may
Contain other nodes, but only other nodes. That is, the capability to contain other elements is inherited from
Classifiers :: Class, but is then limited to elements typed as nodes. In UML 1.4, a node could contain
components. In UML 2.0 a node may only contain nodes, but may be associated with deployed artifacts. This
relationship is explored further in the "Deploying Artifacts on Nodes" section later in this chapter.
Be subclassed into devices and execution environments.
A device is a physical computational resource-a piece of hardware such as a desktop computer, a processor, or a
server, for example, or a human work unit such as a department or team. A device is commonly composed of
other devices. Composition may be modeled by placing the contained device within the node icon representing the
containing device. For example, in Figure 17-5, the application server contains a processor.
Figure 17-5: Nested nodes.
An execution environment is a type of node that defines a set of services that support software. For example, an
execution environment within the processor on a server in Figure 17-5 might provide the operating system-level
services needed to support a database application installed in that environment. Some typical stereotypes for
execution environment include OS, workflow engine, database system, and J2EE container. Figure 17-6
extends Figure 17-5 to add an instance of the J2EEServer execution node, and an instance of the
PerformanceEJB component, running in the P174:Processor execution environment.
Figure 17-6: An execution environment node that contains a component and runs within a device node. (The
gray shading simply highlights the contained execution environment and component.)
Modeling node instantiation
Nodes, like classes, may be described at the specification level (corresponding to a class) or at the instantiation
level (corresponding to an object). A node specification uses the same naming convention as a class, a noun that
describes the type of node, such as ApplicationServer or DatabaseServer. A node instance follows the naming
convention for objects, that is, instance name : node name. Figure 17-7 represents nodes on the left and node
instances on the right.
Figure 17-7: Modeling nodes (left) versus node instances (right).
Modeling node communication paths
As Figure 17-8 illustrates, CommunicationPath is a subclass of Association. It specifies the relationship between
nodes by defining the number of nodes that may be connected (multiplicity), and the nature of the connection, via
the name of the path or a stereotype. This addition in UML 2.0 is simply a refinement of the UML 1.4 use of
associations to connect nodes.
Figure 17-8: CommunicationPath is a subclass/specialization of association.
CommunicationPaths support the modeling of a network of nodes to represent the topology of a physical network.
For example, Figure 17-9 represents a simple network with client workstations and printers, an application server,
a print server, and two database servers (two instances of the same type). The multiplicities of the
CommunicationPaths tell us that any number of client workstations may be connected to the application server (in
practice there would be an upper limit). There is one print server attached to the application server. There are
between one and five printers attached to the print server. The two database servers support the application
server, one as the primary and one as a backup.
Figure 17-9: Network topology using nodes in a Deployment diagram.
UML suggests the use of the three-dimensional node icon, but there is nothing in the standard that requires its use.
You are free to associate any icon with a node that you want. The only limitation is in what the tool you use will
support. For example, Figure 17-10 draws the same model as Figure 17-9 but with some more familiar icons.
Figure 17-10: Alternative node icons.
Modeling node generalization
Because a node is a type of class, nodes may possess attributes, operations, and associations. In addition, as a
subclass of Class, a node may be generalized. That is, properties of nodes that share the same purpose may be
organized into sets of shared and unique properties, using superclasses and subclasses, respectively, in an
inheritance hierarchy.
For example, Figure 17-11 models a generalization hierarchy of application servers in which application servers
may be configured to three standardized specifications depending on the types of applications they support.
Figure 17-11: Generalizing nodes.
<Day Day Up>
<Day Day Up>
Defining Artifacts
In the transition from design to implementation, every logical construct of the design must be mapped to an
implementation element called an artifact. Each artifact represents an actual piece of software (versus a logical
specification for software such as a class) that may be addressed in a storage device or within processor memory.
Each artifact is a manifestation of one or more model elements. For example, the ContractUserInterface class in a
design model may become an HTML page defined to display contract-related content.
TipArtifacts may also be found in manual systems as paperwork. But since this book is focused primarily on
software system development I chose to keep all the examples related to software systems.
Figure 17-12 is the metamodel of the Artifacts package. Referring to the model, an artifact is a type of classifier. As
such, it may own properties (attributes) and operations. This makes sense because an artifact is the physical
manifestation of the logical requirements defined by a class. In addition, an artifact may be named to uniquely
identify it within a file structure.
Figure 17-12: Artifact package metamodel.
An artifact may be composed of other artifacts (see nestedArtifact in Figure 17-12). For example, the user
interface artifact for a contract could be implemented using a Java Servlet that includes the specification for an
HTML page, compressed into a jar file. (Later, you will see how the rules for deploying an artifact may be
embedded within the artifact as well.)
Now, in order to describe how an artifact is created, the model draws a relationship called a manifestation,
between the artifact and the elements used in its construction. Figure 17-13 adds the manifestation portion of the
Artifacts package to model the rules for this relationship. A manifestation is a type of dependency; specifically it is a
type of abstraction dependency. It is drawn as a dashed arrow between the artifact and each element utilized by
the artifact (see Figure 17-14).
Figure 17-13: Manifestations used to create an artifact.
OMG 2.0
Figure 17-14: The manifestation dependency between an artifact and a model element.
The utilized elements may be any type of packageable element, that is, pretty much anything in the model that can
be named. In Chapter 15, a component was defined as the specification for a physical artifact. A component is
defined in terms of classifiers that together describe all the features of the component. Because an artifact
implements the component requirements, the artifact might use the same classifiers or corresponding
packageable elements that represent physical implementation of the classifiers. For example, Figure 17-14
represents the relationship between the ContractHTML file and the ContractUI class, that is, the ContractHTML file
manifests the specification of the ContractUI class in a specific technology.
Notice the notation for the artifact: a rectangle with a file icon in the top right corner. An artifact may also simply use
a rectangle with the stereotype artifact, as shown in Figure 17-15.
Figure 17-15: Alternative notation for artifacts.
The example in Figure 17-14 highlights an important benefit of modeling the relationship between artifacts and the
elements used to manifest, or produce, the artifact. The basic principles of object-oriented design constantly strive
to separate programming concerns-operation and method, interface and implementation (in terms of behavior and
data), and control-from structure using stereotyped classes. An artifact may be manifested in any number of
technological alternatives. Using the previous example, the same artifact might be generated using a Java Server
Page instead of a Servlet.
Stereotypes can simplify the work of defining artifacts. At a high level of abstraction, artifacts might be distinguished
as source versus executable artifacts. Furthermore, given that developers typically spend considerable time in
one particular set of technologies, it is also useful to stereotype artifacts to represent the standard set of elements
used in a technology platform. For example, Java developers might utilize JSPs, EJBs, Servlets, and HTML. To
facilitate the definition of artifacts, the team may choose to establish a profile that includes these element types as
standard artifact stereotypes, that is, JSP, EJB, Servlet, and HTML.
<Day Day Up>
<Day Day Up>
Deploying Artifacts on Nodes
An artifact must be deployed in order to be used. That is, it must be placed in a location where it may be stored
and used. The target of the deployment may be a node, that is, an execution environment or a device, a property,
or an instance specification. The relationship between the location and the artifact is defined by the Deployment
dependency relationship.
Figure 17-16 is the metamodel for deployments found in the Nodes package. Deployment target is an abstract
class used to identify the common features of elements that may be used as the location to deploy an artifact. By
defining the deployment target and artifacts separately, the model supports a mix-and-match approach to the
assembly of software and hardware elements to craft any number of implementation solutions for a design.
Figure 17-16: Deployment metamodel.
OMG 2.0
DeploymentTarget and DeploymentArtifact are abstract metaclasses. Figure 17-17 shows how deployment targets
may be nodes, properties, or instance specifications, and deployed artifacts may either be artifacts, as previously
defined, or instance specifications.
Figure 17-17: Types of deployment targets and deployed artifacts.
A deployment is modeled as a stereotyped dependency. This dependency may be modeled in any of three ways,
as illustrated in Figure 17-18. The ContractUI.jar artifact is deployed on the ClientWorkstation. In the first example
the deployment dependency is modeled as a dashed arrow from the node to the artifact with the optional
stereotype deploy. In the second example, the artifact icon is physically located within the node icon. In the third
example, the artifacts are listed textually within the node icon.
Figure 17-18: Alternative notations for deploying an artifact on a node.
The definition of an artifact is further specialized in a DeploymentSpecification. A deployment specification adds
properties that describe the execution parameters for an artifact. The parameters are synchronized with the type of
execution environment on which the artifact is deployed. In other words, a deployment specification defines the
relationship between a specific execution environment and the execution of a specific artifact.
Figure 17-19 reveals two properties of a deployment specification. The deploymentLocation identifies where the
artifact is loaded onto the node in terms of a directory or memory location. For example, the ContractUI.jar might
be stored in the application's directory on the client. The executionLocation identifies the execution environment in
which the artifact runs. The ContractUI executes in the java virtual machine (JVM) on the client workstation.
Figure 17-19: Deployment specification metamodel.
OMG 2.0
The parameters for execution defined by a deployment specification may include concurrency, execution, and
transaction-specific options expressed as tagged values:
concurrencyMode - including thread, process, and none (sequential)
executionMode - including local, remote, and none
transactionMode - including transaction, nestedTransaction, and none
Of course, you may also add your own tagged values.
The element that contains the specification values is itself an artifact, such as an XML document or a text file.
Modeling a deployment specification implies the need to represent the definition of the specification as well as the
instances actually applied to artifacts. UML 2.0 uses approximately the same notation as for classes and objects as
shown in Figure 17-20.
Figure 17-20: Deployment specification notation.
Applying the deployment specification to an artifact requires a way to model the relationship. UML 2.0 offers two
alternatives, shown in Figure 17-21. The first example models the deployment specification as a separate model
element with a dependency arrow from the specification to the artifact to which it applies. The second example
models the deployment specification as a set of properties within the artifact icon.
Figure 17-21: Modeling an artifact specification.
<Day Day Up>
<Day Day Up>
Summary
UML 2.0 supports a combined view of the Component and Deployment diagrams that illustrates how software is
implemented in the computing environment. Components are represented by artifacts that implement the
requirements specified by the components in a Component diagram. Nodes and connections on a Deployment
diagram provide the deployment and execution locations for the artifacts.
Component: A component defines the requirements for an implementation of the features specified in a Class
diagram. A component realizes the features of classes (classifiers).
Artifact: An artifact defines the implementation of a component in a specific technology. An artifact manifests
the features of one or more packageable elements used to describe a physical implementation.
Node: A node is either a device or an execution environment within a device. (For manual processes a node
may be an organizational unit.)
Communication path: A communication path is the physical connection between nodes.
Deployment specification: A deployment specification defines how an artifact is allocated to a node, including
the concurrency mode, execution mode, and the transaction mode.
Dependencies model the types of relationships between model elements that represent different levels of
specification within a model. Dependencies on a combined Component and Deployment diagram are modeled as
a dashed arrow with one of the following stereotypes:
Realization: A component realizes, or describes the requirements for implementing, the features of one or
more classifiers.
Manifest: An artifact manifests, or defines a specific implementation for, the features of one or more physical
software elements.
Implement: An artifact implements, or defines one implementation for the requirements defined by a
component.
Deploy: A node deploys, provides a place to store and/or execute, an artifact.
<Day Day Up>
<Day Day Up>
Part VI: Bringing Rigor to the Model
In This Part
Chapter 18: Applying Constraints to the UML Diagrams
Chapter 19: Action Semantics
<Day Day Up>
<Day Day Up>
Chapter 18: Applying Constraints to the UML Diagrams
Overview
As I mentioned in earlier chapters, you can use a formal language, the Object Constraint Language (OCL), to
specify constraints on attributes and associations, and, in fact, on any classifier.
NoteThere was a previous release of the same document under the title "UML 1.4 with Action Semantics." To
my knowledge, the only difference is the addition of the Action Semantics section. The OMG simply
thought that the added content warranted a new version number. You will even find references to 1.4 in
the OCL 2.0 specification.
A constraint may be specified as an invariant, a precondition, or a post condition. This description of a constraint
reveals one very important fact about OCL: OCL is used to specify static requirements.
NoteThere has been work proposed to integrate a dynamic language with OCL, which might be
accomplished using a blend of the action semantics described in Chapter 19. But the primary goal of a
constraint language, and OCL specifically, is to define the state of the system at a point in time.
A precondition defines the state that a system (or other subject) must assume before the specified action may be
taken. Likewise, a post condition defines the state that a subject must be in when the action is completed. An
invariant defines a state that must hold true for the life of the subject. Consequently, a constraint cannot have any
residual effect on the subject, that is, it cannot alter the subject in any way.
Now, having stressed the static nature of OCL expressions, I have to say that OCL may also be used to specify an
operation or action. However, the distinction between OCL and a programming language is that OCL may only
specify the result of a behavior-it cannot execute a behavior. Like an operation, the result of every OCL expression
is a type. But unlike a method (the implementation of an operation), the expression cannot change the state of the
system.
Furthermore, the evaluation of an OCL expression is instantaneous. This means that the states of objects in a
model cannot change during evaluation.
Although there is an earlier version of OCL, this chapter covers only OCL 2.0. In the chapters on specific UML
diagrams, I go into detail about both UML 1.4 and UML 2.0 so that those who are currently using UML 1.4 can
understand what has changed and how to map their existing models to the updated version. However, OCL has
yet to be applied to the extent that the diagrams have, and this new version of OCL is a substantial enhancement.
The previous specification may be downloaded as "UML 1.5 with Action Semantics" on the OMG Web site,
http://www.omg.org/cgi-bin/doc?ptc/2002-09.
OCL 2.0 provides some substantial enhancements to the existing standard:
OCL 2.0 has a metamodel consistent with MOF 2.0, so that OCL uses and extends the same metamodel
used to create other languages such as UML and CWM. This approach supports the OMG objective to
provide a standard modeling framework that may
be extended to provide new modeling tools (languages). a.
ensure interchange of models between vendor products and between problem domains that support
the standard. (In fact, the interchange format is defined as part of the OCL specification.)
b.
1.
2.
b.
The OCL specification provides a concrete syntax that implements the principles defined by the abstract
syntax (expressed as a metamodel). This relationship is analogous to the one in UML, which provides a
diagramming syntax that implements the UML metamodel that also is based on the MOF.
2.
By providing a clear distinction between the abstract syntax and the concrete syntax, OCL 2.0 provides the
means to define any number of alternative concrete bodies of syntax using either text or diagrams.
3.
OCL has been expanded beyond simply defining constraints to an object query and expression language.
Consequently, any model created using the MOF (such as a UML or CWM model) may be queried using
OCL, including the MOF model itself. This is illustrated in the fact that the well-formedness rules for the
UML infrastructure and superstructure are defined using OCL statements.
4.
OCL can now invoke behaviors in order to form the content of a query. OCL statements can evaluate
operations using the OCLMessage concept, a standard approach to describing a behavior and its result (in
the case of synchronous calls). OCLMessage is like a wrapper for an operation. It contains the operation
and supports access to the features and use of the operation. (Technically OCLMessage is a template class
that is instantiated using an operation or signal as the parameter.)
5.
<Day Day Up>
<Day Day Up>
Defining the Object Constraint Language
OCL 2.0 defines the language at two levels, an abstract syntax (or metamodel), and a concrete syntax, the
language actually used in UML models to specify constraints and to make queries. The metamodel defines the
OCL concepts and rules for applying the concepts, or abstract syntax, in the same manner that a metamodel
defines the diagramming concepts and rules for UML diagrams. The concrete syntax implements the abstract
syntax. The concrete syntax provided in the UML 2.0 specification is only one of any number of implementations of
the OCL metamodel. The concrete syntax corresponds to the diagramming notations in UML.
Introducing the abstract syntax
Abstract syntax refers to the conceptual level of the language definition for OCL. In UML, the abstract syntax is
expressed as a metamodel (2M or Infrastructure) that explains, for example, what a class is, or what an operation
is, as opposed to creating a specific class or operation. Specifically, the UML 2M defines a class as a description
for "a set of objects that share the same specifications of features, constraints, and semantics." It explains that a
class may be associated with any number of properties (attributes), operations, relationships, and even nested
classes. In like manner, as the portion of the metamodel pictured in Figure 18-1 illustrates, the OCL metamodel
defines an OCL expression and its relationships to other meta-concepts such as classifiers, loop mechanisms, and
variable expressions.
Figure 18-1: A portion of the abstract syntax/metamodel.
OMG 2.0
In contrast, the concrete syntax, or model-level syntax, describes a class that represents some real-world entity.
For example, the class Person has properties, including name and address; operations, including work, play, and
sleep; and an "owns" association with the class Book. The following OCL statements define invariants on the
attributes of the class Event. The first example states that the number of performances linked to an Event must be
equal to or greater than one, that is, reflect a multiplicity of 1..*. The second example states that the date of the
performance must be equal to or greater than the start date of the event, with which the performance is
associated.
context Event inv:
self.performance->size() >= 1
context Performance inv:
self.date >= event.startDate
The RFP for OCL 2.0 requires the new standard to define a clear distinction between the abstract syntax for OCL
and any concrete syntax derived from the abstract syntax. The abstract syntax supports the development of
additional constraint languages, just as the MOF/UML Infrastructure metamodel supports the development of
modeling languages for various specialized domains, such as UML for modeling software and the CWM for
modeling data warehouse domains.
The RFP also stated that the new standard needed to be compatible with the UML 2.0 metamodel. Consequently,
the abstract syntax uses the same data types and extension mechanisms defined by the MOF/UML Infrastructure
metamodel, plus a few new ones of its own.
Finally, the abstract syntax needed to support a true query language, so new concepts have been introduced. For
example, the concept of tuple is added to provide the expressiveness of SQL. As a complete query language, OCL
may be used to map the transformation of models, an integral part of the OMG MDA strategy for transitioning
models from requirements, through design, and on to implementation.
Introducing the concrete syntax
In contrast to the rule-oriented abstract syntax, the concrete syntax applies the rules of the abstract syntax to create
expressions that may be evaluated at runtime. The OCL expression is associated with a classifier, and applied to
either the classifier itself or to an attribute, operation, or parameter. In each case the constraint is defined in terms
of its placement, the contextual classifier, and the self instance of the OCL expression.
The placement is the position where the OCL expression is used in the UML model, that is, as an invariant
attached to a classifier, a precondition attached to an operation, or a default value attached to a parameter.
The contextual classifier defines the namespace in which the expression is evaluated. For example, the
contextual classifier of a precondition is the class that is the owner of the operation in which the precondition is
defined. This means that all model elements within that class, such as attributes, associations, and operations,
may be referenced within the OCL expression.
The self instance is the reference to the object that evaluates the expression. It is always an instance of the
contextual classifier. This means that evaluation of an OCL expression may result in a different value for every
instance of the contextual classifier. Consequently, OCL may be used to evaluate test data.
OCL concrete syntax may be used for a number of different purposes:
As a query language
To specify invariants on classes and types in the class model
To specify a type invariant for Stereotypes and attributes
To specify derivation rules for attributes
To describe pre- and post conditions on operations and methods
To describe guards
To specify a target, or target sets, for messages and actions
To specify any expression in a UML model, such as those associated with Behaviors, Parameters,
ChangeTriggers and TimeTriggers, and Lifelines
NoteThe concrete syntax still has a couple of unresolved issues. In UML 2.0, pre- and post conditions are
viewed as separate entities. OCL considers them parts of a single operation specification. So the
mapping of multiple pre- and post conditions in a single operation has yet to be determined.
Frame conditions define a context in which to interpret a constraint, so that unless a constraint is explicitly
stated, it is understood that everything else about the context (frame) not explicitly mentioned should
remain the same. This ensures that there are no undefined side effects for an operation.
Backward Compatibility
The new standard also needed to be backward compatible with OCL 1.4. As an example, collections as
defined in UML 1.4 (1.5 with Action Semantics) are always flat, or one-dimensional. UML 2.0 defines
collections to allow for nested collections. But this means that existing operations such as collectNested() must
still work as specified in the earlier version. To address this requirement, UML 2.0 preserves the old operations
with their original meaning, and provides additional operations to cope with nested collections.
<Day Day Up>
<Day Day Up>
Accessing Properties in a UML Diagram
In order to apply OCL to UML, this chapter uses the example Class diagram shown in Figure 18-2. The diagram
says that
A Venue employs Employees.
Those employees report to one another in a hierarchical structure of supervisors and subordinates.
Employees may report to more than one supervisor.
Employees, while in the role of venue manager, may authorize contracts with agents.
A contract authorizes one agent, and is authorized by one venue manager.
In order for an agent to be in the system he must have at least one contract, that is, he has been authorized at
least once by a venue manager.
EmployeeStatus is an enumeration that lists the valid values for the empStatus attribute used in the Employee
class definition.
ContractStatus is an enumeration that lists the valid values for the status attribute used in the Contract class
definition.
OCL statements may be assigned to just about any element seen in Figure 18-2. But in order to assign a constraint
we must be able to define the placement of the constraint. The placement is defined in terms of an element of a
UML model - the attribute Employee firstName, the role name agent on the authorizes association, or the
operation Agent.getName(), for example.
Figure 18-2: Sample Class diagram.
Every element of a UML model resides within a context. For OCL statements, the context is always expressed as
an OCL classifier. The result of an OCL expression is always a data type. Figure 18-3 is the model for all OCL data
types defined in the OCL Standard Library.
Figure 18-3: OCL Standard Library.
OMG 2.0
The OCL Standard Library includes UML model types under the class OCLAny, as well as OCLMessages and
Collections. OCLAny encompasses all OCL primitive types (Real, Boolean, String, and Integer) and all types
defined in a UML model. The classes OCLType, OCLState, and OCLModelElement are enumerations that map
the parts of a UML model to the OCL syntax so that the elements can be referenced in OCL statements. In other
words
There is an entry in the OCLModelElement enumeration for every element defined in a UML model. The
OCLModelElement value is used as the parameter on the ocllnState() and oclIsKindOf() operations to find
out the state of a model element and the type of the model element, respectively.
There is an entry in the OCLType enumeration for each class of objects defined in a UML model. A value from
this enumeration is returned from the operation oclIsKindOf(ome:OCLModelElement) identifying the type of
the model element passed in as the parameter. This is most useful when the actual type is a subtype in a
generalization hierarchy and the constraint needs to evaluate the specific subtype.
There is an entry in the OCLState enumeration for each state defined in a UML model. A value from this
enumeration is returned from the operation oclIsInState(ome:OCLModelElement) identifying the state of the
model element passed in as the parameter.
OCLMessage and OCLCollection (and their subclasses) are template classes, designated by the "T" in a box in
the top right corner of the class. A template class cannot be instantiated directly. Instead, it requires a parameter,
some other type, which defines the contents of the instantiated class. For example, a Set with the parameter Agent
is instantiated as a Set that contains only unique instances of Agent objects. A Set with the parameter Contract is
instantiated as a Set that contains only unique instances of Contract objects.
The OCL Standard Library is documented fully later in this chapter.
The context for an OCL expression is written using the context keyword and the context classifier name, as the
following example shows:
context Employee...
-- this context statement identifies the Employee class
as the context classifier
context Contract...
-- this context statement identifies the Contract class
as the context classifier
Note the use of the double dash (--) for comments.
When a model involves many packages there is a possibility that class names may be duplicated across
packages. The following code samples represent two classes with the name Employee defined in two different
packages within the TheaterSystem package. In this case, the fully qualified description of a context classifier
includes the keyword package and the package path name:
package TheaterSystem::Sales
context Employee...
and
package TheaterSystem::ContractAdministration
context Employee...
where the double colons (: :) act as separators for the package names to indicate containment. In this example,
the ContractAdministration package is contained in the TheaterSystem package.
The constraint may be applied to the context classifier itself or to one of its properties. Properties include attributes,
operations, and association ends.
CautionOnly those operations that do not change the state of the system may be used in OCL statements.
Modeling constraints on attributes
Constraints on attributes are expressed as invariants. Invariant expressions are constructed using references to
elements of the model with logical and arithmetic operators. References created within expressions may be reused
through the application of let and def statements.
Invariants
An invariant is a rule that must hold true throughout the life of the attribute. In UML, an invariant (constraint) on an
attribute is modeled as a property, an expression enclosed in curly braces following the attribute declaration.
Here's an example of a UML attribute declaration:
-startDate:Date {can't overlap any other contracts for
the same agent}
The default value is the current date. The invariant states that the start date of this contract cannot overlap the
effective period of any other contracts for the same agent.
Invariants in OCL use the keyword inv. For example:
package TheaterSystem::ContractAdministration
context Employee
inv: firstName -> size() >=1 and firstName->size() <=30
The example invariant states that the context classifier is the Employee class found in the ContractAdministration
package, within the TheaterSystem package. The invariant further states that the property, an attribute called
firstName, must be at least one character and no more than 30 characters in length.
The last line of the example reveals the syntax for invoking features of the OCL elements. The attribute
firstName is part of the Employee class. The attribute firstName is a String. The expression
firstName.size() uses the predefined operation size() on the String OCL data type. The dot notation is the
OCL standard approach for accessing features of an OCL data type. Other features of the OCL String data type
include concat, substring, tolnteger, and toReal (). All of these features are defined in the OCL
Standard Library later in this chapter.
The operators >= and <= are among the set of standard operators for OCL expressions. The complete set of
operators is described in Table 18-1.
Table 18-1: OCL Infix Operators
+ addition
- subtraction
* multiplication
/ division
< less than
> greater than
<> not equal to
<= less than or equal to
>= greater than or equal to
and both values must be true
or at least one of the expressions must be true
xor only one of the expressions is true
let and def expressions
In the evaluation of an OCL expression, it is often necessary to introduce an interim value used only in the
expression. The let expression enables you to define a variable, assign a data type using the colon (:)
designation, and even assign an initial value using the equal to (=) operator. Once the variable is defined, it may be
used anywhere in the rest of the expression that contains it. When the expression completes, the variable is no
longer available for use. In other words, the variable is scoped by the expression in which it is defined. In the
following example, lengthOfEmployment is available only within the context Employee invariant expression.
context Employee inv:
let lengthOfEmployment: Integer = <expression> in
if lengthOfEmployment > 365
then <expression>
else <expression>
endif
The def (definition) provides the means to use a variable whenever the context classifier is evaluated. The def
expression is defined independent of the places where it may be used. Once the definition is created in the context
classifier, it may be used in any expression applied to the same context classifier.
An attribute definition uses the keywords def: attr:
context Agent
def: attr lengthOfEmployment: Integer = <expression>
An operation definition uses the keywords def: oper:
context Agent
def: oper averageSalesPercentage(): Integer
Modeling pre- and post conditions on operations
Constraints may be assigned to operations in two forms:
A precondition, which defines the required state of the model before the operation may execute.
A post-condition, which defines the required state of the model after the operation has completed execution.
A precondition is expressed in terms of the acceptable values of the input parameters and/or the state of the model
when the operation is invoked. For example, the operation Employee.setAwardStatus () is invalid if the
employee is currently on probation or in disciplinary status. The context of the constraint is the Employee class.
The property is the setAwardStatus () operation. The constraint is a precondition, designated with the
keyword pre. The following OCL statement captures these requirements:
context Employee: :setAwardStatus(): Boolean
Pre:
status <> EmployeeStatus:: PROBATION and
status <> EmployeeStatus:: DISCIPLINE
EmployeeStatus is an enumeration, and both probation and discipline are allowed values of the enumeration.
The double colon (::) is used to identify a value within the enumeration.
You also can use literals, as in
context Employee: :setAwardStatus (): Boolean
Pre:
status <> 'PROBATION' and
status <> 'DISCIPLINE'
Note that the line breaks are discretionary. The following expressions are also valid:
context Employee::setAwardStatus():Boolean
Pre: status <> EmployeeStatus::PROBATION and
status <> EmployeeStatus::DISCIPLINE
context Employee::setAwardStatus():Boolean Pre:
status <> EmployeeStatus::PROBATION and
status <> EmployeeStatus::DISCIPLINE
A post condition states what must be true when the operation has completed. This is expressed by testing the
result value of the operation and/or the state of the model when the operation has completed. For example, in the
following OCL expression the operation setAwardStatus () is supposed to change the value of the attribute to
EmployeeStatus::award, so when the operation has completed, the test for the expected change should
result in a true value.
context Employee::setAwardStatus():Boolean
post:status = EmployeeStatus::AWARD
The standard also supports the use of constraint names. For pre- and post conditions the name is placed
immediately after the keyword and before the colon, as in the following code snippet:
context Employee: :setAwardStatus (): Boolean
post success: status = EmployeeStatus::AWARD
A post condition may also require that, for the operation to succeed, it must have sent a message to another
object. To do this, OCL needs a means to specify operation calls. To express that an operation has been invoked
on another object, specify the object type, the ^ (has been sent) symbol, and the operation that must have been
sent to the object. For example, when the setAwardStatus() operation has completed it must have sent the
message issueAward (e:Employee) to the HumanResources object (the parameter value for the message
is the current employee instance):
context Employee
post: HumanResources^issueAward(self)
The post condition reads, "The HumanResources object has been sent (^) the message issueAward', along with
the information about the current employee instance (the self-instance)".
A post condition may refer to values for properties of an object at two points during the evaluation of the
expression: at the start of the operation or upon completion of the operation.
To refer to the value of a property at the start of the operation, postfix (add to the end of) to the property name the
keyword @pre:
context Employee assign(empl:Employee):Boolean
post: nbrOfSubordinates = nbrOfSubs@pre + 1
CautionAttempting to access a property of an object that has been created or destroyed during execution of
the operation results in the type OclUndefined.
Navigating associations
A constraint is often based on the relationships between objects and/or values of attributes of associated objects.
Making references to associated objects is referred to as navigating across the association. OCL uses dot notation
to trace the ownership of information across a set of objects and their attributes. For example, in the sample Class
diagram in Figure 18-2, an agent is associated with the employees who have functioned as venue managers on
the contracts that the agent has with the theater company.
When a venue manager needs to look up information about agents with whom he has contracted, the OCL
expression simply prefixes the property name with the role name of the end of the association next to the class
being referenced, as in associationEndName.address. For example:
context Employee
inv: self.workLocation() = venue.address()
In this example, venue is the role name of the end of the employs association next to the Venue class, as shown
in Figure 18-2.
In this second example, the result of the operation currentContract is an object of type Contract. So, the
result of currentContract () is used in the OCL expression to gain access to the Contract attribute status:
context Agent terminate():Boolean
post: currentContract().status=
ContractStatus::TERMINATED
If there is no role name on the association end, the type of the object is used. This works just about everywhere
except on reflexive associations where the types on both ends are the same. In that case, the role names are
required in order to remove the ambiguity from the references.
Navigating across associations has to take into account the multiplicity of the association end. When the maximum
multiplicity value is one, the reference is a single object, as in the previous examples. But when the multiplicity
allows more than one instance, the result is a Set object containing all of the objects in the relationship, without any
duplicates. If the {ordered} constraint is applied to the association end, the result is a Sequence, an ordered group
of objects.
Navigating to association classes uses the same basic reasoning. Because there is no role name, the type of the
reference is the type of the association class. In Figure 18-4, an agent is associated with the Contract class, an
association class describing the relationship between a venue manager and an agent.
Figure 18-4: Navigating an association class.
When an agent behavior needs to reference a property of the association class, use the dot notation and write the
name of the association class in lower case:
context Agent
inv: contract->size() >= 1
This example states that in order for an agent to exist, he must participate in at least one contract.
CautionAs the examples become more complex, I won't write out the entire OCL expression when trying to
illustrate a single point about syntax. I will occasionally use an ellipsis () to indicate that I am
omitting some information not directly pertinent to the current topic.
If the association class describes a reflexive association, as does the Assignment class in Figure 18-5, then the
class name is not enough. The association class may be accessed by employees participating on either end of the
association. Without further explanation we cannot know how the employee is participating in the relationship and
whether or how they should access the association class. For example, an employee functioning as a subordinate
should not be able to query his supervisor's assignments, but a supervisor must be able to query her subordinates'
assignments.
Figure 18-5: Navigating to an association class on a reflexive association.
To clarify the context, append the role name supervisor in square braces [supervisor] as in the following
expression:
context Employee
inv: ... self.assignment[supervisor] ...
The preceding expression refers to the set of assignments that describe relationships between the context
employee and all of the associated supervisors. Use this approach when you want to find out who an employee
has been assigned to work for and when he worked for them.
The following expression refers to the set of assignments that describe relationships between the context
employee and all of the associated subordinates. Use this approach when you want to find out who is working for
the employee and when they worked for her.
context Employee
inv: ... self.assignment[subordinate] ...
Navigating out of an association class, to either of the classes on the ends of the association, uses the standard
dot notation. When the association class Assignment needs to refer to the object playing the subordinate role it
uses subordinate.property. When the association class Assignment needs to refer to the object playing the
supervisor role it uses supervisor.property.
context Assignment
inv:
... subordinate.firstName ...
... supervisor.firstName ...
To navigate a qualified association, the qualifier value is enclosed in square braces following the type of the
referenced object. In the following example, a venue looks up an employee using an employee id value:
context Venue
inv: ... self.employee[123456] ...
If there is more than one qualifier attribute, the values are separated by commas, in the order specified in the UML
class model.
context Venue
inv: ... self.employee[Pender, Reno] ...
Also note that OCL does not allow the use of a partially specified qualifier value.
Accessing overridden properties
When using subclasses, it is valid to override an inherited attribute definition or operation. If you need access to the
definition in the superclass, use the oclAsType expression to recast the object reference to the type of the
superclass. Here's an example:
context PremiumContract
inv: ... self.oclIsType(Contract).terms ...
This expression accesses the terms property as defined in the superclass Contract instead of the definition
provided in the context class called PremiumContract.
<Day Day Up>
<Day Day Up>
Using the Predefined Properties for all Objects
There are several predefined properties that apply to all objects, namely OclType and OclState.OclType
contains a reference to the classifier type associated with the context object. OclState contains a reference to
the current state of the context object.
These properties can be used to evaluate an object before trying to use it. Standard operations that use these
properties provide the means to test the object's type, to test whether it is a subclass of another type of object, to
test the current state of the object, and to test whether it was created as part of the current operation. You can
even recast the object as one of its subtypes. The operations to test these predefined properties are as follows:
oclIsTypeOf (t: OclType): Boolean
oclIsKindOf (t: OclType): Boolean
oclInState (s: OclState): Boolean
oclIsNew (): Boolean
oclAsType (t: OclType): instance of OclType
oclIsTypeOf
Use the property oclIsTypeOf to determine whether the current object is the same type as the context object. To
do so, test the property value using the corresponding operation oclIsTypeOf(type). For example:
context Agent
inv: self.oclIsTypeOf(Agent) -- is true
inv: self.oclIsTypeOf(Venue) -- is false
oclIsKindOf
The oclIsTypeOf example dealt with the direct type of an object. Use the operation oclIsKindOf(t) to
determine whether it is either the direct type of an object or one of the supertypes of an object.
context PremiumContract
inv: self.oclIsKindOf(PremiumContract)
-- true for both contracts and premium contracts
oclInState
Use the operation oclInState(s) to determine the current state of an object. Values for s are the names of the
states in the state machine(s) attached to the classifier of object. For nested states, the state names may be
combined using the double colon (::). In the example state machine in Figure 18-6, values for s can be
Probation, Normal, Probation::AwaitingReview, Probation::NewHire.
Figure 18-6: Sample partial state machine for Employee.
The valid OCL expressions based on Figure 18-6 are:
object.oclInState(Probation)
object.oclInState(Normal)
object.oclInstate(Probation::AwaitingReview)
object.oclInState(Probation::NewHire)
If there are multiple state machines attached to the object's classifier, the state name can be prefixed with the
name of the state machine containing the state and the double colon (::), as with nested states.
oclIsNew
Use the operation oclIsNew() only in post conditions to determine whether the object was created during the
execution, as in
context Contract
Contract(start:Date, end:Date, terms:String)
post:self.oclIsNew()
In this example, the expression tests to see whether the instance of contract was created during the execution of
the constructor Contract(start: Date, end: Date, terms:String).
OclAsType
OclAsType allows the expression to recast an object into a more specific type. For example, an expression may
be passed a value of type Contract, but the expression needs to evaluate properties unique to
PremiumContracts:
context Contract
inv: ... self.oclAsType(PremiumContract).terms ...
<Day Day Up>
<Day Day Up>
Working with Collections
Many of the results of OCL expressions contain more than a single value. Many of them include lists of objects that
OCL calls Collections. OCL defines four types of lists - Collection, Set, Bag, and Sequence - as shown in Figure
18-7.
Figure 18-7: OCL Collection classes.
Collection is an abstract type, with the concrete collection types as its subtypes:
A Set contains a group of like items (the same type) and may not contain any duplicates. There is no specified
order to the elements of the set.
A Bag contains a group of like items (the same type) but, unlike a set, may contain duplicates. There is no
specified order to the elements of the bag.
A Sequence is like a Bag, but the elements are ordered. This feature corresponds to the use of the {ordered}
constraint on a group of elements in a UML diagram - instances of a class on the end of an association or
multiple values of an attribute, for example.
CautionThe "order" in a Sequence refers to the placement of an item within the sequence, not an ordering
based on the values of the elements themselves.
In UML 1.4, a collection in OCL is always flat, that is, a collection can never contain other collections as elements.
This restriction is lifted in UML 2.0 to allow collections to contain elements that are also collections. The OCL
Standard Library includes specific flatten operations for collections:
collectNested(), which is identical to the OCL 1.4 collect, but without flattening applied
flatten(), which flattens a nested collection
collect(), which is identical to collectNested()- > flatten ()
Each of these operations is explained later in the "OCL Standard Library" section.
Collection operations
OCL defines a number of operations specifically aimed at addressing the need to facilitate the manipulation of
collections:
select functions like a filter to pick and choose items from a collection to make a new collection that
contains only the items that meet the specified criteria.
reject is the opposite of select(), effectively creating a collection of items that do not meet the specified
criteria.
collect is used to create a new collection from information gleaned from another collection or collections.
forAll allows the specification of a constraint that is applied to every element in a collection.
exists determines whether a value is found in at least one member of a collection.
iterate accesses each member of a collection, enabling evaluations and queries to be performed on each
element.
The properties of a collection are accessed using the arrow symbol (- >) between the collection name and the
property. For example,
collection -> select(...)
agents -> select(...)
The parameter of the select, reject, collect, forAll, and exists operations is the same. They take on
four forms, three standard forms and a shorthand form.
In this first form, the operation uses the Boolean to evaluate every member of the collection:
collection -> operation(boolean-expression)
Here's a sample OCL statement using the select operation:
context Venue
inv: self.employee ->
select(status = EmployeeStatus :: PROBATION)
This statement iterates through all the members of the employee collection defined in the venue (through the
association with the Employee class). It creates a collection of all employees employed at the current venue, and
who are on probation.
In this second form, the operation uses the variable v to hold each member of the collection as it iterates through
the members. It then evaluates the Boolean expression against the member held in the variable.
collection -> select ( v | boolean-expression)
Naming the variable allows named access to the properties of the member. In this example, status is an attribute
of an employee.
context Venue
inv: self.employee -> select
( e | e.status = EmployeeStatus :: probation)
In the third form, the variable is assigned a type, which must conform to the type of the collection:
collection -> select( v: Type | boolean-expression)
The following example defines the type of the variable.
context Venue
inv: self.employee -> select
( e: Employee | e.status = EmployeeStatus :: probation)
The iterate operation provides a shorthand form to read through every member of a collection and accumulate
information. The result is a value expressed as the accumulator variable in the following syntax. In order to
iterate through a collection, the iterate expression needs an iterator, designated as element in the example.
collection -> iterate
( element: Type 1; accumulator: Type2 = <initial value
expression> | <evaluation expression>)
This expression says, "Iterate through the collection. For each element (of Type1), evaluate the
<evaluation expression> and save the result in the accumulator (of Type2), which was initialized using
the <initial value expression>."
For example, the following expression accumulates the number of contracts authorized by Employees at a venue:
Context Venue
inv:
employee -> iterate
( e: Employee: contracts: Integer = 0 |
contracts = contracts + e.contract.size())
Creating collections using literals
Collections may be created explicitly by the use of literals. Simply write the name of the collection type followed by
the list of comma-separated values enclosed within curly brackets, as illustrated in the following examples:
Set {1 , 2 , 5 , 88}
Set {'Tom' , 'Cathy' , 'Susan'}
Sequence {1, 3, 45, 2, 3}
Sequence {'agent', 'premier agaent'}
Bag {1 , 3 , 4 , 3 , 5}
A Sequence may also be defined by specifying a range using the variables Int-expr1 and Int-expr2. The
range notation is the same as for multiplicity in UML-minimum..maximum, or more precisely, Int-expr1..Int-
expr2. Place the range within the curly braces where you would normally place the series of comma-separated
values. For example,
Sequence {1. .10}
Sequence {1. .(maxCount)} -- where maxCount = 10
-- are both identical to
Sequence{1, 2, 3, 4, 5, 6, 7, 8, 9, 10 }
<Day Day Up>
<Day Day Up>
Using Messages in OCL
OCL supports access to existing operations. This means that an OCL expression may send messages in the forms
of operation calls and signals. To do so, OCL provides three mechanisms:
^: The hasSent symbol. This symbol indicates that the specified object has been sent the specified message.
NoteHereafter, I refer to this symbol (^) as the hasBeenSent symbol because I believe this name is more
accurate and helps clarify the meaning of the expressions in which it is used.
OclMessage: OclMessage is a sort of container for evaluating messages and providing access to their
features.
^^: The enhanced form of the hasSent symbol, which allows access to the set of messages that has been
sent. Each message is contained within an OclMessage.
To evaluate whether a message has in fact been sent, specify the target object, the ^ (hasBeenSent symbol), and
the message that should have been sent. For example, the expression
context Agent::terminate()
post: currentContract()^terminate()
states that when the agent operation terminate() has completed execution, the current contract for the agent
should have been sent the message terminate(). In other words, when the system terminates an agent, it must
make certain that the agent's contract is also terminated.
Messages may include parameters. When an operation specifies parameters, the values passed in the expression
must conform to the parameter types. If the parameter values are unknown prior to evaluation of the expression,
use a question mark in place of the parameter, and provide the type as shown in the following sample expression.
First, here are the operation declarations:
Agent terminate (date: Date, vm: Employee)
Contract terminate (date: Date)
And here's the OCL expression:
context Agent::terminate(?: Date, ?: Employee)
post: currentContract()^terminate(?: Date)
This example states that the message terminate has been sent to the current contract object, but we don't
know, and don't care, what the parameter values were.
The ^^ message operator supports access to a Sequence object that contains the sent messages. Each message
in the set is contained within an OclMessage (more on OclMessage in a moment). For example,
context Agent::terminate(?: Date, ?: Employee)
post: contracts^^terminate(?: Date)
This expression results in a Sequence object that contain the messages sent to all the contracts associated with
the agent instance during the execution of the terminate operation on the agent.
To gain access to the messages themselves, OCL provides the OclMessage expression. OclMessage is
essentially a container that provides some predefined operations that help evaluate the execution of the operation,
namely:
hasReturned(): Boolean
result(): The return type of the called operation
isSignalSent(): Boolean
isOperationCall(): Boolean
The complete descriptions for these operations are provided in the OCL Standard Library.
Using OclMessage, you can now gain access to the individual messages returned by the previous expression that
used the ^^ message operator. To set up the OclMessage, use the let statement to create a variable of type
Sequence to contain the Sequence obtained from the ^^ message operator.
Operation declarations are as follows:
Agent terminate (date: Date, vm: Employee)
Contract terminate (date: Date)
And here's the OCL expression:
context Agent::terminate(?: Date, ?: Employee)
post: let messages: Sequence(OclMessage) =
contracts^^terminate(?: Date) in
messages->notEmpty and
messages->forAll(contract |
contract.terminationDate = agent.terminationDate and
contract.terminationVM = agent.terminationVM)
This expression evaluates each message sent to each contract to test whether the date and venue manager
attributes have been set properly to coincide with the values in the agent.
The one significant difference between operations and signals in an OCL expression is the fact that an operation
has a return and a signal does not. Attempting to use the result of an operation that has not completed execution
yields an error. OCL syntax provides the has Returned() operation to test whether an operation has completed
execution. When the result of hasReturned() operation is true, the OCL expression can continue, knowing that
the values generated by the operation are accessible. If the result of hasReturned() operation is false, testing
the outcome result of the operation is not possible and the OCL expression should terminate.
In the previous OCL expression, the statements messages->notEmpty and following would be references to
non-existent values if the operation never complete execution. The addition of the messages.hasReturned()
operation prevents the following statements from executing when there are no values to reference.
context Agent::terminate(?: Date, ?: Employee)
post: let messages: Sequence(OclMessage) =
contracts^^terminate(?: Date) in
messages.hasReturned() and
messages->notEmpty and
messages->forAll(contract |
contract.terminationDate = agent.terminationDate and
contract.terminationVM = agent.terminationVM)
<Day Day Up>
<Day Day Up>
Creating and Using Tuples in OCL
A tuple is the definition of a block of data elements, such as a record in a file or a row in a database. Each
element, or column, is named and typed. A tuple may be created using literals or assigned values based on
expressions.
A tuple is defined in OCL using curly braces around a series of name: type pairs and optional assigned values:
Tuple {name: String = 'Tom', age: Integer = 45}
The tuple is only a means to assemble a set of values. The tuple must then be assigned to a variable. The
following expression uses a def (definition) expression to create a new attribute called sales within the context of
an agent classifier. sales is a Set of tuples. sale is the name of the tuple.
context Agent def:
attr sales : Set
(sale(venue: Venue, performance: Performance,
soldSeats: Integer, perfCommission: Integer)
)
...
This expression defines a Set of tuples containing information about an agent's sales for each performance.
Subsequent expressions could define how to set the values for each tuple. From that point on, the sales attribute
of Agent would contain the set of tuples and the assigned values.
<Day Day Up>
<Day Day Up>
Using Class-Level Features
All the features described so far apply to instances. But just as in programming, there are times when the
application needs to perform queries and tests against the set of instances that make up the class. One such
class-scoped feature in OCL is the allInstances() operation. allInstances() returns a set of objects of
the type defined by the class. For example, the following expression returns the set of all agent instances that have
more than one contract.
context Agent
... self.allInstances()->forAll(contract->size() > 1)...
Once you have the result set, you can use any of the collection operations on that set.
<Day Day Up>
<Day Day Up>
OCL Standard Library
The previous section covers a number of possible applications of OCL expressions in a UML model using a variety
of OCL types. The OCL Standard Library defines the complete set of available OCL types used to form OCL
expressions. Each type has a set of operations (and sometimes attributes) that is available on objects of that type.
Every OCL statement results in a value of some defined type. Very often the result is a Boolean value, because
constraints are most often tests against the condition of an object or set of objects. The allowed OCL types are
defined in the OCL Standard Library (refer back to Figure 18-3) and any type defined in a UML model - Venue,
Contract, or Agent, for example.
OclAny covers any type defined in a UML model, using OclType, OclState, and Ocl Model Element to
track them. Boolean, String, Real, and Integer support the basic primitive types we've come to expect in
data manipulation languages.
The OclMessage and Collection metaclasses are all template classes designated with a T in the top right corner.
This means that they cannot be directly instantiated. Instead, they are instantiated by providing a parameter. For
example, the Sequence class may be instantiated as a sequence of type Agent (the parameter), such as an
ordered list of Agents, which may include duplicates.
The following sections provide detailed descriptions of each of the standard OCL types and their usage.
The OclAny, OclMessage, and OclVoid types
The OclAny type includes not only the subclasses shown in Figure 18-3, but the UML model types as well. In fact,
UML model types inherit all of the features of OclAny. The primitives correspond to the primitives defined for most
programming languages.
OclMessage defines either a signal or an operation. The features of OclMessage allow access to the properties
of an operation, including its result, whether it is a signal or call, and if it is a call, whether it has returned.
OclVoid defines a single instance that contains an undefined value.
OclAny
The type OclAny is the supertype of all types in the UML model and the primitive types in the OCL Standard
Library. All classes in a UML model inherit all operations defined on OclAny. To avoid name conflicts between
properties in the model and the properties inherited from OclAny, all names on the properties of OclAny start
with ocl. One can also use the oclAsType() operation to explicitly refer to the OclAny properties.
In all of the following operation descriptions, the instance of OclAny is called object.
= (object: OclAny): Boolean
Description: True if self is the same object as object.
post: result = (self = object)
<> (object: OclAny): Boolean
Description: True if self is a different object from object. not is an Infix operator.
pre: result = not (self = object)
oclIsNew(): Boolean
Description: May only be used in a post condition because it tests to see whether it was created by the expression.
oclIsNew() evaluates to true if the self is created during performing the operation, meaning that it didn't exist at
precondition time.
post: self@pre.oclIsUndefined()
oclIsUndefined(): Boolean
Description: Evaluates to true if the self is equal to OclUndefined.
post: result = self.isTypeOf(OclVoid)
OclMessage
This section contains the definition of the standard type OclMessage. As defined in this section, each OCL
message type is actually a template type with one parameter. A concrete OCL message type is created by
substituting an operation or signal for the parameter. Every OclMessage is fully determined by either the operation,
or signal given as parameter. Every type has as attributes the name of the operation or signal, and either all formal
parameters of the operation, or all attributes of the signal.
hasReturned(): Boolean
Description: True if the type of template parameter is an operation call, and the called operation has returned a
value. This implies that the message has been sent.
post: result(): The return type of the called operation
Description: Returns the result of the called operation if the type of the template parameter is an operation call and
if the called operation has returned a value. Otherwise the result is undefined.
pre: hasReturned()
isSignalSent(): Boolean
Description: Returns true if the OclMessage represents the sending of a UML Signal.
isOperationCall(): Boolean
Description: Returns true if the OclMessage represents the sending of a UML Operation call.
OclVoid
The type OclVoid is a type that conforms to all other types. It has a single instance called OclUndefined. Any
property call applied on an undefined type results in OclUndefined, except for the operation
oclIsUndefined(), which returns true.
oclIsUndefined(): Boolean
Description: oclIsUndefined() evaluates to true if the object is equal to OclUndefined.
post: result = true
ModelElement types
This section defines several enumeration types that allow the modeler to refer to elements defined in the UML
model.
OclModelElement
An OclModelElement is an enumeration. For each element in a UML model there is a corresponding
enumeration literal.
= (object: OclModelElementType): Boolean
Description: True if self is the same object as object.
< > (object: OclModelElementType): Boolean
Description: True if self is a different object from object.
post: result = not (self = object)
OclType
An OclType is an enumeration. For each Classifier in a UML model there is a corresponding enumeration literal.
= (object: OclType): Boolean
Description: True if self is the same type as object.
< > (object: OclType): Boolean
Description: True if self is a different type from object.
post: result = not (self = object)
OclState
An OclState is an enumeration. For each state in a UML model there is a corresponding enumeration literal.
= (object: OclState): Boolean
Description: True if self is in the same state as object.
< > (object: OclState): Boolean
Description: True if self is in a different state than object.
post: result = not (self = object)
Primitive types
The primitive types defined in the OCL Standard Library are Real, Integer, String, and Boolean. They are all
instances of the metaclass Primitive from the UML core package.
Real
The standard type Real represents the mathematical concept of real. Note that Integer is a subclass of Real,
so for each parameter of type Real, you can use an integer as the actual parameter.
+ (r: Real): Real
Description: The value of the addition of self and r.
- (r: Real): Real
Description: The value of the subtraction of r from self.
* (r: Real): Real
Description: The value of the multiplication of self and r.
-: Real
Description: The negative value of self.
/ (r: Real): Real
Description: The value of self divided by r.
abs(): Real
Description: The absolute value of self.
post: if self < 0 then result = - self
else result = self
endif
floor(): Integer
Description: The largest integer that is less than or equal to self.
post: (result <= self) and (result + 1 > self)
round(): Integer
Description: The integer that is closest to self. When there are two such integers, the largest one.
post: ((self - result).abs() < 0.5) or
((self - result).abs() = 0.5 and (result > self))
max(r: Real): Real
Description: The maximum of self and r.
post: if self >= r then result = self
else result = r endif
min(r: Real): Real
Description: The minimum of self and r.
post: if self <= r then result = self
else result = r endif
< (r: Real): Boolean
Description: True if self is less than r.
> (r: Real): Boolean
Description: True if self is greater than r.
post: result = not (self <= r)
<= (r: Real): Boolean
Description: True if self is less than or equal to r.
post: result = ((self = r) or (self < r))
>= (r: Real): Boolean
Description: True if self is greater than or equal to r.
post: result = ((self = r) or (self > r))
Integer
The standard type Integer represents the mathematical concept of integer. Integer is itself an instance of the
metatype Primitive (from UML Core).
- : Integer
Description: The negative value of self.
+ (i: Integer): Integer
Description: The value of the addition of self and i.
- (i: Integer): Integer
Description: The value of the subtraction of i from self.
* (i: Integer): Integer
Description: The value of the multiplication of self and i.
/ (i: Integer): Real
Description: The value of self divided by i.
abs(): Integer
Description: The absolute value of self.
post: if self < 0
then result = - self
else result = self
endif
div(i: Integer): Integer
Description: The number of times that i fits completely within self.
pre: i <> 0 post: if self / i >= 0
then result = (self / i).floor()
else result = -((-self/i).floor())
endif
mod(i: Integer): Integer
Description: The result is self modulo i.
post: result = self - (self.div(i) * i)
max (i: Integer): Integer
Description: The maximum of self and i.
post: if self >= i then result = self
else result = i
endif
min(i: Integer): Integer
Description: The minimum of self and i.
post: if self <= i then result = self
else result = i
endif
String
The standard type String represents strings, which can be ASCII or Unicode. String is itself an instance of the
metatype Primitive (from UML Core).
size(): Integer
Description: The number of characters in self.
concat(s: String): String
Description: The concatenation of self and s.
post: result.size() = self.size() + string.size()
post: result.substring(1, self.size()) = self
post: result.substring (self.size() + 1,
result.size()) = s
substring(lower: Integer, upper: Integer): String
Description: The substring of self starting at character number lower, up to and including character number upper.
Character numbers run from 1 to self.size().
pre: 1 <= lower
pre: lower <= upper
pre: upper <= self.size()
toInteger(): Integer
Description: Converts self to an Integer value.
toReal(): Real
Description: Converts self to a Real value.
Boolean
The standard type Boolean represents the common true/false values. Boolean is itself an instance of the
metatype Primitive (from UML Core).
or (b: Boolean): Boolean
Description: True if either self or b is true.
xor (b: Boolean): Boolean
Description: True if either self or b is true, but not both.
post: (self or b) and not (self = b)
and (b: Boolean): Boolean
Description: True if both self and b are true.
not: Boolean
Description: True if self is false.
post: if self then result = false else result = true endif
implies (b: Boolean): Boolean
Description: True if self is false, or if self is true and b is true.
post: (not self) or (self and b)
Collection-related types
This section defines the collection types and their operations. Each collection type is actually a template type with
one parameter. A concrete collection type is created by substituting a type for the parameter, so Set (Integer) and
Bag (Person) are collection types.
Collection
Collection is the abstract supertype of all collection types in the OCL Standard Library. Each occurrence of an
object in a collection is called an element. If an object occurs twice in a collection, there are two elements. This
section defines the operations of Collections that have identical semantics for all collection subtypes. Some of
these operations may be overridden in the subtypes to provide an additional post condition or a more specialized
return value.
NoteThe definition of several common operations is different for each subtype. These operations are not
mentioned in this section. The semantics of the collection operations is given in the form of a post
condition that uses the IterateExp of the IteratorExp construct. The semantics of those constructs is
defined in section A (Semantics) of the OCL specification. In several cases the post condition refers to
other collection operations, which in turn are defined in terms of the IterateExp or IteratorExp constructs.
size(): Integer
Description: The number of elements in the collection self.
post: result =
self->iterate(elem; acc: Integer = 0 | acc + 1)
includes(object: T): Boolean
Description: True if object is an element of self; false otherwise.
post: result = (self->count(object) > 0)
excludes(object: T): Boolean
Description: True if object is not an element of self; false otherwise.
post: result = (self->count(object) = 0)
court(object: T): Integer
Description: The number of times that object occurs in the collection self.
post: result =
self->iterate(elem; acc: Integer = 0 |
if elem = object then acc + 1 else acc endif)
The following OCL expressions form queries that return true or false:
includesAll(c2: Collection(T)): Boolean
Description: Does self contain all the elements of c2?
post: result = c2->forAll(elem | self->includes(elem))
excludesAll(c2: Collection(T)): Boolean
Description: Does self contain none of the elements of c2?
post: result = c2->forAll(elem | self->excludes(elem))
isEmpty(): Boolean
Description: Is self the empty collection?
post: result = (self->size() = 0)
notEmpty(): Boolean
Description: Is self not the empty collection?
post: result = ( self->size() <> 0)
sum():T
Description: The addition of all elements in self. Elements must be of a type supporting the + operation. The +
operation must take one parameter of type T (the parameter type of the collection) and be both associative
((a+b)+c = a+(b+c)), and commutative (a+b = b+a). Integer and Real fulfill this condition.
post: result =
self->iterate( elem: acc: T = 0 | acc + elem)
Set
The Set is the mathematical set. It contains elements without duplicates. Set is itself an instance of the metatype
SetType.
union(s: Set(T)): Set(T)
Description: The union of self and s.
post: result->forAll(elem |
self->includes(elem) or s->includes(elem))
post: self->forAll(elem | result->includes(elem))
post: s->forAll(elem | result->includes(elem))
union(bag: Bag(T)): Bag(T)
Description: The union of self and bag.
post: result->forAll(elem | result->count(elem) =
self->count(elem) + bag->count(elem))
post: self->forAll(elem | result->includes(elem))
post: bag->forAll(elem | result->includes(elem))
= (s: Set(T)): Boolean
Description: Evaluates to true if self and s contain the same elements.
post: result = (self->forAll(elem | s->includes(elem)) and
s->forAll(elem | self->includes(elem)) )
intersection(s:Set(T)):Set(T)
Description: The intersection of self and s (that is, the set of all elements that are in both self and s).
post: result->forAll(elem |
self->includes(elem) and s->includes(elem))
post: self->forAll(elem |
s->includes(elem) = result->includes(elem))
post: s->forAll(elem |
self->includes(elem) = result->includes(elem))
intersection(bag: Bag(T)):Set(T)
Description: The intersection of self and bag.
post: result = self->intersection( bag->asSet)
- (s: Set(T)): Set(T)
Description: The elements of self that are not in s.
post: result->forAll(elem |
self->includes(elem) and s->excludes(elem))
post: self->forAll(elem |
result->includes(elem) = s->excludes(elem))
including(object: T): Set(T)
Description: The set containing all elements of self plus object.
post: result->forAll(elem |
self->includes(elem) or(elem = object))
post: self->forAll(elem | result->includes(elem))
post: result->includes(object)
excluding(object: T): Set(T)
Description: The set containing all elements of self without object.
post: result->forAll(elem |
self->includes(elem) and (elem <> object))
post: self->forAll(elem |
result->includes(elem) = (object <> elem))
post: result->excludes(object)
symmetricDifference(s:Set(T)):Set(T)
Description: The sets containing all the elements that are in self or s, but not in both.
post: result->forAll(elem |
self->includes(elem) xor s->includes(elem))
post: self->forAll(elem |
result->includes(elem) = s->excludes(elem))
post: s->forAll(elem |
result->includes(elem) = self->excludes(elem))
count(object: T): Integer
Description: The number of occurrences of object in self.
post: result <= 1
flatten():Set(T2)
Description: If the element type is not a collection type, this result is the same self. If the element type is a
collection type, the result is the set containing all the elements of self.
post: result =
if self.type.elementType.oclIsKindOf (CollectionType)
then self->iterate(c; acc: Set() = Set{} |
acc->union(c->asSet()) )
else self
endif
asSet(): Set(T)
Description: A set identical to self. This operation exists for convenience reasons.
post: result = self
asSequence(): Sequence(T)
Description: A Sequence that contains all the elements from self, in undefined order.
post: result->forAll(elem | self->includes(elem))
post: self->forAll(elem | result->count(elem) = 1)
asBag(): Bag(T)
Description: The bag that contains all the elements from self.
post: result->forAll(elem | self->includes(elem))
post: self->forAll(elem | result->count(elem) = 1)
Bag
A bag is a collection with duplicates allowed. That is, one object can be an element of a bag many times. There is
no ordering defined on the elements in a bag. Bag is itself an instance of the metatype BagType.
= (bag: Bag(T)): Boolean
Description: True if self and bag contain the same elements, the same number of times.
post: result =
(self->forAll(elem |
self->count(elem) = bag->count(elem)) and
bag->forAll(elem |
bag->count(elem) = self->count(elem))
)
union(bag: Bag(T)): Bag(T)
Description: The union of self and bag.
post: result->forAll(elem | result->count(elem) =
self->count(elem) + bag->count(elem))
post: self->forAll(elem | result->count(elem) =
self->count(elem) + bag->count(elem))
post: bag->forAll(elem | result->count(elem) =
self->count(elem) + bag->count(elem))
union(set: Set(T)): Bag(T)
Description: The union of self and set.
post: result->forAll(elem | result->count(elem) =
self->count(elem) + set->count(elem))
post: self->forAll(elem | result->count(elem) =
self->count(elem) + set->count(elem))
post: set->forAll(elem | result->count(elem) =
self->count(elem) + set->count(elem))
intersection(bag: Bag(T)): Bag(T)
Description: The intersection of self and bag.
post: result->forAll(elem |
result->count(elem) =
self->count(elem).min(bag->count(elem)) )
post: self->forAll(elem |
result->count(elem) =
self->count(elem) .min(bag->count(elem)) )
post: bag->forAll(elem |
result->count(elem) =
self->count(elem).min(bag->count(elem)) )
intersection(set: Set(T)): Set(T)
Description: The intersection of self and set.
post: result->forAll(elem | result->count(elem) =
self->count(elem).min(set->count(elem)) )
post: self->forAll(elem | result->count(elem) =
self->count(elem).min(set->count(elem)) )
post: set->forAll(elem | result->count(elem) =
self->count(elem).min(set->count(elem)) )
including(object:T):Bag(T)
Description: The bag containing all elements of self plus object.
post: result->forAll(elem |
if elem = object
then result->count(elem) = self->count(elem) + 1
else result->count(elem) = self->count(elem)
endif)
post: self->forAll(elem |
if elem = object
then result->count(elem) = self->count(elem) + 1
else result->count(elem) = self->count(elem)
endif)
excluding(object:T):Bag(T)
Description: The bag containing all elements of self apart from all occurrences of object.
post: result->forAll(elem |
if elem = object then result->count(elem) = 0
else result->count(elem) = self->count(elem)
endif)
post: self->forAll(elem |
if elem = object then result->count(elem) = 0
else result->count(elem) = self->count(elem)
endif)
count(object: T): Integer
Description: The number of occurrences of object in self.
flatten(): Bag(T2)
Description: If the element type is not a collection type, this operation results in the same bag. If the element type is
a collection type, the result is a bag containing all the elements of all the collection elements of self.
post: result =
if self.type.elementType.oclIsKindOf(CollectionType)
then self->iterate(c; acc: Bag() = Bag{} |
acc->union(c->asBag()) )
else self
endif
asBag():Bag(T)
Description: A bag identical to self. This operation exists for convenience reasons.
post: result = self
asSequence(): Sequence(T)
Description: A sequence that contains all the elements from self, in undefined order.
post: result->forAll(elem | self->count(elem) =
result->count(elem))
post: self->forAll(elem | self->count(elem) =
result->count(elem))
asSet():Set(T)
Description: The set containing all the elements from self, with duplicates removed.
post: result->forAll(elem | self->includes(elem))
post: self->forAll(elem | result->includes(elem))
Sequence
A sequence is a collection in which the elements are ordered. An element may be part of a sequence more than
once. Sequence is itself an instance of the metatype SequenceType.
count(object: T): Integer
Description: The number of occurrences of object in self.
= (s: Sequence(T)): Boolean
Description: True if self contains the same elements as s in the same order.
post: result =
Sequence {1..self->size() }->
forAll (index: Integer | self->at(index) = s->at(index))
and
self->size() = s->size()
union (s: Sequence(T)): Sequence(T)
Description: The sequence consisting of all elements in self, followed by all elements in s.
post: result->size() = self->size() + s->size()
post: Sequence {1..self->size()}->
forAll(index: Integer |
self->at(index) = result->at(index))
post: Sequence{1..s->size()}->
forAll(index: Integer |
s->at(index) = result->at(index + self->size() )))
flatten(): Sequence(T2)
Description: If the element type is not a collection type, this operation results in the same self. If the element type is
a collection type, the result is the sequence containing all the elements of all the sequence elements of self. The
order of the elements is partial.
post: result =
if self.type.elementType.oclIsKindOf(CollectionType)
then self->iterate(c; acc: Sequence() = Sequence{} |
acc->union(c->asSequence() ))
else self
endif
append (object: T): Sequence(T)
Description: The sequence of elements, consisting of all elements of self, followed by object.
post: result->size() = self->size() + 1
post: result->at(result->size()) = object
post: Sequence{1..self->size()}->
forAll(index: Integer |
result->at(index) = self->at(index))
prepend(object: T): Sequence(T)
Description: The sequence consisting of object, followed by all elements in self.
post: result->size = self->size() + 1
post: result->at(1) = object
post: Sequence{1..self->size()}->
forAll(index: Integer |
self->at(index) = result->at(index + 1))
insertAt(index: Integer, object: T): Sequence(T)
Description: The sequence consisting of self with object inserted at position index.
post: result->size = self->size() + 1
post: result->at(index) = object
post: Sequence{1..(index - 1)}->
forAll(i: Integer | self->at(i) = result->at(i))
post: Sequence{(index + 1).self->size()}->
forAll(i: Integer | self->at(i) = result->at(i + 1))
subSequence(lower: Integer, upper: Integer):Sequence(T)
Description: The subsequence of self starting at number lower, up to and including element number upper.
pre : 1 <= lower
pre : lower <= upper
pre : upper <= self->size()
post: result->size() = upper - lower + 1
post: Sequence{lower..upper}->
forAll( index |
result->at(index - lower + 1) = self->at(index))
at(i:Integer):T
Description: The i-th element of sequence.
pre: i >= 1 and i <= self->size()
indexOf(obj: T): Integer
Description: The index of object obj in the sequence.
pre: self->includes(obj)
post: self->at(i) = obj
first():T
Description: The first element in self.
post: result = self->at(1)
last():T
Description: The last element in self.
post: result = self->at(self->size())
including(object: T): Sequence(T)
Description: The sequence containing all elements of self plus object added as the last element.
post: result = self . append (object)
excluding(object: T): Sequence(T)
Description: The sequence containing all elements of self apart from all occurrences of object. The order of the
remaining elements is not changed.
post: result->includes(object) = false
post: result->size() =
self->size() - self->count(object)
post: result =
self->iterate(elem; acc: Sequence(T) = Sequence{} |
if elem = object then acc else acc->append(elem) endif)
asBag():Bag(T)
Description: The bag containing all the elements from self, including duplicates.
post: result->forAll(elem |
self->count(elem) = result->count(elem))
post: self->forAll(elem |
self->count(elem) = result->count(elem))
asSequence(): Sequence(T)
Description: The sequence identical to the object itself. This operation exists for convenience reasons.
post: result = self
asSet(): Set(T)
Description: The set containing all the elements from self, with duplicates removed.
post: result->forAll(elem | self->includes(elem))
post: self->forAll(elem | result->includes(elem))
Predefined iterator expressions
This section defines the standard OCL iterator expressions. In the abstract syntax, these are all instances of
IteratorExp. Iterator expressions always have a collection expression as their source, and are shown here per
source collection type. The semantics of each expression are defined through a mapping from the iterator to the
iterate construct, which means it does not need to be defined separately in the semantics sections.
In all the following OCL expressions, the left-hand side of the equals sign is the IteratorExp to be defined, and the
right-hand side of the equals sign is an IterateExp. For example,
- Employee.agents->exist(name='Tom')
Name is the iterator expression, the variable that is being examined in each member. The value Tom' is the iterate
expression, the value that the expression is searching for in each member variable.
The names source, body, and iterator refer to the role names in the abstract syntax as defined in Table 18-2.
Table 18-2: Iterator Expressions
Iterator role Description
Source The source expression of the IteratorExp
Body The body expression of the IteratorExp
Iterator The iterator variable of the IteratorExp
Iterator role Description
Iterator The iterator variable of the IteratorExp
Result The result variable of the IterateExp
NoteWhen new iterator expressions are added to the standard library, their mapping to existing constructs
should be fully defined. If this is done, the semantics of the new iterator expression are defined.
Collection
The following are standard iterator expressions with source of type Collection(T).
Exists
Description: Results in true if body evaluates to true for at least one element in the source collection.
source->exists(iterators | body) =
source->iterate(iterators; result: Boolean = false |
result or body)
forAll
Description: Results in true if the body expression evaluates to true for each element in the source collection;
otherwise, result is false.
source->forAll(iterators | body) =
source->iterate(iterators; result: Boolean = true |
result and body)
isUnique
Description: Results in true if body evaluates to a different value for each element in the source collection;
otherwise, result is false.
source->isUnique(iterators | body) =
source->collect(iterators | body)->forAll (x, y | x <> y)
sortedBy
Description: Results in the Sequence containing all elements of the source collection. The element for which body
has the lowest value comes first, and so on. The type of the body expression must have the < operation defined.
The < operation must return a Boolean value and must be transitive, that is, if a < b and b < c, then a < c.
sortedBy may have at most one iterator variable.
source->sortedBy(iterator | body) =
iterate ( iterator: result: Sequence(T): Sequence {} |
if result->isEmpty()
then result.append(iterator)
Iterator The iterator variable of the IteratorExp
Result The result variable of the IterateExp
NoteWhen new iterator expressions are added to the standard library, their mapping to existing constructs
should be fully defined. If this is done, the semantics of the new iterator expression are defined.
Collection
The following are standard iterator expressions with source of type Collection(T).
Exists
Description: Results in true if body evaluates to true for at least one element in the source collection.
source->exists(iterators | body) =
source->iterate(iterators; result: Boolean = false |
result or body)
forAll
Description: Results in true if the body expression evaluates to true for each element in the source collection;
otherwise, result is false.
source->forAll(iterators | body) =
source->iterate(iterators; result: Boolean = true |
result and body)
isUnique
Description: Results in true if body evaluates to a different value for each element in the source collection;
otherwise, result is false.
source->isUnique(iterators | body) =
source->collect(iterators | body)->forAll (x, y | x <> y)
sortedBy
Description: Results in the Sequence containing all elements of the source collection. The element for which body
has the lowest value comes first, and so on. The type of the body expression must have the < operation defined.
The < operation must return a Boolean value and must be transitive, that is, if a < b and b < c, then a < c.
sortedBy may have at most one iterator variable.
source->sortedBy(iterator | body) =
iterate ( iterator: result: Sequence(T): Sequence {} |
if result->isEmpty()
then result.append(iterator)
else let position: Integer =
result->select(item | item > iterator)->first()
in
result.insertAt(position, iterator)
endif
any
Description: Returns any element in the source collection for which body evaluates to true. If there is more than
one element for which body is true, only one of them is returned. There must be at least one element fulfilling
body, otherwise the result of this IteratorExp is OclUndefined. any may have at most one iterator variable.
source->any(iterator | body) =
source->select(iterator | body)->asSequence()->first()
one
Description: Results in true if there is exactly one element in the source collection for which body is true. one may
have at most one iterator variable.
source->one(iterator | body) =
source->select(iterator | body)->size() = 1
collect
Description: The collection of elements that results from applying body to every member of the source set. The
result is flattened. Notice that this is based on collectNested, which can be of a different type depending on the
type of source. collectNested is defined individually for each subclass of CollectionType.
source->collect(iterators | body) =
source->collectNested (iterators | body)->flatten()
Set
The following are standard iterator expressions with source of type Set (T).
select
Description: The subset of set for which expr is true. select may have at most one iterator variable.
source->select(iterator | body) =
source->iterate(iterator; result: Set(T) =
Set{} |
if body
then result->including (iterator)
else result
endif)
reject
Description: The subset of the source set for which body is false. reject may have at most one iterator variable.
source->reject(iterator | body) =
source->select(iterator | not body)
collectNested
Description: The Bag of elements which results from applying body to every member of the source set.
source->collect(iterators | body) =
source->iterate(iterators; result: Bag(body.type) =
Bag{} | result->including(body))
Bag
Following are the standard iterator expressions with source of type Bag (T).
select
Description: The sub-bag of the source bag for which body is true. select may have at most one iterator variable.
source->select(iterator | body) =
source->iterate(iterator; result: Bag(T) =
Bag{} |
if body
then result->including(iterator)
else result
endif)
reject
Description: The sub-bag of the source bag for which body is false. reject may have at most one iterator
variable.
source->reject (iterator | body) =
source->select(iterator | not body)
collectNested
Description: The Bag of elements that results from applying body to every member of the source bag.
source->collect(iterators | body) =
source->iterate(iterators; result: Bag(body.type) =
Bag{} | result->including(body))
Sequence
The following are standard iterator expressions with source of type Sequence (T).
select(expression: OclExpression): Sequence(T)
Description: The subsequence of the source sequence for which body is true. select may have at most one
iterator variable.
source->select(iterator | body) =
source->iterate(iterator; result: Sequence(T) =
Sequence{} |
if body
then result->including(iterator)
else result
endif)
reject
Description: The subsequence of the source sequence for which body is false. reject may have at most one
iterator variable.
source->reject(iterator | body) =
source->select(iterator | not body)
collectNested
Description: The Sequence of elements that results from applying body to every member of the source sequence.
source->collect(iterators | body) =
source->iterate(iterators; result; Sequence(body.type) =
Sequence{} | result->append(body))
<Day Day Up>
<Day Day Up>
Summary
OCL defines an abstract syntax, a metamodel, for languages used to specify constraints.
OCL defines a concrete syntax that implements the abstract syntax. This concrete syntax is only one of many
that may be created using the OCL metamodel.
OCL expressions are static and instantaneous. They cannot alter the state of the system.
OCL expressions require placement, a context classifier, and a self-instance.
OCL defines expressions and types. The set of valid types and valid expressions on those types are defined in
the OCL Standard Library.
An invariant is a condition that must hold true for the life of the system.
A precondition defines the state of the system when the context operation is invoked.
A post condition defines the state of the system at the completion of the context operation.
The let expression enables you to create variables that are scoped by the expression in which they are
defined.
The def (definition) expression enables you to create variables that are scoped by the context classifier in
which they are defined.
The OCL Standard Library defines three types of Collections: Set, Bag, and Sequence. Collection itself is an
abstract superclass.
OclMessage is a container for an operation. It allows access to the features of the operation, such as
result(), hasReturned, isSignalSent, and isOperationCall.
OCL supports access to any type defined in a UML model via the OCL metaclass enumerations OclType,
OclState, and OclModelElement.
<Day Day Up>
<Day Day Up>
Chapter 19: Action Semantics
Overview
For most people, the primary items of interest in the UML are the diagrams. Most of the features of UML that
modelers use are there to enable communication with other people-customers, managers, analysts, designers,
developers, and so on. For them the important, visible part of UML is the portion that describes the notation. The
semantics section for each diagram type ensures that everyone interprets the diagram in the same way.
The action semantics specification is different. It describes something for which UML provides no notation-an
action specification. An action specification describes the behavior associated with some part of a UML model, but
the notation used to describe the behavior can be any language that conforms to the action semantics. This means
that the action semantics section of UML is not going to be of direct interest in the way that people might take
notice of a new UML diagram type. In this case, there is nothing concrete to look at.
However, for anyone who uses or intends to use a language designed for writing precise behavior specifications (a
specification language), UML now describes the actions that can be performed on a UML model and the effect that
they have. If an action language conforms to the UML semantics, then behavior descriptions made in it are
capable, in principle, of being shared with any other UML tool. Instead of being a way (as UML diagrams are) of
enabling meaningful communication between people, the action semantics specification is intended to help enable
communication between tools.
Early versions of the UML did not prescribe a way of precisely defining behavior. An action semantics specification
has recently been incorporated into the semantics section of UML. This specification defines the semantics for a
set of actions that can be used to describe behavior within a UML model.
NoteThe action semantics specification discussed in this chapter is "Actions", Part 5 of the UML Semantics
section of UML 1.5. At the time of writing this was the latest formally adopted version of the UML
specification, available at http://www.omg.org/technology/documents/formal/uml.htm.
No standard language for describing behavior is currently proposed. Modelers may use any language that is
capable of implementing the action semantics. This approach allows models to include precise, platform-
independent descriptions of behavior while retaining the flexibility to use the specification language of choice. It
offers the potential for behavioral descriptions to be moved without loss of meaning between UML-compliant
modeling environments.
The increased precision with which behavior can be described also enhances the ability of UML models to support
features such as model simulation, improved code generation, and automatic test generation.
<Day Day Up>
<Day Day Up>
The Need for Action Semantics
In terms of sheer volume, the Actions section of UML 1.5 is a major addition to the UML specification. It accounts
for more than 40 percent of the entire semantics section of the UML standard. Ivar Jacobson, who together with
Grady Booch and Jim Rumbaugh originally developed the UML, has described action semantics as "the missing
piece to make UML an executable language". What was missing from UML before action semantics were
incorporated, and why did they take so long to appear?
The late arrival of action specification standards into UML is due to a combination of technical and historical
factors. The initiative that eventually produced UML started as an attempt to unite two OO methodologies, the
"Booch" method developed by Grady Booch and the Object Modeling Technique (OMT) developed by Jim
Rumbaugh and co-workers. The result was not a unified method but a unified notation that allowed models to be
created using any one of a number of different methodologies.
Despite the fact that UML is deliberately non-method-specific, it inevitably inherited a number of features that are
consistent with the general approach used by the main contributing methods. One such feature is the use of
common diagram types for both analysis and design. This favors the elaborative approach of adding detail to a
modified analysis model in order to produce a design model. It reflects the principle that software objects are
abstractions of concepts in the real world. It is also convenient for iterative development because it avoids the need
for repeated transformations between diagram types for different phases.
Earlier versions of UML allowed the modeler to use freeform textual descriptions to describe the intended behavior
of some parts of the model, such as methods. UML treats these descriptions as uninterpreted strings. The onus is
therefore on the modeler to ensure that the descriptions are consistent with the rest of the model, and that the
behavior so described actually takes place as specified when the system is implemented.
Uninterpreted strings are adequate for many modeling purposes, but for some methodologists they fall short of
exploiting the full value of the effort invested in creating a model. The lack of rigor limits the extent to which the
model can be validated by automated execution techniques or by generating code. This is a major shortcoming for
advocates of the "translational" approach exemplified by the "Shlaer-Mellor" technique of Sally Shlaer and
Stephen Mellor.
Shlaer-Mellor views design as a translation process. Shlaer-Mellor builds an implementation-free formal
model of the application, and an application-free formal model of the system architecture. Both models can
be formally verified, and the processes of building these models have formal entry and exit criteria. The
application model is then systematically translated according to the rules of the architecture. This translation
process can be automated. (Stephen J. Mellor: A Comparison of the Booch Method and Shlaer-Mellor
OOA/RD, 1993, http://www.projtech.com.)
This highlights a fundamental distinction between the elaborative and translational approaches, summed up from
the translational side of the debate by Mellor's conclusion that "Booch uses notation in the sense of an artist's
rendition, whereas Shlaer-Mellor uses notation in the sense of a blueprint."
From this point of view, a model must be constructed with sufficient precision to enable it to be translated into other
artifacts (and ultimately to code) by applying appropriate rules. Action semantics standardization makes this
possible. In this sense, the adoption of action semantics marks the incorporation into UML of a key feature of
support for the translational approach.
A number of vendors had already created UML tools incorporating specialized action languages designed to
describe model behavior more rigorously. Statements in the chosen action language are used to describe behavior
precisely in model domain terms. These can be either executed directly, or translated into an appropriate target
language to validate or implement the model. However, because tools used different languages, each of which
integrated in a different way with the model, there was no guarantee that action specifications in a UML model
would be capable of translation if the model were to be moved between tools.
The arguments for action specification standards were made in a paper entitled "Software-Platform-Independent,
Precise Action Specifications for UML" by Mellor, Tockey, Arthaud and LeBlanc, (Project Technology Inc., 1998).
Mellor and co-workers called for a standardizable software-platform-independent language for precise action
specifications. Many of the recommendations in this paper were incorporated into the OMG's Action Semantics for
the UML-Request For Proposal (OMG, 1998), which outlined the main reasons for defining standard semantics for
action specifications (see the "Why Software-Platform-Independent Action Specifications?" sidebar).
Why Software-Platform-Independent Action Specifications?
Model precision and level of implementation detail are two separate things. Software-platform-independent
action specifications, in conjunction with the UML, can completely specify a computing problem without
actually programming it. Such action specifications
Can be used to build complete and precise models that specify problems at a higher level of abstraction
than a programming language or a graphical programming system.
Can support formal proofs of correctness of a problem specification.
Make possible high-fidelity model-based simulation and verification.
Enable reuse of domain models, because each domain is completely specified, though not in a form
embedded in code.
Provide a stronger basis for model design and eventual coding.
Support code generation to multiple software platforms.
However, the RFP requested submissions not for a standard action language but a set of standard semantics for
action specifications that could be supported by many languages. The response to this invitation was a submission
by a group of tool vendors who wanted to ensure portability of models containing action specifications in any
compliant action language between tools.
A semantic model for action specifications makes it possible to define behavior precisely enough to define
mappings into a variety of programming languages, validation tools, and simulation tools. Importantly, it improves
the capacity of UML models to be used to generate code. These capabilities are consistent with the OMG's long-
term strategy to separate specification from implementation as expressed in the Model Driven Architecture (MDA)
(http://www/omg.org/mda).
The resulting action semantics specification in UML 1.5 does not define a UML action language or notation. By
separating the semantics from the notation, the specification leaves open the possibility of using any notation that
supports the UML action semantics. This allows modelers to use any notation they choose, including graphical
techniques. The way is therefore left open for new action languages and notations to be introduced as the need
arises.
Of course, the vast majority of modelers will not want to invent new action languages but to use an existing
language where a suitable one exists. Some action languages which have been applied to UML models are listed
in UML 1.5 Appendix B. Those described in the Appendix are the Action Specification Language, the BridgePoint
Action Language, the Kabira Action Semantics, and the action language subset of SDL. It is pointed out in the
Appendix that no single language or group of languages described provides constructs that cover all the features
of the UML action semantics. This might be taken to suggest an opening for a language that does implement all
the features. However, it is more likely that users will choose a language that fits their specific requirements rather
than necessarily adopt one purely on the basis of its comprehensive support for UML semantics. As in the case of
programming languages, the choice is more likely to be based on the modeling team's previous familiarity, the
language's understandability, and on its applicability to the particular modeling problem.
Action specifications in UML
The Action Semantics specification is intended to provide modelers with a way of precisely specifying behavior
within a UML model. Behavior in UML is described using actions.
UML defines an action as
The specification of an executable statement that forms an abstraction of a computational procedure. An
action typically results in a change in the state of the system, and can be realized by sending a message to
an object or modifying a link or a value of an attribute. (UML 1.5 Glossary)
Action specifications can describe the body of a method, the output of a transition between states in a state or
activity diagram, or activities associated with system states. In earlier versions of UML, textual action specifications
were typically free-form descriptions that UML treated as uninterpreted strings. Individual modelers and toolset
vendors were free to interpret the content of the description in any way they chose. Some modelers constructed
more precise action specifications using either common programming languages or specialized action languages.
Each tool used to create specifications reflected a particular vendor's assumptions about the relationships between
the language constructs and the UML model elements they referenced. In the absence of any standards, it was
difficult to ensure that a model created in one tool could be exchanged with another tool while continuing to display
consistent behavior.
The UML already contains its own language intended to remedy the ambiguity inherent in natural language: the
Object Constraint Language (OCL). It is a formal language designed to enable the definition of constraints on a
model. A typical use of OCL is to describe pre- and postconditions on operations. However, OCL is a declarative
language not intended for procedural descriptions. It is not possible to write procedural logic or flow control in OCL.
An OCL expression is also deliberately intended to be free of side effects, so it cannot change anything in the
model. Specifying behavior using pre- and post-conditions guarantees that no implementation assumptions
become embedded in the description. However, the lack of a procedural description capability makes it difficult to
use OCL to describe behavior in an intuitive way.
NoteThere is a current effort to integrate static and dynamic features in the OCL, although no formal
submission has been made at this time. See Chapter 18 for more depth on the Object Constraint
Language.
One option is to define behavior procedurally using an existing popular programming language such as Java, C++,
or Visual Basic. However, the use of a programming language for this purpose has some disadvantages:
Modern languages contain richer constructs than are necessary for describing actions.
Languages contain their own idioms for implementing model constructs.
Expressing actions using a programming language can excessively constrain the modeler. Programming
language statements can suggest to the implementer the use of a particular construct or algorithm. For
example, an association in UML simply indicates a connection between instances. The connection might be
implemented in a variety of ways. Java, on the other hand, can represent an association only by object
references in the associated classes.
Writing statements in a programming language tends to force a sequential model on the specification. This
can obscure the possibility that the same result might be achieved more efficiently by an alternative sequence,
or by concurrent execution of some statements. The resulting specification may needlessly constrain the order
of execution, even though alternative sequences or concurrent execution may be acceptable. It is a principle of
the UML Action Semantics specification that concurrent execution of actions is assumed unless explicitly
sequenced, or implicitly sequenced by a need to share data with other actions.
Code fragments may be intentionally placed within a model, with a view to executing the model, or generating
code that incorporates the code statements directly. This has the effect of embedding implementation detail
within the model, making it hard to distinguish essential features from implementation mechanisms.
Conventional programming languages do not "understand" UML. An object-oriented language like Java
implements common OO concepts such as class and attribute, but does not recognize the significance of an
attribute on a Class diagram. The programming language statements take no direct account of the model they
are intended to describe. Instead, any relevant model contents must be explicitly declared in language-specific
terms. This can result in duplication and the usual problems of redundancy in a specification.
Mellor's view suggests that a purpose-designed action language should be capable of recognizing the context of
procedures within a UML model. An action language specification of a class method would thus automatically
recognize attributes of the class. There are a number of languages designed for writing specifications as opposed
to writing code (some examples are listed in the Action Language Examples appendix of UML 1.5). Some of these
have already been integrated into UML modeling tools. So why did the OMG not simply aim to incorporate an
existing or purpose-built language into the UML?
One of the problems of trying to standardize on a procedural language within a general-purpose standard like
UML is that UML is used in a very wide range of problem domains. This calls into question the advisability of
prescribing a single language. The argument against mandating the use of a single language, even within a
relatively restricted domain, has been summarized as follows:
Instead of promoting the one language that will solve all design problems (which does not and will not ever
exist) this book takes the view that different problems demand different languages, and a designer who
knows the spectrum of available languages has the advantage over one who is trapped using the wrong
language. (Stephen A. Edwards: Languages for Digital Embedded Systems. Kluwer Academic Publishers,
2000.)
If a single language is restrictive for embedded systems designers, it is going to be severely limiting for UML users
describing the broader spectrum of applications from business systems to real-time software. The OMG chose
instead to standardize not a single language, but the semantics that any compliant language must support.
In fact the UML Action Semantics RFP recognized that a single set of action semantics might not be flexible
enough to meet the needs of all UML users. It therefore allowed for the provision of several execution profiles to
address different user needs. A profile is an extension to the standard UML that enables the construction of
specialized models for specific purposes. For example, UML 1.5 provides an example profile for Business
Modeling. The Action Semantics specification allows for specific execution profiles for some of the action
packages. For example, request handling behavior may be defined on different platforms by means of a profile
defining the given system environment.
The term "executable UML" is often used to describe the application of a UML profile in the context of a method
that aims to automatically generate an executable application from an abstract UML model. An example of such a
profile is described in "Executable UML-A Foundation for Model Driven Architecture" by Stephen Mellor and Marc
Balcer (Addison-Wesley, 2002). Action semantics are regarded as a necessary addition to UML in order to support
this technique. However, it should be noted that the primary reason for having action semantics is to provide a
standard for the exchange of action specifications between tools, rather than to enable execution of UML models.
Executable models can be constructed using existing UML artifacts such as statecharts.
Advantages of precise action semantics
Precise action semantics enable much more powerful modeling of behavior than unstructured descriptions. Some
of the difficulties associated with unstructured descriptions can be summarized as:
In UML actions are described using non-interpreted text strings. This leads to possible interpretation errors
when exchanging specifications, the impossibility to automatically check the obtained models, the
impossibility to test the models against some specified constraints, the impossibility to use tools for simulating
behaviour, and the limited usage of actions at code generation time, when actions described textually must
be either skipped, or copied blindly. (Ileana Stan-Ober, "Harmonisation of Modeling Languages with Object-
Oriented Extensions and Executable Semantics." Doctoral Thesis, Institut National Polytechnique De
Toulouse, 2001, p. 83.)
Mellor and co-workers' original paper calling for the introduction of action semantics explores some of the potential
benefits of precise behavioral specifications. These are described in terms of how the specification language SDL
(Specification and Description Language) can be used to deliver the benefits, but some benefits can be also
achieved using other languages.
Code generation is possible using earlier features of UML. Class and attribute declarations, together with particular
association implementations, can be generated from static model diagrams. Code can also be generated from
state machines. However, a general mechanism for defining behavior in other parts of the model, such as class
methods and activity descriptions, provides the opportunity for a more systematic treatment. Such a mechanism
offers the possibility of using proven specification languages such as SDL to define entire subsystems in the
context of a UML model.
Precise specifications also make possible simulation of the model without going to the level of detail required for
implementation. This technique permits validation of the model at an early stage. SDL, for example, enables
simulation without vendor-specific extensions. Tools exist that can use SDL specifications to build extensive
verification facilities. These include verifying that a given scenario is (or is not) possible, and generating test
sequences that violate some required property.
There are strong arguments for automatic model checking as part of a strategy of integrating system validation
early in the design process. As systems become more complex, reasoning about system behavior becomes more
difficult. Systematic techniques and tools that support the validation process become increasingly valuable,
because, more time and effort is often required on validation than on construction.
While vendors might individually produce their own extensions to deliver additional functionality, the standards-
based approach is more attractive to users. Defining specifications in a UML-standard rather than in a vendor-
specific way allows for portability of model-based specifications between different products. Standard semantics
mean that in principle behavior specifications can be moved between products without distortion.
<Day Day Up>
<Day Day Up>
Uses of Action Semantics
Much of the work on action semantics concentrates on their application in developing unambiguous specifications
of requirements in a detailed but platform-independent way. However, the prospect of the adoption of standard
semantics has led to proposals for other applications.
Code generation for specific platforms
Some advocates of the model-driven approach favor extending the scope of action semantics. Why should we
stop at platform-independent action specifications? Why not create a set of action specifications for specific
platforms to enable direct code generation? The principle of using a precise model-based specification to act as a
basis for generation of code for an entire application has been a common theme in system development circles for
many years. Code generation from diagram-based representations of one sort or another is probably the single
most common topic for computer science theses. Advocates of this approach argue that a move toward
diagrammatic specification is a logical consequence of the trend toward higher-level abstractions by programming
tools. Starting with machine code and progressing through assembly language and high-level languages, each
step has enabled the programmer to use abstractions that are closer to those of the problem domain. Ultimately,
models should be capable of being compiled to generate executable code in the same way that high-level
language programs are currently compiled to generate executable code.
The UML standardization body, the OMG, has recently moved its prime focus away from middleware
standardization to concentrating on model-based development. The OMG is currently promoting an initiative based
on UML together with its other standards. This is the concept of Model-Driven Architecture (MDA). MDA is based
on the separation of the fundamental logic behind a specification from the specifics of the implementation.
An MDA-based application is intended to be built by first creating a platform-independent application model. This is
expressed via UML in terms of an appropriate core model. A different core model will be used to represent each
distinct application environment. The core model will be independent of any middleware platform. The application
model will then be converted into one targeted to a specific platform. The conversion itself may be carried out by
specialists assisted by tools that can be used to automate some aspects of the work using standard mappings.
The MDA vision depends on the application model being an unequivocal statement of functional behavior that can
be translated into a platform-specific form. A standard set of action semantics is a prerequisite for a tool to be able
to faithfully render the mappings in the target language.
On a cautionary note, the ability of the current UML to unambiguously represent even static, structural aspects of a
model has been questioned. If the significance of the static model is capable of multiple interpretations, it is
impossible to write unambiguous action specifications based on it. Until these issues are resolved, it will not be
possible to realize all the benefits of standardizing action semantics.
NoteNot everyone agrees that UML is sufficiently precise to support the goals of MDA. For an examination of
some of the issues surrounding the static modeling features of UML, see, for example Antoine Beugnard,
"Is MDA Achievable Without a Proper Definition of Late Binding?" (paper presented at WiSME,
Workshop in Software Model Engineering, Dresden, Germany, October 2002.)
Designing new action languages.
The UML Appendix B: Action Language Examples describes mappings from a set of specification fragments in
existing action languages onto the UML Action Semantics models. However, it points out that these languages do
not, individually or as a group, support all the actions in UML.
Mellor and co-workers' original paper setting out the case for action specification standards within UML called for a
standard action language. While this is not, at the moment, a feature of UML, defined Action Semantics should
help designers of languages intended to integrate with UML models. Conformance with the semantics can be
ensured while retaining the flexibility of alternative modes of expression. The expression mechanism may be
textual and/or graphical, depending on the needs of the user community.
Model-level transformations
Most applications of action semantics relate to the specification of behavior within model instances. However, the
UML metamodel is itself a UML model and this opens up some interesting possibilities. Attempts have been made
to define transformations not only for model instances but also for models themselves. In their paper, Suny et al.
describe several applications of model-level transformations (Gerson Suny, Franois Pennaneac'h, Wai-Ming Ho,
Alain Le Guennec, and Jean-Marc Jzquel, Using UML Action Semantics for Executable Modeling and Beyond,
IRISA, France. 2001). For example, refactoring of source code is a technique to make the source code of an
application more readable and reusable. The authors describe the refactoring of a model such that the behavior of
the original model is preserved in the transformed model. Other applications explored are pattern application and
aspect weaving.
<Day Day Up>
<Day Day Up>
The Action Package
The UML Action Semantics specification defines a syntax and semantics for executable actions and procedures.
The UML does not, however, describe a corresponding notation or programming language.
The action semantics specification defines and categorizes actions. Each action definition contains descriptions of
Attributes
Associations
Inputs
Outputs
Well-formedness rules
Additional operations that may be performed
The implementation of the actions may be specified in a language capable of executing the desired behavior. A
language chosen for this purpose is sometimes referred to as a "surface" language. The surface language
constructs are mapped onto actions defined by the UML action semantics. The semantics define the effect of the
actions in terms of the UML model.
Concepts
In UML Action Semantics, several common concepts apply to all kinds of actions. Actions are described using a
terminology that includes input and output pins, data flows, control flows, procedures, and primitive actions. These
are the classes of the action Foundation package.
A behavior specification is based on actions. An action performs a transformation on a set of inputs to produce a
set of outputs. An output from one action may act as input to another action.
Inputs and outputs of an action are specified as its pins. The use of the term pin is analogous to the familiar use of
"input" and "output" pins on hardware devices. The pins of different actions may be linked by means of data flows
to enable one action to provide input to another action. A data flow connects from the output pin of one action to
the input pin of another.
The specification of a pin defines the type and multiplicity of values that may be held by the pin. Data flows may
only be exchanged between pins that have compatible types and multiplicities. Consequently, not all output and
input pins may be linked.
Note that the pins need not be identical, so long as the input pin conforms to the type of the source output pin. In
order to be conformant,
The type of the output pin must either be the same as, or a descendant of, the type of the input pin.
All cardinalities allowed by the multiplicity of the output pin must be allowed by the multiplicity of the input pin.
Figure 19-1 illustrates a data flow between two actions. The multiplicities indicated in square brackets at either end
of the data flow line have their usual UML meanings: [1] indicates "exactly one" and [1..*] indicates "one or more". If
Personal Account is a subtype of Account it is valid to send a single Personal Account instance to the input pin of
Action 2 because Action 2 can accept one or more Account instances as input. The notation used is the informal
notation described in UML 1.5 (Appendix B.6.2-Illustrative Notation), which is summarized in the section "A
Notation for Action Specifications" later in this chapter.
Figure 19-1: Data flow between pins with compatible types and multiplicities.
A data flow from an output pin may be directed to one or more conforming input pins, if, for example, the flow is
used by several actions which can execute independently. An input pin, on the other hand, may only have one
incoming data flow.
Data flows imply sequence. That is, a successor action cannot be carried out until the data it needs is available.
Control of a given sequence of actions may be necessary even if the actions do not exchange data directly. In this
case, the order of action execu-tion may be specified explicitly using a control flow. Where actions are linked by
control flows, a successor action takes place only when the predecessor action is complete. In Figure 19-2, control
passes to Action 2 if and when Action 1 is completed.
Figure 19-2: Control flow indicating action sequence.
The lowest level of action - one that contains no nested actions - is called a primitive action. Primitive actions are
intended to represent simple separate low-level behavior. A primitive action either performs a computation or
accesses object memory, but not both.
Actions may be nested within each other. The highest level of a nested group of actions is called a procedure. A
procedure is a group of actions that may be treated as a unit to describe the behavior of some other part of the
model, for example a method or an action triggered by a state machine transition.
Although a procedure is a high-level grouping of actions, the terms procedure and action are considered quite
distinct. The UML 1.5 Glossary provides definitions of both terms. A procedure consists of a coordinated set of
actions that models a computation, while an action is the specification of an executable statement that may be part
of a computational procedure. Procedures are considered to be sequenced by messages, while the sequencing of
actions is determined by data and control flows. Procedures extract data from messages and assemble data into
messages for output. Actions receive data on input pins and produce data on output pins.
Figure 19-3 shows a class called Order with an operation CalculateTax. The operation takes a parameter
Percentage and returns a value of type money. The procedure is depicted in the part of the figure inside the
ellipse - in practice it would be more conveniently shown on a separate diagram hyperlinked to the operation string.
Figure 19-3: Implementation of an operation described using a procedure specification.
Argument and result pins are shown on the procedure boundary, together with their types. They may also be
labeled to improve readability. Labels are indicated by italics. In this case the argument corresponding to the
parameter Percentage has been labeled tax rate. Note that two arguments are shown, even though the
operation takes only one parameter (Percentage). This is because the object itself (Order) is regarded as an
argument, so that the object's state information is available to the procedure. The type of the result (money) is
shown and assigned a label (amount) for clarity.
The body of the procedure (omitted in the figure) is normally expressed in terms of exchanges between actions
enclosed within the procedure boundary.
Two different execution models are provided for actions and procedures.
There are four stages in the lifecycle of an action execution: waiting, ready, executing, and complete. An action
execution may be created any time after its containing procedure has started executing. Preceding actions provide
values on the input pins of the action execution. The action execution is initially in a waiting state. When all
prerequisite actions have been executed, it enters the ready state. An action may begin executing at any time after
entering the ready state. This allows the modeler additional flexibility. For example, a time delay may be specified
after which execution begins. However, the first action in a sequence nested within a process starts executing when
the process itself starts executing. After execution is finished, the action execution is complete. On completion, all
output and input pins have values.
A procedure execution lifecycle also has four stages: ready, executing, returning, and complete. A procedure
execution starts in the ready state. Input parameters take the form of values on the argument pins, often as a result
of a messaging action that initiates the procedure. Once in the ready state, (although not necessarily immediately)
a procedure may begin executing. This causes the execution of the nested action. After completion of its nested
action, the procedure enters the returning state - at this point, all result pins have values. The procedure execution
may package the results for a reply if it is triggered by a messaging action. The procedure execution becomes
complete after it has finished returning.
Action package
The action semantics section of UML defines a metamodel for actions. The meta-model defines the types of
actions that can be used by modelers. The action types are grouped into packages.
UML defines six categories of actions, which are considered to be subpackages of the Action Foundation package:
Composite actions
Read and write actions
Computation actions
Collection actions
Messaging actions
Jump actions
Action Semantics defines simple primitive constructs to ensure flexibility. Primitive actions either carry out a
computation, or access object memory, but do not do both. Primitive actions may be grouped together into
composite actions. The composite action may also include control structures. A primitive delete action operates
only on a single instance. If a set of instances is to be deleted, a composite action containing multiple delete action
primitives can be constructed. An implementation of this behavior in a surface language could define a more
complex "delete set" operation.
The Action Semantics specification avoids semantics that force action languages to specify sequence
unnecessarily. This is a problem with using programming languages for specification. Action Semantics assumes
that all actions execute concurrently unless explicitly sequenced. Sequence may be dictated by a data flow or
control flow between actions.
Composite actions
Actions may be grouped together for execution as a unit. The grouping construct is a composite action. Composite
actions fall into one of three types: Group Action, Conditional Action, and Loop Action. These enable, respectively,
composition, selection, and iteration of actions within a procedure. The Composite Actions package contains these
actions together with the supporting classes Clause and Variable.
A Group action is the simplest form of composite action. It provides a way of gathering subactions into a
higher-level unit, for example to enable the group to be executed conditionally or simply to enable a procedure
to be partitioned into meaningful sets of actions. The subactions may execute concurrently, sequentially, or in
some combination of the two.
A conditional action provides a way of selectively executing one or more contained actions. It contains one or
more clauses. A clause consists of two actions, a "test" and a "body". The body action of a clause is executed
only if its test action evaluates to true.
An if-then-else statement maps onto a conditional action with two clauses, corresponding to the "then" and
"else" parts of the statement.
A loop action provides a mechanism for iteration. It contains a single clause. Both the test and the body part
are executed repeatedly while the test evaluates to true.
Composite actions can receive control flows. If a composite action is sequenced by a control flow, then its
subactions may execute as long as all their other prerequisites (such as receipt of any necessary data) are fulfilled.
Data flows are not accepted by the composite action itself but may be directed to its subactions.
The following figures illustrate examples of how a composite action (in this case a group action) can handle control
and data flows. In general, composite actions may have input and output pins. Group actions, however, do not
have their own pins. In Figure 19-4 a control flow is passed to the group action as a whole. In Figure 19-5 a data
flow is sent directly to one of the actions within the group.
Figure 19-4: A group action may receive a control flow. The control flow is implicitly passed to each subaction.
Figure 19-5: A group action is transparent to data flows. A data flow may be received by a subaction.
A variable allows the sharing of data between actions. A local variable allows sharing of data between actions
in a group, but it is not available to actions outside the group. If actions share data using a variable rather than
a data flow, they must be sequenced explicitly using a control flow.
Read and Write actions
Read actions obtain values. Write actions can modify values, create or destroy objects, and create or destroy links
between objects. In order to maintain maximum flexibility, the actions are designed to have minimum impact. A
read action, therefore, does not modify the value it reads. Similarly, creating an object does not cause constructors
to be executed, although these actions may be grouped together if desired.
Read and Write actions include
Object actions
Attribute actions
Association actions
Variable actions
Object actions enable objects to be created, destroyed and reclassified. Attribute actions enable the values of
attributes to be read or changed. Association actions enable direct object links to be identified, navigated,
examined, created, and modified. Variables within a procedure or group of which the action is part may be read
and modified by variable actions.
There are also additional miscellaneous read and write actions. One example is an action that determines the set
of all instances of a given classifier that exist at the time the action is performed.
Computation actions
A computation action performs a transformation that operates on a set of input values to produce a set of output
values. Only the values of the inputs influence the transformation. No other values (for example, stored data
values) are taken into account.
Primitive computational functions such as arithmetical operations are not defined in the UML. Action languages
may define their own functions for specific purposes. If required, a UML profile-a set of model elements which have
been customized using the UML extension mechanisms-can be created to describe domain-specific functions.
Examples of computation actions are
Computing a primitive predefined mathematical function (ApplyFunctionAction).
Performing an action defined outside UML (CodeAction).
Producing a literal value as output (LiteralValueAction).
Creating an object with initialized attribute values (MarshalAction).
Checking two values to see if they have the same identity (TestIdentityAction).
Finding the state information about an object of known type (UnmarshalAction).
Collection actions
A collection action applies some other action (a subaction) to a collection of elements. A collection consists of a
number of elements that have the same type. The size of the collection is the number of elements in the
collection. If a collection action takes more than one collection as input, they must all have the same size, because
the number of repetitions is dictated by the size.
Collection actions fall into one of four subclasses:
A filter action performs a subaction that applies some criterion to elements of a collection. Elements that
satisfy the criterion are included in the new output collection. The subaction may be applied to all the elements
concurrently.
An iterate action performs a subaction repeatedly on collection elements. It is a special case of a loop in which
the number of iterations is determined by the number of elements in the collection. The subaction is not
applied concurrently because the iteration may have to terminate before the subaction can be applied to every
element. It is therefore applied to each element in sequence.
A map action performs a subaction on a slice. A slice contains one element from the same position of each
collection. The subactions performed on each slice are performed concurrently. Each collection must be
ordered to allow matching to take place correctly.
Figure 19-6 shows a slice through two collections. Collection 1 contains a set of names of countries and Collection
2 a set of capital city names. The collections are ordered so that a slice contains a country and its capital city.
Figure 19-6: A slice containing elements from two collections.
A reduce action applies a subaction repeatedly to adjacent pairs of slices. The subaction performs some
operation on adjacent slices and creates a single working slice, which is then paired with the next slice for the
next repetition of the subaction. A constraint on reduce actions is that only associative operations are
permitted, so that the order in which the pairs of slices are evaluated does not affect the result. An example of
an associative operation is multiplication, since (6 (3) (2 gives the same result as 6 ((3 (2), that is, 36. Division
on the other hand is not associative, because (6 (3) (2 = 1 but 6 ((3 (2) = 4.
A reduce action can be used to perform addition of the elements in a collection by adding the first two
elements to create a working element containing the sum of the first two. This working element can then be
paired with the next element. When there is only one element left, it contains the sum of all the starting
elements. Depending on the operation being applied, the order of the elements in each pair may be
significant.
Messaging actions
Messaging actions perform the exchange of messages between objects. Messaging actions include handling of
requests and replies, effect resolution, operation lookup, and transition triggering.
A request is an invocation message sent from one object to another. In the case of an asynchronous invocation,
the sending object continues execution without waiting for a reply. In the case of synchronous invocation, the
sending object suspends execution until the activity invoked by the request sends a reply message back to the
sender. The messaging model describes a number of ways of matching behavior to requests. The unit of behavior
that can be invoked by a request is a procedure.
The mapping of a request type to a procedure is called operation lookup. Action semantics provides for different
kinds of operation lookups to allow for the variety of techniques employed in different languages.
The following are examples of messaging actions:
Creating a request that is transmitted to a target object
Creating a request that is transmitted to all potential target objects in the system
Assembling an operation call request
Sending a request object to a target object using an explicit argument list
Jump actions
Jump actions enable normal flow of control to be abandoned and an alternative flow of control taken. The jump
action is exemplified in programming language terms by the go to construct, as well as the break, continue, and
exception constructs.
The Jump classes are
Action
HandlerAction
JumpAction
JumpHandler
Jump handling classes extend the definitions of some other action classes to define the behavior of the action
when the jump occurs. An action may have handlers associated with it, to handle any jumps that take place during
execution of the action. Executing a JumpAction causes a specified jump to occur. A JumpAction execution cannot
itself complete normally. Instead, it terminates the current group of actions and escapes to a JumpHandler. A jump
handler is not an action in its own right, but relates an action and a jump type to a HandlerAction. The
HandlerAction has a body that is triggered by the jump handler. The body is often a group action.
<Day Day Up>
<Day Day Up>
A Notation for Action Specifications
UML does not define a notation or language for action specifications. However, in order to illustrate the application
of action semantics concepts, an informal notation is described in the Action Language Examples Appendix (UML
1.5, Appendix B).
The notation is considered to be based on an Object diagram with some amendments. However, there are also
strong similarities with data flow diagrams. An action is modeled using object notation - a rectangle with a name in
the format instance name : action type. Pins are shown as squares drawn on the border of action rectangles. An
input pin is shown by an empty square, and an output pin is a filled square. An arrow drawn from an output pin to
an input pin represents a data flow relationship.
The following figure shows a fragment containing two actions from some action sequence. The first action (square)
takes as input an integer from the pin labeled n and causes the input to be squared. The result, an integer labeled
n
2
is passed to the input pin of the second action. The second action ("
*
2") multiplies the input by two and places
the value on an output pin labeled 2n
2
.
The type of the output pin is indicated by a label. Type labels may be omitted from input pins at the other end of
the flow line. The names in italics shown adjacent to pins (such as n in Figure 19-7) are labels to assist in
interpreting the specification.
Figure 19-7: Actions with pins showing types and descriptive labels.
A simple name in the action rectangle indicates an ApplyFunctionAction, which computes a primitive predefined
mathematical function. Examples are XOR, square root, and addition. A value inside a rectangle indicates a
LiteralValueAction. Other actions are labeled with the kind of action such as LoopAction, GroupAction, Clause, and
so forth. The label may be preceded with a name and colon to identify individual instances such as
body:GroupAction. Actions may be nested to indicate ownership of the containing action. Figure 19-8 shows
examples of, left to right, an ApplyFunctionAction (square root), a LiteralValueAction, (1) and a nested action
MapAction.
Figure 19-8: ApplyFunctionAction, LiteralValueAction, and Nested Action examples.
Procedures have argument and result pins placed on their border in the same way that input and output pins
appear on actions. Figure 19-9 shows a procedure that can take an ordered pair of points as argument.and
produces a result of type "real" labeled m.
Figure 19-9: Procedure outline showing argument and result pins.
The argument is shown as an output pin even though it carries the input to the procedure. From the point of view of
the procedure, the argument may be thought of as the output of some preceding procedure.
A line of pins inside an action (see Figure 19-10) indicates an array. This set of pins may be labeled.
Figure 19-10: Pins indicating an array inside an action.
The hatched pin symbol inside an action (see Figure 19-11) indicates a reference to a pin that is owned by a
nested action. The pin is not actually duplicated by enclosing action.
Figure 19-11: A hatched pin indicates a reference to a pin owned by a nested action.
The informal notation shows data flows between actions. Interestingly, data flow diagrams were (and remain)
intentionally omitted from the UML on the basis that they do not fit cleanly into a consistent object-oriented
paradigm. However, the UML 2.0 Superstructure RFP (UML 2.0 RFP) calls for proposals to provide improved
control and data flow modeling in activity graphs. The RFP also states that UML 2.0 shall consider reconciling with
the action semantics. It is therefore likely that at some point UML will incorporate some notation for representing
action specifications, if only for the same reason that other UML diagram notations are standardized:
The UML notation is an essential element of the UML to enable communication between team members.
Compliance to the notation is optional, but the semantics are not very meaningful without a consistent way of
expressing them. (UML 1.5, Preface p.xxxviii)
<Day Day Up>
<Day Day Up>
Summary
UML action semantics provide modelers with a common set of formalisms for writing behavior specifications. The
action semantics specification does not restrict the modeler to a single notation but allows any formalism that
conforms to the semantics to be used. The formalism may be graphical or text-based, leaving the choice of
expression mechanism to the modeler.
By conforming to common semantics, behavior specifications that use one action language can potentially be
translated into other languages without distortion. This facilitates the portability of models between tools and
encourages the use of models for disparate purposes throughout the model lifecycle. Activities that rely on
rigorous specification techniques will benefit from this. These include not only code generation, but also model
simulation and automatic test generation.
At the moment there is no UML standard notation for expressing action specifications. However, the introduction of
action semantics is likely to stimulate interest in enhanced Activity diagrams or data flow diagrams for this purpose.
By its incorporation into the UML, action semantics provides standards for the use of action languages as a
specification technique. The adoption of this standard will raise the awareness of model specification using action
languages among analysts and designers who are using, or intend to use, UML. There is, therefore, likely to be
renewed interest in methodologies and tools that support these techniques.
Model-based development by automatically validating models and generating code has been successfully applied
in specific applications but has not so far threatened the dominance of traditional programming techniques. It will
be interesting to see if the adoption of support for precise action specifications into UML, given UML's enormous
impact on thinking within the software development community, will cause this position to change.
<Day Day Up>
<Day Day Up>
Part VII: Automating the UML Modeling Process
In This Part
Chapter 20: Using a Modeling Tool
Chapter 21: Customizing UML Using Profiles
Chapter 22: XML Metadata Interchange
Appendix A: UML 1.4 Notation Guide
Appendix B: UML 2.0 Notation Guide
Appendix C: Standard Elements
<Day Day Up>
<Day Day Up>
Chapter 20: Using a Modeling Tool
Modeling tools and UML go hand-in-hand. UML specifies a graphical notation to model systems, with underlying
semantics for what the notation means and how things piece together. Modeling tools enable users to easily draw
these notations, and input information concerning what they mean in an underlying storage mechanism. Modeling
tools enable you to capture information, graphically design systems, disseminate the designs to a wide audience
through publishing of models and reports, and can even generate the working code of the applications and
databases. Modeling tools become the centerpiece of a set of tools that you use to understand your business, and
design or redesign the systems and databases that support it. Like any good tool, the modeling tool must be easy
to use, customizable so that you can tailor it to the job you have at hand, and be able to play well with the other
tools in your suite. In this chapter you take a look at modeling tools, so that you can understand important features
to look for when choosing one for your organization.
The Advantages of Using a Modeling Tool
Modeling tools offer a number of advantages over drawing diagrams on napkins, or on the walls of caves. One is
that modeling tool vendors specialize in making their tools support the exact graphical notations of the UML
specification. Another is that modeling tools enable you to specify underlying information to the graphical symbols-
part of the semantics of UML. An example is the fact that a class has attributes, methods, perhaps a textual
description, a stereotype, and various other properties. Modeling tools store this information in some type of
underlying storage facility, be it a file-based storage mechanism, or, better yet, a database. Storing your models in
a com-puter-based storage mechanism provides a number of benefits, to wit:
It enables you to capture the intellectual property that exists in your programmers' and business modelers'
heads.
It enables reuse of information.
It enables modelers to work as a team. The strategy used varies by modeling tool, based on its underlying
storage mechanism.
The UML semantic specification mandates how UML modeling elements are interrelated. For example, if you
model a method call as a message sent from a sending object to a receiving object on a Sequence diagram, then
that method should also be represented within the class that the receiving object instantiates. If you were to draw a
link between two objects on a Collaboration diagram, you'd expect the classes instantiated by those objects to
have a corresponding association drawn between them on a Class diagram. If you were to draw an association
between two classes on one Class diagram, and then draw the same two classes on another Class diagram, those
two classes should have the same association drawn between them. Making sure that all UML modeling elements
are consistently represented on different models within your project is difficult if you are drawing things by hand or
with a simple drawing tool. Modeling tools offer an important advantage here if they support the underlying
semantics of UML, and automatically make the proper additions or subtractions across the models. This doesn't
guarantee that your design is good, but it is a step towards good design in that it guarantees that your models are
consistent.
Modeling tools also offer additional benefits over simple drawing tools. For one, they offer reporting and publishing
capabilities. Models are a communication mechanism, but if they are only stored and accessible in the modeling
tool, then anyone wanting to view the models would need a copy of the tool, which isn't very cost effective.
Modeling tools offer varying capabilities to create reports on the models for distribution to management and other
interested parties. The reports can simply detail what the models contain, or provide metrics on the design itself-for
example, calculating the average number of methods per class. Such reports give you a barometer on how good
the design is. Many modeling tools also offer the ability to publish the designs and all of the underlying information
to HTML or XML, so that designs can be disseminated on the Internet or a corporate intranet.
Modeling tools offer varying degrees of code-generation support, so that you can automatically generate code for
your models, and reverse-engineering support, so that you can automatically create models from code. Automatic
code generation and reversal, and its corollary, round-trip engineering, has long been a silver bullet that modeling
tools have touted but never lived up to completely. Recent advances in the richness of the UML specification,
including its Action Semantics, have given hope that applications can be completely generated and managed from
models, what the Object Management Group (OMG) calls its Model-Driven Architecture (MDA) initiative.
<Day Day Up>
<Day Day Up>
Modeling Tool Features
A number of different types of modeling tools have emerged in the industry, each playing to different strengths.
Users typically choose the tool best suited to their organizational modeling needs. Many organizations use more
than one tool, and are now using interfaces, such as XML or repositories provided by third-party vendors to bridge
tools. Most UML modeling tools fall into one or more of these broad areas:
Point-solution UML modeling tools, providing support for UML notation and semantics, and code generation
and reversal, sometimes integrated with a code Integrated Development Environment (IDE). Examples are the
Rational Rose tool, now owned by IBM, Embarcadero's Describe tool, and No Magic, Inc.'s MagicDraw tool,
used for many of the figures in this book.
UML modeling tools that provide UML support integrated with support for other modeling notations, such as
relational data modeling and enterprise business modeling. An example is Popkin Software's System
Architect, also used for many of the figures in this book.
UML modeling tools with an underlying multiuser repository. System Architect falls into this category, as does
Telelogic's UMLTau tool and Computer Associates' AllFusion Component Modeler.
UML modeling tools geared toward design of real-time systems. An example is I-Logix's Rhapsody tool.
UML modeling tools that are integrated with code, so that the modeling tool is actually another type of view of
the code. The model information is stored in the code. In essence, the graphical diagram becomes a code
editor. An example is TogetherSoft, now owned by Borland.
Graphical tools that enable you to draw UML diagrams, but do not allow you to put information into them.
In the rest of this section we examine some of the important features that UML tools provide.
Support for UML diagrams
Whatever the type of modeling tool, if it is supporting UML, it should support all UML diagram types, and all or
most of the notations that UML specifies you can draw on each diagram. UML 1.4 directly specified nine different
diagram types, and indirectly specified one other (the Package diagram), making a total of ten different diagram
types. UML 2.0 has introduced a few new diagram types, and renamed two of the existing ones.
UML 1.4 Diagram Types
The following is a summary of UML 1.4 diagram types:
Activity diagram. In UML 1.4, the Activity diagram is specified as a kind of Statechart diagram. It is intended
for modeling business processes and method flows.
Use Case diagram. The Use Case diagram is one of the three most popular diagrams used with UML (the
Class and Sequence diagrams are the other two).
Class diagram. The Class diagram is one of the core UML diagrams. It provides a representation of the static
structure of the system.
Object diagram. Do not look for an Object diagram in a modeling tool. Draw objects on a Class diagram, and
draw links between the objects. If you do so, you have an object diagram, according to the UML specification.
Package diagram. Do not look for a Package diagram in a modeling tool supporting the UML 1.4
specification, because the spec does not call for one. If you draw primarily packages on a Class diagram, you
can consider it a Package diagram. Until UML 2.0, this was an informal name given to a Class diagram on
which modelers showed the subpackage structure of a given package, and the relationships between the
subpackages.
Statechart diagram. This diagram is very important for real-time analysis and design. If you are involved in
real-time design, you should make sure the modeling tool provides support for the many notations of the State
Machine diagram, including nested states, hiding of substates, history, and so forth. If you add an attribute or
method to a state, is it also added to the class? Does the modeling tool support automatic generation of code
from the State diagram?
Sequence diagram. The Sequence diagram is a type of Interaction diagram. It's widely used, and UML
specifies a lot of ancillary notation for it. You should make sure the modeling tool supports the basic notation
that you need, and any ancillary notation that you will be using. Key questions: is it easy to draw focus-of-
control lines in the tool, and can you move object lifelines freely on the diagram so that you can show object
creation?
Collaboration Diagram. This is the Sequence diagram's sister diagram. Most modeling tools enable you to
automatically create the Sequence diagram from this diagram, and vice versa. Be advised that in UML 2.0, this
diagram is renamed to Communication diagram, described in the next section.
Component diagram. The Component diagram is important for modeling the structure of your code modules
and for code generation. See if the modeling tool enables you to specify the classes contained in each
component, and if the component diagram is involved in the tool's code generation and reversal.
Deployment diagram. A key diagram used to model the hardware architecture of your systems. It is
advantageous if the modeling tool supports custom graphics, so that you can replace rectangular nodes with
symbols that more accurately reflect your hardware.
UML 2.0 Diagram Types
UML 2.0 specifies some new diagram types. It also specifies all of the diagram types of UML 1.4 with some
noteworthy changes that are described below:
Communication diagram. In UML 2.0 the Collaboration diagram of UML 1.4 was renamed to Communication
diagram.
State Machine diagram. UML 2.0 renames the Statechart diagram of UML 1.4, and specifies two types of
state machines that can be modeled on the diagram: behavioral state machines and protocol state machines.
Much of the notation of the State Machine diagram is inherited from the Statechart diagram of UML 1.4.
Interaction Overview diagram. This is a new diagram type introduced by UML 2.0. It is a variant of the Activity
diagram that enables you to represent an overview of control flow between interactions described by
Sequence diagrams.
Timing diagram. This is a new diagram type introduced by UML 2.0. It is considered optional. The Timing
diagram is used to show conditions that change within and among object lifelines along a linear time axis.
Composite Structure diagram. This is a new diagram type introduced by UML 2.0. This diagram type is used
to depict the internal structure of a classifier.
NoteThe UML 2.0 specification clarifies the confusion concerning the Object and Package diagram
introduced by UML 1.4. Both are considered kinds of Structure diagrams. If you draw primarily classes on
a Structure diagram, you have a Class diagram. If you draw primarily objects and links between them on
a Structure diagram, you have an Object diagram. If you draw mostly packages and their relationships
on a Structure diagram, you have a Package diagram. Many UML modeling tools may not have renamed
their Class diagram type to Structure diagram. Don't fret if they haven't; it's the same thing.
Navigation
Navigation in almost all modeling tools is done through a standard browser, which presents UML packages in
much the same way that Microsoft Windows Explorer presents items in folders.
Viewing the organization of the models
Packages enable you to see the structure of your models. Packages may be nested within other packages; a
package provides a separate namespace for the elements within it. Within the packages, the modeling tool
presents the UML diagrams contained in the package, and the definitions in the package, which may or may not be
represented on diagrams.
Figure 20-1 shows a typical user interface for a modeling tool, in this case the user interface for System Architect,
with a Sequence diagram drawn in the diagram workspace.
Figure 20-1: Modeling tool user interface with browser providing navigation.
The browser is presented on the left side of the tool, although it may be detached and floated or closed to provide
more diagram workspace. Above the browser is a toolbar that provides the drawing elements specific to the
Sequence diagram. To the right of that toolbar are standard graphical tools for coloring and specifying fonts, which
you would find in any drawing tool. Above that are toolbars for zooming in and out of the diagram, and for various
other functions unique to modeling tools, such as navigating between leveled parent-child diagrams.
Finding classes and other definitions
Although a package-based browser presents the organization of the models nicely, an alternative view is
necessary to help users find particular classes and other definitions while they work. If the package structure were
the only view available, you would have to search within each package to find a particular class. Most UML
modeling tools offer an alphabetical list of classes, and other definition types, so that you may easily find the item
you want to edit or use on a diagram. Some tools offer reference-by commands, so that you can right-click on an
item in the browser, and quickly see every diagram on which the particular item is presented, and every definition
that uses it. When doing real work, being able to find items easily and quickly is extremely important.
Moving classes and other items between packages
During analysis and design, you will often find it necessary to move classes between packages as you change your
design ideas. A modeling tool should enable you to select one or more items, such as classes, from one package
and move them to another package in a single step, similar to the way you move items around in Windows
Explorer. Modeling tools should accommodate both moving and copying an item to a different package.
Other navigational tools
Some tools have introduced two- and three-dimensional matrices to view a crosscut of items in the repository. For
example, you might want to view a crosscut of Use Cases versus Requirements, or Classes versus Tables that
they access.
Model repository
The term repository is one that is used often in the modeling arena, yet it means different things to different people.
The most common understanding is that a repository is a storage mechanism for all of the information concerning
your systems. For a modeling tool, having a repository generally means that the tool stores model information in
an underlying database, either a proprietary one, or one based on an industry-standard database, such as
Microsoft SQL Server or Oracle. The model information may include links to external documents, such as
requirements documents, test plans, and so forth, that may sit outside the modeling tool.
There are a number of key features normally supported by the repository:
Navigating through the repository's information, via a browser or other means.
Customizing the metamodel of the repository.
Getting information into and out of the repository, from and to other tools. To do this, the repository should
have an open and documented API. Many modeling tools today typically have an interface accessed via a
published Object Model, so that users can use a script language, such as Visual Basic for Applications (VBA)
to get information into and out of the repository.
Allowing the modeling elements in the repository to link to external documents, such as requirements
documents or test plans, in directories on the network external to the repository, or stored in the repository.
Backing up, versioning, and restoring the repository.
Allowing many users to work on the repository at the same time.
Extensibility
A modeling tool must support UML's extensibility provisions to be useful. Otherwise you may find yourself not being
able to capture information important to your organization in the tool. Extensibility also enables modeling tools to
work well with other tools, and enables you to customize the look of symbols on diagrams to promote better
communication of your design ideas.
Implementing the UML metamodel
A good modeling tool will have implemented the UML metamodel correctly. It will also offer the user the capability
to extend the UML metamodel.
Extending with tagged values and stereotypes
A tagged value is a user-defined property. An example is adding a new property called Author Name to the
information captured against a class, so that you may fill in the programmer who designed the class. To support
UML correctly, the modeling tool should enable you to add tagged values to all UML classifiers.
A stereotype is a UML type that you specify for a classifier, and in so doing categorize the classifier. The modeling
tool should provide a formal list of stereotypes for each classifier type, and allow users to create their own
stereotypes. In addition, the modeling tool should change the information that you may associate with a definition
of a classifier based on its stereotype. For example, you may specify that a class is of stereotype Actor. In the
modeling tool, you select Actor from a list of predefined stereotypes to choose from for a class. Once specified, the
tool should filter the information to fill in for the class so that only information for an Actor is presented, which would
be business-level information.
Creating new classifier types
Some modeling tools and metamodel repositories have implemented a meta-metamodel layer or equivalent,
which gives you a language to extend the UML metamodel further, or create other metamodels. These tools offer
the capability to create new classifier types. For example, you might want to create new classifier types for
Functional Requirement, System Requirement, and Technology Requirement so that you could use the modeling
tool's repository to store your requirements, and relate them to UML model elements that satisfy them. Each new
requirement classifier type would have its own set of tagged values.
Customizing icons in the tool
UML's graphical notation may be extended. Users may replace the standard rectangular or oval symbols with their
own icons, as long as they do so within UML's guide-lines. Modeling tools should allow the user to choose whether
a symbol is displayed according to the standard UML specification or a user-supplied icon. Customized icons
should be based on the particular stereotyped UML item they represent. Once an iconic relationship with a
stereotype is defined, any node drawn with the modeling tool that uses that stereotype may use the specified icon
to represent it instead of the standard representation.
Figure 20-2 shows UML nodes on a Deployment diagram. Within the modeling tool, the user has defined
stereotypes that represent different types of nodes, in this case Firewall, Modem, and Tablet PC, and has supplied
a graphic for each. The figure shows two allowable representations, one displaying the nodes in the regular form,
which is a cube, and one using the icons supplied by the user.
Figure 20-2: Displaying an item according to its stereotype, using user-supplied graphic metafiles.
The user-provided graphic for an icon is typically a metafile, not a bitmap or jpeg. A metafile is a vector image,
which means that it is made up of individual vector lines. The advantage of a vector image is that it scales well -
you may drag to increase or decrease its size, and the image will retain its sharpness. Non-vector images distort
when they are resized in a graphical tool.
Sharing models
Modeling large systems is a collaborative effort. You may have business analysts modeling business requirements
and workflow, programmers designing the applications, data modelers designing the databases, and so on. To
facilitate multiple users working on the models concurrently, it is essential that modeling tools enable multiple
users to share the models. The level of support for this varies by tool. At one end of the spectrum, some tools
enable multiple users on a network to work on models at the same time, with some sort of conflict resolution.
Other tools provide a strategy for users to check out portions of the model to work on in their workspace, and later
check their portion back in.
Team support
During analysis, it is advantageous to have multiple team members working on the same models at the same time.
That way, no modeler reinvents the wheel. As they work, modelers can see the models of the entire system, even
as new models and classes are added by other team members while they work. Tools that support multiple users
working on the models at the same time generally work as follows: if User A opens the definition of a class to edit
it, and User B tries to open the definition while User A has it open, User B gets a read-only version of the class
definition. As soon as User A closes the definition dialog, any other user can open the definition dialog. Likewise, if
User A opens a diagram for graphical editing, all other users can only open a read-only version of the diagram until
User A closes the diagram.
In addition to conflict resolution, sharing models also requires the capability to check out or to freeze certain
definitions. Checking out a definition means that it is yours until you put it back; no one else can edit it, whether it's
open or not, until you check it back in. Freezing a definition enables it to become a standard that anyone can use,
but no one can change. Normally only a project leader or system administrator is given the authority to freeze a
definition. In the browser in Figure 20-1, the modeling tool provides a check mark next to the Manager class to
indicate that it is checked out, and an icon of a thermometer next to the Customer class to indicate that it is frozen.
UML modeling tools predicated towards design offer a different scheme for multiuser use. The strategy involves
using a version control system to hold the models, and for users to check out portions of the model for use on their
desktop. The package normally serves as the grouping mechanism that gets checked out. In other words a user
checks out a package to her workspace, and works using the classes and other UML classifiers within that
package.
The advantage of this workflow is that it is similar to the way that programmers work while coding. And it scales
well. Each modeler can work in a different package without getting in another modeler's way. The disadvantage is
that if a package containing many subpackages and classes is checked out, all of those classes are also checked
out and become unavailable to other users. This decreases the multiuser usefulness of the tool.
Scalability
Scalability is another important issue when using modeling tools in a multiuser environment. Scalability refers to
the ability of the modeling tool to scale (increase in size and/or number of users) without performance degradation
- scale in the amount of users who can work on models simultaneously, scale in the size of the repository as it
becomes filled with models, and scale in the size of the largest diagrams that can be built in the tool.
Modeling tools that support multiple simultaneous users generally allow 20 to 50 users working simultaneously on
a project, depending on bandwidth. A strategy is offered for larger teams, wherein a repository may be subdivided
into multiple projects, with each project originating from a check-out of material from an enterprise repository.
Many of the users who need to access the models often need to only view the models. For this reason, Web
publishing of models becomes an important part of a modeling tool's scalability solution.
The size of a repository based on the number of models and the amount of information stored within it is generally
not an issue. However, large "spaghetti" diagrams containing hundreds of classes can create problems: they are
not only difficult to read and understand, but also cause delays in the modeling tool's painting when presenting
them on the screen. Overlarge class diagrams are generally easy to avoid with UML modeling tools. Since
modeling tools support UML's underlying semantics as well as notation, you can subdivide a large diagram into
multiple small Class diagrams without loss of information.
Access control or security
When working in a multiuser environment, some sort of access control or security is necessary to establish what
individual modelers can access or do. For example, you might not want a junior person deleting or editing classes
without approval by a supervisor or senior programmer.
Most multiuser tools provide access control at the project level, enabling a system administrator to grant various
modes of access - such as ability to add, edit, delete, or simply view the models - to individual users. There are a
number of ways to slice access control further. You might want to specify access by user group or by the function
that the modeler performs - for example, only enabling users designated as business modelers to edit and create
Use Case diagrams, while programmers can only work on diagrams concerning class design, and data modelers
can only work on data models.
Audit trails
Modeling tools generally provide the ability to retain and access an audit trail of all user interactions within the
repository. So, for example, you can look at the definition of a class, and see the ID of the user who created it, and
who last changed it, and at what time it was changed. You also can run reports that tell you what every modeler
touched and changed on a particular day or period of time.
Change management
Management of change to the models is extremely important in a working environment. There are two reasons
why change management is important to UML modeling tools - the capability to manage project and enterprise
repositories, and the capability to version projects (and at times roll back unwanted changes).
Repository management
When working in an enterprise environment, you typically store your models in an enterprise repository and check
items out of that repository to create smaller project repositories. At some point, the project repository is merged
back into the enterprise repository. During this process, it is imperative to know what has changed in the project
repository.
The key to change management is part organizational management and part modeling tool functionality. From an
organizational management view, you should have procedures in place so that the project repository is properly
created, and items merged back into the enterprise repository at the proper time. The modeling tool needs to
provide the capability to compare the elements in each repository, down to the finest level - for example, the textual
description of a class definition. The modeling tool should enable you to specify and merge particular items back
into the enterprise repository.
Versioning
You may also create different versions of the models themselves. It is very common to create a baseline or "as is"
version of the system, and then a target or "to be" version. Ensuing versions of the models can be built, similar to
the way that code bases are versioned.
The modeling tool should provide a means of determining the differences between two versions, again through
some sort of repository comparison tool. In addition, the modeling tool should provide the capability to version the
repository, or parts of the repository, to an off-the-shelf version control system.
Reporting
Information is disseminated to an audience via reporting or Web publishing, two of the most important features a
modeling tool provides. (See the next section for more on Web publishing.) Your audience might be management,
to whom you may need to provide updates on what's going on with the project. Management may also want to
reference the models as an information source regarding the workflow of the business and the architecture of the
underlying systems. Your audience might include your programmers, who want to see the Use Cases for the
applications they are building, or the data models they are building applications against. Your audience might
include your quality assurance people, who use the Use Cases to test the system. Your audience might be the end
users to your system, who want to gain an understanding of how the system works by looking at the Use Cases or
Activity diagrams. Your audience might be outside vendors, if you are bringing in contract work.
Types of reports
Reports can simply be output pictures of the diagrams and all of the information contained in them, or they can get
much more complicated. You might want to produce a report for your programmers detailing all of the
components available in a system, and the specification of their public interfaces. You might want to produce a
report to management concerning the Use Cases affected by a change to a business requirement, and the Activity
diagrams and Sequence diagrams that are affiliated with the affected Use Cases. Metrics reports provide you with
a barometer of how well your application is designed by offering such information as the average number of
methods per class, or the total number of classes with less than five attributes.
Types of reporting systems
Modeling tools generally come with a number of canned reports to generate for the models. The canned reports
present standard information, and usually enable you to make simple choices about what information is to be
generated.
For more complicated reports, a user-customizable reporting system is necessary. If the modeling tool stores its
information in an underlying database, the tool generally offers either a proprietary custom reporting system, or an
interface to a third-party data extraction and report writing tool, such as Crystal Reports.
If the modeling tool provides its own custom report writer, you should make sure it is well-documented, flexible,
and easy to use.
Output medium
The output medium for your reports will vary depending on the audience you are distributing them to, and a good
modeling tool should support multiple media.
When examining a modeling tool, first understand to whom you will be outputting reports. Will you require printed
reports to hand to management in a hard-copy format? Will you be publishing reports for distribution on the
corporate intranet? In most cases, you will be doing both.
The modeling tool's report writer should be able to print out formatted reports. Some report writers offer interfaces
to word-processing tools, such as Microsoft Word, so that formatting and printing can be done in those programs.
For dissemination of reports to the Web or intranet, newer report writers output information to XML and enable
formatting of the report via XSL stylesheets. This is a very flexible method for publishing reports.
Formatting
An important feature of a modeling tool's reporting capability is how well its reports can be formatted. No one looks
at a report that is hard to read; conversely, an attractive report shines a good light on an entire project.
The report writer should enable you to easily format the report output. Such formatting includes sizing the diagram,
setting column headings, specifying the number of columns on a page, and so forth. If you are dealing with
government specifications, you should be sure that the modeling tool can output reports to MIL-spec standards,
which often specify the exact width of borders, and so on. The report writer's print function should enable print-to-
screen and print preview options.
Web publishing
Web publishing has become a standard feature in modeling tools; some tools perform this function better than
others. Web publishing enables you to publish your models to a wide audience. The model information and
associated graphical information is generated to HTML, or XML, for publishing on the Internet or corporate intranet.
There are a number of things you should examine concerning a modeling tool's Web publishing:
Does the modeling tool provide you with the capability to choose what information from the model is
generated? How fine-tuned are your choices?
Can you customize the HTML output so that you can put your own corporate labels on the published HTML
pages?
How easy is the generated HTML to navigate? Most modeling tools provide hyperlinks from diagram symbols
to underlying definitions, and numerous hyperlinks to jump around in the report. However, remember that in
the modeling tool, the browser and other navigational aids such as an alphabetical listing of classes are
important to your navigation of the models. The HTML output from the modeling tool should offer similar
amenities. See if the modeling tool's browser is replicated in the HTML output, so that you can navigate the
same package structure you are familiar with as a UML modeler or Windows Explorer user.
Perhaps the biggest problem with HTML output from modeling tools concerns the size and presentation of the
graphical diagram. Modeling tools generally create .jpg or .png images of diagrams, and provide you with
options on how to scale the diagram before generation. For large diagrams, however, what you often end up
with is diagrams so small that the symbols on them are hard to read. This defeats the purpose of the graphical
nature of UML to provide information. Some modeling tools are now translating the graphical diagrams into
Scalable Vector Graphics (SVG) format, a vector format that enables you to zoom in and out of the graphical
diagram in the published HTML output just as you would in the graphical modeling tool.
Integration with third-party tools
No modeling tool is an island. A modeling tool is one important piece of a set of tools you use to create and
maintain the information about your business and to design its systems. The modeling tool often becomes the
centerpiece of information capture. At the front end are requirements management tools, and at the back end are
testing tools, integrated development environments (IDEs), and database management systems (DBMSs). In
between are other tools used to gather information about your business and its systems, such as word processors
and spreadsheets.
Requirements management
Requirements management tools are designed to capture, trace, analyze, and manage requirements. Depending
on the tool, the requirements are either stored in an underlying database or managed in external documents.
Many modeling tools provide interfaces to third-party requirements management tools, so that a link is created
between requirements in the requirements management tool and model elements that satisfy the requirements in
the modeling tool. Reports may be generated to see which requirements are satisfied by what model elements. If a
requirement changes, a report can be run to provide the impact analysis of the change to the requirement.
Testing
Some modeling tools provide links to third-party testing tools, so that Use Cases can be generated as test scripts in
the testing tool. If Use Cases are changed, the link provides automatic updating of the test scripts. Integrating the
modeling tool with your testing tool enables your quality assurance people to be in tune with the requirements of
the applications they are testing.
Getting information into and out of the modeling tool
Most vendors support generic mechanisms for getting information into and out of the modeling tool. These include
importing and exporting information in XML format, XMI format, and in CSV (comma-separated value) format. XML
is a version of XML that supports all of the UML diagram types. Tools that support more modeling methods than
just UML (for example, data models and business process, function, and organizational models) often also offer
XML import and export to a tool-specific DTD.
There are a number of reasons why you would want to get information into and out of the modeling tool's
repository. Information is often generated outside the modeling tool. For example, some modelers prefer to
brainstorm a list of classes in an Excel spreadsheet, and then import them into the modeling tool. A CSV import
easily accomplishes this, without the need for building a special interface. At other times, users might want to
create information in a modeling tool and then manipulate it somewhere else - for example, export information
from the tool in XML format, and then build a Java application to manipulate the data in some way.
VBA
Pre-built interfaces to third-party tools that the vendor supplies are sometimes not enough. Most modern modeling
tools have adopted Microsoft's Visual Basic for Applications within the tool. What this means is that you can access
the VBA IDE within the tool, and build custom programs, called macros, that are started by events in the tool,
whether by a menu command that you create, opening or closing a diagram, or some other event. A scripting
language such as VBA enables you to build custom interfaces to most third-party tools.
Code generation and reversal
One of the traditionally sexy features of modeling tools is their capability to automatically generate code from
models, and to reverse-engineer existing code to automatically create diagrams. The languages supported for
code generation and reversal are typically Java, C++, Visual Basic, and more recently C# and VB.NET. Most tools
only support generation and reversal of the class and component diagrams, which represent the static structure
and organization of the code.
Some tools also support generation of code from Sequence diagrams, Activity diagrams, and State diagrams.
Less support is provided for reversal of code into these diagrams.
The most popular of the code generation tools are those that sit directly on the code, so that the modeling tool
basically becomes a code editor - a change to the model causes a direct change to the code. The IDE is built into
the tool, so that you may see the model and the code at the same time.
Modeling tools that offer the traditional approach of generating to and from files also offer benefits to certain users,
especially those who have many files of code that they want to reverse engineer into the modeling tool as a start to
analysis.
Round-trip engineering
Round-trip engineering refers to a tool's ability to automatically generate code, enabling programmers to modify
that code, and then have the tool reverse engineer that code so that the models become synchronized with the
newly modified code. Subsequent generations and reversals of code continue to keep the models synchronized
with the code.
XMI
Support for export and import of XMI is a new solution for code generation and reversal supported by modeling
tools. A number of third-party vendors are now offering services to transform XMI, via XSLT, to other languages,
such as Java, C++, C#, VB .NET, and so forth.
<Day Day Up>
<Day Day Up>
Model-Driven Architecture (MDA)
Modeling tools have been around for more 20 years now. Early modeling tools were referred to as Computer
Aided Software Engineering (CASE) tools. These tools were touted as the "silver bullet" of their time - they
promised full code generation from models, so that business modelers could design the business workflow, and
push a button to generate the supporting applications. The CASE tools did not live up to this promise, resulting in a
rather soiled reputation for the term CASE. Through the years, the industry realized that such tools were still
extremely important in helping users to analyze and design their business and systems - enabling them to model
their systems and capture and disseminate design information, if not generate the code automatically. Modeling
tool became a more appropriate term to describe these tools.
Through the years, technology has been advanced to the point where full code generation from a modeling tool is
again being looked at as a real possibility. The straightforward alignment of object-oriented code with object-
oriented models, the ongoing maturation of the UML specification, and the advent of Web services and business
execution languages has made full code generation from business and technology models a realizable goal.
The Object Management Group (OMG) is at the forefront of the drive to realize this goal, with the Model-Driven
Architecture (MDA) initiative. The initiative is aimed using modeling tools and metamodel repositories to drive the
design and implementation of distributed systems. MDA aims to make all OMG standards, from CORBA to UML to
numerous profile specifications, work together to support the full life cycle of designing and deploying systems.
MDA places emphasis on models over technology.
PIMs and PSMs
The idea of MDA is to drive code generation from models. MDA specifies that a platform-independent model (PIM)
be created, containing a precise specification of the system expressed in UML, without specifying technology-
dependent details. The PIM can be mapped to a platform-specific model (PSM), which contains design and
implementation details. The PSM is then mapped to working code in a particular coding language. The goal is to
model once, and generate everywhere.
To support MDA, the modeling tool should enable you to create a PIM and a PSM, independent of one another.
When building a PIM, you focus your modeling efforts on the business problem at hand, without worrying about
implementation details. However, a PIM should not be confused with an analysis model - both analysis and design
models can be PIMs. During design you modify your analysis models to reflect design decisions and structure, but
if you are following the MDA paradigm, you do not specify platform- or technology-dependent information. This
information is specified in the PSM.
What makes a PIM stand out from traditional analysis and design models is that it is a precise specification of the
function, structure, and behavior of the system. It needs to be precise so that it can be properly translated to a PSM
without losing information or any interpretations of what the system does. A number of advanced UML features are
used to make these models precise. The Object Constraint Language (OCL) is used to express constraints on
model elements in a formal manner, rather than just expressing constraints with simple text, which can be
ambiguous. Specifying patterns in the PIM is another technique to express design concepts in a formal,
unambiguous manner. The Action Semantics of UML provide another means to specify precise details of the
behavior of the system, without specifying platform-specific details.
To fully support MDA, the modeling tool should support OCL and Action Semantics.
UML profiles are the primary tool used to model PSMs. A number of profiles have been adopted by the OMG for
specific platforms, such as J2EE and CORBA. Profiles enable you to model information specific to a platform
using stereotypes, tagged values, and constraints.
To fully support MDA, the modeling tool should support working with profiles for the languages that you wish to
generate code for.
Cross-Reference Refer to Chapter 18 for detailed information on OCL. See Chapter 19 for more on action
semantics. Refer to Chapter 21 for detailed information on profiles.
Mapping PIMs to and from PSMs
An important enabler of MDA is the ability to map PIMs to and from PSMs without loss of information. To support
MDA, the modeling tool should not only enable you to create a PIM and a PSM, independent of one another, but
also provide an automatic mapping of a PIM to a PSM, and a PSM to working code. There are four mappings that
are of interest, as follows:
PIM to PIM - such as an analysis model to a design model. Look for this mapping to be available in the
modeling tool.
PIM to PSM - this can be performed in the modeling tool, if it supports both PIMs and PSMs, or it may be
enabled by generating the models to an external coding tool. One strategy is to output the PIM to XMI, and
then use a transformation script in a language, such as XSLT, to map the PIM to a PSM.
PSM to PIM - reverse engineering of a PSM to a PIM. Again, this can be performed in the modeling tool, or if
the modeling tool supports import of XMI.
PSM to PSM - for component realization and deployment.
<Day Day Up>
<Day Day Up>
Evaluation Criteria: Checklist for selecting a modeling tool
When selecting a modeling tool, you should have a clear understanding of what features are important to you in
creating models. As mentioned earlier in this chapter, modeling tools on the market today feature strengths in
individual areas. Some are ideal for overall enterprise modeling, some are geared toward real-time analysis and
design, and others are for visualization and reversal of code.
Once you narrow down the tools you are looking for, try to arrange a demonstration of the tool. If you expect to buy
a number of licenses of the tool, you can ask the tool vendor for a free demonstration. Most vendors will
demonstrate the tool for you either on site or via a Web conference call. Some tool vendors also provide canned
demos on their Web sites. Most provide a free evaluation of their products, which you can download and try for a
limited time period. Once you select a tool, run a pilot project.
The following checklist is not definitive, but it should help you formulate questions when shopping for a modeling
tool. You should reference the material presented earlier in this chapter for more information on each point.
Support for UML diagrams
Remember that UML specifies the notation and semantics of models. The UML specification has become fairly
complicated and continues to evolve. There is no modeling tool on the market that supports 100 percent of it.
Luckily, there are few users that use 100 percent of it. Most users use anywhere between 20 to 70 percent of what
the specification details. Most modeling tools support 80 to 90 percent of the specification. Depending on the
degree of customizability of the modeling tool, you may be able to add any missing notation or functionality to the
tool yourself
Support for UML diagram notations. Ascertain what UML diagrams your organization will use in the short
and long term. Use this book as a guideline in determining the notations of each diagram type, and see if the
UML tool provides those notations.
Support for UML semantics. If you draw an association between two classes on one diagram, and drop the
same two classes down on another diagram, is the association drawn automatically? If you add a method to a
message on a Sequence diagram, is the method added to the class that the receiving object instantiates? If
you add an attribute to a state in a State diagram, is the attribute automatically added to the class's definition?
These are the types of questions you should ask while examining a tool's support for UML semantics.
Diagram views. Can you easily show and hide items on the symbols on diagrams? For example, does the
tool provide the capability of hiding certain relationship types on a diagram? Can you hide and show various
properties of a class on an individual-class basis as well as on the diagram as a whole?
Parent/child relationships. Can you create hyperlinks between diagrams, so that clicking on a symbol
enables you to navigate to a "child" diagram? Does the tool support the connecting of multiple child diagrams
to a single symbol? Does the tool support the connecting of multiple "parent" symbols to one child diagram?
Integration with other methods
Business modeling integration. Are the business modelers in your organization using UML, or are they
using other methods to model the business? If they are using other methods, does the modeling tool provide
support for such business modeling, integrated with UML diagrams, or provide appropriate links to other
business modeling tools?
Data modeling integration. UML provides some support for relational data modeling through a profile to a
Class diagram, but this is often insufficient for serious data modelers. Does the modeling tool provide
relational data modeling that satisfies your data modelers, or provide appropriate links to other data modeling
tools?
Navigation
Can you easily get a list of classes in the project, or within the particular package you are working in, to reuse
them on diagrams?
Can you navigate the package structure of your UML models in a browser?
Can you easily move multiple items from one package to another via the browser?
Does the tool support navigational aids other than a typical browser, such as cross-reference matrices?
Repository
Does the tool have an underlying repository, and if so, what is its structure? Is it proprietary or based on an
industry-standard database? Does it have an open API? Can you easily get information into and out of it?
Can you easily search the repository to find items?
Customization
Can the metamodel of the tool's repository be customized?
Can you add tagged values to the tool?
Can you add your own stereotype values?
Can you add your own custom graphical symbols (metafiles) to the tool? Can these graphical symbols be
selected based on stereotype?
Team support
What does the vendor mean by multiuser support, and will this accommodate your work environment?
Can you control who can create, read, update, and delete items? Can you specify access control based on a
user's role in the system?
Version control
Does the vendor provide a version control strategy for its models?
At what level is the versioning of a model: individual definition level, package level, or project level? Is the level
of versioning sufficient for your modeling workflow?
Does the vendor provide a comparison tool so that you can compare the contents between versions?
Reporting
How good are the tool's preformatted reports?
Does the tool have an interface to a third-party report writer, or provide its own custom report writer, so that
you can easily create more complicated reports?
Can reports be formatted and printed? Can reports be published to the Web, possibly via XML with XSL
stylesheets?
Web publishing
Is Web publishing (HTML) output easy to navigate, possibly providing the same type of package-based
browser as the one in the modeling tool?
Does the tool's Web-publishing output generate diagrams to SVG format, enabling zooming in and out of the
diagrams published in HTML?
Integration with other tools
Does the tool support a scripting language, such as Visual Basic for Applications (VBA), with a published
object model, so that the tool's behavior can be modified, and interfaces can be built to other tools?
List the tools that your organization uses that you require the modeling tool to integrate with, such as:
Requirements management tools
Coding tools and IDEs
Testing tools
Database management systems
Configuration management tools
Office management tools containing information (that is, Word documents, Excel spreadsheets, Access
databases, and so forth)
Printing
Does the tool support print previewing of the diagrams?
Can you format the printed diagram output, to provide borders and so forth?
Can you print to a plotter printer?
Code generation and reversal
Examine the code generation and reversal requirements of your firm. Will your programmers be using the tool
heavily to model their designs?
Does the tool allow users to import and work with third-party libraries, such as the JDK?
Does the tool provide an IDE integrated in the tool?
Reverse engineer code into the tool, make changes to the model, then generate it back out. Examine the code
to see if the code regenerated matches the code that you started with, with the appropriate changes that you
made to the model incorporated.
Ease of use
Is the tool easy to use? Can you start the tool, create a project, and build a simple diagram in a straightforward
manner?
Documentation and training
Is the tool's on-line help thorough and well laid out?
Does the tool provide extensive tutorials so that your modelers can get up and running with the product
quickly?
Does the tool vendor supply on-site and public training courses?
Does the tool vendor supply online training courses?
Vendor-related questions
What type of technical support is provided?
Does the vendor produce new releases and updates to the tool regularly?
Does the vendor provide a user group for the tool?
Ask the vendor for client success stories in areas similar to your business.
Examine the vendor's Web site. What is the frequency of press releases concerning the tool at which you are
looking?
What kind of material is available on the Web site concerning the tool?
<Day Day Up>
<Day Day Up>
Summary
In this chapter you learned:
A modeling tool is an important piece of a set of tools you use to maintain the information of your business and
design its systems.
The modeling tool becomes the centerpiece of information capture.
A number of different types of modeling tools have emerged in the industry, each having different strengths.
Navigation in modeling tools is done through a standard browser, which presents UML packages in much the
same way that Microsoft Windows Explorer presents items in folders.
Some modeling tools store information in a repository, which is typically an underlying database: either a
proprietary one or one based on an industry-standard database from a leading vendor.
Being able to navigate and find information in the underlying repository is an important feature of a modeling
tool.
A modeling tool should support UML's extensibility provisions to be useful. This includes extending the UML's
metamodel, adding tagged values and stereotypes, and customizing the way symbols are displayed on
diagrams with user-defined icons.
To facilitate multiple users working on the models concurrently, it is essential that modeling tools enable
multiple users to share the models. This includes enabling multiple users on a network to work on models at
the same time, with conflict resolution, or providing a strategy for users to check out portions of the model to
work on in their workspace. Both approaches have advantages and disadvantages.
Change management is an important part of the modeling process. Change management includes proper
organizational procedures to manage projects, and tool functionality, such as a comparator utility that enables
you to compare versions of projects to see differences.
Reporting on models and publishing of models are two of the most important features that modeling tools
provide.
Modeling tools often provide a customizable report writing system, or an interface to a third-party report-writing
system. Reports are output to different media, including hard-copy printouts, and XML-based reports,
formatted by XSL stylesheets.
Web publishing enables publishing of models to a wide audience. The model information is generated to
HTML or XML. Some modeling tools now output the pictures of the diagrams themselves to SVG format,
which enables users to zoom in and out of the published diagram in their browser.
Modeling tools offer important interfaces to other tools involved in the system-building process, such as
requirements management and testing tools.
Many modeling tools now offer VBA and a published object model to facilitate customization of the tool, and
make it easy to build custom interfaces to the modeling tool with other tools.
Modeling tools enable you to automatically generate code from diagrams, and reverse engineer code to
create diagrams.
Most code generation/reversal is done to/from the Class diagram, although some modeling tools now offer
generation for the Activity, Sequence, and State diagrams.
Modeling tools support code generation in a variety of ways. Some tools actually sit on top of the code, so that
a change to the model immediately changes the code, and vice versa.
XMI is becoming a new standard for modeling tools to support code generation and reversal of languages like
Java and C++.
The OMG's MDA initiative is aimed at having modeling tools drive the design of code. The goal is to model
once, and generate everywhere.
<Day Day Up>
<Day Day Up>
Chapter 21: Customizing UML Using Profiles
Overview
UML specifies the notation and underlying semantics to model business systems. It is a broad and detailed
specification, and it satisfies the needs of most general modelers. But the UML specification is not broad or
detailed enough to encompass all of the modeling aspects for every particular programming platform or modeling
domain.
To satisfy these needs, UML can be extended. The UML metamodel is extended with three basic devices:
stereotypes, tagged values, and constraints. When you group a set of these extensions to model a specific
platform or domain, you create a profile.
The UML specification details how to build a profile. It also provides example profiles. Users and modeling tool
vendors may create their own profiles. In addition, the OMG has adopted a number of standard profiles for specific
platforms and domains of modeling, and is in the process of adopting more. Many of these offer both a lightweight
UML profile and an alternative MOF-based metamodel extension.
In this chapter, we examine profiles-what they contain, how they are built, and how they are used. We also briefly
summarize some of the profiles that have either been adopted by the OMG, or are being popularly used in the
industry.
<Day Day Up>
<Day Day Up>
What Is a Profile?
A profile is a group of stereotypes, constraints, and tagged values that work together to extend UML for a particular
platform or domain of modeling.
A profile extends the UML metamodel. It can be thought of as creating a new dialect to the Unified Modeling
Language. Profiles can be built to model the peculiarities of various platforms (such as J2EE and .NET), vertical
domains (such as banking, telecommunications, and aerospace), and modeling domains (such as systems
engineering, real-time analysis and design, and testing).
In addition to profiles, you may also extend UML by extending the MOF metamodel upon which UML itself is based,
creating appropriate metaclasses and metarelationships, to create a new language related to UML. In fact, MOF
extension mechanisms enable you to extend any MOF metamodel. Profiles are actually defined to be a subset of
the MOF extension mechanism.
Profiles are considered a lightweight extension mechanism, geared toward being straightforward and easily
supported by modeling tool vendors. The MOF extension mechanisms are geared toward being supported by
metadata repository tools and UML modeling tools providing a MOF metadata repository.
You might look at a MOF extension like adding a new extension to your house, where you actually change the
structure of your house. If you instead took an existing room in your house, added bookshelves, repainted the
room, added a new entry door, and specified that this was your business office, you would do the equivalent of
making a profile. The bookshelves could be considered the tagged values-providing you with a limited new
capability, to house books in the room.
Users may create their own profile for modeling as long as they follow UML specification rules. Likewise, modeling
tools may create and provide profiles. A number of profiles have emerged in the industry, such as the Web
Application Extension (WAE) profile.
Stereotypes
A stereotype is a type that you may apply as a property value to a UML element to extend its properties and slightly
alter its semantics. Stereotypes may be applied to all UML element types, such as classes, use cases,
components, associations, dependency relationships, and so forth.
Once you apply a stereotype to a model element, additional properties, or tagged values (described next) may
become available in the class definition.
The stereotype of a UML element is provided in guillemets above the element's name. Some stereotypes are
associated with icons, as described later in this section.
Tagged values
A tagged value is an extra property that can be added to a UML element, so that you can specify additional
information that you normally couldn't.
An example of a tagged value might be the business analyst that created a use case, or the author of a class, or
the date and time that a class was created or modified.
Constraints
Constraints enable you to specify rules and restrictions on model elements in UML. For example, a profile might
specify a constraint that you cannot draw an association between two classes of stereotype entity.
How profiles are communicated
One of the most visible aspects of profiles are the icons you can use to represent different UML classifiers, based
on their stereotype. (See Figure 21-1.) This enables you to visually express concepts more vividly than by using the
normal rectangular or oval symbols associated with most classifiers. This is important because, after all, UML is a
visual language that enables communication of design ideas.
Figure 21-1: Example of special icon to represent a class with stereotype boundary. You may either show a
class in its rectangular form or its iconized form.
Not all stereotypes have an icon associated with them. If one does, you have the choice to display the element of
that stereotype in its normal UML form, or by the icon associated with its stereotype. A well-known example of this
is the Actor symbol, which is actually a class of stereotype actor. You may choose to display it according to its
familiar stick-figure icon, or by a rectangular class symbol with the keyword actor above the class name.
Many readers may be familiar with some of the icons established by the UML Profile for Business Modeling, which
is provided as an example profile in the UML spec. This profile specifies different icons for an entity class, control
class, and boundary class when performing robustness analysis, as shown in Figure 21-1.
A modeling tool should allow profiles to be specified at a package level. Some tools offer them at the project level.
Once specified, new sets of stereotypes become available for the applicable model elements, such as classes,
use cases, and components.
Once you select a specific stereotype for a model element, such as a class, additional properties within the
definition dialog of that model element appear, if called for by the stereotype. The modeling tool may give you a
choice to display the model element by its stereotype or in its normal form.
Additional toolbars may be provided in the drawing workspace of the modeling tool, to easily enable you to draw
new, stereotyped model elements (such as a toolbar that provides icons for control, entity, and boundary classes
for the Profile for Software Development Processes, described later in this section).
How many profiles are there?
In theory, there are an unlimited number of profiles. Modelers may create their own profiles, and modeling tool
vendors may introduce profiles into their tools to model certain aspects of modeling.
However, a proliferation of profiles would be contrary to UML's basic goal, which is to provide a standard language
for communicating ideas. If six different organizations created their own profiles for modeling real-time systems, for
example, it would not be easy to compare the models produced under the different profiles. To head off this
problem, the OMG has set up an adoption process for profiles, so that experts in the industry can get together and
form standard profiles for various domains of modeling.
At the same time, there have been some profiles that have gained popular usage in the industry. Some have been
introduced in textbooks and others introduced by modeling tool vendors. It is expected that these profiles
eventually will work their way into OMG-adopted profiles.
OMG-adopted profiles
The OMG has issued a number of requests for proposals (RFPs) for profiles on important modeling domains. The
proposals submitted are put through the OMG's adoption process.
The following is a list of profiles that have been adopted by the OMG, or are undergoing the adoption process:
UML Profile and Interchange Models for Enterprise Application Integration (EAI) (OMG document ptc/02-02-
02)
UML Profile for Enterprise Distributed Object Computing (EDOC) (OMG document ptc/02-02-05)
UML Profile for Schedulability, Performance, and Time (OMG document ptc/02-03-02)
UML Testing Profile (OMG document ad/01-07-08)
UML Profile for CORBA (OMG document formal/02-04-01)
Profiles for components and for systems engineering are being worked on by subcommittees of the OMG. More
are to come.
UML specification example profiles
The UML specification itself contains example profiles, as follows:
UML Profile for Business Modeling, contained in the UML 1.0-1.4 specs
UML Profile for Software Development Processes, contained in the UML 1.0-1.4 specs
Profile for Java, introduced in the UML 2.0 spec and used as an example of how to describe a profile at the
metamodel level
Component Profile Examples, for J2EE/EJB, COM, .NET, and CCM. These profiles are provided in the UML
2.0 appendix to illustrate how UML can be customized to model component architectures. They are not meant
to be complete, but do specify the stereotypes that may be applied to components, interfaces, methods,
associations, and other model elements for each of these popular component architectures.
Common profiles found in industry
A number of profiles have emerged in the industry, proposed in certain books and supported by certain modeling
tool vendors. The most popular of these are
Data Modeling Profile for UML
Web Application Extension (WAE) profile
The specification of a profile is typically quite extensive. The specifications for the profiles adopted by or proposed
to the OMG generally range from between 200 and 500 pages each. While it is outside of the scope of this book to
describe each of these profiles in detail, summaries of many of these profiles are provided later in this chapter.
How to define a profile
UML's Infrastructure library contains a Profiles package that specifies how profiles are defined. The Profiles
package is dependent upon the Core package of the UML Infrastructure, as shown in Figure 21-2. The Core
package specifies the core concepts that you use when you model UML itself. The Profiles package defines the
mechanisms that you use to customize metamodels.
Figure 21-2: The Profiles package is dependent on the Core package of the UML infrastructure.
NoteThe concepts detailed in this section are used to model a profile. When you use such concepts, you are
actually modeling at the metamodel level - or performing metamodeling, if you will. You are not actually
modeling a real system - you are modeling additions to UML, using UML.
The Profiles package exists outside of the UML package and outside of the MOF package. Again, you may use
profiles to extend the UML metamodel, and any other MOF-based metamodel. At the same time, a profile cannot
exist separately - it must be based on UML, or another metamodel that it extends, to be useful.
Figure 21-3 shows the contents of the Profiles package. It is a Class diagram that specifies the metamodel of the
Profile constructs that enable you to extend metamodels such as UML.
Figure 21-3: Contents of the Profiles package, providing the class structure of the mechanisms used to extend
metamodels with profiles.
Let's take a look at each of these classes.
Package
Package inherits from the Package classifier in Constructs. There is a composite relationship between the
Package metaclass and the ProfileApplication metaclass. The ProfileApplication metaclass is new in UML 2.0 - it
enables you to specify the profiles that have been applied to a package.
Profile
Profile is a kind of Package. It uses the same notation as a Package, with the keyword profile before or above
the name of the package.
The Profile metaclass has associations with four metaclasses:
ProfileApplication: A profile is applied to a package via a ProfileApplication. When it is applied, it plays the
role of importedProfile. Since a profile is a kind of package (inheritance relationship), it follows that a profile
can be applied to another profile.
Stereotype: A profile is the composite of all of its stereotypes.
ElementImport: A profile also has a composite relationship to ElementImport, which plays the role of
metaclassReference. The profile defines a limited capability to extend these metaclasses.
PackageImport: A profile must always reference a metamodel. In Figure 21-3, profile has a composite
relationship to PackageImport, which plays the role of metamodelReference.
ProfileApplication metaclass
The ProfileApplication metaclass shows which profiles have been applied to a package, thus the name Profile
Application. ProfileApplication is new to UML 2.0. Previously, it was not possible to know what profiles had been
applied to a package. When you apply a profile to a package, the iconic stereotypes of that profile become
available to the model elements of the package, although you are not required to use the verbal stereotypes.
To model a profile applied to a package, draw a dashed line with open-stick arrow-head from the package being
extended to the profile being applied. Figure 21-4 shows the profiles Java and EJB being applied to the package
On-line Reservations. The dashed line is annotated with the keyword apply.
Figure 21-4: Example of the EJB profile and the Java profile being applied to the On-line Reservations
package.
Applying multiple profiles
You may apply one or more profiles to a package. If you apply more than one profile, they must not have
conflicting constraints. If a profile that is being applied depends on other profiles, then those profiles must be
applied first. If you apply multiple profiles and some of those profiles have stereotypes with the same name, then
you should qualify the stereotype with the profile name (for example, Business_Modeling:Entity and
Software_Development_Processes:Entity).
Removing a profile from a package
You may also remove a profile that you have applied to a package. When you remove a profile, you do not remove
the model elements that the profile was applied to - you simply remove the profile extensions. So if you apply a
Business Modeling profile to a package, and model a class Reservation with stereotype Entity, then remove the
profile, the class Reservation still exists, but the class no longer has the stereotype Entity applied to it.
The fact that profiles are applied in this way also means that you can exchange a model to which a profile has
been applied in one modeling tool to another modeling tool that does not support the profile. The second tool does
not see the profile extensions, but it still sees the core UML model elements.
Class
Class has a derived association (indicated by the slash mark) to Extension. This indicates how the class may be
extended through one or more stereotypes. Class plays the role of metaclass in this association. It may be a Class,
a Use Case, a Component, and so forth.
You notate a class that is extended by a stereotype with the optional keyword metaclass shown above or before
its name.
Stereotype
A stereotype extends classes through extensions. In Figure 21-3, you can see that Stereotype also inherits from
Class. This means that it is a kind of Class, and therefore may have properties. The stereotype's properties are
referred to as tag definitions. When a stereotype is applied to a model element, the values of the properties are
called tagged values. The tagged values become actual properties of the model element.
For example, Figure 21-5 shows Class extended by the stereotype Requirement. The stereotype has four tagged
definitions, author, source_document, date_entered, and date_last_updated. When the profile of this example is
applied to a package, and you model within that package and create a class, you are able to specify the class as
being of stereotype Requirement. Once you do, the class contains the additional text properties of author,
source_document, date_entered, and date_last_updated.
Figure 21-5: Specifying that a metaclass is extended with a stereotype during metamodeling.
A stereotype is displayed as a rectangular class symbol, with keyword stereotype placed above the name. You
draw an Extends line from the stereotype class to the metaclass it extends.
While metamodeling a profile, you may use the same stereotype to extend more than one metaclass, such as
Class, Component, Use Case, and so forth. Conversely, a metaclass can be extended by more than one
stereotype.
While modeling, you may attach more than one stereotype to a model element. When you do so, the stereotypes
are listed in a comma-separated list within the normal guillemets or brackets, above the name of the model
element's symbol.
Finally, you may also specify an icon for a stereotype, which can be displayed instead of the normal symbol used
for the model element. The icon for an actor stereotype, for example, is a stick figure.
Extension
An extension is the relationship line drawn between a stereotype class and a metaclass class to show that the
properties of the metaclass are extended through the stereotype. It is drawn as a straight line with a solid
arrowhead (see Figure 21-5).
You may specify that an extension is required. This is applied as a constraint to the Extension line, which means
that an instance of a stereotype must always be linked to an instance of the metaclass.
ExtensionEnd
An ExtensionEnd is a property of the Extension line. It ties one or more stereotypes to a metaclass.
<Day Day Up>
<Day Day Up>
Modeling Profiles
This section provides a short overview of some profiles that are either provided as examples in the UML spec, have
been adopted by the OMG, or are found in the industry. The specifications of most of these profiles are far too
extensive to be covered in detail within the scope of this book. Consider this section a guide so that you can gain
some familiarity with these profiles, and the methods that they enable you to use.
UML profile for EJB
The UML 2.0 specification provides a very simple profile for Enterprise JavaBeans as an example of profile
concepts presented in the previous section. Figure 21-6 shows the metamodel presented for EJBs.
Figure 21-6: Example EJB profile provided in UML 2.0 specification.
NoteThe EJB profile presented here and in the UML 2.0 specification is not a complete profile of EJBs. It is
simply an example that shows how some of the profile terminology and notation is used.
It shows that a Component is extended by a Bean stereotype, which is required. The Bean stereotype is an
abstract type, with two subtypes - Entity and Session. Each instance of Component, therefore, must be extended
by an instance of either the Entity stereotype or the Session stereotype. Remember that a stereotype is a kind of
class that can have properties - in this case, a Session stereotype has an attribute named state. This corresponds
to a tagged definition whose value specifies the state of the Session. The tagged value is an enumeration,
StateKind, which has - either a stateless or stateful value.
The Component has a constraint on it, displayed in the note attached to the Component symbol, which states that
a Component cannot be generalized or specialized.
The diagram also shows that an Interface metaclass is extended by the Remote and Home stereotypes. The EJB
package has a constraint, displayed in the note that sits in the package, that states a Bean must realize exactly one
Home interface.
Modeling with the EJB profile
All we have shown so far is how to model a profile at the metamodel level. When you apply a profile in a modeling
tool, you do not need to model the profile or draw an apply dependency from the package you are working in to
the profile. You normally turn on a profile via a selection in a dialog that the modeling tool presents, preferably at
the package level but, depending on the modeling tool, sometimes at a project level.
The stereotypes, tagged values, and constraints applied by the profile become apparent to you as you model.
Figure 21-7 shows part of a UML Component diagram. With the EJB profile applied to the package in which this
diagram is being drawn, certain new choices become available. Figure 21-7 shows how you may specify the
stereotype of a component as either Session or Entity. Note that Bean is not provided as a choice; as mentioned in
the previous section, Bean is a generalization of Session and Entity.
Figure 21-7: With the EJB profile applied to the package in which you are modeling, new choices for
stereotypes become available for a component.
UML Profile for Software Development Processes
The UML Profile for Software Development Processes is provided as an example profile in the UML 1.4
specification itself. The profile is used with the Rational Unified Process (RUP), and has its origins in the work of
Ivar Jacobson. It is also used with other UML-based business modeling methods, such as the ICONIX Unified
Modeling Approach.
The profile is defined only through stereotypes and constraints; no tagged values are specified. The profile steers
you toward grouping your models into four general categories - UseCase, Analysis, Design, and Implementation-
that you apply to models, packages, and subsystems. For example, the UseCaseModel stereotype is applied to
the highest-level package for the Use Cases representing your business analysis. The profile specifies that
associations between classes and Use Cases can be stereotyped as Communicate and Subscribe.
Most recognizable to readers are the stereotypes specified for classes: Boundary, Control, and Entity. Table 21-1
describes these stereotyped classes, and provides the iconized notation for each.
Table 21-1: UML Profile for Software Development Processes
Type Stereotype Description Icon
Class Boundary A Boundary Class sits at the boundary to a system, and
is an interface between actors outside the system and
the classes within the system, such as entity, control,
and other boundary classes. In Jacobson's early work, it
was called an interface class, but the name was
changed so that it wasn't confused with a component
interface.
Class Control The objects of a Control Class control the interaction
between other class objects. The behavior of a Control
Class is usually specific to the Use Case for which it is
modeled.
Class Entity An Entity Class is a passive class - objects of other
classes work with it or on it. The Entity Class does not
initiate interactions on its own. It is usually persistent, in
that it stores information and exists after any Use Case
realization that it is in finishes.
Using icons to distinguish stereotyped classes helps you to visually communicate design ideas. Figure 21-8 shows
the interaction of several business-level classes in what the ICONIX process calls a Robustness diagram - a Use
Case diagram on which you delve into object interactions. Jacobson called this an Ideal Object diagram in his work
in the early '90s. The ICONIX process puts forth additional constraints on these classes, for example that you
cannot draw an association between two Entity classes. In the example shown in Figure 21-8, this means that you
cannot draw an association between Reservation and Room. Only a Control class, such as Manager, or a
Boundary class, such as Reception, can interact with an entity class such as Room. These constraints force you to
build correctness into your models.
Figure 21-8: Example of special icons for Boundary Class, Entity Class, and Control Class specified by the
UML Profile for Business Modeling.
The iconized form of stereotyped elements is also applied to other diagrams, such as the Sequence diagram.
Figure 21-9 shows a Sequence diagram with an interaction between instances of the classes from the Robustness
diagram in Figure 21-8. The object lifelines are displayed in their iconized form, with the icon placed at the top of
the object lifeline.
Figure 21-9: Example of special icons for Boundary Class, Entity Class, and Control Class applied to
instances of classes on a Sequence diagram.
UML Profile for Business Modeling
The UML Profile for Business Modeling also is provided as an example profile in the UML 1.4 specification itself. It
is defined only through stereotypes and constraints; there are no tagged values.
This profile is a simple example of how UML may be applied for business modeling, based again on work done by
Ivar Jacobson. The profile specifies that a model can be stereotyped to UseCaseModel or ObjectModel,
packages within them stereotyped as UseCasePackage or UseCaseSystem, and subsystems within them
categorized as WorkUnit, OrganizationUnit, or ObjectSystem. Associations are stereotyped as either
Communicate or Subscribe. Classes are stereotyped as shown in Table 21-2. The table shows icons that
have been specified for particular class stereotypes. For example, if you specify that a class is of stereotype
Worker, you may show it in its normal rectangular form with the word Worker placed above the name, or show
the class by its special icon.
Table 21-2: UML Profile for Business Modeling
Type Stereotype Description Icon
Class Worker A Worker class represents a human worker in
a system. Worker objects interact with other
Worker objects and manipulate objects of
Entity classes.
Class Internal
Worker
An Internal Worker class is a subclass of a
Worker class - it is a specialization of a
Worker class. It is found inside the system,
and interacts with other workers and entities
inside the system.
Class Case
Worker
A Case Worker class is a subclass of Worker
class - it is a specialization of a Worker class.
Similar to a Boundary class, it interacts
directly with actors outside the system.
Class Entity An Entity Class is passive - objects of other
classes work with it or on it. The Entity Class
does not initiate interactions on its own. It is
usually persistent, in that it stores information
and exists after any Use Case realization that
it is in finishes.
UML Profile for Enterprise Application Integration (EAI)
Enterprise Application Integration (EAI) involves building new applications by coupling existing applications that
may be built in different languages and exist on different platforms. The UML Profile for EAI specifies mechanisms
that enable you to model this coupling. The full specification for EAI is more than 300 pages. It is titled UML Profile
and Interchange Models for Enterprise Application Integration (EAI) (OMG document ptc/02-02-02). This section
provides an overview of this profile.
Why do you need EAI?
Business-to-consumer and business-to-business commerce on the Internet is forcing corporations to rethink their
business processes and the existing applications that support them. Companies want to make their legacy
applications support new business processes and integrate with new applications in short order. The idea is not to
redesign the legacy applications, but to simply make them work with new applications and each other in support of
new business processes.
This integration is done through messaging that provides a loose coupling between the applications. However, that
is difficult because there is usually a need to customize each connection that ties different applications together,
especially since the applications are generally built in different languages, and exist on different operating systems
and platforms.
The UML Profile for EAI specifies a standard for the metadata that is exchanged between applications. This
enables you to design the integration points between legacy applications. Using the EAI profile, you model at the
application architecture level, designing the interfaces and interactions among legacy and new applications.
The EAI specification provides both a UML Profile and a MOF-based EAI metamodel for implementing EAI
modeling. These are alternative approaches. The UML Profile enables support of the EAI profile by modeling
tools. The MOF-compliant metamodel enables support of EAI by MOF-based repository tools and tools built
specifically for EAI. In this book, we cover the UML Profile.
Special Notations of the EAI Profile
The EAI profile does not define any special notations or icons for any UML classifiers. Stereotypes are specified for
various model elements. It is left to the user to specify any special icons.
UML EAI subprofiles
The UML Profile for EAI provides two profiles, which can be thought of as subprofiles. They can be used together
or separately, depending on the amount of modeling being done, and the focus of the modeling effort:
Collaboration Modeling Profile, which enables modeling of the structure and semantics of collaboration
between two applications, and the message flows between them.
Activity Modeling Profile, which enables you to design models that show the high-level control and data flow
required for integration of two applications.
Collaboration Modeling Profile of EAI
The Collaboration Modeling Profile of EAI specifies extensions to UML Class and Collaboration diagrams to notate
EAI models, as follows:
Terminals. Different kinds of terminals between applications are notated by appropriate stereotypes on a
class, for example, input for input terminals and output for output terminals.
Operators. An application can be thought of as an operator that works on data input to it through input
terminals and outputs information through output terminals. The EAI Profile provides class stereotypes to
denote different kinds of operators. The list of operators includes the primitive operator (which has no internal
structure of interest - it's used to model a system application), transformers, database transformers, filters,
streams, post daters, source adapters, target adapters, call adapters, request/reply adapters, sources and
queued sources, sinks and queued sinks, aggregators, timers, routers, subscription operators, publication
operators, topic publishers, and compound operators.
You use a Class diagram to model operators and their input and output terminals, and the message formats of
those terminals. You may also define the operations performed by the operator when manipulating incoming
messages to generate outgoing messages. Figure 21-10 shows an example Class diagram for a primitive
operator, with input and output terminals.
Figure 21-10: One example of stereotypes called out by the UML Profile for EAI - a Class diagram for a
primitive operator, with input and output terminals, and message content passed through the terminal.
You use Collaboration diagrams to show how individual components, such as filters, terminals, and so on, are
connected.
Resources. Resources are things that operators use to do their job, but which are not themselves operators.
The profile declares three specific resources: databases, queues, and subscription tables. Resources are
defined as classes with stereotype Database, Queue, or SubscriptionTable, or for anything else, simply
Resource.
Message formats. A message format is denoted by a class with a stereotype specified for each of the
different kinds of message format. In Figure 21-10, you see two classes - Y1 and Y2 - specified as classes of
stereotype MessageContent.
The EAI profile uses an example of a brokerage system throughout its specification. This example is pictured in
Figure 21-11. The Online Brokerage system is represented by a package that contains an International Brokerage
server and an Investment Manager Server. The International Brokerage Server interrelates with an external
Investment Manager System via http. The Investment Manager Server interrelates with an external International
Brokerage System via TCP/IP. Both the International Brokerage Server and the Investment Manager Server
convert orders to a common format and route them through a Middleware Server to a Back-End Brokerage
System, where they are processed. The Back-End Brokerage System routes the processed orders through a
Publish and Subscribe (Pub/Sub) Server to back to either the International Brokerage Server or the Investment
Manager Server, depending on which provided the order.
Figure 21-11: Example of on-line brokerage provided by EAI Profile.
Figure 21-12 shows an example taken from the EAI specification showing how the online brokerage can be
modeled as classes with specific EAI stereotypes. OnlineBrokerage is a compound operator that is a composite of
the other application operators. Notice that MiddlewareServer is a primitive operator - it has no internal structure of
interest in this view. The BackEndBrokerageSystem is shown as a compound operator that is a composite of other
classes not shown here. The figure shows its input and output terminals. It receives OrderInput (from the
MiddlewareServer, the connection not shown here), processes the order, adds ownership information, and outputs
the order to the Pub/Sub Server (connection not shown here). Remember this is the Class diagram that shows the
logic of the couplings; it does not show how things are actually connected. You would use a Collaboration diagram,
with appropriate stereotypes provided by the EAI Profile, to model actual connections.
Figure 21-12: Example of a Class diagram for a compound operator with compound components.
Activity Modeling Profile for EAI
There are two ways to model the coupling between applications. You can model the structure of the coupling and
the message passing, using the Collaboration Profile described earlier, or you can model the process flow of how
the applications pass information between each other, using the Activity Modeling Profile. Modeling the process
flow enables you to find the integration points of the applications that need to be implemented.
The Activity Modeling Profile for EAI specifies stereotypes and tagged values that are applied to action states and
transitions of the Activity diagram. The profile provides examples of modeling message flow and control flow for
system integration processes.
Conformance to EDOC's CCA Profile
The EAI Profile conforms to the CCA Profile of the EDOC, described in the next section, which specifies
component composition and communication. You can use the CCA Profile notations to describe EAI systems. An
example of using the notations of the CCA Profile for the online brokerage system is provided in the EAI
specification.
Implementation Mappings
The EAI Profile is for logical modeling of EAI couplings. The profile also provides mappings to various technologies
and tools appropriate to integration, such as message brokers. Example mappings to IBM's WebSphere MQ
Integrator message broker product and to the Java Message Service (JMS) specification of J2EE 1.3 are provided.
The EAI Profile also provides example language mappings for data structures representing connector interfaces.
The languages covered are COBOL, PL/1, C, and C++. Additional metamodels are provided for mappings to
Enterprise Application System domains such as IBM's IMS Transaction Message, IMS Message Format Service
(MFS), and CICS Basic Mapping Support (BMS).
UML Profile for Enterprise Distributed Object Computing (EDOC)
The UML Profile for Enterprise Distributed Object Computing (EDOC) specifies extensions to UML to model
integrated enterprise systems, including business modeling, application modeling, and data modeling. Part of its
purpose is to enable the modeling of business components - components that capture business processes - so
that you can build business systems by assembling enterprise components. One of the goals of EDOC is to enable
a business component marketplace, where you can buy off-the-shelf business components and assemble them to
build integrated enterprise systems. The EDOC is described in detail in the document titled UML Profile for
Enterprise Distributed Object Computing (EDOC) (OMG document ptc/02-02-05). This section provides a brief
overview of EDOC.
Why do you need EDOC?
Many businesses are coming to the realization that to properly capture the information about business systems,
and to efficiently build and manage the enterprise, you need to understand the functions of the business, the
business process work-flow that achieves those functions, and the applications and databases that implement
those functions. All of these models should be aligned and integrated, so that you can properly assess the effects
of change on the business. Better yet, if these systems are componentized at both the business and application
levels, you can build a system by assembling and integrating the proper off-the-shelf components.
The technology for enterprise-scale, multiplatform components is becoming a reality with the arrival of XML, Soap,
Java, EJBs, and .NET. What is still not available is a way to componentize the business processes, and a
systematic way to build integrated systems with these components.
EDOC provides a way to model and build business process components. It introduces the concept of a process
component, and provides necessary extensions to UML to model it. EDOC also specifies extensions to UML to
allow a loosely-coupled integration between process components and application components and data
structures.
The EDOC profile specifies these extensions at the platform independent model (PIM) level, so that the business
components can be built independent of the choice of technology and middleware.
What the UML Profile for EDOC contains
The UML Profile for EDOC contains the following:
The Enterprise Collaboration Architecture (ECA) Profile provides the core of the EDOC extensions. The ECA
Profile itself contains five profiles, described in the next section.
A Patterns Profile, which provides a standard means to express object models for EDOC systems.
A set of technology-specific metamodels, which allow the definition of Platform Dependent Models (PSMs) as
defined by the MDA. The technology-specific metamodels include a Java metamodel and an Enterprise
JavaBeans metamodel (from EJB 1.1). The Java metamodel is not a complete metamodel of the Java
language; it is intended to provide sufficient details to support the EJB development life cycle of creation,
assembly, and deployment of Enterprise JavaBeans.
The Enterprise Collaboration Architecture (ECA) Profile
The ECA specifies technology-independent modeling elements of the profile. It contains five profiles, which can be
thought of as subprofiles:
The Component Collaboration Architecture (CCA) Profile
The Business Process Profile
The Entity Profile
The Events Profile
The Relationships Profile
The CCA Profile
The Component Collaboration Architecture (CCA) Profile enables you to model enterprise systems as a set of
reusable components, both at the business level and the technology level. The CCA Profile introduces new
notation to model business components, and specifies stereotypes, tagged values, and constraints for use with
UML Class, Collaboration, and Activity diagrams to model the structure and behavior of the logical business
components of a system.
One of the key new elements to the profile is the concept of a ProcessComponent. A ProcessComponent is a
business process component. It "does something" in the system. At a high level of abstraction, a
ProcessComponent might represent a business partner. At a lower level of abstraction, a ProcessComponent
might represent business activities. The CCA Profile specifies a notation for the ProcessComponent, shown in
Figure 21-13.
Figure 21-13: The notation for a ProcessComponent.
The ProcessComponent is notated as a subsystem package symbol containing input and output ports. It uses
these ports to interact with other ProcessComponents. The simplest kind of port is the flow port, which produces or
consumes a single data type. Flow ports are displayed as arrows going through the package boundary box. In
Figure 21-13, both Receives and Sends are flow ports. Flow ports that send information, such as Sends in the
figure, have a solid black background. Flow ports that receive information have a white background.
The ProcessComponent also may contain protocol ports and operation ports. These ports enable more complex
information to go through the port than a flow port can. The flow port allows only unidirectional data flow. Protocol
ports enable a complex conversation between components based on a protocol. Operation ports represent typical
request/response or call/return operations. Protocol ports and operation ports are boxes going through the
package boundary box. In Figure 21-13, Responder and Initiator are protocol ports.
You may also design the choreography of port activities, or the order in which actions of the Process Component's
ports do something, such as sending or receiving messages or initiating subprotocols. The CCA Profile specifies
extensions to UML State Machine and Activity diagrams to enable modeling of port choreography.
A ProcessComponent can have a Property definition, notated at the bottom of the ProcessComponent symbol.
You use this box to specify any configuration parameters of the component when it is used. You specify the name,
type, and default value (if any) of the configuration parameter in separate cells. You may specify more than one
configuration parameter, by adding additional rows.
The type of the ProcessComponent is represented as an icon to the right of the name in the ProcessComponent
package - in Figure 21-13, a generic "t" for type is notated.
The ProcessComponent notation describes what the ProcessComponent looks like to the outside world. To model
its behavior, you model the composition of the ProcessComponent inside the symbol. The ProcessComponent
may include subcomponents-each is called a Usage. When a ProcessComponent is made up of subcomponents,
it is considered a Composite Component. Within a Composite Component, you model how the components are
used. Figure 21-14 shows a Composite Component with internal Usage components.
Figure 21-14: Composite Component notation containing internal Usage ProcessComponents.
The CCA Profile also introduces the concept of Community Components, and specifies a notation for them. The
notation is similar to the Composite Component symbol, but without the port boxes. A Community Component is a
model of how a set of large-grain components works together for some purpose.
As an alternative to the notations defined in the CCA Profile, you may also use normal UML notations, applying
appropriate stereotypes. For example, the ProcessComponent notation may be replaced by a class of stereotype
ProcessComponent, with associations to classes representing its ports, discerned by stereotypes flow port,
protocol port, and operation port. The composition of Composite Components and ProcessComponents may
be modeled using Collaboration diagrams, with appropriate extensions specified by the CCA Profile.
Business Process Profile
The Business Process Profile specifies extensions to UML to model business processes in the context of the
components and entities described in the other profiles of CCA. The profile supports the modeling of business
processes, subactivities, individual tasks, iterations of tasks, time expressions such as deadlines and durations of
tasks, and so forth. It specifies three main model elements:
BusinessProcess
CompoundTask
Activity
A BusinessProcess represents a complete process specification. It contains CompoundTasks, which contain
activities. You may represent a BusinessProcess by a ProcessComponent symbol as described in the previous
section.
Activities are the most elemental pieces of work required to complete a process. You model activities in terms of
who is responsible for them, who performs them, what artifacts they work on or produce, and their pre- and post-
conditions. CompoundTasks are containers for a set of activities and DataFlows used to interconnect them.
The Business Process Profile introduces a notation for Activities, and for ProcessRoles that interact with them, as
shown in Figure 21-15. Similar to a ProcessComponent, the notation used is a derivative of UML's subsystem
package notation. An icon that looks like a box with a lollipop coming out of the top is used to denote that the
package represents an activity; it is placed to the right of the package name in the name tab, also shown in Figure
21-15. Boxed arrows drawn into and out of the package symbol represent ProcessMultiPorts, with the horizontal
lollipop symbol within them representing individual process flow ports. There are three types of port groups:
Figure 21-15: Notation of a Business Activity as specified by the Business Process Subprofile of the EDOC.
Boxed arrows with rectangular edges, which represent synchronous port groups.
Boxed arrows with a rounded side, which represent asynchronous port groups.
Boxed arrows with a triangular side, which represent exception groups.
ProcessRoles are drawn as octagons and are attached to the Business Activity by associations - by
performedBy, usesArtifact, or responsibleFor associations.
The Business Process Profile also introduces a notation for a CompoundTask. It is similar to an Activity, but with no
ProcessRoles attached. It is denoted by a special icon to the right of the name in the package's name tab-the icon
is that of two boxes with a flow arrow between them, as shown in Figure 21-16.
Figure 21-16: Example of a CompoundTask that contains internal Activities.
The Business Process Profile presents several patterns of commonly occurring CompoundTasks. Figure 21-16
shows an example of one of these patterns, and at the same time is an example of a typical CompoundTask, and
how it is a container for a set of Activities. This particular CompoundTask shows the modeling of a while loop.
Entity Profile
The Entity Profile specifies extensions to UML to model entity objects as components. At a base level, data
modeling is enabled through application of stereotypes such as entity applied to classes, and stereotypes such as
key attribute, key element, and foreign key are applied to class attributes. At a higher level, new concepts are
introduced, such as EntityRole, which extends an entity based on the role it has in a business situation, and
DataManager, which specifies port access for entity components.
Events Profile
The Events Profile specifies extensions to UML that can be used to model event-driven systems. This is an optional
subprofile of the ECA Profile. It provides various stereotypes, tagged values, and constraints to enable modeling of
event-driven process architectures, and publish-and-subscribe information architectures.
Relationships Profile
The Relationships Profile describes extensions to the UML core facilities that support the need for rigorous
relationship specification in general and in business modeling and software modeling in particular.
UML Profile for Schedulability, Performance, and Time
The UML Profile for Schedulability, Performance, and Time provides extensions to UML to support the modeling of
all kinds of real-time systems. The profile supports a broad range of real-time systems, including soft real-time
systems, hard real-time systems, distributed and centralized systems, fault-tolerant and non-fault-tolerant systems,
and so forth. The profile is described in detail in the document titled UML Profile for Schedulability, Performance,
and Time (OMG document ptc/02-03-02). This section provides a brief overview of the profile.
The profile is broken down into major areas of real-time analysis, as specified in the package structure shown in
Figure 21-17.
Figure 21-17: Structure of the Schedulability, Performance, and Time Profile.
General Resource Modeling Framework
The General Resource Modeling Framework is the core framework for modeling real-time systems with UML. It
contains three subprofiles: Real-Time Resource Modeling, Real-Time Concurrency Modeling, and Real-Time
Time Modeling.
The Real-Time Resource Modeling Profile specifies extensions to UML models to capture information concerning
time and time values, events in time, time-related stimuli, and timing mechanisms such as clocks and timers.
Schedulability Analysis
The Schedulability Analysis (SA) Profile provides extensions to model and calculate the schedulability of a system,
including its ability to meet all of the deadlines defined for individual scheduling jobs. Stereotypes and tagged
values are applied to a broad range of UML models, including Class, Sequence, and Activity diagrams. All
stereotypes and tag values of the schedulability profile are prefixed with an "SA" to avoid confusion with tag values
of other profiles. By applying the SA Profile and inputting appropriate information into the models, you typically
analyze the system under several scenarios using different parameter values for each to see how the system can
be improved.
Performance Analysis
The Performance Analysis Profile provides extensions to estimate the performance of a system, and to run
simulation against UML models. Stereotypes and tagged values are applied to UML Class, Collaboration,
Sequence, and Activity diagrams. Simulation enables you to see how the system can be improved by identifying
bottlenecks or critical resources. All stereotypes and tag values of the performance analysis profile are prefixed
with a "PA" to avoid confusion with tag values of other profiles.
UML Testing Profile
The UML Testing Profile extends UML so that you may model information on testing your systems. The
specification provides both a UML Testing Profile and an alternative MOF metamodel for testing. The profile is
described in detail in the document titled UML Testing Profile (OMG document ad/01-07-08). This section provides
a brief overview of the profile.
The UML Testing Profile specifies a set of stereotypes, tagged values, and constraints that are applied to Class,
Collaboration, Sequence, and Activity diagrams to specify the structure of tests and the workflow of specific tests. It
is applied to enable you to specify tests at various levels, including unit level test cases, integration and system-
level tests, and cross-enterprise level tests.
The profile itself is divided into five subpackages (shown in Figure 21-18):
Figure 21-18: Basic structure of the UML Testing Profile. Each package contains the metamodel of a profile
for a specific area of testing.
Test Architecture
Test Data
Test Behavior
Time Concepts
Test Deployment
For a UML modeling tool to support the Testing Profile, it must at least support the Test Architecture, Test
Behavior, and Test Data packages. Support of the Time Concepts package and the Test Deployment package is
optional.
In the Testing Profile specification, each of these packages contains a metamodel expressed as a Class diagram,
which presents the metamodel extensions. The following sections provide brief overviews of the extensions
specified in these packages.
Test Architecture
The Test Architecture package and metamodel specify the structural aspects of a test suite. At the heart of this is
the test suite, which specifies how the test cases are executed. Test suite is specified as a stereotype on a
classifier. Figure 21-19 shows a class modeled as testSuite for an Online_Reservation form. The
Online_Reservation test suite contains four test cases. Each test case is actually a method of the
Online_Reservation testSuite class.
Figure 21-19: Class symbol stereotyped as a Test Suite with four test cases.
A test component is specified as a stereotype on a class. You may use a test component to specify low-level test
behavior, such as test scripts. In Figure 21-19, the class Customer_Emulator is specified as a test component,
which provides an e-mail address for testing.
Two important concepts specified by the test architecture package are the System Under Test (SUT) and the
Arbiter. The SUT is a stereotype applied to a system. In the preceding example, the SUT would be an Online
Reservation system. An arbiter is an interface that defines the operations used to assign and return verdicts. The
verdict can be Pass, Fail, Inconclusive, or Error. Error is an error condition of the test system itself. The Testing
Profile provides an arbitration algorithm, and users can define their own.
The Test Architecture package also specifies test configurations and utility parts, or miscellaneous components of
the test system.
Test Data
The Test Data package and metamodel specify the structure of data sent to and processed in a test. This includes
Wildcards (special symbols that represent values or ranges of values, such as ? and *), Data Pools (a collection of
values used to execute test cases), Data Partitions (a logical value for a parameter used in test cases, such as
valid e-mail addresses), and Coding Rules (for languages such as XML, so that the test system can interface with
the SUT).
Test Behavior
The Test Behavior package and metamodel specify the stimuli to a test, activities performed during a test, and
observations of a test. At the heart of this package is the test case-defined as a testCase stereotype on an
operation that provides a tagged value on the operation of test objective. A test case always returns a verdict.
Figure 21-19 shows that four test cases are defined for the Online_Reservation test case. All have a return of
Verdict, which, as previously mentioned, can have a value of pass, fail, inconclusive, or error. Verdict is defined as
an enumerated list in the Test Behavior package.
Each test case has an Objective (not shown in the diagram). A test objective is normally given by a textual
description.
The Test Behavior package also specifies a Stimulus, which is the test data sent to the SUT to activate tests, and
an Observation, which is the test data received from the SUT in response to stimuli.
The package also includes Test Control, which specifies how test cases are to be executed in a test suite; Test
Invocation, which enables you to invoke a test case with specific parameters or within a specific context; and
Coordination, which specifies ordering mechanisms and messaging to manage concurrent testing. It also specifies
test traces, default values, and various actions such as logging and validating the test results.
Test Deployment
The Test Deployment package and metamodel extension are optional for tool vendors to support. They specify the
deployment of test artifacts and components to physical nodes or target platforms. This enables you to model the
deployment of test components.
Time Concepts
The Time Concepts package and metamodel specify time constraints and time observations for test execution.
This enables you to quantify test execution and to model timed execution of test cases.
The Web Application Extensions (WAE)
The Web Application Extensions have not been submitted as a potential profile to OMG. However, they have
become popular for modeling Web applications and can be considered an informal profile. They are put forth by
Jim Conallen in his book Building Web Applications with UML (Addison Wesley Professional, 2002), and appear in
other books in the field. The WAE defines a set of stereotypes, tagged values, and constraints that enable
modeling of Web applications. Table 21-3 lists stereotypes that may be applied to classes (on Class, Component,
and Use Case diagrams), components (on Component diagrams), and object lifelines (on Sequence diagrams).
Table 21-3: UML Profile for Web Application Extensions
Type Stereotype Description Icon
Class ServerPage A server page is a Web page that has
scripts executed by the server.
Examples are a Java Server Page
(JSP), an Active Server Page (ASP), or
a PERL script page. A constraint on a
server page is that it can only interact
with objects on the server. A tagged
value for a server page is the language
that is used.
Class Client Page A client page is a simple HTML Web
page. It contains data and presentation,
and any local scripts. There are no
constraints but three tagged values of
note are TitleTag (the title of the page),
BaseTag (the base URL), and BodyTag
(the HTML <body> tag that sets fonts
and background colors).
Type Stereotype Description Icon
page. It contains data and presentation,
and any local scripts. There are no
constraints but three tagged values of
note are TitleTag (the title of the page),
BaseTag (the base URL), and BodyTag
(the HTML <body> tag that sets fonts
and background colors).
Class Form A form is a set of fields that users fill
out, including text boxes, radio buttons,
etc. The attributes of a form class
are the names of the fields. A form
class has no operations; operations that
interact with the form belong to the
page on which the form sits.
Class Frameset A frameset represents a group of Web
pages contained in a frame. It has no
constraints and two tagged values:
rows, which is a string of comma-
separated values of row heights, and
cols, which is a string of comma-
separated column widths.
page. It contains data and presentation,
and any local scripts. There are no
constraints but three tagged values of
note are TitleTag (the title of the page),
BaseTag (the base URL), and BodyTag
(the HTML <body> tag that sets fonts
and background colors).
Class Form A form is a set of fields that users fill
out, including text boxes, radio buttons,
etc. The attributes of a form class
are the names of the fields. A form
class has no operations; operations that
interact with the form belong to the
page on which the form sits.
Class Frameset A frameset represents a group of Web
pages contained in a frame. It has no
constraints and two tagged values:
rows, which is a string of comma-
separated values of row heights, and
cols, which is a string of comma-
separated column widths.
Type Stereotype Description Icon
Class Target A target is a window in which a web
page can be displayed. For example,
for a hyperlink, you can specify that the
targeted page is displayed in a new
window, in the same frame, or in a
parent frame. There are no tagged
values for this stereotype.
Class JavaScript
Object
When working with JavaScript, you can
use objects of the Document Object
Model (DOM), such as the Window
object, and its Document object to
perform tasks. You can also create
your own generic objects. Such
JavaScript objects are represented by a
class of stereotype JavaScript
Object. A specialized icon is not
specified for a JavaScript class.
Class ClientScript
Object
A ClientScript Object is a collection of
client-side scripts, which are commonly
used functions, placed in a separate
file. They are invoked by a separate
request by the browser.
Component Web Page A Web Page is an HTML-formatted
page that contains HTML text code, and
Class Target A target is a window in which a web
page can be displayed. For example,
for a hyperlink, you can specify that the
targeted page is displayed in a new
window, in the same frame, or in a
parent frame. There are no tagged
values for this stereotype.
Class JavaScript
Object
When working with JavaScript, you can
use objects of the Document Object
Model (DOM), such as the Window
object, and its Document object to
perform tasks. You can also create
your own generic objects. Such
JavaScript objects are represented by a
class of stereotype JavaScript
Object. A specialized icon is not
specified for a JavaScript class.
Class ClientScript
Object
A ClientScript Object is a collection of
client-side scripts, which are commonly
used functions, placed in a separate
file. They are invoked by a separate
request by the browser.
Component Web Page A Web Page is an HTML-formatted
Type Stereotype Description Icon
Component Web Page A Web Page is an HTML-formatted
page that contains HTML text code, and
may also contain scripts that run on the
client browser, and/or on the server. It
may also contain a compiled module
that loads on the server. You specify
the full URL or path of the Web Page
as a tagged value.
Component ASP Page An Active Server Page (ASP) Page
implements ASP code on the server.
You specify the full URL or path of the
ASP Page as a tagged value.
Component JSP Page A Java Server Page (JSP) Page
implements JSP code on the server.
You specify the full URL or path of the
JSP Page as a tagged value.
Component Servlet A Servlet is a Java component that runs
on the server. You specify the full URL
or path of the Servlet as a tagged
value.
Component Web Page A Web Page is an HTML-formatted
page that contains HTML text code, and
may also contain scripts that run on the
client browser, and/or on the server. It
may also contain a compiled module
that loads on the server. You specify
the full URL or path of the Web Page
as a tagged value.
Component ASP Page An Active Server Page (ASP) Page
implements ASP code on the server.
You specify the full URL or path of the
ASP Page as a tagged value.
Component JSP Page A Java Server Page (JSP) Page
implements JSP code on the server.
You specify the full URL or path of the
JSP Page as a tagged value.
Component Servlet A Servlet is a Java component that runs
Type Stereotype Description Icon
Component Servlet A Servlet is a Java component that runs
on the server. You specify the full URL
or path of the Servlet as a tagged
value.
Component Script
Library
A Script Library is a component that
provides a library of functions and
subroutines that can be used by other
components. You specify the full URL
or path of the script library as a tagged
value.
<Day Day Up>
Component Servlet A Servlet is a Java component that runs
on the server. You specify the full URL
or path of the Servlet as a tagged
value.
Component Script
Library
A Script Library is a component that
provides a library of functions and
subroutines that can be used by other
components. You specify the full URL
or path of the script library as a tagged
value.
<Day Day Up>
<Day Day Up>
Summary
In this chapter, you learned:
The UML metamodel is extended with three basic devices - stereotypes, tagged values, and constraints.
When you group a set of these extensions to model a specific platform or domain, you create a profile. The
profile is regarded as one overall extension to the UML. You can apply a number of profiles to your modeling.
A profile is considered a lightweight extension. It can be thought of as creating a new dialect to the Unified
Modeling Language.
A more heavyweight alternative to a profile is to extend the MOF that UML is built on, creating a new
metamodel for a particular modeling domain or platform. This can be thought of as creating a new language
related to UML.
The UML specification details how to build a profile. It also provides example profiles.
You can build your own profile, and some profiles have been developed in the industry, introduced by
modeling tool vendors or book authors, for domains such as data modeling and Web applications. These
profiles are in common use, but they are not officially adopted by the OMG.
The OMG has adopted a number of standard profiles for specific platforms and domains of modeling, and is in
the process of adopting more.
OMG-adopted profiles generally offer both a lightweight UML Profile and an alternative MOF-based
metamodel extension.
A stereotype is a type that you may apply as a property value to a UML element to extend its properties and
slightly alter its semantics.
Stereotypes may be applied to all UML element types, such as Classes, Use Cases, Components,
Associations, Dependency relationships, and so on.
Once you apply a stereotype to a model element, additional properties or tagged values may become
available in the class definition.
A tagged value is an extra property that can be added to a UML element, so that you can specify additional
information that you normally couldn't.
Constraints enable you to specify rules and restrictions on model elements in UML.
One of the most visible aspects of profiles is the icons you can use to represent different UML classifiers,
based on their stereotype.
You may model a profile using UML itself. You use a Class diagram to model the structure of a profile. When
you do so, you are performing metamodeling.
A profile is applied to a package.
The UML specification provides a very simple profile for Enterprise JavaBeans.
The UML Profile for Software Development Processes is provided as an example profile in the UML
specification itself. The profile is used with the Rational Unified Process (RUP), and has its origins in the work
of Ivar Jacobson. It is responsible for introducing the commonly used boundary, control, and entity
class stereotypes and their associated icons.
The UML Profile for Business Modeling is provided as an example profile in the UML specification itself. It is
responsible for introducing the commonly used worker, internal worker, case worker, and entity
class stereotypes and their associated icons.
Enterprise Application Integration (EAI) involves building new applications by coupling existing applications that
may be built in different languages and exist on different platforms. The UML Profile for EAI specifies
mechanisms that enable you to model this coupling of existing applications.
The Enterprise Distributed Object Computing (EDOC) Profile presents extensions to UML to enable you to
model the integration of your enterprise business workflow, applications, and databases. It introduces the
concept of business process components and how they can be modularly built and integrated with application
components. One of its purposes is to enable a business component marketplace.
The UML Profile for Schedulability, Performance, and Time provides extensions to UML to support the
modeling of all kinds of real-time systems.
The UML Testing Profile extends UML so that you may model information on testing your systems.
The UML Testing Profile is applied to enable you to specify tests at various levels, including unit-level test
cases, integration and system-level tests, and cross-enterprise level tests.
<Day Day Up>
<Day Day Up>
Chapter 22: XML Metadata Interchange
Overview
The XML Metadata Interchange (XMI) is a specification created by the OMG and intended to enable easy
interchange of information between modeling tools supporting the UML metamodel, and also any metadata
repositories that are based on the Meta Object Facility (MOF).
XMI is based on the Extensible Markup Language (XML) of the W3C, which has become the industry standard
format for information exchange across distributed environments.
Its primary objective is to enable, for the first time, exchange of UML models between modeling tools. Moreover,
third-party vendors can use XMI output from any UML modeling tool that can be manipulated external to the tool,
to create code (Java, Visual Basic, and so forth). XMI does not only pertain to UML, it can interchange information
based on any MOF-based metamodel, such as the Common Warehouse Metamodel (CWM). In this chapter, you
will receive an overview of XMI, be presented with the core information you need to know about XML, and take a
look at the underlying UML architecture and how XMI is generated. You will examine a case study in both XMI 1.0
and 1.1, and be introduced to the Diagram Interchange Specification.
<Day Day Up>
<Day Day Up>
Introduction to XMI
XMI enables output of UML information from modeling tools and object repositories into a standard, easily
transportable format, based on industry-standard XML. This offers two very important benefits to UML. First and
most popularly, this enables modeling tools to exchange UML model information, as long as they support export
and import of XMI. Just as importantly, it enables third-party vendors to manipulate XMI data output from modeling
tools and object repositories, and transform it into other forms, including code (Java and other languages).
Why exchange information between tools?
Many organizations today need to exchange information between modeling tools. There are a number of reasons
for this-the corporation may be using more than one tool; it may be working with vendors that are using a different
tool than the one employed in the organization; or it may be switching tools. The following paragraphs take a look
at these scenarios in turn.
A corporation may be using more than one modeling tool because it has made a deliberate decision to use the
best tool for each type of modeling job. There are a number of tools on the market today that offer expertise in
different areas of modeling. An organization may use one tool more adept at analysis for analysis, and another tool
more adept at code generation for design.
For example, some UML modeling tools are better at code generation and reversal-some tools literally sit on the
code, so that a change to the model is directly reflected in the code and vice versa. Other tools provide extensive
analysis capabilities, wherein the models are stored in a repository or underlying database so that multiple users
can work on the same models at the same time, with access control features built in. Some tools provide
integration with other methods, such as traditional business modeling, data modeling, or structured analysis. Very
often a company will have business analysts using one tool, while programmers use another. That company might
want the business models or data models being developed in the one tool to get mapped to UML models, and
then synchronized with the UML models being created by developers in the other tool.
Sometimes a company or division of a company has standardized on one tool, but its vendors, or other
departments, are using a different tool, and they may require receipt of models that work with their tool. And at still
other times, a company may simply be switching the tool that it uses, and wants to get all of its information out of
the old tool and into the new one.
Exchange of information between modeling tools is not a new idea - it's been around for as long as modeling tools
have, which dates back about 20 years. There have been numerous attempts in the past to develop a standard
interchange format for information exchange, including the CASE Data Interchange Format (CDIF), the Interface
Definition Language (IDL) of the Integrated Computer-Aided Manufacturing (ICAM) DEFinition IDEF methodology,
and recent work by the Metadata Coalition (Meta Data Interchange Specification).
Most of these efforts have been unsuccessful or, at best, minimally successful for a variety of reasons. Through
the years, most modeling tools have supported various methods, including numerous object-oriented techniques,
business modeling techniques, structured analysis and design techniques, and data modeling. The wide range of
techniques, plus the wide array of differing definitions and properties that each modeling tool supported, have
made establishing a common metamodel for exchange difficult. Additionally, when an interchange format such as
CDIF became available, no tool vendors were willing to modify their tools to completely support it, or if they did,
they did not think that it was in their best interests to provide both output and input of the standard into their tools. If
they supported the standard, they were more apt to make sure input into their tools was good, but not output, so
that customers would be less inclined to use the output to move information to another vendor's tool.
XMI has a high chance of being very successful for a number of reasons. First, UML is becoming the defacto
standard for systems and application modeling, so there is one common source of information to exchange.
Second, UML's underlying metamodel is a highly defined specification, maintained by the OMG, which is almost
universally accepted as a non-partisan specifications body. Third, that metamodel may be extended, and XMI can
reflect those extensions. This means that extra definitions and properties that have been added to a particular tool
can be expressed in the XMI and interchanged between tools, as long as both tools support the ability to add UML
extensions (stereotypes, tagged values, and constraints) as UML specifies that they must. Finally, the UML
metamodel is actually built on top of a more generalized metamodel, called the Meta Object Facility (MOF). UML
is only one of many metamodels that are built or are being built on top of the MOF, so the same principles that
apply to UML model information also apply to the exchange of information for other metamodels, such as the
Common Warehouse Metamodel (CWM), which enables the exchange of data warehousing information.
What needs to get exchanged
When exchanging information between modeling tools, two basic artifacts need to be exchanged: the UML model
information and the diagrams.
UML model information includes the package structure of the models, and all of the information concerning the
models themselves: classes and their underlying definitions, their attributes and methods, class associations,
inheritance structures, dependencies, use case definitions and their relationships to actors and other use cases,
object definitions, and messages passed between objects (as seen on a Sequence or Collaboration diagram),
state definitions and transitions, component definitions and dependency relationships, node definitions and link
relationships, and so forth.
Diagrammatic information consists of the diagram itself; its name; what UML model elements are represented on it
as symbols; exactly where those symbols are positioned (in X, Y coordinates); the colors, fonts, and exact shapes
used for the symbols on the diagram; how lines on the diagram are routed; the thickness and style of the lines, and
any other information concerned with presenting symbols on a diagram workspace.
Obstacles to tool interchange
The XMI specification was originally constructed as an information interchange. No diagrammatic information is
included in the specification. The OMG has addressed diagrammatic information with the Diagram Interchange
specification, detailed later in this chapter.
This means that modeling tools that have built XMI interchanges based on XMI specifications such as XMI 1.0 or
XMI 1.1 can only interchange model information. For many users, this is good enough. If a modeling tool supports
the underlying semantics of the UML metamodel, then a user can import UML information via XMI, manually
create a diagram in the modeling tool, and place (or drag) appropriate UML elements (a number of classes, for
example) onto the diagram workspace, and relationships should be drawn automatically, thereby creating the
diagram. However, although the diagram would contain the drawn information, it most certainly would not look like
the original diagram in the first tool. Moreover, the user would need to reference the first tool to find out how many
diagrams there were, what package they were in, what each diagram's name was, and what model elements were
contained in each one, and so forth. That is a lot of manual work that could be automated using a tool scripting
language such as VBA, but that would defeat the purpose of XMI, which is to enable easy exchange of information
between modeling tools. Support of the Diagram Interchange specification solves this problem.
A second problem is that most if not all UML modeling tools do not support the full UML specification. UML has a
very large specification, and most UML modeling tools do not allow you to draw everything defined in the spec, or
enable you to define all properties contained in the specification. In addition, the UML spec is constantly changing,
and it takes time for modeling tool vendors to make product changes to support new features in the specification.
This may be okay if you are modeling in a tool - if the feature isn't there, you don't use it. But exchanging
information via XMI is another matter. If you have invested the time to model something in one tool, you must make
sure that the other tool supports this functionality, or can be extended to support this functionality, so that the
information can be exchanged.
Model-driven applications
One of the major initiatives of the OMG is model-driven applications (MDA). In essence, this means driving code
creation through modeling. With MDA, you perform analysis and design of systems before coding, and automate
the coding of those systems from the models. To do this, the models themselves must have enough rigor in them
to support real code generation, and the modeling tool must support good code generation. XMI is one enabling
technology for MDA in that tools that support it generate UML models to a standard form that can be manipulated
by third-party code creation tools to map the UML models to any coding language.
Using XSLT to transform XMI
After UML models are mapped to XMI, eXtensible Stylesheet Language Transformations (XSLT) becomes a
natural fit for transforming the XMI into other useful forms. Using XSLT you can transform the structure and format
of an XMI document. This becomes a natural mechanism to map UML models to and from other languages, such
as Java, Visual Basic.NET, and C#.
What you need to know
To be able to read, understand, and manipulate the data in XMI, you must understand the basics of the XML
language. You also need to be familiar with the UML architecture, and to understand how XMI is structured so you
can navigate the XMI itself. You should also be familiar with tools available to examine XMI. Later in this chapter, I
review tools that enable you to discover, understand, and correct problems in XMI.
<Day Day Up>
<Day Day Up>
The XMI Specification
The XMI specification includes the following:
XML Document Production Rules for encoding MOF-based metadata and producing an XMI instance
document. These rules can be applied in reverse to create models from XMI.
XML Document Type Definition (DTD) Production Rules for transforming MOF-based metamodels into XML
DTDs. Using these rules, vendors can create a DTD for any MOF-based repository. They may create their
own UML.DTD, used to validate that the XMI generated from a modeling tool is correct. They may also create
a DTD for any other MOF-based repository.
Prebuilt DTDs for UML and MOF.
XML Schema Production Rules, which are included in the newest XMI specifications, XMI 1.3 and XMI 2.0.
Using these rules, vendors can create a schema for any MOF-based repository. They may create their own
schemas for UML, used to validate that the XMI generated from a modeling tool is correct.
The Unisys Extensions
Unisys Corporation has built an XMI interface to the Rose modeling tool. The Unisys toolkit, offered as a free
add-in to Rose, provides XMI generation and importing facilities, and introduces extensions, referred to in the
XMI world as the Unisys extensions, to enable exchange of diagrammatic information, in lieu of lack of
formalized standards existing for diagrammatic information. Some tool vendors have incorporated these
extensions into their XMI.
Subcommittees, or revision task forces (RTFs) and finalization task forces (FTFs), of the OMG are continuously
working to improve the XMI specification. In addition, it is mandatory that every time the UML specification is
updated, the XMI specification also be updated to reflect changes to the UML metamodel. Therefore, for every
version of UML, there is a corresponding version of XMI. However, the version numbers of the specifications do not
currently correspond:
UML 1.3, MOF 1.3, XMI 1.0
UML 1.4, MOF 1.4, XMI 1.1-XMI 1.2
UML 1.5, MOF 1.5, XMI 1.3
UML 2.0, MOF 2.0, XMI 2.0, Diagram Interchange specification
The Diagram Interchange specification has been adopted at the same time as UML 2.0. It is the definitive standard
for exchange of diagrammatic information between modeling and graphic tools, and is explained in more detail
later in this chapter.
The XMI 1.0 spec is the most commercially supported spec on the market today. It is the lowest common
denominator.
The XMI 1.1 spec provided a significant change over XMI 1.0. Version 1.0 relies on nested elements with fully
qualified namespaces, while version 1.1 makes use of namespaces and attributes to make XMI instance
documents much more compact and easier to read. XMI 1.2 is a minor revision to XMI 1.1.
The XMI 1.3 and XMI 2.0 specs introduce XML schema to validate instance documents, whereas previous specs
relied upon a UML.DTD to validate the XMI instance document. The XMI-1.3 and XMI 2.0 specs came out at about
the same time-XMI 1.3 is intended for use with UML 1.4, and XMI 2.0 is intended for use with UML 2.0.
<Day Day Up>
<Day Day Up>
Creating XMI from MOF
OMG originally intended MOF to be the technology to define metadata and represent it as Common Object
Request Broker Architecture (CORBA) objects. OMG's design was to use CORBA Interface Definition Language
(IDL) to enable exchange of objects in a distributed environment. An IDL mapping is specified for MOF that maps it
onto a corresponding set of CORBA IDL interfaces.
Looking at it another way, the original intent was to have CORBA IDL act as the mechanism to transfer information
between MOF-based repositories. However, CORBA never caught on in the industry as much as many people
thought it would. XMI offers key advantages over CORBA IDL that increase its chances of catching on.
Like CORBA IDL, XMI enables the interchange of MOF metadata that exists in a MOF-based repository. CORBA
does this via IDL interfaces using ORB-to-ORB connectivity to transfer information. XMI uses the Stream-based
Model Interchange Format (SMIF) to enable stream-based interchange of metadata. More precisely, XMI
exchanges MOF metadata in a serialized form within an XML document and accompanying DTD. There is no
need for ORB-to-ORB connectivity to transfer the information. There is no need for middleware. You may
exchange information from one MOF repository to another by simply sending the XML document with
accompanying DTD via e-mail or any other vehicle that can transfer text documents. As long as one MOF
repository can export XMI, and the receiving MOF repository can import XMI, you can exchange information.
Because of this, XMI increases the availability of data stored in MOF-based repositories, and therefore increases
the usefulness and popularity of the MOF itself.
Moreover, XMI can be used to exchange information between repositories that are not MOF-based. A mapping can
be created from the proprietary metamodel of the repository to the MOF metamodel when generating XMI.
Creating XMI from MOF
The XMI specification's DTD Production Rules enable anyone, but more specifically programmers, to create a
DTD from the MOF. A DTD representing any MOF-based metamodel may be created. UML is only one example of
a MOF-based metamodel. The XMI 1.1 specification provides three sets of DTD Production Rules:
Rule Set 1 provides rules to create a simple DTD.
Rule Set 2 provides rules to create a DTD, and uses XML entities for convenience and compactness. Entities
are an XML structure described later in this chapter, in the XML overview section.
Rule Set 3 provides rules to create a DTD using hierarchical grouped entities.
The UML.DTD is created by applying the XMI production (or generation) rules to the MOF.
NoteXMI enables the interchange of UML information between modeling tools, and the translation of UML
models to code. But it does more than that. To get a complete understanding of what XMI does, you
need to know a little bit of the architecture of UML and the Meta Object Facility (MOF). If you need a
refresher course on the architecture, turn back to Part I and skim through Chapters 1 and 2.
How XMI, MOF, and UML fit together
Since the UML metamodel is a MOF-based metamodel, applying the XMI DTD Production Rules on the UML
metamodel creates the UML.DTD. Applying the Document Production Rules to a UML model creates a
corresponding XMI instance document. The UML.DTD reflects the UML metamodel, and specifies the structure
and rules of the XMI instance document. The XMI instance document contains the UML model information in a
textual, serialized format. Information in this format is easily transferred. This information can be accurately
exchanged between modeling tools-vendors can create a mapping from XMI into their own metamodels to import
UML information into their tools without having MOF implemented. The XMI information can also be transformed to
other formats, such as Java, using a language that can transform the XML, such as XSLT.
Other metamodels
The extensible architecture of MOF, combined with the convenience of using XMI to interchange information
between MOF-based repositories, has caused the OMG to begin creating metamodels for other uses, such as the
Common Warehouse Metadata (CWM) metamodel for exchange of data warehouse information. Once an MOF-
compliant metamodel for data warehousing can be agreed upon, how to map that metamodel to XMI is already
specified, and can be easily automated.
<Day Day Up>
<Day Day Up>
Basic Primer on XML
This section covers the basic XML information you need in order to understand XMI. For further information, there
are many books available that cover the topic in detail.
What is XML?
XML is a specification of the World Wide Web Consortium (W3C). It is a subset of the more powerful Standardized
Generalized Markup Language (SGML). SGML, which has been around since the 1960s, was standardized by the
International Organization for Standardization (ISO) in 1986 as the language for defining markup languages.
SGML enabled authors to create a markup language within which they could define the elements and attributes in
the language, thereby enabling them to create their own tags that relate to their content. The definition of the
created markup language is kept in a Document Type Definition (DTD), which has to be provided with the SGML
document for the custom-created tags within the language to be understood.
The W3C created XML expressly for use on the Web. XML is a simplified version of SGML, eliminating many of the
aspects of SGML that are not essential for Web use.
There are a number of important things to know about XML:
The actual information or data is specified within tags in a text document, often called an XML instance
document. This document normally has an .XML extension.
The rules for the structure of the instance document are provided in a Document Type Definition (DTD) file.
These rules are often called the grammar. This file normally has a .DTD extension.
In XML, you can create your own tags, and specify their meaning. This is an important feature of XML, one that
makes it perfect as a language for exchanging UML and MOF-based information.
XML data is structured in a tree-based hierarchy. When navigating the information, either in the instance
document or the matching DTD, you find yourself navigating the tree structure.
Instance documents
An instance document is the file that contains the actual data, represented in XML form, within tags. The file almost
always has an extension of .XML, although this is not mandatory. The instance document contains a reference to
the DTD that specifies how the data is structured.
For UML's XMI, the instance document carries the information concerning the model elements. So if you modeled
a class Order within a package Order_System, and the class had attributes Order_Number, Part_Number,
and Order_Quantity, that information would be modeled in the instance document. The fact that a package
contains a class that contains attributes is contained in the DTD.
DTDs
The Document Type Definition, or DTD, specifies the syntax of an XML instance document. It defines the different
kinds of elements that can appear in the instance document, and the way that elements may be nested in the tree
hierarchy.
The DTD can be included in the XML instance document, or a reference to it can be specified in the top of the XML
instance document.
Normally, the DTD is housed in an external file with a .DTD extension, and a reference to it is provided at the top of
the instance document using a Universal Resource Identifier (URI) such as http://www.xmi.org/UML.DTD.
It is advantageous to separate the instance document from the DTD in this fashion. The reason for this is that an
instance document can be read and used without the accompanying DTD. In most cases, you want to have the
accompanying DTD so that you can validate that the instance document is correct. But there are other cases
where the user can assume the instance document is correct, and use the information in it without using the DTD.
To save transmission bandwidth, you can send someone an instance document without the accompanying DTD,
and he can still use the data.
XML schemas
An XML schema is an alternative, and newer, technology to DTDs for validating instance documents. A DTD
specifies the structure of an XML file: it gives the names of the elements, attributes, and entities that can be used,
and how they fit together. XML schemas offer a number of advantages over DTDs, most importantly the ability to
specify element content in terms of data types, including range checking. This enables the schema to provide the
criteria for validating some of the content of elements.
A typical example is that of an Address element, which might contain sub-elements such as name, street address,
city, state, zip code, and so forth. An application that receives an instance document containing addresses would
want to know that all Zip Codes, for example, are nine digit numbers, or that all states are two characters that can
only be one of 50 values specified by an enumerated list (AL, NY, NJ, and so on). XML schemas enable you to
specify such data types. The advantage is that the instance document itself can be checked for data type validity
by an XML processor before being provided to any application that must work on the data. This reduces the work
that programmers of applications have to do-they won't have to write code that would perform such checks.
XML document correctness
As you learn XMI, and speak in the world of XML, the first thing you will need to know are the levels of correctness
that an instance document can attain. People who "speak" XML toss around these terms often.
There are two levels of correctness that an instance document can attain: well formed and valid.
Well-formed XML documents
A document is well formed if it follows these three rules:
It must contain one or more elements.
It must contain a uniquely named element, known as the root element, no part of which appears in the content
of any other element.
All other elements within the root element must be correctly nested.
If you open an XML instance document in any modern browser, the browser automatically checks the document to
see if it is well formed. If it is not, the browser reports this fact to you.
Valid XML documents
A document is valid if it conforms to the rules and structure specified by its DTD or schema. Most browsers on the
market today do not check to see if an instance document is valid. They open the document just fine, even if the
document is not valid.
This coincides with what we said -previously: you do not have to provide the accompanying DTD or schema of an
instance document to use the document. To see if an instance document validates against its DTD, you need a
special tool to parse it. There are many such tools on the market. One popular, free tool is Microsoft's XML
Notepad, which you'll see in the "Tools to Use" section at the end of this chapter.
XML elements
An element is the main structural piece of data in an XML document. An element is made up of a start tag, an end
tag, and the data in between. The tag specifies the name of the element; the name included in start tag must
exactly match the name included in the end tag (and is case sensitive). The data in between the tags is referred to
as the element's content. Here's an example of an element named Video, with simple textual data in the content.
<Video>Description of a movie video.</Video>
Elements may contain other elements, which are considered child elements. These child elements may contain
other child elements, ad infinitum. This nesting of elements within other elements creates a natural tree-like
hierarchy of XML information. Each element contains a content model that lists the other elements it can contain.
The following element, Movie, contains five nested elements that describe it in more detail: Movie_Name,
Lead_Actor, Lead_Actress, Director, and Year.
<Movie>
<Movie_Name>The Hulk</Movie_Name>
<Lead_Actor>Eric Bana</Lead_Actor>
<Lead_Actress>Jennifer Connolly</Lead_Actress>
<Director>Ang Lee</Director>
<Year> 2003 </Year>
</Movie>
XML attributes
Attributes are used to represent small, descriptive bits of information for describing elements. Attributes are
contained within the start tag of an element, after the element's name, and are followed by the equal sign (=) sign
and then the value of the attribute in quotes. For example:
<Lead_Actor age="35"> </Lead_Actor>
Attribute list declaration
An attribute list declaration enables you to constrain the range and types of attributes you use to describe
elements. The attribute list statement declares the attributes in the DTD. This information is used to make sure the
instance document is valid.
Attribute list statements generally describe four things:
The element with which the attribute list is associated.
The name of each attribute in the list.
The data types of the attributes.
The default value of each attribute.
In the following movie element example, the ATTLIST statement first specifies that the attribute list pertains to the
element movie. The next three lines specify the names of three attributes, their types, constraints, and default
values.
<!ELEMENT movie>
<!ATTLIST movie
is_DVD (yes | no) "yes"
serialNumber ID #REQUIRED
Description CDATA #IMPLIED
>
As you can see, there is an attribute named is_DVD, with a constraint (yes | no), and a constraint default
value of "yes". The attribute named serialNumber is of type ID, and it is required (#REQUIRED). The
Description attribute is of type CDATA (Character Data), and it is optional (specified by the #IMPLIED
statement).
XML entities
In XML, entities provide a mechanism for associating a name with a piece of text (generally a long piece of text that
is used repeatedly in a document) so that you can replace the text with the entity name wherever the text is found
in the XML document. This makes the XML more compact, and also makes changes more easily performed-if you
need to change the text, you only have to change it in one place.
There are a number of types of entities, including external entities (in which the replacement text resides in a text
file external to the XML document), and internal entities (in which the replacement text resides in the declaration of
the entity). The following line is an example of an internal entity:
<!Entity> entityname "Some replacement text"/>
Contrast this to an external entity, which references an external document in which replacement text is located:
<!Entity> % entityname SYSTEM
"http://www.popkin.com/customers/xxxx.xml"/>
Namespaces
Namespaces provide a uniqueness of element names. When mixing elements from different XML applications,
you are likely to encounter the same element name used for two different things. For example, an instance
document may have an element named Title referring to the title of a person in one DTD, and an element
named Title referring to the title of an HTML page from a different DTD. Namespaces enable you to use both
elements in the same instance document as long as you specify which namespace each refers to - for example,
Person:Title and HTML:Title.
Namespaces in XML are identified by a Uniform Resource Identifier (URI) or Uniform Resource Locator (URL).
This allows each namespace to be universally unique, as it needs to be if you are viewing element and attribute
names from all over the Internet. A URI is a superset of URLs. A URI is a more general way of locating a resource
than a URL, which specifies the exact physical location.
XML keywords
As you play in the world of XMI, you will need to know that the rules are specified on XMI by its DTD, through the
use of operators. Table 22-1 presents these operators, which are always expressed in Extended Backus-Naur
Form (EBNF) notation. You will see firsthand how some of these are used later in this chapter, when you examine
some sample XMI documents.
Table 22-1: Content Model Operators
EBNF symbol Meaning
(empty space) Required
' Strict ordering
| A selection or choice
+ One or more
* Zero or more
? Zero or one (optional)
() Grouping
Table 22-2 presents various combinations of elements grouped using the operators in Table 22-1. Although some
of the examples may seem straightforward, Table 22-2 can be a very handy table to reference when you are
interpreting XMI, as you will see later in this chapter. (Table 22-1 is adapted with changes from XML Applications,
Wrox Press, Inc., 1998.)
Table 22-2: Various Element Content Declarations
Content
model
Explanation
A The single element A is expected.
A | B Either A or B is expected.
A, B Two elements expected, A and B, in that order.
A, B ? Two elements are allowed. A is expected, B is optional.
(A, B, C) Three elements are expected, A and B and C, in that order.
A, (B | C) Two elements are allowed. A is expected, followed by either B or C.
(B | C)* Any number of B and/or C expected.
A, (B | C)* Two elements are allowed. A is expected followed by any number of B and/or C,
including none.
Content
model
Explanation
including none.
A, (B | C)+ At least two elements are expected, A followed by at least one of B or C. Any number of
B and C may follow.
A | (B, C) Either A is expected, or B followed by C is expected.
<Day Day Up>
including none.
A, (B | C)+ At least two elements are expected, A followed by at least one of B or C. Any number of
B and C may follow.
A | (B, C) Either A is expected, or B followed by C is expected.
<Day Day Up>
<Day Day Up>
Using XMI to Exchange Information Between Modeling Tools
To exchange information between two modeling tools, they must both support a common XMI version. Most UML
modeling tools support XMI version 1.0. Some tools also support XMI 1.1 or later versions. The instance document
for XMI 1.0 and 1.1 look quite different, although both versions are commercially acceptable and will have shelf life
for the foreseeable future. If you learn how data are represented in XMI 1.1, and then look at an instance
document in XMI 1.0, it will take you some time to understand the XMI 1.0 document. Therefore, we'll take a look
at representing a simple UML model in both XMI 1.0 and XMI 1.1.
Exchanging information using XMI 1.0
XMI 1.0 is the first commercial release of the XMI specification. A majority of UML modeling tools support the XMI
1.0 specification, so it is the current common denominator in exchanging UML models between tools.
The XMI 1.0 specification relies heavily on the use of XML elements and less so on the use of XML attributes that
XMI 1.1 and later specifications use. However, understanding XMI 1.0 will give you a good grounding in how UML
information is represented in XMI, and how most XMI interchange tools on the market today work.
XMI 1.0 instance document
The following code represents a typical XMI 1.0 instance document generated from a modeling tool. It is a file with
an .XML extension. You may open it in a browser such as Internet Explorer, and when you do, the browser will
parse the file against the rules of XML as specified by the W3C, making sure that it conforms. The parsing checks
to see if the markup is correctly configured; if each tree has been started with an opening bracket (<), and has a
corresponding closing bracket (/>); and so forth. It also checks to see if the hierarchy of the information is
correctly laid out.
<?xml version="1.0"?>
<!DOCTYPE XMI SYSTEM "UML.DTD">
<XMI xmi.version ="1.0"?>
+ <XMI.header>
+ <XMI.content>
</XMI>
The DOCTYPE statement specifies that the document is validated by the UML.DTD. Since a path is not specified,
this DTD must exist in the path of the XML instance document. The entire DTD could have been placed in the
instance document, but in this case, the reference to it makes the code less unwieldy and easier to read. The
version of XMI is also specified as 1.0.
The header section
XMI contains two main sections - the XMI.header and the XMI.content - that were not yet expanded in the
preceding example. (The + next to these sections indicates that these sections have not been expanded.)
Clicking on the + next to <XMI.header> expands the header section, as the following shows:
<?xml version="1.0"?>
<!DOCTYPE XMI SYSTEM "UML.DTD">
<XMI xmi.version="1.0">
<XMI.header>
<XMI.documentation>
<XMI.exporter>Popkin Software</XMI.exporter>
<XMI.exporterVersion>1.0.1</XMI.exporterVersion>
</XMI.documentation>
<XMI.metamodel xmi.name="UML" xmi.version="1.3"/>
</XMI.header>
Now you can see that the header section contains documentation, which includes two tag values: exporter (the
name of the maker of the software tool from which this XMI was generated - Popkin Software, in this example) and
exporterVersion (the version of the exporter application - 1.0.1, in this case).
The content section
The content section contains the guts of the information concerning the UML models. The best way to understand
how UML models are presented in XMI is to look at some examples, so let's take a look at use cases and various
class diagram structures. XMI supports information contained in all nine UML diagram types.
Example of a use case
We use a very simple example of a use case named Order Product that models a customer placing an order of a
product. Figure 22-1 shows this use case, wherein a customer, modeled as an actor, orders a product.
Figure 22-1: Simple use case of a customer ordering a product.
The XMI for this use case information is represented in the content section of the XMI instance document, which
contains information for all of the UML models generated. Listing 22-1 shows the XMI for only the Order Product
use case, not for the entire Use Case model.
Listing 22-1: XMI 1.0 Code for Order Product Use Case
<Behavioral_Elements.Use_Cases.UseCase xmi.id="S.10226">
<Foundation.Core.ModelElement.name>Order Product
</Foundation.Core.ModelElement.name>
<Foundation.Core.ModelElement.visibility xmi.value="public"/>
<Foundation.Core.GeneralizableElement.isRoot xmi.value="true"/>
<Foundation.Core.GeneralizableElement.isLeaf xmi.value="true"/>
<Foundation.Core.GeneralizableElement.isAbstract xmi.value="false"/>
<Behavioral_Elements.Use_Cases.UseCase.extensionPoint/>
<Foundation.Core.Classifier.associationEnd>
<Foundation.Core.AssociationEnd xmi.idref="IN.2"/>
</Foundation.Core.Classifier.associationEnd>
<Foundation.Core.Classifier.associationEnd>
<Foundation.Core.AssociationEnd xmi.idref="IN.3"/>
</Foundation.Core.Classifier.associationEnd>
<Foundation.Core.Classifier.associationEnd>
<Foundation.Core.AssociationEnd xmi.idref="E.22"/>
</Foundation.Core.Classifier.associationEnd>
<Foundation.Core.ModelElement.taggedValue>
<Foundation.Extension_Mechanisms.TaggedValue>
<Foundation.Extension_Mechanisms.TaggedValue.tag>documentation
</Foundation.Extension_Mechanisms.TaggedValue.tag>
<Foundation.Extension_Mechanisms.TaggedValue.value>To order a
product, the customer may use the company's internet site or
phone the sales department. The customer must specify the part
name and number, and how many items he or she wishes to order.
The sales interface (either internet form or salesperson) must
provide total price to customer and receive confirmation from
customer that they wish to order after being told the total
price. Sales interface must ascertain customer has enough credit
to cover purchase before placing order.
</Foundation.Extension_Mechanisms.TaggedValue.value>
</Foundation.Extension_Mechanisms.TaggedValue>
<Foundation.Extension_Mechanisms.TaggedValue>
<Foundation.Extension_Mechanisms.TaggedValue.tag>Responsible
Analyst</Foundation.Extension_Mechanisms.TaggedValue.tag>
<Foundation.Extension_Mechanisms.TaggedValue.value>Fred
Modeler</Foundation.Extension_Mechanisms.TaggedValue.value>
</Foundation.Extension_Mechanisms.TaggedValue>
</Foundation.Core.ModelElement.taggedValue>
</Behavioral_Elements.Use_Cases.UseCase>
Notice that the Order Product Use Case is described within the Behavioral_Elements.Use_Cases.UseCase
tag. Its name is the first element specified, on the line <Foundation.Core.ModelElement.name>Order
Product.
The XMI code snippet for the Order Product Use Case was found deep down in the XMI for the Use Case model.
Remember that when you navigate an XMI document, you navigate the hierarchy structure of the UML metamodel,
since XMI is a mapping of the UML metamodel to XML. So if you navigate the XMI instance document, or the
corresponding DTD, you navigate the same UML metamodel hierarchy. Use Cases, for example, are defined
within the Behavioral Elements package of the UML metamodel. This package exists within the UML's
Model_Management package, which is contained within the UML's Foundation.Core.Namespace.ownedElement
package of the Model_Management.Model. To get a clearer look at this hierarchical structure, examine Figure 22-
2, which uses XML Notepad to present the XMI shown in Listing 22-1.
Figure 22-2: Package hierarchy presented for XMI of overall Order System Use Case model.
XML Notepad presents a different user interface than a typical code editor. XML Notepad enables you to see the
hierarchy of this instance document more clearly. The package structure of the XMI instance document is on the
left side of the screen in Figure 22-2, and the data values of the XMI are on the right. The
Foundation.Core.Namespace.ownedElement package contains numerous subpackages of which one (the
Behavioral_Elements.Use_Cases.UseCase package) is highlighted and expanded. Underneath this package, you
see the elements of the Use Case - name, visibility, isRoot, isLeaf, isAbstract, and so forth. To
the right of Foundation.Core.ModelElement.name, you see the value Order Product. We'll examine these
properties more in the coming paragraphs.
As previously stated, the Foundation.Core.Namespace.ownedElement package has a number of subpackages in
addition to the one for Order Product. Directly below it is the package Behavioral_Elements.Use_Cases.Actor (that
is the actor in our Use Case diagram), followed by the package Foundation.Core.Association, which is the
association between the Use Case and the Actor in the Use Case diagram.
Below the expanded Behavioral_Elements.Use_Cases.UseCase package for Order Product (and its eight
subpackages) are four other packages (starting with Foundation.Core.Association): two other Associations and two
other use cases. These are the other two use cases in our diagram, with appropriate associations - in XMI, an
Extends and an Includes relationship are both treated as associations with stereotype of Extend or Include. You
would see their names and stereotypes if you extended each package.
Moving up in the structure, notice that the overall Foundation.Core.Namespace.ownedElement package is one of
a number of packages of Model_Management. Package, and the name of the particular
Model_Management.Package is Order_System. This corresponds to the package that our Use Case diagram was
created in within the modeling tool. The Model_Management.Package is one of a number of packages belonging
to the Model_Management.Model package UML_Bible.UDL. This corresponds to the name of the overall model -
in this case the name of the modeling tool's repository in which all of this information was created. (UDL stands for
Universal Data Locator. This modeling tool happens to use SQL Server as the repository, and the UDL file points
at the database on a server. In XMI terms, it is simply the name of the overall model.)
So far you have examined the XMI instance document, which contains the actual data of the UML Use Case
model. The hierarchy of this instance document must match the UML.DTD to be valid. In addition, the UML.DTD
specifies certain rules for the XMI instance document that must hold true for the instance document to be valid.
Listing 22-2 shows a snippet of code for the UML.DTD corresponding to the instance document of Listing 22-1 for
the use case.
Listing 22-2: UML.DTD of XMI 1.0 for Use Case Definition
<! -- METAMODEL CLASS: UseCase -- >
<! -- ________________________________________________________ -->
<!ELEMENT
Behavioral_Elements.Use_Cases.UseCase.extensionPoint ANY >
<!ELEMENT Behavioral_Elements.Use_Cases.UseCase (
Foundation.Core.ModelElement.name,
Foundation.Core.ModelElement.visibility,
Foundation.Core.GeneralizableElement.isRoot,
Foundation.Core.GeneralizableElement.isLeaf,
Foundation.Core.GeneralizableElement.isAbstract,
Behavioral_Elements.Use_Cases.UseCase.extensionPoint,
XMI.extension*,
Foundation.Core.ModelElement.constraint*,
Foundation.Core.ModelElement.requirement*,
Foundation.Core.ModelElement.provision*,
Foundation.Core.ModelElement.stereotype*,
Foundation.Core.ModelElement.elementReference*,
Foundation.Core.ModelElement.collaboration*,
Foundation.Core.ModelElement.partition?,
Foundation.Core.ModelElement.template?,
Foundation.Core.ModelElement.templateParameter*,
Foundation.Core.ModelElement.view*,
Foundation.Core.ModelElement.presentation*,
Foundation.Core.ModelElement.namespace?,
Foundation.Core.ModelElement.behavior*,
Foundation.Core.ModelElement.binding?,
Foundation.Core.ModelElement.implementation*,
Foundation.Core.GeneralizableElement.generalization*,
Foundation.Core.GeneralizableElement.specialization*,
Foundation.Core.Classifier.parameter*,
Foundation.Core.Classifier.structuralFeature*,
Foundation.Core.Classifier.specification*,
Foundation.Core.Classifier.associationEnd*,
Foundation.Core.Classifier.participant*,
Foundation.Core.Classifier.createAction*,
Foundation.Core.Classifier.instance*,
Foundation.Core.Classifier.collaboration*,
Foundation.Core.Classifier.classifierRole*,
Foundation.Core.Classifier.realization*,
Foundation.Core.Classifier.classifierInState*,
Foundation.Core.ModelElement.taggedValue*,
Foundation.Core.Namespace.ownedElement*,
Foundation.Core.Classifier.feature*)?
>
<!ATTLIST Behavioral_Elements.Use_Cases.UseCase
%XMI.element.att;
%XMI.link.att;
>
Notice how similar the use case properties of the DTD are to the instance document. In fact, they should be the
same. A careful examination of the DTD will reveal the rules that it is specifying.
The first five use case properties - name, visibility, isRoot, isLeaf, and isAbstract - are
mandatory. This rule is specified by the fact that there is no EBNF modifier after the property (see Table 22-2,
which shows that having no EBNF modifier means the property is mandatory). A modeling tool must support these
properties, a person modeling a system must specify a value for them, and, as a consequence, any XMI generated
from the modeling tool must contain these properties and have values for them. Most modeling tools provide a
default value for these properties, so that they have a value if the user forgets to specify one.
The use case definition has a number of other properties that have the asterisk (*) after them, such as extension,
constraint, requirement, and stereotype. This is EBNF notation specifying that there are zero or more values for
these properties. These are mandatory properties according to the UML specification, but their values could be
zero. For example, a UML modeling tool should provide a stereotype property for a use case, but the modeler
does not have to specify a stereotype value for a particular use case that he or she models. It may be left blank (no
stereotype). When XMI is generated, the instance document will not contain any reference to the existence of that
property.
The use case definition has a number of properties, such as partition, template, namespace, and binding that have
a question mark (?) after them. This is EBNF notation for an optional property. This means the modeling tool does
not have to support these properties at all, and they do not need to be in the XMI.
Tagged values
One of the important extensibility features of UML is tagged values, which have a direct correlation to XMI. The
UML specification allows users to create their own properties within UML definition types using tagged values.
Examples of tagged values for a Use Case might be adding properties to enable a modeler to write a description
for the Use Case, or capture the name of the analyst who designed the Use Case. UML modeling tools that
support the MOF enable users to extend the UML metamodel in this way. To fully exchange data between
modeling tools, both tools must support this sort of extensibility, and the transfer mechanism must be able to
transfer this information. XMI, of course, is a self-describing markup language, so tagged values are naturally
expressed by it. This gives XMI a significant advantage over any proprietary interface that could be built between
two modeling tools - once a proprietary interface is built, adding tagged values to the metamodel of one of the
tools means that the interface has to be modified in order to capture and transfer this information. Using XMI, no
modification is necessary; tagged values are naturally understood and put into the XMI.
One of the properties in the UML.DTD in Listing 22-2 is called
Foundation.Core.ModelElement.taggedValue*. The asterisk indicates that a use case can have zero or
more tagged values. Take another look at the XMI instance document in XML Notepad. Figure 22-3 shows the
tagged value package of the Place Order use case expanded.
Figure 22-3: XMI instance document, with taggedValue property expanded for Order Product Use Case.
You can see two tagged values for the Order Product use case in Figure 22-3. Each one has a tag
(Foundation.Extension_Mechanisms.TaggedValue.tag) and a value. The tag provides the name of the
property - one property is called documentation, and the other is called Responsible Analyst. The value is the
modeling data captured for this use case for the property. For the documentation property, there is a textual
description that starts with the words "To order a product,.".
The Responsible Analyst for this use case is a person named Fred Modeler. Here's the actual code (from near the
end of the XMI shown in Listing 22-1):
<Foundation.Core.ModelElement.taggedValue>
<Foundation.Extension_Mechanisms.TaggedValue>
<Foundation.Extension_Mechanisms.TaggedValue.tag>documentation
</Foundation.Extension_Mechanisms.TaggedValue.tag>
<Foundation.Extension_Mechanisms.TaggedValue.value> To order a
product, the customer may use the company's internet site or
phone the sales department. The customer must specify the part
name and number, and how many items he or she wishes to order.
The sales interface (either internet form or salesperson) must
provide total price to customer and receive confirmation from
customer that they wish to order after being told the total
price. Sales interface must ascertain customer has enough credit
to cover purchase before placing order.
</Foundation.Extension Mechanisms.TaggedValue.value>
</Foundation.Extension_Mechanisms.TaggedValue>
<Foundation.Extension_Mechanisms.TaggedValue>
<Foundation.Extension_Mechanisms.TaggedValue.tag>Responsible
Analyst</Foundation.Extension_Mechanisms.TaggedValue.tag>
<Foundation.Extension_Mechanisms.TaggedValue.value>Fred
Modeler</Foundation.Extension_Mechanisms.TaggedValue.value>
</Foundation.Extension_Mechanisms.TaggedValue>
</Foundation.Core.ModelElement.taggedValue>
<Day Day Up>
<Day Day Up>
Exchanging Information Using XMI 1.1
The UML.DTD for XMI 1.1 is quite different from XMI 1.0. The most significant difference is the use of
namespaces. Namespaces were not used in XMI 1.0 because at the time that the specification was written, the
W3C had not finalized the official recommendation of Namespaces. All names need to be fully qualified in the XMI
1.0 spec, which makes any XMI 1.0 instance document very long winded. Instance documents for XMI 1.1 are
much more compact and easier to read than those for XMI 1.0. However, at the time of this writing, not all
modeling tools support XMI 1.1.
XMI 1.1 instance document
The following code shows an XMI 1.1 instance document for the Use Case model shown earlier in this chapter.
<?xml version="1.0" encoding="IS0-8859-1" ?>
- <XMI xmi.version="1.1" xmlns:UML="//org.omg/UML/1.3">
+ <XMI.header>
+ <XMI.content>
</XMI>
The document contains a header section and a content section, as did the XMI 1.0 instance document.
The second line of the instance document specifies that the version of XMI used is 1.1. It also specifies the
namespace: xmlns:UML. This means that the namespace is declared as UML. In the next section, you see how
this is used. The logical URI is specified as //org.omg/UML/1.3.
The header section
The following code shows the expanded header section, which is very similar to the header of XMI 1.0. It specifies
the vendor that generated the XMI (TogetherSoft), and the version of the export utility (6.0).
<?xml version="1.0" encoding="IS0-8859-1" ?>
- <XMI xmi.version="1.1" xmlns:UML="//org.omg/UML/1.3">
- <XMI.header>
- <XMI.documentation>
<XMI.exporter>TogetherSoft</XMI.exporter>
<XMI.exporterVersion>6.0</XMI.exporterVersion>
</XMI.documentation>
<XMI.metamodel xmi.name="UML" xmi.version="1.4" />
</XMI.header>
+ <XMI.content>
</XMI>
The content section
All of the information about the UML models themselves is contained in the content section. Here's a snippet of
code from the content section for the Order Product Use Case.
<UML:UseCase xmi.id = 'S.10'
name = 'Order Product'
visibility = 'package'
isSpecification = 'false'
isAbstract = 'false'>
</UML:UseCase>
Notice that it is much more compact than the equivalent specification of this Use Case element in the XMI 1.0
instance document. There are two reasons for this: use of a namespace and use of XML attributes instead of child
elements.
Use of namespaces
The use of a namespace (in this case, "UML") makes the declaration of the UseCase element much more
compact. In the opening and closing tags above, the namespace UML: replaces the fully qualified name
(Behavioral_Elements.UseCases) that existed in the XMI 1.0 instance document, shown previously and repeated
below.
<Behavioral_Elements.Use_Cases.UseCase xmi.id="S.10226">
...
</Behavioral_Elements.Use_Cases.UseCase>
Use of attributes
To see how attributes are used in the XMI instance document, let's look at the UML.DTD for XMI 1.1 in Listing 22-
3.
Listing 22-3: XMI 1.1 DTD Section for Use Cases
<! - - CLASS: Behavioral_Elements.Use_Cases.UseCase - ->
<!ELEMENT UML:UseCase.extensionPoint (#PCDATA |
XMI.reference)* >
<!ELEMENT UML:UseCase (UML:ModelElement.name |
UML:ModelElement.visibility |
UML:GeneralizableElement.isRoot |
UML:GeneralizableElement.isLeaf |
UML:GeneralizableElement.isAbstract |
UML:UseCase.extensionPoint | XMI.extension |
UML:ModelElement.binding |
UML:ModelElement.template |
UML:ModelElement.templateParameter |
UML:ModelElement.implementation |
UML:ModelElement.view |
UML:ModelElement.presentation |
UML:ModelElement.namespace |
UML:ModelElement.constraint |
UML:ModelElement.requirement |
UML:ModelElement.provision |
UML:ModelElement.stereotype |
UML:ModelElement.elementReference |
UML:ModelElement.collaboration |
UML:ModelElement.behavior |
UML:ModelElement.partition |
UML:GeneralizableElement.generalization |
UML:GeneralizableElement.specialization |
UML:Classifier.parameter |
UML:Classifier.structuralFeature |
UML:Classifier.specification |
UML:Classifier.realization |
UML:Classifier.associationEnd |
UML:Classifier.participant |
UML:Classifier.createAction |
UML:Classifier.instance |
UML:Classifier.collaboration |
UML:Classifier.classifierRole |
UML:Classifier.classifierInState |
UML:ModelElement.taggedValue |
UML:Namespace.ownedElement |
UML:Classifier.feature)* >
<!ATTLIST UML:UseCase
name CDATA #IMPLIED
visibility (public | protected | private) #IMPLIED
isRoot (false | true) #IMPLIED
isLeaf (false | true) #IMPLIED
isAbstract (false | true) #IMPLIED
extensionPoint CDATA #IMPLIED
binding IDREFS #IMPLIED
template IDREFS #IMPLIED
templateParameter IDREFS #IMPLIED
implementation IDREFS #IMPLIED
view IDREFS #IMPLIED
presentation IDREFS #IMPLIED
namespace IDREFS #IMPLIED
constraint IDREFS #IMPLIED
requirement IDREFS #IMPLIED
provision IDREFS #IMPLIED
stereotype IDREFS #IMPLIED
elementReference IDREFS #IMPLIED
ModelElement.collaboration IDREFS #IMPLIED
behavior IDREFS #IMPLIED
partition IDREFS #IMPLIED
generalization IDREFS #IMPLIED
specialization IDREFS #IMPLIED
parameter IDREFS #IMPLIED
structuralFeature IDREFS #IMPLIED
specification IDREFS #IMPLIED
realization IDREFS #IMPLIED
associationEnd IDREFS #IMPLIED
participant IDREFS #IMPLIED
createAction IDREFS #IMPLIED
instance IDREFS #IMPLIED
Classifier.collaboration IDREFS #IMPLIED
classifierRole IDREFS #IMPLIED
classifierInState IDREFS #IMPLIED
%XMI.element.att;
%XMI.link.att;
The XMI 1.1 DTD section for use cases looks appreciably different from the XMI 1.0 equivalent. In XMI 1.0, shown
in Listing 22-2, the UseCase element had a number of child elements specified within parentheses, each
separated by a comma. The comma in XML specifies that the elements need to appear in the order that they are
listed (see Table 22-2). Some elements, if you remember, are mandatory - those with no special annotation after
them, such as visibility, isRoot, isLeaf, isAbstract.
In Listing 22-3, we see that a pipe (|), not a comma, separates the elements. This is equivalent to an or statement
in XML - the Use Case element contains the visibility child element or the isRoot child element or the
isLeaf child element, and so forth. This seems odd until you look at the end of the closing parenthesis:
... | UML:Classifier.feature)* >
This is equivalent to the (B | C)* sample shown in Table 22-3. It indicates that you can have any number of these
child elements in the XMI, in any order. What does this mean to you? It signifies that the ordering restriction has
been relaxed in XMI 1.1, so that these child elements may appear in any order. This makes the XMI itself a bit
more flexible - if any one of these elements is out of order in XMI 1.0, the instance document does not validate
against the UML.DTD. If your modeling tool generated any of these values in incorrect order, you could not
validate the XMI against its DTD.
The <!ATTLIST UML:UseCase declaration specifies the attributes for the Use Case element. The name of the
use case is an attribute called name. It is CDATA and #IMPLIED.visibility, isLeaf, isRoot, and
isAbstract are also represented as attributes that have #IMPLIED values that are specified - for example,
visibility can be public, private, protected, or package.
Take another look at the code snippet from the Order Product use case instance document:
<UML:UseCase xmi.id = 'S.10'
name = 'Order Product'
visibility = 'package'
isSpecification = 'false'
isAbstract = 'false'>
</UML:UseCase>
You can clearly see that four attributes are specified, with their values.
Tagged values
The original use case had more information than that represented in the code above. Remember, there were
tagged values such as Description and Responsible Analyst. To find these tagged values, we open the entire
instance document in XML Notepad (see Figure 22-4).
Figure 22-4: XMI 1.1 instance document, with TaggedValue property expanded for Order Product use case.
Notice that UML:TaggedValue is a separate package outside of the UML:Namespace.OwnedElement package in
which the use case element resides. This is a very different structure than XMI 1.0. Your first question may be,
"How do I know that tagged value belongs to the Order Product use case?" The answer is provided through the
use of IDRefs.
We go back to the DTD and find the specification for tagged values, shown in Listing 22-4.
Listing 22-4: Tagged Values Specified in XMI 1.1 DTD
<!-- CLASS: Foundation.Extension_Mechanisms.TaggedValue -->
<!-- __________________________________________________ -->
<!ELEMENT UML:TaggedValue.tag (#PCDATA | XMI.reference)* >
<!ELEMENT UML:TaggedValue.value (#PCDATA | XMI.reference)* >
<!ELEMENT UML:TaggedValue.modelElement (UML:ModelElement)* >
<!ELEMENT UML:TaggedValue.stereotype (UML:Stereotype)* >
<!ELEMENT UML:TaggedValue (UML:TaggedValue.tag |
UML:TaggedValue.value | XMI.extension |
UML:TaggedValue.modelElement |
UML:TaggedValue.stereotype)* >
<!ATTLIST UML:TaggedValue
tag CDATA #IMPLIED
value CDATA #IMPLIED
modelElement IDREFS #IMPLIED
stereotype IDREFS #IMPLIED
%XMI.element.att;
%XMI.link.att;
>
Examine the line specifying the TaggedValue element:
<!ELEMENT UML:TaggedValue (UML:TaggedValue.tag |
UML:TaggedValue.value | XMI.extension |
UML:TaggedValue.modelElement |
UML:TaggedValue.stereotype)* >
This is another example of (B | C)*, which means that the element can have any number of the child elements. In
our case, it interests us that a tagged value may have a referenced modelElement.
The following code, from the instance document in Figure 22-3, shows that the tagged value documentation has a
reference to a modelElement named S.10. To find what modelElement this tagged value is referenced to, you
simply need to find out what S.10 is. Look again at the Order Product use case in Figure 22-4; you can see that it
has an XMI.ID of S.10. Thus the documentation tagged value belongs to the Order Product use case.
Specifying this using an ID reference makes for less wordy XMI code - the documentation tagged value did not
have to be prefaced by a long path name.
<UML:TaggedValue xmi.id = 'XX.2'
name = 'documentation'
modelElement = 'S.10'>
<UML:TaggedValue.dataValue>To order a product, the
customer may use the company's internet site or phone the
sales department. The customer must specify the part name
and number, and how many items he or she wishes to order.
The sales interface (either internet form or
salesperson) must provide total price to customer and
receive confirmation from customer that they wish to
order after being told the total price. Sales interface
must ascertain customer has enough credit to cover
purchase before placing order.
</UML:TaggedValue.dataValue>
</UML:TaggedValue>
<Day Day Up>
<Day Day Up>
Diagram Interchange
The initial XMI specifications, versions 1.0 through 1.3, have one serious flaw: the specifications themselves lack
any information concerning diagrams. What this means is that there is no information concerning the existence of
the diagrams themselves, their type (Use Case, Class, Activity, and so forth), or what package each belongs to.
There is no information about which classifiers are represented as symbols on each diagram's workspace, how the
symbols are positioned on the diagram's workspace, or what the lines that connect them look like (straight
connections or lines with bend points in them). There is no information concerning the coloring of the symbols on
the diagrams, the fonts used, the size of the symbols, and so on.
None of this information is important if XMI is being generated with the intention of using it with a coding tool,
wherein the XMI is translated to a coding language such as Java. But if the XMI is being used to transfer
information from one UML modeling tool to another, a serious bit of information is lost.
For example, if UML tool A contains a package with three Use Case diagrams, two Class diagrams, and six
Sequence diagrams, and this information is ported to UML tool B, the XMI provides UML tool B with the package
construct, and all of the definitions such as the use cases, classes, objects, and messages within this package. It is
up to the user to manually create the 11 diagrams in tool B, and drag the particular definitions onto each diagram.
If UML modeling tool B understands the semantics of the relationships between the classifiers, it should
automatically draw the relationships between the symbols on the diagram. Still, even with all of this manual work
by the user, the exact positioning of symbols on the diagram is lost.
The OMG recognized this important deficiency in the XMI specification, and to correct it, issued a Request for
Proposal (RFP) for a Diagram Interchange specification. Three proposals were submitted to the OMG in response
to this RFP. The submitters agreed to join their proposals into one specification, which was adopted by the OMG to
coincide with UML 2.0.
OMG's RFP mandates that the Diagram Interchange specification support the following diagramming features:
Diagram placement (X, Y, and optional Z coordinates)
Grouping of diagram elements
Alignment of diagram elements
Fonts
Support for Character sets
Color
Attachment points on relationships
Visibility on artifacts (for example, hiding or showing operations in a class, or classes on a diagram)
Non-UML artifacts on diagrams (for example, artifacts not covered by the current UML notation)
Scaling information, rotation information, and so on.
User-defined icons and shapes (for example, some modeling tools allow users to specify that a symbol that
normally represents a UML definition be replaced by a metafile that the user provides, generally based on the
stereotype property of the definition)
Positioning Aspects of the diagram elements (for example, where the end-points are drawn for a segmented
line, the position of symbol and line names, and so forth)
The Diagram Interchange specification is intended to work as an add-on to the XMI specification. Just as you apply
the XMI Production Rules to the MOF to produce a UML.DTD or schema, the strategy of the Diagram Interchange
specification is to introduce a separate metamodel for diagram information that is added as a separate package to
the existing metamodel of UML. The XMI DTD or Schema Production Rules are applied to this metamodel to
produce a DTD or schema for diagram interchange.
Producing a separate metamodel for diagram interchange provides a number of benefits. First, it enables the
people creating the spec to do so without worrying about changing the UML metamodel itself, since they are
simply extending it. Just as importantly, the UML spec may change without affecting the Diagram Interchange
spec. Second, the resulting Diagram Interchange DTD or schema becomes a component that can be used or not
used depending on the interchange scenario:
It can be used in conjunction with the UML.DTD or schema to exchange information between modeling tools,
which carry the graphic and semantic information of modeling elements.
It can be used by itself for simple drawing tools that do not carry semantic information.
It does not have to be used at all when modeling tools output XMI that will be converted to other code
languages such as Java.
The Diagram Interchange metamodel
The Diagram Interchange specification provides a MOF-compliant metamodel for diagrammatic information. Since
the XMI DTD and Schema Production Rules specify how a MOF-compliant metamodel is translated to an XMI
DTD or schema, all the OMG needs to do is create and agree upon a metamodel for diagram interchange. Once
the metamodel is agreed upon, all of the other work in creating the DTD is taken care of by the XMI specification
itself, which can be automated.
The creation of a Diagram Interchange DTD from an MOF-compliant Diagram Interchange metamodel is shown in
Figure 22-5.
Figure 22-5: Overview of creation of Diagram Interchange DTD.
The actual MOF-compliant metamodel for diagram interchange is developed in a UML modeling tool, using the
UML Profile for MOF. This metamodel is output to an XMI instance document using the modeling tool's ability to
export XMI based on the XMI document production rules. The instance document contains the content of the new
metamodel. To create the new combined DTD for UML and diagram interchange, the new instance document is
first translated to a MOF instance document using the MOF Profile rules, which are contained in the UML Profile
for MOF. This MOF instance document expresses the MOF representation of the combined UML and Diagram
Interchange metamodel. The XMI DTD Production rules are applied to this MOF instance document to create the
combined DTD for UML and diagram interchange. Alternatively, the XMI Schema Production Rules can be applied
to the MOF instance document to create a schema for UML and diagram interchange.
Use of graph theory to exchange diagrammatic information
The Diagram Interchange specification uses traditional graph theory to specify the appearance of symbols on UML
diagrams. Each diagram is a graph that consists of nodes and edges. Nodes consist of the rectangles, circles,
ovals, and other symbol shapes that represent classes, components, Use Cases, states, and the like. Nodes can
contain compartments (such as the compartments in a class for attributes and methods), have other nodes nested
within them (such as you might do with super- and sub-states), and contain annotations. Edges are the connecting
lines between the nodes, which represent associations, inheritance, and other relationships. In some cases an
edge can connect a node to another edge (such as in the case of an association class where a line is drawn
connecting a class to an association line between two other classes). Graph theory works well for UML, because
all diagrams except for the Sequence diagram map easily to graphs. And the Sequence diagram is simply another
view of the Collaboration diagram (most UML modeling tools offer automatic translation from a Collaboration
diagram to a Sequence diagram and vice versa), so if the Collaboration diagram can be mapped to a graph that is
represented in XMI, then the Sequence diagram can be expressed as well.
<Day Day Up>
<Day Day Up>
Tools to Use
As mentioned earlier in this chapter, XMI can provide you with all of the information concerning your UML models
in serialized textual form that is easily transported and manipulated. There are many tools available on the market
to help you manipulate the XMI, depending on what your goal is.
If you are generating XMI from one modeling tool and importing it into another, you shouldn't need any additional
tools. The XMI generators and importers of the modeling tools should take care of the modeling information
exchange seamlessly. If errors are encountered however, you may want to investigate the cause by looking directly
at the XMI.
After you have generated XMI from a modeling tool, you first want to check that the XMI is okay. As mentioned
earlier, there are two levels of verification to check that the XMI document is valid. It must conform to rules of XML
as specified by the W3C, and it must validate against the rules set forth in its DTD. The following is a list of tools
that will help you check, validate, and explore an XMI instance document.
Conforming to the Rules of XML as Specified by W3C: Most popular browsers on the market, including
Internet Explorer 5.0 and beyond, will parse an XML document to see if it conforms to the rules of XML as
specified by the W3C. All you have to do is open the XML document in the browser.
Validating Against the DTD and Schema: There are a number of tools that will validate an XML document
against its DTD. One of the more useful, simple tools is Microsoft XML Notepad. It gives you an option of
validating the XML document against its DTD upon opening it, or turning validation off, which is useful if you
want to examine an XML document that contains errors. Tools that can validate an XML document against its
schema are also widely available, including Microsoft XML Core Services 4.0 RTM (MSXML 4.0) parser and
Altova's XMLSpy.
Cross-Reference Microsoft's XML Notepad is an extremely useful tool that has never officially been
commercialized by Microsoft. It has been in beta for several years, and is available
free of charge from a number of websites, including http://www.webattack.com.
Examining the XML and DTD: You can use any word processor or text editor to view XML and DTD files.
Code editors, including IDEs such as MSVC or EditPlus, enable you to view line numbers of the code, which is
very helpful when troubleshooting. High-end tools such as Altova's XMLSpy provide a plethora of features for
examining the XML instance document and accompanying DTD. Many modeling tools, such as System
Architect and IBM/Rational Rose, provide the ability to reverse engineer the structure of DTDs and instance
documents to provide a graphical interpretation of the XML hierarchy.
<Day Day Up>
<Day Day Up>
Summary
In this chapter, you learned that
UML information in modeling tools and object repositories can be translated to and from XMI, which is a
standard, serialized, easily transportable format, based on industry-standard XML.
XMI enables modeling tools to exchange UML model information, as long as they support export and import of
XMI.
When exchanging information between modeling tools, two basic artifacts need to be exchanged: the UML
model information and the diagrams. Current XMI specifications only allow exchange of model information; the
Diagram Interchange specification will enable exchange of diagrammatic information.
After UML models are mapped to XMI, XSLT becomes a natural fit for transforming the XMI into other useful
forms. You can use XSLT to transform the structure and format of an XMI document.
XMI is an enabling technology for MDA in that tools that support it generate UML models to a standard form
that can be manipulated by third-party code creation tools to map the UML models to any coding language.
XMI specifications include a set of XMI Document Production Rules, DTD Production Rules, and, for the latest
specs, XMI Schema Production Rules.
The XMI Document Production Rules are used to encode UML metadata to create the XMI instance
document. This is the document that contains the actual UML model information.
The DTD Production Rules and Schema Production Rules enable a DTD or schema to be created from any
MOF-based metamodel repository, including UML and the Common Warehouse Metadata Interchange
(CWMI).
The DTD or schema is used to validate the instance document to make sure the document is structured
correctly.
The XMI spec comes with a prebuilt UML DTD and MOF DTD.
The UML architecture is comprised of four layers of metamodels, M0 through M3. At the base, or M3 layer, of
the UML architecture is the MOF. UML is only one example (albeit the most popular example) of M2 layer
metamodels built on top of the MOF.
There are two levels of XMI instance document correctness: it can be well formed and it can be valid. A
document is well formed if it contains one or more elements, has a root element, and all elements within the
root element are properly nested. Most browsers will check a document to see if it is well formed upon
opening it. A document is valid if it conforms to the rules and structure specified by its DTD or schema.
Browsers do not check a document for validity upon opening it; you need to use a tool to check this.
An XMI instance document created for XMI 1.0 looks substantially different than one for XMI 1.1. It is much
smaller and easier to read because it uses namespaces and makes more use of attributes, while XMI 1.0
relies on nested elements with fully qualified namespaces.
An XMI instance document contains a header and a content section. The information about UML models is
contained in the content section.
The Diagram Interchange specification is intended to work as an add-on to the XMI specification.
The Diagram Interchange specification uses traditional graph theory to specify the appearance of symbols on
UML diagrams. Each diagram is a graph that consists of nodes and edges.
<Day Day Up>
<Day Day Up>
Appendix A: UML 1.4 Notation Guide
Class Diagram Notation
The Class diagram notation is explained fully in Chapters 5 through 7.
Class notation
Figure A-1: Class icon with the default name, attribute, and operation compartments, and a user-defined
compartment.
Attribute declaration
[visibility] [/] name [:type] [multiplicity] ['=' default]
['{'property-string'}']
The optional underline defines a class-level attribute.
Operation declaration
[visibility] name ([parameter-list]) ':' [return-result]
['{'property-string'}']
The optional underline defines a class-level attribute.
Tagged value declaration
tagname ':' value
Valid class presentations
Classes may be identified with a name and optional stereotype. The stereotype may be in text or icon form.
Figure A-2: Four presentation alternatives for classes with stereotypes.
Template class
Figure A-3: Template class.
Parameter syntax
name ':' type [= default]
Bound element syntax
template-name '<' value-list '>'
Interface class notation
Figure A-4: Interface class notation.
Association notation
Associations are covered in Chapter 6.
Figure A-5: Binary association notation.
Reflexive association and roles
Figure A-6: Reflexive association and roles notation.
Constraints between associations
Figure A-7: Constraints between associations.
Association navigability
Figure A-8: Association navigability.
Ordering, derived association, and qualified association
Figure A-9: Ordering, derived association, and qualified association.
Association class notation
Figure A-10: Association class notation.
N-ary association
Figure A-11: N-ary association.
Aggregation and composition notation
Figure A-12: Aggregation and composition notation.
Alternative composition notation
Chapter 7 addresses Composite Structure diagrams, the alternative notation for composition.
Figure A-13: Alternative composition notation.
Generalization notation
Figure A-14 and A-15 together provide the complete notation for generalization.
Chapter 6 addresses generalization.
Figure A-14: Generalization notation: complete constraint, Power Type, ellipse, abstract class.
Figure A-15: Generalization notation: discriminator, disjoint and overlapping, constraints, and multiple
inheritance.
Dependency notation
Chapter 6 addresses dependency notation.
Figure A-16: Dependency notation between two packages (left) and two classes (right).
Figure A-17: Class dependency notation.
<Day Day Up>
<Day Day Up>
Object Diagram
Chapter 7 addresses the Object diagram.
Object and link notation
Figure A-18: Object notation.
Object name syntax
Object-name : class-name
Attribute value syntax
Attribute-name '=' value
Pattern/Collaboration notation
Chapter 7 covers patterns and collaborations.
Modeling a design pattern using a collaboration
Figure A-19: Using collaboration notation to define a design pattern.
Implementing a design pattern/collaboration
Figure A-20: Implementing a design pattern (collaboration).
<Day Day Up>
<Day Day Up>
Sequence Diagram Notation
Chapters 8 and 9 address Sequence diagram notation.
Sequence diagram lifeline, message and return, self-reference, guard, and
iteration
Figure A-21: Sequence diagram notation.
Message (and arrow) types
Figure A-22: Message types.
Message syntax
predecessor/ sequence-expression return value :=
message-name argument-list
predecessor :=
sequence-number [',' sequence-number...] '/'
sequence-expression :=
sequence-term [',' sequence-term...] ':'
sequence-term :=
[integer | name] [recurrence]
recurrence :=
'*' '[' iteration-clause ']' -- for an iteration
'[' condition-clause ']' -- for a branch
Recursive message
Figure A-23: Recursive message.
Object creation and termination
Figure A-24: Object creation and termination.
Time constraints
Figure A-25: Time constraints.
Activation and focus of control
Figure A-26: Activation (also called focus of control).
<Day Day Up>
<Day Day Up>
Collaboration Diagram Notation
Chapter 8 addresses the Collaboration diagram.
Figure A-27: Collaboration diagram notation.
<Day Day Up>
<Day Day Up>
Statechart Diagram Notation
The Statechart diagram is covered in Chapter 10.
Initial and final state, state, transition with guard
Figure A-28: Statechart notation (1).
When and after clauses
Figure A-29: When and after clauses.
Transition syntax
Event-name (comma-separated-parameter-list)
[guard-condition] / action-expression
Self-transition, and entry and exit actions
Figure A-30: Self-transition, and entry and exit actions.
Static branch state
Figure A-31: Static branch state.
Dynamic choice point
Figure A-32: Dynamic choice point.
Composite state
Figure A-33: Composite state.
Deep and shallow history
Figure A-34: Deep and shallow history.
Concurrent substates
Figure A-35: Concurrent substates.
Split and merge of control
Figure A-36: Split and merge of control.
Submachine state and stub states
Figure A-37: Submachine state and stub states.
Synch states
Figure A-38: Synch states.
Send and receive signals
Figure A-39: Send and receive signals.
NoteThe gray highlighted rectangles are for emphasis only.
<Day Day Up>
<Day Day Up>
Use Case Diagram
The Use Case diagram is covered in Chapter 12.
Figure A-40: Use Case diagram notation.
<Day Day Up>
<Day Day Up>
Activity Diagram
Chapter 13 discusses the Activity diagram.
Start, end, decision (split), and merge
Figure A-41: Start, end, decision (split), and merge.
Concurrency using the Synchronization bar to model forks and joins
Figure A-42: Fork and join notation.
Activity, transition, and transition guard
Figure A-43: Activity, transition, and transition guard.
Swimlanes and object flows
Figure A-44: An Activity diagram divided into three swimlanes and passing the Order object from one activity
to the next.
<Day Day Up>
<Day Day Up>
Component Diagram
Chapter 15 addresses the Component diagram.
Figure A-45: Component diagram notation.
Alternative notation for resident and implementing classes
Figure A-46: Alternative notation for resident and implementing classes.
<Day Day Up>
<Day Day Up>
Deployment Diagram
Chapter 16 covers the Deployment diagram.
Figure A-47: Nodes defined as classifiers, with attributes and operations, at type and instance levels.
Figure A-48: Component diagram at type and instance levels.
<Day Day Up>
<Day Day Up>
Combined Component and Deployment Diagram
This topic is covered in Chapter 17.
Component deployment on a node instance
Figure A-49: Deployment of a component on a node instance.
Containment version
Figure A-50: Deployment of components on a node instance using containment.
<Day Day Up>
<Day Day Up>
Packages
Basic Package diagram
Packages as Namespaces
Figure A-51: Packages as namespaces.
Package containment notation alternatives
Figure A-52: Package containment notation alternatives.
Access dependency
Figure A-53: Access dependency.
Merge dependency
Figure A-54: Merge dependency.
Subsystem diagram
Subsystem notation alternatives
Figure A-55: Subsystem notation alternatives.
Subsystem interface notation
Figure A-56: Subsystem interface notation.
Subsystem realization
Figure A-57: Subsystem realization.
Model diagram
Model notation
Figure A-58: Model notation.
<Day Day Up>
<Day Day Up>
Appendix B: UML 2.0 Notation Guide
Class Diagram Notation
The Class diagram notation is explained fully in Chapters 5 through 7.
Class notation
Figure B-1: Class icon.
Attribute declaration
[visibility] [/] name [:type] [multiplicity] ['='default]
['{'property-string'}']
The optional underline defines a class-level attribute.
isDerived: The default value is false.
isReadOnly: The default value is false.
Operation declaration
[visibility] name ([parameter-list]) ':' [return-result]
['{'property-string'}']
The optional underline defines a class-level attribute.
Tagged value declaration
tagname ':' value
Valid class presentations
Classes may be identified with a name and optional stereotype. The stereotype may be in text or icon form.
Figure B-2: Four presentation alternatives for classes with stereotypes.
Interface class notation
Figure B-3: Interface class notation.
Template class
Figure B-4: Template class.
Parameter syntax
template-parameter ::= parameter-name
[':' parameter-kind]['>' constraint]
['=' default]
parameter-kind :: =
'class' | 'component' | 'type' | 'interface' | 'signal'
|'value' |'operation' | 'attribute' | 'part' | 'class'
| parameter ::=parameter-name | operation-name
(parameter-list)
constraint ::= ['{contract}'] classifier-name
default ::= classifier-name | expression | attribute-name | part-name
| operation-name
If the parameter-kind is omitted, then parameter-kind is class'.
Bound element syntax
template-name '<'value-list'>'
Association notation
Association notation is covered in Chapter 6.
Figure B-5: Binary association notation.
Reflexive association and roles
Figure B-6: Reflexive association and roles notation.
Constraints between associations
Figure B-7: Constraints between associations.
Association navigability
Figure B-8: Navigability.
Ordering, derived association, and qualified association
Figure B-9: Ordering, derived association, and qualified association.
Association class notation
Figure B-10: Association class notation.
N-ary association
Figure B-11: N-ary association.
Aggregation and composition notation
Figure B-12: Aggregation and composition notation.
Composite structure notation
Figure B-13: Alternative composition notation.
Generalization notation
Generalization is explained in Chapter 6.
Figure B-14: Generalization notation: complete constraint, Power Type, ellipse, and abstract class.
Figure B-15: Generalization notation: discriminator, disjoint and overlapping constraints, and multiple
inheritance.
Dependency notation
Figure B-16: Dependency notation between two packages (left) and two classes (right).
Figure B-17: Class dependency notation.
<Day Day Up>
<Day Day Up>
Object Diagram
Chapter 7 covers the Object diagram.
Object and link notation
Figure B-18: Object notation.
Object name syntax
Object-name : class-name
Attribute value syntax
Attribute-name '=' value
Pattern/Collaboration notation
Chapter 7 covers patterns and collaborations.
Modeling a design pattern using a collaboration
Figure B-19: Using collaboration notation to define a design pattern.
Implementing a design pattern/collaboration
Figure B-20: Implementing a design pattern (collaboration).
<Day Day Up>
<Day Day Up>
Sequence Diagram Notation
The Sequence diagram is covered in Chapter 9.
Sequence diagram (interaction) lifeline, message and return, self-
reference, guard, and iteration
Figure B-21: Sequence diagram basic notation.
Message (and arrow) types
Figure B-22: Message types.
Message syntax
message-ident ::=
signal-or-operation-name [ (arguments) ][: return-value]
arguments ::= argument [ , arguments]
argument ::=
parameter-name:argument-value | argument-value |
State invariant
Figure B-23: State invariant.
<Day Day Up>
<Day Day Up>
Object creation and termination
Return is optional (some languages do not allow returns in contsructor syntax)
Figure B-24: Object creation and termination.
Duration constraints
Figure B-25: Duration constraints.
Time constraints
Figure B-26: Time constraints.
Interaction occurrence
Figure B-27: Interaction occurrence.
Gates and parameters
Figure B-28: Interaction occurrence.
Interaction operands and operators
Figure B-29: Interaction occurrence.
Interaction operators consider, ignore, and assert
Figure B-30: Interaction operators consider, ignore, and assert.
<Day Day Up>
<Day Day Up>
Communication Diagram
Chapter 9 covers the Communication diagram.
Figure B-31: Communication diagram notation.
<Day Day Up>
<Day Day Up>
Interaction Overview Diagram
Chapter 9 addresses the Interaction Overview diagram.
Figure B-32: Interaction Overview notation.
Figure B-33: Interaction Overview lifeline notation.
<Day Day Up>
<Day Day Up>
Timing Diagram
The Timing diagram is discussed in Chapter 9.
Figure B-34: Timing diagram notation.
Figure B-35: Timing diagram alternative notation.
<Day Day Up>
<Day Day Up>
Statechart Diagram Notation
Chapter 11 discusses the Statechart diagram.
Initial and final state, state, transition with guard
Figure B-36: Statechart notation (1).
When and after clauses
Figure B-37: When and after clauses.
Transition syntax
Event-name (comma-separated-parameter-list)
[guard-condition] / action-expression
Self-transition, and entry and exit actions
Figure B-38: Self-transition, and entry and exit actions.
Static branch state
Figure B-39: Static branch state.
Dynamic choice point
Figure B-40: Dynamic choice point.
Composite state
Figure B-41: Composite state.
Deep and shallow history
Figure B-42: Deep and shallow history.
Concurrent substates
Figure B-43: Concurrent substates.
Split and merge of control
Figure B-44: Split and merge of control.
Submachine state and stub states
Figure B-45: Submachine state and stub states.
Synch states
Figure B-46: Synch states (Sync state still appears in the UML 2.0 glossary but is not part of the UML 2.0
specification.)
Action specification with send and receive signals
Figure B-47: Action specification with send and receive signals.
NoteThe gray highlighted rectangles are for emphasis only.
Activity and completion transition
Figure B-48: Activity and completion transition.
Two ways to model common transitions
Figure B-49: Two ways to model common transitions.
Protocol state machine and generalization
Figure B-50: Protocol state machine and generalization.
<Day Day Up>
<Day Day Up>
Use Case Diagram
The Use Case diagram is covered in Chapter 12.
Figure B-51: Use Case diagram notation.
<Day Day Up>
<Day Day Up>
Activity Diagram
Chapter 13 has details on the Activity diagram.
Start, end, decision (split), and merge
Figure B-52: Start, end, decision (split), and merge.
Concurrency using fork and join nodes
Figure B-53: Fork and join notation.
Activity, transition, and transition guard
Figure B-54: Activity, transition, and transition guard.
<Day Day Up>
<Day Day Up>
Component Diagram
Chapter 15 discusses the Component diagram.
Figure B-55: Component diagram notation.
Alternative notations for realizing classes
Figure B-56: Alternative notation for realizing classes.
<Day Day Up>
<Day Day Up>
Deployment Diagram
Chapter 16 provides details on the Deployment diagram.
Figure B-57: Nodes defined as classifiers, with attributes and operations, at type and instance levels.
Figure B-58: Component diagram at type and instance levels.
<Day Day Up>
<Day Day Up>
Combined Component and Deployment Diagram
This topic is covered in Chapter 17.
Artifacts that implement components
Figure B-59: Artifacts that implement components.
Component deployment on a node instance
Figure B-60: Deployment of a component on a node instance.
Deployment specification
Figure B-61: Deployment specification.
Deployed components
Figure B-62: Deployed components.
<Day Day Up>
<Day Day Up>
Packages
Basic Package diagram
Packages as namespaces
Figure B-63: Packages as namespaces.
Package containment notation alternatives
Figure B-64: Package containment notation alternatives.
Access dependency
Figure B-65: Access dependency.
Merge dependency
Figure B-66: Merge dependency.
Subsystem diagram
Subsystem notation alternatives
Figure B-67: Subsystem notation alternatives.
Subsystem interface notation
Figure B-68: Subsystem interface notation.
Subsystem realization
Figure B-69: Subsystem realization.
Model diagram
Model notation
Figure B-70: Model notation.
<Day Day Up>
<Day Day Up>
Appendix C: Standard Elements
Throughout the text, reference is made to a number of predefined stereotypes. Table C-1 provides a complete list
of the stereotypes included as part of the UML specification, where they are defined, what they apply to (class,
package, and so forth), and a brief description. While these stereotypes are commonly accepted, remember that
stereotypes are an extension mechanism. So you can expect many more to be developed, and you are free to
develop your own.
Table C-1: Standard Elements
Name Subpackage Applies to Description
auxiliary Kernel Class A class that supports another more central
or fundamental class, typically by
implementing secondary logic or control
flow. The class that the auxiliary supports
may be defined explicitly using a Focus
class or implicitly by a dependency
relationship. Auxiliary classes are typically
used together with Focus classes, and are
particularly useful for specifying the
secondary business logic or control flow of
components during design. See focus.
buildComponent Components Component A collection component that defines a set
for organizational or system level
development purposes.
call Dependencies Usage A usage dependency whose source is an
operation and whose target is an operation.
The relationship may also be subsumed to
the class containing an operation, with the
meaning that there exists an operation in the
class to which the dependency applies. A
call dependency specifies that the source
operation or an operation in the source
class invokes the target operation or an
operation in the target class. A call
dependency may connect a source
operation to any target operation that is
within scope including, but not limited to,
operations of the enclosing classifier and
operations of other visible classifiers.
create Dependencies Usage A usage dependency denoting that the
client classifier creates instances of the
supplier classifier.
Name Subpackage Applies to Description
supplier classifier.
create Kernel BehavioralFeature Specifies that the designated feature
creates an instance of the classifier to which
the feature is attached. May be promoted to
the Classifier containing the feature.
derive Dependencies Abstraction Specifies a derivation relationship among
model elements that are usually, but not
necessarily, of the same type. A derived
dependency specifies that the client may be
computed from the supplier. The mapping
specifies the computation. The client may
be implemented for design reasons, such
as efficiency, even though it is logically
redundant.
destroy Kernel BehavioralFeature Specifies that the designated feature
destroys an instance of the classifier to
which the feature is attached. May be
promoted to the classifier containing the
feature.
document Deployments Artifact A generic file that is not a source file or
executable. Subclass of file.
entity Components Component A persistent information component
representing a business concept.
executable Deployments Artifact A program file that can be executed on a
computer system. Subclass of file.
file Deployments Artifact A physical file in the context of the system
developed.
focus Kernel Class A class that defines the core logic or control
flow for one or more auxiliary classes that
support it. Support classes may be defined
explicitly using Auxiliary classes or implicitly
by dependency relationships. Focus classes
are typically used together with one or more
Auxiliary classes, and are particularly useful
for specifying the core business logic or
control flow of components during design.
See auxiliary.
framework Kernel Package A package that contains model elements
that specify a reusable architecture for all or
part of a system. Frameworks typically
include classes, patterns, or templates.
When frameworks are specialized for an
application domain, they are sometimes
referred to as application frameworks.
supplier classifier.
create Kernel BehavioralFeature Specifies that the designated feature
creates an instance of the classifier to which
the feature is attached. May be promoted to
the Classifier containing the feature.
derive Dependencies Abstraction Specifies a derivation relationship among
model elements that are usually, but not
necessarily, of the same type. A derived
dependency specifies that the client may be
computed from the supplier. The mapping
specifies the computation. The client may
be implemented for design reasons, such
as efficiency, even though it is logically
redundant.
destroy Kernel BehavioralFeature Specifies that the designated feature
destroys an instance of the classifier to
which the feature is attached. May be
promoted to the classifier containing the
feature.
document Deployments Artifact A generic file that is not a source file or
executable. Subclass of file.
entity Components Component A persistent information component
representing a business concept.
executable Deployments Artifact A program file that can be executed on a
computer system. Subclass of file.
file Deployments Artifact A physical file in the context of the system
developed.
focus Kernel Class A class that defines the core logic or control
flow for one or more auxiliary classes that
support it. Support classes may be defined
explicitly using Auxiliary classes or implicitly
by dependency relationships. Focus classes
are typically used together with one or more
Auxiliary classes, and are particularly useful
for specifying the core business logic or
control flow of components during design.
See auxiliary.
framework Kernel Package A package that contains model elements
that specify a reusable architecture for all or
part of a system. Frameworks typically
include classes, patterns, or templates.
When frameworks are specialized for an
application domain, they are sometimes
referred to as application frameworks.
Name Subpackage Applies to Description
referred to as application frameworks.
implement Components Component A component definition that is not intended
to have a specification itself. Rather, it is an
implementation for a separate
specification to which it has a
Dependency.
implementation
Class
Classes Class The implementation of a class in some
programming language (C++, Smalltalk, or
Java, for example) in which an instance may
not have more than one class. This is in
contrast to Class, for which an instance may
have multiple classes at one time and may
gain or lose classes over time, and an
object (a child of instance), which may
dynamically have multiple classes. An
Implementation class is said to realize a
Classifier if it provides all of the operations
defined for the Classifier with the same
behavior as specified for the Classifier's
operations. An Implementation class may
realize a number of different Types. Note
that the physical attributes and associations
of the Implementation class do not have to
be the same as those of any Classifier it
realizes and that the Implementation Class
may provide methods for its operations in
terms of its physical attributes and
associations. See type.
instantiate Dependencies Usage A usage dependency among classifiers
indicating that operations on the client
create instances of the supplier.
library Deployments Artifact A static or dynamic library file. Subclass of
file.
metaclass Kernel Class A class whose instances are also classes.
metamodel Model
Management
Model A model of a model, that typically contains
metaclasses. See metaclass.
modelLibrary Kernel Package A package that contains model elements
that are intended to be reused by other
packages. A model library differs from a
profile in that a model library does not
extend the metamodel using stereotypes
and tagged definitions. A model library is
analogous to a class library in some
programming languages.
process Components Component A transaction based component.
realization Kernel Classifier A classifier that specifies a domain of
referred to as application frameworks.
implement Components Component A component definition that is not intended
to have a specification itself. Rather, it is an
implementation for a separate
specification to which it has a
Dependency.
implementation
Class
Classes Class The implementation of a class in some
programming language (C++, Smalltalk, or
Java, for example) in which an instance may
not have more than one class. This is in
contrast to Class, for which an instance may
have multiple classes at one time and may
gain or lose classes over time, and an
object (a child of instance), which may
dynamically have multiple classes. An
Implementation class is said to realize a
Classifier if it provides all of the operations
defined for the Classifier with the same
behavior as specified for the Classifier's
operations. An Implementation class may
realize a number of different Types. Note
that the physical attributes and associations
of the Implementation class do not have to
be the same as those of any Classifier it
realizes and that the Implementation Class
may provide methods for its operations in
terms of its physical attributes and
associations. See type.
instantiate Dependencies Usage A usage dependency among classifiers
indicating that operations on the client
create instances of the supplier.
library Deployments Artifact A static or dynamic library file. Subclass of
file.
metaclass Kernel Class A class whose instances are also classes.
metamodel Model
Management
Model A model of a model, that typically contains
metaclasses. See metaclass.
modelLibrary Kernel Package A package that contains model elements
that are intended to be reused by other
packages. A model library differs from a
profile in that a model library does not
extend the metamodel using stereotypes
and tagged definitions. A model library is
analogous to a class library in some
programming languages.
process Components Component A transaction based component.
realization Kernel Classifier A classifier that specifies a domain of
Name Subpackage Applies to Description
realization Kernel Classifier A classifier that specifies a domain of
objects and that also defines the physical
implementation of those objects. For
example, a Component stereotyped by
realization will only have
realizingClassifiers that implement behavior
specified by a separate specification
Component. This differs from
implementation class because an
implementation class is a realization of a
Class that can have features such as
attributes and methods, which is useful to
system designers. See specification.
refine Dependencies Abstraction Specifies a refinement relationship between
model elements at different semantic levels,
such as analysis and design. The mapping
specifies the relationship between the two
elements or sets of elements. The mapping
may or may not be computable, and it may
be unidirectional or bidirectional.
Refinement can be used to model
transformations from analysis to design and
other such changes.
responsibility Kernel Usage A contract or an obligation of an element in
its relationship to other elements.
script Deployments Artifact A script file that can be interpreted by a
computer system. Subclass of file.
send Dependencies Usage A usage dependency whose source is an
operation and whose target is a signal,
specifying that the source sends the target
signal.
service Components Component A stateless, functional component
(computes a value).
source Deployments Artifact A source file that can be compiled into an
executable file. Subclass of file.
specification Kernel Classifier A classifier that specifies a domain of
objects without defining the physical
implementation of those objects. For
example, a Component stereotyped by
specification will only have provided and
required interfaces, and is not intended to
have any realizingClassifiers as part of its
definition. This differs from type because
a type can have features such as
attributes and methods, which is useful to
analysts modeling systems. See
realization.
realization Kernel Classifier A classifier that specifies a domain of
objects and that also defines the physical
implementation of those objects. For
example, a Component stereotyped by
realization will only have
realizingClassifiers that implement behavior
specified by a separate specification
Component. This differs from
implementation class because an
implementation class is a realization of a
Class that can have features such as
attributes and methods, which is useful to
system designers. See specification.
refine Dependencies Abstraction Specifies a refinement relationship between
model elements at different semantic levels,
such as analysis and design. The mapping
specifies the relationship between the two
elements or sets of elements. The mapping
may or may not be computable, and it may
be unidirectional or bidirectional.
Refinement can be used to model
transformations from analysis to design and
other such changes.
responsibility Kernel Usage A contract or an obligation of an element in
its relationship to other elements.
script Deployments Artifact A script file that can be interpreted by a
computer system. Subclass of file.
send Dependencies Usage A usage dependency whose source is an
operation and whose target is a signal,
specifying that the source sends the target
signal.
service Components Component A stateless, functional component
(computes a value).
source Deployments Artifact A source file that can be compiled into an
executable file. Subclass of file.
specification Kernel Classifier A classifier that specifies a domain of
objects without defining the physical
implementation of those objects. For
example, a Component stereotyped by
specification will only have provided and
required interfaces, and is not intended to
have any realizingClassifiers as part of its
definition. This differs from type because
a type can have features such as
attributes and methods, which is useful to
analysts modeling systems. See
realization.
Name Subpackage Applies to Description
realization.
subsystem Components Component A unit of hierarchical decomposition for
large systems. Definitions of subsystems
vary widely among domains and methods,
and it is expected that domain and method
profiles will specialize this construct.
systemModel Model
Management
Model A systemModel is a stereotyped model that
contains a collection of models of the same
physical system. A systemModel also
contains all relationships and constraints
between model elements contained in
different models.
trace Dependencies Abstraction Specifies a trace relationship between
model elements or sets of model elements
that represent the same concept in different
models. Traces are mainly used for tracking
requirements and changes across models.
Since model changes can occur in both
directions, the directionality of the
dependency can often be ignored. The
mapping specifies the relationship between
the two, but it is rarely computable and is
usually informal.
type Classes Class A class that specifies a domain of objects
together with the operations applicable to
the objects, without defining the physical
implementation of those objects. However, it
may have attributes and associations.
Behavioral specifications for type operations
may be expressed using, for example,
activity diagrams. An object may have at
most one implementation class, however it
may conform to multiple different types. See
implementationClass.
utility Classes Class A class that has no instances, but rather
denotes a named collection of non-member
attributes and operations, all of which are
class-scoped.
Table C-2 lists predefined standard elements for UML 1.x that are now obsolete.
Table C-2: Retired Standard Elements
Standard Element Name Applies to Base Element
access Permission
realization.
subsystem Components Component A unit of hierarchical decomposition for
large systems. Definitions of subsystems
vary widely among domains and methods,
and it is expected that domain and method
profiles will specialize this construct.
systemModel Model
Management
Model A systemModel is a stereotyped model that
contains a collection of models of the same
physical system. A systemModel also
contains all relationships and constraints
between model elements contained in
different models.
trace Dependencies Abstraction Specifies a trace relationship between
model elements or sets of model elements
that represent the same concept in different
models. Traces are mainly used for tracking
requirements and changes across models.
Since model changes can occur in both
directions, the directionality of the
dependency can often be ignored. The
mapping specifies the relationship between
the two, but it is rarely computable and is
usually informal.
type Classes Class A class that specifies a domain of objects
together with the operations applicable to
the objects, without defining the physical
implementation of those objects. However, it
may have attributes and associations.
Behavioral specifications for type operations
may be expressed using, for example,
activity diagrams. An object may have at
most one implementation class, however it
may conform to multiple different types. See
implementationClass.
utility Classes Class A class that has no instances, but rather
denotes a named collection of non-member
attributes and operations, all of which are
class-scoped.
Table C-2 lists predefined standard elements for UML 1.x that are now obsolete.
Table C-2: Retired Standard Elements
Standard Element Name Applies to Base Element
Standard Element Name Applies to Base Element
access Permission
appliedProfile Package
association AssociationEnd
copy Flow
create CallEvent
create Usage
destroy CallEvent
facade Package
friend Permission
invariant Constraint
local AssociationEnd
parameter AssociationEnd
postcondition Constraint
powertype Class
precondition Constraint
profile Package
realize Abstraction
requirement Comment
self AssociationEnd
signalflow ObjectFlowState
stateInvariant Constraint
stub Package
table Artifact
thread Classifier
topLevel Package
<Day Day Up>
access Permission
appliedProfile Package
association AssociationEnd
copy Flow
create CallEvent
create Usage
destroy CallEvent
facade Package
friend Permission
invariant Constraint
local AssociationEnd
parameter AssociationEnd
postcondition Constraint
powertype Class
precondition Constraint
profile Package
realize Abstraction
requirement Comment
self AssociationEnd
signalflow ObjectFlowState
stateInvariant Constraint
stub Package
table Artifact
thread Classifier
topLevel Package
<Day Day Up>
<Day Day Up>
Glossary
A
abstract class
A class that cannot be directly instantiated because at least one operation lacks a method
(implementation). Any superclass may be abstract because the implementation can be provided by a
subclass. An abstract class is identified either by italicizing the class name or by adding the property
{abstract} to the operations that do not have a corresponding method, that is, the operations that prevent
the class from being instantiated.
Figure GL-1: Notation options for abstract classes.
See also concrete class .
abstraction
A representation of an entity that includes only those properties that support the proposed use of the
representation, and sufficient to distinguish it from all other kinds of entities. An abstraction defines a
boundary relative to the perspective of the viewer. Also, the process of choosing information to include in
the representation of an entity based on how and why the user plans to use the representation.
action
An action is the fundamental unit of behavior specification and represents some transformation or
processing in the modeled system, be it a computer system or a real-world system. Actions are contained in
an activity-expression , which provide their context. An action typically results in a change in the state of the
system, and can be realized by sending a message to an object, modifying an attribute value, or by
modifying a link.
See also entry action .
See also exit action .
See also action .
See also Activity diagram .
action sequence
An expression that resolves to an ordered set of actions that occur during a transition. The series may be
expressed as a textual description of a state transition, or as an icon in a State Machine diagram, that is, a
rectangle containing the series of actions.
Figure GL-2: Action sequence notation.
action state
A state of an object during which a single entry action is performed. The completion of entry action
generates the completion event that triggers the transition out of the state. Multiple outgoing transitions are
allowed if they are differentiated by guard conditions (UML 1.4).
See also focus of control .
activation
In a sequence diagram, the time during which an object is performing an action.
Figure GL-3: Activation in a Sequence diagram (UML 1.4).
See also focus of control .
active class
A class whose instances are active objects.
See also active object .
active object
An object that may execute its own behavior without requiring method invocation. This is sometimes
referred to as "the object having its own thread of control." The point at which an active object responds to
communications from other objects is determined solely by the behavior of the active object and not by the
invoking object. This implies that an active object is both autonomous and interactive to some degree.
Figure GL-4: An active object modeled using a bold outline.
See also active class .
See also thread (of control) .
Activity diagram
A diagram that depicts behavior using a control and dataflow model.
activity-expression
A sequence of actions associated with a state transition.
trigger-signature ['['guard-constraint']'] '/' activity-expression
activity partition
A grouping mechanism used in an Activity diagram to identify actions that have some characteristic in
common. They are often used to represent organizational units in a business model.
Figure GL-5: Activity partitions.
See also swimlane .
actor (class)
A role employed in a Use Case diagram that a user or any other system or device plays when it interacts
with the subject (system) under consideration. It is a type of entity that interacts with but is external to the
subject. Actors may represent human users, external hardware, or other subjects. An actor does not
necessarily represent a specific physical entity. For instance, a single physical entity may play the role of
several different actors and, conversely, a given actor may be played by multiple physical entities.
Figure GL-6: An actor icon in a Use Case diagram.
actual parameter
See also argument .
aggregate (class)
A class that represents the "whole" (the point of control in an assembly of classes) in an aggregation
(whole-part) relationship.
See also aggregation .
aggregation
A special form of association that specifies a whole-part relationship between the aggregate (whole) and a
component part. The relationship is used to insure the integrity of a configuration of objects. The
aggregation symbol is a hollow diamond on the end of the association next to the class that represents the
whole in the whole-part relationship.
Figure GL-7: Aggregation symbol is a hollow diamond.
See also composition .
analysis
The part of the software development process whose primary purpose is to formulate a model of the
problem domain that is independent of implementation considerations. Analysis focuses on what to do;
design focuses on how to do it.
See also design .
analysis time
Refers to something that occurs during an analysis phase of the software development process.
See also design time .
See also modeling time .
architecture
The organizational structure and associated behavior of a system. An architecture can be recursively
decomposed into parts that interact through interfaces, relationships that connect parts, and constraints for
assembling parts. Parts that interact through interfaces include classes, components, and subsystems.
argument
A binding for a parameter that is resolved later. An independent variable.
See also actual parameter .
See also parameter .
artifact
A physical piece of information that is used or produced by a software development process. Examples of
artifacts include models, source files, scripts, and binary executable files. An artifact may constitute the
implementation of a deployable component. Synonym: product.
See also component .
association
The semantic relationship between two or more classifiers that specifies the allowed connections among
their instances.
Figure GL-8: Two associations between the same pair of classes.
association class
A model element that has both association and class properties. It is a class that encapsulates information
about a relationship, such as when it starts and ends, and its current status.
Figure GL-9: Here Contract is an association class.
association end
The endpoint of an association, which connects the association to a classifier. The end encapsulates the
rules that determine if and how the connected classifier may participate in the association. UML 2.0 does
not define a metaclass for an association end. Instead it draws a relationship between the Association and
Property metaclasses and assigns the role name "member end" to the participating properties.
attribute
A structural feature of a classifier that characterizes instances of the classifier. An attribute relates an
instance of a classifier to a value or values through a named relationship.
[visibility] [/] name [: type] [ multiplicity] [=default] [{property-string}]
attribute compartment
A predefined compartment within a class definition that contains the attribute specifications for one class.
Figure GL-10: Attribute compartment.
auxiliary class
A stereotyped class that supports another more central or fundamental class, usually by implementing
secondary logic or control flow. Auxiliary classes are typically used together with focus classes, and are
particularly useful for specifying the secondary business logic or control flow of components during design.
See also focus class .
<Day Day Up>
<Day Day Up>
B-C
behavior
The observable effects of an operation or event, including its results. The description of a behavior can
take a number of forms: interaction, state machine, activity, or procedure (a set of actions).
behavioral feature
A dynamic feature of a model element, such as an operation or method.
behavioral model aspect
A model aspect that emphasizes the behavior of the instances in a system, including their methods,
collaborations, and state histories.
binary association
An association between two classes. A special case of an n-ary association.
See also association.
binding
The creation of a model element from a template by supplying arguments for the parameters of the
template.
Boolean
An enumeration whose values are True and False.
Boolean expression
An expression that evaluates to a Boolean value.
call
An action state that invokes an operation on a classifier.
cardinality
The number of elements in a set.
See also multiplicity.
child
In a generalization relationship, the specialization of another element the parent.
Figure GL-11: Parent and child classes in an inheritance hierarchy/tree.
See also subclass.
See also parent.
class
A description of a set of objects that share the same attributes (properties), operations, methods,
relationships, constraints, and semantics. A class may use a set of interfaces to specify collections of
operations it provides to its environment. UML 2.0 defines a class as a type of classifier that describes
a set of objects that share the same features.
Figure GL-12: Class icon examples include fully expanded (top), suppressed attributes and
operations (bottom left), and stereotype icon (bottom right).
See also interface.
Class diagram
A diagram that represents the resources of a subject area as classes, associations between classes,
and generalizations. It models the purpose and features of the resources essential to the proper
operation of the subject area.
class path
A naming specification that includes both the class name and the package location of the class; for
example, package:: classname as in Superstructure :: Classes and
OrderSystem::AccountsReceivable :: Account.
class template
A descriptor for a class with unbound formal parameters. The class may not be used directly. It has to
be used to create a class by binding parameter values.
Figure GL-13: Template class.
classification
The assignment of an object to a classifier.
See also dynamic classification.
See also multiple classification.
See also static classification.
classifier
A collection of instances that have something in common. A classifier can have features that
characterize its instances. Classifiers include interfaces, classes, data types, and components.
class-level attribute
An attribute that defines a class instead of an instance of the class; also called a static or class-scoped
attribute. Designated by underlining the attribute declaration.
Figure GL-14: Class/static attribute notation (underline the attribute declaration).
See also class-level operation.
class-level operation
An operation that defines a class instead of an instance of the class; also called a static or class-
scoped operation. Designated by underlining the operation declaration. Refer to the
getNextTicketNbr() operation in Figure GL-14.
See also class-level attribute.
client
A classifier that requests a service from another classifier.
See also supplier.
cohesion
A measure of the degree to which all of the parts of an entity contribute to the same purpose. Low
cohesion means that elements in the same entity support different goals; high cohesion means that all
elements within an entity support the same goal.
See also coupling.
collaboration
The specification of how an operation or classifier, such as a use case, is realized by a set of
classifiers and associations playing specific roles used in a specific way. The collaboration defines an
interaction.
See also interaction.
Collaboration diagram (UML 1.4)
A diagram that shows interactions organized around the structure of a model, using either classifiers
and associations, or instances and links. Unlike a Sequence diagram, a Collaboration diagram shows
the relationships among the instances. Sequence diagrams and Collaboration diagrams express
similar information, but show it in different ways. UML 1.4.
Figure GL-15: Collaboration diagram example.
See also Sequence diagram.
See also Communication diagram (UML 2.0).
collaboration occurrence
A particular use of a collaboration to explain the relationships between the parts of a classifier, or the
properties of an operation. It may also be used to indicate how a collaboration represents a classifier
or an operation. A collaboration occurrence defines a set of roles and connectors that cooperate
within the classifier or operation. There may be multiple occurrences of a given collaboration within a
classifier or operation, each involving a different set of roles and connectors. A given role or connector
may be involved in multiple occurrences of the same or different collaborations.
Figure GL-16: A collaboration occurrence to explain an operation.
See also collaboration.
comment (UML 1.4)
An annotation attached to an element or a collection of elements. A comment has no semantics. See:
Note (UML 2.0)
Figure GL-17: Comment icon attached to the attribute that it references.
See also constraint.
Communication diagram (UML 2.0)
A diagram that shows interactions organized around the structure of a model, using either classifiers
and associations, or instances and links. Unlike a Sequence diagram, a Communication diagram
shows the relationships among the instances. Sequence diagrams and Communication diagrams
express similar information, but show it in different ways. UML 1.4.
See also Sequence diagram.
See also Collaboration diagram (UML 1.4).
compartment
A partition within a model element such as a class, collaboration, or package.
Figure GL-18: Class compartments' notations.
See also attribute compartment.
See also operation compartment.
See also list compartment.
compile time
Refers to something that occurs during the compilation of a software module.
See also modeling time.
component
Represents a modular part of a system that encapsulates its contents, whose manifestation is
replaceable within its environment. A component defines its behavior in terms of provided and required
interfaces. As such, a component serves as a type, whose conformance is defined by these provided
and required interfaces (encompassing both their static as well as dynamic semantics). A component
is typically specified by one or more classifiers (such as implementation classes) that reside on it, and
may be implemented by one or more artifacts (binary, executable, or script files, for example).
Figure GL-19: Component icons for UML 1.4 and 2.0. UML 1.4 defines a single generic type of
interface. UML 2.0 differentiates between provided and required interfaces.
See also artifact.
Component diagram
A diagram that shows the organization and dependencies among components.
Figure GL-20: Component diagram examples from UML 1.4 and UML 2.0.
composite (class)
A class that is related to one or more classes by a composition relationship.
See also composition.
composite aggregation
See also composition.
composite state
A state that consists of either concurrent (orthogonal) substates or sequential (disjoint) substates.
Figure GL-21: Composite states.
See also substate.
Composite Structure diagram
A diagram that depicts the parts of a classifier, including the interaction points of the classifier to other
parts of the system. It shows the configuration of parts that jointly perform the behavior of the
containing classifier. The architecture diagram specifies a set of instances playing parts (roles), as well
as their required relationships, given in a particular context.
Figure GL-22: Composite Structure diagram example.
composition
A form of aggregation requiring that a part instance be included in, at most, one aggregate relationship
at a time, and that the aggregate object be responsible for the creation and destruction of the parts.
Composition may be recursive.
Figure GL-23: Composition notation (solid diamond).
See also composite aggregation.
See also aggregation.
concrete class
A class that can be directly instantiated because every operation (whether inherited or locally
specified) has a corresponding method.
See also abstract class.
concurrency
The occurrence of two or more activities during the same time interval. Concurrency can be achieved
by interleaving or simultaneously executing two or more threads.
Figure GL-24: Abstract and concrete classes in an inheritance hierarchy/tree.
Figure GL-25: Concurrency in an Activity diagram.
See also thread (of control).
concurrent substate
A substate that can be held simultaneously with other substates contained in the same composite
state.
Figure GL-26: Concurrent substates.
See also composite state.
See also disjoint substate.
Conditional node
A specialized type of structured activity node that represents a choice in which only one alternative can
be selected. A conditional node defines one or more clauses. Each clause specifies a test and a body.
A conditional node is defines two additional Boolean attributes, isDetermined and isAssured.
connectable element
An abstract metaclass representing model elements that may be linked via a connector.
See also connector.
connector
A link that enables communication between two or more instances. The link may be realized by
something as simple as a pointer or as complex as a network connection.
constraint
A semantic condition or restriction. It can be expressed in natural language text, mathematically formal
notation, or a machine-readable language for the purpose of declaring some of the semantics of a
model element. Certain constraints are predefined in the UML; others may be user-defined.
Constraints appear within curly braces when used on a diagram. Constraints are one of three
extensibility mechanisms in UML.
The code line shows a constraint specification on an operation (using freeform text).
SetDuration(new_duration:int) : void {the new duration may
Not cause overlap with another scheduled Event}
See also tagged value.
See also stereotype.
See also Object Constraint Language (OCL).
container
An instance that exists to contain other instances and that provides operations to access or iterate over
its contents, for example, arrays, lists, sets. Also, a component that exists to contain other
components.
Figure GL-27: Conditional node.
Figure GL-28: Constraint on an association end (using freeform text).
containment hierarchy
A namespace hierarchy consisting of model elements, and the containment relationships that exist
between them. A containment hierarchy forms a graph.
Figure GL-29: Physical containment and a containment hierarchy are two ways to model
containment.
context
A view of a set of related modeling elements for a particular purpose, such as specifying an operation.
coupling
A measure of the degree of dependence between elements. Dependency implies communication;
consequently, as dependency increases, communication often increases. If a lot of dependency
relationships are drawn between elements, those elements are highly coupled. A disadvantage to
highly coupled systems is that a change to an object often requires changes to the objects that
depend on it.
<Day Day Up>
<Day Day Up>
D-E
datatype
A descriptor of a set of values that lack identity (that is, they are pure values) and whose operations do not
have side effects. Datatypes include primitive predefined types and user-definable types. Predefined types
include numbers, string, and time. User-definable types include enumerations and other classes.
default
A value that is assigned to an element when no value is provided by the application. In UML 2.0, default
replaced initial value from UML 1.4.
[visibility] [/] name [: type] [multiplicity] [=default] [{property-string}]
defining model [MOF]
The model on which a repository is based. Any number of repositories can have the same defining model.
delegation
The ability of an object to issue a message to another object in response to a message. Delegation can be
used as an alternative to inheritance.
See also inheritance .
dependency
A relationship between two modeling elements, in which a change to one modeling element (the
independent element) affects the other modeling element (the dependent element). Dependency is
typically noted as a dashed arrow between model elements.
Figure GL-30: Dependency notation.
Deployment diagram
A diagram that shows execution architecture, that is, the configuration of runtime processing nodes and
the artifacts, processes, and objects that live on them. It represents system artifacts on nodes, which are
connected through communication paths to create network systems of arbitrary complexity. Nodes are
typically defined in a nested manner, and represent either hardware devices or software execution
environments. Artifacts represent runtime manifestations of code units.
Figure GL-31: Deployment diagram example.
See also Component diagram .
See also artifact .
See also component .
derived element
A model element that can be computed (or arrived at) using other elements, but that is shown for clarity or
that is included for design purposes even though it adds no semantic information. A derived attribute may
be designated by a forward slash (/) in front of an attribute declaration.
[visibility] [/] name [: type] [multiplicity] [=default] [{property-string}]
A derived association may be designated by a forward slash (/) in front of the association name or in front
of the role name on an association.
Figure GL-32: A derived association.
design
The part of the software development process whose primary purpose is to decide how the system will be
implemented. During design, strategic and tactical decisions are made to meet the required functional and
quality requirements of a system.
design time
Refers to something that occurs during a design phase of the software development process.
See also modeling time .
See also analysis time .
development process
A set of partially ordered steps performed for a given purpose (constructing or implementing models, for
example) during software development.
diagram
A graphical presentation of a collection of model elements, most often rendered as a connected graph of
arcs (relationships) and vertices (other model elements).
disjoint substate
A substate that cannot be held simultaneously with other substates contained in the same composite
state, such as Moving in 1
st
gear and Moving in 2
nd
gear in Figure GL-33 .
Figure GL-33: Disjoint substates.
See also composite state .
See also concurrent substate .
distribution unit
A set of objects or components that are allocated to a process or a processor as a group. A distribution
unit can be represented by a runtime composite or an aggregate.
domain
An area of knowledge or activity characterized by a set of concepts and terminology understood by
practitioners in that area.
dynamic classification
A semantic variation of generalization in which an object may change its classifier.
See also static classification .
element
A constituent of a model.
entry action
An action executed upon entering a state in a state machine, regardless of the transition taken to reach
that state.
Figure GL-34: Entry actions in a state icon.
enumeration
A list of named values used as the range of a particular attribute type. For example, RGBColor = {red,
green, blue}. Boolean is a predefined enumeration with values from the set {false, true}.
event
The specification of a significant occurrence that has a location in time and space. In the context of State
diagrams, an event is an occurrence that can trigger a transition.
Figure GL-35: Event on a state transition.
exception
A special kind of signal typically used to indicate fault situations. The sender of the exception aborts
execution, and execution resumes with the receiver of the exception, which may be the sender itself. The
receiver of an exception is determined implicitly by the interaction sequence during execution; it is not
explicitly specified.
execution occurrence
A unit of behavior within a lifeline on an interaction diagram, and bounded by two event occurrences.
exit action
An action executed upon leaving a state in a state machine regardless of the transition taken to exit that
state. See Figure GL-34 .
See also entry action .
See also internal transition .
See also Activity diagram .
Expansion node
A specialized type of structured activity that supports multiple executions of the same structured activity.
Values are passed into and out of the expansion region through expansion nodes. An expansion region
may execute in parallel, iterative, or stream modes.
Figure GL-36: Expansion region.
expression
A string that evaluates to a value of a particular type. For example, the expression "(7 + 5 * 3)" evaluates
to a value of type integer.
extend
A relationship from an extension use case to a base use case, specifying how the behavior defined for the
extension use case augments (subject to conditions specified in the extension) the behavior defined for the
base use case. The behavior is inserted at the location defined by the extension point in the base use
case. The base use case does not depend on performing the behavior of the extension use case.
See also extension .
See also include .
extension
Used to indicate that the properties of a metaclass are extended through a stereotype; provides the
capability to flexibly add and remove stereotypes from classes.
<Day Day Up>
<Day Day Up>
F-I
facade
A stereotyped package containing only references to model elements owned by another package. It is
used to provide a "public view" of some of the contents of a package.
feature
A property such as an operation or attribute that is encapsulated within a classifier, such as an
interface, a class, or a datatype.
Figure GL-37: The extend relationship between use cases.
Figure GL-38: Extension notation for dynamically adding stereotypes to a metaclass.
final state
A special kind (subclass) of state signifying that the enclosing composite state or the entire state
machine is completed.
Figure GL-39: Final state notation.
fire
To execute a state transition.
See also transition.
focus class
A stereotyped class that defines the core logic or control flow for one or more auxiliary classes that
support it. Focus classes are typically used together with one or more auxiliary classes, and are
particularly useful for specifying the core business logic or control flow of components during design.
Figure GL-40: Focus class in a component in a Deployment diagram.
See also auxiliary class.
focus of control
A symbol on a sequence diagram that shows the period of time during which an object is performing
an action, either directly or through a subordinate procedure.
Figure GL-41: Focus of control in a Sequence diagram.
formal parameter
See also parameter.
framework
A stereotyped package that contains model elements which specify a reusable architecture for all or
part of a system. Frameworks typically include classes, patterns, or templates. When frameworks are
specialized for an application domain, they are sometimes referred to as application frameworks.
See also pattern.
generalizable element
A model element that may participate in a generalization relationship.
See also generalization.
generalization
A taxonomic relationship between a more general classifier and a more specific classifier. Each
instance of the specific classifier is also an instance of the general classifier, thus the specific classifier
indirectly has features of the more general classifier. The more specific element is fully consistent with
the more general element, but may also override or add to the general definition. An instance of the
more specific element may be used wherever the more general element is allowed.
Figure GL-42: Generalization hierarchy/tree.
See also inheritance.
guard condition
A condition that must be satisfied in order to enable an associated transition to fire.
Figure GL-43: A guard condition ([amount=totalPrice]) on the transition event receivePayment.
implementation
A definition of how something is constructed or computed. For example, a class is an implementation
of a type; a method is an implementation of an operation.
implementation class
A stereotyped class that specifies the implementation of a class in some programming language
(C++, Smalltalk, or Java, for example) in which an instance may only have one class. An
implementation class is said to realize a type if it provides all of the operations defined for the type with
the same behavior as specified for the type's operations.
See also type.
implementation inheritance
The inheritance of the implementation of a more general element. Includes inheritance of the
interface.
See also interface inheritance.
import
In the context of packages, a dependency that shows the packages whose classes may be referenced
within a given package (including packages recursively embedded within it).
Figure GL-44: Import dependency between packages.
See also merge.
include
A relationship from a base use case to an inclusion use case, specifying how the behavior for the base
use case contains the behavior of the inclusion use case. The behavior is included at the location
defined in the base use case. The base use case depends on performing the behavior of the inclusion
use case, but not on its structure (that is, attributes or operations).
Figure GL-45: Include relationship between use cases.
See also extend.
inheritance
The mechanism by which more specific elements incorporate structure and behavior of more general
elements related by behavior.
See also generalization.
initial state
A special kind of state signifying the source for a single transition to the default state of the composite
state.
Figure GL-46: Initial state icon pointing to an initial state.
instance
An entity that has unique identity, a set of operations that can be applied to it, and state that stores the
effects of the operations.
See also object.
interaction
A specification of how stimuli are sent between instances to perform a specific task. The interaction is
defined in the context of a collaboration.
See also collaboration.
interaction diagram
A generic term that applies to several types of diagrams that emphasize object interactions. These
include Collaboration and Sequence diagrams in UML 1.4, and Sequence, Communication,
Interaction Overview, and Timing diagrams in UML 2.0.
interaction overview diagram
A diagram that depicts interactions through a variant of Activity diagrams in a way that promotes
overview of a control flow in which each node can be an interaction diagram.
Figure GL-47: Interaction overview diagram.
interface
A named set of operations that characterize the behavior of an element.
Figure GL-48: Interface notation alternatives.
See also provided interface.
See also required interface.
interface inheritance
The inheritance of the interface of a more general element (the method of the operation is not
inherited).
See also implementation inheritance.
internal transition
A transition signifying a response to an event without changing the state of an object. See Figure GL-
34.
See also entry action.
See also exit action.
See also Activity diagram.
<Day Day Up>
<Day Day Up>
L-M
layer
The organization of classifiers or packages at the same level of abstraction. A layer represents a
horizontal slice through an architecture, whereas a partition represents a vertical slice.
See also partition.
link
A semantic connection among a tuple of objects. Also, an instance of an association.
Figure GL-49: Objects and links.
See also association.
list compartment
A partition of a classifier that may hold a collection of like references, such as an attribute
compartment that contains attributes.
Figure GL-50: List compartment example.
See also attribute compartment.
See also operation compartment.
loop node
A specialized structured activity that defines a set of features to manage functions that need to be
performed repeatedly. The loop node is made up of a setupPart, test, and body pairs, and an output
value (decider) used to decide when to exit the loop. Each of these elements is a separate sub-region
within the loop node. Each contains one or more activity nodes and edges.
Figure GL-51: Loop node.
merge
See also package merge.
message
A specification of the conveyance of information from one instance to another, with the expectation
that activity will ensue. A message may specify the raising of a signal or the call of an operation.
messageident ::= [attribute=] signal-or-operation-name [(arguments)] [:
return-value]
arguments ::= argument [, arguments]
argument ::= parameter-name:argument-value | attribute argument-value |
metaclass
A class whose instances are classes. Metaclasses are typically used to construct metamodels.
meta-metamodel (3M)
A model that defines the language for expressing a metamodel. The relationship between a meta-
metamodel (3M) and a metamodel (2M) is analogous to the relationship between a metamodel and a
model.
metamodel (2M)
A model that defines the language for expressing a model.
metaobject
A generic term for all meta-entities in a metamodeling language; for example, metatypes,
metaclasses, meta-attributes, and meta-associations.
method
The implementation of an operation. It specifies the algorithm or procedure associated with an
operation.
model
An abstraction of a physical system with a certain purpose.
See also physical system.
model [MOF]
Usage note: In the context of the MOF specification, which describes a meta-metamodel, the meta-
metamodel is frequently referred to simply as the model.
model aspect
A dimension of modeling that emphasizes particular qualities of the metamodel. For example, the
structural model aspect emphasizes the structural qualities of the metamodel.
model elaboration
The process of generating a repository type from a published model. Includes the generation of
interfaces and implementations that enable repositories to be instantiated and populated based on,
and in compliance with, the model elaborated.
model element
An element that is an abstraction drawn from the system being modeled.
See also view element.
model element [MOF]
In the MOF specification, model elements are considered to be metaobjects.)
model library
A stereotyped package that contains model elements that are intended to be reused by other
packages. A model library differs from a profile in that a model library does not extend the metamodel
using stereotypes and tagged definitions. A model library is analogous to a class library in some
programming languages.
modeling time
Refers to something that occurs during a modeling phase of the software development process. It
includes analysis time and design time. (Usage note: When discussing object systems, it is often
important to distinguish between modeling-time and runtime concerns.)
See also analysis time.
See also design time.
See also runtime.
module
A software unit of storage and manipulation. A module may include source code, binary code, or
executable code.
See also component.
MOF (Meta Object Facility)
The MOF defines the foundation for creating modeling languages used for object modeling, such as
UML, and for data modeling, such as the Common Warehouse Model (CWM). The MOF defines
standard formats for the key elements of a model so that they can be stored in a common repository
and exchanged between modeling tools and languages.
multiple classification
A semantic variation of generalization in which an object may belong directly to more than one
classifier.
See also static classification.
See also dynamic classification.
multiple inheritance
A semantic variation of generalization in which a type may have more than one supertype.
Figure GL-52: Multiple inheritance example.
See also single inheritance.
multiplicity
A specification of the range of allowable cardinalities that a set may assume. Multiplicity specifications
may be given for roles within associations, parts within composites, repetitions, and other purposes.
Essentially a multiplicity is a (possibly infinite) subset of the non-negative integers.
Figure GL-53: Multiplicity on an association (ends).
See also cardinality.
multi-valued [MOF]
A model element with multiplicity defined whose Multiplicity Type :: upper attribute is set to a number
greater than one. The term multi-valued does not pertain to the number of values held by an attribute,
parameter, and so forth at any point in time.
lineItem[0..*]: LineItem
See also Single-valued [MOF].
<Day Day Up>
<Day Day Up>
N-P
name
A string used to identify a model element.
name compartment
A predefined class compartment containing the class name, stereotype, and properties.
Figure GL-54: Name compartment notation for a class.
namespace
A part of the model in which the names may be defined and used. Within a namespace, each name
has a unique meaning.
See also name.
n-ary association
An association among three or more classes. Each instance of the association is an n-tuple of values
from the respective classes.
Figure GL-55: N-ary association.
See also binary association.
node
A classifier that represents a runtime computational resource, which generally has at least a memory
and often processing capability. Runtime objects and components may reside on nodes.
Figure GL-56: Node notation for Deployment diagram.
note
(UML2.0) An annotation attached to an element or a collection of elements. A note has no semantics.
See also comment (UML 1.4).
object
An object is an instance of a class. An entity with a well-defined boundary and identity that
encapsulates state and behavior. State is represented by attributes and relationships. Behavior is
represented by operations, methods, and state machines.
Figure GL-57: Object notation.
See also class.
See also instance.
Object Constraint Language (OCL)
A formal language used to describe expressions in UML models. These expressions typically specify
invariant conditions that must hold for the system being modeled or queries over objects described in
a model. Note that when OCL expressions are evaluated, they do not have side effects; that is, their
evaluation cannot alter the state of the corresponding executing system. OCL expressions can be
used to specify operations or actions that, when executed, do alter the state of the system. UML
modelers can use OCL to specify application-specific constraints in their models. UML modelers can
also use OCL to specify queries on the UML model, which are completely programming-language
independent.
context ExpressionInOcl
inv: self.attribute->notEmpty()
and
self.attribute.owner->size() = 1
Object diagram
A diagram that encompasses objects and their relationships at a point in time. An Object diagram may
be considered a special case of a Class. It is most often used to model test cases and examples.
Figure GL-58: Object diagram.
See also Class diagram.
See also Collaboration diagram (UML 1.4).
See also Communication diagram (UML 2.0).
object flow
An activity edge that can have objects or data passing along it.
Figure GL-59: Object flow notation alternatives.
object lifeline
A line in a Sequence diagram that represents the existence of an object over a period of time.
Figure GL-60: Object lifelines.
See also Sequence diagram.
OMG [Object Management Group]
An independent consortium that overSees standards for software development, including the
standards for CORBA, XML, MOF, UML, and CWM.
operation
A feature which declares a service that can be performed by instances of the classifier of which they
are instances. An operation has a signature, which may restrict the actual parameters that are
possible, and uniquely defines the operation within a class.
getStreetAddress():Address
operation compartment
A predefined class compartment containing all of the operation specifications for the class. See Figure
GL-18, Operations compartment.
See also name compartment.
See also attribute compartment.
See also list compartment.
package
A general purpose mechanism for organizing elements into groups. Packages may be nested within
other packages. See Figure GL-61.
Package diagram
A diagram that depicts how model elements are organized into packages and the dependencies
among them, including package imports and package extensions.
Figure GL-61: Package diagram example.
package merge
A relationship between two packages, where the contents of the target package (the one pointed at) is
merged with the contents of the source package through specialization and redefinition, where
applicable. This is a mechanism that should be used when elements of the same name are intended
to represent the same concept, regardless of the package in which they are defined. A merging
package takes elements of the same kind with the same name from one or more packages and
merges them together into a single element using generalization and redefinitions.
Figure GL-62: Package merge.
package visibility
An element with package visibility is owned by a namespace that is not a package, and is visible to
elements that are in the same package as its owning namespace.
parameter
The specification of a variable that can be changed, passed, or returned. A parameter may include a
name, type, and direction. Parameters are used for operations, messages, and events.
getObjects( start : Date, end : Date)
See also formal parameter.
See also argument.
parameterized element
The descriptor for a class with one or more unbound parameters.
See also template.
parent
In a generalization relationship, the generalization of another element, the child. See Figure GL-11.
See also superclass.
See also child.
See also subclass.
See also subtype.
part
An element representing a set of instances that are owned by a containing classifier instance. Parts
may be joined by attached connectors and specify configurations of linked instances to be created
within an instance of the containing classifier.
Figure GL-63: Part notation within a Composite Structure diagram.
participate
The connection of a model element to a relationship or to a reified relationship. For example, a class
participates in an association; an actor participates in a use case.
partition
A portion of an Activity diagram that organizes the responsibilities for actions. See: swimlane. Also, a
set of related classifiers or packages at the same level of abstraction or across layers in a layered
architecture; a partition represents a vertical slice through an architecture.
See also layer.
pattern
A template collaboration that describes the structure of a design pattern. UML patterns are more
limited than those used by the design pattern community. In general, design patterns involve many
non-structural aspects, such as heuristics for their use and usage trade-offs. Such aspects are not
modeled in UML but could be associated with a collaboration.
persistent object
An object that exists after the process or thread that created it has ceased to exist.
physical system
The subject of a model. Also, a collection of connected physical units, which can include software,
hardware, and people, which are organized to accomplish a specific purpose. A physical system can
be described by one or more models, possibly from different viewpoints.
See also system.
pin
A model element that represents the data values passed into a behavior upon its invocation as well as
the data values returned from a behavior upon completion of its execution, identified as input pins
(InputPin) and output pins (OutputPin).
Figure GL-64: Input and output pins on a component.
port
A feature of a classifier that specifies a distinct interaction point between that classifier and its
environment or between the (behavior of the) classifier and its internal parts. Ports are connected to
other parts through connectors through which requests can be made to invoke the behavioral features
of a classifier.
Figure GL-65: Ports on the parts of a Composite Structure diagram.
post-condition
A constraint that must be true at the completion of a behavior such as after the execution of an
operation or use case.
powertype
A classifier whose instances are also subclasses of another classifier. Powertypes are metaclasses
with an extra twist: the instances are also subclasses. A powertype is designated with a colon followed
by the classifier name of the powertype.
Figure GL-66: Powertypes (Solo, Group, and so forth) used to specify two overlapping
generalizations.
pre-condition
A constraint that must be true when a behavior is invoked.
primitive type
A predefined data type without any relevant substructure (that is, it is not decomposable) such as an
integer or a string.
private visibility
An element with private visibility is only visible inside the namespace that owns it. Private visibility may
be designated by a minus sign (-) in front of the element.
name:String
getName():String
procedure
A set of actions that may be attached as a unit to other parts of a model, for example, as the body of a
method. Conceptually, a procedure, when executed, takes a set of values as arguments and
produces a set of values as results, as specified by the parameters of the procedure.
process
A heavyweight unit of concurrency and execution in an operating system. (Contrast with thread, which
includes heavyweight and lightweight processes. If necessary, an implementation distinction can be
made using stereotypes.) Also, the steps and guidelines by which to develop a software system. Also,
to execute an algorithm or otherwise handle something dynamically.
profile
A stereotyped package containing model elements that have been customized for a specific domain
or purpose using extension mechanisms, such as stereotypes, tagged definitions and constraints. A
profile may also specify model libraries on which it depends and the metamodel subset that it extends.
projection
A mapping from a set to one of its subsets.
property
A named value denoting a characteristic of an element. A property has semantic impact. Certain
properties are predefined in UML; others may be user-defined. When added to compartment or
element definition they can be enclosed within braces, such as {date=11-02-03}, and are typically
expressed with either tagged values or strings. See: tagged value. Properties may also be expressed
as a simple string.
protected visibility
An element with protected visibility is visible to elements that have a specialization relationship to the
namespace that owns it. Protected visibility may be designated by a pound sign (#) in front of the
element.
#name:String
#getName():String
provided interface
A service offered/supported by a class.
Figure GL-67: Provided interfaces are shown on left of the figure, to easily distinguish them from
the required' interface symbol on the right of the figure.
pseudo-state
A vertex in a state machine that has the form of a state but doesn't behave as a state. Pseudo-states
include initial and history vertices.
public visibility
An element with public visibility is visible to all elements that can access the contents of the
namespace that owns it. Public visibility may be designated by a plus sign (+) in front of the element.
+name:String
+getName():String
published model [MOF]
A model that has been frozen, and becomes available for instantiating repositories and for support in
defining other models. A frozen model's model elements cannot be changed.
<Day Day Up>
<Day Day Up>
Q-S
qualifier
An association attribute or tuple of attributes whose values partition the set of objects related to an
object across an association.
Figure GL-68: Qualified association.
realization
A specialized abstraction relationship between two sets of model elements, one representing a
specification (the supplier) and the other representing an implementation of the latter (the client,
realization). Realization can be used to model stepwise refinement, optimizations, transformations,
templates, model synthesis, framework composition, and so forth.
Figure GL-69: Realization dependency.
receive (a message)
The handling of a stimulus passed from a sender instance.
See also sender (object).
See also receiver (object).
receiver (object)
The object handling a stimulus passed from a sender object.
See also sender (object).
reception
A declaration that a classifier is prepared to react to the receipt of a signal.
reference
A denotation of a model element. Also, a named slot within a classifier that facilitates navigation to
other classifiers. Synonym: pointer.
refinement
A relationship that represents a fuller specification of something that has already been specified at a
certain level of detail. For example, a design class is a refinement of an analysis class.
Figure GL-70: Refinement dependency.
relationship
An abstract class that specifies the semantic connection among model elements. Examples of
relationships include associations and generalizations.
repository
A facility for storing object models, interfaces, and implementations. Each modeling element defined
in a UML diagram in the same modeling tool is stored within and shared from the same storage
facility. For example, a Car object defined on a Sequence diagram is the same Car object that
appears on an Activity diagram within the same project.
required interface
A service that a class defines as needed from another class. See Figure GL-67.
requirement
A desired feature, property, or behavior of a system.
responsibility
A contract or obligation of a classifier.
return-result
The datatype of the response from an operation; often referred to as the type of the operation.
operationName():return
reuse
The use of a pre-existing model element or artifact.
role
A description of how an entity participates in a relationship. Also, the named specific behavior of an
entity participating in a particular context. A role may be static (an association end, for example) or
dynamic (such as a collaboration role). A role may also be a synonym for association end often
referring to a subset of classifier instances that are participating in the association.
Figure GL-71: Role names on associations.
runtime
The period of time during which a computer program executes.
See also modeling time.
scenario
A specific sequence of actions that illustrates behaviors. A scenario may be used to illustrate an
interaction or the execution of a use case instance.
See also interaction.
schema [MOF]
In the context of the MOF, a schema is analogous to a package that is a container of model elements.
Schema corresponds to an MOF package.
See also metamodel (2M).
See also package.
semantic variation point
A point of variation in the semantics of a metamodel. It provides an intentional degree of freedom for
the interpretation of the metamodel semantics.
send (a message)
The passing of a stimulus from a sender instance to a receiver instance.
See also sender (object).
See also receiver (object).
sender (object)
The object passing a stimulus to a receiver object.
See also receiver (object).
Sequence diagram
A diagram that shows object interactions arranged in time sequence. In particular, it shows the objects
participating in the interaction and the sequence of messages exchanged. Unlike a Collaboration
diagram (UML 1.4) or Communication diagram (UML 2.0), a Sequence diagram includes time
sequences but does not include object relationships. A Sequence diagram can exist in a generic form
(describes all possible scenarios) and in an instance form (describes one actual scenario). Sequence
diagrams and Collaboration/Communication diagrams express similar information, but show it in
different ways.
Figure GL-72: Sequence diagram example.
See also Collaboration diagram (UML 1.4).
See also Communication diagram (UML 2.0).
signal
The specification of an asynchronous stimulus that triggers a reaction in the receiver in an
asynchronous way and without a reply. The receiving object handles the signal as specified by its
receptions. The data carried by a send request and passed to it by the occurrence of the send
invocation event that caused the request is represented as attributes of the signal instance. A signal is
defined independently of the classifiers handling the signal.
signature
The name and parameters of a behavioral feature. A signature may include an optional returned
parameter.
operationName(parm1 : datatype) : void
setSartDate(newDate : Date) : void
single inheritance
A semantic variation of generalization in which a type may have only one supertype. Synonym:
multiple inheritance [OMA].
See also multiple inheritance.
Single-valued [MOF]
A model element with multiplicity defined is single valued when its Multiplicity Type :: upper attribute is
set to 1. A single-valued attribute (for instance, with a multiplicity lower bound of 0) may have no value.
orderNbr[1]:int
See also multi-valued [MOF].
slot
A specification that an entity modeled by an instance has a value or values for a specific structural
feature. A slot defined on an object corresponds to an attribute defined on a class.
specialization
A class inherits all of the features of another class and either overrides or adds to the inherited class
specification. Also, the act of identifying characteristics of an object or set of objects sharing the same
class specification that do not share all the same attributes, operations, or relationships as other
members of the class. The unique elements of these objects are isolated and defined together under
a specialized class.
See also subclass.
specification
A declarative description of what something is or does.
See also implementation.
state
A condition or situation in the life of an object during which it satisfies some condition, performs some
activity, or waits for some event. An object's state is defined by (captured in) the values of its attributes.
Figure GL-73: Two forms of the state icon are elided (left) and expanded (right).
state machine
A behavior that specifies the sequences of states that an object or an interaction goes through during
its life in response to events, together with its responses and actions.
State Machine diagram
A UML 2.0 diagram that depicts discrete behavior modeled through finite state-transition systems. In
particular, it specifies the sequences of states that an object or an interaction goes through during its
life in response to events, together with its responses and actions.
See also state machine.
See also Statechart diagram.
Statechart diagram
A UML 1.4 diagram that shows a state machine.
See also state machine.
static classification
The assignment of an instance to a classifier where the assignment may not change to any other
classifier.
See also dynamic classification.
stereotype
A class that defines how an existing metaclass (or stereotype) may be extended, and enables the use
of platform- or domain-specific terminology or notation in addition to those used for the extended
metaclass. Certain stereotypes are predefined in UML; others may be user defined. Stereotypes are
one of the extensibility mechanisms in UML. A stereotype is denoted using guillemets, as in
stereotype.
Figure GL-74: Alternative forms of stereotyped class notation.
See also constraint.
See also tagged value.
stimulus
The passing of information from one instance to another, such as raising a signal or invoking an
operation. The receipt of a signal is normally considered an event.
See also message.
string
A sequence of text characters. The details of string representation depend on implementation, and
may include character sets that support international characters and graphics.
structural feature
A static feature of a model element, such as an attribute.
structural model aspect
A model aspect that emphasizes the structure of the objects in a system, including their types,
classes, relationships, attributes, and operations.
structured activity
Defines a unit of functionality that appears only once within the model, that is, a structured activity may
only be a part of one activity and its execution is independent of all other parts of the model. Structured
activities are specialized into expansion regions, conditional nodes, and loop nodes.
Figure GL-75: Structured activity.
subactivity state
(UML 1.4) A state in an Activity diagram that represents the execution of a non-atomic sequence of
steps that has some duration. Replaced by explicitly modeled actions in UML 2.0.
subclass
In a generalization relationship, the specialization of another class; the superclass.
See also generalization.
See also superclass.
See also child.
submachine state
A state in a state machine that is equivalent to a composite state, but its contents are described by
another state machine.
subpackage
A package that is contained in another package.
Figure GL-76: Superclass-subclass relationship in an inheritance hierarchy/tree.
Figure GL-77: A submachine state within a composite state.
Figure GL-78: Subpackages within a package.
substate
A state that is part of a composite state.
Figure GL-79: Non-orthogonal (single/same region) and orthogonal (concurrent) are two types of
substates.
See also concurrent substate.
See also disjoint substate.
subsystem
A grouping of model elements that represents a behavioral unit in a physical system. A subsystem
offers interfaces and has operations. In addition, the model elements of a subsystem can be
partitioned into specification and realization elements.
Figure GL-80: UML 1.4 Subsystem stereotypes on packages. In UML 2.0 the package symbol is
replaced by a simple rectangle with the subsystem stereotype.
See also component.
See also physical system.
subtype
In a generalization relationship, the specialization of another type, the supertype.
See also subclass.
See also generalization.
See also supertype.
superclass
In a generalization relationship, the generalization of another class/es (the subclass). See Figure GL-
76.
See also generalization.
See also subclass.
supertype
In a generalization relationship, the generalization of another type, the subtype.
See also generalization.
See also subtype.
supplier
A classifier that provides services that can be invoked by others.
See also client.
swimlane
See also activity partition.
synch state
A vertex in a state machine used for synchronizing the concurrent regions of a state machine.
Figure GL-81: Synch state.
system
An organized array of elements functioning as a unit. Also, a top-level subsystem in a model.
See also physical system.
<Day Day Up>
<Day Day Up>
T-V
tagged value
The explicit definition of a property as a name-value pair. In a tagged value, the name is referred to as
the tag. Certain tags are predefined in UML; others may be user defined. Tagged values are one of
three extensibility mechanisms in UML.
"lastUpdated=02-09-02"
"updatedBy=Tom"
See also constraint.
See also stereotype.
template
See also parameterized element.
thread (of control)
A single path of execution through a program, a dynamic model, or some other representation of
control flow. Also, a stereotype for the implementation of an active object as a lightweight process.
See also process.
time event
An event that denotes the time elapsed since the current state was entered.
See also event.
time expression
An expression that resolves to an absolute or relative value of time.
Timing diagram
An interaction diagram that shows the change in state or condition of a lifeline (representing a
Classifier Instance or Classifier Role) over linear time. The most common usage is to show the
change in state of an object over time in response to accepted events or stimuli. The format of the
diagram facilitates the description of time and duration constraints on state changes.
top level
topLevel is a package stereotype denoting the top-most package in a containment hierarchy. The
topLevel stereotype defines the outer limit for looking up names, as namespaces "See" outward.
For example, topLevel subsystem represents the top of the subsystem containment hierarchy.
trace
A dependency stereotype that indicates a historical or process relationship between two elements that
represent the same concept without specific rules for deriving one from the other.
transient object
An object that exists only during the execution of the process or thread that created it.
transition
The change from one state to another state triggered by an event. On such a change of state, the
transition is said to fire. A transition fires only if the associated conditions are satisfied. A transition
causes the interruption of activities in the current state, execution of exit actions in the current state,
event actions, and entry actions on the new state.
Figure GL-82: Transition with event, guard, and action.
type
A stereotyped class that specifies a domain of objects together with the operations applicable to the
objects, without defining the physical implementation of those objects. A type may not contain any
methods, maintain its own thread of control, or be nested. However, it may have attributes and
associations. Although an object may have at most one implementation class, it may conform to
multiple different types.
See also implementation class.
See also interface.
type expression
An expression that evaluates to a reference to one or more types.
use
In a use dependency, one element (the client) requires the presence of another element (the
supplier) for its correct functioning or implementation.
use case
The specification of a sequence of actions, including variants, that a system (or other entity) can
perform, interacting with actors of the system. Refer to Figure GL-83.
See also use case instance.
Use Case diagram
A diagram that shows the relationships among actors and use cases (features) within a system.
use case instance
The performance of a sequence of actions being specified in a use case.
See also scenario.
use case model
A model that describes a system's functional requirements in terms of use cases, use case narratives,
and scenarios.
Figure GL-83: Use Case diagram example.
utility
The utility stereotype groups global variables and procedures in the form of a class declaration. The
utility attributes and operations become global variables and global procedures, respectively. A utility is
not a fundamental modeling construct, but a programming convenience.
value
An element of a type domain.
vertex
A source or a target for a transition in a state machine. A vertex can be either a state or a pseudo-
state.
See also state.
See also pseudo-state.
view
A projection of a model Seen from a given perspective or vantage point and omitting entities that are
not relevant to that perspective.
view element
A view element is a textual and/or graphical projection of a collection of model elements.
view projection
A projection of model elements onto view elements. A view projection provides a location and a style
for each view element.
visibility
An enumeration whose value (public, protected, package, or private) denotes how the model element
to which it refers may be Seen outside its enclosing namespace.
private
+ public
# protected
~ package
<Day Day Up>
<Day Day Up>
Index
SYMBOLS
* (asterisk)
indicating message iteration, 258-259
indicating unlimited upper value of range, 127
multiplication operation, OCL, 615, 617
multiplication operator, OCL, 596
zero or more operator, XML, 737
{} (braces)
enclosing constraints, 71, 175-176
enclosing ordering for multiplicity, 128, 129
enclosing properties, 116-117, 139
enclosing state invariant, 286-288
enclosing tagged values, 70
enclosing uniqueness for multiplicity, 129
^ (caret), indicating message has been sent, 598-599, 608-609
->, collection property, 606
: (colon)
indicating attribute type, 135
indicating operation parameter type, 148
between object name and class name, 223
between role name and interface specifier in association, 172
, (comma), strict ordering operator, XML, 737
^^ (double caret), indicating set of messages sent, 608, 609
:: (double colon)
indicating value of an enumeration, 598
between nested substates, 356
between package name and class name, 112
- (double dash), indicating comment in OCL, 71
(ellipsis), indicating more subclasses, 203-204
= (equal sign)
equal to operation, OCL
for Bag, 624
for ModelElement types, 614
for OclAny, 613
for OclState, 615
for OclType, 614
for Sequence, 626
for Set, 621
indicating default value of attribute, 137-138
in properties, 116-117
in tagged values, 70
>= (greater than or equal to sign)
greater than or equal to operation, OCL, 617
greater than or equal to operator, OCL, 596
> (greater than sign)
greater than operation, OCL, 616
greater than operator, OCL, 596
"" (guillemets), enclosing stereotypes, 69
- (hyphen)
in class names, 110
indicating private visibility, 121, 514
subtraction operation, OCL, 615, 617, 622
subtraction operator, OCL, 596
<= (less than or equal to sign)
less than or equal to operation, OCL, 616
less than or equal to operator, OCL, 596
< (less than sign)
less than operation, OCL, 616
less than operator, OCL, 596
- (minus sign)
indicating private visibility, 121, 514
subtraction operation, OCL, 615, 617, 622
subtraction operator, OCL, 596
<> (not equal to sign)
not equal to operation, OCL, 613, 614, 615
not equal to operator, OCL, 596
() (parentheses)
enclosing operation parameters, 147-148
grouping operator, XML, 737
+ (plus sign)
addition operation, OCL, 615, 617
addition operator, OCL, 596
in circle, indicating package elements, 513
indicating public visibility, 121, 514
one or more operator, XML, 737
# (pound sign), indicating protected visibility, 121
@pre keyword, indicating beginning value of property, 599
? (question mark), zero or one operator, XML, 737
/ (slash)
division operation, OCL, 615, 617
division operator, OCL, 596
indicating derived association, 182-183
indicating derived attribute, 134
separating event from action, 333
[] (square brackets)
indicating context of association, 601
indicating message conditions, 259-260
indicating multiplicity, 126
indicating number of parts in class, 235
indicating qualifier for association, 602
~ (tilde), indicating package visibility, 121
| (vertical bar), selection operator, XML, 737
<Day Day Up>
<Day Day Up>
Index
A
A Comparison of the Booch Method and Shlaer-Mellor OOA/RD (Mellor), 637
abs() operation, 616, 617
abstract class
compared to interface, 160
definition of, 29, 92, 204
modeling, 204-205
in multiple generalization, 207
in UML 1.4, 29
abstract package, 512
{abstract} property, 512
abstract syntax for OCL, 589-590
abstraction dependency, 213-214, 215, 216
abstraction of objects, 76-78
Abstractions package, 41, 117
access control for modeling tools, 671-672
access dependency between packages, 515-516, 792, 832
access stereotype, 215, 515, 518, 841
action, See also action semantics
collection actions, 652-653
compared to procedure, 647
composite actions, 649-650
computation actions, 651
conditions on, 485-486
control flow for, 646
data flow for, 646
definition of, 14, 325, 639, 645
entry and exit actions, 334-335, 368, 778, 818
input and output pins for, 477-478, 645-646, 654-655
jump actions, 653-654
lifecycle of, 647
messaging actions, 653
modeling, 332-333, 467-469
multiple, modeling, 375-376
nested, 656
notation for, 823
parameters for, 490-492
primitive actions, 646
read and write actions, 650-651
Action package
categories of actions in, 648-649
collection actions, 652-653
composite actions, 649-650
computation actions, 651
jump actions, 653-654
messaging actions, 653
read and write actions, 650-651
action semantics
action languages designed using, 644
advantages of, 642
code generation enabled by, 643-644
definition of, 14, 35-36, 635-636, 645-648
example notation for, 654-657
history of, 8, 636-638
language-independence of, 638
languages used for, 638-639, 640-641
model-level transformations defined using, 644
necessity of, 636-639
OCL and, 639-640
as UML 1.5, 5, 27
uses of, 639-641, 643-644
action sequence, 371, 375-377, 646
action state, See also activity
definition of, 448, 453
UML 1.4 compared to UML 2.0, 449
ActionState class, 448
activation (focus of control)
definition of, 261
notation for, 261-262, 284, 775
active object, 268
activity
data stores for, 489-490
definition of, 325, 368, 373, 453
interruptible, 493-494
modeling, 335-336, 453, 467-469
notation for, 823, 827
parameters for, 490-492
structured activity
expansion regions for, 496-499
loop nodes for, 501-505
notation for, 495-496
Activity diagram
compared to State Machine diagram, 363, 448
definition of, 13, 34, 38, 447-448, 664
notation for, 784-786, 826-827
scenarios modeled with, 434-442
UML 1.4 compared to UML 2.0, 45, 448-450
UML 1.4 features of
action state, 448, 449
activities in, 453, 785
concurrency in, 456-457, 785
constructing from use case narrative, 457-464
decisions in, 448, 454-455, 784
guard conditions in, 453-454
merge points in, 455-456, 784
method modeling with, 452
subactivity state, 448, 449
transitions in, 453, 785
use case modeling with, 451
workflow modeling with, 451
UML 2.0 features of
actions, 448, 449, 467-469, 477-478, 490-492
activities, 448, 449, 467-469, 490-492, 493-494
activity edges, 470
activity groups, 478
activity partitions, 479-484
central buffer nodes, 479
concurrency in, 474-475, 827
conditional nodes, 499-501
constraints on actions, 485-486
data stores, 489-490
decision and merge nodes, 448, 470-474, 826
expansion regions and expansion nodes, 496-499
final flow node, 484
initial and activity final nodes, 469
joins for multiple threads, 492-493
levels of compliance, 450
list of, 465-467
loop nodes, 501-505
object flows, 475-477, 487-488
object nodes, 475-477, 488-489
structured activity nodes, 495-496
structured programming support, 450
uses of, 60-61, 450-452
activity edges, 470
activity final node, 314-315, 469
Activity graph, 33, 34, 45, 450. See also Activity diagram
activity group, 478
activity partition (swimlane)
definition of, 479-480
modeling, 480-484
notation for, 786
ActivityEdge class, 449
activity-expression, 371
ActivityFinalNode class, 449
ActivityPartition class, 449
actor. See also Use Case diagram
association with use case, 407, 416-417
definition of, 407, 409
generalization of, 411-412
modeling, 409-412
actual gate, 297
actual parameters (arguments)
of interactions, 297
of messages, 289
of procedures, 647-648, 655-656
addition operation (+()), OCL, 615, 617
addition operator (+), OCL, 596
{addOnly} property, 180
after clause, notation for, 777, 818
aggregate class, 102
aggregate object, part decomposition with, 281-283
aggregation. See also associations; Composite Structure diagram; composition
compared to association, 194-195
composition
definition of, 89-90, 165-166, 197, 551
notation for, 89, 197-199, 768-769, 802
UML 2.0 definitions for, 199-200
definition of, 87-89, 165, 194-196
notation for, 88, 196-197, 768, 802
UML 2.0 definitions for, 199-200
aggregation attribute, 143-144
AggregationKind data type, 30, 199-200
AllFusion Component Modeler (Computer Associates), 663
allInstances() operation, 611
alt (alternatives) interaction operator, 300
alt operator, 298-299
Altova, XMLSpy tool, checking XML with, 757-758
analysis model, for RUP method, 524-528
and() operation, 619
and operator, OCL, 596
angle brackets
double left and right (), 69
left (<), less than operator, OCL, 596
left and right (<>), not equal to operator, OCL, 596
left equal (<=), less than or equal to operator, OCL, 596
right (>), greater than operator, OCL, 596
right equal (>=), greater than or equal to operator, OCL, 596
anonymous object, 223
any() operation, 631
append() operation, 627
application framework. See framework
application server stereotype, 573
applications of MDA, 17, 19
appliedProfile stereotype, 841
apply stereotype, 694
ApplyFunctionAction, 651
architecture
CORBA, 18, 21, 691, 730-731
execution architecture, 559
four-layer metamodel architecture, 23-26
MDA (Model-Driven Architecture), 4, 15-21, 26
UML 1.4, 27-36
UML 2.0, 38-44
ArgListsExpression data type, 30
arguments
of interactions, 297
of messages, 289
of procedures, 647-648, 655-656
arrows. See also lines
on dashed line
indicating dependencies, 213-214, 241
indicating realization, 541
hollow
indicating inheritance, 203
indicating realization, 541
on message line, placement of, 250
solid
indicating association direction, 169
indicating synchronous message, 251, 291-292
stick
indicating association navigability, 179
indicating asynchronous message, 256, 292
indicating return from message, 252
artifact
categories of, 536
compared to component, 536
definition of, 567, 569, 577-578
deploying on nodes, 579-582
layers of, 25-26
manifestation dependency for, 578
notation for, 578-579, 830
stereotypes for, 579
UML 2.0 changes in, 567-568
artifact stereotype, 578
asBag() operation, 623, 626, 629
ASP page icon, 720
assembly connector, 552-553
as Sequence() operation, 623, 626, 629
assert (assertion) interaction operator, 304
asSet() operation, 623, 626, 629
association actions, 651
association class
definition of, 190-191
notation for, 191, 767, 801
promotion of, 191-193
association ends
changeability, 180, 187
constraints, 175-177
definition of, 168
interface specifier, 172, 183
modeling, 170-171
multiplicity, 173-174, 186-187
navigability, 179-180, 189-190
notation for, 188-190
ordering, 174-175, 188
qualifiers, 177-179
role name, 171-172, 188
UML 2.0 definitions for, 184-190
visibility, 172
association stereotype, 841
AssociationEnd class, 184
associations. See also links
between actors and use cases, 407, 416-417
aggregation, 87-89, 165, 194-197, 768, 802
binary, 167-168
changeability of, 180, 187
communication paths, 575-576
compared to generalization, 91, 201-202
composition, 89-90, 165-166, 197-200
constraints between, 180-181, 766, 800
constraints on objects in, 175-177
coupling and, 99
definition of, 86-87, 165-167, 228, 560
derived, 182-183, 767, 801
direction of, 168-169
interface required for, 172, 183
modeling
association ends, 168, 170-180
association line, 168, 179-180
classes in, 167-168
name, 168-170
multiplicity of, 126-130, 186-187
multiplicity of roles in, 173-174
naming, 168-170
n-ary (between more than two classes), 193-194, 768, 802
navigability of, 179-180, 189-190, 599-602, 766, 800
between nodes, 560-563
notation for, 765-769, 799-802
ordering for multiple objects in, 174-175, 188
qualified, 188, 602, 767, 801
qualifiers for objects in, 177-179
reflexive, 182, 765, 799
roles of objects in, 171-172, 188
stereotypes for, 563
UML 2.0 definitions for, 183-190
visibility of roles in, 172
asterisk (*)
indicating message iteration, 258-259
indicating unlimited upper value of range, 127
multiplication operation, OCL, 615, 617
multiplication operator, OCL, 596
zero or more operator, XML, 737
asynchronous invocation, 653
asynchronous message, 255-256, 290-292
at() operation, 628
atomicity, 496
attribute
class-level attribute, 141, 143
data type of, 135-136, 142
default value of, 137-139, 143, 144, 347
derived, 134-135, 142, 144
instance-level attribute, 141
invariant on, 595-597
modeling, 130-132
multiplicity of, 126-130, 136-137, 143
naming, 135, 142
for nodes, 561, 571
notation for, 132-141, 142-144, 762, 796
properties for, 139-141, 143-144
readonly, 143
reference, 131
state attributes, 326
state of, 130-131
UML 2.0 definitions for, 141-144
in utility class, 115
values for, in Object diagram, 223-224, 771
visibility of, 121-126, 133, 142
XML, 735-736
attribute actions, 651
attribute compartment
for class definitions, 109-110
for classes compared to objects, 228
information in, 130-132
multiplicity in, 126-130
notation for, 132-141, 762, 796
for objects, 223-224
visibility in, 121-126
audit trails for modeling tools, 672
automatic (completion) transition, 374-375, 386, 823
auxiliary class, 836
auxiliary stereotype, 836
<Day Day Up>
<Day Day Up>
Index
B
Bag
definition of, 605
iterator expressions for, 632-633
operations for, 623-626
{bag} property, 189
Balcer, Marc ("Executable UML-A Foundation for Model Driven Architecture"), 641
ball and socket icon, 162-163, 520, 549-550
Basic package, 41, 117
BasicActivities package
action input and output pins, 477-478
activities and actions, 467-469
activity edges, 470
activity group, 478
decision and merge nodes, 470-474
fork and join nodes, 474-475
initial and activity final nodes, 469
list of features in, 465
object nodes and object flows, 475-477
BasicBehaviors class, 571-572
become stereotype, 564
becomes stereotype, 542
behavior, 79-80. See also collaboration; operation
behavioral diagrams. See also Activity diagram; Sequence diagram
Collaboration diagram
active objects in, 268
compared to Sequence diagram, 269-270
definition of, 37, 265-266, 664
integrating with Class diagram, 270-271
links in, 266-267
messages in, 267-268
multi-objects in, 269
notation for, 776
objects in, 266-267
for RUP design model, 530
UML 1.4 compared to UML 2.0, 45, 246
uses of, 62-63
Communication diagram
definition of, 307, 665
guard condition in, 311
iteration expression in, 309
modeling, 307-308
notation for, 814
parallel execution in, 310
UML 1.4 compared to UML 2.0, 45
uses of, 63-64
Interaction Overview diagram
definition of, 312, 665
modeling, 312-315
notation for, 815-816
UML 1.4 compared to UML 2.0, 45
uses of, 64-65
list of, 58-68
Protocol State Machine diagram
definition of, 390
modeling, 390-393
notation for, 824
uses of, 67-68, 390
State Machine diagram
collaboration in, 240
compared to Activity diagram, 363, 448
composite states in, 377-387
definition of, 365-366, 387, 665
notation for, 817-824
ports in, 371-372
signals in, 376-377
states in, 366-369, 374
submachine states in, 387-389
transitions in, 372-373, 374-376
triggers in, 369-372
UML 1.4 compared to UML 2.0, 44
uses of, 66-67
Statechart diagram
compared to Sequence diagram, 325
composite state containing, 349, 377
definition of, 37, 323-325, 664
deriving from Sequence diagram, 324, 343-348
events in, 327-333, 337
internal transitions in, 333-337
notation for, 777-783
split and merge of control in, 358, 781
states in, 326-327
synch states in, 358-359
transitions in, 328-333, 337-342
UML 1.4 compared to UML 2.0, 44, 246
when to use, 324
Timing diagram
definition of, 315-316, 665
general value timeline, 319-320
lifelines in, 316, 318-319
notation for, 816-817
state timeline, 316-318
UML 1.4 compared to UML 2.0, 45
uses of, 65-66
Use Case diagram
actors in, 407
associations in, 407, 416-417
definition of, 37, 399-400, 664
elements of, 407-408
extend relationships in, 408, 419-423
include relationships in, 407, 418-419
modeling, 408-409
notation for, 783, 825
packages in, 406-407, 413-414
UML 1.4 compared to UML 2.0, 403-404
UML 2.0 changes in, 403-404, 415-416
use cases in, 407, 412-415
uses of, 59, 399-403
Behavioral Elements package, 33-34
Behavioral elements, Superstructure library, 43
behavioral feature. See operation; use case
BehavioredClassifier class, 403, 571-572
Beugnard, Antoine ("Is MDA Achievable Without a Proper Definition of Late Binding?"), 644
binary association
definition of, 167-168
modeling
association ends, 168, 170-180
association line, 168, 179-180
changeability property, 180
classes in, 167-168
constraints, 175-177, 180-181
interface specifier, 172
multiplicity, 173-174
name compartment, 168-170
ordering, 174-175
qualifiers, 177-179
roles of objects, 171-172
visibility, 172
bind stereotype, 215
binding dependency, 213, 215
blob data type. See Uninterpreted data type
Booch, Grady (Booch method developer), 6-7
Booch method of modeling, 6, 637
books. See also publications; specifications
about executable UML, 641
about languages for embedded systems, 641
about modeling design approaches, 637
about object-oriented design, 101
Boolean data type, 30, 619
Boolean expression, 30
BooleanExpression data type, 30
Borland, TogetherSoft tool, 663
boundary icon, 699
BPR (Business Process Re-engineering), 12
braces ({})
enclosing constraints, 71, 175-176
enclosing ordering for multiplicity, 128, 129
enclosing properties, 116-117, 139
enclosing state invariant, 286-288
enclosing tagged values, 70
enclosing uniqueness for multiplicity, 129
brackets ([])
indicating context of association, 601
indicating message conditions, 259-260
indicating multiplicity, 126
indicating number of parts in class, 235
indicating qualifier for association, 602
break interaction operator, 300
browsers, checking XMI with, 757
buildComponent stereotype, 836
bull's-eye icon
indicating activity ending point, 456
indicating activity final nodes, 314-315, 469
indicating final states, 326-327
business modeling, integrating with UML modeling tools, 680
Business Modeling, UML Profile for, 691, 700-701
Business Process Re-engineering. See BPR
<Day Day Up>
<Day Day Up>
Index
C
calculated (derived) attribute
definition of, 134-135
notation for, 134, 142, 144
call stereotype, 216, 836
CallConcurrencyKind data type, 30
capitalization, of class names, 110
caret (^), indicating message has been sent, 598-599, 608-609
caret, double (^^), indicating set of messages sent, 608, 609
cascading deletions. See composition
CCM, UML profile examples for, 691
central buffer nodes, 479
centralBuffer stereotype, 479
change event, 328, 330-331
ChangeableKind data type, 30-31
child (subclass)
definition of, 92, 202-203
discriminator for, 206-207
powertype for, 205-206
choice pseudo state, 376, 381-382
circles
ball and socket icon, 162-163, 520, 549-550
bull's-eye
indicating activity ending point, 456
indicating activity final nodes, 314-315, 469
indicating final states, 326-327
with "H*" inside, indicating deep history, 385-386
with "H" inside, indicating shallow history, 385
half, indicating required interface, 162-163
hollow
identifying dynamic choice point, 341-342
indicating choice pseudo state, 381
indicating control stereotype, 115
indicating entity stereotype, 115
indicating interface stereotype, 160-161, 162-163
lollipop notation, 162, 520, 541-542, 711
with plus sign, indicating package elements, 513
solid
indicating activity starting point, 456
indicating initial and final states, 374
indicating initial node, 314-315, 469
indicating initial state, 326-327
indicating junction pseudo state, 382
indicating static branch point, 340
Class diagram. See also Object diagram
aggregation in, 194-197
association class in, 190-193
associations in
binary association, 167-181
derived association, 182-183
n-ary association, 193-194
reflexive association, 182
UML 2.0 features of, 183-190
attribute compartment in
class-level attribute, 141
data type of attribute, 135-136
default value of attribute, 137-139
definition of, 130-132
derived attribute, 134-135
multiplicity of attribute, 136-137
name of attribute, 135
property string for attribute, 139-141
UML 2.0 features of, 141-144
visibility of attribute, 133
class template in, 158-159
code generation from, 106
Collaboration diagram affecting, 270-271
compared to Object diagram, 226-228
composition in, 197-200
definition of, 36, 664
dependency in, 213-217
generalization in
constraints for, 208-209
definition of, 200-201
discriminator for, 206-207
multiple generalization, 207-208
notation for, 202-205
powertype for, 205-206
UML 2.0 features of, 210-213
interface in, 159-163
multiplicity in
ordering, 128
range of values, 126-127
range without limit, 127
set of discrete values, 128
specific value, 127
UML 2.0 features of, 128-130
name compartment in
class name, 110-113
properties, 116-117
stereotype, 113-116
UML 2.0 features of, 117-121
notation for, 762-771, 796-805
operation compartment in
class-level operation, 149-150
definition of, 144-145
exceptions raised by operation, 150-151
name of operation, 146-147
parameter list for operation, 147-148
post conditions for operation, 151-152
preconditions for operation, 151
properties for operation, 149
return-result for operation, 148-149
UML 2.0 features of, 153-156
visibility for operation, 145-146
relationship to other diagrams, 106-107
Sequence diagram affecting, 270-271
testing with Object diagrams, 228-234
user-defined compartment in, 156-158
uses of, 52-53, 105-108
visibility in
definition of, 121-122
package, 123
private, 122
protected, 124-126
public, 123-124
Class metaclass, 695
class path, 112
class template
definition of, 594
modeling, 158-159
notation for, 763-764, 798
classes. See also Class diagram; objects
abstract class, 92, 204
ancestry of, 118
association class, 190-193, 767, 801
associations between, 86-90, 165-167, 228, 560
attributes for
class-level attribute, 141
data type of, 135-136, 142
default value of, 137-139, 143, 144, 347
derived, 134-135, 142, 144
instance-level attribute, 141
invariant on, 595-597
modeling, 130-132
multiplicity of, 126-130, 136-137, 143
naming, 135, 142
for nodes, 561, 571
notation for, 132-141, 142-144, 762, 796
properties for, 139-141, 143-144
reference, 131
state attributes, 326
state of, 130-131
UML 2.0 definitions for, 141-144
in utility class, 115
values for, in Object diagram, 223-224, 771
visibility of, 121-126, 133, 142
XML, 735-736
auxiliary class, 836
components mapped to, 543-545
concrete class, 29, 92-93, 204-205, 207-208
defining according to purpose, 111
definition of, 76, 118
enumeration, 116
finding in modeling tool, 667
focus class, 837
generalization of, 90-94, 166, 200-209, 211-213
implementation class, 838
implementing class, 96, 161, 788
imported, 113, 516-517
interface class, 95, 764, 797
metaclass, 23
modeling, 108-110, 235
moving between packages, 667
naming, 110-113
notation for, 52, 762-764, 796-798
OCL operation for, 611
operations for
class-level, 149-150, 155
common, interfaces for, 159-160
definition of, 84, 452
dependencies between, 836
exceptions for, 150-151
internal use of, 147
messages invoking, 253
modeling, 145-152
naming, 146-147, 154
for nodes, 561, 571
notation for, 154-156, 762, 796
parameters for, 147-148, 154
post conditions for, 151-152, 597-599
preconditions for, 151-152, 597-599
properties for, 149, 155
return-result of, 148-149, 154
signature of, 95, 146, 276
UML 2.0 definitions for, 153-156
in utility class, 115
visibility of, 121-126, 145-147, 154
package for, specifying, 112-113
ports for, 119-120
private visibility within, 121, 122
properties for, 116-117, 119-120
referenced, 113
resident class, 788
subclass, 92, 202-203, 205-207
superclass, 92, 202-203, 206-207
template class, 158-159, 594, 763-764, 798
UML 2.0 definitions for, 117-120
utility class, 115
visibility of, 121-126
Classifier class, 28, 29, 118
ClassifierRole, 237-239
classifiers
for attributes, 135-136
contextual classifier, of constraint, 591, 592, 594-595
definition of, 29, 547
listed in UML specification, 119
as members of package, 119
modeling tools extending, 668-669
in packages, 514-517
for use cases, 415-416
class-level (static) attribute
definition of, 141
notation for, 141, 143
class-level (static) operation
definition of, 149
notation for, 150, 155
class-scoped attribute. See class-level attribute
class-scoped operation. See class-level operation
client, 14. See also actor; Use Case diagram
client devices. See hardware, modeling
client page icon, 718
client workstation stereotype, 573
clientscript object icon, 719
code. See software
code generation
action semantics enabling, 643-644
from Class diagram, 106
MDA and, 677-679
modeling tools supporting, 676-677, 683
with XMI, 677, 726, 728-729
CodeAction, 651
cohesion, 96-98
collaboration. See also Composite Structure diagram; interaction; Sequence diagram
definition of, 13, 34, 54-55, 237, 304
modeling, 237-239, 304-306
notation for, 237, 772, 806
Collaboration diagram
active objects in, 268
compared to Sequence diagram, 269-270
definition of, 37, 265-266, 664
integrating with Class diagram, 270-271
links in, 266-267
messages in, 267-268
multi-objects in, 269
notation for, 776
objects in, 266-267
for RUP design model, 530
UML 1.4 compared to UML 2.0, 45, 246
uses of, 62-63
collaboration occurrence
definition of, 239
modeling, 239-241
CollaborationOccurrence class, 240
collect() operation, 605, 606, 631
collection actions, 652-653
Collections
Bag, 605, 623-626, 632-633
creating using literals, 608
definition of, 605
iterator expressions for, 630-631
operations for, 605-607, 619-629
properties for, 130, 606
Sequence, 605, 626-629, 633
Set, 605, 621-623, 632
types of, 605
collectNested() operation, 605, 632, 633
colon (:)
indicating attribute type, 135
indicating operation parameter type, 148
between object name and class name, 223
between role name and interface specifier in association, 172
colon, double (::)
indicating value of an enumeration, 598
between nested substates, 356
between package name and class name, 112
COM, UML profile examples for, 691
Combined Deployment and Component diagram
notation for, 790, 830-831
UML 1.4 features of, 563-565
UML 2.0 features of, 569-570
uses of, 57-58
combined fragment
definition of, 298
guard condition for, 299
interaction operands in, 299
interaction operators in, 300-304
modeling, 298-299
comma (,), strict ordering operator, XML, 737
comma-separated value (CSV), modeling tools importing and exporting from, 676
comment. See also note
in constraints, 71
for constraints involving multiple associations, 181
for extension points in use cases, 421-422
for messages, 257
notation for, 72
Common Object Request Broker Architecture. See CORBA
Common Warehouse Model. See CWM
Communication diagram
definition of, 307, 665
guard condition in, 311
iteration expression in, 309
modeling, 307-308
notation for, 814
parallel execution in, 310
UML 1.4 compared to UML 2.0, 45
uses of, 63-64
communication paths, 575-576
Communications class, 571-572
compartments
attribute compartment
for class definitions, 109-110
for classes compared to objects, 228
information in, 130-132
multiplicity in, 126-130
notation for, 132-141, 762, 796
for objects, 223-224
visibility in, 121-126
for class definitions, 109-110
list compartment, 110
name compartment
class name for, 110-113
for classes compared to objects, 228
notation for, 762, 796
for objects, 223-224
ports in, 119-120
presentation of, 109
properties in, 116-117, 119-120
stereotypes in, 113-116
operation compartment
for class definitions, 109-110
definition of, 144-145
notation for, 145-152, 762, 796
visibility in, 121-126
user-defined, 156-158, 762, 796
compilers for UML, 4
complete constraint, 209
complete message, 292
CompleteActivities package
behavior on object flows, 487-488
constraints on actions, 485-486
data stores, 489-490
interruptible activity regions, 493-494
joins for multiple threads, 492-493
list of features in, 466-467
object node customizations, 488-489
parameters for actions and activities, 490-492
completion event, 374-375, 386
completion transition, 374-375, 386, 823
component. See also Combined Deployment and Component diagram; Component diagram
combining with nodes, 563-565
compared to artifact, 536
connectors and ports for, 551-556
definition of, 13-14, 535, 539-540, 567, 569
dependencies of, 55-56, 536, 542-543, 547
interfaces for, 536, 541-542, 549-551
mapping to classes, 543-545
modeling, 540, 546
notation for, 56, 787-788, 830-831
ports for, 552-555, 556
realization and, 547-549, 551-555
stereotypes for, 540-541
UML 2.0 definitions for, 567-568
white box view of, 550
Component diagram
definition of, 36, 535-536, 664
notation for, 787-788, 828
for RUP implementation model, 530
UML 1.4 compared to UML 2.0, 537-539, 568-569
UML 1.4 features of
component dependencies, 542-543
component interfaces, 541-542
component stereotypes, 540-541
components, 539-540
UML 2.0 features of
component dependencies, 547
component interfaces, 549-551
component realization, 547-549, 551-556
components, 546
connectors and ports, 551-556
definition of, 545-546
uses of, 55-56, 535-536, 537
component icon, 56, 540, 546
Component Profile Examples, for J2EE/EJB, Com, .NET, and CCM, 691
component stereotype, 546
composite actions, 649-650
composite aggregation. See composition
Composite Context diagram. See Composite Structure diagram
composite icon, 349
composite object, 198-199
Composite Object diagram, 44. See also Composite Structure diagram
composite state
choice pseudo state in, 376, 381-382
compared to submachine state, 388
concurrent substates in, 351, 357-360, 780, 821
definition of, 348-349, 377-378
direct substates in, 377
entering and exiting, 383-387
extending, 369
fork pseudo state in, 379-380
join pseudo state in, 380-381
junction pseudo state in, 381-382
mutually exclusive substates in, 350
notation for, 349, 779, 820
orthogonal, 378
regions in, 351, 377, 378-379, 383-387
returning to previous substate in, 357
split and merge of control in, 379-380, 821
submachine states in, 351-352
terminate pseudo state in, 382-383
transitions in, 352-360, 379-387
transitively nested states in, 377
Composite Structure diagram
classes in, 235
collaboration in, 237-239, 304
collaboration occurrence in, 239-241
connectors in, 235-237
definition of, 221-222, 234, 665
notation for, 803
ports in, 235-237
UML 1.4 compared to UML 2.0, 44-45
uses of, 54-55
composition. See also Composite Structure diagram
definition of, 89-90, 165-166, 197, 551
notation for, 89, 197-199, 768-769, 802
UML 2.0 definitions for, 199-200
compound transition, 339-342
computation actions, 651
computed (derived) attribute
definition of, 134-135
notation for, 134, 142, 144
Computer Associates, AllFusion Component Modeler, 663
concat() operation, 618
concrete class
definition of, 29, 92-93, 204
generating objects with, 207-208
modeling, 204-205
concrete syntax for OCL, 590-591
concurrency
definition of, 456
joins for multiple threads, 492-493
modeling in Activity diagram, 456-457, 474-475, 827
concurrent substate
notation for, 351, 780, 821
transitions to and from, 357-360
condition timeline. See state timeline
conditional action, 649
conditional node, 499-501
conditional stereotype, 501
conditions. See also constraint
for actions, 485-486
definition of, 71
for messages, 259-260
notation for, 71
post condition
for actions, 485-486
definition of, 14, 67, 587, 597
modeling in Activity diagram, 460-461
for operations, 151-152, 156, 597-599
precondition
for actions, 485-486
definition of, 14, 67, 587, 597
modeling in Activity diagram, 459-460
for operations, 151-152, 156, 597-599
for use cases, 426-427
for use cases, 424-427, 460-461
connector
in Activity diagram, 556
in Component diagram, 552-555
definition of, 552
in interaction diagrams, 556
modeling, 235-237
consider interaction operator, 303
constraint. See also conditions; OCL
on associations, 175-177, 180-181, 599-602, 766, 800
contextual classifier of, 591, 592, 594-595
definition of, 13, 71, 175, 587
duration, 810
in generalizations, 208-209, 211-213
invariant
on attributes, 595-597
definition of, 67, 587, 595
for messages, 293-295
notation for, 71, 175-177, 211-213, 766
placement of, 591, 592
post condition
for actions, 485-486
definition of, 14, 67, 587, 597
modeling in Activity diagram, 460-461
for operations, 151-152, 156, 597-599
precondition
for actions, 485-486
definition of, 14, 67, 587, 597
modeling in Activity diagram, 459-460
for operations, 151-152, 156, 597-599
for use cases, 426-427
in profiles, 689
result of, 592
self instance of, 591
for state transitions, 373
for timed messages, 257-258, 775, 811
constraint language. See OCL
constructor, 292
Constructs package, 41-42, 117
container
components as, 539
multiplicity and, 174
OclMessage as, 609
packages as, 406, 511
template class as, 163
containing state machine, 351
contextual classifier, of constraint, 591, 592, 594-595
control flow of actions, 646
control icon, 114-115, 699
control stereotype, 113-115
copy stereotype, 841
CORBA (Common Object Request Broker Architecture)
MDA and, 18
MOF and, 21, 730-731
UML profile for, 691
Core package
UML 1.4, 28-29
UML 2.0, 40-42
count() operation, 620, 623, 625, 626
coupling, 98-100
create stereotype, 836, 841
critical region (region) interaction operator, 302
CRUD (Create, Read, Update, Delete) checklist, 414-415
CSV (comma-separated value), modeling tools importing and exporting from, 676
curly braces ({})
enclosing constraints, 71, 175-176
enclosing ordering for multiplicity, 128, 129
enclosing properties, 116-117, 139
enclosing state invariant, 286-288
enclosing tagged values, 70
enclosing uniqueness for multiplicity, 129
customer. See actor; client
customization of UML. See extensibility of UML
CWM (Common Warehouse Model)
definition of, 21
MOF and, 4, 20, 732
Web sites about, 21
<Day Day Up>
<Day Day Up>
Index
D
dash, double (-), indicating comment in OCL, 71
data flow of actions, 646
data modeling
compared to object-oriented modeling, 447
integrating with UML modeling tools, 680
Data Modeling Profile for UML, 691
data stores, 489-490
data types
of attribute, 135-136, 142
of class template parameters, 158
for OCL, 592-594, 612, 614, 615, 619
of operation parameters, 148
of operation return-result, 148-149
for UML metamodel, 30-33
Data Types package, 30-33
database
as artifact, 536
database system stereotype for, 573
as model repository, 667
modeling as a component, 563
objects represented in, 108
OCL tuples for, 611
table stereotype for, 541
database system stereotype, 573
Datastore class, 449
deactivation, 261
decision node, 314, 470-474, 826
DecisionNode class, 448
decomposition. See part decomposition
deep history, 385, 780, 820
def expression, OCL, 596-597, 611
default entry of state, 383-384
deferred event, 369
delegation. See inheritance
delegation connector, 552-553
dependency
between artifacts and nodes (deployment), 579-582
between components, 55-56, 536, 542-543, 547
on creation of classifier instance, 836, 838
definition of, 166, 213
on derived elements, 837
between nodes (manifestation), 578
notation for, 213-215, 213-216, 770-771, 804-805
between operations, 836
between packages, 50-51, 514-517
refinement, 839
on sending a signal, 839
stereotypes for, 215-216, 836-840
substitution, 216-217
on trace relationship between elements, 840
types of, 213, 216
UML 2.0 notation for, 216-217
deploy stereotype, 563, 580
deployment dependency, 579-582
Deployment diagram
definition of, 37, 664
notation for, 789, 829
for RUP design model, 528
for RUP implementation model, 530
UML 1.4 compared to UML 2.0, 569
UML 1.4 features of
associations, 560-563
components, 563-565
definition of, 559-560
instance-level diagram, 561-562
nodes, 560-563
type-level diagram, 561-562
UML 2.0 features of
artifacts, 567, 577-582
communication paths, 575-576
nodes, 567, 570-576, 579-582
uses of, 57, 537, 559-560, 568-569
deployment spec stereotype, 582
derive stereotype, 215, 837
derived association
definition of, 182
notation for, 182-183, 767, 801
derived attribute
definition of, 134-135
notation for, 134, 142, 144
Describe tool (Embarcadero), 663
design model, for RUP method, 528-530
design pattern
applying with collaboration occurrence, 241
definition of, 13
modeling with collaboration, 237-239
notation for, 772, 806
UML support of, 11
destroy stereotype, 837, 841
device, 573. See also hardware, modeling
Diagram Interchange specification, 730, 754-757
diagrams
Activity diagram
compared to State Machine diagram, 363, 448
definition of, 13, 34, 38, 447-448, 664
notation for, 784-786, 826-827
scenarios modeled with, 434-442
UML 1.4 compared to UML 2.0, 45, 448-450
behavioral, 58-68
Collaboration diagram
active objects in, 268
compared to Sequence diagram, 269-270
definition of, 37, 265-266, 664
integrating with Class diagram, 270-271
links in, 266-267
messages in, 267-268
multi-objects in, 269
notation for, 776
objects in, 266-267
for RUP design model, 530
UML 1.4 compared to UML 2.0, 45, 246
uses of, 62-63
Combined Deployment and Component diagram
notation for, 790, 830-831
UML 1.4 features of, 563-565
UML 2.0 features of, 569-570
uses of, 57-58
Communication diagram
definition of, 307, 665
guard condition in, 311
iteration expression in, 309
modeling, 307-308
notation for, 814
parallel execution in, 310
UML 1.4 compared to UML 2.0, 45
uses of, 63-64
Component diagram
definition of, 36, 535-536, 664
notation for, 787-788, 828
for RUP implementation model, 530
UML 1.4 compared to UML 2.0, 537-539, 568-569
UML 1.4 features of, 539-543
UML 2.0 features of, 545-556
uses of, 55-56, 535-536, 537
Composite Structure diagram
classes in, 235
collaboration in, 237-239, 304
collaboration occurrence in, 239-241
connectors in, 235-237
definition of, 221-222, 234, 665
notation for, 803
ports in, 235-237
UML 1.4 compared to UML 2.0, 45
uses of, 54-55
Deployment diagram
notation for, 829
for RUF design model, 528
for RUP implementation model, 530
UML 1.4 compared to UML 2.0, 569
UML 1.4 features of, 560-565
UML 2.0 features of, 567, 570-582
uses of, 57, 537, 559-560, 568-569
dynamic view, 37
enclosing in frames, 278-279
functional view, 37-38
HTML output of, 674-675
importing and exporting from modeling tools, 727, 730, 754-757
interaction diagrams, 45, 61-66, 275-276
Interaction Overview diagram
definition of, 312, 665
modeling, 312-315
notation for, 815-816
UML 1.4 compared to UML 2.0, 45
uses of, 64-65
list of, 44-45, 664-665
model management, 50-51
modeling tool support for, 663-665, 680
nesting, 278-279
Object diagram
attribute compartment, 223-224
compared to Class diagram, 226-228
definition of, 36, 221, 664
drawing in modeling tool, 664, 665
name compartment, 223-224
notation for, 771-772, 805-806
testing Class diagram with, 228-234
UML 1.4 compared to UML 2.0, 44, 665
uses of, 53-54
Package diagram
definition of, 664
drawing in modeling tool, 664, 665
modeling, 518
notation for, 791-794, 831-834
UML 1.4 compared to UML 2.0, 44, 665
uses of, 50-51
Protocol State Machine diagram
definition of, 390
modeling, 390-393
notation for, 824
uses of, 67-68, 390
relationships to each other, 106-107
reports of, 673-674, 682
State Machine diagram
collaboration in, 240
compared to Activity diagram, 363, 448
composite states in, 377-387
definition of, 365-366, 387, 665
notation for, 817-824
ports in, 371-372
signals in, 376-377
states in, 366-369, 374
submachine states in, 387-389
transitions in, 372-373, 374-376
triggers in, 369-372
UML 1.4 compared to UML 2.0, 44
uses of, 66-67
Statechart diagram
compared to Sequence diagram, 325
composite state containing, 349, 377
definition of, 37, 323-325, 664
deriving from Sequence diagram, 324, 343-348
events in, 327-333, 337
internal transitions in, 333-337
notation for, 777-783
split and merge of control in, 358, 781
states in, 326-327
synch states in, 358-359
transitions in, 328-333, 337-342
UML 1.4 compared to UML 2.0, 44, 246
when to use, 324
static view, 36-37
structural, 51-58
Timing diagram
definition of, 315-316, 665
general value timeline, 319-320
lifelines in, 316, 318-319
notation for, 816-817
state timeline, 316-318
UML 1.4 compared to UML 2.0, 45
uses of, 65-66
Use Case diagram
actors in, 407
associations in, 407, 416-417
definition of, 37, 399-400, 664
elements of, 407-408
extend relationships in, 408, 419-423
include relationships in, 407, 418-419
modeling, 408-409
notation for, 783, 825
packages in, 406-407, 413-414
UML 1.4 compared to UML 2.0, 403-404
UML 2.0 changes in, 403-404, 415-416
use cases in, 407, 412-415
uses of, 59, 399-403
using, 47-50
dialog, use case
modeling in Activity diagram, 461-463
in use case narrative, 428-429
diamonds
hollow
indicating aggregation, 88, 196-197
indicating choice pseudo state, 376, 381
indicating decision node, 314, 454
indicating merge point, 455
indicating n-ary association, 194
solid, indicating composition, 89, 197-198
direct substates, 377
directional indicator for association, 169
discriminator
definition of, 93
notation for, 206-207, 211
disjoint constraint, 209
div() operation, 617
division operation (/()), OCL, 615, 617
division operator (/), OCL, 596
document file, 837
document stereotype, 541, 837
DTD (Document Type Definition)
compared to XML schemas, 734
creating from MOF, 731
definition of, 732, 733-734
domain, 18
domain facilities of MDA, 17, 18
Domain Task Force. See DTF
dot notation, 338, 600
double angle brackets ( ). See guillemets
double caret (^^), indicating set of messages sent, 608, 609
double colon (::)
indicating value of an enumeration, 598
between nested substates, 356
between package name and class name, 112
double dash (-), indicating comment in OCL, 71
DTD (Document Type Definition)
compared to XML schemas, 734
creating from MOF, 731
definition of, 732, 733-734
DTF (Domain Task Force), 18
duration constraint, 810
dynamic choice point, 341-342, 779, 819
dynamic view diagrams, 37
<Day Day Up>
<Day Day Up>
Index
E
EAI (Enterprise Application Integration), UML Profile for, 690, 702-706
EDOC (Enterprise Distributed Object Computing), UML Profile for, 690, 706-712
Edwards, Stephen (Languages for Digital Embedded Systems), 641
EJB stereotype, 579
EJB, UML Profile for, 696-701
EJBEntity stereotype, 541
elaborative approach of modeling, 636
elapsed-time event, 328, 330
Element class, 143
ElementImport metaclass, 693
ellipsis (), indicating more subclasses, 203-204
Embarcadero, Describe tool, 663
embedded device stereotype, 573
EncapsulatedClassifier node, 571-572
encapsulation
applying, 84-85
definition of, 80
implementation of an object, 82-83
interface of an object, 81
private visibility for, 122, 133
purpose of an object, 83
for reuse, 236
Enterprise Application Integration, UML Profile for. See EAI, UML Profile for
Enterprise Distributed Object Computing, UML Profile for. See EDOC, UML Profile for entities, XML, 736-737
entity icon, 114-115, 699, 701
Entity Relationship modeling. See ER modeling
entity stereotype, 113-115, 223-224, 837
entry action
definition of, 368
modeling, 334-335
notation for, 778, 818
enumeration
double colon (::) indicating value of, 598
modeling, 116
enumeration stereotype, 116
equal sign (=)
equal to operation, OCL
for Bag, 624
for ModelElement types, 614
for OclAny, 613
for OclState, 615
for OclType, 614
for Sequence, 626
for Set, 621
indicating default value of attribute, 137-138
in properties, 116-117
in tagged values, 70
ER (Entity Relationship) modeling, 6
error, resulting from operations, 150-151, 253
Ethernet stereotype, 563
event. See also message; Protocol State Machine diagram; State Machine diagram; trigger
actions triggered by, 325, 332-333
change event, 328, 330-331
completion event, 374-375, 386
deferred, 369
definition of, 327-328, 369
deriving from Sequence diagram, 343-348
elapsed-time event, 328, 330
guard condition for, 332
for messages, 289-290
modeling, 328-333
notation for, 328
ordering of, 337, 338
relationship to message, 327
relationship to transition, 328
send event, 338
state affecting response to, 329-330
exception, resulting from operations, 150-151, 253
excludes() operation, 620
excludesAll() operation, 620
excluding() operation, 622, 625, 628-629
executable stereotype, 541, 579, 837
executable UML, 641
"Executable UML-A Foundation for Model
Driven Architecture" (Mellor; Balcer), 641
execution architecture, 559
execution environment
definition of, 573-574
deployment and, 579-581
stereotypes for, 573
execution occurrence, 289-290
execution profiles
constraints in, 689
defining, 691-696
definition of, 3-4, 10, 72, 641, 688
industry-adopted profiles, 691
MOF and, 688
multiple, applying to one package, 694
OMG-adopted profiles, 690-691
removing from package, 694
standards for, 690
stereotype icons in, 689-690
stereotypes in, 688
tagged values in, 689
UML Profile for Business Modeling, 700-701
UML Profile for EJB, 696-701
UML Profile for Enterprise Application Integration (EAI), 702-706
UML Profile for Enterprise Distributed Object Computing (EDOC), 706-712
UML Profile for Schedulability, Performance, and Time, 712-714
UML Profile for Software Development Processes, 698-700
UML specification examples of, 691
UML Testing Profile, 714-717
WAE (Web Application Extension) profile, 717-721
exists() operation, 606, 630
exit action
definition of, 368
modeling, 334-335
notation for, 778, 818
expansion node
definition of, 497
notation for, 497-499
expansion region
definition of, 496
notation for, 497-499
explicit entry of state, 384
Expression data type, 31
extend relationship
compared to include relationship, 423
conditions for use of, 421-423
definition of, 408
modeling, 419-423
extensibility of modeling tools, 668-670, 681
extensibility of UML
constraints for
on associations, 175-177, 180-181, 599-602, 766, 800
contextual classifier of, 591, 592, 594-595
definition of, 13, 71, 175, 587
duration, 810
in generalizations, 208-209, 211-213
invariant, 67, 587, 595-597
for messages, 293-295
notation for, 71, 175-177, 211-213, 766
placement of, 591, 592
post condition, 151-152, 156, 460-461, 485-486, 597-599
precondition, 151-152, 156, 426-427, 459-460, 485-486, 597-599
features for, 12-13, 68-71
as goal of UML, 10
metaclasses for, 68
profiles for
constraints in, 689
defining, 691-696
definition of, 3-4, 10, 72, 641, 688
industry-adopted profiles, 691
MOF and, 688
multiple, applying to one package, 694
OMG-adopted profiles, 690-691
removing from package, 694
standards for, 690
stereotype icons in, 689-690
stereotypes in, 688
tagged values in, 689
UML Profile for Business Modeling, 700-701
UML Profile for EJB, 696-701
UML Profile for Enterprise Application Integration (EAI), 702-706
UML Profile for Enterprise Distributed Object Computing (EDOC), 706-712
UML Profile for Schedulability, Performance, and Time, 712-714
UML Profile for Software Development Processes, 698-700
UML specification examples of, 691
UML Testing Profile, 714-717
WAE (Web Application Extension) profile, 717-721
stereotypes for
for artifacts, 579
for components, 540-541
for control elements, 113-115
defined within UML, 70
definition of, 12-13, 68-70, 113
for dependencies, 215-216
for entity elements, 113-115
for enumerations, 116
for execution environments, 573
icons for, 689-690
list of, 836-841
modeling tools extending, 668
for node associations, 563
for nodes, 572-573
notation for, 69, 113, 115
for objects, 223
obsolete, 841
for operations, 144-145
for packages, 512
in profiles, 688
profiles providing, 72
in user-defined compartments, 157
for utility classes, 115
tagged values for
definition of, 13, 70
modeling tools extending, 668
notation for, 70, 763
in profiles, 689
transferring with XMI, 745-747, 751-754
UML 2.0 support of, 15, 39
eXtensible Stylesheet Language
Transformations. See XSLT
Extension Mechanisms package, 30
Extension metaclass, 696
extension points, 421-423
ExtensionEnd metaclass, 696
ExtensionPoint class, 403-404
external stereotype, 483
ExtraStructuredActivities level, 450
<Day Day Up>
<Day Day Up>
Index
F
facade stereotype, 841
factored path, 339-342
fault situation. See exception, resulting from operations
Feature class, 143, 153, 155, 186
file icon, 578
file stereotype, 541, 837
files. See also artifact
document file, 837
graphics files, for diagrams, 675
library file, 838
physical file, 837
program file, 837
filter action, 652
final flow node, 484
final state
definition of, 327, 374
notation for, 327, 374, 777, 817
first() operation, 628
flatten() operation, 605, 623, 625, 627
floor() operation, 616
flow. See workflow
FlowFinalNode class, 449
focus class, 837
focus of control (activation)
definition of, 261
notation for, 261-262, 284, 775
focus stereotype, 837
folder icon, 50
forAll() operation, 606, 630
fork icon, 519
fork, in Activity diagram, 456-457
fork node, 313, 474-475, 827
fork pseudo state, 379-380
ForkNode class, 449
form icon, 718
formal gate, 297
formal parameter
of actions and activities, 490-492
of class template, 158
of operations, 99, 147-148, 154
forward slash (/)
division operation, OCL, 615, 617
division operator, OCL, 596
indicating derived association, 182-183
indicating derived attribute, 134
separating event from action, 333
Foundation package, 28-33
four-layer metamodel architecture, 23-26
Fowler, Martin (Refactoring-Improving the Design of Existing Code), 101
fragment
definition of, 298
guard condition for, 299
interaction operands in, 299
interaction operators in, 300-304
modeling, 298-299
frame
interaction occurrences using, 296
modeling, 278-279
frameset icon, 718
framework
definition of, 837
metaclasses for, 68
UML support of, 11
framework stereotype, 837
French quotes ( ). See guillemets
friend stereotype, 841
{frozen} property, 180
functional modeling, 447. See also Activity diagram
functional view diagrams, 37-38
Fundamentals of Object-Oriented Design in UML (Page-Jones), 101
<Day Day Up>
<Day Day Up>
Index
G
gate, in interaction occurrence, 297-298
general value timeline, 319-320
GeneralizableElement class, 29
generalization. See also inheritance
of actors in use cases, 408, 411-412
compared to association, 91, 201-202
constraints for, 208-209, 211-213
definition of, 90-94, 166, 200-201
discriminators and, 206-207, 211
multiple, 207-208
of nodes, 576
notation for, 202-209, 211-213, 769-770, 803-804, 824
polymorphism and, 94-95
powertypes and, 205-206, 211
protected visibility within, 121, 124-126
separate target style of notation, 203
shared target style of notation, 203-204
UML 2.0 definitions for, 210-213
of use cases, 408
generalization set, 211
GeneralizationSet class, 210-211
Geometry data type, 31
graphics files, for diagrams, 675
greater than or equal to sign (>=)
greater than or equal to operation, OCL, 617
greater than or equal to operator, OCL, 596
greater than sign (>)
greater than operation, OCL, 616
greater than operator, OCL, 596
group action, 649
guard condition
for compound transitions, 340-342
for decisions, 454, 471
for events, 332
for interactions, 299
for messages, 311, 773, 807
for state transitions
in Activity diagram, 453-454, 785, 827
in State Machine diagram, 370-371, 373, 817
in Statechart diagram, 777
guillemets ( ), enclosing stereotypes, 69
<Day Day Up>
<Day Day Up>
Index
H
"H*", indicating deep history, 385-386
"H", indicating shallow history, 385
hardware, modeling. See Combined Deployment and Component diagram; Deployment diagram; node
Harel, David (Statecharts developer), 324
"Harmonisation of Modeling Languages with Object-Oriented Extensions and Executable Semantics" (Stan-Ober),
642
hasReturned() operation, 609, 610, 613
history entry points, 384-386, 780, 820
history icon, 385, 386
history pseudo state, 357
Ho, Wai-Ming (Using UML Action Semantics for Executable Modeling and Beyond), 644
HTML, generated by modeling tools, 674-675, 682
HTML stereotype, 579
hyperlink, to package elements, 513
hyphen (-)
in class names, 110
indicating private visibility, 121, 514
subtraction operation, OCL, 615, 617, 622
subtraction operator, OCL, 596
hyphen, double (-), indicating comment in OCL, 71
<Day Day Up>
<Day Day Up>
Index
I
IBM, Rational Rose tool, 663, 758
icons. See also shapes in diagrams
actor icons, 405
ASP page icon, 720
ball and socket icon, 162-163, 520, 549-550
boundary icon, 699
client page icon, 718
clientscript object icon, 719
component icon, 56, 540, 546
composite icon, 349
control icon, 114-115, 699
customizing in modeling tool, 669-670, 689-690
diamond icon
indicating aggregation, 88, 196-197
indicating choice pseudo state, 376, 381
indicating composition, 89, 197-198
indicating decision node, 314, 454
indicating merge point, 455
indicating n-ary association, 194
entity icon, 114-115, 699, 701
file icon, 578
final state icon, 374
folder icon, 50
fork icon, 519
form icon, 718
frameset icon, 718
"H" inside a circle, 385
"H*" inside a circle, 385-386
history icon, 385, 386
initial state icon, 374
interface icons, 549-550
JSP page icon, 720
lollipop icon, 162, 520, 541-542, 711
in profile, 689-690
script library icon, 721
server page icon, 717
servlet icon, 721
stop icon, 320
"T" inside a square, 593, 594, 612
target icon, 719
triangle icon, 522
for WAE, 717-721
Web page icon, 720
worker icons, 701
IDE (Integrated Development Environment), 663, 675
ignore interaction operator, 303
I-Logix, Rhapsody tool, 663
implement stereotype, 544, 838
implementation, 82-83. See also Combined Deployment and Component diagram; Component diagram;
Deployment diagram; method
implementation class, 838
implementation model, for RUP method, 530
implementation view. See also Component diagram
implementationClass stereotype, 838
implementing class
definition of, 96, 161
notation for, 788
implies() operation, 619
import (merge) relationship between packages, 516-517, 792, 833
import stereotype, 215
imported class
definition of, 516-517
package name requirements for, 113
include/, indicating submachine reference, 352
include relationship
compared to extend relationship, 423
definition of, 407
modeling, 418-419
include stereotype, 418-419
includes () operation, 620
includesAll () operation, 620
including () operation, 622, 625, 628
incomplete constraint, 209
indexOf () operation, 628
inequality sign (<>)
not equal to operation, OCL, 613, 614, 615
not equal to operator, OCL, 596
information hiding (encapsulation)
applying, 84-85
definition of, 80
implementation of an object, 82-83
interface of an object, 81
private visibility for, 122, 133
purpose of an object, 83
for reuse, 236
Infrastructure library, 38, 40-43, 117
inheritance. See also delegation; generalization
definition of, 90-91
notation for, 203
protected visibility within, 121, 124-126
initial node, 314-315, 469
initial state
definition of, 326, 374
notation for, 326-327, 374, 777, 817
initial value. See attribute, default value of
input pins, 477-478, 645-646, 654-655
insertAt() operation, 627
instance. See also objects
of association (link), 86, 224
of collaboration (collaboration occurrence), 239
component instance, 560, 563
of message (stimulus), 249, 252-253
of meta-metamodel (metamodel), 25
of metamodel (model), 25
node instance, 560, 574
of use case (scenario), 432
instance documents, 733
instance-level attribute, 141
instance-level Deployment diagram, 561-562, 789, 829
instance-level operation, 149
InstanceSpecification class, 225-226
instantiaie stereotype, 216, 838
Integer data type, 31, 617-618
Integrated Development Environment. See IDE
interaction. See also collaboration; message; object lifeline
breaking execution of, 300
conditional execution of, 299, 300
identifying only valid interaction, 304
iterative execution of, 304
messages ignored by, 303
modeling, 246-248, 312-315
optional execution of, 300
parallel execution of, 300-301
precedence of, 302
prohibiting execution of, 302
reusing, 295-298
sequencing execution of, 301-302
sequencing of, in Communication diagram, 313-315
interaction (combined) fragment
definition of, 298
guard condition for, 299
interaction operands in, 299
interaction operators in, 300-304
modeling, 298-299
interaction diagrams. See also Sequence diagram
Collaboration diagram
active objects in, 268
compared to Sequence diagram, 269-270
definition of, 37, 265-266, 664
integrating with Class diagram, 270-271
links in, 266-267
messages in, 267-268
multi-objects in, 269
notation for, 776
objects in, 266-267
for RUP design model, 530
UML 1.4 compared to UML 2.0, 45, 246
uses of, 62-63
Communication diagram
definition of, 307, 665
guard condition in, 311
iteration expression in, 309
modeling, 307-308
notation for, 814
parallel execution in, 310
UML 1.4 compared to UML 2.0, 45
uses of, 63-64
Interaction Overview diagram
definition of, 312, 665
modeling, 312-315
notation for, 815-816
UML 1.4 compared to UML 2.0, 45
uses of, 64-65
list of, 45, 61-66, 275-276
tabular versions of, 275
Timing diagram
definition of, 315-316, 665
general value timeline, 319-320
lifelines in, 316, 318-319
notation for, 816-817
state timeline, 316-318
UML 1.4 compared to UML 2.0, 45
uses of, 65-66
UML 1.4 compared to UML 2.0, 45
interaction occurrence
arguments, 297-298
definition of, 295-296
gates, 297-298
modeling, 296, 312-315
notation for, 811-813
reference operator, 297
Interaction Overview diagram
definition of, 312, 665
modeling, 312-315
notation for, 815-816
UML 1.4 compared to UML 2.0, 45
uses of, 64-65
interface. See also operation
associations requiring, 172, 183
compared to abstract class, 160
for components, 536, 541-542, 549-551
definition of, 13-14, 159, 452
for messages, 61, 246-247
modeling, 159-160
notation for, 160-161, 162-163
for objects, 81
provided, 162-163, 236, 520, 549
required, 162-163, 235-236, 520, 549
for subsystems, 520, 793
UML 2.0 definitions for, 161-163
interface class
definition of, 95
notation for, 764, 797
interface icons, 549-550
interface stereotype, 160-161, 541, 550
Interfaces package, 161
IntermediateActivities package
activity partitions, 479-484
central buffer nodes, 479
final flow node, 484
list of features in, 465-466
internal transition
compartment for, in state, 333-334
definition of, 325, 368
entry and exit actions for, 334-335
modeling, 336-337
InternalStructures class, 571-572
interruptible activity, 493-494
InterruptibleActivityRegion class, 449
intersection() operation, 622, 624-625
inv keyword, OCL, 595
invariant
on attributes, 595-597
definition of, 67, 587, 595
state invariant, 286-288, 808
invariant stereotype, 841
invocation message, 653
"Is MDA Achievable Without a Proper Definition of Late Binding?" (Beugnard), 644
isCovering attribute, 212-213
isDerived attribute, 143-144, 185
isDerivedUnion attribute, 143-144
isDisjoint attribute, 212-213
isEmpty() operation, 621
isolation, 496
isOperationCall() operation, 609, 614
isOrdered attribute, 128-130
isSignalSent() operation, 609, 614
isSubstitutable attribute, 210-211
isUnique attribute, 128-130
isUnique() operation, 630
iterate action, 652
iterate() operation, 606
iterator expressions, OCL, 629-633
<Day Day Up>
<Day Day Up>
Index
J
J2EE container stereotype, 573
J2EE/EJB, UML profile examples for, 691
Jacobson, Ivar
describing action semantics, 636
OOSE developer, 6-7
Java
association representation, 640
extend relationship, 421
inner class compared to composition, 90, 198
instance-level attributes in interfaces, 162
interface class, 95
multiple inheritance of classes, 208
polymorphism, 159
protected visibility, 125
UML profile for, 691
Vector used for multiplicity, 131
Jzquel, Jean-Marc (Using UML Action Semantics for Executable Modeling and Beyond), 644
join node, 313, 474-475, 827
join pseudo state, 380-381
JoinNode class, 449
joins for multiple threads, 492-493
Jones, Capers (Patterns of Software Systems Success and Failure), 101
JSP page icon, 720
JSP stereotype, 579
jump actions, 653-654
junction pseudo state, 381-382
<Day Day Up>
<Day Day Up>
Index
K
Kabira Technologies, UML compilers by, 4
<Day Day Up>
<Day Day Up>
Index
L
Languages for Digital Embedded Systems (Edwards), 641
last() operation, 628
Layer M0, 25, 26
Layer M1, 25, 26
Layer M2, 25-26
Layer M3, 25
layering, 39
Le Guennec, Alain (Using UML Action Semantics for Executable Modeling and Beyond), 644
less than or equal to sign (<=)
less than or equal to operation, OCL, 616
less than or equal to operator, OCL, 596
less than sign (<)
less than operation, OCL, 616
less than operator, OCL, 596
let expression, OCL, 596-597
library file, 838
library stereotype, 541, 838
lifeline. See also object lifeline
in Sequence diagram, 773, 807
in Timing diagram, 316, 318-319
lines. See also arrows
in containing state, indicating stub states, 352
dashed
between association line and association class, 191
between association lines, 181
crossing generalization lines, 208
indicating dependencies, 213-214, 547
indicating merge relationship, 517
between object lifelines, 254, 256
separating regions in composite state, 351
vertical, indicating object lifeline, 249-250, 280
indicating associations in Class diagram, 168
indicating relationships in Class diagram, 107
between object lifelines, indicating messages, 250
slanted, indicating message requiring a long time, 258
links. See also associations
aggregation, 87-89
composition, 89-90
definition of, 86-87, 167-168, 228
notation for, 224-225, 266-267, 771, 805
list compartment, 110. See also attribute compartment; operation compartment; user-defined compartment
ListCompartment metaclass, 110
LiteralValueAction, 651
local stereotype, 841
LocationReference data type, 31
logic, modeling. See Activity diagram; Interaction Overview diagram
lollipop notation, 162, 520, 541-542, 711
loop action, 649
loop body stereotype, 503
loop interaction operator, 304
loop node
definition of, 501-503
notation for, 503-505
loop setup stereotype, 503
loop stereotype, 503
loop test stereotype, 503
<Day Day Up>
<Day Day Up>
Index
M
M2. See metamodel
M3. See meta-metamodel
MagicDraw tool (No Magic, Inc.), 663
manifest stereotype, 578
Manifestation class, 567
manifestation dependency, 578
map action, 652
Mapping data type, 31
MappingExpression data type, 31
MarshalAction, 651
max() operation, 616, 618
MDA (Model-Driven Architecture)
action semantics and, 638, 643-644
code generation and, 677-679
companies using, 19
definition of, 16-19
executable XML and, 641
four-layer architecture and, 26
MOF and, 19-21
OMG role in, 15-16
UML development and, 4
XMI and, 728-729
MDC (Meta-Data Coalition), 21
Mealy state machine, 324
Mellor, Stephen
A Comparison of the Booch Method and Shlaer-Mellor OOA/RD, 637
"Executable UML - A Foundation for Model Driven Architecture", 641
"Software-Platform-Independent, Precise Action Specifications for UML", 637
memberEnd property, 184-190
merge dependency between packages, 516-517, 792, 833
merge node, 314, 470-474, 826
MergeNode class, 448
message. See also event; Sequence diagram
asynchronous, 255-256, 290-292
comments for, 257
complete, 292
constructor, 292
definition of, 246-247, 252-253, 288
duration constraint for, 293-295
events associated with, 289-290
execution of, 289-290
found, 293
guard condition for, 311, 773, 807
instance of (stimulus), 249, 252-253
iterating, 258-259, 309
lost, 293
modeling, 249-252
notation for
in Collaboration diagram, 267-268
in Communication diagram, 307-311
in Sequence diagram, 250, 280, 288-289, 773-774, 807-808
operation calls, 291
parallel execution of, 310
recursive calls to, 261-262, 774
relationship to event, 327
reply (return) to, 254
request (invocation message), 653
requirements for, 247-248
requiring a long time to execute, 258
self-reference message, 254-255, 807
sending in OCL, 598-599, 608-610
sequence expression for, 307-308
signal, 291
signal raised by, 253
sorts of, 290-292
in state timeline, 316-317
synchronous, 254, 290-292
testing for, in post condition, 598-599
time constraint for, 293-295
timed message, 257-258
unknown, 292
messaging actions, 653
Meta Object Facility specification. See MOF specification
metaclass stereotype, 695, 838
Meta-Data Coalition. See MDC
meta-metamodel (M3)
in four-layer architecture, 25
MOF as, 20
metamodel (M2)
Activity diagram changes in, 448-449
association changes in, 183-190
attribute changes to, 141-144
class changes in, 117-120
collaboration changes in, 240
component changes in, 567-568
in four-layer architecture, 25-26
generalization changes in, 210-213
interface changes in, 161-163
modeling tools supporting, 668
MOF as, 19-20
multiplicity changes in, 128-130
node changes in, 570-574
object changes to, 225-226
operation changes to, 153-156
state changes to, 364-365
Use Case diagram changes in, 403-404
metamodel (OCL), 588, 589-590
metamodel stereotype, 838
method. See also Activity diagram; implementation; operation
definition of, 84, 145, 452
modeling with Activity diagram, 452
min() operation, 616, 618
minus sign (-)
indicating private visibility, 121, 514
subtraction operation, OCL, 615, 617, 622
subtraction operator, OCL, 596
mobile device stereotype, 573
mod() operation, 618
model. See also diagrams
definition of, 521-522
notation for, 522, 794, 834
model layer, 25, 26
model library, 838
model management diagram
definition of, 50-51
Package diagram
definition of, 664
drawing in modeling tool, 664, 665
modeling, 518
notation for, 791-794, 831-834
UML 1.4 compared to UML 2.0, 44, 665
uses of, 50-51
Model Management package, 35
model stereotype, 521-522
Model-Driven Architecture. See MDA
ModelElement class, 29, 186
modeling. See also CWM; UML
Booch method of, 6, 637
data modeling, 447
elaborative approach of, 636
ER (Entity Relationship) modeling, 6
functional modeling, 447
history of, 6
importing to and exporting from, 676
modeling tools
access control and security for, 671-672
advantages of using, 661-662
audit trails for, 672
categories of, 663
change management for, 672, 681
choosing, checklist for, 679-683
code generation and reversal by, 676-677, 683
customizing icons in, 669-670, 689-690
documentation for, 683
extensibility of, 668-670, 681
importing and exporting using XMI
problems with, 728
reasons for, 726-727
specification for, 729-730
version 1.0, 738-747
version 1.1, 747-754
integration with third-party tools, 675-676, 680, 682
MDA and, 677-679
navigation features, 665-667, 681
printing support by, 682
reporting by, 673-674, 682
repository for models, 667-668, 681
round-trip engineering by, 677
scalability of, 671
sharing models with, 670-672
technical support for, 683
UML diagram support, 663-665, 680
user interface for, 666, 683
VBA support by, 676
vendor's support for, 683
Web publishing by, 674-675, 682
XMI support, 757-758
model-level transformations, 644
modelLibrary stereotype, 838
modularity, 38-39
modules, modeling. See Component diagram
MOF (Meta Object Facility) specification
creating XMI from, 730-732
CWM and, 732
definition of, 4, 19-21
extending, 688
Moore state machine, 324
multi-object, 269
multiple inheritance, 207-208
multiple threads. See concurrency
multiplication operation (*()), OCL, 615, 617
multiplication operator (*), OCL, 596
Multiplicities package, 128
multiplicity
for associations, 126-130, 173-174, 186-187
for attributes, 126-130, 136-137, 143
definition of, 126
notation for, 126-128, 136-137, 143, 173
ordering of, 128, 174-175
range of values, 126-127
range without limit, 127
set of discrete values, 128
specific value, 127
UML 2.0 notation for, 128-130
in use case associations, 417
MultiplicityElement class, 128, 143, 153-154, 186
MultiplicityRange data type, 31
<Day Day Up>
<Day Day Up>
Index
N
name compartment
class name for, 110-113
for classes compared to objects, 228
notation for, 762, 796
for objects, 223-224
ports in, 119-120
presentation of, 109
properties in, 116-117, 119-120
stereotypes in, 113-116
Name data type, 31
NamedElement class, 142, 153-154
namespace
for packages, 511-512
XML, 737
Namespace class, 118-119
Namespace namespace, 118, 119
n-ary association
definition of, 193
notation for, 194, 768, 802
neg (negative) interaction operator, 302
nested actions, 656
nested object, 198-199
.NET, UML profile examples for, 691
No Magic, Inc., MagicDraw tool, 663
node. See also Combined Deployment and Component diagram; Deployment diagram
activity final node, 314-315, 469
artifacts deployed on, 579-582
attributes in, 571
communication paths between, 575-576
conditional node, 499-501
decision node, 314, 470-474, 826
definition of, 560, 570-574
devices in, 573
execution environments in, 573
expansion node, 497-499
final flow node, 484
fork node, 313, 474-475, 827
generalization of, 576
initial node, 314-315, 469
join node, 313, 474-475, 827
loop node, 501-505
merge node, 314, 470-474, 826
modeling, 560-563, 574-576
notation for, 789, 829
object node, 475-477, 488-489
operations in, 571
ports in, 572
stereotypes for, 572-573
not equal to sign (<>)
not equal to operation, OCL, 613, 614, 615
not equal to operator, OCL, 596
not() operation, 619
note, 181. See also comment
notEmpty() operation, 621
<Day Day Up>
<Day Day Up>
Index
O
object actions, 651
Object Constraint Language. See OCL
Object diagram. See also Class diagram
attribute compartment, 223-224
compared to Class diagram, 226-228
definition of, 36, 221, 664
drawing in modeling tool, 664, 665
name compartment, 223-224
notation for, 771-772, 805-806
testing Class diagram with, 228-234
UML 1.4 compared to UML 2.0, 44, 665
uses of, 53-54
object flow
behavior for, 487-488
definition of, 475
notation for, 475-477, 786
object lifeline. See also lifeline
definition of, 246
modeling, 248-249, 279-288
notation for, 249, 279-280
Object Management Group. See OMG
object node
customizations to, 488-489
modeling, 475-477
ObjectFlow class, 449
ObjectFlowState class, 448, 449
Object-Modeling Technique. See OMT
ObjectNode class, 449
Object-Oriented Analysis and Design. See OOA&D
object-oriented concepts. See OO concepts
Object-Oriented Software Engineering. See OOSE
objects. See also classes; Collaboration diagram; Communication diagram; instance; Object diagram; Sequence
diagram; State Machine diagram
abstractions of, 76-78
activation of, 261, 284-286
active object, 268
aggregate, part decomposition for, 281-283
anonymous, 223
associated, referencing, 599-602
behavior of, 79-80, 82
cohesion of, 96-98
collaborations and, 237-239
communication between, 99
compared to slots, 225-226
composite, 198-199
coupling (dependency) between, 98-100
creation of, 262-264, 774, 809, 836
data associated with, 82,85
deactivation of, 261
defining, 78-80
definition of, 76
destruction of, 262-264, 283-284, 774, 809, 837
encapsulation of, 80-85
exceptions raised by, 253
focus of control for, 261, 284
implementation (method) for, 82-83
interface (operation) for, 81
links between, 86-90, 224-225
multi-objects, 269
naming, 223-224, 281
nested, 198-199
notation for
in Collaboration diagram, 266-267
in Object diagram, 223-224, 771, 805-806
in Sequence diagram, 280-281
ports for, 222, 235-237
predefined properties for, 602-604
purpose of, 83
signals raised by, 253
state of, 79, 82, 286-288
structure of, 78
suspension of, 284-286
UML 2.0 definitions for, 225-226
unique identity of, 78
OCL (Object Constraint Language)
abstract syntax, 589-590
action semantics and, 639-640
backward compatibility of, 592
concrete syntax, 590-591
constraints defined with, 71
data types, 592-594, 612, 614, 615, 619
definition of, 14, 35, 587-588
expressions
applying to classes, 611
Collections in, 605-608
invariants on attributes, 595-597
invoking operations in, 598-599
navigating associations, 599-602
operators for, 596
overridden properties in, 602
post conditions on operations, 597-599
preconditions on operations, 597-599
predefined properties for, 602-604
result of, 592-594
sending messages with, 608-610
syntax for, 590-591, 594-595
tuples in, 611
variables in, 596-597
iterator expressions, 629-633
operations
for collection types, 619-629
for ModelElement types, 614-615
for OclAny data type, 612-613
for OclMessage data type, 613-614
for OclVoid data type, 614
for primitive types, 615-619
as query language, 590
version 2.0 enhancements, 588-589
OclAny data type, 612-613
ocllAsType property, 604
ocllnState property, 603-604
ocllsKindOf property, 603
oclIsNew() operation, 604, 613
oclIsTypeOf property, 603
oclIsUndefined() operation, 613, 614
OclMessage data type, 613-614
OclMessage expression, 608, 609-610
OclModelElement data type, 614
OclState data type, 615
OclState property, 602-603
OclType data type, 614-615
OclType property, 602-603
OclVoid data type, 614
OMG (Object Management Group). See also MDA
code generation and, 677
definition of, 15-16
profiles adopted by, 690-691
RTF (Revision Task Force) of, 8
UML development and, 4, 7-8
OMT (Object-Modeling Technique), 6, 61, 636
one() operation, 631
OO (object-oriented) concepts
abstraction, 76-78
associations, 85-90
books about, 101
classes, 76
cohesion, 96-98
coupling, 98-100
encapsulation, 80-85
generalization (inheritance), 90-94
history of, 5-8, 75
links, 85-90
objects, 76, 78-80
polymorphism, 94-96
UML supporting, 5, 10
OOA&D (Object-Oriented Analysis and Design), 27
OOSE (Object-Oriented Software Engineering), 6-7
operation. See also interface
class-level, 149-150, 155
common, interfaces for, 159-160
control stereotype and, 114
definition of, 84, 452
dependencies between, 836
exceptions for, 150-151
internal use of, 147
messages invoking, 253
modeling, 145-152
naming, 146-147, 154
for nodes, 561, 571
notation for, 154-156, 762, 796
OCL operations
for collection types, 619-629
for ModelElement types, 614-615
for OclAny data type, 612-613
for OclMessage data type, 613-614
for OclVoid data type, 614
for primitive types, 615-619
parameters for, 99, 147-148, 154
post conditions for, 151-152, 156, 597-599
preconditions for, 151-152, 156, 597-599
properties for, 149, 155
return-result of, 148-149, 154
signature of, 95, 146, 276
UML 2.0 definitions for, 153-156
in utility class, 115
visibility of, 121-126, 145-147, 154
operation compartment
for class definitions, 109-110
definition of, 144-145
notation for, 145-152, 762, 796
visibility in, 121-126
operators
content model operators in XML, 737-738
in OCL, 596
opt (option) interaction operator, 300
or() operation, 619
or operator, OCL, 596
{ordered} property, 174, 189
OrderingKind data type, 31
orthogonal composite state, 378
OS stereotype, 573
output pins, 477-478, 645-646, 654-655
ovals
dashed, indicating collaborations, 237
indicating use cases, 412, 422
overlapping constraint, 208
ownedEnd property, 185
<Day Day Up>
<Day Day Up>
Index
P
package. See also Package diagram
abstract, 512
access relationship between, 515-516, 832
containment of, 512, 518, 832
definition of, 50, 511
deleting, 517
dependencies between, 50-51, 514-517
elements in, 512-514
grouping in a model, 521-522
import (merge) relationship between, 516-517, 792, 833
model library in, 838
moving classes between, 667
namespace for, 511-512
notation for, 50, 512, 513-514, 791, 831-832
organizing
ICONIX Unified Modeling Approach method, 527
methods for, 522-523
RUP method, 523-531
package visibility within, 121, 123
specifying in class name, 112-113
for use cases, 406-407, 413-414
viewing in modeling tool, 665-666
Package class, 692
Package diagram
definition of, 664
drawing in modeling tool, 664, 665
modeling, 518
notation for, 791-794, 831-834
UML 1.4 compared to UML 2.0, 44, 665
uses of, 50-51
package visibility, 121, 123
PackageableElement class, 118-119
PackageableElement namespace, 118, 119
PackageImport metaclass, 693
Page-Jones, Meilir (Fundamentals of Object-Oriented Design in UML), 101
par (parallel) interaction operator, 300-301
parallel stereotype, 563
parameter
of actions and activities, 490-492
of class template, 158
of operations, 99, 147-148, 154
parameter stereotype, 841
ParameterDirectionKind data type, 31-32
parameterized (template) class
definition of, 594
modeling, 158-159
notation for, 763-764, 798
parent (superclass)
definition of, 92, 202-203
discriminator for, 206-207
parentheses(())
enclosing operation parameters, 147-148
grouping operator, XML, 737
part, 234-235
part decomposition, 281-283
Partition class, 448
partition (swimlane)
definition of, 479-480
modeling, 480-484
notation for, 786
partitioning, 38-39
path, factored. See factored path
pattern
applying with collaboration occurrence, 241
definition of, 13
modeling with collaboration, 237-239
notation for, 772, 806
UML support of, 11
Patterns of Software Systems Success and Failure (Jones), 101
Pennaneac'h, Francois (Using UML Action Semantics for Executable Modeling and Beyond), 644
permission dependency, 213, 215
pervasive services of MDA, 17, 18
physical file, 837
physical implementation. See also Component diagram
component as type of, 536
definition of, 535
mapping components to, 543-545
physical system, modeling, 35, 519, 521-522
PIM (platform-independent model)
code generation and, 678
mapping to and from PSMs, 679
MDA and, 16
using UML for, 4
pins
as array, 656
definition of, 645-646
modeling, 477-478
for nested action, 656
notation for, 654-655
platform-independent model. See PIM
platform-specific code generation, 643-644
platform-specific model. See PSM
plus sign (+)
addition operation, OCL, 615, 617
addition operator, OCL, 596
in circle, indicating package elements, 513
indicating public visibility, 121, 514
one or more operator, XML, 737
polymorphism
definition of, 94-96
interfaces used for, 159
Popkin Software, System Architect tool, 663, 758
port
for classes, 119-120
for components, 552-555, 556
for nodes, 572
notation for, 235-236, 371
for objects, 222, 235-237
for triggers, 371-372
types of, 236-237
Ports class, 119-120, 571-572
post condition
for actions, 485-486
definition of, 14, 67, 587, 597
modeling in Activity diagram, 460-461
for operations, 151-152, 156, 597-599
for use cases, 429-430
postcondition stereotype, 841
pound sign (#), indicating protected visibility, 121
powertype
definition of, 93
notation for, 205-206, 211-212
powertype stereotype, 205-206, 841
@pre keyword, indicating beginning value of property, 599
precondition
for actions, 485-486
definition of, 14, 67, 587, 597
modeling in Activity diagram, 459-460
for operations, 151-152, 156, 597-599
for use cases, 426-427
precondition stereotype, 841
prepend() operation, 627
primitive action, 646
primitive types
in OCL, 594, 615-619
in UML, 133
PrimitiveTypes package, 41, 117
private visibility
for classifiers in packages, 514
definition of, 122
to enforce encapsulation, 122, 133
notation for, 121
procedure
compared to action, 647
lifecycle of, 648
notation for, 655-656
ProcedureExpression data type, 32
process, 13
process stereotype, 839
profile
constraints in, 689
defining, 691-696
definition of, 3-4, 10, 72, 641, 688
industry-adopted profiles, 691
MOF and, 688
multiple, applying to one package, 694
OMG-adopted profiles, 690-691
removing from package, 694
standards for, 690
stereotype icons in, 689-690
stereotypes in, 688
tagged values in, 689
UML Profile for Business Modeling, 700-701
UML Profile for EJB, 696-701
UML Profile for Enterprise Application Integration (EAI), 702-706
UML Profile for Enterprise Distributed Object Computing (EDOC), 706-712
UML Profile for Schedulability, Performance, and Time, 712-714
UML Profile for Software Development Processes, 698-700
UML specification examples of, 691
UML Testing Profile, 714-717
WAE (Web Application Extension) profile, 717-721
Profile class, 692-693
Profile for Java, 691
profile stereotype, 692, 841
ProfileApplication metaclass, 693-694
Profiles package, 43, 691-692
program code. See software
program file, 837
programming by contract. See OCL
programming languages. See also Java
for action semantics, 640-641
ports for, 119-120
UML independence from, 10, 12
Project Technology, Inc., UML compilers by, 4
property. See also tagged value
of attributes, 139-141, 143-144
of classes, 116-117, 119-120
modeling tools extending, 668
notation for, 116, 139, 149
of operations, 149, 155
predefined, in OCL, 602-604
UML 2.0 definition of, 119, 141-144
in user-defined compartments, 156-157
protected visibility
definition of, 124-126
for generalization, 202
notation for, 121
{protocol} keyword, 391
protocol state machine
definition of, 390
modeling, 391
specialization of, 392-393
states in, 391
transitions in, 391-392
Protocol State Machine diagram
definition of, 390
modeling, 390-393
notation for, 824
uses of, 67-68, 390
prototypes, compared to scenarios, 433-434
provided interface
for components, 549
definition of, 162, 236
notation for, 162-163
for subsystems, 520
pseudo state
choice pseudo state, 376, 381-382
definition of, 326
fork pseudo state, 379-380
history pseudo state, 357
initial state, 326-327, 374, 777, 817
join pseudo state, 380-381
junction pseudo state, 381-382
static branch point, 340, 778, 819
terminate pseudo state, 382-383
PseudostateKind data type, 32, 364-365
PSM (platform-specific model)
code generation and, 678
mapping to and from PIMs, 679
MDA and, 16
using CWM for, 4
public visibility
for classifiers in packages, 514
definition of, 123-124
notation for, 121
publications. See also specifications
about action semantics, 642
about action specifications for UML, 637
about executable UML, 641
about languages for embedded systems, 641
about MDA, 644
about modeling design approaches, 637
about model-level transformations, 644
about object-oriented design, 101
about UML profiles, 690-691
<Day Day Up>
<Day Day Up>
Index
Q
qualified association
definition of, 188
navigating, 602
notation for, 767, 801
qualifier
definition of, 177
notation for, 177-179
UML 2.0 changes to, 188
query language, OCL, 590
question mark (?), zero or one operator, XML, 737
<Day Day Up>
<Day Day Up>
Index
R
range of values, in multiplicity, 126-127
Rational Rose tool (IBM), 663, 758
Rational Unified Process. See RUP
read actions, 650-651
Real data type, 615-617
realization
connectors and ports for, 551-556
definition of, 95, 547, 567, 569
modeling, 547-549
notation for, 793, 828, 834
realization compartment, subsystem, 520-521
realization stereotype, 520-521, 548, 839
realize stereotype, 841
realizes stereotype, 521
receive signal, 376-377, 782, 823
receiver object, 61
rectangles. See also squares
at association end, indicating qualifier, 178
dashed
indicating structured activity, 496
indicating suspension, 285
indicating template parameters, 158
with folded corner, indicating comments, 181
with folder tab, indicating package, 512
icons in
boundary icon, 699
component icon, 56, 540, 546
composite icon, 349
control icon, 114-115, 699
entity icon, 114-115, 699, 701
file icon, indicating artifact, 578
fork icon, indicating subsystem, 519
triangle icon, indicating model, 522
on lifeline, indicating activation or focus of control, 284
overlapping, indicating recursion, 262
rounded
indicating activity, 453
indicating state, 326, 368
indicating state invariant, 286-288
indicating structured activity, 496
with thick border, indicating active object, 268
three-dimensional, indicating nodes, 575-576
on timeline, indicating activation or focus of control, 261, 284
two, connected, indicating composite state, 349
two, overlapping element rectangle, indicating component, 540, 546
RedefinableElement class, 118-119
{redefined} property, 189
reduce action, 653
ref operator, 297
Refactoring-Improving the Design of Existing Code (Fowler), 101
reference attribute, 131
referenced class, 113
referenced state machine, 351
refine stereotype, 839
refinement
abstraction through, 213-215
definition of, 13
dependency, 839
refinement stereotype, 15, 215
reflexive association
definition of, 182
notation for, 765, 799
region (critical region) interaction operator, 302
region, in composite state
definition of, 351, 377
entering and exiting, 383-387
modeling, 378-379
reject() operation, 606, 632, 633
relationship
associations
between actors and use cases, 407, 416-417
aggregation, 87-89, 165, 194-197
binary, 167-168
changeability of, 180, 187
communication paths, 575-576
compared to generalization, 91, 201-202
composition, 89-90, 165-166, 197-200
constraints between, 180-181, 766, 800
constraints on objects in, 175-177
coupling and, 99
definition of, 86-87, 165-167, 228, 560
derived, 182-183, 767, 801
direction of, 168-169
interface required for, 172, 183
modeling, 168-180
multiplicity of, 126-130, 173-174, 186-187
naming, 168-170
n-ary (between more than two classes), 193-194, 768, 802
navigability of, 179-180, 189-190, 766, 800
navigating, 599-602
between nodes, 560-563
notation for, 765-769, 799-802
ordering for multiple objects in, 174-175, 188
qualified, 767, 801
qualifiers for objects in, 177-179
reflexive, 182, 765
roles of objects in, 171-172, 188
stereotypes for, 563
UML 2.0 definitions for, 183-190
visibility of roles in, 172
definition of, 165
dependency
between artifacts and nodes (deployment), 579-582
between components, 55-56, 536, 542-543, 547
on creation of classifier instance, 836, 838
definition of, 166,213
on derived elements, 837
between nodes (manifestation), 578
notation for, 213-215, 770-771, 804-805
between operations, 836
between packages, 50-51, 514-517
refinement, 839
on sending a signal, 839
stereotypes for, 215-216, 836-840
on trace relationship between elements, 840
types of, 213, 216
UML 2.0 notation for, 216-217
generalization
of actors in use cases, 408, 411-412
compared to association, 91, 201-202
constraints for, 208-209, 211-213
definition of, 90-94, 166, 200-201
discriminators and, 206-207, 211
multiple, 207-208
of nodes, 576
notation for, 202-209, 211-213, 769-770, 803-804, 824
polymorphism and, 94-95
powertypes and, 205-206, 211
protected visibility within, 121, 124-126
separate target style of notation, 203
shared target style of notation, 203-204
UML 2.0 definitions for, 210-213
of use cases, 408
reports generated by modeling tools, 673-674, 682
repository
audit trails for, 672
change management for, 672
definition of, 107, 667-668
importing and exporting from, 676
modeling tools with multiuser repository, 663
MOF requirements for, 20
requirements for, 681
scalability of, 671
required interface
for components, 549
definition of, 162, 235-236
notation for, 162-163
for subsystems, 520
requirement stereotype, 841
requirements management tools, 675
reside stereotype, 543-544
resident class, 788
resources
associations between, 165
classes modeling, 52-53, 107-108
collaborations modeling, 54-55, 234
modeling in use cases, 414-415
responsibility stereotype, 839
result() operation, 609, 613
return-result
definition of, 148
notation for, 148-149, 154
reuse
Communication diagram and, 63
encapsulation and, 236
as goal of UML 2.0, 38-39
of interactions, 64, 295-296
model library and, 838
Sequence diagram and, 277
of state machines, 377
of use cases, 418
Revision Task Force, See RTF
Rhapsody tool (I-Logix), 663
role
of actors in use cases, 409-410
in associations, 171-174, 188
in collaborations, 237-239
round() operation, 616
RTF (Revision Task Force), 8
Rumbaugh, James
OMT developer, 6-7
Sequence diagram developer, 61
runtime environment, modeling, 563-565
RUP (Rational Unified Process)
analysis model, 524-528
definition of, 523
design model, 528-530
implementation model, 530
overall hierarchy, 531-532
testing model, 531
use case model, 523-524
<Day Day Up>
<Day Day Up>
Index
S
scenario. See also Sequence diagram
applying to test cases, 443
definition of, 432-433
finding, 434-435
modeling with Activity diagram, 434-442
modeling with Sequence diagram, 247, 432
as part of use case approach, 400, 405-406
reasons to use, 433-434
Schedulability, Performance, and Time, UML Profile for, 690, 712-714
ScopeKind data type, 32
script library icon, 721
script stereotype, 839
SDL (Specification and Description Language), 6
security with modeling tools, 671-672
select() operation, 606, 632, 633
self stereotype, 841
self transition
definition of, 337-338, 372
notation for, 337, 778, 818
self-reference message, 254-255, 807
send event, 338
send signal, 376-377, 782, 823
send stereotype, 216, 839
sender object, 61
seq (weak sequence) interaction operator, 301
Sequence
definition of, 605
iterator expressions for, 633
operations for, 626-629
Sequence diagram
collaboration in, 240, 304-306
compared to Collaboration diagram, 269-270
compared to Statechart diagram, 325
definition of, 37, 664
deriving Statechart diagram from, 324, 343-348
integrating with Class diagram, 270-271
notation for, 773-775, 807-813
for RUP design model, 530
UML 1.4 compared to UML 2.0, 45
UML 1.4 features of
activation shown in, 261
asynchronous messages in, 255-256
branching in, 260
comments in, 257
conditions in, 259-260
example, 264-265
focus of control shown in, 261
iterations in, 258-259
messages in, 249-253
object creation and destruction, 262-264
object lifelines in, 248-249
purpose of, 246-248
recursion in, 261-262
self-reference messages in, 254-255
synchronous messages in, 254
timed messages in, 257-258
UML 2.0 features of
combined fragments in, 298-304
focus of control shown in, 284
frames in, 278-279
interaction occurrences in, 295-298
messages in, 288-295
new features, 277-278
object activation and suspension, 284-286
object destruction, 283-284
object lifelines in, 279-288
part decomposition in, 281-283
state invariant in, 286-288
use case scenarios modeled with, 247, 432
uses of, 61-62
{sequence} property, 189
server page icon, 717
service port, 236-237
service stereotype, 839
servlet icon, 721
Servlet stereotype, 579
Set
definition of, 605
iterator expressions for, 632
operations for, 621-623
shallow history, 385, 780, 820
shapes in diagrams. See arrows; circles; diamonds; icons; lines; ovals; rectangles; squares
Shlaer-Mellor approach of modeling, 637
signal. See also message
definition of, 253
exception as, 253
modeling, 376-377
notation for, 782, 823
signal port, 236
signalflow stereotype, 841
signature of operation
definition of, 95, 146
modeling, 276
size() operation, 618, 620
slash (/)
division operation, OCL, 615, 617
division operator, OCL, 596
indicating derived association, 182-183
indicating derived attribute, 134
separating event from action, 333
slot, 225-226
Slot class, 225-226
SMIF (Stream-based Model Interchange Format), 731
software. See also Combined Deployment and Component diagram; Component diagram; modeling tools
artifacts as, 536, 577-578, 579-582
for checking validity of XMI, 757-758
code generation
action semantics enabling, 643-644
from Class diagram, 106
MDA and, 677-679
modeling tools supporting, 676-677, 683
with XMI, 677, 726, 728-729
modeling tools
access control and security for, 671-672
advantages of using, 661-662
audit trails for, 672
categories of, 663
change management for, 672, 681
choosing, checklist for, 679-683
code generation and reversal by, 676-677, 683
documentation for, 683
extensibility of, 668-670, 681
importing and exporting using XMI, 726-730, 738-747, 747-754
integration with third-party tools, 675-676, 680, 682
MDA and, 677-679
navigation features, 665-667, 681
printing support by, 682
reporting by, 673-674, 682
repository for models, 667-668, 681
round-trip engineering by, 677
scalability of, 671
sharing models with, 670-672
technical support for, 683
UML diagram support, 663-665, 680
user interface for, 666, 683
VBA support by, 676
vendor's support for, 683
Web publishing by, 674-675, 682
XMI support, 757-758
programming language independence, 10, 12
requirements management tools, 675
structured programming support with Activity diagram, 450
testing tools, 675
Software Development Processes, UML Profile for, 691, 698-700
"Software-Platform-Independent, Precise Action Specifications for UML" (Mellor; Tockey; Arthaud; LeBlanc), 637
sortedBy() operation, 631
source stereotype, 579, 839
spaces, in class names, 110
specialization, 91, 200-201. See also generalization
Specification and Description Language. See SDL
specification compartment, subsystem, 520-521
specification stereotype, 520, 548, 840
specification-level state machine, 556
specifications. See also publications
action semantics specification, 636
CWM specifications, 21
Diagram Interchange specification, 730, 754-757
MDA (Model-Driven Architecture), 18
UML 1.4, 27
UML 1.5 with Action Semantics specification, 588
UML 2.0, 117
UML support of other specifications, 10
XMI (XML Metadata Interchange), 729-730
square brackets ([])
indicating context of association, 601
indicating message conditions, 259-260
indicating multiplicity, 126
indicating number of parts in class, 235
indicating qualifier for association, 602
squares. See also rectangles
on edge of action, indicating input or output pins, 477, 654-655
at end of connectors, indicating ports, 235-236
with "T" inside, indicating template class, 593, 594, 612
Standard Elements, 836-841
Stan-Ober, Ileana ("Harmonisation of Modeling Languages with Object-Oriented Extensions and Executable
Semantics"), 642
state. See also Protocol State Machine diagram; State Machine diagram; Statechart diagram; Timing diagram
active, 378
activities performed during, 325, 335-336
attributes applied during specific states, 326, 366
attributes storing information about, 130-131, 325, 366
changes to, 324-325
composite
compared to submachine state, 388
concurrent substates in, 351, 357-360, 780, 821
definition of, 348-349, 367, 377-378
direct substates in, 377
entering and exiting, 383-387
mutually exclusive substates in, 350
notation for, 349
orthogonal, 378
regions in, 351, 377, 378-379
returning to previous substate in, 357
submachine states in, 351-352
transitions in, 352-360, 379-387
transitively nested states in, 377
definition of, 79, 325, 366
deriving from Sequence diagram, 343-348
event response affected by, 329-330
extending to composite state, 369
final, 327, 374, 777, 817
inactive, 378
initial, 326-327, 374
modeling, 366-369
notation for, 286-288, 326-327, 368
oclInState property, 603-604
OclState property, 602-603
in protocol state machine, 391
state list, 382
submachine state, 351-352, 367
substate
concurrent, 351
definition of, 325, 349-350
direct substate, 377
mutually exclusive, 350
returning to previous substate, 357
transitions to and from, 352-355
superstate, 325, 349
transition between, 325, 372
UML 2.0 definitions for, 364-365
state attributes, 326
state invariant
modeling, 286-288
notation for, 808
state machine
definition of, 34, 363, 365-366
implementing a protocol state machine, 392-393
specification-level, 556
State Machine diagram. See also Statechart diagram
collaboration in, 240
compared to Activity diagram, 363, 448
composite states in, 377-387
definition of, 365-366, 387, 665
notation for, 817-824
ports in, 371-372
signals in, 376-377
states in, 366-369, 374
submachine states in, 387-389
transitions in, 372-373, 374-376
triggers in, 369-372
UML 1.4 compared to UML 2.0, 44
uses of, 66-67
state timeline, 316-318
state transition
actions in, 375-376
branching in, 339-341, 381-382
completion transition, 374-375, 386, 823
in composite states, 352-360, 379-387
compound, 339-342
in concurrent substates, 357-360
constraints for, 373
definition of, 325, 372
forking, 379-380
guard condition for
in Activity diagram, 453-454, 785, 827
in State Machine diagram, 370-371, 373, 817
in Statechart diagram, 777
internal, 325, 333-337, 368
joining, 380-381
modeling, 328-333, 370-376
notation for
in Activity diagram, 453, 827
in State Machine diagram, 370-371, 817-818, 823-824
in Statechart diagram, 328, 777-778
in protocol state machine, 391-392
relationship to event, 328
self transition, 337-338, 372, 778, 818
signals sent and received during, 376-377
in stub states, 356
in substates, 352-355
Statechart diagram. See also State Machine diagram
compared to Sequence diagram, 325
composite state containing, 349, 377
definition of, 37, 323-325, 664
deriving from Sequence diagram, 324, 343-348
events in, 327-333, 337
internal transitions in, 333-337
notation for, 777-783
split and merge of control in, 358, 781
states in, 326-327
synch states in, 358-359
transitions in, 328-333, 337-342
UML 1.4 compared to UML 2.0, 44, 246
when to use, 324
stateInvariant stereotype, 841
static branch point, 340, 778, 819
static (class-level) attribute
definition of, 141
notation for, 141, 143
static (class-level) operation
definition of, 149
notation for, 150, 155
static view diagrams, 36-37
stereotype. See also specific stereotypes for artifacts, 579
for associations, 563
for components, 540-541
for control elements, 113-115
defined within UML, 70
definition of, 12-13, 68-70, 113
for dependencies, 215-216, 836-840
for entity elements, 113-115
for enumerations, 116
for execution environments, 573
icons for, 689-690
list of, 836-841
modeling tools extending, 668
for node associations, 563
for nodes, 572-573
notation for, 69, 113, 115
for objects, 223
obsolete, 841
for operations, 144-145
for packages, 512
in profiles, 688
profiles providing, 72
in user-defined compartments, 157
for utility classes, 115
stereotype class. See auxiliary class
Stereotype metaclass, 693, 695-696
stereotype stereotype, 695
stimulus, 249, 252-253. See also message
stop icon, 320
Stream-based Model Interchange Format. See SMIF
streaming, 491-492
strict (strict sequence) interaction operator, 302
String data type, 32, 618-619
structural diagrams. See also Class diagram
Combined Deployment and Component diagram
notation for, 790, 830-831
UML 1.4 features of, 563-565
UML 2.0 features of, 569-570
uses of, 57-58
Component diagram
definition of, 36, 535-536, 664
notation for, 787-788, 828
for RUP implementation model, 530
UML 1.4 compared to UML 2.0, 537-539, 568-569
UML 1.4 features of, 539-543
UML 2.0 features of, 545-556
uses of, 55-56, 535-536, 537
Composite Structure diagram
classes in, 235
collaboration in, 237-239, 304
collaboration occurrence in, 239-241
connectors in, 235-237
definition of, 221-222, 234, 665
notation for, 803
ports in, 235-237
UML 1.4 compared to UML 2.0, 45
uses of, 54-55
Deployment diagram
notation for, 829
for RUP design model, 528
for RUP implementation model, 530
UML 1.4 compared to UML 2.0, 569
UML 1.4 features of, 560-565
UML 2.0 features of, 567, 570-582
uses of, 57, 537, 559-560, 568-569
list of, 51-58
Object diagram
attribute compartment, 223-224
compared to Class diagram, 226-228
definition of, 36, 221, 664
drawing in modeling tool, 664, 665
name compartment, 223-224
notation for, 771-772, 805-806
testing Class diagram with, 228-234
UML 1.4 compared to UML 2.0, 44, 665
uses of, 53-54
structural feature. See attribute; slot
structural view diagrams. See static view diagrams
StructuralFeature class, 186
Structure elements, Superstructure library, 43
StructureClassifiers class, 571-572
structured activity
expansion regions for, 496-499
loop nodes for, 501-505
notation for, 495-496
structured activity nodes
conditional, 499-501
modeling, 495-496
StructuredActivities level, 450
StructuredActivities package
conditional nodes, 499-501
expansion regions and expansion nodes, 496-499
list of features in, 467, 494
loop nodes, 501-505
structured activity nodes, 495-496
StructuredClassifier node, 571-572
StructuredCompleteActivities level, 450
StructuredFeature class, 143
stub states
definition of, 351
notation for, 352, 781, 822
transitions to and from, 356
stub stereotype, 841
subactivity state, 448, 449
SubactivityState class, 448
subclass
definition of, 92, 202-203
discriminator for, 206-207
powertype for, 205-206
submachine, 387
submachine state
compared to composite state, 388
definition of, 366, 367, 388
modeling, 351-352, 387-389
notation for, 781, 822
subpackage, 406, 518
subSequence () operation, 628
{subsets} property, 189
subsettedProperties attribute, 144
substate
concurrent, 351, 357-360, 780, 821
definition of, 325, 349-350
direct substate, 377
mutually exclusive, 350
returning to previous substate, 357
transitions to and from, 352-355
substitution dependency, 216-217
substitution stereotype, 216-217
substring() operation, 618
subsystem
compartments in, 520-521
definition of, 519
grouping in a model, 521-522
interfaces for, 520, 793
notation for, 519-520, 793, 833-834
subsystem stereotype, 519, 840
subtraction operation (-()), OCL, 615, 617, 622
subtraction operator (-), OCL, 596
sum() operation, 621
Suny, Gerson (Using UML Action Semantics for Executable Modeling and Beyond), 644
superclass
definition of, 92, 202-203
discriminator for, 206-207
superstate, 325, 349. See also composite state
Superstructure library, 38, 43-44, 117, 118
Supplemental elements, Superstructure library, 43, 44
supplier, 14
swimlane (activity partition)
definition of, 479-480
modeling, 480-484
notation for, 786
symmetricDifference() operation, 622-623
synch state
definition of, 358
notation for, 359, 782, 822
synchronization bar, 358, 456-457
synchronous invocation, 653
synchronous message, 254, 290-292
System Architect tool (Popkin Software), 663, 758
system, public visibility within, 121, 123-124
systemModel stereotype, 840
<Day Day Up>
<Day Day Up>
Index
T
"T", indicating template class, 593, 594, 612
table stereotype, 541, 841
tag definition 70
tagged value. See also property
definition of, 13, 70
modeling tools extending, 668
notation for, 70, 763
in profiles, 689
transferring with XMI, 745-747, 751-754
target icon, 719
Telelogic, UMLTau tool, 663
template class
definition of, 594
modeling, 158-159
notation for, 763-764, 798
terminate pseudo state, 382-383
TestIdentityAction, 651
testing model, for RUP method, 531
thread stereotype, 841
threads, 13. See also concurrency
"three amigos". See Booch, Grady; Jacobson, Ivar; Rumbaugh, James
tilde (~), indicating package visibility, 121
time constraints
definition of, 257
notation for, 258, 775, 811
time event. See elapsed-time event
timed message, 257-258
TimeExpression data type, 32
timeline. See also lifeline; object lifeline
general value timeline, 319-320
state timeline, 316-318
Timing diagram
definition of, 315-316, 665
general value timeline, 319-320
lifelines in, 316, 318-319
notation for, 816-817
state timeline, 316-318
UML 1.4 compared to UML 2.0, 45
uses of, 65-66
TogetherSoft tool (Borland), 663
toInteger() operation, 618
topLevel stereotype, 841
toReal() operation, 619
trace stereotype, 15, 215, 840
traceability, 410-411
transient stereotype, 267-268
transition
actions in, 375-376
branching in, 339-341, 381-382
completion transition, 374-375, 386, 823
in composite states, 352-360, 379-387
compound, 339-342
in concurrent substates, 357-360
constraints for, 373
definition of, 325, 372
forking, 379-380
guard condition for
in Activity diagram, 453-454, 785, 827
in State Machine diagram, 370-371, 373, 817
in Statechart diagram, 777
internal, 325, 333-337, 368
joining, 380-381
modeling, 328-333, 370-376
notation for
in Activity diagram, 453, 827
in State Machine diagram, 370-371, 817-818, 823-824
in Statechart diagram, 328, 777-778
in protocol state machine, 391-392
relationship to event, 328
self transition, 337-338, 372, 778, 818
signals sent and received during, 376-377
in stub states, 356
in substates, 352-355
translational approach of modeling, 637
triangle. See arrows
triangle icon, 522
trigger. See also event
definition of, 327, 369
modeling, 369-372
Trigger class, 364-365
tuples, in OCL, 611
type, 108. See also data types
type stereotype, 840
TypedElement class, 142, 186
TypeExpression data type, 32
type-level Deployment diagram, 561-562, 789, 829
<Day Day Up>
<Day Day Up>
Index
U
UML 1.4, unique aspects of
Activity graph, 33, 34, 45, 450
architecture for, 27-35
Behavioral Elements package, 33-34
Collaboration diagram
active objects in, 268
compared to Sequence diagram, 269-270
definition of, 37, 265-266, 664
integrating with Class diagram, 270-271
links in, 266-267
messages in, 267-268
multi-objects in, 269
notation for, 776
objects in, 266-267
for RUP design model, 530
UML 1.4 compared to UML 2.0, 45, 246
uses of, 62-63
comments, 72
Composite Object diagram, 44
diagrams, 36-38, 664
Foundation package, 27, 28-33
Model Management package, 35
OCL, 35
Statechart diagram
compared to Sequence diagram, 325
composite state containing, 349, 377
definition of, 37, 323-325, 664
deriving from Sequence diagram, 324, 343-348
events in, 327-333, 337
internal transitions in, 333-337
notation for, 777-783
split and merge of control in, 358, 781
states in, 326-327
synch states in, 358-359
transitions in, 328-333, 337-342
UML 1.4 compared to UML 2.0, 44, 246
when to use, 324
UML 1.4 with Action Semantics
action languages designed using, 644
advantages of, 642
code generation enabled by, 643-644
definition of, 14, 35-36, 635-636, 645-648
example notation for, 654-657
history of, 8, 636-638
language-independence of, 638
languages used for, 638-639, 640-641
model-level transformations defined using, 644
necessity of, 636-639
OCL and, 639-640
as UML 1.5, 5, 27
uses of, 639-641, 643-644
UML 1.5, 5
UML 2.0, unique aspects of
Activity diagram changes, 448-450
aggregation definitions, 199-200
artifacts, 567-568
association definitions, 183-190
attribute definitions, 119, 141-144
class definitions, 117-120
collaboration occurrence, 239-241
Combined Deployment and Component diagram changes, 569-570
Communication diagram
definition of, 307, 665
guard condition in, 311
iteration expression in, 309
modeling, 307-308
notation for, 814
parallel execution in, 310
UML 1.4 compared to UML 2.0, 45
uses of, 63-64
component definitions, 567-568
Component diagram changes, 545-556
Composite Structure diagram
classes in, 235
collaboration in, 237-239, 304
collaboration occurrence in, 239-241
connectors in, 235-237
definition of, 221-222, 234, 665
notation for, 803
ports in, 235-237
UML 1.4 compared to UML 2.0, 45
uses of, 54-55
composition definitions, 199-200
Core package, 40-42
dependency definitions, 216-217
diagrams, 44-45, 665
generalization definitions, 210-213
Infrastructure library, 38, 40-43
Interaction Overview diagram
definition of, 312, 665
modeling, 312-315
notation for, 815-816
UML 1.4 compared to UML 2.0, 45
uses of, 64-65
interface definitions, 161-163
levels of compliance, 450
multiplicity definitions, 128-130
node definitions, 570-574
notes, 181
object definitions, 225-226
objectives of, 14-15
OCL enhancements, 588-589
operation definitions, 153-156
Profiles package, 43
Protocol State Machine diagram
definition of, 390
modeling, 390-393
notation for, 824
uses of, 67-68, 390
RFPs, Web sites for, 39
state definitions, 364-365
State Machine diagram
collaboration in, 240
compared to Activity diagram, 363, 448
composite states in, 377-387
definition of, 365-366, 387, 665
notation for, 817-824
ports in, 371-372
signals in, 376-377
states in, 366-369, 374
submachine states in, 387-389
transitions in, 372-373, 374-376
triggers in, 369-372
UML 1.4 compared to UML 2.0, 44
uses of, 66-67
subsystem definition, 519
Superstructure library, 38, 43-44
Timing diagram
definition of, 315-316, 665
general value timeline, 319-320
lifelines in, 316, 318-319
notation for, 816-817
state timeline, 316-318
UML 1.4 compared to UML 2.0, 45
uses of, 65-66
Use Case diagram changes, 403-404, 415-416
UML metamodel. See metamodel
UML package, 43-44
UML Partners Consortium, 7-8
UML Profile for Business Modeling, 691, 700-701
UML Profile for CORBA, 691
UML Profile for EJB, 696-701
UML Profile for Enterprise Application Integration (EAI), 690, 702-706
UML Profile for Enterprise Distributed Object Computing (EDOC), 690, 706-712
UML Profile for Schedulability, Performance, and Time, 690, 712-714
UML Profile for Software Development Processes, 691, 698-700
UML profiles. See profile
UML Testing Profile, 691, 714-717
UML (Unified Modeling Language). See also diagrams; extensibility of UML; modeling tools
architecture of, 23-26, 27-36, 38-44
definition of, 3-4
features of, 12-14
goals of, 7, 9-11
history of, 5-8
OMG and, 15-21
scope of, 11-12
UMLTau tool (Telelogic), 663
underline
indicating class-level attribute, 141
indicating class-level operation, 150
indicating instance in collaboration, 238
indicating object name expression, 223
underscore character, in class names, 110
Unified Modeling Language. See UML
Uninterpreted data type, 33
uninterpreted strings, 636
union() operation, 621, 624, 626-627
{union} property, 189
unknown message, 292
UnlimitedInteger data type, 32
UnmarshalAction, 651
{unordered} property, 175
usage dependency, 213, 216
use case. See also Activity diagram; Use Case diagram
association with actor, 407, 416-417
assumptions for, 424-426
as basis for Sequence diagram, 247
classifiers and, 415-416
CRUD checklist for, 414-415
definition of, 34, 407
dialog for, 428-429, 461-463
extending another use case with, 419-423
including another use case in, 418-419
initiation for, 427
minimal guarantees of, 431
modeling, 412-415, 451
notation for, 783, 825
post conditions for, 429-430
preconditions for, 426-427
RUP method for, 523-528
successful guarantees of, 431-432
termination of, 429
use case approach. See also scenario; Use Case diagram; use case narrative
definition of, 399-400
goal-focused modeling used in, 402-403, 413
levels of requirements for, 401
scenarios and, 400, 405-406
scope of, 400, 404-405
Use Case diagram and, 400, 404-405
use case narratives and, 399-400, 405
Use Case diagram
actors in, 407
associations in, 407, 416-417
definition of, 37, 399-400, 664
elements of, 407-408
extend relationships in, 408, 419-423
include relationships in, 407, 418-419
modeling, 408-409
notation for, 783, 825
packages in, 406-407, 413-414
UML 1.4 compared to UML 2.0, 403-404
UML 2.0 changes in, 403-404, 415-416
use cases in, 407, 412-415
uses of, 59, 399-403
use case instance. See scenario
use case model
definition of, 406
for RUP method, 523-524
use case narrative
assumptions in, 424-426
constructing Activity diagram from, 435-442, 457-464
dialog in, 428-429, 461-463
elements of, 423-424
minimal guarantees in, 431
as part of use case approach, 399-400, 405
post conditions in, 429-430
preconditions in, 426-427
success guarantees in, 431-432
use case initiation and triggers in, 427
use case termination in, 429
use case package, 406
use case realization, 526
use case scenario. See scenario
use case system, 406
use stereotype, 216
user object layer, 26
user-defined compartment
modeling, 156-158
notation for, 762, 796
users. See actor
uses stereotype, 550
Using UML Action Semantics for Executable Modeling and Beyond (Sunye; Pennaneac'h; Ho; Le Guennec;
Jzquel), 644
utility class, 115
utility stereotype, 115, 840
<Day Day Up>
<Day Day Up>
Index
V
valid XML documents, 735
ValueSpecification class, 226
variable actions, 651
VBA (Visual Basic for Applications), 676
versioning of models, 672, 681
vertex, 370, 372
vertical bar (|), selection operator, XML, 737
visibility
for associations, 172
for attributes, 121-126, 133, 142
of classifiers in packages, 514
definition of, 121-122
multiple, overriding rules for, 125
notation for, 121, 133, 142, 145-146
for operations, 121-126, 145-146, 154
package, 121, 123
private, 121, 122, 133, 514
protected, 121, 124-126, 202
public, 121, 123-124, 514
VisibilityKind class, 126
VisibilityKind data type, 33
Visual Basic for Applications. See VBA
<Day Day Up>
<Day Day Up>
Index
W
WAE (Web Application Extension) profile, 691, 717-721
weak sequence (seq) interaction operator, 301
Web page icon, 720
Web publishing by modeling tools, 674-675, 682
Web sites
action semantics specification, 636
companies using MDA, 19
CWM specifications, 21
Kabira Technologies, 4
Project Technology, Inc., 4
Shlaer-Mellor approach of modeling, 637
UML 1.5 with Action Semantics specification, 588
UML 2.0 RFPs, 39
XML Notepad, 758
well-formed XML documents, 734-735
when clause, notation for, 777, 818
white box view of component, 550
worker icons, 701
workflow
determining requirements for, 430
modeling with Activity diagram, 451
use case assumptions affecting, 425-426
workflow engine stereotype, 573
write actions, 650-651
<Day Day Up>
<Day Day Up>
Index
X-Z
"X"
indicating end of timeline, 320
indicating object destruction, 263-264, 283
indicating termination of state machine, 382-383
XMI (XML Metadata Interchange)
checking validity of, 757-758
code generation and reversal with, 677, 726, 728-729
creating from MOF, 730-732
definition of, 4, 21, 725-727
Diagram Interchange specification for, 730, 754-757
importing and exporting models with
version 1.0, 738-747
version 1.1, 747-754
MDA and, 728-729
problems with, 728
purposes of, 726-727
specification for, 729-730
versions of, 730
XSLT transforming, 729
XML
attributes, 735-736
content model operators, 737-738
definition of, 732-733
document correctness of, 734-735
DTDs for, 733-734
elements, 735
entities, 736-737
instance documents, 733
modeling tools importing and exporting from, 676
namespaces, 737
XML Core Services 4.0 RTM, checking XMI with, 757
XML Metadata Interchange. See XMI
XML Notepad, checking XMI with, 757-758
XML schema, 734
XMLSpy tool (Altova), checking XMI with, 757-758
xor() operation, 619
xor operator, OCL, 596
{xor} property, 181
XSLT (extensible Stylesheet Language Transformations), 729
<Day Day Up>
<Day Day Up>
List of Figures
Preface
Figure FM-1: Using gray shaded rounded rectangles to highlight changes in the metamodel.
Figure FM-2: Using gray shaded rounded rectangles to highlight elements of an illustration.
Chapter 1: What Is UML?
Figure 1-1: The Model-Driven Architecture.
Figure 1-2: The relationship between the MOF and the UML and CWM languages.
Chapter 2: UML Architecture
Figure 2-1: A metamodel defining Class and Association instantiated in a model containing two instances of
class and an instance of association (the arrow between Person and Car).
Figure 2-2: A metamodel defining a Class and an Instance Specification instantiated by a diagram containing a
class and an object.
Figure 2-3: Top-level packages of UML 1.4.
OMG 1.4
Figure 2-4: UML 1.4 Foundation packages.
OMG 1.4
Figure 2-5: UML 1.4 Behavioral Elements packages.
OMG 1.4
Figure 2-6: UML 1.4 Action example.
OMG 1.4
Figure 2-7: Three complementary sets of diagramming tools.
Figure 2-8: UML 2.0 Infrastructure defines the core metamodel for the rest of the MDA components.
Figure 2-9: UML 2.0 Core package.
Figure 2-10: The relationship between MOF and the Infrastructure Core package.
Figure 2-11: The SuperstructureLibrary package.
Chapter 3: UML Diagrams and Extension Mechanisms
Figure 3-1: A screen shot of a typical modeling tool with menu, navigation area, thumbnail view, canvas, and
diagram-specific toolbar.
Figure 3-2: Package icon.
Figure 3-3: Package dependency.
Figure 3-4: A class with the three predefined compartments.
Figure 3-5: A Class diagram with a relationship called "authorizes."
Figure 3-6: Object diagram.
Figure 3-7: Composite Structure diagram of a pricing strategy.
Figure 3-8: A Composite Structure diagram representing a collaboration.
Figure 3-9: UML 1.4 Component diagram using components and dependencies.
Figure 3-10: UML 2.0 Component diagram using components and dependencies.
Figure 3-11: Deployment diagram with four nodes and their connections.
Figure 3-12: Combined Component and Deployment diagram.
Figure 3-13: Use Case diagram showing the customer's expectations for using the sales system.
Figure 3-14: Activity diagram for selecting a theater performance.
Figure 3-15: Sequence diagram of a portion of the "Select a Performance" use case.
Figure 3-16: A Collaboration diagram version of the "Select a Performance" sequence from Figure 3-15.
Figure 3-17: A Communication diagram modeling an interaction that includes another interaction, the sd
(Collaboration diagram) "get performances."
Figure 3-18: An Interaction Overview diagram modeling the logical progression through a series of
interactions.
Figure 3-19: A sample Timing diagram, showing the different states of a heartbeat over time. OMG 2.0
Figure 3-20: Partial State Machine diagram for a seat at a performance.
Figure 3-21: Protocol State Machine for a seat at the theater.
Figure 3-22: Three examples of the application of stereotypes.
Figure 3-23: Constraints on attributes and associations.
Figure 3-24: A comment attached to a class.
Chapter 4: Object-Oriented Concepts
Figure 4-1: Real objects versus abstractions.
Figure 4-2: Victor (on the left) and an abstraction of Victor (on the right, an object icon).
Figure 4-3: The interface for a car enables us to use the car by accessing its behaviors and its knowledge.
Figure 4-4: Defining the internal design of an object so that it will work properly.
Figure 4-5: Purpose drives the design and use of an object.
Figure 4-6: Separation of interface from implementation supports a difference between the internal storage of
data and the external use of data.
Figure 4-7: Modeling an association.
Figure 4-8: The relationship between association, aggregation, and composition.
Figure 4-9: How to represent an aggregation relationship in UML.
Figure 4-10: How to represent composition.
Figure 4-11: Modeling generalization.
Figure 4-12: Modeling generalization with discriminators.
Figure 4-13: Polymorphic behavior: calcAppliedDiscount() is implemented differently by each subclass of
Discount.
Figure 4-14: Unrelated classes realizing the same interface class.
Figure 4-15: Balancing cohesion and coupling.
Chapter 5: Capturing Rules about Objects in a Class Diagram
Figure 5-1: All other diagrams feed information to the Class diagram.
Figure 5-2: The relationships between the Class diagram, other diagrams, and the application code.
Figure 5-3: A simple Class diagram of the relationships between the resources Venue, Event, and Seat.
Figure 5-4: Three predefined class compartments.
Figure 5-5: Valid presentation options for classes.
Figure 5-6: Classes with names only.
Figure 5-7: Separating identity from attributes in a class description.
Figure 5-8: Fully qualified class names.
Figure 5-9: Four ways to model classes with stereotypes.
Figure 5-10: Utility classes have no instances and contain only static operations.
Figure 5-11: An enumeration class defines a set of literal values, usually used for validation.
Figure 5-12: Examples of properties using tagged values.
Figure 5-13: The ancestry of the definition for Class.
Figure 5-14: A class may contain nested classes, attributes, and operations.
OMG 2.0 (modified)
Figure 5-15: Adding ports to the class definition. OMG 2.0
Figure 5-16: Private elements of Class B are visible/accessible only to objects of Class B.
Figure 5-17: The package-visible elements of Class B are visible/accessible to all objects in Package 1.
Figure 5-18: The public elements of Class B are visible/accessible to objects in the same system regardless of
the package they reside in.
Figure 5-19: The protected elements of Class B are visible/accessible to subclasses of Class B regardless of
where they reside.
Figure 5-20: VisibilityKind and NamedElement classes.
OMG 2.0
Figure 5-21: Modeling a range for the number of values associated with an attribute.
Figure 5-22: Using the upper value when the lower and upper range values are the same.
Figure 5-23: Use an asterisk to signify "or more", meaning no upper limit.
Figure 5-24: Multiplicity ordering.
Figure 5-25: Multiplicity associated with any TypeElement.
OMG 2.0
Figure 5-26: Modeling ordering and uniqueness with multiplicity.
Figure 5-27: What an object knows about itself.
Figure 5-28: Add the reference attribute so that the event can collaborate with the venue.
Figure 5-29: Sample attribute-entry form in a modeling tool.
No Magic
Figure 5-30: Assigning private visibility (- ) to attributes to enforce encapsulation.
Figure 5-31: Identifying base and derived attributes.
Figure 5-32: Each attribute is assigned a data type.
Figure 5-33: Internal and external data types.
Figure 5-34: Attribute multiplicity.
Figure 5-35: A default value assigned to each attribute can help prevent errors and improve ease of use for
your clients.
Figure 5-36: Attribute properties enable you to define constraints and other facts to ensure the integrity of the
attribute value.
Figure 5-37: A static attribute is modeled by underlining the attribute definition.
Figure 5-38: A property inherits many of its features from other metaclasses.
OMG 2.0
Figure 5-39: A property describes a class, may be subsetted, and may have a default value.
OMG 2.0
Figure 5-40: Operations compartment with stereotypes.
Figure 5-41: Each operation identifies a behavioral feature of the class.
Figure 5-42: Operation parameters define the required input for the class behavior.
Figure 5-43: Operation return-results define the output of an operation.
Figure 5-44: A static operation is modeled by underlining the operation definition.
Figure 5-45: Tools support the definition of operation exceptions. No Magic
Figure 5-46: UML operation metamodel, part 1 of 2.
OMG 2.0
Figure 5-47: UML operation metamodel, part 2 of 2.
Figure 5-48: User-defined compartment with a name and tagged values (attributes and operations
compartments are suppressed).
Figure 5-49: User-defined compartment with properties sorted by stereotype.
Figure 5-50: Template notation with parameters.
Figure 5-51: Interface notation alternatives.
Figure 5-52: Structure::Classes::Interfaces interface definition - Part 1 of 2.
Figure 5-53: Structure::Classes:: Interfaces interface definition - Part 2 of 2.
Figure 5-54: Provided interface - the MarketingPlan provides an interface to price products.
Figure 5-55: Required interface - the shirt needs to be priced.
Figure 5-56: Interconnected provided and required interfaces.
Chapter 6: How to Capture Rules about Object Relationships
Figure 6-1: Association is a type of relationship. A link is an instance, or implementation, of an association.
Figure 6-2: An Association is made up of a connection and two AssociationEnds.
Figure 6-3: An association's name uses a verb or verb phrase.
Figure 6-4: Each association represents a separate set of rules.
Figure 6-5: Association ends define the participation of each type of object.
Figure 6-6: Role names assigned to association ends.
Figure 6-7: Assigning multiplicity to each association end.
Figure 6-8: The ordered constraint for an association end.
Figure 6-9: Adding constraint language to an association end.
Figure 6-10: Concatenating constraints.
Figure 6-11: Using a tool to enter association end constraints.
No Magic
Figure 6-12: Using constraints to restrict object participation.
Figure 6-13: Using a qualifier to get direct access to an object.
Figure 6-14: Specify navigation by placing an arrow at the end of the association.
Figure 6-15: Modeling the non-default changeability property {frozen}.
Figure 6-16: Exclusive or constraint on two associations {xor}.
Figure 6-17: Constraint notation involving more than two elements uses a comment (or note) with anchor lines
to the constrained elements.
Figure 6-18: A reflexive association models relationships between objects in the same class.
Figure 6-19: Finding information in a large or complex model.
Figure 6-20: The highlighted ellipse shows the derived association notation using a forward slash in front of the
association name.
Figure 6-21: The metamodel for associations.
OMG 2.0
Figure 6-22: Agent inherits from Vendor so Agent inherits the binds association with Contract.
Figure 6-23: Redefining the end of an association.
Figure 6-24: Modeling the redefined memberEnd property called contract.
Figure 6-25: Notation for the allowed navigability options in UML 2.0.
Figure 6-26: Association class captures information about an association.
Figure 6-27: An association class may participate in other associations.
Figure 6-28: Add the explicit associations to replace the associations implied by the association class.
Figure 6-29: Map the original multiplicities to the two new associations.
Figure 6-30: Update the new (exposed) association multiplicity as needed.
Figure 6-31: An n-ary association using the diamond symbol.
Figure 6-32: The unique characteristics of an aggregation association.
Figure 6-33: How to model an aggregation relationship.
Figure 6-34: How to model an aggregation relationship.
Figure 6-35: How to represent a composition relationship in UML.
Figure 6-36: A composite object.
Figure 6-37: Generalization structure with two levels of specialization.
Figure 6-38: Superclasses and subclasses in a generalization hierarchy.
Figure 6-39: Shared target style notation for generalizations.
Figure 6-40: Alternatives for modeling an abstract class.
Figure 6-41: Abstract and concrete classes.
Figure 6-42: Identifying subclasses using a powertype.
Figure 6-43: Applying a discriminator to define subclasses.
Figure 6-44: Modeling multiple discriminators.
Figure 6-45: Modeling generalization constraints.
Figure 6-46: Applying constraints to a generalization.
Figure 6-47: The Generalization metamodel.
OMG 2.0
Figure 6-48: Defining a generalization set as a collection of generalizations on the same classifier.
OMG 2.0
Figure 6-49: UML 2.0 notation for powertype associated with a generalization set with constraints.
Figure 6-50: Modeling dependency notation.
Figure 6-51: Modeling refines and realizes dependencies.
Figure 6-52: Merging dependency lines.
Figure 6-53: Adding the concept of substitution. $OMG 2.0.
Figure 6-54: Using the substitution dependency.
Chapter 7: Testing with Objects
Figure 7-1: Drawing classes and objects in a modeling tool.
No Magic
Figure 7-2: Two objects of type Customer, Kevin and Jackie, and one anonymous Venue object.
Figure 7-3: Modeling object attributes.
Figure 7-4: Modeling links.
Figure 7-5: The relationship between instances and slots.
OMG 2.0
Figure 7-6: Adding the ValueSpecification to store values for each slot.
No Magic
Figure 7-7: UML Class notation for an association between two classes.
Figure 7-8: UML object notation for one customer who has placed two orders.
Figure 7-9: Initial Class diagram for sales agreements and seats.
Figure 7-10: The Object diagram for test case 1 confirms the Class diagram.
Figure 7-11: The Object diagram with an unassigned seat.
Figure 7-12: The updated Class diagram.
Figure 7-13: Seats assigned by two different sales agreements.
Figure 7-14: Updated Class diagram with revised multiplicity and a new constraint.
Figure 7-15: Adding the new SeatGroup to facilitate seat assignments.
Figure 7-16: Revised Class diagram with seat groups.
Figure 7-17: Revised Class diagram with the Location generalization.
Figure 7-18: Composite Structure diagram of a pricing strategy.
Figure 7-19: A Composite Structure diagram representing a collaboration.
Figure 7-20: Class notation in a Composite Structure diagram.
Figure 7-21: Connectors and ports.
Figure 7-22: Modeling a collaboration icon.
Figure 7-23: Applying role names to classes.
Figure 7-24: A collaboration occurrence is bound to either operations or classes.
No Magic
Figure 7-25: Applying the collaboration structure to the theater system.
Figure 7-26: Modeling collaborations that realize an operation.
Chapter 8: Modeling Interactions in UML 1.4
Figure 8-1: An example of the automated support for finding operations, and for adding new operations based
on messaging requirements. $No Magic
Figure 8-2: Object lifelines for five objects..
Figure 8-3: Messages are placed on the object lifelines to model object interactions. Relative vertical position
indicates the order of execution from top to bottom.
Figure 8-4: Self-reference.
Figure 8-5: Asynchronous event..
Figure 8-6: A comment on a Sequence diagram.
Figure 8-7: Timed messages using constraint notation.
OMG 1.4
Figure 8-8: Modeling iteration on a message.
Figure 8-9: Modeling conditions to explain the flow of messages. Message 3 states that if the show seat that is
being selected in message 2 has not already been selected, then message 3 will return a reference to the
selected show seat object.
Figure 8-10: Modeling an alternative scenario using a condition to explain the variation.
Figure 8-11: Object activation and deactivation.
Figure 8-12: Recursive message calls.
Figure 8-13: Two UML standard visualizations for object creation.
Figure 8-14: Object creation with the created object at the top of the page.
Figure 8-15: Object termination.
Figure 8-16: Sequence diagram for a scenario where a valid selection is made and saved.
Figure 8-17: Collaboration diagram of cancel event scenario modeled in Figure 8-4.
Figure 8-18: Objects and links.
Figure 8-19: Messages on a Collaboration diagram.
Figure 8-20: An active object.
Figure 8-21: Multi-object..
Chapter 9: Modeling Interactions in UML 2.0
Figure 9-1: A customer selects a seat at a show (a ShowSeat).
Figure 9-2: UML diagram frame.
Figure 9-3: A frame for a Class diagram.
Figure 9-4: Nested frames.
Figure 9-5: Object placement within a Sequence diagram interaction.
Figure 9-6: A draft of the interaction for canceling an event.
Figure 9-7: Modeling a reference to an existing interaction between parts and their aggregate.
Figure 9-8: Stop notation for a Sequence diagram.
Figure 9-9: Modeling object activation.
Figure 9-10: Modeling object suspension.
Figure 9-11: Modeling a focus of control using the activation icon.
Figure 9-12: Alternative activation presentation.
Figure 9-13: Modeling a lifeline constraint using curly brace notation.
Figure 9-14: Modeling a lifeline constraint using a state icon.
Figure 9-15: Modeling a state invariant as a requirement after the execution of an interaction.
Figure 9-16: Declaring messages with parameters.
Figure 9-17: A message with sending and receiving EventOccurrences.
Figure 9-18: Modeling an ExecutionOccurrence (activation) and the bounding receiveEvent and sendEvent
(EventOccurrences).
Figure 9-19: A synchronous message and return.
Figure 9-20: An asynchronous message.
Figure 9-21: A message that creates an object.
Figure 9-22: A lost message.
Figure 9-23: A found message.
Figure 9-24: Defining duration constraints between EventOccurrences.
Figure 9-25: Defining time constraints.
Figure 9-26: Using two interaction occurrences to construct a larger interaction/Sequence diagram.
Figure 9-27: An interaction with three formal gates to receive and pass on three parameters from a message
from an external source.
Figure 9-28: Modeling a combined fragment within a Sequence diagram frame.
Figure 9-29: Parallel combined fragments.
Figure 9-30: Modeling a critical region.
Figure 9-31: Modeling the interaction operators ignore, consider, and assert.
Figure 9-32: Modeling a collaboration that utilizes a composite structure and an interaction occurrence (sd
Observe).
Figure 9-33: The model for the interaction referenced by the interaction occurrence called sd Observe.
Figure 9-34: Applying the Observer pattern collaboration to a show and its internal structure.
Figure 9-35: Modeling the application of an interaction occurrence to implement the observer pattern
collaboration in the SelectShowSeat interaction.
Figure 9-36: Start a Communication diagram by using an Object diagram format showing links between
objects.
Figure 9-37: Modeling a Communication diagram with sequence numbers to guide the execute order of the
messages.
Figure 9-38: Modeling an iteration expression.
Figure 9-39: Modeling parallel execution with an iteration expression.
Figure 9-40: Modeling a guard expression.
Figure 9-41: Interaction notation.
Figure 9-42: Interaction occurrence notation.
Figure 9-43: Fork and join notation to allow concurrency in an Interaction Overview diagram.
Figure 9-44: The use of a combined decision and merge point.
Figure 9-45: A complete Interaction Overview diagram.
Figure 9-46: Modeling object lifelines in a Timing diagram.
Figure 9-47: Modeling a state timeline.
Figure 9-48: Adding messages to a state timeline.
Figure 9-49: Adding a time constraint to a state timeline.
Figure 9-50: Adding a duration constraint to a state timeline.
Figure 9-51: Modeling interactions between multiple lifelines.
Figure 9-52: A general value timeline.
Chapter 10: Modeling an Object's Lifecycle in UML 1.4
Figure 10-1: State icon with the name compartment shown (minimum configuration).
Figure 10-2: Initial state notation.
Figure 10-3: Final state notation.
Figure 10-4: The State transition from Allocated to Enabled, caused by the event enable().
Figure 10-5: The same event causes different responses based on the state of the object when it receives the
event.
Figure 10-6: An elapsed-time event.
Figure 10-7: Modeling a change event.
Figure 10-8: Deriving new states from the event parameters.
Figure 10-9: Revised Statechart diagram that improves cohesion and coupling.
Figure 10-10: Modeling a guard condition.
Figure 10-11: Modeling an event/action pair.
Figure 10-12: The expanded state icon.
Figure 10-13: Redundant actions entering and exiting the Placed state of the Order.
Figure 10-14: Consolidating the entry actions.
Figure 10-15: Consolidating the exit actions.
Figure 10-16: The expanded state icon with activities.
Figure 10-17: Internal transition.
Figure 10-18: Modeling a self-transition.
Figure 10-19: Modeling an action invoked on another object.
Figure 10-20: The original problem definition found by following one requirement after another in linear
fashion.
Figure 10-21: Modeling a static branch point to re-factor compound conditions.
Figure 10-22: Combining the transitions into a single model.
Figure 10-23: Modeling transition contingent on the result of the event action.
Figure 10-24: Modeling a dynamic choice point.
Figure 10-25: A basic Sequence diagram with events and transitions.
Figure 10-26: Mapping a Sequence diagram to a Statechart diagram.
Figure 10-27: A standardized pair of scenarios for the first use case, Purchase ShowSeat.
Figure 10-28: Finding the transition events and candidate states for scenario 1 of the Purchase ShowSeat use
case.
Figure 10-29: Scenario 2 from the Purchase ShowSeat use case.
Figure 10-30: Consolidated Statechart diagram for the first two scenarios.
Figure 10-31: The final, consolidated Statechart diagram for the ShowSeat object.
Figure 10-32: Eliminating insignificant events.
Figure 10-33: An elided superstate icon (left) and the expanded superstate icon (right).
Figure 10-34: Mutually exclusive substates displayed in a graphic compartment within a superstate.
Figure 10-35: Composite state with concurrent regions.
Figure 10-36: State containing a submachine state with stub states designating the available entry and exit
points.
OMG 1.4
Figure 10-37: Transition to the default initial state.
Figure 10-38: Initial state refers to a specific substate.
Figure 10-39: Leaving a superstate.
Figure 10-40: Exiting a superstate from a specific substate.
Figure 10-41: Stub states provide entry points for a submachine state while hiding the complete design of the
submachine. $OMG 1.4
Figure 10-42: Modeling an exit stub state.
OMG 1.4
Figure 10-43: Historical pseudo state.
Figure 10-44: Split of control and merge of control using the synchronization bar.
Figure 10-45: Using sync states to coordinate behaviors across regions.
Figure 10-46: Multiple ways to exit a composite state with concurrent substates.
Chapter 11: Modeling an Object's Lifecycle in UML 2.0
Figure 11-1: The UML 2.0 State diagram metamodel, with the changes from UML 1.4 highlighted.
OMG 2.0
Figure 11-2: The change in the definition of state types from UML 1.4 to UML 2.0.
OMG 1.4 OMG 2.0 modified
Figure 11-3: Simple state notation.
Figure 11-4: Trigger metamodel.
OMG 2.0
Figure 11-5: Modeling transitions with the complete event signature.
Figure 11-6: State transition from Complete to ApprovingPayment.
Figure 11-7: Metamodel of a transition.
OMG 2.0
Figure 11-8: Initial and final states for a seat in the theater.
Figure 11-9: An automatic transition does not have an associated event description.
Figure 11-10: Adding action sequences to a transition.
Figure 11-11: Adding a decision into the action sequence of the transition.
Figure 11-12: Adding send and receive signals to the action sequence.
Figure 11-13: Modeling a composite state with one region and six direct substates.
Figure 11-14: Composite state with two regions divided by a dashed line.
Figure 11-15: Initiating concurrent states from single transition using a fork pseudo state.
Figure 11-16: Initiating transitions in two regions from within one of the regions.
Figure 11-17: Using the join pseudo state to manage multiple triggering transitions.
Figure 11-18: Triggering an external transition from within a composite state.
Figure 11-19: Alternatives for modeling the choice pseudo state, with a diamond and with a circle.
Figure 11-20: Basic junction notation.
Figure 11-21: State list alternative notation for a junction.
Figure 11-22: Modeling the terminate pseudo state.
Figure 11-23: Default entry to a composite state with one region.
Figure 11-24: Default entry to a composite state with two (multiple) regions.
Figure 11-25: Explicit entry into a composite state, both non-orthogonal and orthogonal.
Figure 11-26: Returning the shallow history of a composite state.
Figure 11-27: Deep history pseudo state icon.
Figure 11-28: Exiting a composite state.
OMG 2.0
Figure 11-29: Reused state machine.
Figure 11-30: Include statement and entry/exit points for a submachine state.
Figure 11-31: Metamodel for the protocol state machine.
OMG 2.0
Figure 11-32: Protocol state machine identification.
Figure 11-33: Protocol transition notation.
Figure 11-34: Metamodel for ProtocolConformance.
OMG 2.0
Figure 11-35: Conformance mirrors the relationship between classifiers and their state machines. (The
association between the protocol state machines and their corresponding classes is for illustration only. A
modeling tool would maintain this relationship but it would never appear on any diagram.)
Chapter 12: Modeling the Use of a System with the Use Case Diagram
Figure 12-1: Resources of the use case approach.
Figure 12-2: Use Case diagram metamodel.
Figure 12-3: Use case model illustrated using a system hierarchy of packages.
Figure 12-4: Use Case diagram elements.
Figure 12-5: UML suggested icons for actors.
Figure 12-6: Alternative actor icon examples.
Figure 12-7: Using generalization to refine the definitions of actors.
Figure 12-8: Using generalization to refine the definitions of customers.
Figure 12-9: Use case notation alternatives.
Figure 12-10: Package diagram for the theater example.
Figure 12-11: Metamodel update supporting classifier ownership of use cases. $OMG 2.0
Figure 12-12: Modeling associations between agents and use cases.
Figure 12-13: Modeling associations between customers and use cases.
Figure 12-14: include notation for the Use Case diagram.
Figure 12-15: Notation for the extend relationship.
Figure 12-16: Extension point notation using a comment.
Figure 12-17: Using class notation to model a use case with extension points.
Figure 12-18: Evaluating assumptions to establish workflow options.
Figure 12-19: Activity diagram for the SelectShow use case.
Figure 12-20: Trace the successful scenario from beginning to end.
Figure 12-21: In scenario 2, a performance is selected and the confirmation is declined.
Figure 12-22: Scenario 3.
Figure 12-23: Scenario 4.
Figure 12-24: Scenario 5.
Chapter 13: Modeling Behavior Using an Activity Diagram
Figure 13-1: Activities and transitions.
Figure 13-2: A guard condition on a transition.
Figure 13-3: Making a decision.
Figure 13-4: Making a decision in an activity.
Figure 13-5: The diamond as a merge point.
Figure 13-6: Begin and end notation for the activity diagram.
Figure 13-7: Initiating multiple threads or processes.
Figure 13-8: Merging control using the synchronization bar.
Figure 13-9: Modeling the preconditions.
Figure 13-10: Modeling a looping condition and merge point.
Figure 13-11: Modeling post conditions.
Figure 13-12: Modeling the Use case dialog, "For each piece find the Purchase Order."
Figure 13-13: Modeling the use case dialog, "matching the items to the P.O."
Figure 13-14: Modeling the concurrency opportunity.
Figure 13-15: The complete Activity diagram.
Figure 13-16: Two sets of packages that together provide all the available features of the Activity diagram.
OMG 2.0 modified
Figure 13-17: An activity containing four actions and three activity edges.
Figure 13-18: An activity with InitialNode and ActivityFinalNode added.
Figure 13-19: Adding a control flow name and connectors.
Figure 13-20: Adding a decision node to the Activity diagram.
Figure 13-21: Adding a merge node to the Activity diagram.
Figure 13-22: Simplifying the merge and decision node combination.
Figure 13-23: Activity diagram fork and join notation.
Figure 13-24: Combined fork and join notation.
Figure 13-25: Adding object flows and nodes to the Activity diagram.
Figure 13-26: Three icons for object nodes.
Figure 13-27: Notation for input and output pins on actions in an Activity diagram.
Figure 13-28: Central buffer node.
Figure 13-29: Two activity partitions for a single activity.
Figure 13-30: Alternative notation for activity partitions.
Figure 13-31: Modeling nested partitions.
OMG 2.0
Figure 13-32: Modeling participation by an external entity.
Figure 13-33: Alternative for modeling participation by an external entity.
Figure 13-34: Adding a second dimension to the activity partitions.
UML 2.0
Figure 13-35: FlowFinalNode.
Figure 13-36: Appling local pre- and post conditions to an action.
Figure 13-37: Pre- and post conditions on an activity.
Figure 13-38: Adding effects to an object flow.
Figure 13-39: Modeling multicast and multi-receive mechanisms across partitions.
Figure 13-40: Adding selection criteria to an object flow.
Figure 13-41: Specifying ordering on an object flow.
Figure 13-42: Specifying an upper limit on an object flow.
Figure 13-43: Specifying the valid states of an object.
Figure 13-44: Modeling a data store in an Activity diagram.
Figure 13-45: Adding exception parameter notation to an activity parameter node.
OMG 2.0 modified
Figure 13-46: Modeling the stream property on an activity parameter node.
OMG 2.0
Figure 13-47: Defining multiple parameter sets for an action or activity.
OMG 2.0
Figure 13-48: Modeling a join specification.
Figure 13-49: Modeling an interruptible activity region.
OMG 2.0
Figure 13-50: UML 2.0 metamodel for a structured activity as defined within the StructuredActivities package.
OMG 2.0
Figure 13-51: The notation for an activity (left-solid rounded rectangle) and a structured activity (right - a
dashed and rounded rectangle with structured at the top).
Figure 13-52: The metamodel for expansion regions and nodes.
Figure 13-53: Notation for an expansion region with input (top) and output (bottom) expansion nodes.
Figure 13-54: Notation for an expansion region with only one action.
Figure 13-55: Alternative notation for an expansion region with only one action, executed in parallel mode, and
for an unlimited number of executions.
Figure 13-56: Metamodel for conditional nodes.
Figure 13-57: Interim notation for a conditional node, an activity node with the stereotype conditional.
Figure 13-58: The StructuredActivities metamodel for a loop node.
OMG 2.0 modified
Figure 13-59: Loop node notation with nested setup, test, and body activity nodes.
Figure 13-60: The metamodel for a loop node as extended in the CompleteStructuredActivities package.
OMG 2.0 modified
Figure 13-61: Notation for a loop node with inputVariables and results.
Chapter 14: Modeling the Application Architecture
Figure 14-1: Folder structure in Windows.
Figure 14-2: Package notation.
Figure 14-3: Various notations for drawing a package and elements (classes in this example) within it. The
package on the far left has a hyperlink to another diagram (not shown).
Figure 14-4: Package structure shows the organization of the project.
Figure 14-5: The Overnight_Shipment class has an association to the Manager class of the
Human_Resources package because its Product Orders package has an Access dependency relationship to
the Human_Resources package.
Figure 14-6: Example shows packages before merge and after merge.
Figure 14-7: Package diagram is drawn using a Class diagram. It shows all subpackages of a package.
Figure 14-8: Alternative notations for subsystem grouping mechanism, which is a stereotype of a component in
UML 2.0.
Figure 14-9: Provided and required interfaces of subsystem components can be connected together in a ball-
and-socket-style manner.
Figure 14-10: Subsystem contains specification and realization compartments.
Figure 14-11: UML notation for a model is either the model stereotype for a package or the triangular icon
on a package.
Figure 14-12: Initial packaging of use cases during architectural analysis.
Figure 14-13: Regrouped packages. Analyze use cases.
Figure 14-14: Robustness analysis yields analysis classes.
Figure 14-15: Analysis packages for hotel.
Figure 14-16: Mapping subsystems against physical deployment nodes.
Figure 14-17: Hotel reservation subsystem with specification and realization compartments and
interfaces.
Figure 14-18: Overall model, package, and subsystem structure of the hotel example.
Chapter 15: Modeling Software Using the Component Diagram
Figure 15-1: UML 1.4 metamodel for components. OMG 1.4
Figure 15-2: UML 2.0 metamodels for components.
Figure 15-3: Component icon and name.
Figure 15-4: Component stereotype.
Figure 15-5: Interface notation using a class and stereotype.
Figure 15-6: Interface notation using the lollipop.
Figure 15-7: Depending on access to a component's interface.
Figure 15-8: Component dependencies and dependency stereotypes.
Figure 15-9: A component implements artifacts and is specified by classes.
Figure 15-10: A component containing classes.
Figure 15-11: The relationship between component interfaces and the interfaces of resident classes.
Figure 15-12: UML 2.0 redefines Component as a subclass of Class.
Figure 15-13: Changes to the component icon.
Figure 15-14: Component dependencies.
Figure 15-15: A component is an abstraction associated with any number of realizations. Each realization is
defined by a classifier.
Figure 15-16: Modeling realization using dependencies.
Figure 15-17: Interface notation for provided and required interfaces.
Figure 15-18: Connecting required and provided interfaces to form a partnership between components.
Figure 15-19: Alternative notation for interfaces.
Figure 15-20: Component white box view.
Figure 15-21: Component containing realizations.
Figure 15-22: Components and interfaces alone provide no means to map their internal and external
mechanisms.
Figure 15-23: Modeling ports as the intersection between external interfaces and internal realizations.
Figure 15-24: In a delegation connector, the external interface must match the realization interface.
Figure 15-25: An assembly connector example.
Figure 15-26: Shorthand notation for assembly connectors.
Figure 15-27: One port supporting multiple interfaces.
Chapter 16: Using Deployment Diagrams in UML 1.4
Figure 16-1: UML 1.4 node metamodel. OMG 1.4
Figure 16-2: Nodes described with features - attributes, operations, and associations.
Figure 16-3: Node names on a Deployment diagram.
Figure 16-4: Association stereotype between nodes.
Figure 16-5: Modeling components contained within/residing on nodes.
Figure 16-6: Using the deploy dependency stereotype to model containment.
Figure 16-7: Migrating software using the become stereotype.
Chapter 17: Representing an Architecture in UML 2.0
Figure 17-1: UML 2.0 metamodel defines a parallel structure for components and artifacts.
Figure 17-2: An example of the relationship between components and artifacts on a component diagram.
Figure 17-3: Node metamodel.
OMG 2.0
Figure 17-4: Node inheritance tree.
Figure 17-5: Nested nodes.
Figure 17-6: An execution environment node that contains a component and runs within a device node. (The
gray shading simply highlights the contained execution environment and component.)
Figure 17-7: Modeling nodes (left) versus node instances (right).
Figure 17-8: CommunicationPath is a subclass/specialization of association.
Figure 17-9: Network topology using nodes in a Deployment diagram.
Figure 17-10: Alternative node icons.
Figure 17-11: Generalizing nodes.
Figure 17-12: Artifact package metamodel.
Figure 17-13: Manifestations used to create an artifact.
OMG 2.0
Figure 17-14: The manifestation dependency between an artifact and a model element.
Figure 17-15: Alternative notation for artifacts.
Figure 17-16: Deployment metamodel.
OMG 2.0
Figure 17-17: Types of deployment targets and deployed artifacts.
Figure 17-18: Alternative notations for deploying an artifact on a node.
Figure 17-19: Deployment specification metamodel.
OMG 2.0
Figure 17-20: Deployment specification notation.
Figure 17-21: Modeling an artifact specification.
Chapter 18: Applying Constraints to the UML Diagrams
Figure 18-1: A portion of the abstract syntax/metamodel.
OMG 2.0
Figure 18-2: Sample Class diagram.
Figure 18-3: OCL Standard Library.
OMG 2.0
Figure 18-4: Navigating an association class.
Figure 18-5: Navigating to an association class on a reflexive association.
Figure 18-6: Sample partial state machine for Employee.
Figure 18-7: OCL Collection classes.
Chapter 19: Action Semantics
Figure 19-1: Data flow between pins with compatible types and multiplicities.
Figure 19-2: Control flow indicating action sequence.
Figure 19-3: Implementation of an operation described using a procedure specification.
Figure 19-4: A group action may receive a control flow. The control flow is implicitly passed to each subaction.
Figure 19-5: A group action is transparent to data flows. A data flow may be received by a subaction.
Figure 19-6: A slice containing elements from two collections.
Figure 19-7: Actions with pins showing types and descriptive labels.
Figure 19-8: ApplyFunctionAction, LiteralValueAction, and Nested Action examples.
Figure 19-9: Procedure outline showing argument and result pins.
Figure 19-10: Pins indicating an array inside an action.
Figure 19-11: A hatched pin indicates a reference to a pin owned by a nested action.
Chapter 20: Using a Modeling Tool
Figure 20-1: Modeling tool user interface with browser providing navigation.
Figure 20-2: Displaying an item according to its stereotype, using user-supplied graphic metafiles.
Chapter 21: Customizing UML Using Profiles
Figure 21-1: Example of special icon to represent a class with stereotype boundary. You may either show a
class in its rectangular form or its iconized form.
Figure 21-2: The Profiles package is dependent on the Core package of the UML infrastructure.
Figure 21-3: Contents of the Profiles package, providing the class structure of the mechanisms used to extend
metamodels with profiles.
Figure 21-4: Example of the EJB profile and the Java profile being applied to the On-line Reservations
package.
Figure 21-5: Specifying that a metaclass is extended with a stereotype during metamodeling.
Figure 21-6: Example EJB profile provided in UML 2.0 specification.
Figure 21-7: With the EJB profile applied to the package in which you are modeling, new choices for
stereotypes become available for a component.
Figure 21-8: Example of special icons for Boundary Class, Entity Class, and Control Class specified by the
UML Profile for Business Modeling.
Figure 21-9: Example of special icons for Boundary Class, Entity Class, and Control Class applied to instances
of classes on a Sequence diagram.
Figure 21-10: One example of stereotypes called out by the UML Profile for EAI - a Class diagram for a
primitive operator, with input and output terminals, and message content passed through the terminal.
Figure 21-11: Example of on-line brokerage provided by EAI Profile.
Figure 21-12: Example of a Class diagram for a compound operator with compound components.
Figure 21-13: The notation for a ProcessComponent.
Figure 21-14: Composite Component notation containing internal Usage ProcessComponents.
Figure 21-15: Notation of a Business Activity as specified by the Business Process Subprofile of the EDOC.
Figure 21-16: Example of a CompoundTask that contains internal Activities.
Figure 21-17: Structure of the Schedulability, Performance, and Time Profile.
Figure 21-18: Basic structure of the UML Testing Profile. Each package contains the metamodel of a profile
for a specific area of testing.
Figure 21-19: Class symbol stereotyped as a Test Suite with four test cases.
Chapter 22: XML Metadata Interchange
Figure 22-1: Simple use case of a customer ordering a product.
Figure 22-2: Package hierarchy presented for XMI of overall Order System Use Case model.
Figure 22-3: XMI instance document, with taggedValue property expanded for Order Product Use Case.
Figure 22-4: XMI 1.1 instance document, with TaggedValue property expanded for Order Product use case.
Figure 22-5: Overview of creation of Diagram Interchange DTD.
Appendix A: UML 1.4 Notation Guide
Figure A-1: Class icon with the default name, attribute, and operation compartments, and a user-defined
compartment.
Figure A-2: Four presentation alternatives for classes with stereotypes.
Figure A-3: Template class.
Figure A-4: Interface class notation.
Figure A-5: Binary association notation.
Figure A-6: Reflexive association and roles notation.
Figure A-7: Constraints between associations.
Figure A-8: Association navigability.
Figure A-9: Ordering, derived association, and qualified association.
Figure A-10: Association class notation.
Figure A-11: N-ary association.
Figure A-12: Aggregation and composition notation.
Figure A-13: Alternative composition notation.
Figure A-14: Generalization notation: complete constraint, Power Type, ellipse, abstract class.
Figure A-15: Generalization notation: discriminator, disjoint and overlapping, constraints, and multiple
inheritance.
Figure A-16: Dependency notation between two packages (left) and two classes (right).
Figure A-17: Class dependency notation.
Figure A-18: Object notation.
Figure A-19: Using collaboration notation to define a design pattern.
Figure A-20: Implementing a design pattern (collaboration).
Figure A-21: Sequence diagram notation.
Figure A-22: Message types.
Figure A-23: Recursive message.
Figure A-24: Object creation and termination.
Figure A-25: Time constraints.
Figure A-26: Activation (also called focus of control).
Figure A-27: Collaboration diagram notation.
Figure A-28: Statechart notation (1).
Figure A-29: When and after clauses.
Figure A-30: Self-transition, and entry and exit actions.
Figure A-31: Static branch state.
Figure A-32: Dynamic choice point.
Figure A-33: Composite state.
Figure A-34: Deep and shallow history.
Figure A-35: Concurrent substates.
Figure A-36: Split and merge of control.
Figure A-37: Submachine state and stub states.
Figure A-38: Synch states.
Figure A-39: Send and receive signals.
Figure A-40: Use Case diagram notation.
Figure A-41: Start, end, decision (split), and merge.
Figure A-42: Fork and join notation.
Figure A-43: Activity, transition, and transition guard.
Figure A-44: An Activity diagram divided into three swimlanes and passing the Order object from one activity to
the next.
Figure A-45: Component diagram notation.
Figure A-46: Alternative notation for resident and implementing classes.
Figure A-47: Nodes defined as classifiers, with attributes and operations, at type and instance levels.
Figure A-48: Component diagram at type and instance levels.
Figure A-49: Deployment of a component on a node instance.
Figure A-50: Deployment of components on a node instance using containment.
Figure A-51: Packages as namespaces.
Figure A-52: Package containment notation alternatives.
Figure A-53: Access dependency.
Figure A-54: Merge dependency.
Figure A-55: Subsystem notation alternatives.
Figure A-56: Subsystem interface notation.
Figure A-57: Subsystem realization.
Figure A-58: Model notation.
Appendix B: UML 2.0 Notation Guide
Figure B-1: Class icon.
Figure B-2: Four presentation alternatives for classes with stereotypes.
Figure B-3: Interface class notation.
Figure B-4: Template class.
Figure B-5: Binary association notation.
Figure B-6: Reflexive association and roles notation.
Figure B-7: Constraints between associations.
Figure B-8: Navigability.
Figure B-9: Ordering, derived association, and qualified association.
Figure B-10: Association class notation.
Figure B-11: N-ary association.
Figure B-12: Aggregation and composition notation.
Figure B-13: Alternative composition notation.
Figure B-14: Generalization notation: complete constraint, Power Type, ellipse, and abstract class.
Figure B-15: Generalization notation: discriminator, disjoint and overlapping constraints, and multiple
inheritance.
Figure B-16: Dependency notation between two packages (left) and two classes (right).
Figure B-17: Class dependency notation.
Figure B-18: Object notation.
Figure B-19: Using collaboration notation to define a design pattern.
Figure B-20: Implementing a design pattern (collaboration).
Figure B-21: Sequence diagram basic notation.
Figure B-22: Message types.
Figure B-23: State invariant.
Figure B-24: Object creation and termination.
Figure B-25: Duration constraints.
Figure B-26: Time constraints.
Figure B-27: Interaction occurrence.
Figure B-28: Interaction occurrence.
Figure B-29: Interaction occurrence.
Figure B-30: Interaction operators consider, ignore, and assert.
Figure B-31: Communication diagram notation.
Figure B-32: Interaction Overview notation.
Figure B-33: Interaction Overview lifeline notation.
Figure B-34: Timing diagram notation.
Figure B-35: Timing diagram alternative notation.
Figure B-36: Statechart notation (1).
Figure B-37: When and after clauses.
Figure B-38: Self-transition, and entry and exit actions.
Figure B-39: Static branch state.
Figure B-40: Dynamic choice point.
Figure B-41: Composite state.
Figure B-42: Deep and shallow history.
Figure B-43: Concurrent substates.
Figure B-44: Split and merge of control.
Figure B-45: Submachine state and stub states.
Figure B-46: Synch states (Sync state still appears in the UML 2.0 glossary but is not part of the UML 2.0
specification.)
Figure B-47: Action specification with send and receive signals.
Figure B-48: Activity and completion transition.
Figure B-49: Two ways to model common transitions.
Figure B-50: Protocol state machine and generalization.
Figure B-51: Use Case diagram notation.
Figure B-52: Start, end, decision (split), and merge.
Figure B-53: Fork and join notation.
Figure B-54: Activity, transition, and transition guard.
Figure B-55: Component diagram notation.
Figure B-56: Alternative notation for realizing classes.
Figure B-57: Nodes defined as classifiers, with attributes and operations, at type and instance levels.
Figure B-58: Component diagram at type and instance levels.
Figure B-59: Artifacts that implement components.
Figure B-60: Deployment of a component on a node instance.
Figure B-61: Deployment specification.
Figure B-62: Deployed components.
Figure B-63: Packages as namespaces.
Figure B-64: Package containment notation alternatives.
Figure B-65: Access dependency.
Figure B-66: Merge dependency.
Figure B-67: Subsystem notation alternatives.
Figure B-68: Subsystem interface notation.
Figure B-69: Subsystem realization.
Figure B-70: Model notation.
Glossary
Figure GL-1: Notation options for abstract classes.
Figure GL-2: Action sequence notation.
Figure GL-3: Activation in a Sequence diagram (UML 1.4).
Figure GL-4: An active object modeled using a bold outline.
Figure GL-5: Activity partitions.
Figure GL-6: An actor icon in a Use Case diagram.
Figure GL-7: Aggregation symbol is a hollow diamond.
Figure GL-8: Two associations between the same pair of classes.
Figure GL-9: Here Contract is an association class.
Figure GL-10: Attribute compartment.
Figure GL-11: Parent and child classes in an inheritance hierarchy/tree.
Figure GL-12: Class icon examples include fully expanded (top), suppressed attributes and operations (bottom
left), and stereotype icon (bottom right).
Figure GL-13: Template class.
Figure GL-14: Class/static attribute notation (underline the attribute declaration).
Figure GL-15: Collaboration diagram example.
Figure GL-16: A collaboration occurrence to explain an operation.
Figure GL-17: Comment icon attached to the attribute that it references.
Figure GL-18: Class compartments' notations.
Figure GL-19: Component icons for UML 1.4 and 2.0. UML 1.4 defines a single generic type of interface. UML
2.0 differentiates between provided and required interfaces.
Figure GL-20: Component diagram examples from UML 1.4 and UML 2.0.
Figure GL-21: Composite states.
Figure GL-22: Composite Structure diagram example.
Figure GL-23: Composition notation (solid diamond).
Figure GL-24: Abstract and concrete classes in an inheritance hierarchy/tree.
Figure GL-25: Concurrency in an Activity diagram.
Figure GL-26: Concurrent substates.
Figure GL-27: Conditional node.
Figure GL-28: Constraint on an association end (using freeform text).
Figure GL-29: Physical containment and a containment hierarchy are two ways to model containment.
Figure GL-30: Dependency notation.
Figure GL-31: Deployment diagram example.
Figure GL-32: A derived association.
Figure GL-33: Disjoint substates.
Figure GL-34: Entry actions in a state icon.
Figure GL-35: Event on a state transition.
Figure GL-36: Expansion region.
Figure GL-37: The extend relationship between use cases.
Figure GL-38: Extension notation for dynamically adding stereotypes to a metaclass.
Figure GL-39: Final state notation.
Figure GL-40: Focus class in a component in a Deployment diagram.
Figure GL-41: Focus of control in a Sequence diagram.
Figure GL-42: Generalization hierarchy/tree.
Figure GL-43: A guard condition ([amount=totalPrice]) on the transition event receivePayment.
Figure GL-44: Import dependency between packages.
Figure GL-45: Include relationship between use cases.
Figure GL-46: Initial state icon pointing to an initial state.
Figure GL-47: Interaction overview diagram.
Figure GL-48: Interface notation alternatives.
Figure GL-49: Objects and links.
Figure GL-50: List compartment example.
Figure GL-51: Loop node.
Figure GL-52: Multiple inheritance example.
Figure GL-53: Multiplicity on an association (ends).
Figure GL-54: Name compartment notation for a class.
Figure GL-55: N-ary association.
Figure GL-56: Node notation for Deployment diagram.
Figure GL-57: Object notation.
Figure GL-58: Object diagram.
Figure GL-59: Object flow notation alternatives.
Figure GL-60: Object lifelines.
Figure GL-61: Package diagram example.
Figure GL-62: Package merge.
Figure GL-63: Part notation within a Composite Structure diagram.
Figure GL-64: Input and output pins on a component.
Figure GL-65: Ports on the parts of a Composite Structure diagram.
Figure GL-66: Powertypes (Solo, Group, and so forth) used to specify two overlapping generalizations.
Figure GL-67: Provided interfaces are shown on left of the figure, to easily distinguish them from the required'
interface symbol on the right of the figure.
Figure GL-68: Qualified association.
Figure GL-69: Realization dependency.
Figure GL-70: Refinement dependency.
Figure GL-71: Role names on associations.
Figure GL-72: Sequence diagram example.
Figure GL-73: Two forms of the state icon are elided (left) and expanded (right).
Figure GL-74: Alternative forms of stereotyped class notation.
Figure GL-75: Structured activity.
Figure GL-76: Superclass-subclass relationship in an inheritance hierarchy/tree.
Figure GL-77: A submachine state within a composite state.
Figure GL-78: Subpackages within a package.
Figure GL-79: Non-orthogonal (single/same region) and orthogonal (concurrent) are two types of substates.
Figure GL-80: UML 1.4 Subsystem stereotypes on packages. In UML 2.0 the package symbol is replaced by a
simple rectangle with the subsystem stereotype.
Figure GL-81: Synch state.
Figure GL-82: Transition with event, guard, and action.
Figure GL-83: Use Case diagram example.
<Day Day Up>
<Day Day Up>
List of Tables
Chapter 2: UML Architecture
Table 2-1: The Four-Layer Architecture (OMG 1.4)
Table 2-2: Comparison of UML 1.4 and 2.0 Diagrams
Chapter 5: Capturing Rules about Objects in a Class Diagram
Table 5-1: Comparison of entity and control Stereotypes
Table 5-2: Visibility Symbols
Table 5-3: The Use of Properties for Collection Types
Table 5-4: Pre- and Post Conditions in a Simple Request/Response
Table 5-5: Pre- and Post Conditions in a Complex Request/Response
Chapter 6: How to Capture Rules about Object Relationships
Table 6-1: Summary of Notations for memberEnd Features
Table 6-2: AggregationKind in UML 1.4 and 2.0
Table 6-3: Using isCovering and isDisjoint Together
Table 6-4: Predefined Dependency Types
Chapter 7: Testing with Objects
Table 7-1: Comparison of the Class and Object Diagrams
Table 7-2: Examples of ClassifierRole Name Variations
Chapter 8: Modeling Interactions in UML 1.4
Table 8-1: Comparison of Behavioral Diagrams Between UML 1.4 and UML 2.0
Table 8-2: Updated Class Operations
Chapter 9: Modeling Interactions in UML 2.0
Table 9-1: Features of the UML 2.0 Sequence Diagram
Chapter 12: Modeling the Use of a System with the Use Case Diagram
Table 12-1: Include versus Extend
Table 12-2: Use Case Narrative for SelectPerformance
Chapter 13: Modeling Behavior Using an Activity Diagram
Table 13-1: Activity Diagram Notation in UML 1.4 and 2.0
Table 13-2: A Use Case Narrative for Receive Product
Chapter 17: Representing an Architecture in UML 2.0
Table 17-1: Deployment Diagram in UML 1.4 and UML 2.0
Chapter 18: Applying Constraints to the UML Diagrams
Table 18-1: OCL Infix Operators
Table 18-2: Iterator Expressions
Chapter 21: Customizing UML Using Profiles
Table 21-1: UML Profile for Software Development Processes
Table 21-2: UML Profile for Business Modeling
Table 21-3: UML Profile for Web Application Extensions
Chapter 22: XML Metadata Interchange
Table 22-1: Content Model Operators
Table 22-2: Various Element Content Declarations
Appendix C: Standard Elements
Table C-1: Standard Elements
Table C-2: Retired Standard Elements
<Day Day Up>
<Day Day Up>
List of Listings
Chapter 22: XML Metadata Interchange
Listing 22-1: XMI 1.0 Code for Order Product Use Case
Listing 22-2: UML.DTD of XMI 1.0 for Use Case Definition
Listing 22-3: XMI 1.1 DTD Section for Use Cases
Listing 22-4: Tagged Values Specified in XMI 1.1 DTD
<Day Day Up>
<Day Day Up>
List of Sidebars
Chapter 1: What Is UML?
MDA Success Stories
Chapter 2: UML Architecture
Links to the UML 2.0 RFPs
Chapter 4: Object-Oriented Concepts
Recommended Reading on Design Principles
Chapter 6: How to Capture Rules about Object Relationships
Avoiding Dangerous Notation Defaults
Chapter 10: Modeling an Object's Lifecycle in UML 1.4
State attributes
Chapter 12: Modeling the Use of a System with the Use Case Diagram
Why Is It This Way?
Workflow Requirements
Avoiding Analysis Paralysis
Chapter 15: Modeling Software Using the Component Diagram
Modeling Business Processes
Chapter 18: Applying Constraints to the UML Diagrams
Backward Compatibility
Chapter 19: Action Semantics
Why Software-Platform-Independent Action Specifications?
Chapter 22: XML Metadata Interchange
The Unisys Extensions
<Day Day Up>