ece 355 software engineering n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
ECE 355: Software Engineering PowerPoint Presentation
Download Presentation
ECE 355: Software Engineering

Loading in 2 Seconds...

play fullscreen
1 / 74

ECE 355: Software Engineering - PowerPoint PPT Presentation


  • 119 Views
  • Uploaded on

ECE 355: Software Engineering. CHAPTER 2 Unit 4 (Part 1). Presentation material based on past ECE 355 notes by Prof. K. Czarneszki. Course outline. Unit 1: Software Engineering Basics Unit 2: Process Models and Software Life Cycles Unit 3: Software Requirements

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 'ECE 355: Software Engineering' - dobry


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
ece 355 software engineering

ECE 355: Software Engineering

CHAPTER 2

Unit 4 (Part 1)

Presentation material based on past ECE 355 notes by Prof. K. Czarneszki.

course outline
Course outline
  • Unit 1: Software Engineering Basics
  • Unit 2: Process Models and Software Life Cycles
  • Unit 3: Software Requirements

 Unit 4: Unified Modeling Language (UML)

  • Unit 5: Design Basics and Software Architecture
  • Unit 6: OO Analysis and Design
  • Unit 7: Design Patterns
  • Unit 8: Testing and Reliability
  • Unit 9: Software Engineering Management and Economics
what does the system do in response to an event
What does the system do in response to an event?
  • In the traditional approach,
    • a system is viewed as a collection of processes,
    • processes interact with data elements, and
    • processes accept inputs and produce outputs.
  • In the OO approach,
    • a system is a collection of interacting objects,
    • objects interact with the outside world and with each other, and
    • objects send and respond to messages.
unified modeling language uml

Unified Modeling Language (UML)

Sources:

Largely based on a series of 3 UML Tutorials from OMG, see http://www.omg.org/uml/

UML Specification Document v1.4, see http://www.omg.org/uml/

“The Unified Modeling Language User Guide” by Grady Booch, James Rumbaugh, Ivar Jacobson (Addison-Wesley, 1999)

uml outline
UML - Outline
  • Introduction
  • Behavioral modeling
  • Structural modeling
what is uml
What is UML
  • A graphical language for
    • visualizing,
    • specifying,
    • constructing, and
    • documenting

the artifacts of distributed object systems.

  • It is not a OO method, but a OO modeling notation only
a brief history of uml
A brief history of UML
  • 1989-1994: 50+ OO methods
  • Clearly prominent methods
      • Jacobson’s OOSE: support for use cases to capture requirements
      • Booch: expressive during design/construction
      • Rumbaugh’s OMT: analysis+ data intensive systems
  • 1994: Rumbaugh joined Booch at Rational
  • 1995: Jacobson joined Rational
  • 1996: UML version 0.9
  • 1997: Standardized by OMG
    • UML 1.1…1.4 (2.0)
uml goals
UML Goals
  • Define an easy-to-learn but semantically rich visual modeling language
  • Unify the Booch, OMT, and Objectory modeling languages
  • Include ideas from other modeling languages
    • Data modeling (e.g., ERD)
    • Business modeling (e.g., workflow modeling)
    • ...
  • Incorporate industry best practices
  • Address contemporary software development issues
    • scale, distribution, concurrency, executability, etc.
  • Provide flexibility for applying different processes
  • Enable model interchange and define repository interfaces
unifying concepts
Unifying Concepts
  • classifier-instance dichotomy
    • e.g. an object is an instance of a class ORa class is the classifier of an object
  • specification-realization dichotomy
    • e.g. an interface is a specification of a class ORa class is a realization of an interface
  • analysis-time vs. design-time vs. run-time
    • modeling phases (“process creep”)
    • usage guidelines suggested, not enforced
conceptual model of uml
Conceptual model of UML

UML

Building

blocks

Common

mechanisms

Rules

name, scope, visibility

Diagrams

Things

Relations

Class

Object

Use case

Sequence

Collaboration

Statechart

Activity

Component

Deployment

Dependency

Association

Generalization

Realization

Structural

Behavioral

Grouping

Annotate

Class

Interface

Active class

Component

Node

Interaction

State machine

Package

Note

Use case

Collaboration

