Uml Intro h1

8/14/2019 Uml Intro h1

1/82

e University

Hue UniversityHue University

UMLUML

UNIFIED MODELING LANGUAGEUNIFIED MODELING LANGUAGE

Hoang Huu Hanh, [email protected]

ba sed on on lin e cou rses a nd p rese ntation s
mailto:[email protected]:[email protected]:[email protected]:[email protected]


2/82


3/82

Introduction to UML 3

e University

UML HistoryUML History


4/82


e University

WHAT IT ISWHAT IT IS

UML is a modeling language, not amethod

Most methods consist, at least inprinciple, of both a modeling

language and a process.Modelling Language is the (mainly

graphical) notation that methodsuse to express designs.

Process is their advice on whatsteps to take in doing a design.Modeling Language is the most

important part of the method,

which is the key part ofcommunication.


5/82


e University

WHY USE UMLWHY USE UML

Helps Analysis and DesignUsed for communicationUse the advantages of OODocumentation

As stated in The Unified ModelingLanguage User Guide;

UML is a language for:

Visualizing Specifying Constructing Documenting


6/82


e University

VisualizingVisualizing

It makes it easier to understandand work through problem

Since it is a formal language, it

enables other developersfamiliar with the language tomore easily interpret our

drawings.


7/82Introduction to UML 7

e University

SpecifyingSpecifying

We must communicate oursoftware system using somecommon, precise, and

unambiguous communicationmechanism.

Again the formal nature of the

UML facilitates this specificationquite nicely.



e University

ConstructingConstructing

We know that the UML is a formallanguage with its own set of syntacticalrules.

Because of this formality, we can create

tools that interpret our models.They can map the elements to a

programming language, such as Java,C++.

Many tools such as Rational Rose,supports this forward engineering. Infact this is one of the advantages ofusing a formal modeling tool.



e University

DocumentingDocumenting

The models we create are justone of the articats producedthroughout the development

lifecycle.Using the UML in a consistent

fashion produces a set of

documentation that can serveas a blueprint of our system.



e University

USAGESUSAGES

Define the boundaries of a system & itsmajor functions use cases and actors

Illustrate use cases interaction diagrams

Define the static structure of a system class diagrams

Model the behavior of objects state transition diagrams

Document the physical implementationarchitecture component & deployment diagrams

Provide for growth stereotypes



e University

FUNDAMENTAL UMLFUNDAMENTAL UML

Models and ViewsCore DiagramsFundamental Elements



e Universitye University

Model

Views

Class Diagrams

Sequence Diagrams

Class Diagrams

(Packages)

Individual Diagrams

Actor1

UseCase1

UseCase2

Fundamental Elements

Actor2UseCase3

Interface2 uses

-End1*

-End2*

{}

Class3

interface

Interface3

utility

utility1



e University

Models and ViewsModels and Views

UML is more than disjointeddiagrams

Turn attention to an illustration

of the UML from three differentperspectives

Further insight into these

divisions enables us to realizeone of the greatest benefits ofmodeling, which is creatingdifferent views of our softwaresystem.



e University

Core ElementsCore Elements

Construct Description Syntax

class a description of a set of objectsthat share the same attributes,operations, methods, relationshipsand semantics.

interface a named set of operations thatcharacterize the behavior of anelement.

component a modular, replaceable andsignificant part of a system that

packages implementation andexposes a set of interfaces.

node a run-time physical object thatrepresents a computationalresource.

i



e University

Core Elements (contd)Core Elements (contd)

Construct Description Syntax

constraint a semantic condition or restriction.

{ c o n s t r a i n t }

An extension mechanism useful for specifying structural elements.


16/82



e University

DIAGRAMSDIAGRAMS

Individual diagrams contribute more tothe specification of a software system.

They are composition of many of thefundamental elements.

Are mechanism that developers use tocommunicate and solve problems inthe complex aspects of the system.

The most common diagram is the Class

Diagram, which describe the structuralrelationships that exist among theclasses, can guide developers inunderstanding our software systemsclass structure.


18/82


e University

VIEWSVIEWS

As we become more proficient inmodeling, we begin to realize thatusing a combination of diagrams tocommunicate is most effective.

We may need to combine class diagramwith a diagram whose intent is to givesystems dynamics.

By combining these called views.

View is a depiction of our system from aparticular perspective.

By making different views, we canrepresent our system from differentperspectives.


19/82


e University

VIEWSVIEWS (contd)(contd)

There are five main views, Use case

Design

Development

Process

Physical

They must be consistent with each

other, because all of them arerepresenting the same system.Can be used to validate each

other.


20/82


e University

USE CASE VIEWUSE CASE VIEW

