The Unified Modeling Language (UML) A Standard Graphical Modeling Notation Eddie Roache

Outline Why Use UML History UML Characteristics Diagram Types Use Case Diagrams Class Diagrams Copyright © 2003-2006 Eddie Roache. All rights reserved. v1.2 Copyright © 2003 Eddie Roache. All rights reserved.

Why Use UML? Help analyze complex domains Help design complex systems Visualize analysis and design artifacts Clearly document development artifacts Is simple, yet expressive Can be applied to different processes Copyright © 2003-2006 Eddie Roache. All rights reserved. v1.2

Some UML Examples Source: OMG, Unified Modeling Language Specification, version 1.5. March 2003 Copyright © 2003-2006 Eddie Roache. All rights reserved. v1.2

Some UML Examples Source: OMG, Unified Modeling Language Specification, version 1.5. March 2003 Copyright © 2003-2006 Eddie Roache. All rights reserved. v1.2

Some UML Examples Source: OMG, Unified Modeling Language Specification, version 1.5. March 2003 Copyright © 2003-2006 Eddie Roache. All rights reserved. v1.2

History OO takes a foothold New OO modeling notations spring up Three amigos get together Grady Booch Ivar Jacobson James Rumbaugh UML 0.8 is born Copyright © 2003-2006 Eddie Roache. All rights reserved. v1.2 Copyright © 2003 Eddie Roache. All rights reserved.

UML Characteristics Unified Modeling Language Standard graphical modeling notation Supported by formal semantics Current version: 2.0 Wide use and acceptance in the IT industry Large tool support Rational Rose, Together, Visio, Jude, … … although no tool fully supports the standard Is not a process Process independent Copyright © 2003-2006 Eddie Roache. All rights reserved. v1.2

Diagram Types Structure diagrams Behavior diagrams Class diagram Object diagram Component diagram Deployment diagram Package diagram Composite Structure diagram Behavior diagrams Use Case diagram Interaction diagrams Sequence diagram Interaction Overview diagram Communications diagram Timing diagram State Machine diagram Activity diagram Copyright © 2003-2006 Eddie Roache. All rights reserved. v1.2

Diagram Types Source: OMG, Unified Modeling Language: Superstructure Specification, version 2.0. August 2005 Copyright © 2003-2006 Eddie Roache. All rights reserved. v1.2

Use Case Diagrams Model user interaction with system Capture functional requirements Also used for business modeling component specification UML Spec does not include Use Case Specs Copyright © 2003-2006 Eddie Roache. All rights reserved. v1.2

Use Case Definition “A use case specifies a sequence of actions, including variants, that the system can perform and that yields an observable result of value to a particular actor.” “The Unified Software Development Process”, Ivar Jacobsen*, Grady Booch, Jim Rumbaugh What is a use case? Here’s the definition provided in the 3 amigo's book: Use cases describe the services the system under development must provide Services are the functional requirements for the system Use cases are effective because they are based on the interaction of the system with it’s external actors The system is treated as a black box - there is no visibility into how the system provides the services. Use cases are a key unit of requirements Presume “essential” requirements - presume infinite processing resources. *Author of “Object-Oriented Software Engineering: A Use Case Driven Approach” Copyright © 2003-2006 Eddie Roache. All rights reserved. v1.2 Copyright © 2003 Eddie Roache. All rights reserved.

Use Case Specification Name: Create AddressEntry Description: This use case allows the actor to create a new entry for an Address Book. Preconditions: 1. An Address Book is open. Steps: 1. The actor requests to create a new AddressEntry. 2. The system creates a new AddressEntry and returns it to the actor. Post Conditions: 1. An Address Book Entry is created. Use Case specifications provide a detailed description of the steps in the use case. Includes: Pre-Conditions Post Conditions Description Not shown, but part of a formal use case specification are: Performance Requirements Business Rules Alternative courses - what happens if …(need an example…maybe introduce concept later). Notice, Precondition calls for AddressBook being open, but we don’t have an “open” use case. Maybe it’s part of View. Let’s tentatively rename View as Open, and show the interrelationship between the new “Open” use case and Create AddressBookEntry. See “Writing Effective Use Cases” and “http://alistair.cockburn.us/usecases/usecases.html” Copyright © 2003-2006 Eddie Roache. All rights reserved. v1.2 Copyright © 2003 Eddie Roache. All rights reserved.

<<Actor>> Use Case Diagrams <<Actor>> Actor Use Case Association Dependency extend include Generalization Note (Comment) Close AddressBook <<extend>> <<include>> This is a note. Copyright © 2003-2006 Eddie Roache. All rights reserved. v1.2

Address Book Example The Address Book System provides distributed access to a set of address books. An Address Book is made up of Address Book Entries An Address Book Entry contains a name, street address, phone number, email address The Address Book System shall: allow users to create, view, delete, and save address books allow users to create, modify, and delete entries in an address book The goal is to learn about use case modeling, and how this technique can be used to capture requirements for a system. Later, we will see how use cases can be used to derive the design and implementation for a system, and how tractability between requirements and design and implementation can be maintained. Describe the sample system…Address Book System is similar to the address book that e-mail systems have. Copyright © 2003-2006 Eddie Roache. All rights reserved. v1.2 Copyright © 2003 Eddie Roache. All rights reserved.

