Solving the Problem

Document Sample
Solving the Problem Powered By Docstoc
					Solving the Problem
    Analysis & Design
              Requirements Phase
  Requirements -- should be an unambiguous description of the
          external behavior of the system to be built

         R1   Report item name and unit price given item UPC
         R2   Record quantity of each item sold
         R3   Create a total for all the items purchased during sale
         R4   Accept cash, credit card or check as payment
         R5   Compute change for cash sales
         R6   Reduce inventory for items sold
         R7   Report total money in the till
         R8   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
    Discover 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 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 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
                        Use 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 cases
    (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
                  (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 Case
(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,    3) Multiply the price by the quantity and add
its description and price from the sales tag. If there   this to the ongoing sales transaction
is more than one of the same item, the Cashier can
enter the quantity

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)
• Developer decides how the system will be
• 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 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   Show description and price of the current item
enter the quantity as well or re-enter the UPC

4) On completion of item entry, the Cashier             5) Calculate and present the sales total.
indicates to the POST that item entry is complete.

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
     for the user
Use screen navigation diagrams
       when necessary
         Plan 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
        Special Considerations for
       the 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
         structure 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

•   Describe major subsystems
     –   External software interfaces
     –   User interface
     –   Database organization
     –   Data storage
     –   Key algorithms
     –   Concurrency
     –   Security
     –   Networking
     –   Portability
     –   Programming language
     –   Error handling
             Plan 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
     •   Requirements
     •   Design
     •   User documentation
     •   Test cases
     •   Technical reviews
     •   etc
First Cycle: Simplified Use Case
Use 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    3) The item name and description is displayed. The
item.                                                 price is added to the sales total.
4) On completion of item entry, the Cashier           5) Presents the sales total.
indicates to the POST that item entry is complete.

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 model

• concepts relevant to the use case being

• A complete conceptual model would be all
  significant real-world concepts in the problem
              Find domain concepts
                 in 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 List
                           (Craig Larman)
•   Physical objects             •   Organizations
•   Specifications, designs or   •   Processes
    descriptions of things       •   Rules and policies
•   Places                       •   Records of finance, work, contracts,
•   Transactions                     legal matters
•   Transaction line items       •   Financial instruments and services
•   Roles                        •   Manuals, books
•   Things in a container        •   External Computer Systems or
•   Containers of other things       devices
•   Catalogs                     •   Abstract noun concepts
•   Events
Concept Diagram of
    Buy Items
   Decide which domain concepts become
      objects that implement a solution
• Try CRC cards to Bridge from Concepts to Classes
  CRC cards (Class, Responsibility, Collaboration)

• Original paper by Beck and Cunningham
                                    CRC Cards
Class Name = Sale
Responsibilities:                       Collaborators:
    store Item specs and quantity        SalesLineItem
    calculate a sales total              SalesLineItem
    store payment amount and type

•    Class Name -- Domain concept or programmer created class
•    Responsibilities -- Tasks an object can do alone because of its local
•    Collaborators -- Tasks done by other objects because of their knowledge
Responsibilities 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 Procedure
1.   Create cards for each relevant object in the use
       -- 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 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
Each 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
   – Events leading to failure and to success
              Use truth tables to
            check for completeness
Use Case                                  Scenarios

Buy Items                             1       2       3


  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 Diagram
Interaction diagrams
Interaction Diagrams
Entity-Relationship Diagrams
 Free Information for UML and ER
• Introduction to UML Diagramming

• Introduction to ER Diagramming

Shared By: