UML: Unified Modeling Language zStory: yWhat UML is for ySome of the main diagrams are and what you use them for xClass diagrams and class forms xUse Case Diagrams xSequence (Event) Diagram xState Diagrams yAn example

UML: Unified Modeling Language zDeveloped by the “Three Amigos”: Grady Booch, Jim Rumbaugh, Ivar Jacobson yEach had their own development methodology yMore or less emphasis on notation and process zUML is a notation and a process yDiagrams and notation from UML 1.3 Definition (

Diagrams zClass diagrams: Represents static structure zUse case diagrams: Sequence of actions a system performs to yield an observable result to an actor zSequence diagrams:Shows how groups of objects interact in some behavior zState diagrams: Describes behavior of system by describing states of an object

Class Diagrams zBetter name: “Static structure diagram” yDoesn’t describe temporal aspects yDoesn’t describe individual objects: Only the overall structure of the system zThere are “object diagrams” where the boxes represent instances yBut rarely used—other diagrams serve the role of describing object interaction better yWhen used, object diagrams describe static structure, like a data structure

Different Levels of Specifying Classes

Notation in Class Boxes zAbstract classes (and operations) in italics z+ is public, - is private, # is protected zCan also specify stereotypes or compartments y“constructors” or “query” y“controller”

Other variations in Class specifications zUse of templates, interfaces, and types zCan even specify body of methods

Components of Class Diagrams zMultiplicities yHow many of each? zLabels to indicate how reference is viewed zRole and Association classes

Navigability and Aggregations zNavigability yWho owns/contains/has who? yArrows not strictly required zAggregation: Open diamond y“Part-of” relationship, but disagreement zComposition: closed diamond yPart can only belong to whole

Qualifiers zServes to describe an instance variable that partitions the relationship.

Use Case Diagrams zMeans of capturing requirements zDocument interactions between user(s) and the system yUser (actor) is not part of the system itself yBut an actor can be another system zAn individual use case represents a task to be done with support from the system (thus it is a ‘coherent unit of functionality’)

Simple Use Case Diagram Reserve book Borrow book Return book

Use Case Diagram with Multiple Actors

Use Cases zAre actually defined as text, including descriptions of all of the normal and exception behavior expected zDo not reveal the structure of the system zCollectively define the boundaries of the system to be implemented zProvide the basis for defining development iterations

Example Use Case Diagram (Advanced Features)

Sequence (Event) Diagrams zShows individual objects and how they interact zDescribes yLifelines of objects yWho sends what messages when yCan also describe sending messages to self ("self-delegation") yCan describe guards, notes, etc.

Example Sequence Diagram

State Diagrams zDescribe all the possible states a particular object can get into, and the events that lead to those changes zAlso called a "statechart"

Example State Diagram

Other Kinds of UML Diagrams zCollaboration Diagrams yAn alternative to sequence diagrams for describing the flow of messages between objects

Other kinds of UML Diagrams zActivity Diagrams yAlternative to statecharts

Other kinds of UML Diagrams zImplementation Diagrams yDown at the detail level xWhat piece of code goes where? xHow are they connected?

UML in Real Practice zYou don't typically use all the diagrams yYou'll choose between them based on preference and particular situation zYou typically use many diagrams yA single use case may not capture all scenarios yIf you are going to use statecharts, there are probably lots of objects with states yEach sequence/collaboration diagram only shows one interaction

Example: Student Registration System zNot going to do all the diagrams yNot all types, not even all that completely specify the system zBut this is an application you know, so the examples may help make sense

Student Registration Class Diagram * prereqs 0..3 prereqs 0..3 Course name number department creditHours prerequisites 1 *** **1 CourseGrade course grade termEnrolled Transcript courseGrades gradeForCourse: takenCourse: 1*** 1 ** * *** 1..3*** *** * Department courses requiredCourses 111 Student transcript major enrollInClass: gradeInCourse: takenCourse: Section course daysAndTime roster addStudent removeStudent * 1 * sections Registrar courses getSectionsFor: enrollInSection: dropFromSection: schedule registrar 1 * 1

Partial Use Case Diagram Withdraw from a Course Apply for Admission Student Enroll in the University Enroll in a Course Admissions

States of a Student EnrollInClass ( Add a Transcript ) Enrolled Apply [ Must be accepted first ] Graduate [ All courses must be completed ] AddCourse Registered Withdraw

Sequence Diagram: Registering for Course theRegistraraSectiontheTranscriptaStudent state of prereq have prereq enrolled enrollInSection : return sections getSectionsFor: addStudent : enrolled takenCourse: prerequisite

Process to Representations zOOA yCRC Cards (but they’re not officially UML) yUse Cases zOOD yJust about all of the rest yBut variations—some detail is later zOOP yCan actually go UML->code with some tools!

UML v1.3 Copyright Notice Copyright © 1997, 1998, 1999 Object Management Group, Inc. Copyright © 1997, 1998, 1999 Hewlett-Packard Company Copyright © 1997, 1998, 1999 IBM Corporation Copyright © 1997, 1998, 1999 ICON Computing Copyright © 1997, 1998, 1999 i-Logix Copyright © 1997, 1998, 1999 IntelliCorp Copyright © 1997, 1998, 1999 Electronic Data Services Corporation Copyright © 1997, 1998, 1999 Microsoft Corporation Copyright © 1997, 1998, 1999 ObjecTime Limited Copyright © 1997, 1998, 1999 Oracle Corporation Copyright © 1997, 1998, 1999 Platinum Technology, Inc. Copyright © 1997, 1998, 1999 Ptech Inc. Copyright © 1997, 1998, 1999 Rational Software Corporation Copyright © 1997, 1998, 1999 Reich Technologies Copyright © 1997, 1998, 1999 Softeam Copyright © 1997, 1998, 1999 Sterling Software Copyright © 1997, 1998, 1999 Taskon A/S Copyright © 1997, 1998, 1999 Unisys Corporation