introduction to uml - computer and information...

1July 1998 Rev 1.0 Introduction to UML

Introduction to UML

A Practical Approach to Product Development

July 1998 Introduction to UML Slide 2

Description

t This seminar is designed to help you get startedusing the Unified Modeling Language (UML) as avisual design tool using a development process.

t A simple case study is presented to demonstratedomain modeling and design techniques as anintegrated method.

t Familiarity with object technology will enhance theattendee’s understanding of the models, but is notrequired.



Speakers

t Jim Staffordâ DoD Contracting

F OO Mentoring

F UCA Framework SystemEngineering

F Distributed ComputingInfrastructure

â RABA Technologies, Inc

â http://www.raba.com/~jcstaff

â JHU/APL OOP/C++ Instructor

â [email protected]

t Michele Mooreâ DoD Contracting

F OO Mentoring

F Software Development

â RABA Technologies, Inc

â JHU/SCS OOP, C++, Javainstructor

â [email protected]


Objectives

t Introduce UML in the context of a practicalobject-oriented work process

t Introduce a proven object-oriented process

tUnderstand how UML models fit into theprocess

tDiscover how to create UML models



Agenda

t (Day 1) Process and UML: IntroductionâUML Background

âGetting Started with Object Modeling

âModeling At A Glance with UML

âProcess Overview

t (Day 2) Process and UML: InsertionâProcess and UML Applied

âCase Study: Answering MachineâOther Resources


UML Background

tHistory of UML

t The “Methodology Wars”tWhat UML is

tWhat UML is not



History of UML

t Design methods popularized in 70’s & 80’s

t Technical community inundated with models, methodologies,notations by early 90’s

t Standardization was needed, but no one was willing to champion thecause and make it successful; many were opposed to the idea

t OOPSLA ‘94 Grady Booch and James Rumbaugh announced themerging of their methods

t OOPSLA ‘95 revealed the first public description of the UnifiedMethod, with Ivar Jacobson joining the duo

t During 1996, the “Three Amigos” worked on the new method,renaming it as the Unified Modeling Language (UML)

t In January ‘97, UML was proposed to OMG as a standard to facilitatethe interchange of models; UML 1.1 adopted by OMG in Nov ‘97


Methodology Wars of the 90’s

Booch Method - BoochRational

OMT - Rumbaugh, Blaha, Premerlani, Eddy, LorensenGE ACC

OOSE - JacobsonObjectory

Coad/Yourdon - CoadObject International

...Others...



Methodologist Terminology

UML Class Association Generalization Aggregation

Booch Class Uses Inherits Containing

Coad Class &Object

InstanceConnection

Gen-Spec Part-Whole

Jacobson Object AcquaintanceAssociation

Inherits Consists of

Odell ObjectType

Relationship Subtype Composition

Rumbaugh Class Association Generalization Aggregation

Shlaer/Mellor

Object Relationship Subtype N/A


1995 Unified Method from Rational

Unified Method - Booch, RumbaughRational

OOSE - JacobsonObjectory


...Others...



January 1997 UML from Rational

Unified Modeling LanguageObjectory Process - Booch, Rumbaugh

Rational

JacobsonObjectory


...Others...

UML v1.0OMG


November 1997 UML from OMG

Objectory Process - Booch, Rumbaugh, Jacobson

Rational


...Others...

UML v1.1(v1.2 in draft)

OMG



What UML Is

tUML is a modeling language, a notation used toexpress and document designs

tUML unifies the notation of Booch, Rumbaugh(OMT) and Jacobson, and augmented withother contributors once submitted to OMG

tUML proposes a standard for technicalexchange of models and designs

tUML also defines a “meta-model”, a diagramthat defines the syntax of the UML notation


What UML Is Not

tUML is not a method or methodology(Method = Notation (e.g.,UML) + Process)

tUML does not dictate a particular process(although the “Rational Objectory Process” is beingproposed by Booch, Rumbaugh and Jacobson)

tUML can be used to record the resulting domainand design models, independent of the process

tChoose an appropriate process for a particularproject, independent of the modeling language



Why Use UML

t Standardized notation without sacrificingspecialized model data

tCommon language that can be used fromproduct conception to delivery, from system todetailed design levels

tReduced learning curve across projects

t Increased domain and design model reuse

t Increased customer involvement /understandingof problem translation to product solution


Where to Start?

t Identify key domain abstractions … classes integrating:â Attributes

â Behavior (responsibilities, methods)

â MessagingF providing logical independence between client and object

â PolymorphismF providing physical independence between client and implementation

t Consider relationships … integrating classes and objects to formhigher levels of abstractionâ Association (“Uses, Needs”)

â Aggregation (“Has-A”)

â Inheritance (“Is-A”)

t Begin constructing your models



Model Perspectives

tConceptualFBook [Title]

âobjects, “things” from the domain

âconceptual map to implementation

t SpecificationFBookIface { void setTitle(String value); }

âidentifies how to obtain properties

t ImplementationFPersistentBook : BookIface { -> DB }

