mcs 270 spring 2014

MCS 270 Spring 2014

Object-Oriented Software Development

GUSTAVUS ADOLPHUS COLLEGE gustavus.edu

Today’s schedule

Interaction Modeling:

Use Case Model

Sequence Model

Activity Model

Adapted from Software Engineering,

Spring 2006, NYU

http://cs.nyu.edu/courses/spring06/

V22.0474-001

MCS 270 Object-Oriented Software Development


Class model: describes the static structure of objects and relationships in a system

Comprises object and class diagrams

State model: describes the dynamic aspects (life cycles) of objects and the nature of control in a system

Interaction model: describes how objects in a system interact to achieve broader results

Unified modeling language (UML)



Interaction Modeling: Use Cases

A use case names a type of user (actor) and something that they want to do (usecase).

An actor is an external user of a system. Can be a human, a device, or a piece of software.

The use case describes how an actor achieves a specific tangible goal.



Interaction Modeling: Use Cases

Usecase can consist of:

Textual Description: Name, Summary, Actors, Entry conditions, Exit conditions, Exceptions or Errors, Event-Flow Description

UseCase Diagram: Graphical (Brief!) summary of use case



Example: Use-Case Description

Name: Normal Subway Ride

Summary: A passenger takes a subway ride

Actors: Passenger

Entry Condition: Passenger at start station

Exit Condition: Passenger leaves end station

Exceptions: Out of tickets, Train in repair, Train Derail,

Door won’t open, Miss stop station



Event-flow Description

Passenger purchases ticket/has pre-purchased ticketTrain arrives and stops at platformDoors openPassenger steps into trainDoors closePassenger presses request button for final stopDoors open at final stopPassenger exits train


Example: Use-Case Description


Example: Use Case Diagram

G

raph showing

Actors

Use cases

Edge: actor-case if that actor is

involved in that case

A

ctors

Stick figures

U

se cases

Ovals

Repair

Ride

passenger

technician


Boundary for all use cases


Exceptional Situations

Include relationships“Buy Ticket” use case is included in Ride use case.

Extend relationshipsExpresses an exceptional variation of a use case

Normally used to express errors



Repair

Ride

passenger

technician

Derail


<<extend>> Buy Ticket

<<include>>


Summary of Use Cases

Use Case DiagramShows all actors, use cases, relationships

Actors are agents external to the system

Use Case Description – information for single Use caseEntry/Exit Conditions, Story, Main and Alternative Event flows, Exceptions

Specified in a separate document

Report style – complete sentences, etc



Interaction Modeling: Sequence Model


Sequences elaborate Use Cases - consist of:

Textual Scenario: Sequence of events occurring a specific event sequence in a system (could be a use case)

Sequence Diagram: Graphical summary of participants (Actors, Objects) and messages between participants through time


Sequence Diagram

Sequence Diagram is a table

Columns are classes or actors (lifelines)

Rows are time steps (time flows from top to bottom)

Horizontal Arrows show control/data flowMethod callsImportant changes in state

Specific Diagram for each task



Example Sequence Diagram

Passenger

Station

TrainbuyTicket()

arrives

openDoors()

closeDoors()

pushButton(S)

Classes & Actors




Passenger

Station

TrainbuyTicket()

arrives

openDoors()

closeDoors()

Method Call

Note: These are

all synchronous method

calls. There are

other kinds of

invocations.


pushButton(S)



Passenger

Station

TrainbuyTicket()

arrives

openDoors()

closeDoors()

Invocation lifetime spans

lifetimes of all nested

invocations


pushButton(S)



Passenger

Station

TrainbuyTicket()

arrives

openDoors()

closeDoors()

“Lifelines” fill in time between

invocations

pushButton(S)


Interaction Modeling: Activity Model


Activity Model consists of:

Activity Diagram: Flow Chart of operations of application


Example Activity Diagram

buyTicket

trainArrive

board

Activities in

roundtangles

Station Train



buyTicket

trainArrive

board

Fork

Station Train



Join

Concurrency


buyTicket

trainArrive

board

Swim lanes show which

classes/actors are

responsible for which part

of the diagram

Station Train




stopTrain announceNoStop

StopRequested?

yes no

Flow-chart if-then




Overview on Using UML: What’s Good

A common languageMakes it easier to share requirements, specs, designs

Visual syntax is useful, to a pointA picture is worth 1000 wordsFor the non-programmer, easier to grasp simple diagrams

than simple code/pseudo-code

To the extent UML is precise, forces clarityMuch better than natural language

Commercial tool supportTools for UML -> code or vice-versa



Hodge-podge of ideasUnion of most popular modeling languages

Visual syntax does not scale wellMany details are hard to depict visually

Ad hoc text attached to diagramsNo visualization advantage for large diagrams

1000 pictures are very hard to understand

Semantics is not completely clearSome parts of UML underspecified, inconsistent


Overview on Using UML: What’s Not so Good


Why use UML?

UML is being widely adoptedBy users

By tool vendors

By programmers

A step forwardBetter than just diving in and coding!

First standard for high-levels of software process

Expect further evolution, development of UML



Suggestions on using UML

Discovering Requirements for CodeUse Case Diagrams/Descriptions to illustrate use cases

Activity or Sequence Diagrams to illustrate typical flow within a use case

(scenarios)

DesignClass Diagram for system architecture



Use Case Exercise

Groups of 3-4: Create a Use Case analysis of “GusList” – an on-line classified

ad service for the Gustavus community.

Ideal: Design use cases in conversation with users (Students, Faculty, Staff)

Next Best – You will practice this in conversation with each other.

Task: Identify

Actors

Use Case Names (General)

By next Tuesday, prepare (individually) a Requirements statement and a use

case document.

Document contains: Requirements statement. Use Case diagram(s). At least

two fully developed Textual Descriptions.



Assignments

Friday – Read Chapters 10,11

Continue GusList Use Case Project

Homework: Chapter 5. Exercises 5.3, 5.4

Programming: Interfaces

Due Tomorrow: Friday, Feb. 21


mcs 270 spring 2014

Documents

use casesa use case

use casesusecase

use casenormally

software engineering

piece of software

summary of use casemcs

eduinteraction modeling

type of user actor