Table of Contents

< Day Day Up >
Next Section

UML Bible
UML Bible
by Tom 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.

Has Companion Web Site 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 >
Next Section


BackCover

Previous Section
< Day Day Up >
Next Section

Back Cover

Today’s 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. It’s 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.

Previous Section


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.


Who Should Read This Book

Previous Section
< Day Day Up >
Next Section

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 …).


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 … .


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.


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.


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.
Note

Notes provide extra information about a topic, perhaps some technical tidbit or background explanation.
Tip

Expert Tips offer ideas for the advanced user who wants to get the most out of UML.
Caution

Cautions 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.

Click To expand
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.

Click To expand
Figure FM-2: Using gray shaded rounded rectangles to highlight elements of an illustration.


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


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.

Note

When 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


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:

  1. Enable the modeling of systems (not just software) using object-oriented concepts

  2. Establish an explicit coupling to conceptual as well as executable artifacts

  3. Address the issues of scale inherent in complex, mission-critical systems

  4. Create a modeling language usable by both humans and machines (UML 1.4, pgs. 1-12,13)

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.


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.)


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.


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.

Click To expand
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.

Note

In 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.
Start Sidebar
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)

End Sidebar

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.

Click To expand
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.


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.


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.

Click To expand
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.

Click To expand
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.

Note

This 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.


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).

Click To expand
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.

Click To expand
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.

Click To expand
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.

Note

State 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.

Click To expand
Figure 2-6: UML 1.4 Action example.
©OMG 1.4

Here's an explanation of the roles of each element:

  1. The CreateObjectAction object generates an instance, labeled customer, of the Class metaclass.

  2. This new customer object is attached to an OutputPin object that holds the result of the action.

  3. A Dataflow object connects the OutputPin object to an InputPin object so that the "customer" object can be passed through it to another action.

  4. InputPin provides the customer object as an input value to the next action called WriteVariableAction.

  5. WriteVariableAction assigns the customer object to the variable called newCustomer.

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.

Click To expand
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.


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.

Start Sidebar
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

End Sidebar

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.

Click To expand
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).

Click To expand
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.

Click To expand
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.

Click To expand
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.)
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.)


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.


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.


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.

Click To expand
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.


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.

Click To expand
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.


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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
Figure 3-9: UML 1.4 Component diagram using components and dependencies.
Click To expand
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.

Click To expand
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.

Click To expand
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.


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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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."

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.


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.

Click To expand
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.

Click To expand
Figure 3-23: Constraints on attributes and associations.
Note

Curly 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."


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.

Click To expand
Figure 3-24: A comment attached to a class.


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.


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.


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.


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.


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).

Click To expand
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.

Click To expand
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.


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.


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.

Click To expand
Figure 4-3: The interface for a car enables us to use the car by accessing its behaviors and its knowledge.
Caution

The 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.

Click To expand
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.

Click To expand
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.

Click To expand
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.


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.

Click To expand
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.

Click To expand
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:

  1. 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).

  2. 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.

    Click To expand
    Figure 4-9: How to represent an aggregation relationship in UML.

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.

Click To expand
Figure 4-10: How to represent composition.
Tip

In 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.
Caution

The 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.


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.

Click To expand
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.

Click To expand
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


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.

Click To expand
Figure 4-13: Polymorphic behavior: calcAppliedDiscount() is implemented differently by each subclass of Discount.
Caution

Regarding 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.

Note

Actually, 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).

Note

Programming 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.

Click To expand
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.


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.

Click To expand
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.

Start Sidebar
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.

End Sidebar


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.


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


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.


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.

Note

When 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.

Click To expand
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.

Click To expand
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.

Click To expand
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.


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.

Click To expand
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.


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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Note

These 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.

Click To expand
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.

Tip

If 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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.


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.

Click To expand
Figure 5-16: Private elements of Class B are visible/accessible only to objects of Class B.
Tip

If 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.

Click To expand
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.

Click To expand
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.

Click To expand
Figure 5-19: The protected elements of Class B are visible/accessible to subclasses of Class B regardless of where they reside.
Note

Check 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.
Note

In 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.

Click To expand
Figure 5-20: VisibilityKind and NamedElement classes.
©OMG 2.0


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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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


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).

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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:

  1. To protect the integrity of the system from being corrupted by missing or invalid values.

  2. To provide significant ease-of-use improvements for the client.

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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.)

    Click To expand
    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}


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.

Click To expand
Figure 5-40: Operations compartment with stereotypes.
Note

In 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.

Click To expand
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.

Click To expand
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).

Caution

If 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.

Click To expand
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.

Caution

It 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.

Click To expand
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++.

Click To expand
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.

Tip

This 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.

Tip

The 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.

Click To expand
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.

    Caution

    UML 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.

Click To expand
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.


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.)

Click To expand
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.

Click To expand
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.


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.

Tip

Templates 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.

Click To expand
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.

Click To expand
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.

Tip

The 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.

Click To expand
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.

Click To expand
Figure 5-53: Structure::Classes:: Interfaces interface definition - Part 2 of 2.
Caution

Check 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.

Click To expand
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.

Click To expand
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.