âidentifies how interface will be implemented


Initial Modeling Results

t List of use cases, describing systemrequirements

tDomain model, capturing your understanding ofthe business process and key domain classes

tDesign model, realizing both the information inthe domain objects and the behavior describedin the use cases

t Add classes in the design model that actuallydo the work and also provide a reusablearchitecture for future extensions



UML Notation Baseline

tUse Case Diagrams

tClass Diagramst Package Diagrams

t Activity Diagrams

t State-Transition Diagrams

t Event Trace (Interaction) DiagramsâSequence Diagrams

âCollaboration Diagrams

tDeployment Diagrams


Use Case Diagrams

t Show the external actors andtheir connection to thefunctionality (use cases) of thesystem

t Use cases provide the basis ofcommunication betweensponsors/customers andimplementers in the planningof a projectâ Capture some user-visible

function

â May be small or largeâ Achieves a discrete goal for the

user

Student

Billing System

Register for Courses



Class Diagrams

t Show the static structure ofthe domain abstractions(classes) of the system

t Describe the types of objectsin the system and thevarious kinds of staticrelationships that existamong themâ Associations

â Derivations

t Show the attributes andoperations of a class andthe constraints for theway objects collaborate

StudentInfo

major

ProfessorInfo

tenureStatus

StudentSchedule

dateUpdated : char*semester : char*

change( )

1

1

NewCourseForm

(from Interfaces)

1

Curriculum

1..*

Course

newCourse( )getInfo( )

1

1

creates

1

1..*

RegistrationUser

nameIDNumber


Package Diagrams

t Shows the breakdown oflarger systems into a logicalgrouping of smallersubsystems (e.g,Coad/Yourdon’s SubjectLayer)

t Shows groupings of classesand the dependencies amongthem

t A dependency exists betweentwo elements if changes to thedefinition of one element maycause changes to the other

UniversityArtifacts

Interfaces

Database

global



Activity Diagrams

t Show the sequential flow ofactivitiesâ typically in an operation

â also in a use case or event trace

t Complement the class diagramby showing the workflow of thebusiness (aka “Flowchart”)

t Encourage discovery of parallelprocesses which helps eliminateunnecessary sequences inbusiness processes

Select Courses

Confirm Availability

for eachchosen course

Buy Book Attend Class


State-Transition Diagrams

t Show all the possible statesthat objects of the class canhave and which events causethem to change

t Show how the object’s statechanges as a result of eventsthat are handled by the object

t Good to use when a class hascomplex lifecycle behavior

Selecting

select a course

Confirming

select a course

courseselected

course notavailable

Registering

Register studentfor courses

all coursesconfirmed

Completed

registrationdb updated



Interaction (Event Trace) Diagrams (1)

Sequence Diagramst Show the dynamic

collaboration between objectsfor a sequence of messagessent between them in asequence of time

t Time sequence is easier tosee in the sequence diagram,read from top to bottom

t Choose sequence diagramwhen only the sequence ofoperations needs to be shown

: Registrarcourse form :

NewCourseFormSales 101 :

Course : Transaction

Manager : DBCourse

ope

set info

submit for processingnewCourse ( )

course

