Learning Uml 2.0 Pdf Download

O'Reilly - Learning UML 2.0

Documento: pdf (409 páginas) 10.0 MB

Publicado: 2019-05-13

O'Reilly - Learning UML 2.0 Learning UML 2.0 By Kim Hamilton, Russell Miles ............................................... Publisher: O'Reilly Pub Date: April 2006 Print ISBN-10: 0-596-00982-8 Print ISBN-13: 978-0-59-600982-3 Pages: 286 Table of Contents | Index "Since its original introduction in 1997, the Unified Modeling Language has revolutionized software development. Every integrated software development environment in the world--open- source, standards-based, and proprietary--now supports UML and, more importantly, the model- driven approach to software development. This makes learning the newest UML standard, UML 2.0, critical for all software developers--and there isn't a better choice than this clear, step-by- step guide to learning the language." --Richard Mark Soley, Chairman and CEO, OMG If you're like most software developers, you're building systems that are increasingly complex. Whether you're creating a desktop application or an enterprise system, complexity is the big hairy monster you must manage. The Unified Modeling Language (UML) helps you manage this complexity. Whether you're looking to use UML as a blueprint language, a sketch tool, or as a programming language, this book will give you the need-to-know information on how to apply UML to your project. While there are plenty of books available that describe UML, Learning UML 2.0 will show you how to use it. Topics covered include: Capturing your system's requirements in your model to help you ensure that your designs meet your users' needs Modeling the parts of your system and their relationships Modeling how the parts of your system work together to meet your system's requirements Modeling how your system moves into the real world, capturing how your system will be deployed Engaging and accessible, this book shows you how to use UML to craft and communicate your project's design. Russ Miles and Kim Hamilton have written a pragmatic introduction to UML based on hard-earned practice, not theory. Regardless of the software process or methodology you use, this book is the one source you need to get up and running with UML 2.0. Additional information including exercises can be found at www.learninguml2.com. Russ Miles is a software engineer for General Dynamics UK, where he works with Java and Distributed Systems, although his passion at the moment is Aspect Orientation and, in particular, AspectJ. Kim Hamilton is a senior software engineer at Northrop Grumman, where she's designed and implemented a variety of systems including web applications and distributed systems, with frequent detours into algorithms development. Learning UML 2.0 By Kim Hamilton, Russell Miles ............................................... Publisher: O'Reilly Pub Date: April 2006 Print ISBN-10: 0-596-00982-8 Print ISBN-13: 978-0-59-600982-3 Pages: 286 Table of Contents | Index Copyright Preface Chapter 1. Introduction Section 1.1. What's in a Modeling Language? Section 1.2. Why UML 2.0? Section1.3. ModelsandDiagrams Section 1.4. "Degrees" of UML Section 1.5. UML and the Software Development Process Section 1.6. Views of Your Model Section 1.7. A First Taste of UML Section 1.8. Want More Information? Chapter2. ModelingRequirements:UseCases Section2.1. CapturingaSystemRequirement Section2.2. UseCaseRelationships Section2.3. UseCaseOverviewDiagrams Section 2.4. What's Next? Chapter3. ModelingSystemWorkflows:ActivityDiagrams Section3.1. ActivityDiagramEssentials Section 3.2. Activities and Actions Section3.3. DecisionsandMerges Section 3.4. Doing Multiple Tasks at the Same Time Section 3.5. Time Events Section3.6. CallingOtherActivities Section3.7. Objects Section 3.8. Sending and Receiving Signals Section 3.9. Starting an Activity Section 3.10. Ending Activities and Flows Section3.11. Partitions(orSwimlanes) Section3.12. ManagingComplexActivityDiagrams Section 3.13. What's Next? Chapter 4. Modeling a System's Logical Structure: Introducing Classes and Class Diagrams Section 4.1. What Is a Class? Section 4.2. Getting Started with Classes in UML Section4.3. Visibility Section4.4. ClassState:Attributes Section4.5. ClassBehavior:Operations Section 4.6. Static Parts of Your Classes Section 4.7. What's Next Chapter 5. Modeling a System's Logical Structure: Advanced Class Diagrams Section5.1. ClassRelationships Section5.2. Constraints Section5.3. AbstractClasses Section5.4. Interfaces Section5.5. Templates Section 5.6. What's Next Chapter 6. Bringing Your Classes to Life: Object Diagrams Section6.1. ObjectInstances Section6.2. Links Section6.3. BindingClassTemplates Section 6.4. What's Next? Chapter7. ModelingOrderedInteractions:SequenceDiagrams Section7.1. ParticipantsinaSequenceDiagram Section7.2. Time Section 7.3. Events, Signals, and Messages Section7.4. ActivationBars Section7.5. NestedMessages Section7.6. MessageArrows Section 7.7. Bringing a Use Case to Life with a Sequence Diagram Section7.8. ManagingComplexInteractionswithSequenceFragments Section 7.9. What's Next? Chapter8. FocusingonInteractionLinks:CommunicationDiagrams Section8.1. Participants,Links,andMessages Section8.2. FleshingoutanInteractionwithaCommunicationDiagram Section8.3. CommunicationDiagramsVersusSequenceDiagrams Section 8.4. What's Next? Chapter 9. Focusing on Interaction Timing: Timing Diagrams Section 9.1. What Do Timing Diagrams Look Like? Section9.2. BuildingaTimingDiagramfromaSequenceDiagram Section9.3. ApplyingParticipantstoaTimingDiagram Section9.4. States Section9.5. Time Section9.6. AParticipant'sState-Line Section 9.7. Events and Messages Section9.8. TimingConstraints Section9.9. OrganizingParticipantsonaTimingDiagram Section9.10. AnAlternateNotation Section 9.11. What's Next? Chapter10. CompletingtheInteractionPicture:InteractionOverviewDiagrams Section 10.1. The Parts of an Interaction Overview Diagram Section 10.2. Modeling a Use Case Using an Interaction Overview Section 10.3. What's Next? Chapter11. ModelingaClass'sInternalStructure:CompositeStructures Section11.1. InternalStructure Section 11.2. Showing How a Class Is Used Section11.3. ShowingPatternswithCollaborations Section 11.4. What's Next? Chapter 12. Managing and Reusing Your System's Parts: Component Diagrams Section 12.1. What Is a Component? Section 12.2. A Basic Component in UML Section12.3. ProvidedandRequiredInterfacesofaComponent Section12.4. ShowingComponentsWorkingTogether Section 12.5. Classes That Realize a Component Section 12.6. Ports and Internal Structure Section12.7. Black-BoxandWhite-BoxComponentViews Section 12.8. What's Next? Chapter13. OrganizingYourModel:Packages Section13.1. Packages Section 13.2. Namespaces and Classes Referring to Each Other Section13.3. ElementVisibility Section13.4. PackageDependency Section13.5. ImportingandAccessingPackages Section13.6. ManagingPackageDependencies Section 13.7. Using Packages to Organize Use Cases Section 13.8. What's Next? Chapter 14. Modeling an Object's State: State Machine Diagrams Section14.1. Essentials Section14.2. States Section14.3. Transitions Section14.4. StatesinSoftware Section14.5. AdvancedStateBehavior Section14.6. CompositeStates Section14.7. AdvancedPseudostates Section14.8. Signals Section14.9. ProtocolStateMachines Section 14.10. What's Next? Chapter15. ModelingYourDeployedSystem:DeploymentDiagrams Section15.1. DeployingaSimpleSystem Section15.2. DeployedSoftware:Artifacts Section 15.3. What Is a Node? Section15.4. HardwareandExecutionEnvironmentNodes Section15.5. CommunicationBetweenNodes Section15.6. DeploymentSpecifications Section 15.7. When to Use a Deployment Diagram Section 15.8. What's Next? AppendixA. ObjectConstraintLanguage SectionA.1. BuildingOCLExpressions SectionA.2. Types SectionA.3. Operators SectionA.4. PullingItTogether SectionA.5. Context Section A.6. Types of Constraints SectionA.7. OCLAutomation Appendix B. Adapting UML: Profiles Section B.1. What Is a Profile? SectionB.2. Stereotypes SectionB.3. TaggedValues SectionB.4. Constraints Section B.5. Creating a Profile Section B.6. Working with the Meta-Model Section B.7. Using a Profile Section B.8. Why Bother with Profiles? Appendix C. A History of UML Section C.1. Take One Part OOAD... Section C.2. ...with a Sprinkling of OOSE... Section C.3. ...Add a Dash of OMT... Section C.4. ...and Bake for 10 to 15 Years AbouttheAuthors Colophon Index Learning UML 2.0 by Russ Miles and Kim Hamilton Copyright © 2006 O'Reilly Media, Inc. All rights reserved. Printed in the United States of America. Published by O'Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O'Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (safari.oreilly.com). For more information, contact our corporate/institutional sales department: (800) 998-9938 or corporate@oreilly.com. Editors: Brett McLaughlin and Mary T. O'Brien Production Editor: Laurel R.T. Ruma Copyeditor: Laurel R.T. Ruma Proofreader: Reba Libby Indexer: Angela Howard Cover Designer: Karen Montgomery Interior Designer: David Futato Cover Illustrator: Karen Montgomery Illustrators: Robert Romano, Jessamyn Read, and Lesley Borash Printing History: April 2006: First Edition. Nutshell Handbook, the Nutshell Handbook logo, and the O'Reilly logo are registered trademarks of O'Reilly Media, Inc. Learning UML 2.0, the image of a gorilla, and related trade dress are trademarks of O'Reilly Media, Inc. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O'Reilly Media, Inc. was aware of a trademark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this book, the publisher and authors assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein. ISBN: 0-596-00982-8 [M] Preface The Unified Modeling Language (UML) is the standard way to model systems, particularly software systems. If you are working on a system beyond "Hello, World," then having UML in your toolbox of skills is a must, and that's where Learning UML 2.0 comes in. Learning UML 2.0 is about coming to grips with UML quickly, easily, and practically. Along with a thorough set of tutorials on each of the different UML diagram types, this book gives you the tools to use UML effectively when designing, implementing, and deploying systems. The topics covered include: A brief overview of why it is helpful to model systems How to capture high-level requirements in your model to help ensure the system meets users' needs How to model the parts that make up your system How to model the behavior and interactions between parts when the system is running How to move from the model into the real world by capturing how your system is deployed How to create custom UML profiles to accurately model different system domains Audience Learning UML 2.0 is for anyone interested in learning about UML, but it is helpful to have some exposure to object-oriented (OO) design and some familiarity with Java. However, even if you have only a small amount of experience with object orientation, Learning UML 2.0 will improve and extend your knowledge of OO concepts and give you a comprehensive set of tools to work with UML. Although this book is intended to take you through each subject on the path to learning UML, some UML modeling subjects, such as use cases and activity diagrams, are self-explanatory, which means you can dive right into them. About This Book Learning UML 2.0 aims to answer the "what," "how," and "why should I care?" for every aspect of UML. Each chapter picks one subject from UML and explains it based on these questions. Since not everyone is new to UML, there are two main routes through this book. If you're new to UML as a subject and want to get an overview of where the modeling language came from, then you should start with Chapter 1. However, if you want to get your hands dirty as quickly as possible, then you can either skip the introduction chapter to delve directly into use cases or jump to the chapter that describes the UML diagram in which you are most interested. Now you know what Learning UML 2.0 is about, it should be explained what this book is not about. This book is not about any one particular modeling tool or implementation language. However, some tools have their own way of doing things, and some implementation languages do not support everything you can legally model in UML. Wherever appropriate, we have tried to point out where UML tools or implementation languages deviate from or follow the UML standard. Lastly, because of the large variation in software development processes, this book is not about any particular process or methodology. Instead, it focuses on modeling and provides guidelines about appropriate levels of modeling that can be applied in the context of your software development process. Since this book adheres to the UML 2.0 standard, it works alongside any process or methodology you use. Assumptions This Book Makes The following general assumptions are made as to the reader's knowledge and experience: An understanding of object orientation Knowledge of the Java? language for some of the examples Conventions Used in This Book The following typographical conventions are used in this book: Italic Indicates new terms, URLs, email addresses, filenames, file extensions, pathnames, directories, and Unix utilities. Constant width Indicates commands, options, switches, variables, attributes, keys, functions, types, classes, namespaces, methods, modules, properties, parameters, values, objects, events, event handlers, XML tags, HTML tags, macros, the contents of files, or the output from commands. Constant width bold Shows commands or other text that should be typed literally by the user. Constant width italic Shows text that should be replaced with user-supplied values. This icon signifies a tip, suggestion, or general note. This icon indicates a warning or caution. Using Code Examples This book is here to help you get your job done. In general, you may use the code in this book in your programs and documentation. You do not need to contact us for permission unless you're reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing a CD-ROM of examples from O'Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product's documentation does require permission. We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: "Learning UML 2.0, by Russ Miles and Kim Hamilton. Copyright 2006 O'Reilly Media, Inc., 0-596-00982-8." If you feel your use of code examples falls outside fair use or the permission given above, feel free to contact us at permissions@oreilly.com. Safari® Enabled When you see a Safari® Enabled icon on the cover of your favorite technology book, that means the book is available online through the O'Reilly Network Safari Bookshelf. Safari offers a solution that's better than e-books. It's a virtual library that lets you easily search thousands of top tech books, cut and paste code samples, download chapters, and find quick answers when you need the most accurate, current information. Try it for free at http://safari.oreilly.com. How to Contact Us Everything has been done to ensure that the examples within this book are accurate, tested, and verified to the best of the authors' ability. However, even though UML is a standard modeling language, the best practices as to its usage may change with time and this may have an impact on this book's contents. If so, please address comments and questions concerning this book to the publisher: O'Reilly Media, Inc. 1005 Gravenstein Highway North Sebastopol, CA 95472 (800) 998-9938 (in the United States or Canada) (707) 829-0515 (international or local) (707) 829-0104 (fax) There is a web page for this book where you can find errata, examples, and any additional information. You can access this page at: http://www.oreilly.com/catalog/learnuml2 To comment or ask technical questions about this book, email: bookquestions@oreilly.com For more information about our books, conferences, Resource Centers, and the O'Reilly Network, see our web site: http://www.oreilly.com Additional information about this topic, including exercises, can be found at: http://www.learninguml2.com Acknowledgments From the Authors Thanks to Brett and Mary, our ace editors. We are indebted to Brett for providing valuable guidance throughout, and to Mary for her UML expertise, her amazing work bringing this book to completion, and her ability to line up an outstanding team of reviewers. We'd also like to thank all the kind individuals who put in the hours to provide such excellent technical feedback on this book. Thanks to Ed Chou, Glen Ford, Stephen Mellor, Eric Naiburg, Adewale Oshineye, Dan Pilone and Neil Pitman, and Richard Mark Soley (the history of UML would not have been nearly as interesting without your help). From Russ Miles First and foremost, my thanks go to my family and friends: Mum, Dad, Bobbie, Rich, Ad, Corinne (thanks for all your help through the last hectic stages, you're one in a million!), Martin and Sam, Jason and Kerry, and Aimee (wonder dog!). You are always there for me 100 percent and, as a bonus, have the uncanny but very useful ability to get me away from the Mac once in a while when I really need it. I'd also like to take this opportunity to thank my uncle, Bruce Sargent. You got me started on the first steps in this career and for that I am, and always will be, very grateful! I'd like to thank all my proofreaders, including Rob Wilson, Laura Paterson, and Grant Tarrant- Fisher. You've been great proofreaders, tech reviewers and, most of all, friends. With your comments this a much better book than anything I could have put together on my own. Also, a special thanks to Rachel "Kong" Stevens for being the unwitting inspiration for the front coverwe love ya! A big thanks must go to M. David Peterson (http://www.xsltblog.com) and Sylvain Hellegouarch (http://www.defuze.org) for all their help and inspiration with the CMS example that is used throughout this book. You're both top bloggers, developers, and friends and I want to say thanks to you and all the LLUP hackers (http://www.x2x2x.org/projects/wiki) for making my coding life that much more interesting, cheers! Last, but not leastwith what is quickly becoming a standard catch-allthanks to everyone who has helped me out while writing this book. I haven't forgotten your help and I know I owe you all a beer or two! From Kim Hamilton Thanks again to Ed Chou for his gaming expertise that helped create the FPS example (among his many other excellent contributions!) and for the long hours spent reviewing this book at every phase. A big thanks goes to my reviewers: Frank Chiu, Albert Chu, Yu-Li Lin, Justin Lomheim, Samarth Pal, Leland So, and Delson Ting. You were great at everythingfrom providing technical feedback to pointing out the humor in the word OMG. Thanks to John Arcos, Ben Faul, Mike Klug, Dwight Yorke, and Paul Yuenger, whose support helped me get this book out the door. Also, thanks to Thomas Chen for his CMS help! Most of all, thanks to my wonderful family and friendsMom, Dad, Ron, Mark, Grandma and Ed, Grandpa (in loving memory), Aunt Gene, Anne Marie, Kim, Ed C, Sokun, and Tienwho have all been so supportive this past year. Special thanks to my Mom and Dad: my Mom keeps me going with her love, friendship, and phone calls; and my Dad has always been my number one technical mentor. Chapter 1. Introduction The Unified Modeling Language (UML) is the standard modeling language for software and systems development. This statement alone is a pretty conclusive argument for making UML part of your software repertoire, however it leaves some questions unanswered. Why is UML unified? What can be modeled? How is UML a language? And, probably most importantly, why should you care? Systems design on any reasonably large scale is difficult. Anything from a simple desktop application to a full multi-tier enterprise scale system can be made up of hundredsand potentially thousandsof software and hardware components. How do you (and your team) keep track of which components are needed, what their jobs are, and how they meet your customers' requirements? Furthermore, how do you share your design with your colleagues to ensure the pieces work together? There are just too many details that can be misinterpreted or forgotten when developing a complex system without some help. This is where modelingand of course UMLcomes in. In systems design, you model for one important reason: to manage complexity. Modeling helps you see the forest for the trees, allowing you to focus on, capture, document, and communicate the important aspects of your system's design. A model is an abstraction of the real thing. When you model a system, you abstract away any details that are irrelevant or potentially confusing. Your model is a simplification of the real system, so it allows the design and viability of a system to be understood, evaluated, and criticized quicker than if you had to dig through the actual system itself. Even better, with a formal modeling language, the language is abstract yet just as precise as a programming language. This precision allows a language to be machine-readable, so it can be interpreted, executed, and transformed between systems. To effectively model a system, you need one very important thing: a language with which the model can be described. And here's where UML comes in. 1.1. What's in a Modeling Language? A modeling language can be made up of pseudo-code, actual code, pictures, diagrams, or long passages of description; in fact, it's pretty much anything that helps you describe your system. The elements that make up a modeling language are called its notation . Figure 1-1 shows an example of a piece of UML notation. Figure 1-1. A class declaration as it can be shown using UML notation There are references to the UML meta-model and profiles throughout this book. A more complete description of what the UML meta-model contains and why it is useful is available in Appendix B , but for now, just think of the UML meta-model as the description of what each element of notation means and a profile as a customization of that description for a specific domain (i.e., banking). However, notation is not the whole story. Without being told that one of the boxes in Figure 1-1 represents a class, you wouldn't necessarily know what it is, even though you might be able to guess. The descriptions of what the notation means are called the semantics of the language and are captured in a language's meta-model. A modeling language can be anything that contains a notation (a way of expressing the model) and a description of what that notation means (a meta-model). But why should you consider using UML when there are so many different ways of modeling, including many you could make up on your own? Every approach to modeling has different advantages and disadvantages, but UML has six main advantages: It's a formal language Each element of the language has a strongly defined meaning, so you can be confident that when you model a particular facet of your system it will not be misunderstood. It's concise The entire language is made up of simple and straightforward notation. It's comprehensive It describes all important aspects of a system. It's scaleable Where needed, the language is formal enough to handle massive system modeling projects, but it also scales down to small projects, avoiding overkill. It's built on lessons learned UML is the culmination of best practices in the object-oriented community during the past 15 years. It's the standard UML is controlled by an open standards group with active contributions from a worldwide group of vendors and academics, which fends off "vendor lock-in." The standard ensures UML's transformability and interoperability, which means you aren't tied to a particular product. 1.1.1. Detail Overload: Modeling with Code Software code is an example of a potential modeling language where none of the detail has been abstracted away. Every line of code is the detail of how your software is intended to work. Example 1-1 shows a very simple class in Java, yet there are many details in this declaration. Example 1-1. Even in a simple Java class, there can be a lot of detail to navigate through package org.oreilly.learningUML2.ch01.codemodel; public class Guitarist extends Person implements MusicPlayer { Guitar favoriteGuitar; public Guitarist (String name) { super(name); } // A couple of local methods for accessing the class's properties public void setInstrument(Instrument instrument) { if (instrument instanceof Guitar) { this.favoriteGuitar = (Guitar) instrument; } else { System.out.println("I'm not playing that thing!"); } } public Instrument getInstrument( ) { return this.favoriteGuitar; } // Better implement this method as MusicPlayer requires it public void play( ) { System.out.println(super.getName( ) + "is going to do play the guitar now ..."); if (this.favoriteGuitar != null) { for (int strum = 1; strum < 500; strum++) { this.favoriteGuitar.strum( ); } System.out.println("Phew! Finished all that hard playing"); } else { System.out.println("You haven't given me a guitar yet!"); } } // I'm a main program so need to implement this as well public static void main(String[] args) { MusicPlayer player = new Guitarist("Russ"); player.setInstrument(new Guitar("Burns Brian May Signature")); player.play( ); } } Example 1-1 shows all of the information about the Guitar class, including inheritance relationships to other classes, member variables involving other classes, and even implementation details for the methods themselves. What's wrong with using software source code as your model? All of the details are there, every element of the language's notation has meaning to the compiler, and with some effective code-level comments, such as JavaDoc, you have an accurate representation of your software system, don't you? The truth is that you haven't actually modeled anything other than the software implementation. The source code focuses only on the software itself and ignores the rest of the system. Even though the code is a complete and (generally) unambiguous definition of what the software will do, the source code alone simply cannot tell you how the software is to be used and by whom, nor how it is to be deployed; the bigger picture is missing entirely if all you have is the source code. As well as ignoring the bigger picture of your system, software code presents a problem in that you need to use other techniques to explain your system to other people. You have to understand code to read code, but source code is the language for software developers and is not for other stakeholders, such as customers and system designers. Those people will want to focus just on requirements or perhaps see how the components of your system work together to fulfill those requirements. Because source code is buried in the details of how the software works, it cannot provide the higher level abstract views of your system that are suitable for these types of stakeholders. Now imagine that you have implemented your system using a variety of software languages. The problem just gets worse. It is simply impractical to ask all the stakeholders in your system to learn each of these implementation languages before they can understand your system. Finally, if your design is modeled as code, you also lose out when it comes to reuse because design is often reusable whereas code may not be. For example, reimplementing a Java Swing application in HTML or .NET is much simpler if the design is modeled rather than reverse engineering the code. (Reverse engineering is extracting the design of a system from its implementation.) All of these problems boil down to the fact that source code provides only one level of abstraction: the software implementation level. Unfortunately, this root problem makes software source code a poor modeling language. 1.1.2. Verbosity, Ambiguity, Confusion: Modeling with Informal Languages At the opposite end of the spectrum from complete and precise source code models are informal languages. Informal languages do not have a formally defined notation; there are no hard and fast rules as to what a particular notation can mean, although sometimes there are guidelines. A good example of an informal language is natural language. Natural languagethe language that you're reading in this bookis notoriously ambiguous in its meaning. To accurately express something so that everyone understands what you are saying is at best a challenge and at worst flat-out impossible. Natural language is flexible and verbose, which happens to be great for conversation but is a real problem when it comes to systems modeling. The following is a slightly exaggerated but technically accurate natural language model of Example 1-1 : Guitarist is a class that contains six members: one static and five non-static. Guitarist uses, and so needs an instance of, Guitar ; however, since this might be shared with other classes in its package, the Guitar instance variable, called favoriteGuitar , is declared as default . Five of the members within Guitarist are methods. Four are not static. One of these methods is a constructor that takes one argument, and instances of String are called name , which removes the default constructor. Three regular methods are then provided. The first ...