UML Overview [2/2] - SE LAB | KAISTse.kaist.ac.kr/.../2017/02/CS350_03_UML-Overview_2.pdf ·...

UML Overview [2/2]Young-Min Baek, Mingyu Jin, Wonbin Kim,

and Doo-Hwan Bae1,2Korea Advanced Institute of Science and Technology (KAIST)

Daejeon, Republic of Korea

{ymbaek, mgjin, wbkim, bae}@se.kaist.ac.kr

2017 SpringCS350 Introduction to Software Engineering

Software Engineering Lab (SELab), KAIST

Outline 1. Review of UML

2. Modeling RequirementsA. What are the Requirements?

B. Use Case Diagram

C. Use Case Specification

3. Modeling System StructureA. Class Diagram

B. Representing Class States & Behaviors

4. Modeling Ordered InteractionsA. Sequence Diagram

B. State Machine Diagram

5. UML Support Tools

2017 Spring. [CS350] Introduction to Software Engineering – UML Overview [2/2] 2/74Reference: Learning UML 2.0 by Russ Miles & Kim Hamilton

Review of UML

2017 Spring. [CS350] Introduction to Software Engineering – UML Overview [2/2] 3/74

Unified Modeling Language (UML)

UML Review Modeling Requirements Modeling System Structure Modeling Ordered Interactions

The UML is a visual modeling language used to describe the model of software system Structure: What are software’s features? Behavior: What constitutes the software and how do they interact?

Structural diagram of UML Behavioral diagram of UML

4/74

UML Diagrams (1/2)


5/74

UML Diagrams (2/2)


Class Diagram

ComponentDiagram

CommunicationDiagram

Interaction OverviewDiagram

Sequence Diagram

TimingDiagram

Use CaseDiagram

State MachineDiagram

ActivityDiagram

PackageDiagramComposite

StructureDiagram

ObjectDiagram

DeploymentDiagram

Interaction Diagram

BehavioralDiagram

StructuralDiagram

6/74

In This Lecture,


We will study three types of UML diagrams: Use-case diagram

A high level visualization of how the system works

Built on requirement specifications from discussions with developers, customers, and/or end users

Class diagramA collection of static model elements such as classes and types, their

contents, and their relationships

Sequence diagramModel of sequential logic, in effect the time ordering of messages

between classifiers

7/74

In This Lecture,


Diagrams we will learn for analysis & design

Analysis Design

Use-casemodel

Domainmodel

Sequence model

Classdiagram

State machinediagram

Composite structure(Signal, Interface etc.)

Generated Code

Refinement

8/74

Use-Case Diagram:Modeling Requirements

2017 Spring. [CS350] Introduction to Software Engineering – UML Overview [2/2]

To describe WHAT the system will doat a high-level

9/74

Software Requirements is a field within software engineering that deals with establishing the needs of stakeholders that are to be solved by software[1,2].

What is a Software Requirement?


[1] Wiegers, Karl (2002). Software Requirements (2nd ed.). Microsoft Press. ISBN 0-07-285059-0.[2] https://en.wikipedia.org/wiki/Software_requirements 10/74

Requirements elicitation is the practice of collecting the requirements of a system from users, customers, and other stakeholders[1]

If the elicitation fails[2],

Requirements Elicitation


[1] Requirements Engineering A good practice guide, Ramos Rowel and Kurts Alfeche, John Wiley and Sons, 1997[2] Creative Commons License by www.projectcartoon.com

How the customerexplained it

How the project leader understood it

How the analyst designed it

How the programmer wrote it

How the business consultant described it

How the project was documented

What operations installed

How the customer was billed

How it wassupported

What the customer really needed

11/74

Actor Someone or something that must interact with the system under

developmentUsers, external systems, devices

Use Case Functionality that the system shall offer to an actor Interaction between one or more actors and the system

Actor & Use Case


12/74

1. Capturing a system requirement Analyze requirements

2. Describing system requirements Capture actors Capture use cases Connect communication lines Draw system boundaries

3. Describe use cases Complete use case descriptions

Steps for Software Requirements Specification (SRS)


13/74

Step 1: Capturing a System Requirement


Analyze requirements Weblog content management system (CMS)

There is no specific best way to start analyzing requirements, but we can look at things

that interact with the system for starters.

14/74

Step 2: Describing System Requirements