summary of diagram kinds in uml nine concrete kinds
Summary of diagram kinds in UML (nine concrete kinds)
  • Structural diagrams
    • Static structural diagrams
      • Class diagrams
      • Object diagrams
    • Implementation diagrams
      • Component diagrams
      • Deployment diagrams
  • Behavior diagrams
    • Use case diagrams
    • Interaction diagrams
      • Sequence diagrams
      • Collaboration diagrams
    • Statechart diagrams
    • Activity diagrams
what will be covered
What will be covered
  • Will learn some syntax, semantics, and modeling techniques
  • Further details of UML can be found in the supplementary text:
    • Bennet, Sketon, Lunn: UML, Schaum’s Outline Series, McGraw-Hill, 2001
    • “The Unified Modeling Language User Guide” by Grady Booch, James Rumbaugh, Ivar Jacobson (Addison-Wesley, 1999)
    • And in the UML Specification Document and other resources available from http://www.omg.org/uml/
uml outline1
UML - Outline
  • Introduction
  • Structural modeling
  • Behavioral modeling
    • Use case diagrams
    • Interaction diagrams
      • Sequence diagrams and collaboration diagrams
      • More about collaborations
    • State diagrams
    • Activity diagrams
use cases
Use Cases
  • Use-case model describes ways in which an application is to be used.
  • Requirements are often naturally expressed as an interaction between app and user.
  • A use case consists of an interaction between actors (user/external systems) and the application.
use case diagram tour
Use Case Diagram Tour
  • Shows use cases, actor and their relationships
  • Use case internals can be specified by text and/or interaction diagrams
  • Kinds
    • use case diagram
    • use case description
use case diagrams
Use case diagrams
  • Diagram of use cases, actors & relationships
  • Show outwardly visible services.
  • Uses (2 ways)
    • Model the context of a system.
      • Which actors interact with the system.
    • Model requirements of a system.
      • What the system should do.
use case diagram
Use Case Diagram

The same person

(or system) may

play the roles of

a number of actors

at the same time

Billing

System

Fig. 3-53, UML Notation Guide

use case relationships2
Use Case Relationships

<<extend>>

(set priority)

Place

rush order

Place order

Extension points

set priority

<<include>>

Check

password

Track order

<<include>>

Validate user

Retinal scan

use case model use case diagrams and descriptions

Use Case Model

Actors

Use Cases

...

Use-Case Descriptions

Use Case Model: Use Case Diagrams and Descriptions
  • Name
  • Brief description
  • Flows of Events
  • Preconditions
  • Postconditions
  • Interaction, activity and state diagrams
  • Relationships
  • Use-Case diagrams
  • Special requirements
  • Other diagrams
flow of events in a use case
Flow of events in a use case
  • Has one normal, basic flow (“Happy Path”)
  • Several alternative flows
    • Regular variants
    • Odd cases
    • Exceptional flows handling error situations

“Happy Path”

use case description change flight
Use Case Description: Change Flight
  • Actors: traveler, client account db, airline reservation system
  • Preconditions:
    • Traveler has logged on to the system and selected ‘change flight itinerary’ option
  • Basic course
    • System retrieves traveler’s account and flight itinerary from client account database
    • System asks traveler to select itinerary segment she wants to change; traveler selects itinerary segment.
    • System asks traveler for new departure and destination information; traveler provides information.
    • If flights are available then
    • System displays transaction summary.
  • Alternative courses
    • If no flights are available then …
when to model use cases
When to model use cases
  • Model user requirements with use cases.
  • Model test scenarios with use cases.
  • If you are using a use-case driven method
    • start with use cases and derive your structural and behavioral models from it.
  • If you are not using a use-case driven method
    • make sure that your use cases are consistent with your structural and behavioral models.
use case model drives the work from analysis through test

Use-Case Model

Design Model

Implementation Model

Test Model

Use case model drives the work from analysis through test

Verified by

Realized by

Implemented by

model requirements of a system
Model requirements of a system
  • Establish the context (actors).
  • Consider behavior expected by an actor.
  • Name the common behaviors as use cases.
  • Create use case descriptions.
  • Factor common behavior into new use cases
  • Model use cases, actors and their relationships in a use case diagram.
use case modeling tips
Use Case Modeling Tips
  • Make sure that each use case describes a significant chunk of system usage that is understandable by both domain experts and programmers
  • When defining use cases in text, use nouns and verbs accurately and consistently to help derive objects and messages for interaction diagrams
  • Factor out common usages that are required by multiple use cases
    • If the usage is required use <<include>>
    • If the base use case is complete and the usage may be optional, consider use <<extend>>
  • A use case diagram should
    • contain only use cases at the same level of abstraction
    • include only actors who are required
  • Large numbers of use cases should be organized into packages
