Course website:
This presentation is the property of its rightful owner.
Sponsored Links
1 / 132

Course website: http://www.cs.sjtu.edu.cn/~shengbin/course/SE/sesite/home.html PowerPoint PPT Presentation


  • 72 Views
  • Uploaded on
  • Presentation posted in: General

Course website: http://www.cs.sjtu.edu.cn/~shengbin/course/SE/sesite/home.html. Waterfall lifecycle with feedback. Waterfall with feedback, overlaps, and prototypes . Iterative lifecycle with increments .

Download Presentation

Course website: http://www.cs.sjtu.edu.cn/~shengbin/course/SE/sesite/home.html

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Course website http www cs sjtu edu cn shengbin course se sesite home html

  • Course website:

  • http://www.cs.sjtu.edu.cn/~shengbin/course/SE/sesite/home.html


Waterfall lifecycle with feedback

Waterfall lifecycle with feedback


Waterfall with feedback overlaps and prototypes

Waterfall with feedback, overlaps, and prototypes


Iterative lifecycle with increments

Iterative lifecycle with increments

  • Iteration in software development is a repetition of some process with an objective to enrich the software product

  • Iterative lifecycle assumes increments – an improved or extended version of the product at the end of each iteration

  • Iterative lifecycle assumes builds – executable code that is a deliverable of an iteration.

  • Iterative lifecycle assumes short iterations between increments, in weeks or days, not months.

  • Models:

    • spiral

    • IBM Rational Unified Process (RUP)

    • Model Driven Architecture (MDA)

    • Agile lifecycle with short cycles


Iterative lifecycle with increments1

Iterative lifecycle with increments


Spiral model

Spiral model


Rational unified process rup

Rational Unified Process (RUP)


Model driven architecture mda

Model Driven Architecture (MDA)


Agile lifecycle with short cycles

Agile lifecycle with short cycles


13 xp practices

13 XP practices

  • whole team (no barriers between all stakeholders)

  • metaphor (common language; “desktop metaphor”)

  • the planning game (user stories)

  • simple design

  • small releases (two-week iterations)

  • customer tests (acceptance tests)

  • pair programming

  • test-driven development (automated test first)

  • design improvement (refactoring)

  • collective code ownership

  • continuous integration (builds many times per day)

  • sustainable pace (no overtime)

  • coding standards


Summary

Summary

  • Software engineering is concerned with development of large software systems.

  • The stages of software development process are referred to as software lifecycle phases.

  • Software process is part of a business process.

  • The immaterial and changeable nature of software are but two factors that make software engineering different from traditional engineering.

  • Software engineering is more than programming.

  • Software engineering is about modeling.

  • The lifecycle phases are requirements analysis, system design, implementation, integration and deployment, and operation and maintenance.

  • The lifecycle models are broadly divided into the waterfall models with feedback and the iterative models with increments.

  • Waterfall models are not suitable for modern software production.

  • There are four main representatives of iterative models: spiral, Rational Unified Process (RUP), Model Driven Architecture (MDA), and the agile model.


2 software modeling language

2. Software Modeling Language


Topics

Topics

  • Structured modeling language

    • Data flow modeling

    • Entity-relationship modeling

  • Object-oriented modeling language

    • Class diagrams

    • Use case diagrams

    • Interaction diagrams

    • Statechart diagrams

    • Activity diagrams

    • Implementation diagrams


The theme

The theme

  • Software engineering is about modeling

    • the outcome of software engineering – a program – is an executable model

  • Software modeling requires a language as a means of:

    • communicating between stakeholders

    • expressing development processes and artifacts at multiple levels of abstraction

  • The Unified Modeling Language (UML)

  • UML profiles to cater for specific domains and technologies

  • Model consists of one or more diagrams and any additional information stored in the project repository


Structured modeling language

Structured modeling language

  • Structured programming

    • without goto statements,

    • loops and if statements as the main control constructs,

    • top-down approach to program design

  • Structured programming  structured modeling (structured analysis and design)

    • expresses the monolithic and procedural character of Cobol-style systems of the past

    • functional decomposition - top-down function-oriented approach to software development

    • visualization techniques

      • Data Flow Diagrams (DFDs)

      • Entity-Relationship Diagrams (ERDs)

      • structure charts


