SWE513 Spring 2010-UML Tutorial.v2

8/3/2019 SWE513 Spring 2010-UML Tutorial.v2

1/136

Unified ModelingUnified Modeling

LanguageLanguage

SWE 513

UML tutorialPart I

Grkan Gr


2/136

AgendaAgenda

General Software Modeling General UML

UML Diagrams

Functional Requirements Structure

Behavior

Design patterns (optional)

2SWE513 Spring 2010 - UML tutorial Part I


3/136

ResourcesResourcesThese slides are a mashup from different sources, i.e. all the

credits go to them..

Sommervilles book: Software Engineeringlecture slides

Genix UML tutorial:http://www.genixcorp.com/ba/uml.ppt

Tom Hortons Object-Oriented Analysis and Design lecturematerial: http://www.cs.virginia.edu/~horton/cs494/slides/

Amblers book: The Object Primer

D. Schmidts (Boeing example and design patterns part)tutorial : http://www.cs.wustl.edu/~schmidt/tutorials-patterns.html

UML for Systems Engineering,:watching the wheels, 2nd Ed. ,Jon Holt, IET Professional Applications of Computing

Series, 2007. 3SWE513 Spring 2010 - UML tutorial Part I
http://www.cs.wustl.edu/~schmidt/tutorials-patterns.htmlhttp://www.cs.wustl.edu/~schmidt/tutorials-patterns.html


4/136

KeyKey PPointsoints of Software Modelingof Software Modeling

A model is an abstract system view.Complementary types of model providedifferent system information.

Context models show the position of asystem in its environment with othersystems and processes.

Data flow models may be used to modelthe data processing in a system.

State machine models model the systemsbehaviour in response to internal orexternal events.



5/136

KeyKey PPointsoints (cont.)(cont.)

Semantic data models describe the logicalstructure of data which is imported to orexported by the systems.

Object models describe logical systementities, their classification andaggregation.

Sequence models show the interactionsbetween actors and the system objectsthat they use.

Structured methods provide a frameworkfor developing system models.



6/136

Object Oriented MethodsObject Oriented Methods

What are object-oriented (OO) methods? OO methods provide a set of techniques for analyzing,

decomposing, and modularizing software systemarchitectures

In general, OO methods are characterized by structuringthe system architecture on the basis of its objects (andclasses of objects) rather than the actions it performs

What are the benefits of OO? OO enhances key software quality factors of a system and

its constituent components

What is the rationale for using OO? In general, systems evolve and functionality changes, but

objects and classes tend to remain stable over time



7/136

UMLUML

Is a language. It is not simply a notation fordrawing diagrams, but a complete language forcapturing knowledge (semantics) about asubject and expressing knowledge (syntax)

regarding the subject for the purpose ofcommunication.

It is the result ofunifyingthe information

systems and technology industrys bestengineering practices (principals, techniques,methods and tools).



8/136

UML (contd)UML (contd)

Unified because it Combines main preceding OO methods (Booch by

Grady Booch, OMT by Jim Rumbaugh and OOSE by Ivar

Jacobson)

Modeling because it is

Primarily used for visually modeling systems. Manysystem views are supported by appropriate models

Language because It offers a syntax through which to express modelled

knowledge



9/136

UML ElementsUML Elements

Functional requirements view

Emphasizes the functional requirements of the systemfrom the user's point of view.

Static structural view Emphasizes the static structure of the system using

objects, attributes, operations, and relationships.

Dynamic behavior view

Emphasizes the dynamic behavior of the system byshowing collaborations among objects and changes tothe internal states of objects.



10/136

UML (again)UML (again)

What it is A language for capturing and expressing knowledge

A technology for visual development modeling

A set of well-founded guidelines

A milestone generator A popular (therefore supported) technology

What it is not A visual programming language or environment

A database specification tool

A development process (i.e. an SDLC)

A silver bullet

A quality guarantee



11/136

UML (again)UML (again)

The UML is a standard representation devised by thedevelopers of widely used object-oriented analysis anddesign methods.

It has become an effective standard for object-orientedmodelling.

Notation Object classes are rectangles with the name at the top, attributes in

the middle section and operations in the bottom section;

Relationships between object classes (known as associations) areshown as lines linking objects;

Inheritance is referred to as generalisation and is shown upwardsrather than downwards in a hierarchy.



12/136

UML DiagramsUML Diagrams Functional Requirements

Use-Case (relationship between actors and system functions)

Structure Class (static class structure)

Object (same as class - only using class instances i.e. objects)

Package (logical grouping of classes) Component (code structure)

Deployment/Implementation (mapping of software tohardware)

Behavior State (states of objects in a particular class)

Sequence (Object message passing structure)

Collaboration/Communication (same as sequence but alsoshows context - i.e. objects and their relationships)

Activity (sequential flow of activities i.e. action states)



13/136

Main 4 UML DiagramsMain 4 UML Diagrams

Use-Case

Class

Sequence State/Statechart



14/136

TheThe UseUse--CaseCase DiagramDiagram



15/136

Use Case DiagramUse Case Diagram

Components Actor

Goals

Relationships

Use-case Relationship UsesConsumes

Generalization - Specialization

Extends - Inherits



16/136

RequirementsRequirements