Click To expand
Figure 5-56: Interconnected provided and required interfaces.


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


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.

Caution

There 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.


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.


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.

Note

There 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.

Click To expand
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.

Click To expand
Figure 6-2: An Association is made up of a connection and two AssociationEnds.
Note

AssociationEnd 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.

Click To expand
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.

Note

Association 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.

Tip

In 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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Note

Visibility 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).

Click To expand
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.

Note

This 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.

Click To expand
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.

Start Sidebar
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.

End Sidebar

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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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:

  1. 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.

  2. 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.

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.

Caution

A 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.

Click To expand
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.

Caution

Do 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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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:

Click To expand
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.

Click To expand
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:

Click To expand
Figure 6-23: Redefining the end of an association.

  1. 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.

  2. 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}.

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.

Click To expand
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.

Click To expand
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.


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.

Click To expand
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.

Click To expand
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.

Click To expand
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".

Click To expand
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.

Click To expand
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.


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.

Click To expand
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.


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:

Click To expand
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:

  1. 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.

    Click To expand
    Figure 6-33: How to model an aggregation relationship.

  2. 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.

  3. 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.

Figure 6-33 reads as follows:

  1. 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.

  2. The agency is always comprised of at least one agent but there may be any number of agents (1..*).

  3. An agent is considered an employee (role name) of an agency.

  4. Every agent is constrained by the fact that she must have a current contract in order to be an employee of the agency.


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.

Click To expand
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.

Click To expand
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.

Tip

As 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.

Click To expand
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)
Caution

There 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.


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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
Figure 6-41: Abstract and concrete classes.
Caution

Figure 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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Note

Whether 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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.


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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
Figure 6-54: Using the «substitution» dependency.


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».


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.

Click To expand
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).


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
Note

Throughout 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.

Note

The 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.

Click To expand
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.

Click To expand
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.

Click To expand
Figure 7-4: Modeling links.


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.

Click To expand
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.

Click To expand
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.


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.

Click To expand
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.

Click To expand
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.


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.

Click To expand
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.

Click To expand
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.

Click To expand
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).

Click To expand
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).

Click To expand
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:

  1. A seat may be assigned by any number of sales agreements, not just one.

  2. The time periods for the sales agreements that assign the same seat may not overlap one another.

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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Note

By 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.


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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.
/ 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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.


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.


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


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.


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.

Tip

The 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.

Note

You 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:

  1. 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.

  2. 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.

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.

Click To expand
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.

Tip

The 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.

Click To expand
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.

Click To expand
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.
Caution

The 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:

  1. 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.

  2. The control object, SelectShowSeat, asks the performance object for a reference to the show seat that matches the provided identifier.

  3. The performance returns a reference to a show seat object based on the showSeatID passed to it.

  4. The control object tells the order object to add the selected show seat to its list of ordered show seats.

  5. The order returns a Boolean value of True saying that everything worked properly.

  6. 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.

  7. 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.)

Note

Building 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.

Tip

Reusing 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.
Note

Creating 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).

Tip

The 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.

Tip

When 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.

Click To expand
Figure 8-4: Self-reference.
Note

In 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.

Click To expand
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.

Click To expand
Figure 8-6: A comment on a Sequence diagram.
Tip

UML 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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Caution

There 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.

Click To expand
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.

Click To expand
Figure 8-13: Two UML standard visualizations for object creation.
Click To expand
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.

Click To expand
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.

Click To expand
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.

Note

This 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.


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.

Click To expand
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:

  1. Place the participating objects on the diagram.

  2. Draw the links between the objects using the Class diagram as your guide.

  3. 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.

  4. Number the message in its order of execution.

  5. Repeat steps 3 and 4 until the entire scenario has been modeled.

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.

Click To expand
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.

Click To expand
Figure 8-19: Messages on a Collaboration diagram.
Click To expand
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.

Click To expand
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.


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.


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:

  1. Messages map to operations.

  2. Conditions are placed in the implementation logic of the calling object.

  3. Iteration logic is placed in the implementation logic for the calling object.

  4. Parameters and return value identify attributes that need to be defined in a class.

  5. For each new attribute discovered, the owning class must provide accessor operations to maintain the value and to read the value.


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.


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.

Note

The 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.)

Click To expand
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.


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.

Click To expand
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.

Click To expand
Figure 9-3: A frame for a Class diagram.
Note

The 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.

Click To expand
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.

Note

UML 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.

Click To expand
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.

  1. The aggregate grants access to a part object so that another object may manipulate it directly.

  2. The interaction specifically models the propagation of messages from the aggregate to its parts.

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.

Click To expand
Figure 9-6: A draft of the interaction for canceling an event.
Note

I 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.

Click To expand
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.

Note

Using 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.

Click To expand
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.

Click To expand
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).

Tip

Technically 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.

Click To expand
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.

Click To expand
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.

Click To expand
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:

  1. 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.

    Click To expand
    Figure 9-13: Modeling a lifeline constraint using curly brace notation.

  2. 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.

    Click To expand
    Figure 9-14: Modeling a lifeline constraint using a state icon.

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.

Click To expand
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.

Note

UML 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.

Click To expand
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.

Note