using use cases
Using use-cases
  • First describe flow of events for a use case in text.
  • With refinement of your understanding, use interaction diagrams to specify these flows.
  • Use one diagram to specify the main flow.
  • Use variations of the main diagram to specify exceptional cases.
further reading
Further reading
  • Book “Writing Effective Use Cases” by Alistair Cockburn (Addison-Wesley, 2000)
  • For a use case description template and other materials see http://www.usecases.org/
uml outline2
UML - Outline
  • Introduction
  • Structural modeling
  • Behavioral modeling
    • Use case diagrams
    • Interaction diagrams
      • Sequence diagrams and collaboration diagrams
      • More about collaborations
    • State diagrams
    • Activity diagrams
  • Advanced modeling
what are interactions
What are interactions?
  • Interaction: describes a collection of communications between instances, including all ways to affect instances, like operation invocation, as well as creation and destruction of instances
  • The communications are partially ordered (in time)
interactions core elements
Interactions: Core Elements

Construct

Description

Syntax

Instance (object, data value, component instance etc.)

An entity with a unique identity and to which a set of operations can be applied (signals be sent) and which has a state that stores the effects of the operations (the signals).

name

attr values

Action

A specification of an executable statement.

A few different kinds of actions are predefined, e.g. CreateAction, CallAction, DestroyAction, and UninterpretedAction.

textual

interactions core elements cont d
Interactions: Core Elements (cont’d)

Construct

Description

Syntax

Stimulus

A communication between two instances.

Operation

A declaration of a service that can be requested from an instance to effect behavior.

textual

Signal

A specification of an asynchronous stimulus communicated between instances.

«Signal»Name

parameters

interaction core relationships
Interaction: Core Relationships

Construct

Description

Syntax

Link

A connection between instances.

Attribute Link

A named slot in an instance, which holds the value of an attribute.

textual

interaction diagram tour
Interaction diagram tour
  • Show interactions between instances in the model
    • graph of instances (possibly including links) and stimuli
    • existing instances
    • creation and deletion of instances
  • Kinds
    • sequence diagram (temporal focus)
    • collaboration diagram (structural focus)
interaction diagrams

Sequence Diagram

Collaboration Diagram

x

y

z

1.1: a1.2: c

x

y

a

b

1.1.1: b

c

z

Interaction diagrams
uml outline3
UML - Outline
  • Introduction
  • Structural modeling
  • Behavioral modeling
    • Use case diagrams
    • Interaction diagrams
      • Sequence diagrams and collaboration diagrams
      • More about collaborations
    • State diagrams
    • Activity diagrams
  • Advanced modeling
sequence diagram

object symbol

name : Class

other

lifeline

stimulus

name (…)

activation

new (…)

: Class

delete

return

create

Sequence diagram
arrow label

3.7 *[1..5]: move (5, 7)

iteration

sequence number

return value

message name

argument list

3.7 [ z > 0 ]: move (5, 7)

condition

Arrow label

predecessor sequence-expression return-value := message-name argument-list

move (5, 7)

Sequence numbering schema:

1 : actionA

1.1. firstSubactionOfActionA

1.2. secondSubactionOfActionA

1.3. thirdSubactionOfActionA

2 : actionB

2.1. firstSubactionOfActionB

2.1. secondSubactionOfActionB

...

3.7.4: move (5, 7)

3.1: res := getLocation (fig)

different kinds of arrows

Procedure call or other kind of nested (synchronous) flow of control (caller waits for the callee to return)

Asynchronous flow of control (no waiting, no nesting, caller returns immediately)

Return

Different kinds of arrows
example different arrows

Nested Flow

Asynchronous flow

Nested Flow

teller

: Order

: Article

teller

caller

exchange

: Order

: Article

callee

getValue

lift receiver

price

getValue

dial tone

price

dial digit

getName

dial digit

getName

ringing tone

ringing signal

lift receiver

Example: Different Arrows
condition recursion etc

value

[ x > 0]: getValue ()

getValue ()

iterate ()

Condition, recursion, etc.

calculator

filter

[ x < 0]: transform ()

collaboration diagram

object symbol

link symbol

standard stereotype

stimulus

window

: Controller

: Window

window «parameter»

standard stereotype

1: displayPositions (window)

standard constraint

1.1.3.1 add (self)

wire

contents {new}