This view documents the system fromthe customers perspective.

Terminology used in this view should bedomain specific.

Depending on the technical nature of ouraudience, we should avoid obscuretechnical terms.

Diagrams most common in this view are

the use case diagrams and, lesscommon, activity diagrams.Organizations transitioning to the UML

may wish to work only with use casediagrams early and experiment with

activity diagrams over time.


21/82


e University

Design VIEWDesign VIEW

This view documents the systemfrom designers and architectsperspective.

Diagrams most common in thisview are class and interactiondiagrams (either sequence or

collaboration), as well aspackage diagrams illustratingthe package structure of ourJava application.


22/82


e University

Development VIEWDevelopment VIEW

This view documents thecomponents that the system iscomposed of.

This view typically containscomponent diagrams.

Except for the most complex

Java applications, this view isoptional.


23/82


e University

Process VIEWProcess VIEW

This view documents theprocesses and threads thatcompose our application.

These processes and threadstypically are captured on classdiagrams using an active class.

Because of the advanced natureof active classes, coupled withthe volume of use, activeclasses are beyond the scope ofthis discussion.


24/82


e University

Physical VIEWPhysical VIEW

This view documents the systemtopology.

Deployment diagrams that

compose this view illustrate thephysical nodes and devices thatmake up the application, as well

as the connections that existbetween them.


25/82


e University

VIEWS (cont.)VIEWS (cont.)

We are not limited with the listedviews.

If there is something that

architecturally important, forexample security, then we maycreate a new view (ex: security

view) into the system from thatperspective.


26/82


27/82


e University

Diagrams - The foundation ofDiagrams - The foundation ofUMLUMLUse Case Diagrams

Requirements

Activity Diagrams

Generally what, not who - good to detect parallelism

Interaction Diagrams

Collaboration/Communication Diagrams (objectcentered)

Sequence Diagrams (timeline)

Static Structure Diagrams

Objects/Classes/Packages

Statechart Diagrams States of objects with interesting lifecycles

Implementation Diagrams

Component Diagrams

Deployment Diagrams


28/82


e University

DIAGRAMSDIAGRAMS

As weve seen, wecan combinediagrams that formmodels and thatcan serve as viewsinto our system.

If an advantage inmodeling is tocombine diagramsto form views intoour system, then itonly makes sensethat each diagram

has a differentfocus on what itcommunicates.

Each falls into one oftwo categories:behavioral, andstructural.

Most commonly used


29/82


30/82


31/82


32/82


e University

RelationshipsRelationships

An association is a bi-directional connectionbetween classes An association is shown as a line connecting the

related classes

An aggregation is a stronger form of

relationship where the relationship isbetween a whole and its parts An aggregation is shown as a line connecting the

related classes with a diamond next to theclass representing the whole

A dependency relationship is a weaker formof relationship showing a relationshipbetween a client and a supplier where theclient does not have semantic knowledgeof the supplier

A dependency is shown as a dashed line


33/82


e University

Relationship NotationRelationship Notation

1 - one and only one4 - four and only 40..1 - zero or 15..10 - five to and including 100..* - zero or more4..* - four or more


34/82


35/82


e University


RegistrationForm

RegistrationManager

Course

Student

CourseOfferingProfessor

addStudent(Course, StudentInfo)

namenumberCredits

open()

addStudent(StudentInfo)name

major

location

open()

addStudent(StudentInfo)

name

tenureStatus

ScheduleAlgorithm


36/82


e University

AssociationsAssociations

Person

Manages

JobCompany

boss

worker

employeeemployer

1..

0..1

Job

Account

Person

Corporation

{Xor}

salary


37/82


38/82


e University

Relationship NotationRelationship Notation

1 - one and only one4 - four and only 40..1 - zero or 1

5..10 - five to and including 100..* - zero or more4..* - four or more


39/82


e University

Ternary AssociationsTernary Associations

PlayerTeam

Year

Record

goals forgoals againstwinslosses

goalkeeper

season

team

ties


40/82


e University

CompositionComposition

Window

scrollbar [2]: Slidertitle: Headerbody: Panel

Window

scrollbar title body

Header Panel

21 1

Slider

111


41/82


e University

CompositionComposition (contd)(contd)

scrollbar:Slider

Window

2

title:Header1

body:Panel 1


42/82


e University

GeneralizationGeneralization

Shape

SplineEllipsePolygon

Shape

SplineEllipsePolygon

Shared Target Style

Separate Target Style

. . .

. . .


43/82


e University

GeneralizationGeneralization

Vehicle

WindPoweredVehicle

MotorPoweredVehicle

Land

Vehicle

Water

Vehicle

venue

venuepower

power