All 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.

Click To expand
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.

Click To expand
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.

Click To expand
Figure 9-19: A synchronous message and return.
Caution

Note 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.

Click To expand
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.

Click To expand
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.

Note

The 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.

    Click To expand
    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.

    Click To expand
    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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Note

The 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.

Click To expand
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.

Click To expand
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.

Click To expand
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):

  1. The ordering of event occurrences within each of the operands is maintained in the result.

  2. Event occurrences on different lifelines from different operands may come in any order.

  3. 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.

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.

Click To expand
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.

Click To expand
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.


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.

Tip

A 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.

Click To expand
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).

Click To expand
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.

Click To expand
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).

Click To expand
Figure 9-35: Modeling the application of an interaction occurrence to implement the observer pattern collaboration in the SelectShowSeat interaction.


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.)

Click To expand
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.

Click To expand
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 ].

Click To expand
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.

Click To expand
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.

Click To expand
Figure 9-40: Modeling a guard expression.


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.

Click To expand
Figure 9-41: Interaction notation.

Figure 9-42 models the notation for interaction occurrences.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
Figure 9-45: A complete Interaction Overview diagram.


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.

Click To expand
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.

Click To expand
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.)

Click To expand
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.)

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.


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.


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.


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.

Tip

The 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.

Start Sidebar
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.

End Sidebar

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.

Click To expand
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).

Click To expand
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.

Tip

The 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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
Figure 10-9: Revised Statechart diagram that improves cohesion and coupling.
Note

The 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).

Click To expand
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:

Click To expand
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.

Click To expand
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().

Click To expand
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."

Click To expand
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.

Click To expand
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.

Click To expand
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:

  1. If an activity is in progress in the current state, interrupt it (gracefully if possible).

  2. Execute the exit/action(s).

  3. Execute the actions associated with the event that triggered the transition.

  4. Execute the entry/action(s) of the new state.

  5. Begin executing the activity or activities of the new state.

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.

Referring to the earlier section titled "Order of events", you can trace the impact of a self-transition.

  1. If an activity is in progress in the current state, interrupt it (gracefully if possible).

  2. Execute the exit/action(s).

  3. Execute the actions associated with the event that triggered the transition. In this case, we have to perform the removeItems() operation on the order.

  4. Execute the entry/action(s) of the new state.

  5. Begin executing the activity or activities of the new state.

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().

Click To expand
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.

Click To expand
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].

Click To expand
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.

Click To expand
Figure 10-22: Combining the transitions into a single model.
Note

The 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.

Click To expand
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.

Click To expand
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.


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.

Click To expand
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.

Click To expand
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:

  1. Identify the events directed at the lifeline of the ShowSeat object.

  2. Identify candidate states by isolating the segments of the lifeline between the incoming events.

  3. Name the candidate states using adjectives that describe the condition of the object during the period of time represented by the segment.

  4. Add the new states and events to the ShowSeat Statechart diagram.

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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
Figure 10-32: Eliminating insignificant events.


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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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".

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Tip

For 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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

  2. 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.

  3. A specific event, such as T2, could take the object out of a specific substate and out of the composite state entirely.


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:

    1. If an activity is in progress in the current state, interrupt it.

    2. Execute the exit: action(s).

    3. Execute the actions associated with the event that started it all.

    4. Execute the entry: action(s) of the new state.

    5. Execute the activity or activities.

  • 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:

    1. Identify the events directed at the lifeline of the object you're modeling.

    2. Identify candidate states by isolating the portions of the lifeline between the incoming events.

    3. Name the candidate states using adjectives that describe the condition of the object during the period of time represented by the gap.

    4. Add the new states and events to the Statechart diagram.

  • 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.


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.

Caution

The 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.

Click To expand
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.


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.


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.

Click To expand
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.

Click To expand
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.

Click To expand
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:

Click To expand
Figure 11-5: Modeling transitions with the complete event signature.

  1. The pmtReceived() event may come through either the creditCardPmt port or the cashPmt port.

  2. As long as the amount received as payment is greater than or equal to the total value of the order.

  3. then the approvePayment activity will be invoked

  4. and the order will transition from the Complete state to the ApprovingPayment state.

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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
Figure 11-11: Adding a decision into the action sequence of the transition.
Note

When 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.

Click To expand
Figure 11-12: Adding send and receive signals to the action sequence.


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.

Click To expand
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.

Tip

A 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.

Click To expand
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.

Click To expand
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.

Click To expand
Figure 11-16: Initiating transitions in two regions from within one of the regions.
Note

The 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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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).

Click To expand
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.

Click To expand
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:

Click To expand
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.


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.

Click To expand
Figure 11-29: Reused state machine.
Click To expand
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.

Note

It 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.


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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.)


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.


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


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.

Note

The 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).

Click To expand
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.

Tip

Because 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.
Start Sidebar
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.

End Sidebar

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:

  1. To make buying tickets as easy as possible for end-customers.

  2. To reduce the cost of selling tickets.

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.

Click To expand
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.


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.

Caution

Technically 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.


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.

Click To expand
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)

Caution

The 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.


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.

Click To expand
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.

