EVALUATION COPY. The Unified Modeling Language. Unauthorized reproduction or distribution is prohibited. Student Workbook

Transcription

1 The Unified Modeling Language Student Workbook

2 The Unified Modeling Language The Unified Modeling Language Lynwood Wilson Published by ITCourseware, LLC., 7245 South Havana Street, Suite 100, Centennial, CO Contributing Authors: Jamie Romero, Rick Sussenbach, and Rob Seitz. Editors: Danielle Hopkins and Jan Waleri Editorial Assistant: Dana Howell Special thanks to: Many instructors whose ideas and careful review have contributed to the quality of this workbook, offering comments, suggestions, criticisms, and insights. Copyright 2013 by ITCourseware, LLC. All rights reserved. No part of this book may be reproduced or utilized in any form or by any means, electronic or mechanical, including photo-copying, recording, or by an information storage retrieval system, without permission in writing from the publisher. Inquiries should be addressed to ITCourseware, LLC., 7245 South Havana Street, Suite 100, Centennial, Colorado, (303) All brand names, product names, trademarks, and registered trademarks are the property of their respective owners. Page ii Rev ITCourseware, LLC

3 The Unified Modeling Language Contents Chapter 1 - Course Introduction... 7 Course Objectives... 8 The Unified Process... 9 Course Overview Using the Workbook Suggested References Chapter 2 - Use Cases Use Cases Use Case Diagram Components Use Case Diagram Actor Generalizations Include Extend Specialize Other Systems Narrative Template for Use Case Narrative Using Use Cases Labs Chapter 3 - Class Diagrams Class Diagrams Attributes Attribute Properties Operations and Methods Inheritance Abstract Classes Interfaces Interfaces with Ball and Socket Notation Visibility Class Scope ITCourseware, LLC Rev Page iii

4 The Unified Modeling Language Labs Chapter 4 - Class Diagrams and Relationships Dependencies Associations Instance Creation Multiplicity Qualified Associations Association Classes Composition and Aggregation Labs Chapter 5 - Sequence Diagrams Sequence Diagrams Interaction Frames Decisions Loops Creating and Destroying Objects Activation Synchronous & Asynchronous Evaluating Sequence Diagrams Using Sequence Diagrams Labs Chapter 6 - Communication Diagrams Communication Diagrams Communication and Class Diagrams Evaluating Communication Diagrams Using Communication Diagrams Labs Chapter 7 - State Machine Diagrams What is State? State Notation Transitions and Guards Registers and Actions More Actions Page iv Rev ITCourseware, LLC

5 The Unified Modeling Language Internal Transitions Superstates and Substates Concurrent States Using State Machines Implementation Labs Chapter 8 - Activity Diagrams Activity Notation Decisions and Merges Forks and Joins Drilling Down Iteration Partitions Signals Parameters and Pins Expansion Regions Using Activity Diagrams Labs Chapter 9 - Supplemental UML Diagrams Modeling Groups of Elements - Package Diagrams Visibility and Importing Structural Diagrams Components and Interfaces Deployment Diagram Composite Structure Diagrams Timing Diagrams Interaction Overview Diagrams Labs Appendix A - UML Syntax Solutions Index ITCourseware, LLC Rev Page v

6 The Unified Modeling Language Page vi Rev ITCourseware, LLC

7 Chapter 1 Course Introduction Chapter 1 - Course Introduction 2013 ITCourseware, LLC Rev Page 7

8 THe Unified Modeling Language Course Objectives Use modeling in analysis and design, particularly in visual modeling. Use the Unified Modeling Language to create visual models of business problems and software solutions. Create models to show relationships between classes. Create models to portray activities performed by objects. Create models to portray complex algorithms. Create models to show object state. Create models to portray object creation. Page 8 Rev ITCourseware, LLC

9 Chapter 1 Course Introduction The Unified Process This workbook references the Unified Process. The Unified Process is an iterative process, made up of four major phases: The first phase is the Inception Phase, usually used to define what the project will be and create a business case for the project. The second phase is the Elaboration Phase. It is used to perform analysis, prototyping, define the initial architecture, and create a more in-depth business case. The Construction Phase is the third phase. This phase contains a repeating cycle of analysis design code and tests, which produces an increment of functionality. The final phase is the Transition Phase, in which you train the users and deliver the final working product. In each of these phases, diagrams can be created with different perspectives: The first perspective is the Domain Perspective, in which diagrams depict how the current system works. The second perspective is the Specification and Requirements Perspective, in which the diagrams depict what the new system will do. The last perspective is the Design Perspective. This perspective tells how the new system will perform the specification and requirements ITCourseware, LLC Rev Page 9

