1 / 22

Object-Oriented Development Process Part I: Requirement Gathering

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”

Download Presentation

Object-Oriented Development Process Part I: Requirement Gathering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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’

More Related