design

analysis

implementation

testing

maintenance

Waterfall Development Process

Linear

•one phase is completed before the next begins

•in practice, must revise earlier decisions based on experience in project - I.e. there is feedback

design

analysis

implementation

testing

maintenance

Waterfall Development Process

Not iterative

•errors in earlier phases are really expensive to fix

•doesn’t allow for prototyping which is a strong aid for confirming requirements

A Generic Spiral Process for Development

evaluate

Analyze risks / plan

Engineer(design, implement, test)

Analyze requirementsfor this iteration

•4 phases comprise one iteration

•arbitrary number of iterations

•user involvement

•early feedback

•Studies show more successes with an iterative approach

Unified Process (UP)

•Defined by Rational Corporation

•Booch, Rumbaugh, Jacobson

•An iterative development process

•an iteration yields a working system

•iterations last anywhere from 2 weeks to 6 months

•many iterations make a project

•risk-driven

•early iterations prove out the major risks or show-stoppers

Unified Process (UP)

•several activities

•deliverables are referred to as artifacts - works produced (use cases, code, database designs, …)

•4 phases

• inception, elaboration, construction, transition

•Inception

•Use case model is started

Figure 2.4 Illustrates the activities in UP used to develop a system

•Iterative development is central to the UP

Figure 2.3 illustrates the 4 phases comprising the UP

More requirements gathering More programming

Unified Modeling Language (UML)

•Booch, Rumbaugh, Jacobson (the 3 Amigos) joined forces (all work for Rational) to create a unified development method/process, from which came the Unified Modeling Language (UML)

•Not a methodology

•Methodologies can use UML

•examples: Rational’s Unified Process; Catalysis

•value of UML is in the common language IT professionals have for expressing the nature of a system

Use Cases

Use Cases help with:

•requirements capture

•scope definition

•iteration management

•test planning

Use Cases

•a Use Case is initiated by an Actor

•Describes functional requirements from the user’s perspective

•illustrate actors & tasks

•forms:

•pictorial (defined in UML)

•textual

•not defined in UML

•recommended to leave UI details out and focus on the purpose of the use case

•focus on what the system does, not how it does it (black box)

Figure 9.1

Figure 9.3

Use Cases

Widely used. Not just an OO technique.

Diagramming defined in UML

Each Use Case will meet one or more user goals; collectively, Use Cases represent the functionality required by a system.

2 Forms: diagrams, textual – simplicity is important, both used

Scenario: an instance of a Use Case. Scenarios document a single flow (a story) through a Use Case, and are useful for testing purposes later on.

Main success scenario, Alternate scenario 1, Alternate scenario 2 , …

Use Cases

Introduced by Ivar Jacobson in 1986

•literal translation from Swedish ”usage case”

www.usecases.org - may be of use to you in the future

“blackbox” style is recommended - specify what the system must do, and not how it must do it.

A project may begin with the definition of many “brief” or “casual” use case definitions. Later on, these can be become “fully dressed”

Use Cases

Ch 6. Use Case example is very lengthy and fairly complete

must read: pages 45-61, and sections 6.12, 6.13, 6.15

Ch 25. Use Case has been broken down into multiple Use Cases that are related via <<extend>> and <<include>>

must read: sections 25.1, 25.2, 25.3, 25.5

Use Cases

Diagrams

System boundary

Actors – ‘stick people’

Use cases – ovals

Associations

Actors and use cases

Extend

Include

…

Use Case Example - diagram

Cashier

Process Sale

Handle Cheque Payment

<<include>>

Handle Cash Payment

<<include>>

Handle Credit Payment

Process Rental

<<include>> <<include>>

<<include>><<include>>

Cashier

Process Sale

Handle Cheque Payment

<<include>>

Handle Cash Payment

<<include>>

Handle Credit Payment

Process Rental

<<include>> <<include>>

<<include>><<include>>

HandleGift Certificate

Payment

<<extend>>

Use Case Example - diagram

Use Case Example - textual

Ch 6 example.

Process Sale

Ch 25 example

Process Sale

Process Rental

Handle Credit Payment

Handle Cheque Payment

Handle Gift Certificate Payment

Ch 10. Domain Model: Visualizing Concepts

Domain model

• illustrated with a class diagram (with no operations defined)

• emphasis on real-world objects

• a visual dictionary

• a map of concepts in a domain

• contains

• (conceptual) classes from the problem domain

• associations

• attributes

Ch 10. Domain Model: Visualizing Concepts

Domain model

Sequence Diagram ExampleConsider the sequence of events:

For each line of a purchase order

Check the quantity on hand

If there is enough,

remove that quantity from inventory

create a delivery item for those goods

check for the need to reorder

if we need to reorder then create a reorder line item

If there is not enough on hand, then create a back order line item

As a Sequence Diagram

:OLine :Product

hasStock:=checkQOH()

[hasStock] remove()

:PO

*[for each line] checkQOH()

:DelItem

:BOItem

[hasStock] new()

[not hasStock] new()

:RItem

needToReorder := checkLevel()

[needToReorder] new()

Figure 15.3 Collaboration diagram for makePayment

Figure 15.15 Iteration over a multiobject

Collaboration Diagram

128937:POrder

line1:LineItem TYZMonitor:Product

line2:LineItem OptMouseX :Product

