Published on

UML Diagram from Drexel University

1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. Software Design Static Modeling using the Unified Modeling Language (UML) Material based on[Booch99, Rambaugh99, Jacobson99, Fowler97, Brown99] Software Design (UML) © SERG
  2. 2. Classes A class is a description of a set ofClassName objects that share the same attributes, operations, relationships, and semantics.attributes Graphically, a class is rendered as a rectangle, usually including its name,operations attributes, and operations in separate, designated compartments. Software Design (UML) © SERG
  3. 3. Class Names The name of the class is the only requiredClassName tag in the graphical representation of a class. It always appears in the top-mostattributes compartment.operations Software Design (UML) © SERG
  4. 4. Class Attributes Personname : String An attribute is a named property of aaddress : Address class that describes the object being modeled.birthdate : Date In the class diagram, attributes appear inssn : Id the second compartment just below the name-compartment. Software Design (UML) © SERG
  5. 5. Class Attributes (Cont’d) Attributes are usually listed in the form: Person attributeName : Typename : String A derived attribute is one that can beaddress : Address computed from other attributes, butbirthdate : Date doesn’t actually exist. For example,/ age : Date a Person’s age can be computed fromssn : Id his birth date. A derived attribute is designated by a preceding ‘/’ as in: / age : Date Software Design (UML) © SERG
  6. 6. Class Attributes (Cont’d) Person Attributes can be:+ name : String + public# address : Address # protected# birthdate : Date - private/ age : Date / derived- ssn : Id Software Design (UML) © SERG
  7. 7. Class Operations Personname : Stringaddress : Addressbirthdate : Datessn : Id eat Operations describe the class behavior sleep and appear in the third compartment. work play Software Design (UML) © SERG
  8. 8. Class Operations (Cont’d) PhoneBooknewEntry (n : Name, a : Address, p : PhoneNumber, d : Description)getPhone ( n : Name, a : Address) : PhoneNumberYou can specify an operation by stating its signature: listing thename, type, and default value of all parameters, and, in the case offunctions, a return type. Software Design (UML) © SERG
  9. 9. Depicting ClassesWhen drawing a class, you needn’t show attributes and operationin every diagram. Person Person Person name : String birthdate : Date Person ssn : Id name Person eat() address sleep() birthdate eat work() play play() Software Design (UML) © SERG
  10. 10. Class ResponsibilitiesA class may also include its responsibilities in a class diagram.A responsibility is a contract or obligation of a class to performa particular service. SmokeAlarm Responsibilities -- sound alert and notify guard station when smoke is detected. -- indicate battery state Software Design (UML) © SERG
  11. 11. RelationshipsIn UML, object interconnections (logical or physical), aremodeled as relationships.There are three kinds of relationships in UML: • dependencies • generalizations • associations Software Design (UML) © SERG
  12. 12. Dependency RelationshipsA dependency indicates a semantic relationship between two ormore elements. The dependency from CourseSchedule toCourse exists because Course is used in both the add andremove operations of CourseSchedule. CourseSchedule Course add(c : Course) remove(c : Course) Software Design (UML) © SERG
  13. 13. Generalization RelationshipsPerson A generalization connects a subclass to its superclass. It denotes an inheritance of attributes and behavior from the superclass to the subclass and indicates a specialization in the subclass of the more general superclass.Student Software Design (UML) © SERG
  14. 14. Generalization Relationships (Cont’d)UML permits a class to inherit from multiple superclasses,although some programming languages (e.g., Java) do not permitmultiple inheritance. Student Employee TeachingAssistant Software Design (UML) © SERG
  15. 15. Association RelationshipsIf two classes in a model need to communicate with each other,there must be link between them.An association denotes that link. Student Instructor Software Design (UML) © SERG
  16. 16. Association Relationships (Cont’d)We can indicate the multiplicity of an association by addingmultiplicity adornments to the line denoting the association.The example indicates that a Student has one or moreInstructors: Student Instructor 1..* Software Design (UML) © SERG
  17. 17. Association Relationships (Cont’d)The example indicates that every Instructor has one or moreStudents: Student Instructor 1..* Software Design (UML) © SERG
  18. 18. Association Relationships (Cont’d)We can also indicate the behavior of an object in an association(i.e., the role of an object) using rolenames. teaches learns from Student Instructor 1..* 1..* Software Design (UML) © SERG
  19. 19. Association Relationships (Cont’d) We can also name the association. membership Student Team 1..* 1..* Software Design (UML) © SERG
  20. 20. Association Relationships (Cont’d) We can specify dual associations. member of 1..* 1..* Student Team 1 president of 1..* Software Design (UML) © SERG
  21. 21. Association Relationships (Cont’d)We can constrain the association relationship by defining thenavigability of the association. Here, a Router object requestsservices from a DNS object by sending messages to (invokingthe operations of) the server. The direction of the associationindicates that the server has no knowledge of the Router. Router DomainNameServer Software Design (UML) © SERG
  22. 22. Association Relationships (Cont’d)Associations can also be objects themselves, called link classesor an association classes. Registration modelNumber serialNumber warrentyCode Product Warranty Software Design (UML) © SERG
  23. 23. Association Relationships (Cont’d) A class can have a self association. next LinkedListNode previous Software Design (UML) © SERG
  24. 24. Association Relationships (Cont’d)We can model objects that contain other objects by way ofspecial associations called aggregations and compositions.An aggregation specifies a whole-part relationship betweenan aggregate (a whole) and a constituent part, where the partcan exist independently from the aggregate. Aggregations aredenoted by a hollow-diamond adornment on the association. Engine Car Transmission Software Design (UML) © SERG
  25. 25. Association Relationships (Cont’d)A composition indicates a strong ownership and coincidentlifetime of parts by the whole (i.e., they live and die as awhole). Compositions are denoted by a filled-diamondadornment on the association. Scrollbar 1 1 Window Titlebar 1 1 Menu 1 1 .. * Software Design (UML) © SERG
  26. 26. Interfaces An interface is a named set of operations that specifies the behavior<<interface>> of objects without showing their innerControlPanel structure. It can be rendered in the model by a one- or two-compartment rectangle, with the stereotype <<interface>> above the interface name. Software Design (UML) © SERG
  27. 27. Interface Services <<interface>> Interfaces do not get instantiated. ControlPanel They have no attributes or state. Rather, they specify the servicesgetChoices : Choice[] offered by a related class.makeChoice (c : Choice)getSelection : Selection Software Design (UML) © SERG
  28. 28. Interface Realization Relationship A realization relationship <<interface>> connects a class with an ControlPanel interface that supplies its specifier behavioral specification. It is rendered by a dashed line with a hollow triangle towards the specifier. implementationVendingMachine Software Design (UML) © SERG
  29. 29. InterfacesinputStream FileWriter {file must not be locked} A class’ interface can also be rendered by a circle File connected to a class by a solid line. {file must exist} FileReaderoutputStream Software Design (UML) © SERG
  30. 30. Parameterized Class T A parameterized class orLinkedList template defines a family of potential elements. To use it, the parameter must be T bound. 1 .. * A template is rendered by a small dashed rectangle superimposed on the upper-right corner of the class rectangle. The dashed rectangle contains a list of formal parameters for the class. Software Design (UML) © SERG
  31. 31. Parameterized Class (Cont’d) TLinkedList Binding is done with the <<bind>> stereotype and a parameter to supply to the template. These are T adornments to the dashed arrow 1..* denoting the realization relationship. Here we create a linked-list of <<bind>>(Name) names for the Dean’s List.DeansList Software Design (UML) © SERG
  32. 32. Enumeration<<enumeration>> An enumeration is a user-defined Boolean data type that consists of a name and false an ordered list of enumeration true literals. Software Design (UML) © SERG
  33. 33. Exceptions <<exception>> Exceptions can be modeled Exception just like any other class. getMessage() Notice the <<exception>> printStackTrace() stereotype in the name compartment.<<exception>> <<exception>>KeyException SQLException Software Design (UML) © SERG
  34. 34. Packages A package is a container-like element for organizing other elements into groups. A package can contain classes andCompiler other packages and diagrams. Packages can be used to provide controlled access between classes in different packages. Software Design (UML) © SERG
  35. 35. Packages (Cont’d)Classes in the FrontEnd package and classes in the BackEndpackage cannot access each other in this diagram. Compiler FrontEnd BackEnd Software Design (UML) © SERG
  36. 36. Packages (Cont’d)Classes in the BackEnd package now have access to the classesin the FrontEnd package. Compiler FrontEnd BackEnd Software Design (UML) © SERG
  37. 37. Packages (Cont’d) We can model generalizations and Compiler dependencies between packages.JavaCompiler Java Software Design (UML) © SERG
  38. 38. Component DiagramComponent diagrams are one of the two kinds of diagramsfound in modeling the physical aspects of an object-orientedsystem. They show the organization and dependenciesbetween a set of components.Use component diagrams to model the staticimplementation view of a system. This involves modelingthe physical things that reside on a node, such asexecutables, libraries, tables, files, and documents. - The UML User Guide, Booch et. al., 1999 Software Design (UML) © SERG
  39. 39. Component Diagrampath.dll collision.dll Here’s an example of a component model of an executable release. driver.dll version = [Booch,99] IDriveISelfTest Software Design (UML) © SERG
  40. 40. Component Diagram signal.h signal.h signal.h version = 3.5 version = 4.0 version = 4.1 “parent” “parent” signal.cpp interp.cpp version = 4.1Modeling source code.[Booch, 99] irq.h device.cpp Software Design (UML) © SERG
  41. 41. Deployment DiagramDeployment diagrams are one of the two kinds of diagramsfound in modeling the physical aspects of an object-orientedsystem. They show the configuration of run-timeprocessing nodes and the components that live on them.Use deployment diagrams to model the static deploymentview of a system. This involves modeling the topology ofthe hardware on which the system executes. - The UML User Guide, [Booch,99] Software Design (UML) © SERG
  42. 42. Deployment DiagramA component is a physical unit of implementation with well-defined interfaces that is intended to be used as a replaceablepart of a system. Well designed components do not dependdirectly on other components, but rather on interfaces thatcomponents support. - The UML Reference Manual, [Rumbaugh,99] component spell-check Dictionary interfaces synonyms Software Design (UML) © SERG
  43. 43. Deployment Diagram <<database>> stereotyped Account component Transactions Update interface usage dependencycomponent ATM-GUI realization dependency [Rumbaugh,99] Software Design (UML) © SERG
  44. 44. Deployment Diagram server:HostMachine <<database>> meetingsDB Deployment diagram of a client-server :Scheduler reservations system.<<direct channel>> clientMachine:PC [Rumbaugh,99] :Planner Software Design (UML) © SERG
  45. 45. Software DesignDynamic Modeling using theUnified Modeling Language (UML) Software Design (UML) © SERG
  46. 46. Use Case“A use case specifies the behavior of a system or a part of asystem, and is a description of a set of sequences of actions,including variants, that a system performs to yield an observableresult of value to an actor.” - The UML User Guide, [Booch,99]“An actor is an idealization of an external person, process, orthing interacting with a system, subsystem, or class. An actorcharacterizes the interactions that outside users may have withthe system.” - The UML Reference Manual, [Rumbaugh,99] Software Design (UML) © SERG
  47. 47. Use Case (Cont’d) A use case is rendered as an ellipseRegister for Courses in a use case diagram. A use case is always labeled with its name. Software Design (UML) © SERG
  48. 48. Use Case (Cont’d) An actor is rendered as a stick figure in a use case diagram. Each actor participates in one or more use cases.Student Software Design (UML) © SERG
  49. 49. Use Case (Cont’d)Actors can participate in a generalization relation with otheractors. Student Person Software Design (UML) © SERG
  50. 50. Use Case (Cont’d) Actors may be connected to use cases only by associations. Register for CoursesStudent Software Design (UML) © SERG
  51. 51. Use Case (Cont’d)Here we have a Student interacting with the Registrar and theBilling System via a “Register for Courses” use case. Billing System Student Register for Courses Registrar Software Design (UML) © SERG
  52. 52. State Machine“The state machine view describes the dynamic behavior ofobjects over time by modeling the lifecycles of objects of eachclass. Each object is treated as an isolated entity thatcommunicates with the rest of the world by detecting events andresponding to them. Events represent the kinds of changes thatobjects can detect... Anything that can affect an object can becharacterized as an event.” - The UML Reference Manual, [Rumbaugh,99] Software Design (UML) © SERG
  53. 53. State MachineAn object must be in some specific state at any given time duringits lifecycle. An object transitions from one state to another as theresult of some event that affects it. You may create a statediagram for any class, collaboration, operation, or use case in aUML model .There can be only one start state in a state diagram, but there maybe many intermediate and final states. Software Design (UML) © SERG
  54. 54. State Machine start state final state simple state concurrent composite state sequential composite stateSoftware Design (UML) © SERG
  55. 55. State Machine download course offerings downloadingunscheduled make a course selection selecting make a different selection verify selection verifying select another course check schedule sign schedule checking schedulescheduled Software Design (UML) © SERG
  56. 56. Sequence DiagramA sequence diagram is an interaction diagram that emphasizesthe time ordering of messages. It shows a set of objects and themessages sent and received by those objects.Graphically, a sequence diagram is a table that shows objectsarranged along the X axis and messages, ordered in increasingtime, along the Y axis. - The UML User Guide, [Booch,99] Software Design (UML) © SERG
  57. 57. Sequence Diagraman Order Line An object in a sequence diagram is rendered as a box with a dashed line descending from it. The line is called the object lifeline, and it represents the existence of an object over a period of time. Software Design (UML) © SERG
  58. 58. Sequence Diagraman Order Line a Stock Item Messages are rendered as horizontal check() arrows being passed from object to [check = “true”] object as time advances down the remove() object lifelines. Conditions ( such as [check = “true”] ) indicate when a message gets passed. Software Design (UML) © SERG
  59. 59. Sequence Diagraman Order Line a Stock Item check() [check = “true”] Notice that the bottom arrow is remove() different. The arrow head is not solid, and there is no accompanying message. This arrow indicates a return from a previous message, not a new message. Software Design (UML) © SERG
  60. 60. Sequence Diagraman Order a Order Line * prepare() An iteration marker, such as * (as shown), or *[i = 1..n] , indicates that a message will be repeated as Iteration indicated. marker Software Design (UML) © SERG
  61. 61. an Order Entry window an Order an Order Line a Stock Item [Fowler,97] prepare() Condition * prepare()Object check() Message [check = “true”] remove() needsToReorder() Iteration Self-Delegation Return [needsToReorder = “true”] new A Reorder Item [check = “true”] A Delivery new Item Creation Software Design (UML) © SERG
  62. 62. Collaboration DiagramA collaboration diagram emphasizes the relationship of theobjects that participate in an interaction. Unlike a sequencediagram, you don’t have to show the lifeline of an objectexplicitly in a collaboration diagram. The sequence of eventsare indicated by sequence numbers preceding messages.Object identifiers are of the form objectName : className, andeither the objectName or the className can be omitted, and theplacement of the colon indicates either an objectName: , or a:className. Software Design (UML) © SERG
  63. 63. Collaboration Diagram: Order Entry Window Object Sequence Number 1: prepare() Message : Order Self-Delegation 5: needToReorder() 2*: prepare() 3: check() 4: [check == true] remove() : Order Line : Stock Item 7: [check == true] new 6: new :Delivery Item :Reorder Item [Fowler,97] Software Design (UML) © SERG
  64. 64. Collaboration Diagram Sequence DiagramBoth a collaboration diagram and a sequence diagram derivefrom the same information in the UML’s metamodel, so you cantake a diagram in one form and convert it into the other. Theyare semantically equivalent. Software Design (UML) © SERG
  65. 65. Activity DiagramAn activity diagram is essentially a flowchart, showing theflow of control from activity to activity.Use activity diagrams to specify, construct, and documentthe dynamics of a society of objects, or to model the flow ofcontrol of an operation. Whereas interaction diagramsemphasize the flow of control from object to object, activitydiagrams emphasize the flow of control from activity toactivity. An activity is an ongoing non-atomic executionwithin a state machine. - The UML User Guide, [Booch,99] Software Design (UML) © SERG
  66. 66. Receive Order [Fowler,97] Multiple Trigger for each line * item on order Check Cancel Authorize Line Order Payment [failed] Item [succeeded] [in stock] Assign to OrderSynchronization Condition [need to reorder] Reorder Item [stock assigned to all line items and payment authorized] Dispatch Order Software Design (UML) © SERG
  67. 67. References[Booch99] Booch, Grady, James Rumbaugh, Ivar Jacobson,The Unified Modeling Language User Guide, Addison Wesley, 1999[Rambaugh99] Rumbaugh, James, Ivar Jacobson, Grady Booch, The UnifiedModeling Language Reference Manual, Addison Wesley, 1999[Jacobson99] Jacobson, Ivar, Grady Booch, James Rumbaugh, The UnifiedSoftware Development Process, Addison Wesley, 1999[Fowler, 1997] Fowler, Martin, Kendall Scott, UML Distilled(Applying the Standard Object Modeling Language),Addison Wesley, 1997.[Brown99] First draft of these slides were created by James Brown. Software Design (UML) © SERG