Data flow diagrams dfds

Data Flow Diagrams (DFDs)

  • One of the most popular modeling technique in the history of SE

  • Mismatch with the object-oriented approach

  • The cornerstone of DFDs is functional decomposition


Context diagram

Context diagram

  • Consists of:

    • one process only

    • a number of external entities

    • in- and out-flows between the process and external entities

  • Determines the place of the system with regard to its environment


Level 0 diagram

Level “0” diagram

  • Called also the overview diagram


Level 1 diagram

Level “1” diagram

  • Flow balancing

  • Data store


Entity relationship er modeling

Entity-Relationship (ER) modeling

  • A data modeling technique

  • Entity-Relationship Diagrams (ERDs) define just three modeling elements – entities, relationships, and attributes

  • An entity is a conceptual data structure, which represents a business fact or rule and which can be distinctly identified (usually)

  • A relationship represents an association between entity instances from different entity sets and, in some important cases, from a single entity set

  • An attribute is a data-value pair

    • single-valued

    • multi-valued attributes and composite attributes not normally supported


Er crow s foot notation

ER crow’s foot notation

  • Attributes in entities

    • name, identifier indication, type, mandatory indication

  • Multiplicity of relationships

    • mandatory vs optional participation


Object oriented methods

Object-oriented Methods

  • Object-oriented Analysis & Design (OOAD) – Grady Booch

  • The Object Modeling Technique (OMT) – Jim Rumbaugh

  • The Object-oriented Software Engineering method (OOSE) – Ivar Jacobson

  • Each one had its strengths and weaknesses.


Object oriented modeling language

Object-oriented modeling language

  • The Unified Modeling Language (UML) “…is a language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems.“ (UML, 2003b, p.1-1)

  • In the UML, visual modeling is an arrangement of so-called classifiers

    • A classifier is a model element that describes the system’s behavior or structure and that normally has a visual representation

      • Examples of classifiers include class, actor, use case, relationship

  • In a working system, classifiers manifest as objects

    • An object is a piece of software that has

      • state - defined by its attribute values

      • behavior - defined by services (operations) that an object can perform

      • identity – to differentiate between objects (even with the same state and behavior)


Course website http www cs sjtu edu cn shengbin course se sesite home html

UML

  • In 1996 the Unified Modeling Language was introduced as UML 0.9 and then 0.91

  • Input was obtained from many, including TI, IBM, Microsoft, Oracle, and HP.

  • This led to UML 1.0 in 1997

  • Eventually, the semantics and flexibility was improved resulting in UML 2.0 in 2003


What is uml

What is UML?

  • UML (Unified Modeling Language)

    • An emerging standard for modeling object-oriented software.

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

      • OMT (James Rumbaugh)

      • OOSE (Ivar Jacobson)

      • Booch (Grady Booch)

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

  • Supported by several CASE tools

    • Rational ROSE

    • Together/J

    • ...


Course website http www cs sjtu edu cn shengbin course se sesite home html

  • Since its publication in 1991, the UML has been enhanced based on the work of many different authors.


Uml is for visual modeling

UML is for Visual Modeling

A picture is worth a thousand words!

Uses standard graphical notations

Semi-formal

Captures Business Process from enterprise information systems to distributed Web-based applications and even to hard real time embedded systems

Sales Representative

Places Order

Customer

Fulfill Order

Item

via

Ships the Item

Business Process


Uml is also for

UML is also for …

Specifying

  • Building models that are: Precise, Unambiguous, Complete

  • UML symbols are based on well-defined syntax and semantics.

  • UML addresses the specification of all important analysis, design, and implementation decisions.

Constructing

  • Models are related to OO programming languages.

  • Round-trip engineering requires tool and human intervention to avoid information loss

    • Forward engineering— direct mapping of a UML model into code.

    • Reverse engineering— reconstruction of a UML model from an implementation.

Documenting

  • Architecture, Requirements, Tests, Activities (Project planning, Release management)


A rchitecture view

Architecture & View

UML is for visualizing, specifying, constructing, and documenting with emphasis on system architectures (things in the system and relationships among the things) from five different views

Architecture -A set of significant decisions

Design View

Implementation View

vocabulary

functionality

system assembly

configuration mgmt.