The construction of a Use Case diagram employs the following steps:

  1. Define the context of the system:

    1.1

    Identify the actors and their responsibilities.

    1.2

    Identify the use cases, the behaviors of the system, in terms of specific goals and/or results that must be produced.

  2. Evaluate the actors and use cases to find opportunities for refinement, such as splitting or merging definitions.

  3. Evaluate the use cases to find «include» type relationships.

  4. Evaluate the use cases to find «extend» type relationships.

  5. Evaluate the actors and use cases for generalization opportunities (shared properties).

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.

Click To expand
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.

Click To expand
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.

Tip

Throughout 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.

Click To expand
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).

Click To expand
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.

Click To expand
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

  1. How well it satisfies the established objectives (the desired results of the use case).

  2. How well it can be supported within the constraints for the project (performance, cost, time to deliver, quality, and maintainability).

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.

Caution

One 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.

Click To expand
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.

Click To expand
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.

Click To expand
Figure 12-12: Modeling associations between agents and use cases.
Click To expand
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.

Tip

Some 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:

Click To expand
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.

Click To expand
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.

Caution

The 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.

Click To expand
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.

Click To expand
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.


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.

Tip

The 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?

Click To expand
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.

Tip

Notice 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.

Note

The 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).

  1. 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).

  2. The system provides default lists of all currently scheduled events and performances scheduled within the next 20 days.

  3. The user may choose one of the following options:

    1. Cancel out of the transaction.

    2. Select an event. The system responds by replacing the existing list of performances with a list of performances for the selected event.

    3. 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.

    4. Provide a date range. The system responds by replacing the existing list of performances with a list of performances for the selected date range.

  4. 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.

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.

Start Sidebar
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.

End Sidebar

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.


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.

Caution

The 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 is 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.

Start Sidebar
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.

End Sidebar

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 is 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.
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.

Click To expand
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.

Click To expand
Figure 12-20: Trace the successful scenario from beginning to end.
Note

Notice 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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.


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:

  1. Define the context of the system:

    1.1

    Identify the actors and their responsibilities.

    1.2

    Identify the use cases, the features of the system, in terms of specific goals and/or results that must be produced.

  2. Evaluate the actors and use cases to find opportunities for refinement (splitting or merging definitions).

  3. Evaluate the use cases to find «include» type relationships.

  4. Evaluate the use cases to find «extend» type relationships.

  5. Evaluate the actors and use cases for generalization opportunities (shared properties).

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.


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.

Note

Some 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.


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.
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.


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.

Tip

It 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.

Tip

To 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.

Caution

Not 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.


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 page…well, you get the idea. Figure 13-1 shows this concept graphically.

Click To expand
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.

Click To expand
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?"

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
Figure 13-8: Merging control using the synchronization bar.
Caution

Technically, 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.


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 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."

Click To expand
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:

  1. To loop back to a previous place in the logic, use a merge-point diamond.

  2. 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.

Figure 13-10 shows the needed changes.

Click To expand
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.

Click To expand
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.

Click To expand
Figure 13-12: Modeling the Use case dialog, "For each piece find the Purchase Order."
Note

The 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:

  1. Find the Purchase Order using the PO_nbr.

  2. If not found, display "Invalid P.O." error message and set the item aside.

  3. Else (P.O. found).

    Figure 13-13 continues the flow for items where the P.O. was found.

    Click To expand
    Figure 13-13: Modeling the use case dialog, "matching the items to the P.O."

  4. Match the product to an item on the Purchase Order.

  5. If not matched, display "Invalid item" error message and set the item aside.

  6. Else check off the item and quantity on the Purchase Order.

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.

Click To expand
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.

Click To expand
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).


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.

Click To expand
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.


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.)

Click To expand
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.

Click To expand
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."

Click To expand
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.

Tip

Boolean 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.

Click To expand
Figure 13-20: Adding a decision node to the Activity diagram.
Note

There 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".

Click To expand
Figure 13-21: Adding a merge node to the Activity diagram.
Note

So 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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.


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».

Click To expand
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.

Note

Early 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.

Click To expand
Figure 13-29: Two activity partitions for a single activity.
Note

There 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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Note

When 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.

Click To expand
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.

Click To expand
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.

Click To expand
Figure 13-35: FlowFinalNode.


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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Note

An 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.

Click To expand
Figure 13-49: Modeling an interruptible activity region.
©OMG 2.0


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.

Click To expand
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.

Caution

The 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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
Figure 13-54: Notation for an expansion region with only one action.
Note

The 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.

Click To expand
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.

Click To expand
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.

Note

It 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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
Figure 13-61: Notation for a loop node with inputVariables and results.


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.


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


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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.
Note

It'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.

Click To expand
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.

Note

Deleting 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.

Click To expand
Figure 14-7: Package diagram is drawn using a Class diagram. It shows all subpackages of a package.


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.

Click To expand
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.

Click To expand
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.

Click To expand
Figure 14-10: Subsystem contains specification and realization compartments.


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.

Click To expand
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.


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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
Figure 14-18: Overall model, package, and subsystem structure of the hotel example.


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.


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:

  1. The physical description of the software. The Component diagram models the physical implementation of the software specified by the logical requirements in Class diagram.

  2. The layout of the hardware. The Deployment diagram (discussed in Chapter 16) models the physical architecture of the hardware.

  3. 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.

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.

