Introduction to Software Engineering

prettybadelyngeSoftware and s/w Development

Nov 18, 2013 (3 years and 9 months ago)

75 views

Introduction to Software Engineering

ECSE
-
321

Unit
5


Modeling with UML

Modeling


Describing a system at a high level of
abstraction


A model of the system


Used for requirements and specification


Many notations over time


State machines


Entity
-
relationship diagrams


Dataflow diagrams

Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 5


Modeling in UML /
2

Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit
5


Modeling in UML /
3

Why model software?

Software is already an abstraction: why model software?


Software is getting larger, not smaller


Firefox ~ 2 MLOC


Windows XP ~ 40 MLOC (Vista ~ 50 MLOC)


Mac OS X ~ 86 MLOC


Adobe CS ~ 100 MLOC


A single programmer cannot manage this amount of code
in its entirety.


Code is often not directly understandable by developers
(who did not participate in the development)


We need simpler representations for complex
systems

Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
4

Systems, Models, and Views


A
system
is an organized set of communicating
parts


A
model

is an abstraction describing a system or
a subset of a system


A
view

depicts selected aspects of a model


A
notation

is a set of graphical or textual rules for
representing views



Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
5

What is UML?


UML (Unified Modeling Language)


a
notation


A standard for modeling object
-
oriented software


Specifying


Visualizing


Constructing


Documenting


Language independent (OO
)


Designed by a committee


Reference: “The Unified Modeling Language
User Guide”, Addison Wesley, 1999.


www.uml.org


Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
6

What is UML?


Resulted from the convergence of notations
from three leading object
-
oriented methods:


OMT (James
Rumbaugh
), OOSE (
Ivar

Jacobson),
Booch

(Grady
Booch
), etc.


First edition: 1995, belongs to the Object Management Group
(
www.omg.org
)


Resulting design is huge


Many features


Many loosely unrelated styles under one roof


Could be called “union of all modeling
languages”!

Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
7

UML Aspects Covered Here


Functional
models
(functional behavior of the system as
seen by the user)


Use case
diagrams


Structural models
(static structure of the system: Objects,
Attributes, and Associations)


Class
diagrams


Object diagrams


Dynamic
models
(dynamic behavior between actors and
the system and between objects of the system)


Sequence diagrams


Activity diagrams


State diagrams

Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
8

Use
Case Diagrams

Used during requirements elicitation to
represent external behavior



Actors

represent roles, that is, a type of
user of the system


Use cases

represent a sequence of
interaction for a type of functionality


The
use case model

is the set of all use
cases. It is a complete description of the
functionality of the system and its
environment


A solid line represents communications
between actors and use cases

Passenger

PurchaseTicket

Communicate

Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
9

Actors


An actor models an external entity which
communicates with the system:


User


External system


Physical environment


An actor has a unique name and a
description


Examples:


Passenger: A person in the train


GPS satellite: Provides the system with GPS
coordinates


External database

Passenger

Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
10

Use Case

A use case represents a class of
functionality provided by the system
as an event flow.


A use case consists of:


Unique name


Participating actors


Entry conditions


Normal Flow of events


Alternate Flow of Events


Exit conditions


Special requirements (e.g., quality
requirements)

PurchaseTicket

Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
11

Use
Case
Diagram Example

WatchUser

WatchRepairPerson

ReadTime

SetTime

ChangeBattery

Actor

Use case

Package

SimpleWatch

Functionality of the system from
user
’s point of view

Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
12

Use Case Example

Name:

PurchaseTicket


Participating actor:

Passenger


Entry condition:



Passenger

standing in front of
ticket distributor.


Passenger

has sufficient
money to purchase ticket.


Exit condition:


Passenger

has ticket.

Event flow:

1.
Passenger

selects the
destination to be traveled.

2.
Distributor displays the
amount due.

3.
Passenger

inserts money,
of at least the amount due.

4.
Distributor returns change.

5.
Distributor issues ticket.



Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
13

Scenarios


An instance of a
use case


Concrete (names,
actions)


All names are
specific and
underlined


Flow of events is
step by step


Name:

purchaseTicketCCDeclined

Participating actor:

mike:Passenger

Flow of events:

1.
Mike stands in front of ticket machine
and selects Toronto as destination

2.
Distributor displays amount due

3.
Mike inserts credit card

4.
Distributor checks credit card validity
with company. Credit card is declined.

5.
Distributor ask for cash

6.
Mike pays cash

7.
Ticket is issued to Mike

Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
14

The
<<extend>>
Relationship

Passenger

PurchaseTicket

TimeOut

<<extend>>

NoChange

<<extend>>

OutOfOrder

<<extend>>

Cancel

<<extend>>

Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
15

Extend


Models
optional

behavior in the system


new functionality to the customer


functionality for a future iteration


The direction of the
<<extend>>

