Solving the ProblemSolving the Problem

Analysis & DesignAnalysis & Design

Requirements PhaseRequirements Phase

Requirements Requirements -- should be an unambiguous description of the -- should be an unambiguous description of the external behavior of the system to be built external behavior of the system to be built

R1 Report item name and unit price given item UPCR2 Record quantity of each item soldR3 Create a total for all the items purchased during saleR4 Accept cash, credit card or check as payment R5 Compute change for cash salesR6 Reduce inventory for items soldR7 Report total money in the tillR8 etc.

Typical problems :• Contains embedded design decisions (How vs. What).• Vague (must be measurable / testable)• Computer industry language (instead of user's language)• Requirements are not traceable to the system developed

Analysis Phase Analysis Phase Discover and understand the problem domainDiscover and understand the problem domain

• Object-oriented Analysis– decompose a problem by selecting relevant

concepts from the vocabulary of the domain.

• Develop a Conceptual Model– include class and interaction diagrams.

Conceptual ModelConceptual Model

• contains important real-world concepts and associations in the vocabulary of the problem domain: includes objects, roles, events, interactions

• becomes the foundation for the class model

Use CasesUse Cases

• A purposeful user interaction with a system

• A narrative description of a sequence of actions required to produce something of value to an actor or organization

Use CasesUse Cases

• describe functional requirements of the system• give a clear description of needed system behavior• help customer and developer agree on what the system should do• provide a basis for performing verification tests.• trace requirements to actual classes and operations in the system.• set bounds on the problem space

High-level use casesHigh-level use cases(collected to determine the complete scope of the system)(collected to determine the complete scope of the system)

Use Case: Buy Items

Actors: Customer, Cashier

Type: Primary

Description: A Customer arrives at a checkout with items to purchase. The Cashier records the purchase items and collects payment. On completion, the Customer leaves with the items.

• Use Case – the name is usually a business or domain process (Order a product, register for courses)

• Actors -- external agent (person playing a role, computer system, input/output device)

• Type -- primary, secondary or optional • Description -- a short narrative description (2 - 3 sentences)

Setting Priorities Setting Priorities (rank order use cases)(rank order use cases)

• Ranking may involve a combined score including multiple factors:– Impact on the architectural design– Risky, time-critical, or complex functions– New or risky technology– Represent line-of- business processes– Directly support increased revenue or decreased costs.

• Or ranking may simply classify use cases as high, medium, or low

• The most important use case is then expanded

Expanded Use CaseExpanded Use Case(minimal technology references)(minimal technology references)

Use Case Buy Items (essential description)

Typical Course of Events:  

Actor Actions: System Response:

1) This use case begins when a Customer arrives at a cashier's location with items to purchase

 

2) The Cashier records the identifier from each item, its description and price from the sales tag. If there is more than one of the same item, the Cashier can enter the quantity

3) Multiply the price by the quantity and add this to the ongoing sales transaction

4) When the item entry is complete, 5) Calculate the sales total

6) Cashier tells the Customer the total  

7) Customer gives cash payment.  

8) Cashier records the cash received amount 9) Calculate balance due the customer

Object Oriented Design (OOD) Object Oriented Design (OOD) PhasePhase

• Developer decides how the system will be implemented

• Many of the concepts become classes• The design phase elaborates (adds attributes

and methods) to the class model• Try this technique

– Modify the use case to include new system features

Put new system features into the use casePut new system features into the use case

Use Case Buy Items (system solution)

Requirements: R1, R2, R3, R4, R5, R6

Actor Actions: System Response:

1) This Use case starts when a Customer arrives at POST with items to purchase.

 

2) The Cashier enters UPC of each item. 3) Use UPC to determine item name, price and description. The item price is added to the sales total.

If there is more than one of an item, the Cashier can enter the quantity as well or re-enter the UPC

Show description and price of the current item

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

5) Calculate and present the sales total.

6) The Cashier tells the customer the total  

7) The Customer chooses payment type: 8) Log the completed sale

a.       If cash, see Pay by Cash 9) Update inventory levels

b.      If credit, see Pay by Credit 10) Generate a receipt

c.       If check, see Pay by Check  

11) The Cashier gives the receipt to the Customer  

12) The Customer leaves with the items purchased.  

Design a User Interface Design a User Interface for the userfor the user

Use screen navigation diagramsUse screen navigation diagramswhen necessarywhen necessary

Plan the first IterationPlan the first Iteration

• Determine how much can be delivered within the first development cycle

If necessary, create a simplified use case to fit the first time-box

Special Considerations for Special Considerations for the first Development Cyclethe first Development Cycle

• Try to handle the most difficult parts of the system first.

• If the architecture is untested, exercise the functionality of the architecture.

• If there is technological risk, exercise all the significant interfaces and interactions among subsystems to assure they are compatible.

Architecture – describes the Architecture – describes the structure of software systemsstructure of software systems

• Architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces.