SailboatTruck

{overlapping} {overlapping}


44/82


e University

DependenciesDependencies

friendClassA ClassB

ClassC

instantiate

call

ClassD

operationZ()friend

ClassD ClassE

refineClassC combines

two logical classes


45/82


e University

DependenciesDependencies

Controller

DiagramElements

Domain

ElementsGraphicsCore

access

accessaccess

access

access


46/82


47/82


e University

LinksLinks

downhillSkiClub:Club Joe:Person

Jill:Person

Chris:Person

member

member

member

treasurer

officer

president

officer


48/82


e University

Constraints and CommentsConstraints and Comments

M em b e r-of

C h ai r -of

{ subse t }P e rs o n C o m m itt e e

P e r so n C o m p a n y

b o s s

{ Pe r son .em p l oye r =

Pe r son .boss .em p loy e r }

em p loyere m p lo ye e

0 . .1

0 . .1

1

R epre sen ts

an incorpora ted en t i t y .


49/82


e University

ActorsActors

An actor is someone or something that interacts with thesystem

External Forces Human interaction

Automated System

KeyboardOperatorUser

DriverTraffic Control

System


50/82


e University

Use CasesUse Cases

A use case is a pattern of behavior the systemexhibits Each use case is a sequence of related

transactions performed by an actor and thesystem in a dialogue

Details what the system must provide to theactor when the use cases is executed

A flow of events document is created for eachuse case Written from an actor point of view Actors are examined to determine their how

they interact with the system Break down into the most atomic actions possible

Typical contents How the use case starts and ends Normal flow of events Alternate flow of events Exceptional flow of events


51/82


e University

Use case diagramsUse case diagrams

Use case diagrams are centered aroundthe business processes that ourapplication must support.

Most simply, use case diagrams enableus to structure our entire applicationaround the core processes that it mustsupport.

Doing so enables us to use these usecases to drive the remainder of themodeling and development effort.

Shows a set of actors and use cases,

and the relationships between them.Use case diagrams contribute to

effective model organization, as well asmodeling the core behaviors of asystem.


52/82


e University

Use Case DiagramUse Case Diagram

Captures system functionality asseen by users

Built in early stages of

developmentPurpose Specify the context of a system

Capture the requirements of a

system Validate a systems architecture

Drive implementation andgenerate test cases

Developed by analysts and


53/82


e University


Use case diagrams are createdto visualize the relationshipsbetween actors and use cases

Passager

Mechanic

Driver

Lost Luggage

Ramp Maintenance

Pay toll

Customer Service Agent


54/82


e University


Captures system functionality asseen by users


55/82


e University

CollaborationCollaboration DiagramsDiagrams

A type of interaction diagramthat describes theorganizational layout of the

objects that send and receivemessages.Semantically equivalent to a

sequence diagram.It uses class diagrams layout,

and can be used to make morecohesive and less coupled

classes.


56/82


57/82


e University

Sequence DiagramsSequence Diagrams

Semantically equivalent to acollaboration diagram.

sequence diagram is a type of

interaction diagram thatdescribes time ordering ofmessages sent betweenobjects.

Almost in all softwaredevelopment activity, thisdiagram is used.


58/82


e University

Sequence DiagramSequence Diagram

A sequence diagram displaysobject interactions arranged ina time sequence

PassengerCounterAgent

TicketGateAgent

1: Give Info

3: Answer4: Print

6:Present7: Board

9: Return8: Overbook

2: Questions

Plane

5: Safeguard


59/82


e University

The State of an ObjectThe State of an Object

A state transition diagram showsThe life history of a given class

The events that cause a transition

from one state to anotherThe actions that result from a

state change

State transition diagrams are

created for objects withsignificant dynamic behavior


60/82


e University

State Transition DiagramsState Transition Diagrams

Illustrates internal state-relatedbehavior of an object.

Transitions between states help

identify, and validate, complexbehavior.A class can have at most a single

state diagram.


61/82


e University

State Transition DiagramState Transition Diagram

InitializationOpen

entry: Register student

exit: Increment count

Closed

Canceled

do: Initialize course

do: Finalize course

do: Notify registered students

Add Student /Set count = 0

Add student[ count < 10 ]

[ count = 10 ]

Cancel

Cancel

Cancel


62/82


e University

Activity DiagramsActivity Diagrams

Models the flow of activitybetween processes.

These diagrams are most useful

in detailing use case behavior.An activity diagram doesnt show

collaboration among objects.


63/82


e University

STRUCTURAL DIAGRAMSSTRUCTURAL DIAGRAMS

Diagrams in this category are focused onspecifying the static aspects of our system.

Of these four diagrams, the class diagram is mostoften used.