Use Case View

behavior

Process View

Deployment View

system topology

distribution

delivery

installation

performance

scalability

throughput


Three basic building blocks of uml

Three basic building blocks of UML

  • Things

    • important modeling concepts (individual ones as the primitive kinds)

  • Relationships

    • tying individual things (i.e., their concepts)

  • Diagrams

    • grouping interrelated collections of things and relationships

UML=Things+Relationships+Diagrams


Course website http www cs sjtu edu cn shengbin course se sesite home html

Things

Structural — nouns of UML models.

Behavioral — dynamic (verbal) parts of UML models.

Grouping — organizational parts of UML models.

Annotational — explanatory parts of UML models.

Things=Structural+Behavioral+Grouping+Annotational


Course website http www cs sjtu edu cn shengbin course se sesite home html

(1) Structural Things in UML

Nouns of UML models.

Conceptual or physical elements.

Active Class

Class

Collaboration

Event Mgr

thread

time

suspend( )

flush( )

stop( )

Window

origin

size

open( )

close( )

move( )

Node

Chain of

Responsibility

WebServer

Place

Order

listbox

IWindow

Interface

Component

Use Case


2 behavioral things in uml

(2) Behavioral Things in UML

Verbs of UML models.

Dynamic parts of UML models: “behavior over time and space”

Usually connected to structural things in UML.

Two primary kinds of behavioral things:

Interaction

behavior of a set of objects comprising of a set of message exchanges within a particular context to accomplish a specific purpose.

display

State Machine

behavior that specifies the sequences of states an object or an interaction goes through during its lifetime in response to events, together with its responses to those events.

Idle

Waiting


3 grouping things in uml

(3) Grouping Things in UML

Packages - one primary kind of grouping.

- General purpose mechanism for organizing elements into groups.

- Purely conceptual; only exists at development time.

- Contains behavioral and structural things.

- Can be nested.

- Variations of packages are: Frameworks, models, & subsystems.

Meeting Scheduler


4 annotational things in uml

(4) AnnotationalThings in UML

Explanatory parts of UML models

Comments regarding other UML elements (usually called adornments in UML)

Noteis one primary annotational thing in UML

best expressed in informal or formal text.

flexible

drop-out dates


Relationships

Relationships

Dependency

Association

Generalization

Realization


Dependency

Dependency

  • A semantic relationship between two things in which a change to one thing (independent) may affect the semantics of the other thing (dependent).

Directed is optional and label is optional.


Associations

Associations

A structural relationship that describes a set of links, a link being a connection between objects.

Can bedirected labelsCan havemultiplicity & role names

employee

employer

0..1

*

Aggregation

a special kind of association. It represents a structural relationship between the whole and its parts.

Represented by a black diamond.


Realization

Realization

  • Asemantic relationship between two elements, wherein one element guarantees to carry out what is expected by the other element.

Where?

Between interfaces and classes that realize them…

Between use cases and the collaborations that realize them...


Six kinds of diagrams

Six kinds of diagrams

  • state structure,

  • use case,

  • interaction,

  • statechart,

  • activity, and

  • implementation diagrams.


Class diagrams

Class diagrams

  • Class diagram:

    • expresses static structures of models, called also state models

    • visualizes classes (and interfaces), their internal structure, and their relationships to other classes

  • “a classis the descriptor for a set of objects with similar structure, behavior, and relationships.” (UML, 2003b, p.3-35)

  • Attribute is a structural (typed) feature of a class

    • attribute  data member, member variable, instance variable, field

  • Operation is a behavioral feature of a class

    • operation  member function, method


Class diagrams1

Class Diagrams

  • Class diagrams represent the structure of the system.

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

TariffSchedule

Trip

Enumeration getZones()

Price getPrice(Zone)

zone:Zone

price:Price

*

*


Classes

TariffSchedule

Table zone2price

Enumeration getZones()

Price getPrice(Zone)

TariffSchedule

zone2price

getZones()

getPrice()

TariffSchedule

Classes

Name

Signature

Attributes

Operations

  • A class represent a concept.

  • A class encapsulates state (attributes) and behavior (operations).

  • Each attribute has a type.

  • Each operation has a signature.

  • The class name is the only mandatory information.


Instances

Instances