1.1 *[i := 1..n]: drawSegment (i)

{new}: Line

«local» line

wire :Wire

1.1.2: create (r0, r1)1.1.3: display (window)

standard stereotype

«self»

standard constraint

1.1.1a: r0 := position ()

1.1.1b: r1 := position ()

left : Bead

right : Bead

Collaboration diagram

redisplay ()

when to model interactions
When to Model Interactions
  • To specify how the instances are to interact with each other.
  • To identify the interfaces of the classifiers.
  • To distribute the requirements.
interaction modeling tips
Interaction modeling tips
  • Set the context for the interaction.
  • Include only those features of the instances that are relevant.
  • Express the flow from left to right and from top to bottom.
  • Put active instances to the left/top and passive ones to the right/bottom.
  • Use sequence diagrams
    • to show the explicit ordering between the stimuli
    • when modeling real-time
  • Use collaboration diagrams
    • when structure is important
    • to concentrate on the effects on the instances
use case description change flt itinerary
Use Case Description: Change Flt Itinerary
  • Actors: traveler, client account db, airline reservation system
  • Preconditions: Traveler has logged in
  • Basic course:
    • Traveler selects ‘change flight itinerary’ option
    • System retrieves traveler’s account and flight itinerary from client account database
    • System asks traveler to select itinerary segment she wants to change; traveler selects itinerary segment.
    • System asks traveler for new departure and destination information; traveler provides information.
    • If flights are available then …
    • System displays transaction summary.
  • Alternative course:
    • If no flights are available then…
sequence diagram change flight itinerary

Traveler

Client Account DBMS

Client Account DBMS

Airline Reservation System

: Booking System

change flight itinerary

get customer account

select segment

update information

present itinerary

present detailed info

get itinerary

available flight

Sequence Diagram: Change Flight Itinerary

::

collaboration diagram change flt itinerary

1: change flight itinerary

2: get customer account3: get itinerary

: Booking System

4: present itinerary

Client Account DBMS

Traveler

8: available flight

Airline Reservation System

Collaboration Diagram: Change Flt Itinerary

5: select segment

7: update information

6: present detailed info

uml outline4
UML - Outline
  • Introduction
  • Behavioral modeling
    • Use case diagrams
    • Interaction diagrams
      • Sequence diagrams and collaboration diagrams
      • More about collaborations
    • State diagrams
    • Activity diagrams
  • Structural modeling
  • Advanced modeling
collaboration
Collaboration
  • What is a collaboration?
  • Core concepts
  • Diagram tour
  • When to model collaborations
  • Modeling tips
  • Example: A Booking System
what is a collaboration
What is a collaboration?
  • Collaboration: a collaboration defines the roles a set of instances play when performing a particular task, like an operation or a use case.
  • Interaction: an interaction specifies a communication pattern to be performed by instances playing the roles of a collaboration.
collaborations core elements
Collaborations: Core Elements

Construct

Description

Syntax

Collaboration

A collaboration describes how an operation or a classifier, like a use case, is realized by a set of classifiers and associations used in a specific way.

The collaboration defines a set of roles to be played by instances and links, possibly including a collection of interactions.

Name

Interaction

An interaction describesa communication pattern between instances when they play the roles of the collaboration.

collaborations core elements cont d
Collaborations: Core Elements(cont’d)

Construct

Description

Syntax

Collaboration-

Instance

A collection of instances which together play the roles declared in a collaboration.

Name

Interaction-

Instance

A collection of stimuli exchanged between instances playing specific roles according to the communication pattern of an interaction.

All new in UML 1.4

collaborations core elements cont d1
Collaborations: Core Elements(cont’d)

Construct

Description

Syntax

Classifier Role

A classifier role is a specific role played by a participant in a collaboration. It specifies a restricted view of a classifier, defined by what is required in the collaboration.

/ Name

Message

A message specifies one communication between instances. It is a part of the communication pattern given by an interaction.

label

collaborations core relationships
Collaborations: Core Relationships

Construct

Description

Syntax

Association Role

An association role is a specific usage of an association needed in a collaboration.

A generalization is a taxonomic relationship between a more general element and a more specific element. The more specific element is fully consistent with the more general element.

Generalization

classifier instance role trichotomy
Classifier-Instance-Role Trichotomy
  • An Instance is an entity with behavior and a state, and has a unique identity.
  • A Classifier is a description of an Instance.
  • A Classifier Role defines a usage (an abstraction) of an Instance.

