UML Unified Modeling Language z Story y What

UML: Unified Modeling Language z. Story: y. What UML is for y. Some of the main diagrams are and what you use them for x. Class diagrams and class forms x. Use Case Diagrams x. Sequence (Event) Diagram x. State Diagrams y. An example

UML: Unified Modeling Language z. Developed by the “Three Amigos”: Grady Booch, Jim Rumbaugh, Ivar Jacobson y. Each had their own development methodology y. More or less emphasis on notation and process z. UML is a notation and a process y. Diagrams and notation from UML 1. 3 Definition (http: //www. rational. com)

Diagrams z. Class diagrams: Represents static structure z. Use case diagrams: Sequence of actions a system performs to yield an observable result to an actor z. Sequence diagrams: Shows how groups of objects interact in some behavior z. State diagrams: Describes behavior of system by describing states of an object

Class Diagrams z. Better name: “Static structure diagram” y. Doesn’t describe temporal aspects y. Doesn’t describe individual objects: Only the overall structure of the system z. There are “object diagrams” where the boxes represent instances y. But rarely used—other diagrams serve the role of describing object interaction better y. When used, object diagrams describe static structure, like a data structure

Different Levels of Specifying Classes

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

Other variations in Class specifications z. Use of templates, interfaces, and types z. Can even specify body of methods

Components of Class Diagrams z. Multiplicities y. How many of each? z. Labels to indicate how reference is viewed z. Role and Association classes

Navigability and Aggregations z. Navigability y. Who owns/contains/has who? y. Arrows not strictly required z. Aggregation: Open diamond y“Part-of” relationship, but disagreement z. Composition: closed diamond y. Part can only belong to whole

Qualifiers z. Serves to describe an instance variable that partitions the relationship.

Use Case Diagrams z. Means of capturing requirements z. Document interactions between user(s) and the system y. User (actor) is not part of the system itself y. But an actor can be another system z. An 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 z. Are actually defined as text, including descriptions of all of the normal and exception behavior expected z. Do not reveal the structure of the system z. Collectively define the boundaries of the system to be implemented z. Provide the basis for defining development iterations

Example Use Case Diagram (Advanced Features)

Sequence (Event) Diagrams z. Shows individual objects and how they interact z. Describes y. Lifelines of objects y. Who sends what messages when y. Can also describe sending messages to self ("self-delegation") y. Can describe guards, notes, etc.

Example Sequence Diagram

State Diagrams z. Describe all the possible states a particular object can get into, and the events that lead to those changes z. Also called a "statechart"

Example State Diagram

Other Kinds of UML Diagrams z. Collaboration Diagrams y. An alternative to sequence diagrams for describing the flow of messages between objects

Other kinds of UML Diagrams z Activity Diagrams y. Alternative to statecharts

Other kinds of UML Diagrams z Implementation Diagrams y. Down at the detail level x. What piece of code goes where? x. How are they connected?

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

Example: Student Registration System z. Not going to do all the diagrams y. Not all types, not even all that completely specify the system z. But this is an application you know, so the examples may help make sense

Student Registration Class Diagram Student transcript major schedule registrar 1 * Registrar Section course days. And. Time roster add. Student remove. Student 1 1 Department courses required. Courses course. Grades 1 * enroll. In. Class: grade. In. Course: taken. Course: Transcript 1 * * 1 get. Sections. For: enroll. In. Section: drop. From. Section: * 1* 1. . 3 1 courses sections grade. For. Course: taken. Course: 1 * Course 1 * name number 0. . 3 department credit. Hours prerequisites * Course. Grade * course grade term. Enrolled

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

States of a Student Apply [ Must be accepted first ] Enrolled Enroll. In. Class ( Add a Transcript ) Withdraw Registered Add. Course Graduate [ All courses must be completed ]

Sequence Diagram: Registering for Course a. Student the. Registrar a. Section the. Transcript get. Sections. For: return sections enroll. In. Section: taken. Course: prerequisite state of prereq have prereq add. Student: enrolled

Process to Representations z. OOA y. CRC Cards (but they’re not officially UML) y. Use Cases z. OOD y. Just about all of the rest y. But variations—some detail is later z. OOP y. Can actually go UML->code with some tools!

UML v 1. 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 Intelli. Corp Copyright © 1997, 1998, 1999 Electronic Data Services Corporation Copyright © 1997, 1998, 1999 Microsoft Corporation Copyright © 1997, 1998, 1999 Objec. Time 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