1 object oriented analysis and design system events & contracts

1

Object OrientedAnalysis and Design

System Events

&

Contracts

2אוריאל ברגיג, המכללה למנהל - המסלול האקדמי, קורס הנדסת תוכנה מכוונת עצמים

Object Oriented Analysis and Design

Analysis Design

Use Cases

What are the domain process ?

(text + visual notation)

Software Requirements Specification

What are the business needs ?

(long text)

ConceptualModel

What are the concepts, terms ?

(visual)

SystemSequenceDiagrams

What are the system events, operations ?

(visual)

Contracts

What do the system operations do ?

(text)

Collaboration / sequenceDiagrams

How software objects interact to fulfill task ?

(visual)

Design Class

Diagrams

What is the specification for the software classes ?

(visual)


System Sequence Diagrams

Cashier

:System

enterItem(UPC,quantity)

endSale()

makePayment(amount)

Corresponds to:Buy Item Use Case

Repeat until no more items


System Sequence Diagrams

Cashier

:System


endSale()

makePayment(amount)

Actor Actions:1. This use case begins

when a Customer arrives at a POST checkout system with items to purchase

2. Cashier records the identifier for each item. If there is more than one of the same item, Cashier enters the quantity

4. On completion of item entry, Cashier indicates to POST that item entry is complete

6. Cashier tells Customer the total

System Response:

3. Determines item price and adds item info to the running sales transactionDescription and price of the current item is presented

5. Calculates and presents sale total


System Sequence Diagramselements

Cashier

:System


endSale()

makePayment(amount)

Corresponds to:Buy Item Use Case

Repeat until no more items

ActorCross reference to use case

Text to clarify logic, control,

iterations, etc..

System event

System BLACK BOX


System Sequence Diagramselements

enterItem(itemID, quantity)

:System: Cashier

endSale()

makePayment(amount)

box may enlose aniteration area

the * [...] is an iterationmarker and clauseindicating the box is foriteration

external actor tosystem

Process Sale Scenario

system as black box

the name could be "NextGenPOS" but "System" keeps itsimple

the ":" and underline imply an instance, and are explained in alater chapter on sequence diagram notation in the UML

a message withparameters

it is an abstractionrepresenting thesystem event ofentering thepayment data bysome mechanism

description, total

return value(s)associated with theprevious message

an abstraction thatignores presentationand medium

the return line isoptional if nothing isreturned

total with taxes

change due, receipt

* [more items]

makeNewSale()


System Sequence Diagrams Identifying system events

It is necessary to be clear about the system boundary

Actors to be considered are those who trigger the system Costumer is not an actor !

From use case typical course of events, identify system (external) events


System Sequence Diagrams Naming System Events

Express at the level of intent rather than in terms of physical input medium

Preferably, start the name with a verb

endSale() ESCPressed()

makePayment(amount) enterAmountTendered(amount)enterPayment(amount)

Better Worse



Analysis Design

Use Cases





(long text)

ConceptualModel


(visual)



(visual)

Contracts


(text)



(visual)

Design Class

Diagrams


(visual)


Contracts

Describes what an operation commits to achieve What will happen

rather than

how it will be achieved

Depends on conceptual model system sequence diagrams identification of system operations


Contractsexample: enterItem

Name: enterItem(upc:number, quantity:integer)

Responsibility: Enter (record) sale of an item and add it to sale. Display item description and price.

Type: System

Cross References: System Functions: R1.1, R1.3, R1.9. Use Cases: Buy Items

Notes: Use fast dbase access

Exceptions: If UPC is invalid, indicate an error

Pre-Conditions: UPC is known to system


Contractsexample: enterItem

Post-Conditions: If new sale, a Sale was created (instance creation)

If new sale, new Sale was associated with POST (association

formed)

A SalesLineItem was created (instance created)

SalesLineItem was associated with Sale (association formed)

SaleLineItem.quantity was set to quantity (attribute

modification)

SaleLineItem was associated with ProductSpecification based

on UPC match (association formed)


ContractsContract Sections

Name: Name of operation, and parameters

Responsibilities: An informal description of responsibilities

this operation must fulfill

Type: Name of type (concept, software class, interface)

Cross References: System function reference numbers, use cases, etc.

Notes: Design notes, algorithms, etc.

Exceptions: Exceptional cases


ContractsContract Sections

Output: Non-UI outputs such as messages or records that are sent outside of system

Pre-Conditions: Assumptions about the state of system before execution of operation

Post-Conditions: The state of system after completion of operation


Contracts How to make Contracts

Identify system operations from system sequence diagrams

For each system operation, construct a contract

Start by writing responsibilities section

Then complete post conditions section

Then move to pre-conditions section



Writing post conditions

It should describe the state changes that occur to objects in the conceptual model (rather than actions)

Possible state changes: Instance creation or deletionAttribute modificationAssociation formed or broken



Writing post conditions Use past passive tense form (was..)

Establish memory between existing objects: The most common mistake:

not forming associations Association to several objects is very likely

Think of the system and its object like a stage in a theatre

Craig Larman


Contracts More on Contracts

Generating complete and accurate set of post-conditions is not likely and not necessary

Following pre-conditions worth capturing: Things that are important to test in software Things that affect the success of operation

Use notes section to capture known design statements

Use exceptions section to discuss reaction to exceptional situations


From Use Cases to Contracts

Use Case: Buy Item…Typical Course of Events:1. …

Use Case

Cashier System

enterItemendSale

makePayment

System Sequence Diagram

System

enterItem()endSale()makePayment()

SystemOperations

Contracts

Operation:enterItem…Post-conditions:1. …

Operation:endSale…Post-conditions:1. …


Contracts

More example(from larman’s book)


Contracts

More examplelogin use case contract


Use Case Description



Analysis Design

Use Cases





(long text)

ConceptualModel


(visual)



(visual)

Contracts


(text)



(visual)

Design Class

Diagrams


(visual)

1 object oriented analysis and design system events & contracts

Documents