Capture actors Weblog content management system (CMS)

In use cases,actors interact with the system,

but they are not part of the system

15/74




In use cases,actors interact with the system,

but they are not part of the system

The Administrator interacts with the system to create a new blogger’s account, but he/she is not part of the system

16/74




The Administrator interacts with the system to create a new blogger’s account, but he/she is not part of the system

17/74




Deciding what is and what is not an actor is tricky. An actor can be a person or a third party’s system. Not all actors are obvious external systems or people

that interact with your system. Considering other stakeholders is important

How to identify an actor? See appendix

18/74



Capture use cases To find cases where the system is being used to complete a

specific job for an actor – use cases.Use cases can be identified from user’s requirements.

From Requirement A.1, the main use of the CMS is to <create a new blog account>

Create a New Blog Account

Start with a verb

19/74



Connect communication lines To connect an actor and a use case to show the actor

participating in the use caseCommunication lines show the flow of information or who starts the

use case.

20/74



Draw system boundaries To show your system’s boundary on a use case diagram explicitly

Draw a box around all of the use cases but keep the actors outside

Name the box with the name of your system (or subsystem)

21/74

Step 3: Describing Use Cases


Complete use case descriptions A use case description is in the form of a text-based description. Every use case should be accompanied by one.

Include important information to describe a use caseUse 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 important.

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 successfully.

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’s execution.

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

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.

22/74



Complete use case descriptions A use case description is in the form of a text-based description. Every use case should be accompanied by one.

Include important information to describe a use caseUse 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 important.

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 successfully.

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’s execution.

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

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.

• Provide enough detail for your system designers• To complete the use cases• To find missing items• To capture all of the key uses of your system

The more detail you put in, the better and more accurate model you will get

23/74



Example of use case description (1/2)

Use case name Create a new Blog Account

Related Requirements Requirement A.1.

Goal In Context A new or existing author requests a new blog account from the Administrator.

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.

24/74



Example of use case description (2/2)

Main Flow Step

1

2

3

4

5

6

Action

The Administrator asks the system to create a new blog account.

The Administrator selects an account type.

The Administrator enters the author’s details.

The author’s details are verified using the Author Credentials

Database.

The new blog account is created.

A summary of the new blog account’s details are emailed to the

author.

Extensions Step

4.1

4.2

Branching Action

The Author Credentials Database does not verify the author’s details.

The author’s new blog account applications is rejected.

Use case name Create a new Blog Account

25/74

Why do we need use case relationships? To provide your system’s designers with some architectural

guidance so they can efficiently break down the system’s concernsThere may be some similarity between steps in different use cases

There may be some use cases working in several different modes or special cases.

Use Case Relationships


26/74

Why do we need use case relationships? Weblog content management system (CMS) example



Content Management System

Administrator

Create a new Blog Account

AuthorCredentialsDatabase

Create a new

Personal Wiki

Requirement A.2

The content management system shall allow an administrator to create a new personal Wiki, provided the personal details of the applying author are verified using the Author Credentials Database.

27/74

Why do we need use case relationships? Weblog content management system (CMS) example

There is a repetitive behavior, which is checking the applicant’s credentials, in both use cases.



Requirement A.2

The content management system shall allow an administrator to create a new personal Wiki, provided the personal details of the applying author are verified using the Author Credentials Database.

Requirement A.1

The content management system shall allow an administrator to create a new blog account, provided the personal details of the new blogger are verified using the author credentials database.

Check Identity

Both requirements include the same behavior

28/74

Redundancy in use case descriptions A use case can be reused by multiple use cases using the

<<include>> relationship.The <<include>> relationship declares that the use case at the tail of

the dotted arrow completely reuses all of the steps from the use case being included.

Use Case Relationships: <<include>>



Administrator



Create a new Personal Wiki

Check Identity

<<include>>

<<include>>

29/74

Redundancy in use case descriptions A use case can be reused by multiple use cases using the

<<include>> relationship.The <<include>> relationship declares that the use case at the tail of

the dotted arrow completely reuses all of the steps from the use case being included.

Use Case Relationships: <<include>>



Administrator




Check Identity

<<include>>

<<include>>

<use case A> includes <use case B>=

<use case A> completely reuses all of the steps from the <use case B> being included

30/74

Use case inheritance Use case inheritance is useful when you want to show that one