tariff_1974:TarifSchedule

zone2price = {

{‘1’, .20},{‘2’, .40},

{‘3’, .60}}

  • An instance 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.


Actor vs instances

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 (“Pilot”)

  • Class:

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

  • Object:

    • A specific instance of a class (“Joe, the inspector”).


Associations1

TripLeg

pricezone

Associations

TarifSchedule

Enumeration getZones()

Price getPrice(Zone)

*

*

  • Associations denote relationships between classes.

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


The direction of association

The Direction of Association

  • Association can be directional or bidirectional

  • Given an order, we can find a specific customer while the order can not be indicated by a customer

Order

*

1

Customer


1 to 1 and 1 to many associations

Country

City

1

1

Has-capital

name:String

name:String

Point

x:Integer

y:Integer

Polygon

1

*

draw()

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

1-to-1 association

1-to-many association


Many to many associations

Many-to-Many Associations

Company

*

*

tickerSymbol

StockExchange


Association classes

Association Classes

  • Example

    • Authorization services assign a merchant ID to each store for identification during communications

    • A payment authorization request from the store to an authorization service needs the merchant ID that identifies the store to the service

    • Furthermore, a store has a different merchant ID for each service

Store

AuthorizationService

both placements of

merchantID are incorrect

address

address

because there may be more

merchantID

merchantID

than one merchantID

name

name

phoneNumber


Class diagram as static structure diagram

Class diagram as static structure diagram


Course website http www cs sjtu edu cn shengbin course se sesite home html

  • Guidelines

    • An attribute is related to an association

    • Instances of the association class have a life-time dependency on the association

    • There is a many-to-many association between two concepts, and information associated with the association itself


4 qualifiers

Without qualification

File

Directory

1

*

filename

1

Directory

filename

File

(4) Qualifiers

With qualification

0..1

  • Qualifiers can be used to reduce the multiplicity of an association


Qualification another example

*

Lists

*

Company

StockExchange

Qualification: Another Example

Company

*

*

Lists

tickerSymbol

StockExchange

1

tickerSymbol


Aggregation

Exhaust System

Tailpipe

Muffler

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

0..2


Composition

TicketMachine

3

ZoneButton

Composition

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


Generalization

Button

CancelButton

ZoneButton

Generalization

  • Generalization relationships denote inheritance between classes.

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

  • Generalization simplifies the model by eliminating redundancy.


From problem statement to associations

Class Diagram:

Company

*

*

StockExchange

Lists

tickerSymbol

From Problem Statement To Associations

Problem Statement: A stock exchange lists many companies. Each company is uniquely identified by a ticker symbol


From problem statement to code

StockExchange

Company

*

*

tickerSymbol

From Problem Statement to Code

Problem Statement

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

Class Diagram

lists

Java Code

public class StockExchange {

public Vector m_Company = new Vector();

};

public class Company {

public int m_tickerSymbol;

public Vector m_StockExchange = new Vector();

};


Inheritance

CancelButton

ZoneButton

Button

Inheritance

  • Inheritance is another special case of an association denoting a “kind-of” hierarchy

  • Inheritance simplifies the analysis model by introducing a taxonomy

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


Packages

Account

Bank

Customer

Packages

  • Packages help you to organize UML models to increase their readability

  • We can use the UML package mechanism to organize classes into subsystems

  • Any complex system can be decomposed into subsystems, where each subsystem is modeled as a package.


Class modeling in practice

Foo

Amount

CustomerId

Deposit()

Withdraw()

GetBalance()

Class Modeling in Practice

Class Identification: Name of Class, Attributes and Methods

Is Foo the right name?


Naming the class

Account

Foo

“Dada”

Amount

Amount

Amount

CustomerId

CustomerId

CustomerId

Deposit()

Deposit()

Deposit()

Withdraw()

Withdraw()

Withdraw()

GetBalance()

GetBalance()

GetBalance()

Naming the class

Is Foo the right name?


Finding more classes

Account

Amount

Customer

Bank

Name

Name

AccountId

Deposit()

Withdraw()

GetBalance()

Finding More classes

CustomerId

CustomerId

1) Find New Classes

2) Review Names, Attributes and Methods


Finding associations

Account

Amount

Bank

Customer

CustomerId