relationship is
to

the extended use case


Use cases representing exceptional flows can
extend more than one use case


If it is removed or not implemented, there is no
impact on the system (the related use case does
not know about the extension)


Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
16

Passenger

PurchaseSingleTicket

PurchaseMonthlyPass

<<include>>

CollectMoney

<<include>>

The <<include>> Relationship (re
-
use)

Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
17

Include


An
<<include>>

relationship represents
behavior that is factored out of the use
case.


An
<<include>>

represents behavior that
is
factored out

for reuse


The direction of a
<<include>>

relationship is
to the included

use case
(unlike
<<extend>>

relationships).


Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
18

Inheritance Relationship


Refinement of one use
case by another (“kind
of” relationship)


A solid line with triangle
pointing to the basic use
case


Different from
<<extend>>

which
describes a different
flow of events


CollectMoneyWithCard

CollectMoneyWithVISA

CollectMoneyWithAMEX

Class Diagrams


Describe classes


in
the OO sense


Class diagrams are
static


they display
what interacts but not
what happens when
they do interact


Each box is a class


list of fields


list of methods

Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 5


Modeling in UML /
19

Train

addStop

(stop)

startTrain
(velocity)

stopTrain
()

openDoors
()

closeDoors
()


lastStop

nextStop

velocity

doorsOpen
?


Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
20

Classes


A
class

represent a concept


Attribute and behavior of a set of objects


Each attribute has a
type


Each operation may have a
signature


The class name is the only mandatory information.

zone2price

getZones()

getPrice()

TariffSchedule

Table

zone2price

Enumeration

getZones()

Price

getPrice(
Zone
)

TariffSchedule

Name

Attributes

Operations

Signature

TariffSchedule

Type

Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
21

Class Diagrams


Class
diagrams are used


during requirements analysis to model problem domain
concepts


during system design to model subsystems and interfaces


during object design to model classes
.


Different kinds of edges to show relationships
between classes


TariffSchedule

*

*

TripLeg

price: Price

zone: Zone


Enumeration
getZones
()

Price
getPrice
(Zone)

Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
22

Objects (instances)


An
object

encapsulates state and behavior


An object has an indistinguishable identity


An object represents a phenomenon


The name of an instance is
underlined

and can contain
the class of the instance


The attributes are represented with their
values

zone2price = {

{‘1’, 20},

{‘2’, 40},

{‘3’, 60}}

tariff_1372:TarifSchedule

underlined

Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
23

Actor vs. Instances


What is the difference between an actor and a class and
an instance?


Actor:


An entity outside the system to be modeled, interacting with
the system (“Ticker Purchaser”)


Class:


An abstraction modeling an entity in the problem domain,
inside the system to be modeled (“Tariff Database”)


Object:


A specific instance of a class (“Joe, the traveler”, “The Tariff
Database from Montreal to Quebec City”)

Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
24

Associations


Associations denote relationships between classes
(“know of”)


Typically implemented by pointers


The multiplicity of an association end denotes how many
objects the source object can legitimately reference


Usually bi
-
directional


both classes “know of” each other


Enumeration getZones()

Price getPrice(Zone)

TarifSchedule

*

price

zone

TripLeg

*

Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
25

1
-
to
-
1 and 1
-
to
-
Many Associations

1
-
to
-
1 association

1
-
to
-
many association

*

draw()

Polygon

x:Integer

y:Integer

Point

1

Has
-
capital

name:String

Country

name:String

City

1

1

Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
26

Many
-
to
-
Many and Navigational Associations

many
-
to
-
many association

*

draw()

Polygon

x:Integer

y:Integer

Point

*

1
-
to
-
many association

with navigation


direction of usage

*

draw()

Polygon

x:Integer

y:Integer

Point

1

Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
27

Aggregation


An
aggregation

is a special case of association
denoting a “consists of” hierarchy


The
aggregate

is the parent class, the
components

are the children class

1

Car

Engine

Wheels

3..6

VIN

1

1

1

1

Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
28

Composition


A solid diamond denote
composition
, a strong
form of aggregation where components cannot
exist without the aggregate.

3

TicketMachine

ZoneButton

1

Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
29

Dependency


“I need your services, but I don’t know that you
exist” (client
-
supplier). Dashed line
from client to
supplier







Other examples?

draw()

Polygon

3DShadingAlgorithm

Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
30

Generalization


Generalization relationships denote
inheritance

between
classes (“a type of”)


The children classes inherit the attributes and operations
of the parent class


Generalization simplifies the model by eliminating
redundancy


Button

ZoneButton

CancelButton

Abstract classes

are
italicized

Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
31

A File System Example

FileSystemElement

File

Directory

*

1

FileSystemElement

File

Directory

*

*

Standard FS

Non hierarchical FS

Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
32

From Problem Statement to Code

Problem Statement

