UML part Idyja/pliki/SE/lecture03.pdf · 2015-10-27 · Client Client UML – part I 9/41....

UML – part I

UML – part I 1/41

UML - Unified Modeling Language

I unified – it can be shared among workersI modeling – it can be used for description of software modelI language – it has defined structure

UML – part I 2/41

UML – properties

Properties of UML:

I it’s a formal languageI it’s conciseI it’s comprehensiveI it’s scalableI it’s built on lessons learnedI it’s the standard

UML – part I 3/41

UML – history

”Three amigos”

I OOAD (Object-Oriented Analysis and Design) – Grady BoochI OOSE (Object-Oriented Software Engineering) – Ivar

JacobsonI OMT (Object Modeling Technique) – James Rumbaugh

UML – part I 4/41

UML – now

OOSE

Jacobson

OOAD

Booch

OMT

Rumbaugh

Use Case

Class

Object

Sequence

State Machine

Brought about by

the adoption of best

practices across

many other

approaches

Component

Composite Structure

Package

Communication

Activity

Interaction Overview

Timing

Deployment

UML 2.0 diagram types

Directly Influenced

UML – part I 5/41

”Degrees” of UML

Levels:I UML as a sketchI UML as a blueprintI UML as a programming language

UML – part I 6/41

Model views

Logical View Process View

Physical View Development View

Use Case

View

Figure: Philippe Kruchten’s 4+1 view model

UML – part I 7/41

Components of UML

I elementsI relationshipsI diagrams

UML – part I 8/41

A First Taste of UML

I Notes – additional comments that aren’t captured in yourdiagrams

I Stereotypes – signify a special use or intent

Client

<<actor>>

Client

UML – part I 9/41

Modeling Requirements – Use Cases

Use CaseI is a case (or situation) where your system is used to fulfill one

or more of your user’s requirementsI is a functional requirementI does not specify what the system shall not do

UML – part I 10/41

Modeling Requirements – Actors

ActorsI don’t have to be actual people.I should be treated as black boxesI must interact with your system


Use Cases – Actors

Is a "thing" an actual

person interacting

with the system?

Is a "thing" something

that I can change within

the system’s design?

Yes

No

No

Yes

A thing is not an actor A thing is an actor

Identify a "thing" from your requirements


Use Cases – Actors

Person

Student

The more general

"Person" actor

The Generalization Arrow

The more specialized

"Student" actor

Figure: Refining actors


Use Cases

Create a

new personal Wiki

Figure: Notation

Use CaseI from the user’s perspective is a complete use of the systemI consists of interaction with the system, as well as some output

from that interactionI must have very clear pass/fail criteria


Communication Lines

Create a

new personal Wiki

Administrator

Figure: A communication line joins the actor to the use case

I communication between the actor and the use caseI an arrow at one end of communication line shows the flow of

information between the actor and the use case, or show whostarts the use case.


System Boundaries

Create a

new personal Wiki

Administrator

Content Management System

Figure: The Administrator actor is located outside of the CMS, explicitlyshowing that the system boundary box use cases must fall within thesystem boundary box


Use Case Descriptions

Use case description detail What the detail means and why it is useful?Related Requirements Some indication as to which requirements this use case partially or

completely fulfills.Goal In Context The use case’s place within the system and why this use case is im-

portant.Preconditions What needs to happen before the use case can be executed.Successful End Condition What the system’s condition should be if the use case executes suc-

cessfully.Failed End Condition What the system’s condition should be if the use case fails to execute

successfully.Primary Actors The main actors that participate in the use case. Often includes the

actors that trigger or directly receive information from a use case’sexecution.

Secondary Actors Actors that participate but are not the main players in a use case’sexecution.

Trigger The event triggered by an actor that causes the use case to execute.Main Flow The place to describe each of the important steps in a use case’s

normal execution.Extensions A description of any alternative steps from the ones described in the

Main Flow.


A complete use case description

Use case name Create a new Blog AccountRelated Requirements Requirement A.1.Goal In Context A new or existing author requests a new blog account from the Administra-

tor.Preconditions The system is limited to recognized authors and so the author needs to have

appropriate proof of identity.Successful End Condition A new blog account is created for the author.Failed End Condition The application for a new blog account is rejected.Primary Actors Administrator.Secondary Actors Author Credentials Database.Trigger The Administrator asks the CMS to create a new blog account.Main Flow Step Action

1. The Administrator asks the system to create a new blog account.2. The Administrator selects an account type.3. The Administrator enters the author’s details.4. The author’s details are verified using the Author Credentials Database.5. The new blog account is created.6. A summary of the new blog account’s details are emailed to the author.

Extensions Step Branching Action4.1. The Author Credentials Database does not verify the author’s details.4.2. The author’s new blog account application is rejected.


Use Case Relationships

Create a new

Blog Account

Check

Identity

Create a

new personal Wiki

<<include>>

<<include>>

Author

Credentials