Name

Name

AccountId

Deposit()

AccountId

CustomerId

Withdraw()

GetBalance()

Finding Associations

*

?

*

has

?

?

1) Find New Classes

2) Review Names, Attributes and Methods

3) Find Associations between Classes

4) Label the generic associations

5) Determine the multiplicity of the associations

6) Review associations


Find taxonomies

Account

*

*

Has

Amount

Bank

Customer

CustomerId

Name

Name

AccountId

Deposit()

AccountId

CustomerId()

Withdraw()

GetBalance()

Savings

Account

Checking

Account

Mortgage

Account

Withdraw()

Withdraw()

Withdraw()

Find Taxonomies


Simplify organize

Account

Amount

CustomerId

AccountId

Deposit()

AccountId

Withdraw()

GetBalance()

Simplify, Organize

Show Taxonomies

separately

Savings

Account

Checking

Account

Mortgage

Account

Withdraw()

Withdraw()

Withdraw()


Modeling elements of class diagram

Modeling elements of class diagram


Class design with state and behavior features

Class design with state and behavior features


Design class diagram

Design class diagram


Design class diagram1

Design class diagram


Use case diagrams

Use case diagrams

  • The main analysis-level behavior modeling technique in UML

  • The power of use case diagrams does not rest in …graphical diagrams. The real power of use case diagrams is in textual specifications of use cases stored in the repository.

  • Use case represents a major piece of system functionality.

  • Actor is a role that somebody or something plays with regard to a use case.

    • Actor communicates with a use case (via «communicate» relationship) and expects from it some feedback – a value or observable result.


Use case diagrams1

An Actor represents a role, that is, a type of user of the system

Passenger

PurchaseTicket

Use Case Diagrams

Used during requirements elicitation and analysis to represent external behavior (“visible from the outside of the system”)

A use case represents a class of functionality provided by the system

Use case model:

The set of all use cases that completely describe the functionality of the system.


Use case diagrams2

Use Case Diagrams

Package

SimpleWatch

Actor

ReadTime

SetTime

WatchUser

WatchRepairPerson

Use case

ChangeBattery

Use case diagrams represent the functionality of the system

from user’s point of view


Actors

An actor is a model for an external entity which interacts (communicates) with the system:

User

External system (Another system)

Physical environment (e.g. Weather)

An actor has a unique name and an optional description

Examples:

Passenger: A person in the train

GPS satellite: An external system that provides the system with GPS coordinates.

Passenger

Actors

Optional

Description

Name


Use case

• A use case represents a class of functionality provided by the system

• Use cases can be described textually, with a focus on the event flow between actor and system

• The textual use case description consists of 6 parts:

Unique name

Participating actors

Entry conditions

Exit conditions

Flow of events

Special requirements.

PurchaseTicket

Use Case


C ommunication relationships

Communication Relationships

  • Actors and use cases communicate when information is exchanged between them


Use case description

Use Case Description

  • Brief use case -- consists of a few sentences summarizing the use case

  • Casual use case -- consists of a few paragraphs of text, summarizing the use case.

  • Fully dressed use case -- a formal document based on a detailed template with fields for various sections; and it is the most common understanding of the meaning of a use case.


Textual use case description example

1. Name: Purchase ticket

2. Participating actor: Passenger

3. Entry condition:

Passenger stands in front of ticket distributor

Passenger has sufficient money to purchase ticket

4. Exit condition:

Passenger has ticket

5. Flow of events:

1. Passenger selects the number of zones to be traveled

2. Ticket Distributor displays the amount due

3. Passenger inserts money, at least the amount due

4. Ticket Distributor returns change

5. Ticket Distributor issues ticket

6. Special requirements: None.

Passenger

PurchaseTicket

Textual Use Case Description Example


Uses cases can be related

Uses Cases can be related

  • Extends Relationship

    • To represent seldom invoked use cases or exceptional functionality

  • Includes Relationship

    • To represent functional behavior common to more than one use case.

  • Inheritance Relationship

    • One use case can specialize another more general one by adding more detail


The extends relationship

<<extends>> relationships model exceptional or seldom invoked cases

The exceptional event flows are factored out of the main event flow for clarity

The direction of an <<extends>> relationship is to the extended use case

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

