CS1020

1

• Software Life Cycle

The sequence of stages from conception to
operation of a program is called the software
life cycle.
2
Software Life Cycle stages

• Analysis
• Market Requirements
• Technical Requirements
• Functional Specification
• Design
• Architecture
• Technologies
• System level design
• Sub-system component design
• Implementation
• Coding
• Documentation
• Online help
• Tutorials, user manuals
• Quality Assurance Testing
• Validation Verification
• Usability
• Deployment
• operation

3
OO Analysis, Design, Programming

• Related but distinct
• OOA is concerned with developing an object model
  from requirements analysis
• OOD is concerned with developing an object
  oriented system model to implement requirements
• OOP is concerned with realizing an OOD using an
  object oriented programming language such as Java

4
Object-Oriented Design Approach

• Model objects that are part of the problem
  domain
• Have objects exhibit their normal behavior
• Add objects that do not have problem-space
  analogs
• Have the objects work together to create a
  solution

5
ICONIX Unified Object Modeling Approach
Use Case Driven Object Modeling with UML A
Practical Approach by Doug Rosenberg with
Kendall Scott Addison-Wesley, New York, 1999.
ISBN 0-201-43289-7
6
ICONIX Object Modeling Approach
Rosenberg Scott
7
Domain Modeling

• Problem Domain - area that encompasses real-world
  things and concepts related to the problem that
  the system is being designed to solve.
• Domain Modeling - the task of discovering
  objects (classes, actually) that represent
  those things and concepts. Domain modeling
  uncovers objects in the problem space and defines
  static relationships among them

Rosenberg Scott
8
Domain Modeling

• The domain model serves as a glossary that the
  writers of use cases use in the early stages of
  that effort (or vice versa?)
• Domain modeling works outward from the data
  requirements to build a static model of the
  problem domain relevant to the proposed system

Rosenberg Scott
9
Key Elements of Domain Modeling

• Find appropriate classes that accurately
  represent the real abstractions that the problem
  domain presents
• Executed well, this activity establishes a solid
  foundation on which to build the system

Rosenberg Scott
10
Source for Discovering Classes

• High-level problem statement
• Lower-level requirements
• Expert knowledge of the problem space

Rosenberg Scott
11
Grammatical Inspection

• Read relevant material, highlighting nouns, verbs
  and possessive phrases.
• Nouns and nouns phrases become objects and
  attributes
• Verbs and verb phrases become operations and
  associations
• Possessive phrases indicate that nouns should be
  attributes rather than objects

Rosenberg Scott
12
Use Cases
A use case describes particular functionality
that a system is supposed to perform or exhibit
by modeling the dialog that a user, external
system, or other entity will have with the system
developed. Actor entity interacting with the
system, e.g., a user, a device, or another
system. Pfleeger, p. 265
13
Motivation

• Each use case describes a possible scenario of
  how an external entity interacts with the system.
  The collection of uses cases paints a picture of
  the complete functionality of the system.
• Customers can read use cases to see if the
  system will include all desired functionality
• System designers use use cases to lay out the
  systems objects and data elements
• Testers employ use cases as a basis for system
  testing

Pfleeger p. 265-66
14
Use Case Diagram
Cellularnetwork
User
Cellular telephone
15
Use Case Diagram
ltltincludegtgt
16
A use case tells a story of reaching a goal, or a
set of stories of both getting and failing.

• UC 4 Clerk takes customer order
• 1. On order screen, clerk enters the customer
  information, order items, and item quantities.
• 2. System checks customer credit, credit OK.
• 3. System checks order quantities, quantities
  OK.
• 4. System accepts and queues the order.
• Extensions
• 2a. Low credit Clerk takes prepayment, return
  to step
• 3a. Low on stock Customer accepts reduced
  order quantity, return to step 4, or Customer
  cancels order, terminate use case.

Alistair Cockburn www.usecases.org
17
Examining the Goals the system supports makes for
good use cases.

• Place an order.
• Get money from my bank account.
• Get a quote.
• Find the most attractive alternative.
• Set up an advertising program.
• Goals summarize system functions in
  understandable, verifiable terms of use.

Alistair Cockburn www.usecases.org
18
References

• Use Case Driven Object Modeling with UML A
  Practical Approach by Doug Rosenberg with Kendall
  Scott. Addison-Wesley, New York, 1999. ISBN
  0-201-43289-7
• The Unified Modeling Language User Guide by Grady
  Booch, James Rumbaugh, and Ivar Jacobson.
  Addison-Wesley, New York, 1999. ISBN
  0-201-57168-4
• UML Distilled by Martin Fowler with Kendall
  Scott. 2nd Ed. Addison-Wesley, New York, 1999.
  ISBN 0-201-65783-X