id

«originates from»

ClassName

«conforms to»

/ RoleName

«view of»

classifier instance role trichotomy cont d
Classifier-Instance-Role Trichotomy(cont’d)

Classifier

ClassifierRole

Attribute-1

Attribute-2

Attribute-3

Attribute-1

Attribute-2

«originates from»

«conforms to»

Operation-1 (…)

Operation-3 (…)

Operation-1 (…)

Operation-2 (…)Operation-3 (…)

Instance

AttributeValue-1

AttributeValue-2

AttributeValue-3

  • The attribute values of an Instance corresponds to the attributes of its Classifier.
  • All attributes required by the ClassifierRole have corresponding attribute values in the Instance.
  • All operations defined in the Instance’s Classifier can be applied to the Instance.
  • All operations required by the ClassifierRole are applicable to the Instance.
different ways to name a role

A role name is preceeded by a ‘/’

A classifier name is preceeded by a ‘:’

/ Parent

: Person

Example:

/ Parent : Person

Example:

: Person

Charlie

Charlie : Person

Charlie / Parent : Person

Charlie / Parent

Different Ways to Name a Role

/ ClassifierRoleName : ClassifierName

instanceName / ClassifierRoleName : ClassifierName

association and association role

Association

Class

Class

0..5

{changeable}

«view of»

«view of»

«view of»

{frozen}

3..4

/ Role-1

/ Role-2

ClassifierRole

AssociationRole

ClassifierRole

Association and Association Role

Class-1

Class-2

  • An Association Role specifies the required properties of a Link used in a Collaboration.
  • The properties of an AssociationEnd may be restricted by a AssociationEndRole.
example a school
Example: A School

/ Teacher : Person

/ Student : Person

1 tutor

student *

program : Text

position : Text

1 lecturer

faculty member *

participant *

given course *

faculty 1

taken course *

: Faculty

: Course

role model vs class model

Resulting multiplicity

Extra attribute

Resulting multiplicity

Role Model vs. Class Model

The Classes give the complete description while the Roles specify one usage.

Role Model

Class Model

/ Teacher : Person

Person

1

*

/ Student : Person

0..1

name : Textposition : Textprogram : Text

position : Text

program : Text

*

*

*

*

1

1

*

0..1

*

1

*

*

*

: Course

Faculty

Course

: Faculty

collaboration diagram tour
Collaboration Diagram Tour
  • Show Classifier Roles and Association Roles, possibly together with extra constraining elements
  • Kinds
    • Instance level – Instances and Links
    • Specification level – Roles
  • Static Diagrams are used for showing Collaborations explicitly
collaboration diagram at specification level
Collaboration Diagram at Specification Level

/ Teacher : Person

student *

1 tutor

/ Student : Person

position : Text

program : Text

faculty member *

* participant

1 lecturer

given course *

faculty 1

* taken course

: Course

: Faculty

UML 1.4: The diagram shows the contents of a

Collaboration

collaboration diagram at instance level
Collaboration Diagram at Instance Level

student

tutor

Alice / Student

faculty member

John / Teacher

participant

faculty

tutor

Bob / Student

student

participant

: Faculty

taken course

taken course

faculty

lecturer

given course

Sara / Teacher

English : Course

faculty member

UML 1.4: The diagram shows the contents of a CollaborationInstance

collaborations including interactions

Sequence Diagram

Collaboration Diagram

x

y

z

1.1: a1.2: c

x

y

a

b

1.1.1: b

c

z

Collaborations including Interactions

UML 1.4: The diagrams show the contents of a CollaborationInstance with an InteractionInstance superposed

collaborations including interactions1
Collaborations including Interactions

Sequence Diagram

Collaboration Diagram

/ X

/ Y

/ Z

1.1: a1.2: c

/ X

/ Y

a

b

1.1.1: b

c

/ Z

UML 1.4: The diagrams show the contents of a Collaboration with an Interaction superposed

when to model collaborations
When to Model Collaborations
  • Use Collaborations as a tool to find the Classifiers.
  • Trace a Use Case / Operation onto Classifiers.
  • Map the specification of a Subsystem onto its realization.
collaboration modeling tips
Collaboration Modeling Tips
  • A collaboration should consist of both structure and behavior relevant for the task.
  • A role is an abstraction of an instance, it is not a class.
  • Look for
    • initiators (external)
    • handlers (active)
    • managed entities (passive)