JonesSupply:Customer

1:cost:=reportTotal()

1.1:price:=reportPrice()

2:reportTotal()

2.1:price:=reportPrice()

3:discount:=reportDiscount()

reportTotal()

Given that the objects below are involved, we show them along with the basic associations

Since these are objects, not classes, there are no multiplicities

Some message starts things off

In Figure 19.10, we see the result from analyzing all interaction diagrams for navigability.

Anthropomorphism

Anthropomorphism: Object-oriented programming works

like human organizations. Each object will communicate

with another one by sending messages. So the software

objects work by just sending those messages.

Figure 3.1 on page 31 - Architectural Layers

Introduction

• What object should receive this message?• What objects should interact to fulfill the request, and how?

???

Presentation

ApplicationLogic

Video Store

Record Rental

Video ID

...

...

...

... ...

Clerk

appLogicRequest()

Now what happens?

GRASP Patterns

1. Expert

2. Creator

3. Controller

4. Low Coupling

5. High Cohesion

Expert

• What is most basic, general principle of responsibility assignment?

• Assign a responsibility to the object that has the information necessary to fulfill it.– “That which has the information, does the work.”

– Not a sophisticated idea - rather, it is common sense

– E.g., What software object calculates sales tax?• What information is needed to do this?

• What object or objects has the majority of this information.

In the NextGEN POS application, it is necessary to know the grand total of a sale.

Where should that responsibility be placed?

Expert suggest that we should look for a class that has the information needed to determine the grand total.

If our design is just beginning, we look at the Domain Model and bring the pertinent conceptual classes into the class model

Pages

221-226

Law of Demeter• Also called Don’t Talk to Strangers

• Each class should only use a limited set of other classes: only units “closely” related to the current unit.

• “Each class should only talk (send messages) to its friends.” “Don’t talk to strangers.”

Law of DemeterFRIENDS

Layers PatternThe Layers Pattern organizes the large-scale logical/conceptual structure of a system into discrete layers with distinct, but related responsibilities.

Each layer exhibits high cohesion.

Lower layers are low-level providing general services; higher levels are more application specific.

Collaboration and coupling is from higher to lower layers

Layers defines an N-tier model

Page 450-1

Layers PatternBenefits/goals:

•strong cohesion within layers

•clean/clear definition of interface between layers

•promotes re-usability, replaceability

Typical Layers in an Information System - Fig 30.1, P. 451

Layers is a pattern where the structure of a system is organized into discrete layers where each layer is highly cohesive, and where higher layers are more application specific, lower layers are more low-level and service oriented.

Activity Diagrams

start

end

branch

merge

fork

join

guard

transition

swimlanes

activity

Used to present procedural steps (algorithm) that may involve concurrency. See pages 607-8.

Get nextdelta

[ none left ]

Check for existing dimension record

Insert newdimension record

[ does not exist ]

Update existingdimension record

[ exists ]

Updating a Star Schema

Churn Star Schema from The Official Guide to Informix/Red Brick Data Warehousing

Rate_planPeriod

Customer

Churn_reason

Carrier

Telephone

Churncredit_limitoutstanding_balancecurrent_bill

A Star Schema is a specialized ERD used in Data Warehousing.

To update the database, we:

(1) update each Dimension, and then

(2) update the Fact table

Updating a Star Schema

UpdateCustomer

Update Churn

UpdateRate plan

UpdateChurn Reason

UpdateTelephone

UpdateCarrier

UpdatePeriod

Statechart Diagram

A Statechart Diagram describes

•states for an object

•how/why an objects’ state changes

A Statechart Diagram is a State Machine

Possible states are related to an objects attributes, related classes, operations

A State Diagram models an object’s decision about what it does when it receives a message

States, Events, TransitionsState - a condition or situation during the life of an object during which it satisfies some condition, performs some activity, or waits for some event.

Event - a noteworthy occurrence

•An event can trigger a state transition

Transition – a relationship between two states indicating that on object in the first state will perform certain actions and enter the second state when a specified event occurs and specified conditions are satisfied

Process Sale Use CaseRecall

We can construct a State Diagram showing states for this use case

Waiting For Sale; Entering Items; Waiting For Payment are System states that arise in the Process Sale use case.

Figure 29.2

Transitions are system events … the diagram clearly shows when events, such as makeNewSale, are legal.

active

trx [pos]

overdrawntrx [neg]/warn()

deleteddelete

closed

clos

e

trx [pos] trx [neg]/warn()

close /warn()

reop

en

All together:

Bank Account Example

Prepare for Flow GraphFindMean (FILE ScoreFile){ float SumOfScores = 0.0;

int NumberOfScores = 0; float Mean=0.0; float Score;Read(ScoreFile, Score);while (! EOF(ScoreFile) {

if (Score > 0.0 ) {SumOfScores = SumOfScores + Score;NumberOfScores++;}

Read(ScoreFile, Score);}/* Compute the mean and print the result */if (NumberOfScores > 0) {

Mean = SumOfScores / NumberOfScores;printf(“ The mean score is %f\n”, Mean);

} elseprintf (“No scores found in file\n”);

}

1

2

3

4

5

7

6

89

Constructing the Logic Flow Diagram

4

3

2

1

5

6

7

9

CC = 11-9+2 = 4