Unified Modeling Language (uml)

Unified Modeling Language (UML) • Created by Grady Booch, Jim Rumbaugh & Jacobson - 1994 • The Unified Modeling Language is a visual language for specifying, constructing and documenting a system – Visual: diagram

• 3 perspectives of using UML – Conceptual or informal and incomplete – Specification or detailed design or blueprint – Implementation specific or programming language

Unified Modeling Language (UML) Categories of Diagrams • Structural – Use Cases, Class diagrams, Object diagrams, Collaboration diagrams

• Behavioral – Sequence diagrams, State diagrams, Activity diagrams

• Grouping – Package diagrams, Component diagrams, Deployment diagrams

Use Cases • Use Cases are text stories to discover and record requirements • Use Cases are requirements, primarily functional or behavior to describe what the system will do • They emphasize the user goals and perspectives • Owing to their simplicity, Customers can write (or participate in writing) the Use Cases

Use Cases • Actor: something with behaviour, such as a person, computer system, or organization e.g. a cashier.

• Scenario: specific sequence of actions and interactions between actors and the system under discussion e.g. the scenario of successful purchase of items with cash

• Use case: a collection of related success and failure scenarios that describe actors using a system to support a goal.

Actors • Primary Actor: has user goals for the SuD (System under Discussion) e.g. a cashier.

• Supporting Actor: provides a service (eg. Information) to the SuD e.g. a credit card payment authorization

• Offstage Actor: has an interest in the behavior of the use case (not primary or supportive) e.g. a Government tax agency

Use Case formats • Brief: Terse one paragraph summary e.g. A customer arrives at a checkout with items to purchase. The cashier uses the POS system to record each purchased item, present line-item details and a running total. The customer enters payment information and system will validate and record the sale. System updates the inventory.

Use Case formats • Casual: provides more details handling some failure modes e.g. Handle returns Main success scenario: A Customer arrives at a checkout with items to return. The Cashier uses the POS system to record each returned item… Alternate scenarios: If the credit authorization is reject, inform Customer and ask for an alternative payment method. If item identifier not found in the system, notify the Cashier and suggest manual entry of the identifier code

Use Case formats • Fully Dressed: elaborate. All steps and variations are written in detail, with preconditions and postconditions e.g. - Use case UC1: Process Sale (Start with verb) Primary Actor: Cashier Stakeholders and Interests: -Cashier: Wants accurate and fast entry, no payment errors, … -Salesperson: Wants sales commissions updated. …..Customer, Manager, Company, Credit agency, Tax agency…..

Use case UC1: Process Sale contd Preconditions: Cashier is identified and authenticated. Success Guarantee (Postconditions): -Sale is saved. Tax correctly calculated. … Receipt generated, Inventory, Commission updated Main success scenario (or basic flow): [see next slide] Extensions (or alternative flows): [see next slide] Special requirements: Touch screen UI, robust recovery, Technology and Data Variations List: -Identifier entered by bar code scanner,… Open issues: What are the tax law variations? …

Use case UC1: Process Sale contd • Main success scenario (or basic flow): – The Customer arrives at a POS checkout with items to purchase. – The cashier records the identifier for each item. If there is more than one of the same item, the Cashier can enter the quantity as well. – The system determines the item price and adds the item information to the running sales transaction. The description and the price of the current item are presented. – On completion of item entry, the Cashier indicates to the POS system that item entry is complete.

Use case UC1: Process Sale contd • Main success scenario (or basic flow): contd – On completion of item entry, the Cashier indicates to the POS system that item entry is complete. – The System calculates and presents the sale total. – The Cashier tells the customer the total. – The Customer gives a cash payment (“cash tendered”) possibly greater than the sale total. • Extensions (or alternative flows): – If invalid identifier entered. Indicate error. – If customer didn’t have enough cash, cancel sales transaction.

Goals and Scope of a Use Case • At what level and scope should use cases be expressed? – A: Focus on uses cases at the level of elementary business process (EBP). • EBP: a task performed by one person in one place at one time which adds measurable business value and leaves the data in a consistent state. – Approve credit order - OK. – Negotiate a supplier contract - not OK. • It is usually useful to create separate “sub” use cases representing subtasks within a base use case. – e.g. Paying by credit card

Finding primary actors, goals and use cases • Choose the system boundary • Identify primary actors – Those that have user goals fulfilled through using services of the system • For each actor identify their user goals – Tabulate findings in the Vision artifact (next slide) • Define use cases that satisfy user goals: name them according to their goal

Vision Artifact Actor

Goal