• Describe major subsystems– External software interfaces– User interface– Database organization– Data storage– Key algorithms– Concurrency– Security– Networking– Portability– Programming language– Error handling

Plan Future CyclesPlan Future Cycles

• In subsequent development cycles, – add functionality to the previously delivered use case

or do another use case– update task assignments and milestones for each

cycle:• Requirements• Design• User documentation• Test cases• Technical reviews• etc

First Cycle: Simplified Use CaseFirst Cycle: Simplified Use CaseUse Case Buy Items with cash (First Iteration)

Actor Actions: System Response:

1) This Use case starts when a Customer arrives at POST with items to purchase.

 

2) The Cashier enters the UPC and quantity of each item.

3) The item name and description is displayed. The price is added to the sales total.

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

5) Presents the sales total.

6) The Cashier tells the customer the sales total  

7) The Customer gives a cash amount equal to or greater than the sales total

 

8) The Cashier enters the cash amount 9) Calculate and display change due the customer

  10) Generate a receipt

11) The Cashier gives the receipt and change due to the Customer

 

12) The Customer leaves with the items purchased.  

Make a minimum conceptual modelMake a minimum conceptual model

• concepts relevant to the use case being developed.

• A complete conceptual model would be all significant real-world concepts in the problem domain.

Find domain concepts Find domain concepts in the use casein the use case

• Who are the actors and what are they trying to do?• What “real world” objects are needed for each use case?• How do the objects work together to complete each use

case goal?• Consult with domain experts • Parse for noun and verb phrases

– Nouns become objects or attributes– Verbs become operations or associations.

• Use a Concept Check List

Concept Check ListConcept Check List ( (Craig Larman)Craig Larman)

• Physical objects • Specifications, designs or

descriptions of things • Places• Transactions• Transaction line items• Roles • Things in a container• Containers of other things• Catalogs• Events

• Organizations• Processes• Rules and policies• Records of finance, work, contracts,

legal matters• Financial instruments and services• Manuals, books• External Computer Systems or

devices• Abstract noun concepts

Concept Diagram of Concept Diagram of Buy ItemsBuy Items

Decide which domain concepts become Decide which domain concepts become objects that implement a solutionobjects that implement a solution

• Try CRC cards to Bridge from Concepts to ClassesCRC cards (Class, Responsibility, Collaboration)

• Original paper by Beck and Cunningham

at http://c2.com/doc/oopsla89/paper.html

CRC CardsCRC Cards

• Class Name -- Domain concept or programmer created class

• Responsibilities -- Tasks an object can do alone because of its local knowledge

• Collaborators -- Tasks done by other objects because of their knowledge

Class Name = Sale

Responsibilities: Collaborators:

  store Item specs and quantity   SalesLineItem

calculate a sales total    SalesLineItem

store payment amount and type  

ResponsibilityResponsibilityResponsibilities become class methods

– The method accomplishes a task by the object acting alone or with the help of others.

Two Basic Responsibilities for objects

• Knowing– object’s awareness of its own data, its links to other objects and

knowledge it can derive or calculate

• Doing – objects ability to modify itself, create and link to other objects, or delete

other objects and links, command other objects to take action or control or coordinate activity in other objects

CRC Card ProcedureCRC Card Procedure 1. Create cards for each relevant object in the use

case-- actors initiating a message to the system

-- the first object that receives the message

-- every object from the domain used in the solution

2. Walk through the handling of a system event

3. Allocate responsibilities by deciding which class handles an event or delegates it to another object

-- Put the main responsibilities of each class on the card.

-- Put the collaborators of each class on the card

Role Play the ClassRole Play the Class

A designer or member of a group can act the part of a "Class" when it is given control in a scenario

When role playing a class, determine – what can you do,– how are you dependent on others

ScenariosScenariosEach use case has a successful outcome and usually

one or more failure outcomes.

• Failures usually are:– Looking for an object which does not exist (identifier not found)– Creating a new object but the identifier already exists. – Violation of business rules (i.e. Customer withdraws an amount that makes

the balance lower than the minimum required by the bank)

• Use scenarios to validate the responsibilities of each object.

– Events leading to failure and to success

Use truth tables to Use truth tables to check for completenesscheck for completeness

Use Case Scenarios

Buy Items 1 2 3

Pre-Conditions          

UPC Exists F T T

Customer has sufficient funds   F T

Post-Condition Actions          

Reject sale and provide a message X X

Accept transaction     X  

Class DiagramClass Diagram

Interaction diagramsInteraction diagrams(sequence)(sequence)

Interaction DiagramsInteraction Diagrams(collaboration)(collaboration)

Entity-Relationship DiagramsEntity-Relationship Diagrams

Free Information for UML and ER Free Information for UML and ER diagrammingdiagramming

• Introduction to UML Diagramming http://www.togethersoft.com/services/practical_guides/umlonlinecourse/

http://www.rational.com/media/uml/intro_rdn.pdf

• Introduction to ER Diagramming http://www.utexas.edu/its/windows/database/datamodeling/index.html