21,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
* Uses friendly, easy-to-understand For Dummies style to help readers learn to model systems with the latest version of UML, the modeling language used by companies throughout the world to develop blueprints for complex computer systems * Guides programmers, architects, and business analysts through applying UML to design large, complex enterprise applications that enable scalability, security, and robust execution * Illustrates concepts with mini-cases from different business domains and provides practical advice and examples * Covers critical topics for users of UML, including object modeling, case modeling, advanced dynamic and functional modeling, and component and deployment modeling
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 578
Veröffentlichungsjahr: 2011
Ähnliche
UML 2 For Dummies®
by Michael Jesse Chonoles and James A. Schardt
UML 2 For Dummies®
Published byWiley Publishing, Inc.111 River St.Hoboken, NJ 07030-5774www.wiley.com
Copyright © 2003 by Wiley Publishing, Inc., Indianapolis, Indiana
Published by Wiley Publishing, Inc., Indianapolis, Indiana
Published simultaneously in Canada
No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, 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: [email protected].
Trademarks: Wiley, the Wiley Publishing logo, For Dummies, the Dummies Man logo, A Reference for the Rest of Us!, The Dummies Way, Dummies Daily, The Fun and Easy Way, Dummies.com and related trade dress are trademarks or registered trademarks of Wiley Publishing, Inc., in the United States and other countries, and may not be used without written permission. 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.
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 877-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 electronic books.
Library of Congress Control Number: 2003105654
ISBN: 978-0-7645-2614-5
Manufactured in the United States of America
10 9 8 7 6 5
1B/TR/RQ/QY/IN
About the Authors
Michael Jesse Chonoles: An established system developer, educator, author, and consultant, Michael has done just about everything that you can do in software and system development — business, requirements, and software analysis; software, system, and architectural design; coding in many languages; testing and quality control — right through marketing, packing, and shrink-wrapping the software. His titles include Chief of Methodology for the Advanced Concepts Center (ACC), Software Development Practice Area Director, Consulting Analyst, Software Standard and Practices Manager, Test Director, Senior Software Engineer, several varieties of Team/Project Lead/Staff, and (his personal favorite) Wizard. At the Advanced Concepts Center, he was responsible for the content and direction of its Object-Oriented and Requirements-Gathering Curricula as well as its Software Development Practice. Together with his co-author, he constructed a software/ system-development methodology, CADIT, which was an early attempt to combine agile techniques with aerospace discipline. He continues his quest to make the complicated simple, while increasing the professional rigor, quality, and productivity of his audience’s working lives.
Michael has been involved in many aspects of UML, even before there was a UML. He’s been an active member of the UML RTF (Revision Task Force) at OMG — and frequently writes, lectures, speaks, and suggests UML topics.
Michael has an MSE in Systems Engineering from the University of Pennsylvania and BSs in Math and Physics from MIT. He can be contacted at [email protected].
James A. Schardt: As the Chief Technologist with the Advanced Concepts Center, James provides 24 years of experience and a firm grounding in object-oriented development, data warehousing, and distributed systems. He teaches and mentors Fortune 50 companies in the U.S. and abroad. His many years of practice in object-oriented systems, database design, change management, business engineering, instructional design, systems-architecture assessment, business engineering, and team facilitation bring a wealth of experience to his assignments.
He authors papers on data warehousing and object technology and also wrote a column for Report on Object-Oriented Analysis and Design. James speaks at The Data Warehouse Institute’s world conferences on a regular basis. He delivers a two-day presentation on collecting and structuring the requirements for enterprise data-warehouse development.
James is always looking for ways to improve the way that we develop systems and software. Clients request him by name to deliver his exceptional knowledge transfer skills, both in the classroom and as a mentor on projects. Over the years, James has managed major research and development programs, invented new systems methods, developed “intelligent” information-access systems, and provided unique insights into clients’ difficult development problems.
James has an MSE in Systems Engineering from the University of Pennsylvania. He can be reached via [email protected].
Dedication
Michael dedicates this book to his wife Susann (of blessed memory) and to their son Zev, for their love, support, sacrifice, and silliness.
Jim dedicates this book to his wife Martha for her sustaining love and encouragement, and to M. R. Bawa Muhaiyaddeen as the guiding inspiration in his life.
Authors’ Acknowledgments
We would like to thank all the students whom we have taught over the years for their help in shaping our ideas, and all the members of the Advanced Concepts Center, both past and present, for the chance to work with some of the best practitioners in the business of systems and software development.
Together we acknowledge the absolutely necessary help, encouragement, and moral support of our Wiley editors Terri Varveris and Kala Schrager.
Michael would like to thank a whole bunch of people who have helped him over the years, and specifically with this book: Susann Chonoles for teaching him how to write better and for help in proofreading; Zev Chonoles, for being a Test Dummy For Dummies and reading his chapters; his managers Bob DeCarli, Mike Duffy, and Barbara Zimmerman, who encouraged him even when he messed up; and his high-school buddies Joseph Newmark, Jeffrey Landsman, and Barry Salowitz, who keep on telling him what he’s doing wrong. It goes without saying that he’s grateful to his parents for everything.
He’d also like to acknowledge Jim Schardt for his work toward understanding UML in all its forms, and Lou Varveris for his insight, recommendations, and for access to the Popkin’s System Architect tool. He’s also grateful to all the members of the OMG ADTF and the UML Gurus for their technical advice, encouragement, and support over the years — especially Cris Kobryn, Jim Odell, Jim Rumbaugh, Philippe Desfray, and Bran Selic.
Jim would like to thank a number of individuals who helped him develop his knowledge and skills over the years: David Oliver for his systems perspective; Michael Kamfonas for his data-warehouse development insights; Michael Chonoles for his work toward understanding UML in all its forms; Jim Rumbaugh and Fred Eddy for their mentoring on object-oriented analysis; and Michael Blaha and William Premerlani for their guiding hand in developing database-design techniques using UML.
Publisher’s Acknowledgments
We’re proud of this book; please send us your comments through our online registration form located at www.dummies.com/register/
Some of the people who helped bring this book to market include the following:
Acquisitions, Editorial, and Media Development
Project Editor: Kala Schrager
Acquisitions Editor: Theresa Varveris
Senior Copy Editor: Barry Childs-Helton
Technical Editor: Lou Varveris
Editorial Manager: Kevin Kirschner
Media Development Supervisor: Richard Graves
Editorial Assistant: Amanda Foxworth
Cartoons: Rich Tennant, www.the5thwave.com
Production
Project Coordinators: Kristie Rees, Dale White
Layout and Graphics: Seth Conley, Kelly Emkow, Carrie Foster, LeAndra Hosier, Stephanie D. Jumper, Michael Kruzil, Mary Gillot Virgin
Proofreaders: Laura Albert, Susan Moritz, Dwight Ramsey, TECHBOOKS Production Services
Indexer: TECHBOOKS Production Services
Publishing and Editorial for Technology Dummies
Richard Swadley, Vice President and Executive Group Publisher
Andy Cummings, Vice President and Publisher
Mary C. Corder, Editorial Director
Publishing for Consumer Dummies
Diane Graves Steele, Vice President and Publisher
Joyce Pepple, Acquisitions Director
Composition Services
Gerry Fahey, Vice President of Production Services
Debbie Stailey, Director of Composition Services
Contents
Title
Introduction
How to Use This Book
Some Presumptuous Assumptions
How This Book Is Organized
Icons Used in This Book
Where to Go from Here
Part I : UML and System Development
Chapter 1: What’s UML About, Alfie?
Introducing UML
Appreciating the Power of UML
Choosing the Appropriate UML Diagram
Identifying Who Needs UML
Dispelling Misconceptions about UML
Chapter 2: Following Best Practices
Understanding UML Terminology and Concepts
Improving Your Productivity
Part II : The Basics of Object Modeling
Chapter 3: Objects and Classes
Recognizing Classes and Objects
Naming Objects and Classes
Identifying Attributes
Performing Operations
Diagramming a System’s Parts
Defining Visibility
Chapter 4: Relating Objects That Work Together
Showing Static Relationships in a Class Diagram
Linking Objects Together
Associating Classes
Naming Your Associations
Relating Many Objects (Multiplicity)
Understanding the Roles That Classes Can Play
Associating Classes with Themselves
Using Association Classes
Qualifying Relationships
Finding a Way — Navigation
Creating a Program
Chapter 5: Including the Parts with the Whole
Representing the Whole and the Parts
Showing Ownership: Composition
Showing What Can Be Shared: Aggregation
Deciding between Aggregation and Composition
Using Alternate Composite Notation
Chapter 6: Reusing Superclasses: Generalization and Inheritance
Making Generalizations
Specializing Classes
Using Generalization Sets
Inheriting from Ancestors
Exploring the Pros and Cons of Multiple Inheritances
Reusing Code
Chapter 7: Organizing UML Class Diagrams and Packages
Modeling Objects and Classes on Diagrams
Constructing Class Diagrams
Using Project-Oriented Class Diagrams
Part III : The Basics of Use-Case Modeling
Chapter 8: Introducing Use-Case Diagrams
Identifying Your Audience
Casting the System’s Actors
Exposing an Actor’s Roles
Showing Your System’s Use Cases
Distinguishing between Internal and External
Using Context Diagrams
Packaging Use Cases
Chapter 9: Defining the Inside of a Use Case
Creating a Use-Case Specification
Telling the Use-Case Story
Indicating Alternative Courses of Behavior
Chapter 10: Relating Use Cases to Each Other
Linking Use Cases with «include»
Using Generalization with Use Cases
Extending Use Cases
Part IV : The Basics of Functional Modeling
Chapter 11: Introducing Functional Modeling
Modeling Functions from an Object-Oriented Perspective
Writing Text-Based Behavioral Specifications
Chapter 12: Capturing Scenarios with Sequence Diagrams
Diagramming an Interaction Scenario
Composing Interaction Diagrams
Chapter 13: Specifying Workflows with Activity Diagrams
Ordering the Flow of Behavior
Working through Workflow Diagrams
Chapter 14: Capturing How Objects Collaborate
Developing a Collaboration
Constructing the Communication Diagram
Conquering Concurrency
Capturing the Collaboration’s Design
Chapter 15: Capturing the Patterns of Behavior
Describing Patterns with Collaborations
Applying Patterns
Framing Frameworks
Part V : Dynamic Modeling
Chapter 16: Defining the Object’s Lives with States
Showing the Life of an Object
Programming an Object’s Memory with State Attributes
Creating State Diagrams from Scenarios
Chapter 17: Interrupting the States by Hosting Events
Making Use of Events
Indicating Order of Execution on a Diagram
Showing Transitions as Icons
Chapter 18: Avoiding States of Confusion
Simplifying Large State Diagrams
Handling Concurrency with States
Building Protocol State Machines
Part VI : Modeling the System’s Architecture
Chapter 19: Deploying the System’s Components
Defining Your System
Constructing Logical Pieces
Working with Components
Deploying Physical Pieces (Implementation)
Chapter 20: Breaking the System into Packages/Subsystems
Using Packages and Subsystems
Exploring Dependencies
Patterning the Relationships
Part VII : The Part of Tens
Chapter 21: Ten Common Modeling Mistakes
Splitting Attributes and Operations
Using Too Few or Too Many Diagram Types
Showing Too Much Detail
Using Vague Terminology
Defining the Same Thing Twice
Linking Everything Together
Creating Too Many Use Cases
Completing One Diagram Before Moving On
Cycling Around Class Diagrams
Not Listening to the User
Chapter 22: Ten Useful UML Web Sites
Weave a Tangled Web
UML Home Page
UML Forum
UML 2 Submitters
OCL Center
Magazines and Information Portals
Search Engines
Tool Sites
Training Sites
Forums and Groups
Miscellaneous Sites
Chapter 23: Ten Useful UML Modeling Tools
Picking a Tool
Argo/UML
Konesa
Ideogramic UML
Objecteering
Rational Rose Suite
Rhapsody
System Architect
Tau
Together
Visio
Chapter 24: Ten Ways to Use UML Diagrams
Context Diagram
Use-Case Diagram
Domain Class Diagram
Sequence Diagram
State Diagram
Application Class Diagram
Package Diagram
Deployment Diagram
Communication Diagram
Activity Diagram
Introduction
If, like us, you’re a software developer or computer professional of some sort, you probably have to deal with the stereotype that developers can’t express themselves among normal humans about normal things. Unfortunately, this book may not help you with that particular challenge, but it can help improve your ability to communicate with other developers about technical matters. UML
If you’re already familiar with UML, you know how powerful and expressive it is — but don’t be surprised if you’re impressed all over again by the new features of UML 2. Perhaps you found some parts of UML too complicated or the apparent benefit too obscure. Well, the UML gurus have revamped UML in many areas — making easier to express yourself exactly and clearly — and they have also added fresh capabilities for the latest software- and system-development problems that you’re facing.
But because your problems are complex — and your solutions are some-times even more complex — UML is not always simple to learn. It’s a large and multifaceted language, capable of helping in all areas of development, from analysis to test as well as from database to embedded-real-time. To some, it’s a bewildering array of diagrams and symbols. Sometimes it might appear to you that the UML gurus purposely make it too complicated (and with UML 2, even more so) for therest of us to understand.
Bottom line: You need a practical, experience-based guide to the ins and outs of this new language. Let this book be that guide. We boiled down our experiences with UML (in many environments) and our skills as educators to focus on key UML capabilities that you need first to be more productive.
So, with straightforward English and concrete examples, we give you a leg up on expressing yourself and being more creative on the job. (Hey, it could help you get a raise — just don’t expect us to help you get a date.)
How to Use This Book
There’s a right way and a wrong way to use this book. Luckily (like its subject, UML 2), this book is remarkably versatile. If you’re a traditionalist, you can read it from cover to cover (although you’ll probably stop at the index). That’s a great approach if you’re really new to UML. If you’re familiar with earlier versions of UML, you can skip around looking for the new UML 2 stuff. You may miss our (ahem) great insights into the rest of UML, but you know why you bought the book — do what works. Using any of these techniques will get you familiar with your book so that you can count on it to help unstick you if you hit a snag with UML.
After you make friends with your book, you’ll probably find yourself taking advantage of its just-in-time features. With just a bit of page flipping, you’ll be at a section that’s full of examples, tips, techniques, and warnings that will help you with your UML modeling.
There are other ways to use this book . . . and some of them are wrong ways. It’s not going to work that well as a doorstop (wrong size), and it probably won’t impress your date (unless you’re dating a developer who’s new to UML). However, it’ll look great on your bookshelf — silently conveying to your boss your desire to improve — but if you never open it, you won’t get the full benefit.
Some Presumptuous Assumptions
If you’re reading this, we can safely assume that not only have you already opened the book, you’re probably also a developer of software, systems, or databases, and you want to read or write UML 2 diagrams. Perhaps you’re a manager or business analyst in the same boat.
We won’t assume that you know any particular computer language, although knowing one will certainly help.
For the most part, we assume that you fall into one of two major categories: Either you’re a modeler (with a yen to communicate requirements or how you think the world works), or you’re a developer (looking to explore alternative designs or communicate your results). Either way, this book is for you.
We assume that you’re capable of using a tool to draw UML diagrams — we don’t care which one. If the only tool that you have your hands on is in your hands (as opposed to on-screen), you won’t be at a disadvantage when you use this book (although your diagrams won’t be quite as tidy if you’re drawing with a stick on wet sand). You may even be better off doing some diagrams by hand; electronic UML tools are often expensive and may not yet be up to date with all the neat UML 2 features that we cover. If you’re itching for a high-tech UML tool, take a look at Chapter 23 where we list of some of the more useful examples (in all price categories).
How This Book Is Organized
Here’s your first practical hint about using UML: Put about five to nine major elements on a diagram — no more. Studies have shown (we’ve always wondered who does this type of study) that most people have a hard time comprehending more than about nine elements at a time. Likewise, when designing this book, we decided to follow our own advice and to divide the book into just seven parts.
Remember that you don’t have to read this book in order. Just choose the parts and chapters that you need at the time.
Part I: UML and System Development
If you want to know what UML is (and why knowing it is useful), this is the place to go; it covers the basics of UML and how it can be used. You’ll also find some common principles for communicating or developing systems with UML. These principles guided the UML gurus when they created UML; the same principles can guide you to effective use of it. Ways to apply these principles crop up throughout the book.
Part II: The Basics of Object Modeling
When you model by using UML, the basics are the things (or objects) that you draw and the relationships among them. You’ll find information on classes, objects, associations, inheritances, and generalizations. No matter what type of development you do, understanding this part will probably be essential.
Part III: The Basics of Use-Case Modeling
Use cases (detailed real-world examples) allow you to understand and communicate the purpose of a system or its components. They are great for organizing your thoughts — and your system — when you want to get a value-added product out the door.
Part IV: The Basics of Functional Modeling
When the objects in your system get busy and you want to explain the details of their complex behavior, you’ll need a technique to do so. UML supplies several to choose from — and this part explains and compares them. You’ll see several different types of interaction diagrams (such as sequence, communication, and activity) in action, and discover how to combine them to create solutions, patterns, and frameworks. If you’re experienced with UML, you’ll find lots of new UML 2 stuff in this part.
Part V: Dynamic Modeling
Your objects are more that just clumps of data stuck together with a few functions. The objects that you develop are more like living things; they remember the past and live their lives by changing their states in response to incoming events. In this part, you can make sure that they get a life — and that you know how to explain it. Come to this part for state charts.
Part VI: Modeling the System’s Architecture
Whether you’re an architect, programmer, or construction worker, you build complex architectures. Computer systems and software applications distribute themselves across different hardware platforms — and spread throughout the Internet. This part outlines steps that you can use to design your systems for their mission by using system plans, packaging, and subsystems.
Part VII: The Part of Tens
Everyone enjoys making lists (and daydreaming that they’ll be read aloud, backward, on late-night talk shows). Here are our top-ten lists of useful tips, tools, Web sites, and diagrams. They’re likely to be your top-tens, too.
Icons Used in This Book
Appropriately for a book about graphical communication (even if it is software-oriented), there are signposts throughout to help you find your way.
This icon identifies the really new stuff in UML 2. Not every modified feature will get this flag, but it does alert those who are familiar with UML 1.x that something’s really different here.
Here’s a simpler way of doing something that can make it easier than the typical approach. Think of it as a shortcut to better UML.
UML can be a maze — and it can be amazing. These are gentle reminders to reinforce important points.
If you see this icon but ignore it, you’ll be in good company but a bad mood.
When you see this icon, you know that we thought the associated material really interesting — but every time we tell people enthusiastically about it, they fall asleep. Skip these sections if you want.
Where to Go from Here
Okay, you’re now ready to explore the world of UML 2 modeling. Relax. You’ve got the tools that you need in your head and your hands (one of them is this book), and it’s safe to explore.
So, go ahead and express yourself with the power of UML 2.
Part I
UML and System Development
In this part . . .
Building systems or software isn’t that tough if you can communicate with your clients, co-workers, managers, and tools. Unfortunately, as your problems get harder and more complex, the risks that emerge from miscommunication become greater — and more severe when they do crop up.
Fortunately, there’s a straightforward, visual language that you can use that will help promote more precise and more efficient communication about the nature of your system in all its aspects — software, requirements, architectures, designs, design patterns, and implementations. This language is UML, the Unified Modeling Language. The newest version, UML 2, has become more powerful and more useful than ever.
Starting here, we cover the basics of UML. You find out how it may fit your situation, how and when you can use it, and what it’s good for. We give you just as much background in history, terminology, and basic principles as you’ll need to take advantage of UML’s highly productive features.
Chapter 1
What’s UML About, Alfie?
In This Chapter
Understanding the basics of UML
Exploring the whys and whens of UML diagrams
So you’ve been hearing a lot about UML, and your friends and colleagues are spending some of their time drawing pictures. And maybe you’re ready to start using UML but you want to know what it’s all about first. Well, it’s about a lot of things, such as better communication, higher productivity, and also about drawing pretty pictures. This chapter introduces you to the basics of UML and how it can help you.
Introducing UML
The first thing you need to know is what the initials UML stand for. Don’t laugh — lots of people get it wrong, and nothing brands you as a neophyte faster. It’s not the Universal Modeling Language, as it doesn’t intend to model everything (for example, it’s not very good for modeling the stock market; otherwise we’d be rich by now). It’s also not the Unified Marxist-Leninists, a Nepalese Political party (though we hope you’ll never get that confused). It is the University of Massachusetts Lowell — but not in this context. UML really stands for the Unified Modeling Language.
Well, maybe that’s not the most important thing to know. Probably just as important is that UML is a standardized modeling language consisting of an integrated set of diagrams, developed to help system and software developers accomplish the following tasks:
Specification
Visualization
Architecture design
Construction
Simulation and Testing
Documentation
UML was originally developed with the idea of promoting communication and productivity among the developers of object-oriented systems, but the readily apparent power of UML has caused it to make inroads into every type of system and software development.
Appreciating the Power of UML
UML satisfies an important need in software and system development. Modeling — especially modeling in a way that’s easily understood — allows the developer to concentrate on the big picture. It helps you see and solve the most important problems now, by preventing you from getting distracted by swarms of details that are better to suppress until later. When you model, you construct an abstraction of an existing real-world system (or of the system you’re envisioning), that allows you to ask questions of the model and get good answers — all this without the costs of developing the system first.
After you’re happy with your work, you can use your models to communicate with others. You may use your models to request constructive criticism and thus improve your work, to teach others, to direct team members’ work, or to garner praise and acclamation for your great ideas and pictures. Properly constructed diagrams and models are efficient communication techniques that don’t suffer the ambiguity of spoken English, and don’t overpower the viewer with overwhelming details.
Abstracting out the essential truth
The technique of making a model of your ideas or the world is a use of abstraction. For example, a map is a model of the world — it is not the world in miniature. It’s a conventional abstraction that takes a bit of training or practice to recognize how it tracks reality, but you can use this abstraction easily. Similarly, each UML diagram you draw has a relationship to your reality (or your intended reality), and that relationship between model and reality is learned and conventional. And the UML abstractions were developed as conventions to be learned and used easily.
If you think of UML as a map of the world you see — or of a possible world you want — you’re not far off. A closer analogy might be that of set of blueprints that show enough details of a building (in a standardized representation with lots of specialized symbols and conventions) to convey a clear idea of what the building is supposed to be.
The abstractions of models and diagrams are also useful because they suppress or expose detail as needed. This application of information hiding allows you to focus on the areas you need — and hide the areas you don’t. For example, you don’t want to show trees and cars and people on your map, because such a map would be cumbersome and not very useful. You have to suppress some detail to use it.
You’ll find the word elide often in texts on UML — every field has its own jargon. Rumor has it that elide is a favorite word of Grady Booch, one of the three methodologists responsible for the original development of UML. Elide literally means to omit, slur over, strike out, or eliminate. UML uses it to describe the ability of modelers (or their tools) to suppress or hide known information from a diagram to accomplish a goal (such as simplicity or repurposing).
Chapter 2 tells you more about using these concepts of information hiding and abstraction during development.
Selecting a point of view
UML modeling also supports multiple views of the same system. Just as you can have a political map, a relief map, a road map, and a utility map of the same area to use for different purposes — or different types of architectural diagrams and blueprints to emphasize different aspects of what you’re building — you can have many different types of UML diagrams, each of which is a different view that shows different aspects of your system.
UML also allows you to construct a diagram for a specialized view by limiting the diagram elements for a particular purpose at a particular time. For example, you can develop a class diagram — the elements of which are relevant things and their relationships to one another — to capture the analysis of the problem that you have to solve, to capture the design of your solution, or to capture the details of your implementation. Depending on your purpose, the relevant things chosen to be diagram elements would vary. During analysis, the elements that you include would be logical concepts from the problem and real world; during design, they would include elements of the design and architectural solution; and during implementation, they would primarily be software classes.
A use case diagram normally concentrates on showing the purposes of the system (use cases) and the users (actors). We call a use case diagram that has its individual use cases elided (hidden) a context diagram, because it shows the system in its environment (context) of surrounding systems and actors.
Choosing the Appropriate UML Diagram
UML has many diagrams — more, in fact, than you’ll probably need to know. There are at least 13 official diagrams (actually the sum varies every time we count it) and several semiofficial diagrams. Confusion can emerge because UML usually allows you to place elements from one diagram on another if the situation warrants. And the same diagram form, when used for a different purpose, could be considered a different diagram.
In Figure 1-1, we’ve constructed a UML class diagram that sums up all the major types of UML diagrams (along with their relationships), using the principle of generalization, which entails organizing items by similarities to keep the diagram compact. (See Chapter 2 for more information on generalization.)
In Figure 1-1, the triangular arrows point from one diagram type to a more general (or more abstract) diagram type. The lower diagram type is a kind-of or sort-of the higher diagram type. Thus a Class Diagram is a kind of Structural Diagram, which is a kind of Diagram. The diagram also uses a dashed arrow to indicate a dependency — some diagrams reuse the features of others and depend on their definition. For example, the Interaction Overview Diagram depends on (or is derived from) the Activity Diagram for much of its notation. To get a line on how you might use UML diagrams, check out the summary in Table 1-1.
Figure 1-1: A class diagram of UML diagrams.
Slicing and dicing UML diagrams
There are many ways of organizing the UML diagrams to help you understand how you may best use them. The diagram in Figure 1-1 uses the technique of organization by generalization (moving up a hierarchy of abstraction) and specialization (moving down the same hierarchy in the direction of concrete detail). (See Chapter 6 for more on generalization and specialization.) In Figure 1-1, each diagram is a subtype of (or special kind of) the diagram it points to. So — moving in the direction of increasing abstraction — you can consider a communication diagram from two distinct angles:
It’s a type of interaction diagram, which is a type of behavioral diagram, which is a type of diagram.
It’s derived from a composite structure diagram, which is a kind of structural diagram, which is a type of diagram.
After you get some practice at creating and shaping UML diagrams, it’s almost second nature to determine which of these perspectives best fits your purpose.
This general arrangement of diagrams that we used in our Figure 1-1 is essentially the same as the UML standard uses to explain and catalog UML diagrams — separating the diagrams into structural diagrams and behavioral diagrams. This is a useful broad categorization of the diagrams, and is reflected in the categorizations in Table 1-1:
Structural diagrams: You use structural diagrams to show the building blocks of your system — features that don’t change with time. These diagrams answer the question, What’s there?
Behavioral diagrams: You use behavioral diagrams to show how your system responds to requests or otherwise evolves over time.
Interaction diagrams: An interaction diagram is actually a type of behavioral diagram. You use interaction diagrams to depict the exchange of messages within a collaboration (a group of cooperating objects) en route to accomplishing its goal.
Because UML is very flexible, you’re likely to see various other ways of categorizing the diagrams. The following three categories are popular:
Static diagrams: These show the static features of the system. This category is similar to that of structural diagrams.
Dynamic diagrams: These show how your system evolves over time. This category covers the UML state-machine diagrams and timing diagrams.
Functional diagrams: These show the details of behaviors and algorithms — how your system accomplishes the behaviors requested of it. This category includes use-case, interaction, and activity diagrams.
You can employ UML diagrams to show different information at different times or for different purposes. There are many modeling frameworks, such as Zachman or DODAF (Department of Defense’s Architecture Framework) that help system developers organize and communicate different aspects of their system. A simple framework for organizing your ideas that is widely useful is the following approach to answering the standard questions about the system:
Who uses the system? Show the actors (the users of the system) on their use case diagrams (showing the purposes of the system).
What is the system made of? Draw class diagrams to show the logical structure and component diagrams to show the physical structure.
Where are the components located in the system? Indicate your plans for where your components will live and run on your deployment diagrams.
When do important events happen in the system? Show what causes your objects to react and do their work with state diagrams and interaction diagrams.
Why is this system doing the things it does? Identify the goals of the users of your system and capture them in use cases, the UML construct just for this purpose.
How is this system going to work? Show the parts on composite structure diagrams and use communication diagrams to show the interactions at a level sufficient for detailed design and implementation.
Automating with Model-Driven Architecture (MDA)
Model-driven architecture (MDA) is new way to develop highly automated systems. As UML tools become more powerful, they make automation a real possibility much earlier in the process of generating a system. The roles of designer and implementer start to converge. UML provides you with the keys to steer your systems and software development toward new horizons utilizing model-driven architectures.
In the past, after the designer decides what the system would look like — trading off the design approach qualities such as performance, reliability, stability, user-friendliness — the designer would hand the models off to the developer to implement. Much of that implementation is difficult, and often repetitious. As one part of an MDA approach to a project, UML articulates the designer’s choices in a way that can be directly input into system generation. The mechanical application of infrastructure, database, user interface, and middleware interfaces (such as COM, CORBA, .NET) can now be automated.
Because UML 2 works for high-level generalization or for showing brass-tacks detail, you can use it to help generate high-quality, nearly complete implementations (code, database, user-interface, and so on) from the models.
In MDA, the Development Team is responsible for analysis, requirements, architecture, and design, producing several models leading up to a complete, but Platform-Independent Model (PIM). Then UML and MDA tools can generate a Platform-Specific Model (PSM) based on the architecture chosen and (after some tweaking) produce the complete application.
This approach promises to free the development team from specific middleware or platform vendors. When a new architecture paradigm appears — and it will — the team can adopt it without going back to Square One for a complete redevelopment effort. The combination of UML and MDA also promises to free development teams from much of the coding work. Although the required UML models are much more specific than most organizations are used to, their use will change the way developers make systems.
With the advent of MDA and its allied technologies, UML becomes a sort of executable blueprint — the descriptions, instructions, and the code for your system in one package. Remember it all begins with UML.
Identifying Who Needs UML
Broadly speaking, UML users fall into three broad categories:
Modelers:Modelers try to describe the world as they see it — either the world as is, whether it’s a system, a domain, an application, or a world they imagine to come. If you want to document a particular aspect of some system, then you’re acting as a modeler — and UML is for you.
Designers:Designers try to explore possible solutions, to compare, to trade off different aspects, or to communicate approaches to garner (constructive) criticism. If you want to investigate a possible tactic or solution, then you’re acting as a designer — and UML is for you.
Implementers: Implementers construct solutions using UML as part of (or as the entire) implementation approach. Many UML tools can now generate definitions for classes or databases, as well as application code, user interfaces, or middleware calls. If you’re attempting to get your tool to understand your definitions, then you’re an Implementer — and (you guessed it) UML is for you.
To understand how you can benefit from UML, it will help to know how and why it was developed. It’s based on successful and working techniques proposed by groups of Software Technology Vendors before the Object Management Group, and voted upon by the members.
Dispelling Misconceptions about UML
Many developers have several misconceptions about UML. Perhaps you do too, but after reading this book, you’ll have the misconceptions dispelled:
UML is not proprietary. Perhaps UML was originally conceived by Rational Software, but now it’s owned by OMG, and is open to all. Many companies and individuals worked hard to produce UML 2. Good and useful information on UML is available from many sources (especially this book).
UML is not a process or method. UML encourages the use of modern object-oriented techniques and iterative life cycles. It is compatible with both predictive and agile control approaches. However, despite the similarity of names, there is no requirement to use any particular “Unified Process” — and (depending on your needs) you may find such stuff inappropriate anyway. Most organizations need extensive tailoring of existing methods before they can produce suitable approaches for their culture and problems.
UML is not difficult. UML is big, but you don’t need to use or understand it all. You are able to select the appropriate diagrams for you needs and the level of detail based on you target audience. You’ll need some training and this book (of course), but UML is easy to use in practice.
UML is not time-consuming. Properly used, UML cuts total development time and expenses as it decreases communication costs and increases understanding, productivity, and quality.
The evolution of UML
In the B.U. days (that’s Before UML), all was chaos, because object-oriented developers did not understand each other’s speech. There were over 50 different object-oriented graphical notations available (I actually counted), some of them even useful, some even had tool support. This confusion, interfered with adoption of object-oriented techniques, as companies and individuals were reluctant to invest in training or tools in such a confusing field.
Still the competition of ideas and symbols did cause things to improve. Some techniques were clearly more suited to the types of software problems that people were having. Methodologists started to adopt their competitors’ useful notation. Eventually some market leaders stood out.
In October 1994, Jim Rumbaugh of the Object Modeling Technique (OMT) and Grady Booch of the Booch Method started to work together on unifying their approach. Within a year, Ivar Jacobson (of the Objectory Method), joined the team. Together, these three leading methodologists joined forces at Rational Software, became known as the Three Amigos, and were the leading forces behind the original UML. Jim Rumbaugh was the contributor behind much of the analysis power of UML and most of its notational form. Grady Booch was the force behind the design detail capabilities of UML. Ivar Jacobson led the effort to make UML suitable for business modeling and tying system development to use cases.
The Three Amigos were faced with the enormous job of bringing order and consensus to the Babel of notation and needed input from the other leading methodologist about what works and what doesn’t. They enlisted the help of the Object Management Group (OMG), a consortium of over 800 companies dedicated to developing vendor-independent specifications for the software industry. OMG opened the development of UML to competitive proposals. After much debate, politics, and bargaining, a consensus on a set of notation selected from the best of the working notation used successfully in the field, was adopted by OMG in November 1997.
Since 1997, the UML Revision Task Force (RTF) of OMG — on which one of your authors (okay, it was Michael) served — has updated UML several times. Each revision tweaked the UML standard to improve internal consistency, to incorporate lessons learned from the UML users and tool vendors, or to make it compatible with ongoing standards efforts. However, it became clear by 2000 that new development environments (such as Java), development approaches (such as component-based development), and tool capabilities (such more complete code generation) were difficult to incor- porate into UML without a more systematic change to UML. This effort leads us to UML 2, which was approved in 2003.
Chapter 2
Following Best Practices
In This Chapter
Getting to know the object-oriented principles behind UML
Avoiding vendor hype
Interpreting the buzzwords
Ever notice how buzzwords seem to sprout like mushrooms whenever experts get their hands on something really useful? The object-oriented ideas that form the foundation of UML started in the 1970s and UML itself got going in 1994, so the experts had plenty of time to come up with complex terms — like abstraction, encapsulation, and aggregation — to confuse the rest of the world. The experts think you already know these terms. Luckily, the meaning behind these words is generally quite simple.
Various vendors have developed a host of rival tools to help you with UML. The experts also went into overdrive coming up with competing methodologies (steps for using UML). These tools and the methodologies are supposed to make you and me more productive. Of course the vendors and the experts assume you already know how to use their tools, understand the meaning of UML diagrams, and know all the buzzwords they’ve come up with in their marketing brochures. In this chapter we cover the terms and other details about UML that everyone assumes you already know.
Understanding UML Terminology and Concepts
Over the years (if you’re like most of us) you’ve learned the wisdom of such phrases as “say what you mean, mean what you say” and “get to the point.” You’ve probably found that your best communication with other people happens when you say what needs to be said, no more and no less. The experts use their own special words to describe this common-sense principle; Table 2-1 (which uses an air-filter air exchange unit as an example) interprets what they mean.
Abstracting away irrelevance
Ignoring unimportant details is a fundamental part of your life. Most of the time you are not even aware how much you take no notice of your surroundings. If you had to pay attention to everything around you all the time, you would have no time to do anything else. When you communicate your ideas about a system or the software you are developing, you ignore the trivial and focus on the important. The experts have a fancy word — abstraction — for this process of distilling the “important” information (needed for some clear purpose) out of the mass of surrounding details.
You use different degrees of abstraction at different times. For example, the picture of the air-filter unit in Figure 2-1 is an abstraction; this image is not the real air-filter unit. The picture describes the look of the unit without details such as color, physical dimensions, and actual size.
Sometimes you need different abstractions of the same thing. For example, the electrician may need to see a wiring diagram like the one in Figure 2-2. This diagram “abstracts away” everything about the air-filter unit except its electric circuitry — and even that isn’t what the actual wiring looks like. The symbols on the wiring diagram have special meanings; they indicate components or functions that would otherwise clutter up the diagram with distracting details. The symbol that looks like an upside-down triangle with three lines, for example, shows that the circuit is grounded at this point — exactly how that’s done isn’t important right now, and isn’t shown.
UML diagrams have symbols that act as a shorthand notation. These symbols allow you to show what’s important by using the principle of abstraction, just as a circuit diagram shows the electricians what’s important to them.
Figure 2-1: Picture represen-tation of an air- filter unit.
When you use UML to make models — in particular, objects and classes, which are discussed in detail in Chapter 3 — they make good abstractions of the physical world. A good model contains only the important aspects of an object, such as its identity, structure, behavior, and association with other objects. (Abstracting your real world objects — paring them down to the essentials — is also a great help when you map real-world stuff into object-oriented programs.)
Don’t let someone use UML to describe lots of irrelevant detail. Apply the principle of abstraction — ignore the irrelevant and model what is important to you and fellow developers.
Encapsulating and hiding information
To help you enforce an abstraction, the experts have a couple of other fancy terms:
Encapsulation: When you summarize important features of your objects in one place, you are encapsulating them — your objects can make good abstractions of the real world by combining features such as identity, attributes, and behavior into a neat package. Everything an object needs to be itself — structure, identity, internal behavior — is close together so the object can be itself (function the way it wants to). The operations (behavior) of an object are like a wall between its internal workings and those of other objects. The wall of operations places a barrier that helps the object maintain its separation from other objects, which helps enforce the abstraction.
These walls prevent your intended abstraction from being violated. You turn an air-filter unit on and off. You cannot break the encapsulation of that object and change its internals to create a TV that you can also turn on and off.
Information hiding: Hiding the details of how an object performs its job helps prevent overloading the user with irrelevant details. The advantage is that if you hide internal information about an object from its users, then you can tinker with that object without affecting the users.
Manufacturers of air-filter units try hard to hide how the unit works from the users of these devices. The assumption is that the user doesn’t have to know anything about the operation of the unit except how to turn it on and off. If the manufacturer changes the internal workings of the unit without changing its controls — and it performs the same function — then its users don’t have to retrain themselves to use a new unit.
Encapsulation and information hiding are used in many branches of technology. For example, computer users sometimes complain that PCs — even today — still require the user to master too much detailed knowledge. The users — all of us — still have to know a lot about the internal workings of the computer before we can change a setting or get it to do a simple task. All those details tend to get in the way of performing a job. From the user’s point of view, the PC builders haven’t done enough information hiding or encapsulation.
Figure 2-2: Electric circuit represen- tation of an air- filter unit.
You use encapsulation and information hiding together when developing object-oriented systems and software. By hiding an object’s structure and internal methods of behavior behind a wall of operations, you enforce your abstraction and — in effect — help keep the object intact.
Don’t make the structure of your objects public. Doing so breaks the principle of encapsulation and information hiding. For openers, public attributes often attract tinkerers who make unauthorized modifications, and that makes your job of enforcing an abstraction difficult.
A little information hiding goes a long way
During the 1990s, software developers were obsessed with Y2K — the fear that software programs worldwide would be disrupted when the year changed from 1999 to 2000. The problem boiled down to a lack of (you guessed it) encapsulation and information hiding. Two digits were customarily used to represent the year attribute of a date: 98 for 1998, 99 for 1999, and 00 for — what? 1900 or 2000? Programs that needed accurate dates to function properly relied on those unencapsulated two-digit year attributes — big trouble. Companies and governments around the world spent in excess of $200 billion to solve the problem.
Now, suppose those dates were encapsulated into a date object and the year representation was hidden inside the date object. The software developers could have changed the internal representation of year from two to four digits and added a wall of behavior that would, if asked, provide the date with either two- or four-digit years. When a software developer needed to see whether one date preceded another, the developer would ask two date objects to compare themselves through a simple compare operation. If early software developers had encapsulated all dates in the first place — and hidden the representation of year — then the Y2K scare would have never happened.
Separating the whole from its parts
Aggregation is, in effect, pulling together the parts of an object to make up the actual object. For example, when we say “air-filter unit” we’re talking about a whole object that hides many other objects that we call its parts. The fan, motor, filter, switch, and wires are the internal objects/parts of an air-filter unit. You aggregate the hidden parts to form the whole air-filter unit.
You use aggregation to hide the internal parts of a complex object from the outside world. Aggregation is a form of encapsulation and information hiding. The whole or aggregate object hides many complex internal objects or parts.
If an object is especially complex, you can ignore its internals by focusing on relationships between the whole object and other external objects. We don’t have to talk about the internal parts of an air-filter unit to tell you how to use it. We communicate the relationships between you, the air-filter unit, and the air that gets cleaned and moved throughout the room. In my communication with you we tell you just what you need to know.
If you must maintain the air-filter unit by replacing the filter, we tell you about that specific internal part of the unit. Nobody has to yak on and on about the unit’s relationship with air, the room, and the user. Again, we tell you only what you (as maintainer) need to know.
Whenever you need to hide the internal parts of an object, use UML aggregation notation to isolate the internal complexity of a whole object from outside interactions with other objects.
Composition is another word for a strong form of aggregation. The experts needed a different word to help distinguish between two different situations:
Composition: When the parts of an object are completely bound up in the life of the whole object, the whole object is composed of them. If you take a whole air-filter unit and crush it (end the life of the whole thing), then all its parts are crushed too (the life of each part is bound to the life of the whole).
Aggregation: Some parts of a whole object exist beyond the life of the whole. For example, a subsidiary of a holding company is part of the whole company. However, if the holding company were to go bankrupt and cease to exist, the subsidiary’s life would continue as a standalone company. The relationship between the subsidiary and the holding company is simple aggregation, not composition.
You manage complexity by hiding it. Suppose we build a black box and tell you how to hook up to the black box. If all you worry about is the hook up to the box and not the insides of the black box, then we have successfully hidden any complexity from you. UML classes hide complexity by forcing you to use their public operations (publicly accessible behavior). UML components with internal parts hide complexity by forcing you to use their public interfaces.
Generalizing and specializing
Like most people, UML experts prefer not to repeat themselves when communicating with others. They follow the principle of saying something once. When you hear the following words this is what they mean:
Generalization: You look at a group of objects, extract the features they have in common — their attributes (structure) and their operations (behavior) — and use those features to define a generic classof objects. That way, you refer to these common features whenever you mention the class — and you only have to do so once.
Specialization: Specialization is the opposite of generalization. To specialize a group of objects, you look at a group of objects and identify groups of objects with unique features not shared with other groups of objects. Then, you create a class for each group of objects with their own unique features.
The same is true of any object — especially of any machine. There are lots of different kinds of air-filter units, from no-frills to fancy. Figure 2-3 shows the type of air-filter unit you see above a stove. A more elaborate, whiz-bang air-filter unit, bristling with gizmos, is shown in Figure 2-4. These units share common features — internal fan, On/Off switch, replaceable air filter — that you can find in various types of filter units. When you consider all possible filter units that have these basic features, you’re generalizing.
To help you see the spaghetti sauce you’re cooking, the stovetop unit in Figure 2-3 has a light to illuminate the cooking surface below. None of the other air-filter units have this, so stovetop air-filter units make up a more specific class of objects.
The fancy unit in Figure 2-4 has an ultraviolet light and a motion sensor. Since we’ve already included it in the general class of air-filter units, we can assume that it also has an On/Off switch, an internal fan, and an internal filter — even though there’s no stovetop light.
Inheriting features and performing the same behaviors differently
Okay, air filters in general have the features common to all air filters — so when we speak of a particular air-filter unit, we can focus on its specific features. By doing so, we assume you already understand that the unit has the features listed in the generic description. We’re “reusing” the generic features that all air-filter units have in common.
Figure 2-3: This stove-top air-filter unit has a light so you find the oregano.
This leads us to two more terms that the experts use to confuse us:
Inheritance: You notice that when we talk about a specific kind of air-filter unit, we assume you understand that the specific unit has the same features of any generic air-filter unit. The experts like to say the specific object inherits the features of the generic object.
Through the principle of inheritance, you “reuse” the features of a generic object when talking about or modeling specific objects.
Polymorphism: Of course, everybody studies classical Greek these days, right? So here it is again — poly meaning many, and morph meaning form. It’s when objects have the same behavior but perform it differently. For example, all air-filter units can perform the operation of turning on — but each type of unit performs that operation differently.
In this example, you notice there is a difference between the operation of the object and the method the object uses to perform the operation. In the object-oriented world, objects invoke the operations (behavior) of another object. The second object then performs some internal method (steps in a process) as a result. When you (the first object) invoke the operation of turning on the air filter unit (the second object), the air filter unit performs an internal method (it passes electricity through a switch to the fan).
The idea of polymorphism is to hide the exact method of operation behind the operation itself. You invoke the operation of an object without worrying about how the operation is performed. So when you step up to an air-filter unit, you just turn it on. The method inside the unit does the rest.
Figure 2-4: Air-filter unit with ultraviolet light. (Do dust motes glow in the dark?)
When you use UML to describe general and specific objects, use the Principle of Least Surprise. You place an attribute or an operation in whatever class — generalized class or specialized class — is least likely to surprise the user.