A stock exchange lists many companies. Each company is
identified by a ticker symbol

Class Diagram

Java Code

public class StockExchange {


public Vector Companies = new Vector();

};

public class Company {


public string tickerSymbol;


public Vector stockExchanges = new Vector();

};

*

StockExchange

tickerSymbol

Company

*

lists

Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
33

Example
-

ATM


What are the actors?


Use cases?


Relationship
between actors and use
cases




Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 5


Modeling in UML /
34


Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 5


Modeling in UML /
35

Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
36

UML Sequence Diagrams


Used during requirements analysis


To refine use case descriptions


to find additional objects
(“participating objects”)


Used during system design


to refine subsystem interfaces


Classes

are represented by
columns


Messages

are represented by
arrows


Activations

are represented by
narrow rectangles


Lifelines

are represented by
dashed lines (parallel to
activations)

selectZone ()

pickupChange()

pickUpTicket()

insertCoins()

Passenger

TicketMachine

Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
37

UML Sequence Diagrams: Nested Messages


The source of an arrow indicates the activation which
sent the message


An activation is as long as all nested activations


Dashed line denoted return of data flow

selectZone()

Passenger

ZoneButton

TarifSchedule

Display

lookupPrice(selection)

displayPrice(price)

price

Dataflow

return

…to be continued...

Nested

Activation

Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
38

Sequence Diagram Observations


UML sequence diagrams represent behavior in terms of
interactions


Complement the class diagrams which represent
structure


Help refine use cases


Useful to find participating objects


Time consuming to build but worth the investment


Other types of interaction diagrams exist (see UML
guide)


Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
39

State charts


Represent state machines


Moore (output per state) or Mealy (output
per transition)


Nested state charts


Focus on the behavior of a single object


Used for analysis and design


Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
40

Activity Diagrams


An activity diagram shows flow control within a system




A special case of a state chart diagram in which states
are activities (“functions”)


Two types of states:


Action state:



Cannot be decomposed any further


Happens “instantaneously” with respect to the level of
abstraction used in the model


Activity state:



Can be decomposed further


The activity is modeled by another activity diagram



Handle
Incident
Document
Incident
Archive
Incident
Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
41

Activity Diagram: Modeling Decisions

Open
Incident
Notify
Police Chief
Notify
Fire Chief
Allocate
Resources
[fire & highPriority]
[not fire & highPriority]
[lowPriority]
Branch

Handle incident

Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
42

Activity Diagrams: Modeling Concurrency


Splitting the flow of control into multiple threads


Synchronization of multiple activities

Synchronization

Splitting

Archive

Incident

Open

Incident

Document

Incident

Allocate

Resources

Coordinate

Resources

Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
43

Activity Diagrams: Swimlanes


Actions may be grouped into swimlanes to denote the
object or subsystem that implements the actions.








In this course we use activity diagrams mostly for
development management

Archive

Incident

Dispatcher

FieldOfficer

Open

Incident

Document

Incident

Allocate

Resources

Coordinate

Resources

Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
44

Summary


UML provides a wide variety of notations for representing
many aspects of software development


Powerful, but complex language


Can be misused to generate unreadable models


Can be misunderstood when using too many exotic features



We concentrate only on a few notations:


Functional model: use case diagram


Object model: class diagram


Dynamic model: sequence diagrams, state chart and activity
diagrams


Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
45

Use
Case
Diagram for Simple Watch

WatchUser

WatchRepairPerson

ReadTime

SetTime

ChangeBattery

Actor

Use case

Package

SimpleWatch

Functionality of the system from
user
’s point of view

Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
46

Class Diagrams for Simple Watch

Battery

load()

1

2

Time

now()

PushButton

state

push()

release()

1

1

1

1

1

2

blinkIdx

blinkSeconds()

blinkMinutes()

blinkHours()

stopBlinking()

referesh()

LCDDisplay

SimpleWatch

Class

Association

Multiplicity

Attributes

Operations

The
structure

of the system

Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
47

Interaction Diagrams for Simple Watch

Object

Message

Activation

The
system behavior

as interactions

blinkHours()

blinkMinutes()

incrementMinutes()

refresh()

commitNewTime()

stopBlinking()

pressButton1()

pressButton2()

pressButtons1And2()

pressButton1()

:WatchUser

:Time

:LCDDisplay

:SimpleWatch

time

Winter 2009, Maheswaran

Introduction to Software Engineering


ECSE321


Unit 4


Modeling in UML /
48

button1&2Pressed

button1&2Pressed

button1Pressed

button2Pressed

button2Pressed

button2Pressed

button1Pressed

button1&2Pressed

Increment

Minutes

Increment

Hours

Blink

Hours

Blink

Seconds

Blink

Minutes

Increment

Seconds

Stop

Blinking

Statechart

for
SimpleWatch

State

Initial state

Final state

Transition

Event