Start Sidebar
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).

End Sidebar

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."

Click To expand
Figure 15-1: UML 1.4 metamodel for components. ©OMG 1.4
Click To expand
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.


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.

Tip

A 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.
Tip

The 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.

Click To expand
Figure 15-3: Component icon and name.
Note

The 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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
Figure 15-11: The relationship between component interfaces and the interfaces of resident classes.
Note

Figure 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.


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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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).

Click To expand
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.

Click To expand
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.

Click To expand
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).

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.)

Click To expand
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.

Click To expand
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.


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.


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).

Note

Although 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.


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.

Click To expand
Figure 16-1: UML 1.4 node metamodel. ©OMG 1.4
Note

In 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.

Click To expand
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

Click To expand
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.

Click To expand
Figure 16-4: Association stereotype between nodes.


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.

Click To expand
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.

Click To expand
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.

Click To expand
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.


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.


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.

Click To expand
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.

Click To expand
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.


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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
Figure 17-11: Generalizing nodes.


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.

Tip

Artifacts 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.

Click To expand
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).

Click To expand
Figure 17-13: Manifestations used to create an artifact.
©OMG 2.0
Click To expand
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».


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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
Figure 17-21: Modeling an artifact specification.


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.


Part VI: Bringing Rigor to the Model

In This Part

Chapter 18: Applying Constraints to the UML Diagrams
Chapter 19: Action Semantics


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.

Note

There 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.

Note

There 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:

  1. 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

    1. be extended to provide new modeling tools (languages).

    2. 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.)

  2. 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.

  3. 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.

  4. 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.

  5. 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.)


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.

Click To expand
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

Note

The 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.
Start Sidebar
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.

End Sidebar


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.

Click To expand
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.

Click To expand
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.

Caution

Only 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
Caution

Attempting 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.

Click To expand
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.

Caution

As 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.

Click To expand
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.


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.

Click To expand
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 ...


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.

Click To expand
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.

Caution

The "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 }


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.

    Note

    Hereafter, 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)


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.


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.


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.

Note

The 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
Result | The result variable of the IterateExp
Note

When 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))


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.


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.

Note

The 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.


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).

Start 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.

End Sidebar

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.

Note

There 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.


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.

Note

Not 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é, François Pennaneac'h, Wai-Ming Ho, Alain Le Guennec, and Jean-Marc Jézéquel, 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.


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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
Figure 19-4: A group action may receive a control flow. The control flow is implicitly passed to each subaction.
Click To expand
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.

Click To expand
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.


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 n2 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 2n2.

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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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)


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.


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


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.


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.

Note

The 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.

Click To expand
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.

Click To expand
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.


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.


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?


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.


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.


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.

Click To expand
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.

Click To expand
Figure 21-2: The Profiles package is dependent on the Core package of the UML infrastructure.
Note

The 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.

Click To expand
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».

Click To expand
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.

Click To expand
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.


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.

Click To expand
Figure 21-6: Example EJB profile provided in UML 2.0 specification.
Note

The 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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

    Click To expand
    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.

Click To expand
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.

Click To expand
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.

Click To expand
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.

Click To expand
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:

Click To expand
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.

Click To expand
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.

Click To expand
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):

Click To expand
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.

Click To expand
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). |
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. |
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 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 | 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. |


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.


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.


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.


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.

Start Sidebar
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.

End Sidebar

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.


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.

Note

XMI 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.


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.
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.


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.

Click To expand
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
Start example
<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.

End example

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.

Click To expand
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
Start example
<! -- 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;
>
End example

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.

Click To expand
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>


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
Start example
<! - - 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;
End example

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).

Click To expand
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
Start example
<!-- 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;
>
End example

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>


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.

Click To expand
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.


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.


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.


Appendix A: UML 1.4 Notation Guide

Class Diagram Notation

The Class diagram notation is explained fully in Chapters 5 through 7.

Class notation

Click To expand
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.

Click To expand
Figure A-2: Four presentation alternatives for classes with stereotypes.

Template class

Click To expand
Figure A-3: Template class.
Parameter syntax

name ':' type [= default]
Bound element syntax
template-name '<' value-list '>'

Interface class notation

Click To expand
Figure A-4: Interface class notation.

Association notation

Associations are covered in Chapter 6.

Click To expand
Figure A-5: Binary association notation.

Reflexive association and roles

Click To expand
Figure A-6: Reflexive association and roles notation.

Constraints between associations

Click To expand
Figure A-7: Constraints between associations.

Association navigability

Click To expand
Figure A-8: Association navigability.

Ordering, derived association, and qualified association

Click To expand
Figure A-9: Ordering, derived association, and qualified association.

Association class notation

Click To expand
Figure A-10: Association class notation.

N-ary association

Click To expand
Figure A-11: N-ary association.

Aggregation and composition notation

Click To expand
Figure A-12: Aggregation and composition notation.

Alternative composition notation

Chapter 7 addresses Composite Structure diagrams, the alternative notation for composition.