Defining what the system should do What the clients needs (as opposed to wants)

Not how the solution should be designed or implemented

We recognize three iterative activities :

Elicitation: capturing information from sources Documentation: putting it on paper

Validation: confirming it meets users needs

Analysis (or definition) versus Specification Customer-oriented requirements

Developer-oriented requirements



17/136

SpecificationSpecification DocumentsDocuments

Steven McConnell (IEEE Software, Oct. 2000) says any of thefollowing are called requirements document:

Half-page summary of software product vision

Two-page key features list

50-page list of details about end-user requirements (he calls thisa function-requirements document)

250-page exhaustive list of details about screens and GUI, inputand input conditions, all system states and state changes, allpersistent data, etc.

This 4th item is what we usually mean by a SoftwareRequirements Specification (SRS) document



18/136

Example:Example: AutomatedAutomated Library SystemLibrary System

Vision Statement You have been contracted to develop a

computer system for a university library. The

library currently uses a 1960s program,written in an obsolete language, for somesimple bookkeeping tasks, and a card index,for user browsing. You are asked to build an

interactive system which handles both ofthese aspects online.



19/136

Example: More Details on NeedsExample: More Details on Needs

Books and Journals Library contains books and journals

Books may have several copies

Some books are short-term loans, all others 3weeks

Only staff can borrow journals

Members can borrow up to 6 items at a time

Staff can borrow up to 12 items New items arrive, old items are disposed of

Current years journals are bound at year-end



20/136

Use Case ModelingUse Case Modeling

Use Case: A sequence of actions a system performs to yield an observable

result of value to a particular actor.

Stevens/Pooley: A task which an actor needs to perform withthe help of the system

Actor:

Someone or something outside the system that interacts withthe system

A user of the system in a particular role

Important: We want an external view of the system



21/136

Use CasesUse Cases

Each use case has a name e.g. Borrow Copy of Book

A family (or set, or class) of scenarios A sequence of interactions

A set of different but related scenarios

Documenting Use Cases A UML Diagram showing all of them

Actors are stick-figures; use cases are ovals

For each use case define using English A clear textual description

A set of scenarios in outline form



22/136

Example: Actors and Use CasesExample: Actors and Use Cases

Actors BookBorrower

JournalBorrower

Browser (person who browses, not SW)

Librarian

Use Cases Borrow copy of a book

Reserve a book

Return copy of book Borrow journal

Browse

Update Catalog



23/136

What Form Does a Use Case Take?What Form Does a Use Case Take?

We can describe Use Cases in a variety ofways

First, text paragraphs

Describes the Actors who participatewith the system

Describes the sequence of events



24/136

FormsForms of Such Descriptionsof Such Descriptions

Informal Scenariosan informal narrative story, simple, natural, personal, not

generalisable

Use cases assume interaction with a system

assume detailed understanding of the interaction

Essential use cases abstract away from the details

does not have the same assumptions as use cases



25/136

Example Text DescriptionExample Text Description

Borrow copy of a book:

A Bookborrower presents a copy of a

book. The system checks that the s/he is alibrary member, and that s/he has notchecked out too many books. If both

checks succeed, then the system recordsthat the member now as this copy of thebook. Otherwise it refuses the loan.



26/136

What Else Is In a Use CaseWhat Else Is In a Use CaseDescription?Description? Pre- and Post-conditions

Values of variables, system conditions, otheruse cases etc.

Normal vs. alternative behavior Can be shown in the text description

(somehow)

Exceptions vs. acceptable alternatives



27/136

Example Template for Use CasesExample Template for Use Cases Use case number or id:

Use case title: Actors:

Text description (a few sentences)

Preconditions (if applicable):

Flow of Events:

Basic path:1.First step

2.Second step

3.etc

Alternative Paths: Name and short description (in words) of first alternative path/scenario.

Name and short description (in words) of 2nd alternative path/scenario.

etc.

Postconditions (if applicable)

Special conditions (if applicable).



28/136

Scenario for shared calendarScenario for shared calendarThe user types in all the names of the meeting participants

together with some constraints such as the length of the meeting,

roughly when the meeting needs to take place, and possibly where

it needs to take place. The system then checks against the

individuals calendars and the central departmental calendar and

presents the user with a series of dates on which everyone is freeall at the same time. Then the meeting could be confirmed and

written into peoples calendars. Some people, though, will want to

be asked before the calendar entry is made. Perhaps the system

could email them automatically and ask that it be confirmed beforeit is written in.



29/136

Use case for shared calendarUse case for shared calendar1. The user chooses the option to arrange a meeting.

2. The system prompts user for the names of attendees.3. The user types in a list of names.

4. The system checks that the list is valid.

5. The system prompts the user for meeting constraints.

6. The user types in meeting constraints.

7. The system searches the calendars for a date that satisfies theconstraints.

8. The system displays a list of potential dates.

9. The user chooses one of the dates.

10. The system writes the meeting into the calendar.11. The system emails all the meeting participants informing themof them appointment



30/136

Alternative paths for shared calendarAlternative paths for shared calendar

Step 5. If the list of people is invalid, then:

5.1 The system displays an errormessage.

5.2 The system returns to step 2.

Step 8. If no potential dates are found, then

