Object-Oriented Development Process Part I: Requirement Gathering Warsun Najib Department of Electrical Engineering Gadjah Mada University.
Published byModified over 4 years ago
Presentation on theme: "Object-Oriented Development Process Part I: Requirement Gathering Warsun Najib Department of Electrical Engineering Gadjah Mada University."— Presentation transcript:
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 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’