use case is a special type of another use case.

Use Case Relationships: Generalization



Administrator




Check Identity

<<include>>

<<include>>

Create a new Regular

Blog Account

Create a new Editorial Blog Account

Inheritance

31/74

Optional reuse depending on a runtime or system implementation decision Example: the <Record Application Failure> use case is executed only

when an author applies and is rejected to create a blog or Wiki

Use Case Relationships: <<extend>>



Administrator



Create a new

Personal Wiki

Check Identity

<<include>>

<<include>>


Blog Account

Create a new Editorial

Blog Account

Record Application

Failure<<extend>>

<<extend>>

<Record Application Failure> extendstwo use cases’

behavioral options

32/74

Example Use Case Diagram


Telephone Catalog

Check Status

Place Order

Arrange Payment

Supply Customer

DataActor

Customer

Use Case

Use Case Name

Subject NameSubject

System Boundary

Association

<<include>> <<include>>Dependency

33/74

Class Diagram:Modeling System Structure


To describe the types of objects in a system and the relationships between them

34/74

Class Most important building block of any object-oriented system

Logical system structure A system structure is made up of a collection of pieces often

referred to as objects.

Object, Instance and Class An instance of a class is an object

What is a Class? (1/2)


Class ObjectInstantiate

An instance of a class

35/74

State and behavior of a class A class contains two pieces of information:

The state information that objects of the class will contains

The behavior that will support

A class describes attributes and operations to represent state and behavior, respectively.They enable a class to describe a group of parts within your system

that share common characteristics such as state and behavior.

What is a Class? (2/2)


Class Attributes

Class Operations

Person

- Name: String- Age: Integer

+ getName()+ getAge()

Coffee

- Milk: Boolean- Sugar: Integer- Coffee : String

+ getCoffee()

36/74

Abstraction Discarding irrelevant details within a given context

Encapsulation[1] (same as encapsulation of OO) Enabling a class to hide the inner details of how it works from the

outside world and only expose the operation and data that it chooses to make accessible.Information hiding concept

Keeping the data safe and secure from external interventions

For Class Modeling,


[1] http://marchoeijmans.blogspot.kr/2012/06/encapsulation-concept.html 37/74

Steps for Class Modeling


[1] ISO/PAS 19450:2015, “Automation systems and integration --- Object-Process Methodology,” https://www.iso.org/obp/ui/#iso:std:iso:pas:19450:ed-1:v1:en

1. Finding possible system classes Analyze classes of your system: Coupling & Cohesion Draw class boxes

2. Describing class states with attributes

3. Describing class behaviors with operations

4. Specifying visibility to enforce encapsulation Analyze the accessibility/visibility of attributes or operations Describe visibility with symbols

5. Describing relationships between classes

6. Describing additional characteristics, dependencies

38/74

https://www.iso.org/obp/ui/#iso:std:iso:pas:19450:ed-1:v1:en

How a class is drawn in UML: Split into up to three sections Top section: Name of the class Middle section: Attributes of the class (Optional) Bottom section: Operations of the class (Optional)

Step 1: Class Modeling with UML


ClassName

AttributeAttribute

OperationOperation

ClassName

AttributeAttribute

ClassName

OperationOperation

ClassName

If some sections are not shown,it does not imply that they are empty.

39/74

How to show attributes Attributes can be represented by

Placing them inside their section of the box --> Inline attributes

Association with another class

Step 2: Modeling Class States with Attributes


BlogEntry-entries

1 *

Inlineattributes

-name: String+publicURL: URL

Visibility

BlogAccount

Name Type

An attribute by association

40/74

How to show attributes Attributes can be represented by

Placing them inside their section of the box --> Inline attributes

Association with another class

Step 2: Modeling Class States with Attributes


BlogEntry-entries

1 *

Inlineattributes

-name: String+publicURL: URL

Visibility

BlogAccount

Name Type

An attribute by association

class BlogAccount {

private String name;

public URL publicURL;

...

}

class BlogAccount {

private BlogEntry[] entries;

...

}

class BlogEntry {...}

Any number of objects

41/74

How to represent operations Operations are specified on a class diagram with a signature that

is at minimum made up of:Visibility property

Name

Pair of parentheses for parametersReturn type

Step 3: Modeling Class Behaviors with Operations


BlogAccount

