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
Dec 18, 2015
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