Course website:
Download
1 / 132

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


  • 151 Views
  • Uploaded on

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 .

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Course website: http://www.cs.sjtu.edu.cn/~shengbin/course/SE/sesite/home.html' - wauna


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




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







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


Uml is for visual modeling
UML based on the work of many different authors.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 based on the work of many different authors.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
A based on the work of many different authors.rchitecture & 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 based on the work of many different authors.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 based on the work of many different authors.

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 based on the work of many different authors.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 based on the work of many different authors.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 based on the work of many different authors.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) based on the work of many different authors.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 based on the work of many different authors.

Dependency

Association

Generalization

Realization


Dependency
Dependency based on the work of many different authors.

  • 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 based on the work of many different authors.

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 based on the work of many different authors.

  • 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 based on the work of many different authors.

  • state structure,

  • use case,

  • interaction,

  • statechart,

  • activity, and

  • implementation diagrams.


Class diagrams
Class diagrams based on the work of many different authors.

  • 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 based on the work of many different authors.

  • 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 based on the work of many different authors.

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 based on the work of many different authors.

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 based on the work of many different authors.

  • 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 based on the work of many different authors.

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 based on the work of many different authors.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 based on the work of many different authors.

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 based on the work of many different authors.

Company

*

*

tickerSymbol

StockExchange


Association classes
Association based on the work of many different authors.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 based on the work of many different authors.


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

  • Guidelines based on the work of many different authors.

    • 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 based on the work of many different authors.

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

* based on the work of many different authors.

Lists

*

Company

StockExchange

Qualification: Another Example

Company

*

*

Lists

tickerSymbol

StockExchange

1

tickerSymbol


Aggregation

Exhaust System based on the work of many different authors.

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 based on the work of many different authors.

3

ZoneButton

Composition

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


Generalization

Button based on the work of many different authors.

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: based on the work of many different authors.

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 based on the work of many different authors.

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 based on the work of many different authors.

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 based on the work of many different authors.

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 based on the work of many different authors.

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 based on the work of many different authors.

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 based on the work of many different authors.

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 based on the work of many different authors.

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 based on the work of many different authors.

*

*

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 based on the work of many different authors.

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 based on the work of many different authors.


Class design with state and behavior features
Class design with state and behavior features based on the work of many different authors.


Design class diagram
Design class diagram based on the work of many different authors.


Design class diagram1
Design class diagram based on the work of many different authors.


Use case diagrams
Use case diagrams based on the work of many different authors.

  • 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 based on the work of many different authors.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 based on the work of many different authors.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 based on the work of many different authors.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 based on the work of many different authors.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
C based on the work of many different authors.ommunication Relationships

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


Use case description
Use Case Description based on the work of many different authors.

  • 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: based on the work of many different authors. 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 based on the work of many different authors.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>> based on the work of many different authors. 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>> based on the work of many different authors. 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 based on the work of many different authors.

  • Different abstraction levels

Authenticate

WithPassword

Authenticate

Authenticate

WithCard


Modeling elements of use case diagram
Modeling elements of use case diagram based on the work of many different authors.


Use case diagram
Use case diagram based on the work of many different authors.


4 3 interaction diagram
4.3 Interaction Diagram based on the work of many different authors.

  • 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 based on the work of many different authors.

  • 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 based on the work of many different authors.

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 based on the work of many different authors.

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 based on the work of many different authors.

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 based on the work of many different authors.

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 based on the work of many different authors.


Sequence diagram
Sequence diagram based on the work of many different authors.


Collaboration communication diagram
Collaboration (communication) diagram based on the work of many different authors.


Collaboration diagram
Collaboration Diagram based on the work of many different authors.

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 based on the work of many different authors.

  • A Link is a connection between two instances


Illustrating messages

msg1() based on the work of many different authors.

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 based on the work of many different authors.

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


Illustrating a return value
Illustrating a Return Value based on the work of many different authors.

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


Illustrating messages to self or this
illustrating based on the work of many different authors.Messages to “self” or “this”


Illustrating iteration
Illustrating based on the work of many different authors.Iteration

  • Following the sequence number with a star (*)


Illustrating iteration clause
Illustrating Iteration Clause based on the work of many different authors.


Illustrating creation of instances
Illustrating Creation of Instances based on the work of many different authors.

  • create message sent to the instance being created


Illustrating message number sequencing
Illustrating Message Number Sequencing based on the work of many different authors.

  • 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 based on the work of many different authors.

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 based on the work of many different authors.

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 based on the work of many different authors.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 based on the work of many different authors.

  • 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 based on the work of many different authors.

  • 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 based on the work of many different authors.

initial state

off hook

state

Idle

Active

on hook

transition

event


Internal transitions associated with the settime state

pressBothButtons based on the work of many different authors.

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 based on the work of many different authors.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 based on the work of many different authors.


Activity diagrams
Activity diagrams based on the work of many different authors.

  • 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 based on the work of many different authors.

  • 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 based on the work of many different authors.


Activity diagram modeling decisions
Activity Diagram: Modeling Decisions based on the work of many different authors.


Activity diagrams modeling concurrency

Allocate based on the work of many different authors.

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 based on the work of many different authors.

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. based on the work of many different authors.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 based on the work of many different authors.

  • 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 based on the work of many different authors.

  • “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 based on the work of many different authors.


Deployment diagram
Deployment diagram based on the work of many different authors.


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

FieldStation based on the work of many different authors.

DispatcherStation

Dispatcher

FieldOfficer

EmergencyReport

Incident


An example of a note notes can be attached to a specific element in a diagram
An based on the work of many different authors.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 based on the work of many different authors.

  • 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 based on the work of many different authors.of stereotypes.

«entity»

«control»

«boundary»

Year

ChangeDateControl

ButtonBoundary

«entity»

«entity»

«boundary»

Month

Day

LCDDisplayBoundary


E xample of constraint
E based on the work of many different authors.xample of constraint.

reports

1

EmergencyReport

Incident

1..*

{ordered by time of receipt}


Summary1
Summary based on the work of many different authors.

  • 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

Thanks based on the work of many different authors.shengbin@cs.sjtu.edu.cn