- name: String+ publicURL: URL- authors: Author [1..5]

+ addEntry(newEntry: BlogEntry, author: Author): Void

Visibility Name Parameters Return Type

An operation

42/74

How to enforce encapsulation By using visibility, a class selectively reveal its operations and data

to other classes.Once visibility characteristics are applied, you can control access to

attributes, operations, and entire classes to enforce encapsulation.

Step 4: Describing Visibility of Attributes/Operations


Visibility Notation Accessibility

Public + It can be accessible directly by any other class

Protected # It can be accessible by specialized classes(Part of the same class OR any other classes that inherit from the class)

Package ~ It can be accessible by any class in the same package

Private - It can be accessible within the declared class itself

43/74






More accessible to other parts of the system

Less accessible to other parts of the system

Name----------

(Notation)

44/74






https://www.spinellis.gr/umlgraph/doc/vis.gif 45/74

Relationships offered by UML

Step 5: Describing Relationships between Classes


Other relationships? http://static3.creately.com/blog/wp-content/uploads/2012/03/Class-Diagram-Relationships.png

Dependency Association Aggregation Composition Inheritance

Dashed Arrow Simple ConnectingLine

Empty Diamond Arrow

Filled Diamond Arrow

Empty Arrow

When objects of one class work

briefly withobjects of another

class.

When objects of one class workwith objects of

another class for some prolonged amount of time.

Weak‘whole-part”relationship

(‘has a’)

Strong“whole-part”relationships(‘contains a’)

Relationshipsbetween

superclass &subclasses

When one class owns but shares a

reference to objects of another class.

When one class contains objects of

another class

When one class is a type of another class.

Weaker Class Relationship Stronger Class Relationship

46/74

http://static3.creately.com/blog/wp-content/uploads/2012/03/Class-Diagram-Relationships.png

Relationships offered by UML - Examples



47/74

How to describe multiplicity of associations Number of instances of one class related to ONE instance of the

other class



Association name (verb phrase)

drinks1

MultiplicityPerson



Coffee

- Milk: Boolean- Sugar: Integer- Coffee: String

“One person drinks zero to many coffees”

*

Multiplicity

+ getCoffee()

48/74

Description of static structure using class diagram Foundation for the other diagrams

Example Class Diagram


Tea Coffee

- Milk: Boolean- Sugar: Integer- Coffee: String

Beverage

- Water: Integer

+ Addwater()

- Teabag: String

+ getTea() + getCoffee()

Person



Class Name

Class Attributes

Class Operations

1

*drinks

Association

Multiplicity

Generalization

49/74

Sequence Diagram:Modeling Ordered Interactions


To show sequences of messages between instances in the system in time order

50/74

Sequence Diagram (1/2)


To emphasize on the sequence of communications between parts (i.e., objects) Showing sequence of messages exchanged by objects/actors

performing a task. Emphasizing time ordering of messages Illustrating dynamic view of a system (like a snapshot)

Components of a sequence diagram Time line Activation box Lifeline Message represented as a labeled arrow

51/74



Example[1]

Sequence of actions for withdrawing cash from an ATM machine

[1] http://www.csie.nuk.edu.tw/~ayen/teach/se/se-noteUML.pdf

Time starts at the top of the page and progress

down the page

Message

Time represents ordering, not duration or real-time

52/74



Example[1]

Sequence of actions for course registration

[1] http://www.csie.nuk.edu.tw/~ayen/teach/se/se-noteUML.pdf 53/74

Steps for Interaction Modeling of S.D.


[1] ISO/PAS 19450:2015, “Automation systems and integration --- Object-Process Methodology,” https://www.iso.org/obp/ui/#iso:std:iso:pas:19450:ed-1:v1:en

1. Defining and placing participants1. Analyze possible participants in a use case2. Place participants with lifeline

2. Describing messages1. Define messages2. Describe message passing with activation bar & arrows

3. Describing creation and destruction of participants

4. Managing complex interactions with sequence fragments

54/74

https://www.iso.org/obp/ui/#iso:std:iso:pas:19450:ed-1:v1:en

Step 1: Defining and Placing Participants


Definition of participants Participants are the parts of your system that

interact with each other during the sequence.A sequence diagram is made up of a collection

of participants

Drawing lifelines for individual participants A lifeline states that the part exists at that point

in the sequence.

