Solving the Problem

1
Solving the Problem

• Analysis Design

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

• 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

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

4
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

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

6
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

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

• 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)

8
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

9
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, 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
10
Object Oriented Design (OOD) Phase

• 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

11
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 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.  
12
Design a User Interface for the user
13
Use screen navigation diagramswhen necessary
14
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 time-box

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

16
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
  interfaces.
• Describe major subsystems
• External software interfaces
• User interface
• Database organization
• Data storage
• Key algorithms
• Concurrency
• Security
• Networking
• Portability
• Programming language
• Error handling

17
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
  cycle
• Requirements
• Design
• User documentation
• Test cases
• Technical reviews
• etc

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

20
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

21
Concept Check List (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

22
Concept Diagram of Buy Items
23
Decide which domain concepts become objects 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

24
CRC Cards
Class Name Sale 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 knowledge
• Collaborators -- Tasks done by other objects
  because of their knowledge

25
Responsibility

• 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
• objects 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

26
CRC Card Procedure

• 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
• Walk through the handling of a system event
• 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

27
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

28
Scenarios

• 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 object.
• Events leading to failure and to success

29
Use truth tables to check for completeness
Use Case Scenarios Use Case Scenarios Use Case Scenarios Use Case Scenarios Use Case Scenarios 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  
30
Class Diagram
31
Interaction diagrams(sequence)
32
Interaction Diagrams(collaboration)
33
Entity-Relationship Diagrams
34
Free Information for UML and ER diagramming

• Introduction to UML Diagramming
• http//www.togethersoft.com/services/practical_gu
  ides/umlonlinecourse/
• http//www.rational.com/media/uml/intro_rdn.pdf
• Introduction to ER Diagramming
• http//www.utexas.edu/its/windows/database/datamo
  deling/index.html