Passenger

PurchaseTicket

<<extends>>

OutOfOrder

TimeOut

<<extends>>

<<extends>>

<<extends>>

Cancel

NoChange

The <<extends>>Relationship


The includes relationship

<<includes>> relationship represents common functionality needed in more than one use case

<<includes>> behavior is factored out for reuse, not because it is an exception

The direction of a <<includes>> relationship is to the using use case (unlike the direction of the <<extends>> relationship).

Passenger

PurchaseMultiCard

PurchaseSingleTicket

<<includes>>

<<includes>>

NoChange

Cancel

Cancel

CollectMoney

<<extends>>

<<extends>>

<<extends>>

The <<includes>> Relationship


The inheritance relationships

The Inheritance relationships

  • Different abstraction levels

Authenticate

WithPassword

Authenticate

Authenticate

WithCard


Modeling elements of use case diagram

Modeling elements of use case diagram


Use case diagram

Use case diagram


4 3 interaction diagram

4.3 Interaction Diagram

  • Sequence diagram

    • Emphasizes time ordering of messages.

    • Depicts the lifeline of objects.

    • Sequence diagram illustrates interactions in a kind of fence(栅栏) format

  • Collaboration diagram

    • Emphasizes structural organization.

    • Potentially easier to model complex interactions.

    • Collaboration Diagram illustrates object interactions in a graph or network format

sequence number

1.1 : getLastCheckpoint( )

1 : getPositionAtTime( t )

t : AirTrafficPlanner

p : FlightPlan

message

link

object


Sequence diagrams

Sequence diagrams

  • The first kind of interaction diagrams

  • The second are collaboration diagrams

  • Interaction diagrams are the main design-level behavior modeling technique in UML

  • Sequence diagram is a graphical visualization of sequences of messages between objects

    • placing messages one under another shows this

    • optional numbering of messages also indicates the sequence.

  • Object receiving a message activates the relevant method.

  • The time when the flow of control is focused in an object is called activation

    • shown as narrow rectangle on object lifeline.


Sequence diagrams1

Used during analysis

To refine use case descriptions

to find additional objects (“participating objects”)

Used during system design

to refine subsystem interfaces

Instances are represented by rectangles. Actors by sticky figures

Lifelines are represented by dashed lines

Messages are represented by arrows

Activations are represented by narrow rectangles.

TicketMachine

Passenger

selectZone()

insertCoins()

TicketMachine

pickupChange()

zone2price

selectZone()

insertCoins()

pickupChange()

pickUpTicket()

pickUpTicket()

Sequence Diagrams

Focus on

Controlflow

Messages ->

Operations on

participating Object


Sequence diagrams can also model the flow of data

ZoneButton

TarifSchedule

Display

Passenger

selectZone()

lookupPrice(selection)

price

displayPrice(price)

Sequence Diagrams can also model the Flow of Data

Dataflow

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

  • Horizontal dashed arrows indicate data flow, for example return results from a message

…continued on next slide...


Sequence diagrams iteration condition

CoinIdentifier

Display

CoinDrop

Passenger

insertChange(coin)

lookupCoin(coin)

price

displayPrice(owedAmount)

[owedAmount<0] returnChange(-owedAmount)

Sequence Diagrams: Iteration & Condition

…continued from previous slide...

ChangeProcessor

*

Iteration

  • Iteration is denoted by a * preceding the message name

  • Condition is denoted by boolean expression in [ ] before the message name

Condition

…continued on next slide...


Creation and destruction

Passenger

createTicket(selection)

Ticket

print()

free()

Creation and destruction

…continued from previous slide...

Creation of Ticket

ChangeProcessor

Destruction of Ticket

  • Creation is denoted by a message arrow pointing to the object

  • Destruction is denoted by an X mark at the end of the destruction activation

    • In garbage collection environments, destruction can be used to denote the end of the useful life of an object.


Messages in sequence diagram

Messages in sequence diagram


Sequence diagram

Sequence diagram


Collaboration communication diagram

Collaboration (communication) diagram


Collaboration diagram

Collaboration Diagram

Object

: Order

Fulfillment

5: acknowledgeOrder

4: triggerBill

: Order Clerk

3: placeOrder

1: submitOrder

: Billing

Agent

Link