10 THe Unified Modeling Language Course Overview Audience: Programmers, analysts and software designers. Prerequisites: Experience with objects and object-oriented programming. Experience with analysis and design would be helpful. This course is based on UML Version 2.0, and occasionally mentions features from previous versions. Page 10 Rev ITCourseware, LLC

11 Chapter 1 Course Introduction Using the Workbook This workbook design is based on a page-pair, consisting of a Topic page and a Support page. When you lay the workbook open flat, the Topic page is on the left and the Support page is on the right. The Topic page contains the points to be discussed in class. The Support page has code examples, diagrams, screen shots and additional information. Hands On sections provide opportunities for practical application of key concepts. Try It and Investigate sections help direct individual discovery. In addition, there is an index for quick look-up. Printed lab solutions are in the back of the book as well as on-line if you need a little help. The Topic page provides the main topics for classroom discussion. The Support page has additional information, examples and suggestions. Java Servlets Chapter 2 Servlet Basics The Servlet Life Cycle The servlet container controls the life cycle of the servlet. When the first request is received, the container loads the servlet class and calls the init() method. Topics are organized into first (), second ( ) and For every request, the container uses a separate thread to call the service() method. third ( ) level When points. the servlet is unloaded, the container calls the destroy() method. As with Java s finalize() method, don t count on this being called. Override one of the init() methods for one-time initializations, instead of using a constructor. The simplest form takes no parameters. Hands On: Add an init() method to your Today servlet that initializes a bornon date, then print the bornon date along with the current date: Today.java... Code examples are in a fixed font and shaded. The on-line file name is listed above the shaded area. public class Today extends GenericServlet { private Date bornon; public void service(servletrequest request, ServletResponse response) throws ServletException, IOException {... // Write the document out.println("this servlet was born on " + bornon.tostring()); out.println("it is now " + today.tostring()); } public void init() { bornon = new Date(); } The init() method is called when the servlet is } loaded into the container. Callout boxes point out important parts of the example code. public void init() {...} If you need to know container-specific configuration information, use the other version. public void init(servletconfig config) {... Whenever you use the ServletConfig approach, always call the superclass method, which performs additional initializations. super.init(config); Page 16 Rev ITCourseware, LLC Pages are numbered sequentially throughout the book, making lookup easy. Screen shots show examples of what you should see in class ITCourseware, LLC Rev Page ITCourseware, LLC Rev Page 11

12 THe Unified Modeling Language Suggested References Bellin, David and Susan Simone The CRC Card Book. Addison-Wesley, Reading, MA. ISBN Booch, Grady, James Rumbaugh and Ivar Jacobson The Unified Modeling Language User Guide, Second Edition. Addison-Wesley, Reading, MA. ISBN Cockburn, Alistair Writing Effective Use Cases. Addison-Wesley, Reading, MA. ISBN Fowler, Martin, et al Refactoring: Improving the Design of Existing Code. Addison- Wesley, Reading, MA. ISBN Fowler, Martin UML Distilled: A Brief Guide to the Standard Object Modeling Language, Third Edition. Addison-Wesley, Reading, MA. ISBN Gamma, Erich, et al Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading, MA. ISBN Jacobson, Ivar, Grady Booch and James Rumbaugh The Unified Software Development Process. Addison-Wesley, Reading, MA. ISBN Kruchten, Philippe The Rational Unified Process: An Introduction, Third Edition. Addison- Wesley, Reading, MA. ISBN Larman, Craig Applying UML and Patterns : An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition. Prentice-Hall, Englewood Cliffs, NJ. ISBN Page-Jones, Meilir Fundamentals of Object-Oriented Design in UML. Addison-Wesley, Reading, MA. ISBN X. Pilone, Dan and Neil Pitman UML 2.0 in a Nutshell. O'Reilly & Associates, Sebastopol, CA. ISBN Rumbaugh, James, Ivar Jacobson and Grady Booch The Unified Modeling Language Reference Manual, Second Edition. Addison-Wesley, Reading, MA. ISBN Page 12 Rev ITCourseware, LLC

13 Chapter 1 Course Introduction 2013 ITCourseware, LLC Rev Page 13

14 THe Unified Modeling Language Page 14 Rev ITCourseware, LLC

15 Chapter 3 Class Diagrams Chapter 3 - Class Diagrams Objectives Describe UML syntax for class diagrams. Describe the format of class attributes and any constraints applied to those attributes. Show the notation for inheritance of superclasses. Show the various notations for interface implementation. Use class diagrams to depict abstract classes. Diagram class methods and attributes ITCourseware, LLC Rev Page 41

16 The Unified Modeling Language Class Diagrams A class is like a template for creating objects; it is the definition, description, or blueprint of the object. The class tells what attributes and methods each instance of that class will have. The class also describes the public interface through which other objects can interact with this class. The class is where the code for the methods is held. By convention, class names are capitalized. Here is the UML symbol for the Date class. Date Attributes (fields) and methods (member functions) can also be added to the class diagram. The attributes go in a second box, under the class name. The methods go in the third box. year month day Date getyear() setyear()... adddays() addmonths()... Page 42 Rev ITCourseware, LLC

17 Chapter 3 Class Diagrams You can organize your attributes and methods by adding stereotypes in your diagram. Within the stereotype add a descriptive name to identify a grouping. Student name:string gpa:float balance:float phone:string «constructors» Student() Student(name:String, gpa:float) «accessors» getname() getgpa() «mutators» setname() setgpa() After the third box other boxes can be added to include additional class information. A common possibility would be the class responsibilities that were determined during analysis and design. Another candidate would be a list of exceptions that might be generated by the class. Student Exceptions NegativeBalanceException DuplicateNameException 2013 ITCourseware, LLC Rev Page 43

18 The Unified Modeling Language Attributes Attributes can be simple datatypes or more complex relationships to other classes. The UML notation for an attribute is the attribute name, followed by a colon, with the specific type, followed by multiplicity, default values, and constraints. The following example shows a class with several attributes illustrating attribute notation: Class id:integer {id>0} students:students[1..30] title:string The datatypes of the attributes are often omitted in the early stages. In general, it's often useful to put off details as long as you reasonably can in order to concentrate on the concepts. If you make such decisions late, you'll know more and you're more likely to get them right the first time. It's easier to defer them than change them. Page 44 Rev ITCourseware, LLC

19 Chapter 3 Class Diagrams The member data items (attributes) go in the second box. We usually assume in the early stages that all data is hidden in the object and cannot be accessed from outside. Date day {1-31} month year Months are: January, February,... There are often rules (constraints) to govern the values of the attributes. There are only twelve months. Each has a maximum number of days. There are leap years. All these rules are written into the code that is part of the object so that the data is always maintained in a legal state and the outside code never has to worry about it. Such rules can be represented in a UML model as a text in a box with its corner turned down or as a constraint in curly braces. The box above specifies the legal values for the attribute month. The constraint in the curly braces specifies the legal values for day. You may also specify constraints and relationships between attributes in a separate text file associated with the object. The constraints on a Date are too complex to put in the above diagram. You'd create a separate text document. An outside function can add a day to a date, and rest assured that the Date object will handle wrapping around to the next month or next year, as necessary ITCourseware, LLC Rev Page 45

20 The Unified Modeling Language Attribute Properties Attributes can have several properties enclosed in curly braces after the attribute multiplicity. Some of the properties UML has specified include: ordered You use this to say that an attribute is sorted if the multiplicity of the attribute is greater than one. unique You use this to say that attribute values are unique if the multiplicity of the attribute is greater than one. readonly The attribute may not be modified once given an initial value. The following Invoice class has an array of item integers that will be stored in sorted order and does not allow duplicates. Invoice invno:integer date:date items:integer[1..20] {unique, ordered} balance:float {balance>=0} Page 46 Rev ITCourseware, LLC

21 Chapter 3 Class Diagrams 2013 ITCourseware, LLC Rev Page 47

22 The Unified Modeling Language Operations and Methods A method is a function that belongs to an object. These are sometimes called member functions, because they are members of the class. An operation is similar to a method, but at a more abstract level. Methods are concrete things: functions with code (or at least algorithms), arguments lists, and return types. Operations are abstract just a name that carries a general idea of what it will do, with or without the argument list and return type, but always lacking code. Usually there is a one-to-one relationship between the operations of a class and its methods that you define later as your model becomes more concrete. Sometimes an operation will yield several methods that do the same thing, but differ in argument list, datatypes, etc. A class can have methods that do not descend directly from an operation. Often these are private, for internal use only. Methods or operations go in the third box. The UML specification for a method is the method name, followed by the parameter list in parentheses, and then a colon with the return type of the method. The parameter listing will have the same specification format as attributes. Methods can have pre-condition and post-condition constraints enclosed in curly braces specifying when the method can be called and what the outcome should be. Page 48 Rev ITCourseware, LLC

23 Chapter 3 Class Diagrams Invoice invno:integer date:date items:integer[1..20] {unique, ordered} balance:float {balance>=0} senditems():boolean {precondition:balance=0}... Date year:integer month:integer day:integer same for month and day getyear():integer setyear(integer)... adddays(integer) addmonths(integer) addyears(integer)... cleanup() same for subtraction 2013 ITCourseware, LLC Rev Page 49

24 The Unified Modeling Language Inheritance Inheritance allows you to create a new class that contains all of the attributes and methods of an existing class, and then add to them. The new class is actually an instance of the parent class. The class you inherit from is often called the superclass, and the inherited class is the subclass. The subclass may add new attributes or methods, but it always has all of the attributes and methods of the superclass. The subclass may override one or more of the methods of the superclass by providing different implementations (code) for them. You show inheritance by drawing a solid line with a closed arrow from the child class to the parent class. Person Student Teacher Page 50 Rev ITCourseware, LLC

25 Chapter 3 Class Diagrams Person name address phone dateofbirth setname() getname()... Student stuid gpa classstanding getid() getname() empnum dept salary Teacher raisesalary() Other words for inheritance relationships: Superclass Subclass (This is traditional OO terminology) Generalization Specialization Base class Derived class (This is C++ terminology) Parent class Child class Ancestor class Descendent class 2013 ITCourseware, LLC Rev Page 51

26 The Unified Modeling Language Abstract Classes An abstract class is one that cannot be instantiated; it exists for the sake of an inheritance hierarchy. In UML, show that a class is abstract by italicizing its name. Graphic location color draw() You can also use a stereotype. «abstract» Graphic Abstract classes often contain one or more method declarations, which have no code. Note that draw() above is in italics to indicate that it has no implementation (code). The Graphic class could not draw itself even if it had code. It doesn't know what shape it is. Abstract classes are intended to be used by subclasses that provide implementations for the code-less methods. If a class inherits from an abstract base class, but does not provide code for all of the methods that have no code in the abstract class, the subclass will also be abstract. Any class that has methods without code, or that inherits methods without code but does not provide their code, is abstract and cannot be instantiated. Page 52 Rev ITCourseware, LLC

27 Chapter 3 Class Diagrams The following diagram shows the abstract class Graphic with an abstract method draw(). Square, Circle, and Triangle inherit Graphic and thus must implement the abstract draw() method, or be abstract also. location color Graphic draw() getcolor() draw() Circle draw() Square draw() Triangle 2013 ITCourseware, LLC Rev Page 53

28 The Unified Modeling Language Interfaces An interface is like a class that has only a public interface and no private part. An interface has no attributes (except possibly constants). An interface has public operations (method declarations), but no code for them. Interfaces are naturally abstract. They cannot be instantiated. Indicate an interface with a stereotype. «interface» draw() Graphic Circle Square We say Circle implements Graphic even though it looks like inheritance (note that the line is broken instead of solid). This means Circle and Square inherit the method declarations of Graphic. Circle and Square must provide code for Graphic's draw operation or they become abstract and cannot be instantiated. In Java and C#, interfaces are part of the language. Java and C# do not allow multiple inheritance, but a class may implement multiple interfaces, which gives some of the advantages of multiple inheritance, but few of the complications. Interfaces are not part of the C++ language, but you can get the same effect by creating abstract classes with no code or attributes. Use a stereotype to label them «interface». Page 54 Rev ITCourseware, LLC

29 Chapter 3 Class Diagrams A class may implement several interfaces to get much of the effect of multiple inheritance. Since there are no (variable) attributes in an interface, the problems we mentioned earlier do not occur. Don't be afraid of multiple inheritance in domain and specification models, if you find it useful. In design, you will probably have to stick closer to what your implementation language can do. Note that polymorphism works with classes that implement the same interface just as it does with classes that inherit from the same ancestor. Of course, the only methods that can be used polymorphically are those from the interface. There may well be more structure to an interface than just a set of operations. For example, a certain operation might need to be executed before another operation is usable for a particular purpose. In a complicated case, an interface may have associated with it a state machine or a use case model. It's impossible to create a modeling language (or any other kind of language) that will cover all possible cases. The stereotype is one of the ways we can extend the UML to communicate things that the creators did not anticipate. We can use it to create new specialized elements from existing general ones. If you can't find the «guillemets» on your keyboard, you can use double angle brackets for <<stereotype>> ITCourseware, LLC Rev Page 55

30 The Unified Modeling Language Interfaces with Ball and Socket Notation The implementation of an interface can also be expressed using a ball notation. The interface is expressed as a ball with a line to the class that implements it. The name of the interface is written below the ball. The following class diagram shows that Circle implements the Graphic interface. Circle Graphic Some classes are dependent on other classes that implement a particular interface. Classes that are dependent on a particular interface implementation are expressed using a socket with the name of the interface below the socket. The Picture class in the following diagram is dependent on other objects that implement the Graphic interface. Picture Graphic Put them together and you can see that the Picture class is using the Circle class through the Graphic interface. Picture Graphic Circle Page 56 Rev ITCourseware, LLC

31 Chapter 3 Class Diagrams The following diagram depicts an IAccount interface that is implemented by several classes. The Bank class uses the IAccount interface; thus all the other classes can work with the Bank class. «interface» IAccount deposit(float) withdraw(float) getbalance():float IAccount Checking Bank IAccount IAccount IAccount Savings CD IAccount 401K 2013 ITCourseware, LLC Rev Page 57

32 The Unified Modeling Language Visibility UML specifies four different types of visibility modifiers: public, private, protected, and package. Public data or methods are accessible by the methods of any other class. A public modifier is indicated with a + at the left of the line. Private data or methods are accessible only by the methods of the class in which it was declared. A private modifier is indicated with a - at the left of the line. Protected data or methods in the superclass are accessible by the methods of its subclasses. The exact meaning of "protected" varies between languages. A protected modifier is indicated with a # at the left of the line. Package visibility means that it is accessible to any code in the same package, including code in packages contained within this one. A package modifier is indicated with a tilde (~). Page 58 Rev ITCourseware, LLC

33 Chapter 3 Class Diagrams same for month and day Date -year:integer -month:integer -day:integer +getyear():integer +setyear(integer)... +adddays(integer) +addmonths(integer) +addyears(integer)... -cleanup() same for subtraction 2013 ITCourseware, LLC Rev Page 59

34 The Unified Modeling Language Class Scope An attribute of a class may have class scope. This means there is one copy of the attribute, regardless of how many instances of the class are created. The class scope attribute exists even if there are no instances of the class. All of the instances of the class have access to this single copy of the class scope attribute. Its visibility may be public, private, protected, or package. Generally, any class scope attributes are also constants. The UML syntax for class scope is to underline the attribute name. A method may also have class scope. A class scope method may be called on the class in a situation where there are no instances of the class or the calling code does not have access to one. Such a method may access class scope data, but not object scope attributes. Since it may be called without an object, how would it know which object's attribute to use? Class scope methods may also be public, private, protected, or package. You specify whether an attribute or a method has class scope by underlining it in the class diagram. Page 60 Rev ITCourseware, LLC

35 Chapter 3 Class Diagrams The following student class has a static field called nextid. This field exists in the class and a student object does not need to be instantiated to access this field. You also have access to a static method called getnextid() to get the value of nextid. This allows nextid to be encapsulated inside the class. nextid = 1 id Student getnextid() getid() 2013 ITCourseware, LLC Rev Page 61

36 The Unified Modeling Language Labs Create a class diagram to depict an account at a bank. Include any fields and methods that might be needed to represent any account at a bank. Create a class diagram for checking and savings account classes. Use inheritance to reuse what you developed in the previous lab. Create a class called InterestChecking. Again, use inheritance to reuse what you developed in the previous lab. Add visibility modifiers to your class diagrams. Page 62 Rev ITCourseware, LLC