Actor

Goal

Cashier

Process sales Handle returns Cash in Cash out ----

System Administrator

Add users Modify users Delete users Manage security Manage system tables ----

Manager

Start up Start down

Sales Activity System

Analyze sales & performance data

Use Case Diagram system boundary

communication

NextGen POS

Process Sale Customer

Payment Authorization Service

Handle Returns actor

«actor» Tax Calculator

Cashier

Cash In

«actor» Accounting System

Analyze Activity

«actor» HR System

Manager «actor» Sales Activity System 

Manage Security

System Administrator

Manage Users

. . .

use case

alternate notation for  a computer  system actor

Domain Model • Domain Model – Most important classic model in OO Analysis (Business Object Model) – Illustrates meaningful concepts in the problem domain – Representation of real-world things (Concepts), not software components – It is a set of static structure diagrams, containing all the important players (No operations are defined) – It may show: • Concepts • Associations • Attributes

Domain Model • A Domain Model is a description of things in the real world

Item

* Stocked-in 1

• A Domain Model is not a description of the software design

Store Address Name

• A concept is an idea, thing, or object.

Domain Model • Visualization of things in the Domain – – – – –

Visual dictionary A picture of Business Objects, not of software objects Does not contain responsibilities or methods Is not a data model Why Domain Model

Usecase Model

Domain Model

Design Model

Package Diagrams • Used to illustrate the Logical Architecture • Package name placed in the main folder or if inner members shown on the tab • Dependency between packages shown by dashed lines UI

Swing

Domain

Web

Sales

Object Model • Dynamic Object Models – Interaction Diagrams (Sequence Diagrams and Communication Diagrams) help design logic, behavior of code and methods – Most important since they clarify exact details of what objects need to exist and how they collaborate via messages and methods

• Static Object Models – Design Class Models – Package Diagrams and Deployment Diagrams

Sequence Diagrams :ClassAInstance

:ClassBInstance

Message1() Message2()

Message3()

Sequence diagrams • illustrate interactions in a kind of fence format with a flow sequence • Set of all operation contracts defines system behaviour • Consumes horizontal space

Communication Diagrams • Communication diagrams • illustrate how objects interact via messages • compact

Message1()

:ClassAInstance Message2() Message3()

:ClassBInstance

• Collaboration diagrams • illustrate object interactions in a graph or network format

Sequence Diagrams :Register

• Lifeline boxes and vertical lifelines • Activation bar for focus of control • Messages – time organized • Reply messages • Self messages • Create & destroy

:Sale

NewSale() makeSale() total()

createPayment() :Payment clear

destroy()

X

Loops :A

:B makeNewSale()

loop

enterItem()

[more]

alt

[x<10] [else]

descTotal()

calculateA() calculateB()

• loop – with condition • opt – optional on condition • alt – alternate on condition • par – parallel • region – critical with only one thread

Class Diagrams • Created in design, it is a diagram showing classes, their innards, and the associations between them • It is a final version of a conceptual diagram; A class diagram differs from a Domain Model by showing software entities rather than realworld concepts (Class diagrams in Design are referred to as DCD or Design Class Diagrams) • Once the interaction diagrams have been completed it is possible to identify the specification for the software classes and interfaces

Design Model Classes • Innards of a Class – Class Name – Attributes – Methods • The attribute must contain its class or data type • The method must contain the class or data type of its return variable

Sale date : Date isComplete : Boolean time total() : Currency

Relationships between Classes • Relationships in a class diagram – Aggregation (Whole part relationships) – Inheritance (Derived or child classes) – Association (Link two classes)

Aggregation • Aggregation expresses container classes

Sale date : Date

total() : Currency

Payment amount : Currency

Inheritance • Inheritance allows reuse

Payment amount : Currency

CreditPayment creditCardNumber : int expirationDate : Date

CashPayment amountTendered : Currency

Associations • • • •

There can be many kind of associations They all link two classes Role names are assigned Their purpose is to indicate visibility

Register

Sale Date isComplete:Boolean 1 Captures 1 time

addLineItem(…) ……

makeLineItem(..)

Influence of Interaction Diagrams on Class Diagrams :Register

:Sale makeSale()

• Classes identified in Interaction diagrams are declared in the class diagrams • Messages in Interaction Diagrams indicate methods in nthe Class Diagrams Register

Sale

currentSale 1 makePayment(…) ……

makePayment(..)