Link is a semantic connection

among objects… an instance

of an association

2: processCard

: Order

: CreditCard

Taker

Agen

Message

Message is a specification of a communication between objects

that conveys information with the expectation that activity will occur.


Illustrating links

Illustrating Links

  • A Link is a connection between two instances


Illustrating messages

msg1()

1: msg2()

2: msg3()

3: msg4()

: Register

:Sale

3.1: msg5()

all messages flow on the same link

Illustrating Messages

  • Messages between objects are represented via a labeled arrow on a link line


Illustrating parameters

Illustrating Parameters

  • Parameters of a message may be shown within parentheses following the message name


Illustrating a return value

Illustrating a Return Value

  • A return value variable name and an assignment operator := preceding the message


Illustrating messages to self or this

illustrating Messages to “self” or “this”


Illustrating iteration

Illustrating Iteration

  • Following the sequence number with a star (*)


Illustrating iteration clause

Illustrating Iteration Clause


Illustrating creation of instances

Illustrating Creation of Instances

  • create message sent to the instance being created


Illustrating message number sequencing

Illustrating Message Number Sequencing

  • The first message is not numbered

  • The order and nesting of subsequent messages is shown with a legal numbering scheme in which nested messages have appended to them a number.

    Nesting is denoted by prepending the incoming message

  • number to the outgoing message number.


Course website http www cs sjtu edu cn shengbin course se sesite home html

first

second

third

msg1()

1: msg2()

;ClassA

:ClassB

1.1: msg3()

2.1: msg5()

2: msg4()

:ClassC

fourth

fifth

2.2: msg6()

sixth

:ClassD


Mutually exclusive conditional paths

Mutually Exclusive Conditional Paths

unconditional after

either msg2 or msg4

1a and 1b are mutually

:ClassE

exclusive conditional paths

2: msg6()

1a [test1] : msg2()

msg1()

:ClassA

:ClassB

1b [not test1] : msg4()

1a.1: msg3()

1b.1: msg5()

:ClassD

:ClassC


Interaction diagram properties

Interaction Diagram Properties

  • UML interaction diagram represent behavior in terms of interactions

  • Useful to identify or find missing objects

  • Time consuming to build, but worth the investment

  • Complement the class diagrams (which represent structure).


State machine diagrams

State Machine Diagrams

  • A UML state machine is a notation for describing the sequence of states an object goes through in response to external events

  • State: it is a condition satisfied by the attributes of an object

    • A telephone is in the sate of being “idle”

  • Transition: it represents a change of state triggered by events, conditions, or time

    • Event “off hook”, “idle” to “active” state transition


Statechart diagrams

Statechart diagrams

  • Not specific to object-oriented modeling

  • Capture states of an object and actions that lead to state transitions on that object

  • Drawn for each class, which has interesting state changes worthy of modeling

  • State of an object (class instance) changes when the values of some of its attributes change

  • States have durations – they correspond to intervals of time between two transitions

    event-signature [guard-condition] /action-expression


Course website http www cs sjtu edu cn shengbin course se sesite home html

Telephone

initial state

off hook

state

Idle

Active

on hook

transition

event


Internal transitions associated with the settime state

pressBothButtons

MeasureTime

SetTime

do/count ticks

entry/blink hours

pressButton1/blink next number

pressButton2/increment current number

exit/stop blinking

after 2 min.

pressBothButtons/beep

after 20 years

after 20 years

DeadBattery

Internal transitions associated with the SetTime state.

2Bwatch Example


Refined statechart associated with the settime state

Refined statechart associated with the SetTime state.

SetTime

b1

b1

BlinkHours

BlinkMinutes

BlinkSeconds

b2/incr sec.

b2/incr hour

b2/incr min.

b1

b1

BlinkYear

BlinkMonth

BlinkDay

b2/incr year

b2/incr mo.

b2/incr day

b1

b1


Statechart diagram

Statechart diagram


Activity diagrams

Activity diagrams

  • Activity diagram is a state machine that represents a computation, i.e. the performance of actions, and such that the transitions are triggered by the completion of the actions

  • Typically, an activity diagram is attached to the implementation of an operation or a use case

  • Action states are computations that should not be interrupted by external events or have any outgoing transitions based on explicit events

  • Outgoing transitions from an action state are the result of completing the activity of that state