saveCourse ( saveCourse (

getInfo (

Create a course


Interaction (Event Trace) Diagrams (2)

Collaboration Diagramst Show the actual objects and

their links, the “network ofobjects” that are collaborating

t Time sequence is shown bynumbering the message labelof the links between objects

t Choose collaboration diagramwhen the objects and theirlinks facilitate understandingthe interaction, and sequenceof time is not as important

Create a course:Registrar

courseForm:NewCourseForm

Sales101:Course :TransactionMgr

1: open()

4: newCourse()

2: setInfo()3: submit()

5: saveCourse()

: CourseDB

6: saveCourse()

7: getInfo()

8: courseCreated()



Deployment Models

t Show the physical architectureof the hardware and softwareof the system

t Highlight the physicalrelationships among softwareand hardware components inthe delivered system

t Components on the diagramtypically represent physicalmodules of code andcorrespond exactly to thepackages on a packagediagram

Registration System

Database

Dorm Main Building

Library


Process Overview

tConceptualization

tRequirements Definitiont Architecture Design

t Package Development

tDelivery

tMaintenance



Conceptualization(entire system)

tDefine Purpose and Prioritized Features

t “Sketch” Early Domain Class Modelt Identify Use Cases and Primary Paths

t Identify Schedule, Risks, Resources


Domain Class Model Example

1

1

PhoneLine

1

0..*

CallerMessage

2

GreetingAnswer Mode

1

AnsweringMachine

1

1

1

0..*2

1



Use Case Identification Using Activity Diagrams

Answer Phone Line

Play Greeting

UpdateIndicator

Play toOutput Device

Record Caller Message

[Message]

[No Message]

[Call Stopped]

Take CallerMessage


Use Case Identification Example

t Actors: External Caller, External Owner

tUse Case: Answer CallertUse Case: Review Caller Message

tUse Case: Record Greeting

tUse Case: Set Answer Model

tUse Case: Take Caller Message

tUse Case: Play Greeting

tUse Case: Delete Caller Message



Conceptualization Applied

tConsider a University Student RegistrationSystemâIdentify 5 key abstractions, attributes, responsibilities,

relationships

(Eyes on your own paper! :)


Exercise Results



Requirements Definition(per build OR entire system)

t Define Domain Class Model

t Describe Use Cases, Primary & Alternate Paths

t Map Requirements to Classes & Use Cases/Use CasePaths

Results• Documented in an Operational Concept Document (OCD) and

Software Requirements Spec (SRS)• Presented at Software Requirements Review (SRR)

FunctionalRequirement

DataRequirement

Use Case

Use Case Path

DomainClass

breaks down into one or more

helps id

helps id mapped to

mapped to


Domain Class Model Example

1

GreetingGreeting

Play( )

11

0..*

CallerMessageDateTimeCallerReviewedMessage

Record( )Play( )Delete( )

1

PhoneLineRingCount

Answer( )Play( )Listen( )Hangup( )

11

2AnswerModeAnswer Ring

1

11

MailboxTotal MessagesNew Message Count

1

0..*

1

1

Speaker

Play( )

1

AnsweringMachine

1

11

2

11

1

1

<<uses>>

<<uses>>

<<uses>>

<<uses>>



Class Specification ExampleClass: CallerMessage

Messages are recorded from the caller with associated information.

The caller messages are flagged as new until the owner reviews them and are onlydeleted upon specific request.

Attributes:Date Time - The calls is recorded with the date/time at the start of the call.

Caller - The caller is identified by the phone company.Reviewed - Any caller message that has been played is considered reviewed.

Message - Caller message data must contain a message; empty messages aredeleted

Behavior:Record - Caller messages are recorded from the phone line and are terminated when

the caller hangs up, the maximum message length has been reached, or theowner terminates the recording. Empty messages will be ignored.

Play - Caller messages are played to the speaker for the owner to listen to.

Delete - The owner can delete specific messages.Stop - The play or recording of the caller messages can be stopped by the owner.


System Requirements Example

Caller Message1.The Answering System shall provide the capability for an owner to

review a caller message. (Req-2, Review Caller Messages)

2.The Answering System shall output the date and time of the callermessage to the owner on playback. (Req-11, Review Caller Messages)

3.The Answering System shall output the identity of the caller of the callermessage to the owner on playback. (Req-12, Review Caller Messages)

4.The Answering System shall provide the capability for an owner toreview new caller messages only. (Req-14, Review Caller Messages)

…etc.



Requirements Definition Applied

t Identify 5 System Requirements for theUniversity Student Registration System

tDescribe them as specific use cases


Exercise Results



Use Case Diagram at a Glance

Answer Caller

External Caller

Take Caller Message

<<extends>>

Review Caller Message

Set Answer Mode

Delete Caller Message

<<uses>>

Record Greeting

Play Greeting

<<uses>>External Owner

<<uses>>


Use Case Specification Example

Use Case: Answer Callert This use case begins with a caller ringing the

answering machine and completes after thecall has been completed. This use case ismeant to be extended by mode specificprocessing.

t Actors:â Caller

t Pre-conditions:â Answering machine is idle

t Post-conditions:â Greeting is played to callerâ Mode-specific processing is

performed

t Primary Path (Caller Listens toGreeting):1. The caller rings the phone line

connected to the answering machine.

2. The system waits for the ring countto reach the answering ring count.

3. The system plays a greeting.4. The system performs any mode-

specific processing

t Alternate Path (Caller Hangs UpDuring Greeting):â The caller hangs up during the

playing of the greeting. The systemrecognizes the hang-up, stops thegreeting and prepares for the nextcaller.



Architecture Design(entire system)

t Identify package boundaries and allocate primary responsibility ofdomain classes to a package

t Break complex use cases into uses relationships that fit withinidentified packages

t Identify interfaces for domain classes that cross packageboundaries

t Define event traces for key interactions between packages

t Resolve Strategic Issues

Results• Package interactions generated• Define risk-based build schedule• Documented in Software Design Description (SDD); presented at System PDR

Use Case Path

Event TraceConcrete Analysis

Scenario

DomainClass

ids

used to implement

ConcreteUse CaseScenario


Class Packages

AnsweringSystem

+ AnsweringMachine+ AnswerMode+ AnnounceMode+ MessageMode

IODevices

+ InputDevice+ OutputDevice+ PhoneLine+ Microphone+ Speaker

Messages

+ CallerMessage+ Mailbox+ Greeting

Foundation

+ Clock+ Observer



Key Event Trace Example (1)

1. The caller rings the phone lineconnected to the phone line.

2. The phone line reports the event of anew call to the current answer mode.

3-4. The answer mode waits for theowner-specified.

5. The phone line is told to answer thecaller.

6-8. The answer mode plays the greeting.9. The specific answer mode will perform

any mode-specific processing

10. The phone line is hung up.

: External Caller : PhoneLine : AnswerMode : Greeting

1: Ring ( )

2: New Call ( )

3: Ring ( )4: New Call ( )

5: Answer ( )6: Play ( )

7: Play ( )

8: Greeting Complete

9: Answer Complete ( )

10: Hangup ( )

Answer Caller (Caller Listens to Greeting)


Use Case/Event Trace Text Comparison

Event Trace Script1. The caller rings the phone line

connected to the phone line.

2. The phone line reports the event of anew call to the current answer mode.

3-4. The answer mode waits for theowner-specified.

5. The phone line is told to answer thecaller.

6-8. The answer mode plays thegreeting.

9. The specific answer mode willperform any mode-specificprocessing

Use Case Script

1. The caller rings the phone lineconnected to the answeringmachine.

2. The system waits for the ringcount to reach the answeringring count.

3. The system plays a greeting.

4. The system performs any mode-specific processing



Key Event Trace Example (2)

: External Caller : PhoneLine : MessageMode : Mailbox : Speaker : Message

Indicatormessage :

CallerMessage

3: Create (caller, timeOfCall)

2: CallerId ( )

4: Record (InputDevice)

5: Listen ( )

6: Play ( )

7: Disconnect ( )8: Caller Message Complete

9: Record (message)10: New Message ( )


Take Caller Message (Caller Leaves Message)


Package Requirements Example (1)

1. The Answering System shall provide the capability for an owner to review acaller message. (Req-2, Review Caller Messages)â The IODevices Package shall provide the capability to play audio to a speaker.

(Pkg-4)

â The Messages Package shall provide the capabiliy to play caller messages to anoutput device. (Pkg-10)

2. The Answering System shall output the date and time of the caller messageto the owner on playback. (Req-11, Review Caller Messages)â The Foundation Package shall provide the capability to obtain the time of day.

(Pkg-1)

â The Messages Package shall timestamp caller messages with the time of the call.(Pkg-13)

â The Messages Package shall play the time of day when a caller message isplayed. (Pkg-19)



Package Requirements Example (2)

3. The Answering System shall output the identity of the caller of the callermessage to the owner on playback. (Req-12, Review Caller Messages)â The IODevices Package shall provide the capability to obtain the identity of the

caller. (Pkg-8)

â The Messages Package shall record the identity of the caller. (Pkg-14)â The Messages Package shall output the identity of the caller when a caller

message is played. (Pkg-20)

4. The Answering System shall provide the capability for an owner to reviewnew caller messages only. (Req-14, Review Caller Messages)â The Messages Package shall provide the capability for an owner to review new

caller messages only, (Pkg-17)


Package Development

t Class Design (per customer build)â Identify internal design classes and their

interfaces

â Define Method Traces

â ResultsF Documented in SDDF Presented at CDR

t Class Implementation(per internal build)â Implement classes

â Unit & Integration Testing

t Package Integrationâ Software Integration Testing (SWIT)

Event Trace

Concrete Analysis Scenario

Method Trace

Concrete Design Scenario

ClassDesign

ids details for

used to implement

tested by

tested by

Codeids context for



Class Design Example

InputDevice

Listen( )Initialize( )Audio( )Terminate( )

speaker

0..1

OutputDevice

Play( )Initialize( )Terminate( )

PhoneLine

RingCount

Hangup( )Answer( )Listen( )Play( )Ring( )Disconnect( )CallerId( )Initialize( )

0..1

Observer

Notify( )

(from Foundation)

AudioSample

PhoneLineImpl

MicrophoneImpl SpeakerImpl


Method Trace Example

: External Caller

: PhoneLine

: AnsweringMachine

: MessageMode : CallerMessage

: Mailbox

G

1: Ring

F

F

2: notify ( int, void*)

F

F

3: newCall ( )5: CallerMessage (callerId , dateTime)

6: record (InputDevice&)

P

4: callerId ( )7: listen ( )

Audio

P

8: record (CallerMessage&)

F

F

P

PP

G F

F

F

F

F

F

L

Take Caller Message



Delivery(per build)

t Integrate Changes

t System TestingtDevelop/Update User Documentation

t Field System

t Track Error Reports

tDeployment Diagrams


Maintenance

tCollect Change/Enhancement RequestsâPrioritize

âGroup

t Enter the Process Spiral Again



Overall Process Mapping

FunctionalRequirement

DataRequirement Use Case

Use Case Path

Event TraceConcrete Analysis

Scenario

Method TraceConcrete Design

Scenario

DomainClass

ClassDesign

breaks down into one or more

helps id

helps id

ids

used to implement

ids details for

used to implement

tested by

tested byCode ids context for

mapped tomapped to

Concrete Use CaseScenario

tested by


Process Roles

t Requirements

t Use Cases

t Use Case Paths

t Domain Classes

t Event Traces

t Class Designs

t Message Traces

t Code

t Unit Test

t Integration Test

t Acceptance Testing

t Customer

t Customer Representative

t System Engineer

t Software Architect

t Subsystem Lead

t Developer

t Subsystem Lead

t System Engineer



Session 2: Process Insertion

t Process Goals / ResultsâConceptualization

âRequirements Definition

âArchitecture Design

âPackage Development

âDelivery

âMaintenance

tUML In ActionâCase Study: Answering Machine System


Conceptualization/Requirements Definition Models

tDomain Class Model

tUse Case Modelst Activity Diagrams

tRequirements Management


Class Models

Conceptual Level


Class Model Overview

t Shows static properties of a Class

tDepicted graphically in Class Diagrams andtextually in Class Specifications

tMay be organized into Packages

tClass DiagramsâShow an aspect of a set of Classes

âNeed not contain entire Package

âNeed not be restricted to Package boundaries



Packages

AnsweringSystem

IODevices Messages

Messages


t Grouping of modelelements (including non-class models)

t Can be nested

t Lists classes (optional)contained within packageâ + Public Visibility

â -/# Non-public Visibility


Class Symbols

t Solid rectangle

t Three compartmentsâ Class Name and general

properties (optional)F Package (Package::)

F Stereotypes (<< >>)

F Constraints ({ } )

F Meta-model attributes

â Attributes (optional)

â Operations (optional)

t Additional compartmentsallowed

CallerMessage

Mailbox{ author=“bob” }

Greeting

<<controller>>AnsweringSystem::AnswerMode

IODevices::OutputDeviceresponsibilitiesOutput Audio

IODevices::InputDevice

AnsweringMachine{1}



Class Descriptions

Class: CallerMessage

Caller Messages are recorded from the caller withassociated information. The caller messagesare flagged as new until the owner reviews themand are only deleted upon specific request.


Adding Class Properties

t Attributesâ Describing data properties

of a class

t Operations (Behaviors)â Describing localized

behavior of a class

CallerMessage

DateTimeCallerReviewedMessage

Record( )Play( )Delete( )Stop( )



Property Descriptions

Class: CallerMessage

t AttributesâDateTime - The caller message is recorded with the

date/time at the start of the call.

t Behaviors (Operations)âRecord() - Caller messages are recorded from the

phone line and are terminated when the caller hangsup, the maximum message length has been reached,or the owner terminates the recording. Emptymessages will be ignored.


Adding Relationships

Shown as an attribute Shown as an Association

AnsweringMachine

Greeting

AnswerMode

1

1

2

1

2

1

1

1

Answer Modes

AnsweringMachine

Answer Modes [2]

Greeting

AnswerMode



Associations

t Name (optional)further describes association

between members

t Rolesrole played by associated memberâ namedâ unnamed

t Multiplicityquantity of associated memberâ unspecifiedâ 1 - mandatoryâ 0..1 - optionalâ 0..* (or *) - manyâ # - specified value or range

AnsweringMachine

Greeting

Answer Mode

AnswerMode

1

1

2

1

2

1

1

1

Answer Modes

actions are controlled by


Reading Associations

An AnsweringMachine has “2”modes

The related AnswerModes play the roleof the AnsweringMachine’s “AnswerModes”

An Answer Mode isassociated with “1”Answering Machine

The Greeting plays therole of a “Greeting”

There is “1” Greetingper Answer Mode

A Greeting isassociated with “1”Answer Mode

AnsweringMachine

Greeting

Answer Mode

AnswerMode

1

1

2

1

2

1

1

1

Answer Modes

actions are controlled by

Answering Machine“actions are controlledby” Answer Modes



Adding Properties to Associations

Person

NameSSN

Company

Name0..*0..*0..* 0..*

Employment

Employment

Hire DateTermination DateSalary

Person

NameSSN

Company

Name0..*0..*0..* 0..*

Use Attributed Class to addproperties unique to theassociation between two classes

Use named/unnamed associations where there areno properties unique to the association betweentwo classes


Adding Constraints on Associations

Person

CallerMessage

Organization

{or}

The caller willbe identified aseither a personor anorganization



Adding Aggregation to Associations

CallerMessage

Mailbox

0..*

1

0..*

1

CallerMessage

Mailbox

0..*

1

0..*

1

t Aggregation (open diamond)â shows side of association that

represents the aggregate

t Composite (filled in diamond)â A refinement of aggregation

showing the aggregate havingownership of the member

Aggregation

Composite


Adding Uses Dependency Association

t Uses Relationshipdependency shown with

<<uses>> stereotypeâ shows a usage relationship

between associated classes

â the association is temporary(created and forgotten duringthe completion of a behavior)

InputDevice

OutputDevice

CallerMessage

<<uses>>

<<uses>>

t Dependency Relationshipshown by dashed directed

arrow



Association Descriptions

Class: CallerMessaget Associations:

âMailbox [1] - Caller messages are assigned to aparticular mailbox.

Class: Mailboxt Associations:

âCallerMessage [0..*] - A mailbox contains all callermessages until they are deleted.

tUses:âOutputDevice - Caller Messages are played to the

specified output device.


Inheritance

t Indicates type/sub-typeâ derived classes (sub-type)

comply with base class(type) interface definitions

t Indicates class/sub-classâ derived classes (sub-class)

reuse or extend base class(class) implementation

Microphone

Listen( )

Speaker

Play( )

PhoneLine

RingCount

Hangup( )Answer( )Listen( )Play( )

InputDevice

Listen( )

OutputDevice

Play( )



Reading Inheritance

Microphone

Listen( )

Speaker

Play( )

PhoneLine

RingCount


InputDevice

Listen( )

OutputDevice

Play( )

InputDevice isthe base class ofMicrophone andPhoneLine

Microphone“is-a” type ofInputDevice

PhoneLine “is-a” typeof InputDevice andOutputDevice


Inheritance Descriptions

Class: OutputDevice

t Behaviors:âPlay() - Output devices can play audio.

Class: PhoneLine

t Inheritance:âOutputDevice, InputDevice

t Behaviors:âPlay() - Audio can be played to the phone line until

the caller or system hangs up.



Example: Answering Machine Packages

AnsweringSystem

+ AnsweringMachine+ AnswerMode+ AnnounceMode+ MessageMode

IODevices

+ InputDevice+ OutputDevice+ PhoneLine+ Microphone+ Speaker

Messages



Example: IODevices Package

Microphone

Listen( )

Speaker

Play( )

PhoneLine

RingCount


InputDevice

Listen( )

OutputDevice

Play( )



Example: Messages Package

InputDevice

OutputDevice

0..*

CallerMessageDateTimeCallerReviewedMessage

Record( )Play( )Delete( )Stop( )

<<uses>>

<<uses>>

1

1

Mailbox

Total MessagesNew Message Count

Record( )Play( )

0..*

1

1

1

AnsweringMachine

11

2

1

Greeting

Answer ModeGreeting

Record( )Play( )Stop( )

<<uses>>

<<uses>>

1

AnswerMode

1

2

1

1


Example: Answering System Package

PhoneLineMessageMode

Max Message Length

New Call( )

AnnounceMode

1

Greeting

1

12

AnswerMode

Answer Ring

New Call( )

1

1

1

Mailbox1

1

1

1

1

Speaker

1

AnsweringMachine

12 1

1

1

1

1

1

1 Microphone

1

1


Use Cases

Specifications andUse Case Diagrams


Use Case Overview

tRepresents the functionality of the system (orclass) as seen by the external user



Use Case Diagram Elements

t Use Caseshown by oval with name inside or

below oval - may also containcompartment for extension points

â unit of useful functionalityprovided by system

â sequence of actions

External Owner External Caller

Review CallerMessage

Take Caller Message

t Actorshown by a stick figure with name

â role of an object or objectsexternal to the system

â one object may play manyroles

Answer Caller

extension pointsmode-specific processing


Use Case Specification

Use Case: Answer CallerThis use case begins with a caller ringing the answering machine and completes after

the call has been completed. This use case is meant to be extended by modespecific processing.

t Pre-conditions:â Answering machine is idle

t Post-conditions:â Greeting is played to callerâ Mode-specific processing is performed

t Primary Path (Caller Listens to Greeting):â 1.The caller rings the phone line connected to the answering machine.â 2.The system waits for the ring count to reach the answering ring count.â 3.The system plays a greeting.â 4.The system performs any mode-specific processing

t Alternate Path (Caller Hangs Up During Greeting):â The caller hangs up during the playing of the greeting. The system recognizes

the hang-up, stops the greeting and prepares for the next caller.



Adding Use Case Relationships

Answer Caller

Take Caller MessagePlay Greeting

External Caller

<<extends>>

<<uses>>

Uses

Extends

Communicates


Adding Use Case Relationships

Answer Caller

Take Caller MessagePlay Greeting

External Caller

<<extends>>

<<uses>>

Communicates• participation of anactor in a use case• the onlyrelationship betweenan actor and a usecase

Uses• specifies that theusing use case willalso include behaviorof the use use case

Extends• the extended usecase may containbehavior specified byextending use case



Communicates Relationship

t Participation of an actorin a use case

t This is the onlyrelationship betweenactors and use cases

Answer Caller External Caller

Participates in

Actor:External Caller

Use Case:Answer Caller


Uses Relationship

t Specifies that the usinguse case will also includebehavior of the used usecase

Answer Caller

Play Greeting

External Caller

<<uses>>

Used Use Case: Play Greeting

Using Use Case: Answer Caller

includes the same behavior specified in



Extends Use Case

t The extended use casemay contain behaviorspecified by extendinguse case

Answer Caller

Take Caller Message

External Caller

<<extends>>

Extended Use Case: Answer Caller

may contain the behavior specified by

Extending Use Case: Tale Caller Message


Specifying Use Case Relationships

Use Case: Answer Caller

t Actor:âExternal Caller

tUses:âPlay Greeting

t Extension PointsâMode-specific process will be performed after

greeting is complete.



Example: Answering Machine Use Diagram

Answer Caller

External Caller

Take Caller Message

<<extends>>

Review Caller Message

Set Answer Mode

Delete Caller Message

<<uses>>

Record Greeting

Play Greeting

<<uses>>External Owner

<<uses>>

Activity Diagrams



Activity Diagram Overview

tRepresents the state of a procedureâEach state represents a step in the procedure

âThe exit event from the state is the completion of theprocedure

t Shows a workflow ofâUse Cases (Requirements Definition)

âOperations (Package Specification)

tCan show concurrency


Answer Phone Line

Play Greeting

UpdateIndicator



[Message]

[No Message]

Answering System Example

[Call Stopped]

Take CallerMessage



Activity Diagram Symbols

Synchronization Bar

GuardDecision Activity

Answer Phone Line

Play Greeting

UpdateIndicator



[Message]

[No Message]

ActivityInitial State

End State

State Transition

SynchronizationCondition

[Call Stopped]


Review Messages

Multiple Triggers

Play Message

* Multiple Trigger



Object Flows

Answer Phone Line

Play Greeting

UpdateIndicator



[Message]

[No Message]

Message[new]

Object

[Call Stopped]


Swim Lanes

Answer Phone Line

Play Greeting

UpdateIndicator



[Message] [No Message]

Answering System Messages IO Devices

[Call Stopped]



Architecture Design: Results

tClass Models

tMethod Tracest Event Traces

t State Models

tComponent Models

tDeployment Models

Class Design Models

Specification andImplementation Levels



Class Design Model Overview

t SpecificationâDefine interfaces to software implementing the

domain class model

t ImplementationâShows where and how implementations are

performed


Packages

t Begin to identifyclasses that define theinterface and thepublic/non-publicclasses that implementthose interfaces

Foundation+ Observer

IODevices

+ AudioSample+ InputDevice+ OutputDevice+ PhoneLine- PhoneLineImpl- MicrophoneImpl- SpeakerImpl



Class Symbols

t Indicateâ Types (interface)

F defines the signatures ofhow to communicate withall sub-types

â Base Classes (abstract)F also defines a type

F defines propertyimplementations to beinherited by sub-classclass

<<interface>>Observer

notify() : void

message : AudioCut

Message{Abstract}

play(device: OutputDevice) : void

device.play(message)


Class Symbols

t Parameterized(templates) Classesâ Defines type-independent

template structure andalgorithms

t Instantiated Classesâ Binds template to a data

type

T

vector

Audio

<<bind>><AudioSample>

vector<AudioSample>



Adding Class Properties

t get()/set() operationsadded for public attributeproperties

t public (+), protected (#),and private (-) accessesdesignated for allproperties

t specify scopeâ object (no underline)

â class (underlined)

PhoneLineImpl

#deviceAddress_ : long#model : string

+play (audio : Audio) :

<<interface>>OutputDevice

+play (audio : Audio) :

<<interface>>PhoneLine

+hangup () :


Attribute/Operation Descriptions

Class: PhoneLineImpl

t Attributesâ-deviceAddress_ : long

Contains the i/o port number for the modem

tOperations:â+virtual play(audio : Audio) throw(NotReady, Hangup)

Plays the vector of audio samples to the modem. Will throw aNotReady exception if the modem is not ready or a Hangupexception if the line is hung-up during the play.



Refining Relationships

Message

<<interface>>OutputDevice

play (audio : Audio) : void

PhoneLineImpl

deviceAddress : long

play (audio : Audio) : voidhangup () : void

Message

OututDevice

PhoneLineImpl



MessagePhoneLineImpl



t Implementations will beput together at run-time

t Using implementationswill be coupled to a sub-set (interface) of the usedimplementation’scapabilities

t UML offers a shorthandinterface notation

Interaction Diagrams

Sequence andCollaboration Diagrams



Interaction Diagram Overview

t Shows interaction between objectst Varying levels of detail

âEvents (Event Trace*)âMethods (Method Trace*)

t Sequence DiagramâVisually arranged in time-order of messagesâShows lifeline of objects

tCollaboration DiagramâVisually arranged around objectsâShows object relationships

* non-UML terms


Sequence Diagram

time

objects

: Device Player : OutputDevice

: External Listener

2: Play ( )

4: Terminate ( )

1: Initialize ( )

3: Audio ( )Message

ReturnMessage (optional)

Activation(focus of control) Label



Adding Guard Conditions

t Places a restriction onthe send of a message

t Each branch is labeledwith a [guard]

:MessageMode

:CallerMessage

:Mailbox

Record

[Message Not Empty]Record(CallerMessage)

[Message Empty]


Adding Concurrency

:MessageMode

:PhoneLine

Listen()Play()Stop()



Adding Object Lifeline

:MessageMode

:CallerMessage

Create

Record

:ControlPanel

Play

Delete

Object is created

Object is deleted


Example: Answer Caller

: External Caller : PhoneLine : AnswerMode : Greeting

1: Ring ( )

3: Ring ( )

2: New Call ( )

4: New Call ( )

5: Answer ( )


10: Hangup ( )

6: Play ( )

7: Play ( )

8: Greeting Complete



Example: Take Caller Message

: External Caller : PhoneLine : MessageMode : Mailbox : Speaker : (Message

Indicator)message :

CallerMessage

7: Disconnect ( )

2: CallerId ( )


9: Record (message)10: New Message ( )

3: Create (caller, timeOfCall)

4: Record (InputDevice)

5: Listen ( )

6: Play ( )

8: Caller Message Complete


Collaboration Diagram

t Show Collaborationâ Context (structure,

relationships, ...) in whichinteractions occur

t Show Interactionsâ Message sequencing

between objects

t Object format

: Device Player

: OutputDevice

: External Listener

1: Initialize ( )2: Play ( )

3: Audio ( )

4: Terminate ( )

MessageObject

Relationship

classRoleName : Classifier



Adding Other Elements

: Device Player

Play ( )

: OutputDevice Devices

Multi-object

:MessageMode

Create ( )

: CallerMessage { new }

Object Lifetime ({new}, {deleted}, {transient})

Visibility Specification<<global>> - global (global to related object)<<field>> - attribute of related object)<<parameter>> - passed as temporary to related object<<local>> - created within method of related object


Example: Answer and Take Caller Message

: External Caller

: PhoneLine

: AnsweringMachine

: MessageMode : CallerMessage

: Mailbox

G

1: Ring

F

F

2: notify ( int, void*)

F

F

3: newCall ( )5: CallerMessage (callerId , dateTime)

6: record (InputDevice&)

P

4: callerId ( )7: listen ( )

Audio

P

8: record (CallerMessage&)

F

F

<<global>> <<fieldl>>

<<field>>

<<field>>

<<field>>

<<field>>

<<field>>

<<local>>

<<parameter>>

<<parameter>><<parameter>>


State Diagrams


State Diagram Overview

t Shows sequence of states an object goesthrough in response to a stimuli

t Shows actions and activities performed andevents issued

t Allows identification of missingâAttributes - to remember states

âBehaviors - to receive events



Caller Message Example

Recording

entry: set date/timeentry: set caller id

do: ^InputDevice.Listen

New

Hangup[ Message not empty ]

Reviewed

Playing

do: ^OutputDevice.Play

Idle

DeletedHangup[ Message empty ]

Play / set reviewed = true

Playing


Idle

PlayComplete

Delete

Record


State Diagram Elements

Recording




Hangup[ Message empty ]Record

StateEvent

Start

Guard Condition

Action

Activity

Event

Transition

End



Key Diagram Elements

t TransitionâEvent arg-list [ guard condition ] / action expression

t Action - atomic, non-interruptibleâentry / expression

âexit / expression

âSend ActionF^Target Object.Message(arguments)

t Activity - on-goingâdo / expression


Transition/Entry Actions

New Reviewed

entry: ^OutputDevice.Play


Play

An Action taken on Play from New State

Self-Transition

An Action taken no matter how state entered



Composite States


Reviewed

Playing


Idle



Playing


Idle

PlayComplete

Delete


Concurrent States

Taking Message

Recording

Playing to Output Device

Recording

Playing to Output Device



Updating Class Model

Recording



New


Reviewed

Playing


Idle



Playing


Idle

PlayComplete

Delete

Record

CallerMessage

CallerReviewedDateTime

Record( )Play( )Delete( )

Deployment Diagrams



Deployment Diagram Overview

t Shows mapping of software components tohardwareânode - a computer

âconnection - a link between nodes

âcomponents - physical modules of code

âdependencies - show communication betweencomponents


Deployment Diagram

Messages

AnsweringSystem

IODevices

Node Dependency

Workstation

PhoneCompany

Connection

Components



Refining Dependencies into Interfaces

AnsweringSystem

MessagesIODevices

InputDevice

OutputDevice

PhoneLine

Greeting

CallerMessage

MailboxInterface


UML and Design Patterns

tUse patterns to describe the key ideas in thesystem

tDocument the designs that have beendiscarded; sometimes it is just as important toknow why certain patterns/ideas are not beingused

tUse UML to capture the pattern’s context forsolving this domain problem



Modeling and UML

tWhat makes a good model?

tWhen to apply UMLtHow to apply UML


Summary

t UML is a modeling language that can be used totallyindependent of the development process

t UML has been adopted by the OMG and is quicklybecoming the notation of choice for visual modeling

t UML Resourcesâ http://uml.systemhouse.mci.com (OMG UML info)â http://www.awl.com/cp/awweb.htm (survey of analysis and design methods)â http://st-www.cs.uiuc.edu/users/patterns/patterns.html,

http://c2.com/ppr/index.html (Patterns info)â http://www.rational.com/uml/documentation.html (Rational doc)â http://www.rational.com/products/rose/seed (Rational CASE tools)

introduction to uml - computer and information...

Documents