Object-Oriented Development Process Part I: Requirement Gathering

1. Object-Oriented Development ProcessPart I: Requirement Gathering Warsun Najib Department of Electrical Engineering Gadjah Mada University

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

3. Activities of OODP

4. 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”

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

6. Use Case Rules • A use case should be a discreteunit 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”

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

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

9. 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!

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

11. An Example: A Video Store Application • Problem description

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

13. 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)

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

15. An Example: A Video Store Application • Finalize the use cases

16. 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?

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

18. Partitioning: An Example • Extended video store application • Proposed use cases

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

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

21. 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’

22. 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’