Activity diagrams1

Activity Diagrams

  • An activity diagram shows flow control within a system

  • An activity diagram is 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


Activity diagram

Activity diagram


Activity diagram modeling decisions

Activity Diagram: Modeling Decisions


Activity diagrams modeling concurrency

Allocate

Resources

Open

Coordinate

Archive

Incident

Resources

Incident

Document

Incident

Activity Diagrams: Modeling Concurrency

  • Synchronization of multiple activities

  • Splitting the flow of control into multiple threads

Splitting

Synchronization


Activity diagrams swimlanes

Dispatcher

Allocate

Resources

Open

Coordinate

Archive

Incident

Resources

Incident

FieldOfficer

Document

Incident

Activity Diagrams: Swimlanes

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


Activity diagram vs statechart diagram

Activity Diagram vs. Statechart Diagram

Statechart Diagram for Incident

Focus on the set of attributes of a single abstraction (object, system)

Event causes

state transition

Closed

Active

Inactive

Archived

Incident-

Documented

Incident-

Archived

Incident-

Handled

Activity Diagram for Incident

(Focus on dataflow in a system)

Triggerless

transition

Completion of activity

causes state transition


Implementation diagrams

Implementation diagrams

  • Models for physical implementation of the system

  • Show system components, their structure and dependencies and how they are deployed on computer nodes

  • Two kinds of diagrams:

    • component diagrams

    • deployment diagrams

  • Component diagrams show structure of components, including their interface and implementation dependencies

  • Deployment diagrams show the runtime deployment of the system on computer nodes


Component diagrams

Component diagrams

  • “A component diagram shows the dependencies among software components, including the classifiers that specify them (for example, implementation classes) and the artifacts that implement them; such as, source code files, binary code files, executable files, scripts.” (UML, 2003b, p.3-169)

  • “A component represents a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces.” (UML, 2003b, p.3-174)

  • Component implicitly exposes a set of interfaces, which represent services provided by elements residing on the component

  • Components may be connected to other components by physical containment (direct nesting of a component in its enclosing component)  «reside» relationship or «implement» relationship

  • Packages can be used in a component diagram to illustrate the grouping of the components


Component diagram

Component diagram


Deployment diagram

Deployment diagram


Course website http www cs sjtu edu cn shengbin course se sesite home html

FieldStation

DispatcherStation

Dispatcher

FieldOfficer

EmergencyReport

Incident


An example of a note notes can be attached to a specific element in a diagram

An example of a note. Notes can be attached to a specific element in a diagram.

FieldStation

DispatcherStation

Dispatcher

FieldOfficer

The Emer

gencyReport

class is defined in FieldStation

and used in both stations.

EmergencyReport

Incident


Diagram extensions

Diagram Extensions

  • UML provides a number of extension mechanisms enabling the modeler to extend the language

  • Stereotype: It allows developers to classify model elements in UML

  • Constraint: it is a rule that is attached to a UML model element restricting its semantics


Examples of stereotypes

Examples of stereotypes.

«entity»

«control»

«boundary»

Year

ChangeDateControl

ButtonBoundary

«entity»

«entity»

«boundary»

Month

Day

LCDDisplayBoundary


E xample of constraint

Example of constraint.

reports

1

EmergencyReport

Incident

1..*

{ordered by time of receipt}


Summary1

Summary

  • The Unified Modeling Language (UML) is the standard modeling language for modern object-oriented software systems.

  • The language for structured modeling includes Data Flow Diagrams (DFDs), Entity-Relationship Diagrams (ERDs), and structure charts.

  • The UML range of diagrams includes class diagrams, use case diagrams, interaction diagrams, statechart diagrams, activity diagrams, and implementation diagrams.

  • Object-oriented UML modeling is centered on class diagrams but is driven by use case diagrams.

  • Interaction diagrams are the main design-level behavior modeling technique in UML.

  • Statechart diagrams capture states of objects and actions that lead to state transitions on the objects.

  • Activity diagram is a state machine that represents a computation.

  • Implementation diagrams (component diagrams and deployment diagrams) are models for physical implementation of the system.


Thanks shengbin@cs sjtu edu cn

[email protected]


  • Login