1. 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

2. 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

3. A Generic Spiral Process for Development evaluate Analyze risks / plan Engineer (design, implement, test) Analyze requirements for this iteration 4 phases comprise one iteration arbitrary number of iterations user involvement early feedback Studies show more successes with an iterative approach

4. 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

5. 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

6. Figure 2.4 Illustrates the activities in UP used to develop a system Iterative development is central to the UP

7. Figure 2.3 illustrates the 4 phases comprising the UP More requirements gatheringMore programming

8. 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

9. Use Cases Use Cases help with: requirements capture scope definition iteration management test planning

10. 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)

11. Figure 9.1

12. Figure 9.3

13. 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, …

14. 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”

15. 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 > and > must read: sections 25.1, 25.2, 25.3, 25.5

16. Use Cases Diagrams System boundary Actors – ‘stick people’ Use cases – ovals Associations Actors and use cases Extend Include …

17. Use Case Example - diagram Cashier Process Sale Handle Cheque Payment > Handle Cash Payment > Handle Credit Payment Process Rental >

18. Cashier Process Sale Handle Cheque Payment > Handle Cash Payment > Handle Credit Payment Process Rental > Handle Gift Certificate Payment > Use Case Example - diagram

19. 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

20. 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

21. Ch 10. Domain Model: Visualizing Concepts Domain model

22. Sequence Diagram Example Consider 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

23. 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()

24. Figure 15.3 Collaboration diagram for makePayment

25. Figure 15.15 Iteration over a multiobject

26. Collaboration Diagram 128937:POrder line1:LineItemTYZMonitor:Product line2:LineItemOptMouseX :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

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

28. 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.

29. Figure 3.1 on page 31 - Architectural Layers

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

31. GRASP Patterns 1.Expert 2.Creator 3.Controller 4.Low Coupling 5.High Cohesion

32. 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.

33. 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

34. 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.”

35. Law of Demeter FRIENDS

36. Layers Pattern The 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

37. Layers Pattern Benefits/goals: strong cohesion within layers clean/clear definition of interface between layers promotes re-usability, replaceability

38. 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.

39. 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.

40. Get next delta [ none left ] Check for existing dimension record Insert new dimension record [ does not exist ] Update existing dimension record [ exists ]

41. Updating a Star Schema Churn Star Schema from The Official Guide to Informix/Red Brick Data Warehousing Rate_plan Period Customer Churn_reason Carrier Telephone Churn credit_limit outstanding_balance current_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

42. Updating a Star Schema Update Customer Update Churn Update Rate plan Update Churn Reason Update Telephone Update Carrier Update Period

43. 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

44. States, Events, Transitions State - 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

45. Process Sale Use Case Recall We can construct a State Diagram showing states for this use case

46. 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.

47. active trx [pos] overdrawn trx [neg]/warn() deleted delete closed close trx [pos] trx [neg]/warn() close /warn() reopen All together: Bank Account Example

48. Prepare for Flow Graph FindMean (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); } else printf (“No scores found in file\n”); } 1 2 3 4 5 7 6 8 9

49. Constructing the Logic Flow Diagram 4 3 2 1 5 6 7 9 CC = 11-9+2 = 4