when transitioning to the UML, most organizationstend to use class diagrams first because theyare excellent mechanisms for communication

among developers, as well as tools that can beused for problem solving.There are two forms of class diagrams.The first is the most commonly understood and

consists of the classes that compose our systemand of the structure among these classes.

Unfortunately, the second is not often used but isof equal importance and can be most effectivein helping developers understand our systemfrom a high level.

A type of class diagram, called apackage diagram,often represents the Java packages and thedependencies between them that our

application consists of.


64/82


e University

Class DiagramsClass Diagrams

Illustrates a set of classes,packages, and relationshipsdetailing a particular aspect of

a system.This diagram is likely the most

common one used in modeling.


65/82


66/82


67/82


e University

ObjectObject DiagramsDiagrams

Provides a snapshot of the systemillustrating the static relationships thatexist between objects.

Object diagrams depict the structuralrelationship that exists among the objectswithin our running application at a givenpoint in time.

When we think of the runtime version of oursystem, we typically think of behavior.

Many people have found that objectdiagrams are most useful in fleshing outthe instance relationships among objects,which in turn can help verify our classdiagrams.

Beyond this, object diagrams are not oftenused.


68/82


e University


Relationships provide a pathwayfor communication betweenobjects

Sequence and/or collaboration

diagrams are examined todetermine what links betweenobjects need to exist toaccomplish the behavior -- if twoobjects need to talk there must

be a link between themThree types of relationships are:

Association Aggregation Dependency


69/82


e University

Multiplicity and NavigationMultiplicity and Navigation

Multiplicity defines how many objectsparticipate in a relationships Multiplicity is the number of instances of

one class related to ONE instance ofthe other class

For each association and aggregation,there are two multiplicity decisions tomake: one for each end of therelationship

Although associations andaggregations are bi-directional bydefault, it is often desirable torestrict navigation to one direction

If navigation is restricted, an


70/82


e University

Multiplicity and NavigationMultiplicity and Navigation

RegistrationForm

RegistrationManager

Course

Student

CourseOffering

Professor


name

numberCredits

open()

addStudent(StudentInfo)major

location

open()


tenureStatus

ScheduleAlgorithm

10..*

0..*

1

1

1..*4

3..10

0..41


71/82


e University

InheritanceInheritance

Inheritance is a relationshipsbetween a superclass and itssubclasses

There are two ways to findinheritance: Generalization

Specialization

Common attributes, operations,and/or relationships are shownat the highest applicable level

in the hierarchy


72/82


e University

InheritanceInheritance

RegistrationForm

RegistrationManager

Course

Student

CourseOffering

Professor


name

numberCredits

open()

addStudent(StudentInfo)major

location

open()


tenureStatus

ScheduleAlgorithm

name

RegistrationUser


73/82


e University

The Physical WorldThe Physical World

Component diagrams illustratethe organizations anddependencies among software

componentsA component may be

A source code component

A run time components or

An executable component


74/82


e University

ComponentComponent DiagramsDiagrams

Addresses the staticrelationships existing betweenthe deployable softwarecomponents.

Examples of components may be.exe, .dll, .ocx, jar files, and/orEnterprise JavaBeans.

Component diagrams might beused to show the softwarecomponents within ourapplication.

Com onents arent e uivalent to


75/82

l i h S


76/82


e University

Deploying the SystemDeploying the System

The deployment diagram showsthe configuration of run-timeprocessing elements and the

software processes living onthemThe deployment diagram

visualizes the distribution ofcomponents across theenterprise.

D l Di


77/82


e University

Deployment DiagramDeployment Diagram

Captures the topology of a systemshardware

ibili h iE ibili M h i


78/82


e University

Extensibility MechanismsExtensibility Mechanisms

StereotypeTagged valueConstraint

di hE t di th UML


79/82


e University

Extending the UMLExtending the UML

Stereotypes can be used toextend the UML notationalelements

Stereotypes may be used toclassify and extendassociations, inheritancerelationships, classes, and

componentsExamples: Class stereotypes: boundary,

control, entity, utility, exception

Inheritance stereotypes: uses and

D lD l t DiDi


80/82


e University

DeploymentDeployment DiagramsDiagrams

Describes the physical topology of asystem.

Typically includes various processingnodes, realized in the form of a device

(for example, a printer or modem) or aprocessor (for example, a server).

Deployment diagrams are most usefulwhen we have a complex configuration

environment.If our application is to be deployed to

multiple servers, across locations, adeployment diagram might be useful.


81/82


e University

Q & AQ & A time to ask questions


82/82

e University

Thank you!Thank you! take a break

Uml Intro h1

Documents

Transcript of Uml Intro h1