Object-Oriented Development Process Part I: Requirement Gathering Warsun Najib Department of Electrical Engineering Gadjah Mada University

What is OODP?  Software development process based on object-orientation principle Emphasis on “process” Object-orientation: focusing on “objects” within and around the software  As a software engineering process, OODP can be modeled in different ways Waterfall Incremental (similar to prototyping) Spiral

Activities of OODP

Activities of OODP and Use Cases  OODP activities are centered on the concept of use case A use case is a transaction that begins with a user stimulus and ends with a response In between, there are program logic (input validation, action execution, data update, etc) A use case is triggered by an external event, needs that motivate a user to stimulate the system  Example: “The customer wants to send money to another account” Example of use case in respond to the above event: “money transfer”

Use Case Rules  A use case must define a complete transaction It should contain sufficient information Incomplete information makes it impossible to finish a transaction Example: in the “money transfer” use case, if only account numbers are provided, it is impossible to complete the transfer (i.e., how much ?) The required set of information is determined by the user

Use Case Rules  A use case should be a discrete unit of work Principle of cohesiveness - focuses only at one activity Cohesive use case reduces complexity Example of non-cohesive use case: “create a loan and open a savings acct. to guarantee the loan” Avoid multiple identical inputs that actually belong to separate transactions Example of a use case with multiple identical inputs: “disburse payment from an account to up to three user accounts”

Use Case Signature  How to represent use cases in a concise but meaningful way  Four pieces of information about a use case Inputs (and their order)  What are the inputs for the transaction specified by the use case? Input types  Syntactic definition to check validity of inputs Use case outcomes  Possible logical results of the transaction Any returned information  Information outcomes returned to the user

Use Case Signature  Example: “money transfer” Transferring money from an account to another. Done by specifying the account numbers, PIN, and the amount of money transferred  The use case signature is shown as follows

Requirement Gathering  Goals To define the problem space by binding the scope To provide developers with sufficient abstraction of problem domain without having to go into details  Heavy involvement of users  Ways to gather information from users Existing system walkthrough Document evaluation Interview  Record all (textual) information!

Requirement Gathering  From problem description to object, attribute, actors, and function identification through grammar examination Create vocabulary (i.e., data dictionary) from the problem domain Identify nouns  nouns are potential candidates for attributes or objects Identify adjectives  adjectives can be attributes, too Identify verbs  verbs may point to use cases Identify actors  normally persons involved in running the system

An Example: A Video Store Application  Problem description

An Example: A Video Store Application  Initial selection of application business objects and their attributes Complex elements are most likely objects Primitives (integer, string, etc.) are most likely predicates

An Example: A Video Store Application  Identification of (preliminary) use cases Rent a video (id, customer) Return a rented video (id) Add a new video to the inventory (id, title) Create a new member (id, credit card) Delete an existing video (id) Delete an existing member (id) Make a video late (id) Pay overdue fees (id, amount)

An Example: A Video Store Application  Finding outcomes of each use case Find for logically invalid inputs  id does not exist  a rented video may already be rented  a returned video may have status indicating it was not rented before Duplicating when creating new objects  created id may already exist Business rules  a member with outstanding fines or videos may not rent  members have a max. number of videos that can be rented  videos are considered late after three days

An Example: A Video Store Application  Finalize the use cases

Post-Processing  Walkthrough of the proposed use cases, between users and developers  Try to come up with an agreement on use cases  The questions Have all proposed use cases covered the scope of the application? Are the use cases inputs and their types correct? Have all outcomes of each use case been identified?

Partitioning  To logically map use classes into functional requirements  Partitioning by increments  Partitioning strategies Easiest first: to ease the development team into working with use cases or objects Target use cases for operational support: to get a set of use cases operational a.s.a.p. Provide most functionality a.s.a.p.: to show as much of the system’s capability a.s.a.p. Support end user training: to provide most application operations but not enough to run in production mode

Partitioning: An Example  Extended video store application  Proposed use cases

Partitioning: An Example  Increment #1 Use cases  Add category  Define branch  Add vendor  Add video  Add copy Strategy  A practice increment and does not harm if something wrong happens  If successful, user is able to start building the video database

Partitioning: An Example  Increment #2 Use cases  Add member  New rental agreement  Rent video  Run overdue report  Return video  Collect rental fee  Reserve video Strategy  To deliver most of the essential functions  To operate the store  To demonstrate a fairly complete system

Partitioning: An Example  Increment #3 Use cases  Rent override  Get availability  Pay fines  Run royalty report  Run usage report  Cancel rental Strategy  To provide additional use cases to make the system ‘operational’

Partitioning: An Example  Increment #4 Use cases  Remove copy  Remove video  Remove member  Remove vendor  Set copy status  Rent override  Remove member from wait list Strategy  Non-critical additional features to make the system ‘complete’