Use Case Diagram AddressBook System Create AddressBook View AddressBook AddressBook User Delete AddressBook Copyright © 2003-2006 Eddie Roache. All rights reserved. v1.2 Copyright © 2003 Eddie Roache. All rights reserved.

Use Case Diagram View AddressBook Save AddressBook Delete Address <<extend>> View AddressBook Save AddressBook <<extend>> <<extend>> Address Book User Delete Address Update Address <<extend>> <<extend>> Add New Address <<include>> Add AddressEntry Close AddressBook <<include>> Create AddressEntry Create PersonAddressEntry Create OrgAddressEntry Copyright © 2003-2006 Eddie Roache. All rights reserved. v1.2

Use Case Diagram View AddressBook Save AddressBook Delete AddressEntry Address Book User Delete AddressEntry Update Address Add New Address <<include>> Add AddressEntry Close AddressBook <<include>> Create AddressEntry All dependencies are extend unless stereotyped otherwise Create PersonAddressEntry Create OrgAddressEntry Copyright © 2003-2006 Eddie Roache. All rights reserved. v1.2

Class Diagrams Model system classes, interfaces, and class relationships Capture structural (vs. behavioral) info Used for business domain modeling logical design implementation design Copyright © 2003-2006 Eddie Roache. All rights reserved. v1.2

Class Diagrams Class Abstract Class Class with Attributes and Operations AddressBook AddressBook AddressBook -id +name +phone +getName() +getPhone() Copyright © 2003-2006 Eddie Roache. All rights reserved. v1.2

Class Diagrams Dependency Association Navigability Aggregation Composition Generalization Copyright © 2003-2006 Eddie Roache. All rights reserved. v1.2

Class Diagrams Multiplicity Constraint Role Name Directionality 1..2 * Multiplicity Constraint Role Name Directionality Nesting * {ordered} +entry has displays Copyright © 2003-2006 Eddie Roache. All rights reserved. v1.2

Class Diagrams Stereotype Realization Derived Assoc. Association Class <<Entity>> Stereotype Realization Derived Assoc. Association Class Note (Comment) <<Interface>> /entry This is a note. Copyright © 2003-2006 Eddie Roache. All rights reserved. v1.2

Class Model Element Source: OMG Unified Modeling Language Specification, version 1.5. March 2003 Copyright © 2003-2006 Eddie Roache. All rights reserved. v1.2

Class Model Element Source: OMG Unified Modeling Language Specification, version 1.5. March 2003 Copyright © 2003-2006 Eddie Roache. All rights reserved. v1.2

Address Book Domain AddressBook AddressEntry Party Person Organization * 1 1 AddressEntry Party In writing out the specification, the entities begin to emerge. Develop a type model that describes the vocabulary of the domain the system operates in... Person Organization Copyright © 2003-2006 Eddie Roache. All rights reserved. v1.2 Copyright © 2003 Eddie Roache. All rights reserved.

AddressBookController Logical Design AddressBookView AddressBookController AddressBook Copyright © 2003-2006 Eddie Roache. All rights reserved. v1.2

Implementation Design 1 1 AddressBookController AddressBookView -addrBookFrame: JFrame -addrList: JList -entryNames: String[] +getEntryNames(): String[] +createNewEntry(): AddressBookEntry ~removeEntry() +findEntry(name: String): AddressBookEntry +show() +update() #createAddrBookFrame(): JFrame 1 * * 1 AddressBookEntry AddressBook #name: String #streetAddress: String #city: String #State: String #Zip: String #phoneNumber: String #emailAddress: String -name: String +load() +getEntryNames(): String[] +addEntry() +removeEntry() +findEntry(name: String): AddressBookEntry +toString(): String Copyright © 2003-2006 Eddie Roache. All rights reserved. v1.2

More UML Characteristics Supported by formal semantics (meta-model) Meta-Object Facility Specification UML Model Interchange using XML Metadata Interchange (XMI) Object Constraint Language (OCL) Action Semantics UML Extensions Standard profiles Copyright © 2003-2006 Eddie Roache. All rights reserved. v1.2

Tools Paper and Pencil Any drawing program (preferably vector-based) Rational Rose (and XDE) Together Jude Poseidon ArgoUML StarUML Many others . . . Copyright © 2003-2006 Eddie Roache. All rights reserved. v1.2

References www.omg.org www.uml.org www.rational.com www.martinfowler.com/books.html#uml www.oreilly.com/catalog/umlnut/ www.oreilly.com/catalog/umlpr/ www.oreilly.com/catalog/learnuml/ http://www.ambysoft.com/elementsUMLStyle.html The Unified Modeling Language User Guide The Unified Modeling Language Reference Manual http://alistair.cockburn.us/usecases/usecases.html Copyright © 2003-2006 Eddie Roache. All rights reserved. v1.2

Questions ???

Class Diagram Fruit Seed Apple Orange Pear Granny Smith Red Delicious * Apple Orange Pear Granny Smith Red Delicious Rome Copyright © 2003-2006 Eddie Roache. All rights reserved. v1.2

Class Diagram Copyright © 2003-2006 Eddie Roache. All rights reserved. Source: OMG, Unified Modeling Language: Superstructure Specification, version 2.0. August 2005 Copyright © 2003-2006 Eddie Roache. All rights reserved. v1.2