Click To expand
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.

Click To expand
Figure A-14: Generalization notation: complete constraint, Power Type, ellipse, abstract class.
Click To expand
Figure A-15: Generalization notation: discriminator, disjoint and overlapping, constraints, and multiple inheritance.

Dependency notation

Chapter 6 addresses dependency notation.

Click To expand
Figure A-16: Dependency notation between two packages (left) and two classes (right).
Click To expand
Figure A-17: Class dependency notation.


Object Diagram

Chapter 7 addresses the Object diagram.

Object and link notation

Click To expand
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

Click To expand
Figure A-19: Using collaboration notation to define a design pattern.

Implementing a design pattern/collaboration

Click To expand
Figure A-20: Implementing a design pattern (collaboration).


Sequence Diagram Notation

Chapters 8 and 9 address Sequence diagram notation.

Sequence diagram lifeline, message and return, self-reference, guard, and iteration

Click To expand
Figure A-21: Sequence diagram notation.

Message (and arrow) types

Click To expand
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

Click To expand
Figure A-23: Recursive message.

Object creation and termination

Click To expand
Figure A-24: Object creation and termination.

Time constraints

Click To expand
Figure A-25: Time constraints.

Activation and focus of control

Click To expand
Figure A-26: Activation (also called focus of control).


Collaboration Diagram Notation

Chapter 8 addresses the Collaboration diagram.

Click To expand
Figure A-27: Collaboration diagram notation.


Statechart Diagram Notation

The Statechart diagram is covered in Chapter 10.

Initial and final state, state, transition with guard

Click To expand
Figure A-28: Statechart notation (1).

When and after clauses

Click To expand
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

Click To expand
Figure A-30: Self-transition, and entry and exit actions.

Static branch state

Click To expand
Figure A-31: Static branch state.

Dynamic choice point

Click To expand
Figure A-32: Dynamic choice point.

Composite state

Click To expand
Figure A-33: Composite state.

Deep and shallow history

Click To expand
Figure A-34: Deep and shallow history.

Concurrent substates

Click To expand
Figure A-35: Concurrent substates.

Split and merge of control

Click To expand
Figure A-36: Split and merge of control.

Submachine state and stub states

Click To expand
Figure A-37: Submachine state and stub states.

Synch states

Click To expand
Figure A-38: Synch states.

Send and receive signals

Click To expand
Figure A-39: Send and receive signals.
Note

The gray highlighted rectangles are for emphasis only.


Use Case Diagram

The Use Case diagram is covered in Chapter 12.

Click To expand
Figure A-40: Use Case diagram notation.


Activity Diagram

Chapter 13 discusses the Activity diagram.

Start, end, decision (split), and merge

Click To expand
Figure A-41: Start, end, decision (split), and merge.

Concurrency using the Synchronization bar to model forks and joins

Click To expand
Figure A-42: Fork and join notation.

Activity, transition, and transition guard

Click To expand
Figure A-43: Activity, transition, and transition guard.

Swimlanes and object flows

Click To expand
Figure A-44: An Activity diagram divided into three swimlanes and passing the Order object from one activity to the next.


Component Diagram

Chapter 15 addresses the Component diagram.

Click To expand
Figure A-45: Component diagram notation.

Alternative notation for resident and implementing classes

Click To expand
Figure A-46: Alternative notation for resident and implementing classes.


Deployment Diagram

Chapter 16 covers the Deployment diagram.

Click To expand
Figure A-47: Nodes defined as classifiers, with attributes and operations, at type and instance levels.
Click To expand
Figure A-48: Component diagram at type and instance levels.


Combined Component and Deployment Diagram

This topic is covered in Chapter 17.

Component deployment on a node instance

Click To expand
Figure A-49: Deployment of a component on a node instance.

Containment version

Click To expand
Figure A-50: Deployment of components on a node instance using containment.


Packages

Basic Package diagram

Packages as Namespaces

Figure A-51: Packages as namespaces.

Package containment notation alternatives

Click To expand
Figure A-52: Package containment notation alternatives.

Access dependency

Click To expand
Figure A-53: Access dependency.

Merge dependency

Click To expand
Figure A-54: Merge dependency.

Subsystem diagram

Subsystem notation alternatives

Click To expand
Figure A-55: Subsystem notation alternatives.

Subsystem interface notation

Click To expand
Figure A-56: Subsystem interface notation.

Subsystem realization

Click To expand
Figure A-57: Subsystem realization.

Model diagram

Model notation

Click To expand
Figure A-58: Model notation.


Appendix B: UML 2.0 Notation Guide

Class Diagram Notation

The Class diagram notation is explained fully in Chapters 5 through 7.

Class notation

Click To expand
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.

Click To expand
Figure B-2: Four presentation alternatives for classes with stereotypes.

Interface class notation

Click To expand
Figure B-3: Interface class notation.

Template class

Click To expand
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.

Click To expand
Figure B-5: Binary association notation.

Reflexive association and roles

Click To expand
Figure B-6: Reflexive association and roles notation.

Constraints between associations

Click To expand
Figure B-7: Constraints between associations.

Association navigability

Click To expand
Figure B-8: Navigability.