8.1 The system displays a suitable message.8.2 The system returns to step 5.



31/136

Example use case diagram for sharedExample use case diagram for shared

calendarcalendar

Administrator Departmentalmember

Arrange ameeting

Update calendar

entry

Retrievecontact details



32/136

Essential useEssential use--case forcase for arrangeMeetingarrangeMeeting

Use-case Name: arrangeMeeting

USER INTENTION SYSTEM RESPONSIBILITY 1. arrange a meeting

2. request meeting

attendees & constraints3. identify meeting attendees& constraints

4. search calendars forsuitable dates

5. suggest potential dates6. choose preferred date7. book meeting



33/136

Relationships between Use CasesRelationships between Use Cases

UML supports two relationships betweentwo use cases

and

Note: before UML 1.3 was



34/136

in Use Cases in Use Cases

Meaning: The source use case always includes the

actions specified in the target use case


in Use Cases in Use Cases

Meaning: The target use case my include the behavior

of the source use case


35/136

Back to business...Back to business...

Enough on Requirements-Use Casescouple, back to core UML....



36/136

UMLUML DiagramsDiagrams (recap...)(recap...) Functional Requirements






Behavior State (states of objects in a particular class)

Sequence (Object message passing structure)





37/136

The ClassThe Class DiagramDiagram



38/136

The ObjectThe Object DiagramDiagram



39/136

Example: Library systemExample: Library system

Catalogue n umberAcquisition da teCostTypeStatus

Number of copies

Library item

Acquire ()Catalogue ()Dispose ()Issue ()Return ()

Author

EditionPublication da te

ISBN

Book

Year

Issue

Magazine

Director

Date of release

Distributor

Film

Version

Platfor m

Computerprogram

TitlePublisher

Pub lished item

Title

Medium

Recorded item

LibraryLibrary class hierarchyclass hierarchy



40/136

Example: Lib.Example: Lib. UserUser class hierarchyclass hierarchy

NameAddressPhoneReg istra tion #

Library user

Reg ister ()De-register ()

Affiliation

Reader

Items on loanMax. loans

Borrower

Depar tmentDepar tment phone

Staff

Major subjectHome ad dress

Student



41/136

Multiple inheritanceMultiple inheritance

Rather than inheriting the attributes and services from asingle parent class, a system which supports multipleinheritance allows object classes to inherit from severalsuper-classes.

This can lead to semantic conflicts whereattributes/services with the same name in differentsuper-classes have different semantics.

Multiple inheritance makes class hierarchy

reorganisation more complex.



42/136

Multiple inheritanceMultiple inheritance

# Tapes

Talking book

Author

Edition

Publication da te

ISBN

Book

Speak er

Duration

Recording da te

Voice recording



43/136

Object aggregationObject aggregation

An aggregation model shows how classesthat are collections are composed ofother classes.

Aggregation models are similar to thepart-of relationship in semantic datamodels.



44/136

Object aggregationObject aggregation



45/136

Object behaviourObject behaviour modelingmodeling

A behavioural model shows theinteractions between objects to producesome particular system behaviour that is

specified as a use-case. Sequence diagrams (or collaboration

diagrams) in the UML are used to model

interaction between objects.



46/136

Reminder: Analysis modelsReminder: Analysis models

Earlier we modeled requirements using... Class Diagrams: Known as the ConceptualModel

Sometimes known as the logical model.

Classes represent domain-level entities. (E.g.things in the users world.) Thus no classes for implementation-level things.

Associations model domain-level relationships.(E.g. user-understood relationships betweenthings in the users world.) Usually dont show navigation on associations



47/136

Reminder: Analysis models (2)Reminder: Analysis models (2)

Use Cases and Sequence Diagrams Scenarios in a Use Case can be represented by

UML sequence diagrams

Objects in the sequence diagram could be either:

The system and the actors, or... Domain-level entities modeled in the conceptual model (a

class diagram)

Messages between objects are: Again, at a high-level of abstraction

Scenario descriptions become messages



48/136

Reminder: Goals for designReminder: Goals for design

Create detailed plans (like blueprints)for implementation

Build these from requirements models so

we are confident that all user needs willbe met

Create design models before coding sothat we can: Compare different possible design solutions Evaluate efficiency, ease of modification,

maintainability, etc



49/136

UML Notations forUML Notations for DesignDesign

Several UML notations provide various viewsof a design Class diagrams: Possibly created at two

different levels of abstraction for design:

Specification level: Classes model types, and wefocus solely on interfaces between software modules Implementation level: Think of this as a true

software blueprint. We can go directly to codefrom this model.

Two types of Interaction Diagrams: Sequence diagrams and Collaboration diagrams



50/136

UML Notations for Design (2)UML Notations for Design (2)

Sequence diagrams Objects will be variables implemented in code

Messages are operations (e.g. C++ memberfunctions) applied to objects

Sequence diagrams thus show how a sequence ofoperations called between a set of objectsaccomplishes a larger task

Sequence diagrams for a particular scenario help

identify operations needed in classes They also allow us to verify that a design can

support requirements (e.g. a use-case scenario)



51/136


State diagrams Models how a particular object responds to

messages according to its state

For a single object, show states and transitions

between states Transitions may be conditional based on aguard

condition

May show an action an object takes on transition,

or also activitycarried out within a state Occasionally used to model a systems or

subsystems behavior (not just one objects)



52/136


Packages A simple notation that groups classes together

Possible to use this to show contents of asubsystem

Show dependencies between packages Show visibility of classes between packages

Not really a rich enough notation fordiagramming software architectures

Component Diagrams Models physical modules of code (e.g. files, DLLs,

physical databases)



53/136

Design ProcessDesign Process

There are many different approaches to design, buthere is something typical. First, create a model of the high-level system

architecture UML does not really provide a notation this

Next, use the conceptual class model to build adesign-level class model or models Here well assume were just building an implementation-

levelclass model

Also, model dynamic behavior using interactiondiagrams.



54/136

Design Process (contd)Design Process (contd)

Well use sequence diagrams with objectsfrom the implementation-level class model

Sequence diagrams show how design-levelobjects will carry out actions to implementscenarios defined as part of use-case analysis

Messages between objects are member-functioncalls between objects

Important: Only member-function calls areshown, but other language statements (e.g.assignments) are executed between calls (ofcourse).



55/136

Design Process (contd)Design Process (contd)

Important: Development of class andsequence diagrams is iterative andconcurrent

When we create sequence diagrams for a

new scenarios, we discover classes andoperations that need to be added to theclass model

The two models grow together. Neither is a

complete view of the system. Other documentation in text form is often

used to provide details about class diagramsand sequence diagrams



56/136

SpecificationSpecification--Level Class DiagramsLevel Class Diagrams

How does a design-level class diagramdiffer from a conceptual-level diagram?

No longer just an external view!

We are now modeling how not just what.

This class diagram must document:

Additional classes

How you will implement associations Multiplicity, Navigability or Direction; Association

classes



57/136

Additional Classes in a DesignAdditional Classes in a Design

Are additional classes needed? Of course!In general...

Design-level internal classes Data manager classes. E.g. collection objects that

were simply associations before Facilitator or helper classes that assist with

complex tasks (e.g. ObservableComponent) Factory classes that assist in creating new objects

Classes to implement other design patterns Is there any guidance or strategy for

determining these?


Class Types inClass Types in


58/136

Class Types inClass Types in

a Layereda Layered

ArchitectureArchitecture 5-layer model

Classes only

interact withinlayers, or as shownby arrows

Direction matters!

Next slidedescribes these

User Interface

Classes

System

Classes

Controller/

Process

Classes

Business/Domain

Classes

Persistence Classes

Persistent Store(s)



59/136

Possible Design Class TypesPossible Design Class Types

UI classes Business/Domain classes

Implement domain-objects from Analysis

Data objects plus their behaviors

Controller/Process classes implement business logic, collaborations between business objects

and/or other controller

Persistence classes

How to store, retrieve, delete objects

Hides underlying data stores from rest of system

System classes

Wrap OS-specific functionality in case that changes



60/136

Controller/Process LayerController/Process Layer

Implements business logic Encapsulate a business rule

These often require interactions etc. between

objects of different classes Example from a student course enrollment system:

When can a Student enroll in a Seminar?

Depends on schedule, pre-requisites, other constraints



61/136

More on ControllersMore on Controllers

Why not just put business logic into theDomain class?

Business rules change. We want domain

classes to be reusable. In UI class? Then must use that UI to carry

out this process. (Too tightly coupled.)

How to find Controller classes?

To start: consider one for each use-case

If trivial or belongs in domain class, dont.



62/136

Controller Classes: Good OO?Controller Classes: Good OO?

Violates a principle of the OO approach! Data and behavior kept together!

Yes, but is this always the best solution? DVDs and DVD players -- why not one unit?

Cameras and film vs. disposable cameras Consider coupling, change, flexibility Controller classes are an example of theMediatordesign pattern

Mediator or control classes might grow tobecomegod classes too much control, or too centralized



63/136

Implementing AssociationsImplementing Associations

How associations are implemented is affected bymultiplicity. Where they are implemented depends on navigability.

In one class or in both?

Until now we may not have worried about direction of

associations. Thats fine! Often navigability cannot be determined until design phase.

Often it changes as we do more design.

In prototypes we often keep links bidirectional for flexibility.



64/136

Implementing Associations (2)Implementing Associations (2)

Often we use class operations to hideimplementation details of associations

getters, setters, traversal functions, update

functions, etc. Also, derived associations (or attributes) are

implemented as member functions thatcalculate something that is not stored directly

in the class.



65/136


66/136

Multiplicity and OneMultiplicity and One--Way AssociationsWay Associations

If the multiplicity is 1 or 0..1 then the attributewould be a pointer to an object of the target class E.g. attribute in class Phone: selectedLine: Line*

If the multiplicity is many but has a fixedmaximum, then use array of pointers (or objects) E.g. 3, 0..3, 2..4

If no fixed maximum, e.g. 1..* or 0..*, then use acollection object as an attribute that stores anarbitrarily large number of pointers or objects

For qualified associations use a hash-table or mapobject to associate key with target object



67/136

Multiplicity and OneMultiplicity and One--Way Assoc. (2)Way Assoc. (2)

Examples using the C++ standard library... A vectorclass is like an array with no

maximum capacity Example attribute in class Phone:

linkedLines: vector Other C++ classes might be appropriate

too: set, list Arrays should only be used if you know the

maximum

Note: Your team might agree not to showthe * to indicate pointers. Conventionsvary.



68/136

Implementing TwoImplementing Two--Way AssociationsWay Associations

Three options, depending on your needs Note: Sometimes its OK if traversal in one

direction is slower than the other

Option One: Just like one-way but in both

classes Advantages: Equally efficient in both directions

But, requires more space

Also, updating links between objects is morecomplex Often a good idea to use member functions to handle

updates to links.



69/136

Implementing TwoImplementing Two--Way Assoc. (2)Way Assoc. (2)

Option Two: In one class, Class A, implement just like one-

way (see above) to access Class B objects.

In second class, Class B, write an operationthat uses some kind of search of all objects ofClass A to find the one that points back tothe current B object.

Why? Saves space if access from B to A is very rare But, requires there to be some place where all

objects of Class A are stored



70/136

Implementing TwoImplementing Two--Way Assoc. (3)Way Assoc. (3)

Option Three: Implement an Association Class

This class will have only one instance, which storesall the links between objects of the two classes

Implemented as two dictionary or map objects One points to Class A objects, the other to Class B objects

Search of this object is used to find links for oneobject



71/136

Example of Assoc. ObjectExample of Assoc. Object

Works-For

Person1

Person2

Person3

Company1

Company2

A person works for one company. A company hasmany employees.

If pointers are not bi-directional, then Works-Forobject must support efficient look-up of a Personobject in order to find that objects company.

Note: This is not a UML diagram!



72/136

Flashback to previous slidesFlashback to previous slides

Lets look at class diagrams now.



73/136

Association ClassesAssociation Classes

Recall that qualified associations reallymean that the link between two objectshas an attribute

Often associations are first-class things They have a life-time, state, and maybe

operations

Just like objects!

Association classes Same name as the association because...

They represent the same thing!



74/136

Association Class ExampleAssociation Class Example

Company

Person

0..*

1..*

employer

employee

Job

description : string

dateHired : Date

salary : Money



75/136

World Cup ExampleWorld Cup Example

We need a system to handle the WorldCup. Teams represent countries and aremade up of 22 players.

Countries qualify from zones, where eachzone is either a country or a group ofcountries.

Each team plays a given number of games

in a specific city. Referees are assigned togames. Hotel reservations are made in thecity where the teams play.



76/136

World Cup Problem: Class ModelWorld Cup Problem: Class Model

Qualifying Unit

Country Zone

Team

Player

Hotel

City

Game

Reservation

Assignment

3

Represents

*

2 *

Playsat

22

Repre

sents

1PlaysIn

* *

*

01

*

5

Referee

14

3

2

1

*



77/136

Implementing Association ClassesImplementing Association Classes

Implementation depends on multiplicity If one-to-one, then it would be possible to...

Put attributes and operations inside either object Or, put them in a separate class thats linked to

either object If one-to-many, then same choices as one-to-

one, but do this for the object on themany end

Again, could be a separate object (see next case) If many-to-many, you need a separate class

with an object instantiated for each link


f A Cf A C


78/136

Example of Association Class ImplementationExample of Association Class Implementation

Conceptual-Level Class Diagram

Corresponding Design-Level Class

Diagram

ClassA ClassB

AssocClass

0..1 1..*

ClassA ClassBAssocClass

1 1..* 0..1 1


N E l I l iN E l I l i


79/136

Notes on Example ImplementationNotes on Example Implementation

No direct link (pointer) in design or implementationbetween ClassA and ClassB instances! But...

Each instance of an AssocClass object is linked toexactly one ClassA object and also to one ClassBobject

This forms a 3-tuple for each conceptual-level linkbetween a pair of ClassA and ClassB objects

Note multiplicities reflect concept level: One ClassA object is linked to 1-to-many AssocClass/ClassB pairs. Great!

One ClassB object links to 0-or-one AssocClass/ClassA pairs. Yes!



80/136

Next weekNext weekPart 2 ...Part 2 ...

Some more on UML Some case studies/examples

UML tools: Eclipse UML plugins, MS Visio,Rational Software Architect, others

Project announcement


Th kTh k ))


81/136

Thanks :Thanks :--))

See you next week!

http://www.cmpe.boun.edu.tr/~gurEmail : [email protected]



82/136

Unified ModelingUnified Modeling

LanguageLanguage

SWE 513UML tutorialPart II

Grkan Gr

A dA d


83/136

AgendaAgenda

Some more on UML (especially interactiondiagrams)

Some case studies/examples

UML tools: Eclipse UML plugins, MS Visio,

Rational Rose, others Project announcement

83SWE513 Spring 2010 - UML tutorial Part II

UMLUML DiDi ( )( )


84/136







Behavior State (states of objects in a particular class) Sequence (Object message passing structure)




DynamicViews in UMLDynamicViews in UML


85/136

Dynamic Views in UMLDynamic Views in UML

Class diagrams are models of data types

What non-fundamental types are you using? How are they related? Sometimes referred to as the static model

Running programs define objects of various types that interact

Control is passed between objects methods

Information is passed and returned UML has two almost identical diagrams for this:

Collaboration diagram: object-centered

Sequence diagram: time-oriented

Important: Each diagram models a particular scenario Often we just model important or interesting scenarios


Sequence DiagramSequence Diagram --11


86/136

Sequence DiagramSequence Diagram --11

SWE513 Spring 2010 - UML tutorial Part II 86

Sequence DiagramSequence Diagram--2: i2: issuessue ofof


87/136

q gq g

electronic itemselectronic items


Sequence DiagramSequence Diagram--33


88/136

Sequence DiagramSequence Diagram--33


Collaboration DiagramCollaboration Diagram--11


89/136

Collaboration DiagramCollaboration Diagram--11


Cl Di ithCl Di ith R l t dR l t d C ll b tiC ll b ti


90/136

Class Diagram with aClass Diagram with a RelatedRelated CollaborationCollaboration


Activity DiagramActivity Diagram


91/136

Activity DiagramActivity Diagram


Activity DiagramActivity Diagram--22


92/136

Activity DiagramActivity Diagram 22


Activity diagram showing behaviour of a thought process of how to playchess (badly)

Sequence DiagramSequence Diagram 44


93/136

Sequence DiagramSequence Diagram -- 44


Relationship Between Both NotationsRelationship Between Both Notations


94/136

Relationship Between Both NotationsRelationship Between Both Notations


collaboration diagram

sequence diagram

CCollaborationollaboration DiagramDiagram 22


95/136

CCollaborationollaboration DiagramDiagram -- 22


SequenceSequence DiagramDiagram 55


96/136

SequenceSequence DiagramDiagram--55


Use Cases and Sequence DiagramsUse Cases and Sequence Diagrams


97/136

Use Cases and Sequence DiagramsUse Cases and Sequence Diagrams

So far sequence diagrams model interactionsbetween implementation-level objects

Also, can be used to model use cases Actor(s) interacting with the System

Most useful if more than one Actor Messages are used informally here

Example: ATM customer tries to overdraw

Also, sequence diagrams sometimes used in

high-level design model interactions between major subsystems


Iteration Control ReturnValuesIteration Control ReturnValues


98/136

Iteration, Control, Return ValuesIteration, Control, Return Values

Messages can be labeled with a condition:[hasStock] sellWidget()

Messages can be repeated:

* msg() or *[k=1..2] msg() Return values:

Maybe on dashed return arrow, or

On message call: n = getName() Again, note returns not always explicitly

drawn


Notes on MessagesNotes on Messages


99/136

Notes on MessagesNotes on Messages

Various types of messages supported Filled solid arrow head: like procedure calls, nested flow of control. Caller

waits for action to complete.

Half arrow head: Asynchronous flow of control. Caller is not blocked,

continues to do something.

Dashed arrow:

Return from procedure call. May be omitted if itsimplicit at end of an activation box

Use stereotypes to define anything else.


Iterations, Constraints,Iterations, Constraints, AsynchAsynch. Messages. Messages


100/136

Iterations, Constraints,Iterations, Constraints, AsynchAsynch. Messages. Messages


Phone Switch ExamplePhone Switch Example


101/136


Optional for class lecture




102/136


Classes Phone: a persons telephone

Line: a number associated with a phone

Lines are busy, calls are made on lines, etc.

Connection: dynamically created, represents an active callbetween lines

Switch: a phone switch is a computer system that managesphones, lines and connections

Console: a terminal attached to the switch

Simulator: were writing a simulation!


Associations in Our ModelAssociations in Our Model


103/136

Associations in Our ModelAssociations in Our Model Switch manages other objects More than one Phone may be linked to one line

Like for office secretary, boss

A Phone may have more than one Line But, a Phone has only one Line selected at one time

Must choose a Line to call or answer Also, when a Line is connected, not all Phones that can

possibly use that Line may be participating in the call.

A Connection requires at least two Lines to exist


Conceptual Class DiagramConceptual Class Diagram


104/136

Conceptual Class DiagramConceptual Class Diagram

Connection

id : int

state : ConnState

duration : int

Line

number : string

state : LineState

2..*

0..1

2..*

0..1

Phone

state : PhoneState

name : string

11..*

1onConnection

1..*

1

0..*selected

1

0..*

1..*0..*

1..*0..*

linkedLines

Switch

name : string

0..*

1

0..*

1

manages

0..*

1

0..*

1

manages

0..*

1

0..*

1

manages

Simulator

0..*

1

0..*

1

controls

1

1

1

1

controls


ScenarioScenario


105/136

ScenarioScenario

A normal call Phone1 chooses Line 1 and picks up

Phone 1 dials number for Phone2

Phone 2 rings Phone 2 picks up

Call completed and the two people talk

Phone 2 hangs up

Phone 1 is disconnected

Phone 1 hangs up


Class Diagram with OperationsClass Diagram with Operations


106/136

g pg p

Connection

id : int

state : ConnState

duration : int

disconnect(l : Line) : void

addLine(l : Line) : void

Line

number : int

state : LineState

incomingCall(c : Connection) : void

hungUp(p : Phone) : void

pickedUp(p : Phone) : void

addPhone(p : Phone) : void

2..* 0..12..* 0..1

Phone

state : PhoneState

name : s tring

selectLine(num : int) : void

pickup() : void

hangup() : voidring() : void

dial(num : int) : void

addLine(l : Line) : void

11..*

1onConnection

1..*

1

0..*selected

1

0..*

1..*0..*

1..*0..*

linkedLines

Switch

name : s tring

getPhone(name : string) : PhonegetLine(number : string) : Line

addLine(num : String) : void

addPhone(p : Phone) : void

linkLinePhone(name : string, num : int) : void

newCall(l1 : Line, l2 : Line) : void

completeConn(l : Line, c : Connection) : void

destroyConn(c : Connection) : void

0..*

1

0..*

1

manages

0..*

1

0..*

1

manages

0..*

1

0..*

1

manages

Simulator

processCmds(in : istream)

0..*

1

0..*

1

controls

11 11

controls


s: Simulator p1: Phone

s:Switch l1:

Line

l2:

Line

p2:

Phone

c1:

Connection

Sequence Diagram for a Normal Phone CallSequence Diagram for a Normal Phone Call


107/136

Line Line PhoneConnection

selectLine(n)

pickup()

dial(num) l2 := getLine(num)

newCall(l1, l 2)

pickedUp(p1)

incomingCall(c1)

hangup()

hungup(p1)

(l1)

ring()

pickup()

pickedUp(p2)completeConn(l2,c1)

addLine(l2)

hangup()

hungUp(p2)disconnect(l2)destroyConn(c1)

/* change state */


UMLUML DiagramsDiagrams (recap )(recap )


108/136





Package (logical grouping of classes)

Component (code structure)


Behavior

State (states of objects in a particular class) Sequence (Object message passing structure)




Less Common Diagrams : Package DiagramLess Common Diagrams : Package Diagram


109/136

g g gg g g

SWE513 Spring 2010 - UML tutorial Part II

A package is a UML construct

that enables you to organize

model elements, such as use

cases or classes, into groups.Packages are depicted as file

folders and can be applied on any

UML diagram.

Class Package diagrams

Use Case package diagrams

109

Less Common Diagrams : ComponentLess Common Diagrams : Component


110/136

DiagramDiagram

Issue of electronic itemsIssue of electronic items


Less Common Diagrams : DeploymentLess Common Diagrams : Deployment


111/136

SWE513 Spring 2010 - UML tutorial Part II

DiagramDiagram

111

Enough with standard UMLEnough with standard UML


112/136

narrative, something different ...narrative, something different ...

Optional for class lecture

The next part is from Patterns, Frameworks and Middleware:Their Synergestic Relationships tutorial by D. C. Schmidt:

http://www.cs.wustl.edu/~schmidt/tutorials-patterns.html (a very important source for seriousdistributed networked software design anddevelopment)


Idioms Patterns FrameworksIdioms Patterns Frameworks
http://www.cs.wustl.edu/~schmidt/tutorials-patterns.htmlhttp://www.cs.wustl.edu/~schmidt/tutorials-patterns.htmlhttp://www.cs.wustl.edu/~schmidt/tutorials-patterns.htmlhttp://www.cs.wustl.edu/~schmidt/tutorials-patterns.htmlhttp://www.cs.wustl.edu/~schmidt/tutorials-patterns.html


113/136

Idioms, Patterns, FrameworksIdioms, Patterns, Frameworks

Idiom: a small language-specific pattern or technique A more primitive building block

Design pattern: a description of a problem that reoccursand an outline of an approach to solving that problem

Generally domain, language independent Also, analysis patterns

Framework:

A partially completed design that can be extended to solve

a problem in a domain Horizontal vs. vertical

113

Taxonomy of Patterns & IdiomsTaxonomy of Patterns & Idioms


114/136

yy

Type Description Examples

Idioms Restricted to a particular language,system, or tool Scoped locking

Design

patterns

Capture the static & dynamic roles &

relationships in solutions that occur

repeatedly

Active Object,

Bridge, Proxy,

Wrapper Faade,

& Visitor

Architecturalpatterns

Express a fundamental structuralorganization for software systems that

provide a set of predefined subsystems,

specify their relationships, & include the

rules and guidelines for organizing the

relationships between them

Half-Sync/Half-Async, Layers,

Proactor,

Publisher-

Subscriber, &

Reactor

Optimizationprinciple

patterns

Document rules for avoiding commondesign & implementation mistakes that

degrade performance

Optimize forcommon case,

pass information

between layers

114

Example: Boeing Bold StrokeExample: Boeing Bold Stroke


115/136

Nav Sensors

WeaponManagement

Data LinksMissionComputer

VehicleMgmt

Weapons

Avionics mission computing product-linearchitecture for Boeing military aircraft, e.g.,F-18 E/F, 15E, Harrier, UCAV

DRE system with 100+ developers, 3,000+software components, 3-5 million lines of

C++ code

Based on COTS hardware, networks,operating systems, & middleware

Used as Open ExperimentationPlatform (OEP) for DARPA IXO PCES,MoBIES, SEC, MICA programs

BoldStrokeArchitecture

Hardware (CPU, Memory,I/O)


Networking InterfacesNetworking Interfaces

Operating SystemOperating System

Middleware InfrastructureMiddleware Infrastructure

Mission Computing ServicesMission Computing Services

Radar

115



116/136







p gp g

COTS & Standards-based MiddlewareInfrastructure, OS, Network, &Hardware Platform

Real-time CORBA middleware servicesVxWorks operating system

VME, 1553, & Link16

PowerPC

116



117/136

p gp g

Reusable Object-Oriented ApplicationDomain-specific Middleware FrameworkConfigurable to variable infrastructureconfigurations

Supports systematic reuse of missioncomputing functionality







117



118/136

p gp g

Product Line Component Model Configurable for product-specific functionality& execution environment

Single component development policies Standard component packaging mechanisms







118



119/136







p gp g

Component Integration ModelConfigurable for product-specificcomponent assembly & deploymentenvironments

Model-based component integrationpolicies

Avionics Interfaces

Operator

Real World Model

Infrastructure Services

119

Examples of C++ IdiomsExamples of C++ Idioms


120/136

Examples of C IdiomsExamples of C Idioms Use of an Init() function in constructors

If there are many constructors, make each one call a privatefunction Init()

Init() guarantees all possible attributes are initialized

Initialization code in one place despite multiple constructors

Dont do real work in a constructor Define an Open() member function

Constructors just do initialization

Open() called immediately after construction

Constructors cant return errors

They can throw exceptions

120

Design Patterns: Essential ElementsDesign Patterns: Essential Elements


121/136

Design Patterns: Essential ElementsDesign Patterns: Essential Elements

Pattern name

A vocabulary of patterns is beneficial

Problem

When to apply the pattern, what context.

How to represent, organize components

Conditions to be met before using Solution

Design elements: relationships, responsibilities, collaborations

A template for a solution that you implement

Consequences

Results and trade-offs that result from using the pattern

Needed to evaluate design alternatives

121

Patterns Are (and Arent)Patterns Are (and Arent)


122/136

Patterns Are (and Aren t)Patterns Are (and Aren t)

Name and description of a proven solution to aproblem

Documentation of a design decision

Theyre not:

Reusable code, class libraries, etc. (At a higher level)

Do not require complex implementations

Always the best solution to a given situation

Simply a good thing to do

122

Describing Design PatternsDescribing Design Patterns


123/136

Describing Design PatternsDescribing Design Patterns The GoF (Design Patterns: Elements of Reusable Object-Oriented

Software) defined a standard format Generally followed

Not just a UML diagram!

Pattern Format (13 sections): Pattern name and classification

Intent: whats it do? Rationale? Also known as

Motivation A scenario that illustrates a sample problem and how this

patterns helps solve it.

Applicability For which situations can this be applied?

Structure Graphical representation (e.g. UML)

123

Pattern Format (contd)Pattern Format (contd)


124/136

( )( )

Participants

Classes and objects, their responsibilities

Collaborations

How participants interact

Consequences

Implementation Pitfalls, hints, techniques, language issues

Sample code

Code fragments that illustrate the pattern

Known uses

From real systems Related patterns

Similar patterns, collaborating patterns

124

Example 1: Singleton PatternExample 1: Singleton Pattern


125/136

p gp g

Context: Only one instance of a class is created. Everything inthe system that needs this class interacts with that one object.

Controlling access: Make this instance accessible to all clients

Solution:

The class has a static variable called theInstance (etc) The constructor is made private (or protected)

Clients call a public operationgetInstance() that returns the oneinstance

This may construct the instance the very first time or be given aninitializer

125

Singleton: Java implementationSingleton: Java implementation


126/136

g J pg J p

public class MySingleton {

private static MySingleton theInstance =

new MySingleton();

private MySingleton() { // constructor

}

public static MySingleton getInstance() {

return theInstance;

}

}

126

Static Factory MethodsStatic Factory Methods


127/136

Singleton patterns uses a static factory method

Factory: something that creates an instance Advantages over a public constructor

They have names. Example:BigInteger(int, int, random) vs.BigInteger.probablePrime()

Might need more than one constructor with same/similar signatures Can return objects of a subtype (if needed)

Wrapper class example:Double d1 = Double .valueOf(3.14);Double d2 = new Double (3.14);

127

The State Design PatternThe State Design Pattern


128/136

A connection can be in various states Handles requests differently depending on state

Connection delegates requests to its state object Which changes dynamically

128

Some UML ToolsSome UML Tools


129/136

Some UML ToolsSome UML Tools


Rational Rose Family

eUML Eclipse Plugin

MS Visio

Rational Rose FamilyRational Rose Family


130/136

130

Rational Rose Family (cont.)Rational Rose Family (cont.)


131/136

131

eUML2eUML2


132/136

132

eUML2eUML2 (cont.)(cont.)


133/136

( )( )

133

GGeneratedenerated fromfrom thetheAppenderAppenderinterface tointerface to

display itsdisplay its inheritanceinheritance && assass relationshipsrelationships


134/136

display itsdisplay its inheritanceinheritance && assass.. relationshipsrelationships

134

AA sequence diagram generatedsequence diagram generated automaticallyautomatically

from a methodfrom a method


135/136

from a methodfrom a method

135

Thanks :Thanks :--))


136/136

))

http://www.cmpe.boun.edu.tr/~gur

Email : [email protected]