Representing active state of a participant Activation bars are used to show that a

participant is active.

Participant

55/74

Step 2: Describing Interaction Messages


How to specify messages (1/2) Messages are specified using an arrow from the message caller

to the message receiver.Whatever direction: left->right, right->left, back to itself

The Message Caller

Activation Bar(optional)

The Message

The Message Receiver

Return Arrow(optional)

participant1: PariticipantClass participant2: PariticipantClass2

message(arguments)

56/74



How to specify messages (2/2) Format of a message signature:

attribute = signal_or_message_name (arguments) : return_type

Format of an argument:<name> : <class>

Example message name Description

doSomething() The message’s name is doSomething, but no further information is known about it.

doSomething(number1 : Number, number2 : Number)

The message’s name is doSomething, and it takes two arguments, number1 and number2, which are both of class Number.

doSomething() : ReturnClass The message’s name is doSomething; it takes no arguments and returns an object of class ReturnClass.

myVar = doSomething() : ReturnClass

The message’s name is doSomething; it takes no arguments and returns an object of class ReturnClassthat is assigned to the myVar attribute of the message caller.

57/74



How to specify message types Five main types of message arrow

<< create >> p1: Class

<< destroy >>

A Synchronous Message

An Asynchronous Message

A Return Message

A Participant Creation Message

A Participant Destruction Message

58/74



How to describe nested messages More (Any number of) messages from one message

Initial Message Caller

The Initial Message Messages

nested inside Initial Message

participant1: PariticipantClass participant2

initialMessage(arguments)

participant3

nestedMessage1(arguments)

nestedMessage2(arguments)

59/74

Step 3: Describing Creation & Destruction


Participant creation and destruction messages Participants can be created and destroyed according to the

messages that are being passed. To show a participant is created:

Pass a create(..) message to the participant’s lifelineOr use the dropped participant box notation

To show a participant is deleted:Pass a destroy message to the participant’s lifelineAnd end the participant’s lifeline with the deletion cross.

participant1 : ParticipantClass1 participant2 : ParticipantClass2

create(arguments)

participant3 : ParticipantClass3

<< destroy >>

<< create >>

<< destroy >>60/74

Step 4: Managing Complex Interactions


Sequence Fragments A sequence fragment is represented as a box overlapping the

region of the sequence diagram.

fragment operator

[parameters]

61/74



Sequence Fragments: ref (referencing) Reuse already existing sequence diagrams

Reference

:Customer :CoffeeMachine

sd InsertCoins

Coin()

OK()

:Customer :CoffeeMachine

refInsertCoins

theMessage(“Insert Coins”)

Coffee()

CupofCoffee()

refReturnCoins

sd MakeCoffee

62/74



Sequence Fragments: alt (alternative) Show several alternative interactions

[1] http://www.tracemodeler.com/articles/a_quick_introduction_to_uml_sequence_diagrams/

More types of sequence fragments? See appendix

63/74

Example


Content Management System (CMS) Example Create a sequence diagram that models the interactions needed

for the <Create a new Regular Blog Account> use case.


Administrator



Create a new Personal

Wiki

Check Identity

<<include>>

<<include>>


Blog Account

Create a new Editorial Blog Account

Record Application

Failure<<extend>>

<<extend>>

64/74

Example


Content Management System (CMS) Example Top-level sequence diagram

<<actor>>admin: Administrator

: ContentManagementSystem<<actor>>

acd: AuthorCredentialsDB<<actor>>

es: EmailSystem

createNewBlogAccount

selectBlogAccountType(type)

enterAuthorDetails(author : AuthorDetails)

checkAuthorDetails(author : AuthorDetails)

createNewRegularBlogAccount(author : AuthorDetails)

sendEmail(email : Email)

emailBlogDetails(regularBlogAccount)

65/74

Example


Content Management System (CMS) Example Sequence diagram in detail

<<actor>>admin: Administrator

ui :AccountCreationUI

<<actor>>acd: AuthorCredentialsDB

<<actor>>es: EmailSystem

enterAuthorDetails(author : AuthorDetails)

checkAuthorDetails(author : AuthorDetails)

sendEmail(email : Email)

controller :CreateNewAccountController

createNewRegularBlogAccount(author : AuthorDetails)

emailBlogDetails(regularBlogAccount)

: AuthorDetails<<create>>

newAccount :RegularBlogAccount