Ordering, derived association, and qualified association

Click To expand
Figure B-9: Ordering, derived association, and qualified association.

Association class notation

Click To expand
Figure B-10: Association class notation.

N-ary association

Click To expand
Figure B-11: N-ary association.

Aggregation and composition notation

Click To expand
Figure B-12: Aggregation and composition notation.

Composite structure notation

Click To expand
Figure B-13: Alternative composition notation.

Generalization notation

Generalization is explained in Chapter 6.

Click To expand
Figure B-14: Generalization notation: complete constraint, Power Type, ellipse, and abstract class.
Click To expand
Figure B-15: Generalization notation: discriminator, disjoint and overlapping constraints, and multiple inheritance.

Dependency notation

Click To expand
Figure B-16: Dependency notation between two packages (left) and two classes (right).
Click To expand
Figure B-17: Class dependency notation.


Object Diagram

Chapter 7 covers the Object diagram.

Object and link notation

Click To expand
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

Click To expand
Figure B-19: Using collaboration notation to define a design pattern.

Implementing a design pattern/collaboration

Click To expand
Figure B-20: Implementing a design pattern (collaboration).


Sequence Diagram Notation

The Sequence diagram is covered in Chapter 9.

Sequence diagram (interaction) lifeline, message and return, self-reference, guard, and iteration

Click To expand
Figure B-21: Sequence diagram basic notation.

Message (and arrow) types

Click To expand
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

Click To expand
Figure B-23: State invariant.


Object creation and termination

Return is optional (some languages do not allow returns in contsructor syntax)

Click To expand
Figure B-24: Object creation and termination.

Duration constraints

Click To expand
Figure B-25: Duration constraints.

Time constraints

Click To expand
Figure B-26: Time constraints.

Interaction occurrence

Click To expand
Figure B-27: Interaction occurrence.

Gates and parameters

Click To expand
Figure B-28: Interaction occurrence.

Interaction operands and operators

Click To expand
Figure B-29: Interaction occurrence.

Interaction operators consider, ignore, and assert

Click To expand
Figure B-30: Interaction operators consider, ignore, and assert.


Communication Diagram

Chapter 9 covers the Communication diagram.

Click To expand
Figure B-31: Communication diagram notation.


Interaction Overview Diagram

Chapter 9 addresses the Interaction Overview diagram.

Click To expand
Figure B-32: Interaction Overview notation.
Click To expand
Figure B-33: Interaction Overview lifeline notation.


Timing Diagram

The Timing diagram is discussed in Chapter 9.

Click To expand
Figure B-34: Timing diagram notation.
Click To expand
Figure B-35: Timing diagram alternative notation.


Statechart Diagram Notation

Chapter 11 discusses the Statechart diagram.

Initial and final state, state, transition with guard

Click To expand
Figure B-36: Statechart notation (1).

When and after clauses

Click To expand
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

Click To expand
Figure B-38: Self-transition, and entry and exit actions.

Static branch state

Click To expand
Figure B-39: Static branch state.

Dynamic choice point

Click To expand
Figure B-40: Dynamic choice point.

Composite state

Click To expand
Figure B-41: Composite state.

Deep and shallow history

Click To expand
Figure B-42: Deep and shallow history.

Concurrent substates

Click To expand
Figure B-43: Concurrent substates.

Split and merge of control

Click To expand
Figure B-44: Split and merge of control.

Submachine state and stub states

Click To expand
Figure B-45: Submachine state and stub states.

Synch states

Click To expand
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

Click To expand
Figure B-47: Action specification with send and receive signals.
Note

The gray highlighted rectangles are for emphasis only.

Activity and completion transition

Click To expand
Figure B-48: Activity and completion transition.

Two ways to model common transitions

Click To expand
Figure B-49: Two ways to model common transitions.

Protocol state machine and generalization

Click To expand
Figure B-50: Protocol state machine and generalization.


Use Case Diagram

The Use Case diagram is covered in Chapter 12.

Click To expand
Figure B-51: Use Case diagram notation.


Activity Diagram

Chapter 13 has details on the Activity diagram.

Start, end, decision (split), and merge

Click To expand
Figure B-52: Start, end, decision (split), and merge.

Concurrency using fork and join nodes

Click To expand
Figure B-53: Fork and join notation.

Activity, transition, and transition guard

Click To expand
Figure B-54: Activity, transition, and transition guard.


Component Diagram

Chapter 15 discusses the Component diagram.

Click To expand
Figure B-55: Component diagram notation.

Alternative notations for realizing classes

Click To expand
Figure B-56: Alternative notation for realizing classes.


Deployment Diagram

Chapter 16 provides details on the Deployment diagram.

Click To expand
Figure B-57: Nodes defined as classifiers, with attributes and operations, at type and instance levels.
Click To expand
Figure B-58: Component diagram at type and instance levels.


Combined Component and Deployment Diagram

This topic is covered in Chapter 17.

Artifacts that implement components

Click To expand
Figure B-59: Artifacts that implement components.

Component deployment on a node instance

Click To expand
Figure B-60: Deployment of a component on a node instance.

Deployment specification

Click To expand
Figure B-61: Deployment specification.