Finding Associations –Common Associations List Category Examples A is a physical/logical part of B SalesLineItem - Sale A is physically contained in/on B POS - Store A is logically contained in B ItemDescription - catalog A is a description of B ItemDescription - Item A is a line item of a transaction or report B SalesLineItem - Sale A is known/logged/recorded/ captured in B Sale - POS A is a member of B Cashier - Store ... * High-priority associations

Multiplicity Stocks

POS 1

Sale

*

T * T

T 5

1..*

T

T 1..40

3,5,8

• Multiplicity defines how many instances of a type A can be associated with one instance of a type B, at a particular moment in time • For example, a single instance of a Store can be associated with “many” (zero or more) Item instances

Naming Associations Store 1

Contains 1..*

POS 1

Captures 1..* Paid-by Sale 1

• Name an association based on a TypeName-VerbPhraseTypeName format • Association names should start with a capital letter • A verb phrase should be constructed with hyphens • The default direction to read an association name is left to right, or top to bottom.

1

CreditCard

Multiple Associations Between Two Types • It is not uncommon to have multiple associations between two types • In the example, not every flight is guaranteed to land at an airport.

* Flight

Flies-to

0..1

Air[port

Flies-from *

1

Attributes • An attribute is a logical data value of an object • Include the following attributes: those for which the requirements suggest or imply a need to remember information. • For example, a Sales receipt normally includes a date and time • The Sale concept would need a date and time attribute Sale date time

Valid Attribute Types • Keep attributes simple • The type of an attribute should not normally be a complex domain concept, such as Sale or Airport • Attributes in a Domain Model should preferably be: o Pure data values: Boolean, Date, Number, String, … o Simple attributes: color, phone number, zip code, universal product code (UPC), ... Cashier

Cashier

name currentRegister

name

Invalid – not simple attribute

Register uses

Number

NextGen POS Domain Model Records­sale­of  Ledger

1

Product Catalog 1

Sales LineItem quantity

1 1..*

Contained­in

Paid­by 1 CashPayment

amountTendered

1

1

1

Describes

*

Stocks

Item

*

1..*

Houses

1..* Register

Captured­on 1 0..1

dateTime / total

itemID description price

*

name address

*

Sale

1..*

Used­by

Store

Logs­ completed

1

1

1

Records­ accounts­ for

0..1

1

Contains

Product Description

Is­for

id 1  Works­on

1

1

Customer

Cashier id

System Behavior and System Sequence Diagrams (SSDs) • A sequence diagram is a picture that shows, for a particular scenario of a use case, the events that external actors generate, their order, and possible inter-system events • All systems are treated as a black box; the diagram places emphasis on events that cross the system boundary from actors to systems

SSD for a Process Sale scenario system as black box the name could be "NextGenPOS" but "System" keeps it  simple the ":" and underline imply an instance, and are explained in a  later chapter on sequence diagram notation in the UML external actor to  system

Process Sale Scenario

:System

: Cashier makeNewSale a UML loop  interaction  frame, with a  boolean guard  expression

loop

[ more items ]

enterItem(itemID, quantity) description, total

endSale return value(s)  associated with the  previous message an abstraction that  ignores presentation  and medium    the return line is  optional if nothing is  returned

total with taxes makePayment(amount) change due, receipt

a message with   parameters it is an abstraction  representing the  system event of  entering the  payment data by  some mechanism

Use Case Diagram system boundary

communication

NextGen POS

Process Sale Customer

Payment Authorization Service

Handle Returns actor

«actor» Tax Calculator

Cashier

Cash In

«actor» Accounting System

Analyze Activity

«actor» HR System

Manager «actor» Sales Activity System 

Manage Security

System Administrator

Manage Users

. . .

use case

alternate notation for  a computer  system actor

SSDs derived from use cases : Cashier

makeNewSale

Simple cash­only Process Sale scenario: 1. Customer arrives at a POS checkout  with goods and/or services to purchase. 2. Cashier starts a new sale. 3. Cashier enters item identifier. 4. System records sale line item and  presents item description, price, and  running total.  Cashier repeats steps 3­4 until indicates  done. 5. System presents total with taxes  calculated. 6. Cashier tells Customer the total, and  asks for payment. 7. Customer pays and System handles  payment. ...

Process Sale Scenario

loop

[ more items ]

enterItem(itemID, quantity) description, total

endSale total with taxes makePayment(amount) change due, receipt

:System

Naming System Events and Operations • The set of all required system operations is determined by identifying the system events – – – –

makeNewSale() addLineItem(itemID, quantity) endSale() makePayment(amount)

Choosing events and names

better name

:System

: Cashier enterItem(itemID, quantity)

scan(itemID, quantity) worse name