<<create(authorDetails)>>

<<destroy>>

clickSubmit()

accountCreatedNotification()

opt

[checked=true]

ref

Select Account Type

66/74

UML Support Tools

2017 Spring. [CS350] Introduction to Software Engineering – UML Overview [2/2] 67/74

A sophisticated software modeling tool Compatible with UML 2.x Supports 11 key diagrams in UML:

Class, Use Case, Sequence, Object, Activity, Component, and etc.

StarUML (UML Tool)

http://staruml.io/68/74

Refer to StarUML 2 Documentationhttp://docs.staruml.io/en/latest/

http://docs.staruml.io/en/latest/

Tool information Site: http://staruml.io/download Latest version: v2.8.0 (3/20/2017) Supporting various OSs: Windows, macOS, Linux Unlimited use for evaluation

You may start a UML project with: An empty project consisting of

Use Case diagramClass diagramSequence diagram

The empty project file can be downloadedfrom KLMS or SE course site.

StarUML (UML Tool)

http://staruml.io/69/74

http://staruml.io/download

1. Select a diagram from Model Explorer panel. You can add or delete models. Even you can change some properties

including name, in Editors panel.

2. Select a figure you want to draw. You can find a lot of figures in Toolbox panel. Click on a figure, then draw it on the canvas

by making a drag&drop. If you click one more, the figure is locked

so that you can draw multiple figures in a row.

How to draw a Diagram?

70/74

3. Set proper values for the figure. Change its visibility and name. A note can be added for the figure

to describe detailed information. You can easily add some relevant figures

by clicking buttons on the right.

4. Set relationship between figures. As seen at step 2, select a relation figure. Drag from one figure to another figure. Now you have a relation between figures,

and set proper values for the relation.


71/74

5. Check your figures. You can see the hierarchy of the project

in Model Explorer panel. It includes your diagrams and figures.

6. Reuse the figures. If you want to use the same figure

in the same diagram or in another diagram,it is simply done by dragging itfrom Model Explorer panel to the canvas.


72/74

English http://staruml.sourceforge.net/docs/user-guide(en)/toc.html

Modeling Use Case Diagramhttp://staruml.sourceforge.net/docs/user-guide(en)/ch05_1.html

Modeling Class Diagramhttp://staruml.sourceforge.net/docs/user-guide(en)/ch05_2.html

Modeling Sequence Diagramhttp://staruml.sourceforge.net/docs/user-guide(en)/ch05_3.html

Korean http://staruml.sourceforge.net/docs/user-guide(ko)/toc.html

Modeling Use Case Diagramhttp://staruml.sourceforge.net/docs/user-guide(ko)/ch05_1.html

Modeling Class Diagramhttp://staruml.sourceforge.net/docs/user-guide(ko)/ch05_2.html

Modeling Sequence Diagramhttp://staruml.sourceforge.net/docs/user-guide(ko)/ch05_3.html

Star UML Guide (in both English & Korean)

73/74

http://staruml.sourceforge.net/docs/user-guide(en)/toc.html

http://staruml.sourceforge.net/docs/user-guide(en)/toc.html

http://staruml.sourceforge.net/docs/user-guide(en)/ch05_1.html



http://staruml.sourceforge.net/docs/user-guide(ko)/toc.html

http://staruml.sourceforge.net/docs/user-guide(ko)/ch05_1.html



List of Unified Modeling Language tools https://en.wikipedia.org/wiki/List_of_Unified_Modeling_Languag

e_tools

Other UML Support Tools

http://staruml.io/

Choose a freeware tool that supports UML 2.0 as possible.But, you can use most of tools with a free trial :)

74/74

https://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools

Thank You.

2017-Spring. CS350 Introduction to Software EngineeringUML Overview [2/2]

Young-Min Baek

Appendix


How to Identify Actors of Your System?Appendix A

Here is a simple technique for identifying an actor shown below:

Is it an actual person

interacting with the system?

Is it something that I can change

within the system’s design?

Identify a “thing” from your requirements

Yes

No

Yes

No

It is probably not an actor. Anything that you can affect and have

some control over when designing your system is likely to be considered a part of

your system.

It is probably an actor.Be careful when it comes to people;

some people can be considered part of your system.

Coupling & Cohesion

Modeling a System’s Logical Structure: Introducing Classes and Class Diagrams