Database

Administrator


Figure: The <<include>> relationship supports reuse between use cases



Create a new

Blog Account

Check

Identity

Create a

new personal Wiki

<<include>>

<<include>>

Author

Credentials

Database

Administrator


Create a new

Regular Blog

Account

Create a new

Editorial Blog

Account

Figure: Two types of blog account, regular and editorial, can be createdby the Management System



Create a new

Blog Account

Check

Identity

Create a

new personal Wiki

<<include>>

<<include>>

Author

Credentials

Database

Administrator


Create a new

Regular Blog

Account

Create a new

Editorial Blog

Account

Record

Application

Failure

<<extend>>

<<extend>>

Figure: The <<extend>> relationship comes into play to show thatboth the ”Create a new Personal Wiki” and ”Create a new BlogAccount” use cases might occasionally share the application rejectionrecording behavior


Activity Diagrams

I they belong to the process viewI they show high-level actions chained together to represent a

process occurring in systemI simple notation


Activity Diagrams – example

Ask System to Create new

Blog Account

Select Account

Type

Enter the Author’s

Details

Verify the Author’s

Details

Create new Blog

Account

Email Blog Account

Summary to Author

Reject Application

[authorized] [not authorized]


Activity Diagrams

Lather Rinse Dry

Wash car

Activity

nameAction

Initial

node

Activity

final nodeEdge

Activity

frame


Activity Diagrams

Figure: decision node

Guard conditions:I statements that evaluate to true or falseI examples of guard conditions:

I [Authorization], [wordCount >= 100],[wordCount > 0 & wordCount < 100]

I only one condition can evaluate to trueUML – part I 25/41

Activity Diagrams

Prepare

Case

Prepare

Motherboard

Install

Motherboard

Install

Drives

Install Video Card

and other Parts

Fork Join

Figure: Both outgoing paths are followed at the fork


Objects and pinsReceive Order

RequestRequest

Approve

Payment

Submit

Order

Object

node

Figure: The Order object node emphasizes that it is important data inthis activity and shows which actions interact with it

Receive

Order Request

Approve

Payment

Submit

Order

Output pin

Order

Order

Input pin

Figure: Pins in this change request approval process allow finer-grainedspecification of input and output parameters


Activity diagrams

Calculate TotalUpadate Order

Status

Send Signal

Node

Receive

Response

Receive Signal

Node

Send Request for

Credit Card Approval

Figure: Send and receive signal nodes show interactions with externalparticipants


Activity diagrams

Other elementsI partitions (swimlanes)I time eventsI Calling Other Activities


Sequence Diagrams

I logic viewI show runtime interactions between the parts that make up a

system


Sequence Diagrams – Participants

participant1:ParticipantClass1 participant2:ParticipantClass2

participants

lifelines

Figure: Participants in a Sequence Diagram


Sequence Diagrams – Participants

Participant Names

I AdminI :ContentManagementSystemI admin:AdministratorI :ContentManagementSystem ref cmsInteraction


Sequence Diagrams – Messages

participant1:ParticipantClass1 participant2:ParticipantClass2

The Message

Caller

message(arguments)

The Message

Receiver

Message Caller

Activation Bar

(optional)

The Message Receiver

Activation Bar

(optional)

The Message

Signature

The Message

Return Arrow

(optional)

Figure: Sending a message



Message Signatures

I doSomething()I doSomething(number1:Number, number2:Number)I doSomething():ReturnClassI myVar = doSomething():ReturnClass



p1:Class

A Synchronous Message

An Asynchronous Message

A Return Message

A Participant Creation Message

A Participant Destruction Message

<<create>>

<<destroy>>

Figure: Types of message arrow for use on sequence diagram


Sequence Diagrams – Example

The Create a new Regular Blog Account use caseMain Flow Step Action

1. The Administrator asks the system to cre-ate a new blog account.

2. The Administrator selects the regular blogaccount type.

3. The Administrator enters the author’s de-tails.

4. The author’s details are checked using theAuthor Credentials Database.

5. The new regular blog account is created.6. A summary of the new blog account’s de-

tails are emailed to the author.



Figure: The Create a new Regular Blog Account sequence diagram



Figure: The Create a new Regular Blog Account sequence diagram withSequence Fragments



Figure: The Create a new Regular Blog Account sequence diagram withSequence Fragments – cont.



sd Select Blog Account Type

createNewBlogAccount()

<<actor>>

admin:Administrator:ContentManagementSystem

selectBlogAccountType(type)

Figure: The Create a new Regular Blog Account sequence diagram withSequence Fragments – cont.


Bibliography

I Miles R., Hamilton K.: Learning UML 2.0, Helion, Gliwice2007


Date post:	03-Jul-2018
Category:	Documents
Upload:	vanlien
View:	218 times
Download:	0 times

UML part Idyja/pliki/SE/lecture03.pdf · 2015-10-27 · Client Client UML – part I 9/41....

Documents