Deployed components

Click To expand
Figure B-62: Deployed components.


Packages

Basic Package diagram

Packages as namespaces

Figure B-63: Packages as namespaces.

Package containment notation alternatives

Click To expand
Figure B-64: Package containment notation alternatives.

Access dependency

Click To expand
Figure B-65: Access dependency.

Merge dependency

Click To expand
Figure B-66: Merge dependency.

Subsystem diagram

Subsystem notation alternatives

Click To expand
Figure B-67: Subsystem notation alternatives.

Subsystem interface notation

Click To expand
Figure B-68: Subsystem interface notation.

Subsystem realization

Click To expand
Figure B-69: Subsystem realization.

Model diagram

Model notation

Click To expand
Figure B-70: Model notation.


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.
«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.
«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 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».
«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
«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


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.
Click To expand
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.
Click To expand
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.
Click To expand
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.
Click To expand
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.
Click To expand
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.
Click To expand
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.
Click To expand
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.
Click To expand
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.
Click To expand
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.
Click To expand
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.


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.
Click To expand
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.
Click To expand
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.
Click To expand
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.
Click To expand
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.
Click To expand
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.
Click To expand
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)
Click To expand
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.
Click To expand
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).
Click To expand
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.
Click To expand
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.
Click To expand
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.
Click To expand
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.
Click To expand
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.
Click To expand
Figure GL-24: Abstract and concrete classes in an inheritance hierarchy/tree.
Click To expand
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.
Click To expand
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.
Click To expand
Figure GL-27: Conditional node.
Click To expand
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.
Click To expand
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.


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.
Click To expand
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.
Click To expand
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.
Click To expand
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 1st gear and Moving in 2nd gear in Figure GL-33.
Click To expand
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.
Click To expand
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.
Click To expand
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.
Click To expand
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.


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.
Click To expand
Figure GL-37: The extend relationship between use cases.
Click To expand
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.
Click To expand
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.
Click To expand
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.
Click To expand
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.
Click To expand
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).
Click To expand
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.
Click To expand
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.
Click To expand
Figure GL-47: Interaction overview diagram.
interface
A named set of operations that characterize the behavior of an element.
Click To expand
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.


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.
Click To expand
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.
Click To expand
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.
Click To expand
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.
Click To expand
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.
Click To expand
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].


N-P

name
A string used to identify a model element.
name compartment
A predefined class compartment containing the class name, stereotype, and properties.
Click To expand
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.
Click To expand
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.
Click To expand
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.
Click To expand
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.
Click To expand
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.
Click To expand
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.
Click To expand
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.
Click To expand
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.
Click To expand
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.
Click To expand
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).
Click To expand
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.
Click To expand
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.
Click To expand
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.
Click To expand
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.


Q-S

qualifier
An association attribute or tuple of attributes whose values partition the set of objects related to an object across an association.
Click To expand
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.
Click To expand
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.
Click To expand
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.
Click To expand
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.
Click To expand
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.
Click To expand
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».
Click To expand
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.
Click To expand
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.
Click To expand
Figure GL-76: Superclass-subclass relationship in an inheritance hierarchy/tree.
Click To expand
Figure GL-77: A submachine state within a composite state.
Click To expand
Figure GL-78: Subpackages within a package.
substate
A state that is part of a composite state.
Click To expand
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.
Click To expand
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.
Click To expand
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.


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.
Click To expand
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.
Click To expand
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


Previous Section
< Day Day Up >
Next Section

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


Previous Section
< Day Day Up >
Next Section

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


Previous Section
< Day Day Up >
Next Section

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


Previous Section
< Day Day Up >
Next Section

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


Previous Section
< Day Day Up >
Next Section

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


Previous Section
< Day Day Up >
Next Section

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


Previous Section
< Day Day Up >
Next Section

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


Previous Section
< Day Day Up >
Next Section

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


Previous Section
< Day Day Up >
Next Section

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


Previous Section
< Day Day Up >
Next Section

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


Previous Section
< Day Day Up >
Next Section

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
Jézéquel, 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


Previous Section
< Day Day Up >
Next Section

Index

K

Kabira Technologies, UML compilers by, 4


Previous Section
< Day Day Up >
Next Section

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


Previous Section
< Day Day Up >
Next Section

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


Previous Section
< Day Day Up >
Next Section

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


Previous Section
< Day Day Up >
Next Section

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


Previous Section
< Day Day Up >
Next Section

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


Previous Section
< Day Day Up >
Next Section

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


Previous Section
< Day Day Up >
Next Section

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


Previous Section
< Day Day Up >
Next Section

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


Previous Section
< Day Day Up >
Next Section

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


Previous Section
< Day Day Up >
Next Section

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; Jézéquel), 644
utility class, 115
«utility» stereotype, 115, 840


Previous Section
< Day Day Up >
Next Section

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


Previous Section
< Day Day Up >
Next Section

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


Previous Section
< Day Day Up >
Next Section

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


Previous Section
< Day Day Up >
Next Section

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.


Previous Section
< Day Day Up >
Next Section

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


Previous Section
< Day Day Up >
Next Section

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


Previous Section
< 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