Appendix B

Coupling Coupling refers to how related two classes / modulus are and how dependent

they are on each other. Problems with a High Degree of Coupling

When modifying a class, other classes that are related to that class also needs to be modified.

When comprehending a class, you have to understand all of the related classes. A class with high coupling may not be reusable in other programs.

Thus, a low degree of coupling is more desirable than a high dress of coupling.

Cohesion Cohesion refers to what the class / module will do. Low cohesion means the

class does a great variety of actions and is not focused on what it should do. High cohesion means the class is focused on what it should be doing.

Problems with a Low Degree of Cohesion Hard to understand Rarely reusable Hard for maintenance Sensitive to changes in other classes

Thus, a high degree of coupling is more desirable.

Message Types (1) Synchronous MessagesAppendix C

Synchronous Messages Invoked when the Message Caller waits for the Message Receiver to return

from the message invocation The interaction shown below is implemented in Java using a method

invocation.

messageCaller : MessageCaller messageReceiver : MessageReceiver

foo()

Message Types (2) Asynchronous MessagesAppendix D

Asynchronous Messages Invoked by a Message Caller on a Message Receiver, but the Message Caller

does not wait for the message invocation to return before carrying on with the rest of the interaction’s steps.

A common way of implementing in Java is to use threads.

messageCaller : MessageCaller messageReceiver : MessageReceiver

bar()

messageReceiver2 : MessageReceiver2

foo()

bar()

Sequence Fragment TypesAppendix E

Type Parameters Why is it useful?

ref None

Represents an interaction that is defined elsewhere in the model. Helps you manage a large diagram by splitting, and potentially reusing, a collection of interactions. Similar to the reuse modeled when the <<include>> use case relationship is applied.

assert None

Specifies that the interactions contained within the fragment box must occur exactly as they are indicated; otherwise the fragment is declared invalid and an exception should be raised. Works similar fashion to the assert statement in Java. Useful when specifying that every step in an interaction must occur successfully.

loopmin times, max times, [guard_condition]

Loops through the interactions contained within the fragment a specified number of times until the guard condition is evaluated to false. Very similar to the Java and C# for(..) loop. Useful when you are trying execute a set of interactions a specific number of times.

break NoneIf the interactions contained within the break fragment occur, then any enclosing interaction, most commonly a loop fragment, should be exited. Similar to the break statement in Java and C#.

alt

[guard_condition1]…[guard_condition2]…[else]

Depending on which guard condition evaluates to true first, the corresponding sub-collection of interactions will be executed. Helps you specify that a set of interactions will be executed only under certain conditions. Similar to an if(..) else statement in code.

Sequence Fragment TypesAppendix E

Type Parameters Why is it useful?

opt [guard_condition]

The interactions contained within this fragment will execute only if the guard condition evaluates to true. Similar to a simple if(..) statement in code with no corresponding else. Especially useful when showing steps that have been reused from another use case’s sequence diagrams, where <<extend>> is the use case relationship.

neg None

Declares that the interactions inside this fragment are not to be executed, ever. Helpful if you are just trying to mark a collection of interactions as not executed until you’re sure that those interactions can be removed. Most useful if you happen to be lucky enough to be using an Executable UML tool where you sequence diagrams are actually being run. Also can be helpful to show that something cannot be done. Works in similar fashion to commenting out some method calls in code.

par NoneSpecifies that interactions within this fragment can happily execute in parallel. This is similar to saying that there is no need for any thread-safe locking required within a set of interactions.

region None

Interaction within this type of fragment are said to be part of a critical region. A critical region is typically an area where a shared participant is updated. Combined with parallel interactions, specified using the par fragment type, you can model where interactions are not required to be thread- or process-safe (par fragment) and where locks are required to prevent parallel interactions interleaving (region fragment). Has similarities synchronized blocks and object locks in Java.

This is the end of the fileYoung-Min Baek

{ymbaek, bae}@se.kaist.ac.krhttp://se.kaist.ac.kr

UML Overview [2/2] - SE LAB | KAISTse.kaist.ac.kr/.../2017/02/CS350_03_UML-Overview_2.pdf ·...

Documents

Transcript of UML Overview [2/2] - SE LAB | KAISTse.kaist.ac.kr/.../2017/02/CS350_03_UML-Overview_2.pdf ·...