1 / 47

Object Oriented Analysis

Object Oriented Analysis. Aim of Object-Oriented Analysis. To produce a specification of the requirements of the system in terms of objects. Requirements Specification describes what the system will do, and not how. Requirements. Functional What a system is expected to do

theta
Télécharger la présentation

Object Oriented Analysis

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 Analysis 310414 - OOA

  2. Aim of Object-Oriented Analysis • To produce a specification of the requirements of the system in terms of objects. • Requirements Specification • describes what the system will do, and not how 310414 - OOA

  3. Requirements • Functional • What a system is expected to do • Functionality of the system • Non-functional • Aspects of the system that are concerned with how well it provides the functionality • Response time • Throughput • Security considerations 310414 - OOA

  4. Documenting Requirements A description of the system in terms of: i. What does the proposed system do for the user ? ii. What are the features available and not available? iii. What are the operating assumptions, constraints and dependencies Iv. How will the system be used by the users (i.e. UI consideration). 310414 - OOA

  5. Use Case Model • Captures the functionality of the software from the userpoint of view • Built in early stages of development • Developed by analysts and domain experts • Objectives : • Specify context of a system • Capture requirements • Validate system architecture • Drive implementation and generate test cases 310414 - OOA

  6. Use Case Diagrams • Diagram depict three aspects : • Actors • Use cases • System or subsystem boundary 310414 - OOA

  7. Use Case Model • Identify key elements • Who –Actors • Actors interact with the system • What/ When –Use cases • A use case performs a specific task of the system Use Case model is collection of all use cases 310414 - OOA

  8. Used during requirements elicitation to represent overall behavior Actors represent roles, (types of user of the system) not necessary people Use cases represent standard mode of use or transaction Use Case Diagrams 310414 - OOA

  9. Actor An actor is someone or some thing that must interact with the system under development 310414 - OOA

  10. An actor models an external entity which interacts with the system: User Actor is a role that a user can play A role can be played by many users Staff contact A user can play many roles Manager, Staff Contact External system Actor 310414 - OOA

  11. Use Case A use case is a pattern of behavior, the system exhibits . It is a • specific flow of events performed by the system or • a specific way of using the system 310414 - OOA

  12. ATM Use Cases – Withdraw cash – Deposit funds – Transfer funds – Change PIN Actor – Bank customer Use Case Example 310414 - OOA

  13. Example : Use Case Diagram 310414 - OOA

  14. Example : Use Case Diagram 310414 - OOA

  15. Use Case Example • Diagram Editor • An interactive graphics editor which allows user to create,and edit drawings composed of lines, rectangles, ellipsesand text by allowing creation , selection and editing ofdrawing elements • • User can • Create diagrams • Create text and graphical elements • Edit diagrams, perhaps by deleting elements • Select existing elements • Manipulate diagram elements by moving them • Modifying diagram elements or resizing them by dragging a control point. 310414 - OOA

  16. Use Cases – Create diagram – Create element – Select element – Resize element – Move element – Delete element • Actor -User Use Case Example 310414 - OOA

  17. Use Case example 310414 - OOA

  18. Use Case - Creating Diagram • Editor starts with a new, empty diagram for the user to edit , and that menu options are provided enabling the user to create new diagrams The Diagram object represents the initial diagram The DiagramEditor object represents a “top-level” application object. It keeps track of what diagrams have been created 310414 - OOA

  19. Use case : Creating Elements Creating a rectangle : • The user makes a rectangle tool active; the shape of the cursor changes to a crosshair. • The user moves the cursor a number of times. • The user presses the mouse button. 310414 - OOA

  20. Use case : Creating Elements • The user moves the cursor a number of times. – A faint image of a rectangle is drawn; opposite corners of the rectangle are defined by the position at which the mouse button was pressed and the current position of the cursor. • The user releases the mouse button and the new rectangle is displayed on the screen. 310414 - OOA

  21. Use Case – Selecting Elements • The user makes selection tool active. • User moves the mouse cursor over an element and presses the mouse button. [Exception possible] • The element becomes selected and its control points are displayed. [Exception possible] • The user releases the mouse button 310414 - OOA

  22. Scenarios • A scenario is an instance of a use case. • Scenarios represent specific paths through the Use Case • There can be many scenarios. • Sufficient scenarios should be studied to fully understand the system. 310414 - OOA

  23. Scenario example : Library System • UseCase : Borrow a Book • Scenario 1 (normal): 1. Book borrower Mary borrows the library's 3 rd copy of War and Peace. She has no other book out on loan. 2. The loan is accepted and the system is updated. 310414 - OOA

  24. Scenario example : Library System Scenario 2 (abnormal): 1. Book borrower Joe tries to borrow the library's 1 st copy of Anna Karenina. He already has six books out on loan which is his maximum allowance. 2. The loan is refused. 310414 - OOA

  25. Scenario example : Library System Scenario 3 (abnormal): 1. Book borrower Mary borrows the library's Encyclopedia Britanica. 2. The loan is refused because the book can only be read in the reference room. 310414 - OOA

  26. A Use Case Description • Use case title • Actors • Preconditions • Event flow – brief description or step by step breakdown of the interaction between user and the system • Postconditions • Exceptions 310414 - OOA

  27. Use Case: Purchase ticket Actor: Passenger Pre condition: • Passenger is in front of ticket Distributor. • Passenger has sufficient money( coins) to purchase ticket. Post condition: • Passenger has ticket. Event flow: 1. Passenger inserts coins 2. Distributor displays the possibilities according to the amount deposited 3. Passenger selects one of the options 4. Distributor issues ticket. 5. Distributor returns change. Use Case Example (MRT Ticket Vending Machine) 310414 - OOA

  28. Use case Generalization • Example : Diagram editor creates graphical and text elements • Two more specialized use cases for ‘Create Element’ use case – Create Graphical Element – Create Text Element • ‘Create Element’ is abstract – User has to decide whether a textual or graphical element is to be created 310414 - OOA

  29. Use case Generalization 310414 - OOA

  30. Actors can be related by generalization – e.g. In shared environment ordinary users are not allowed to delete elements – Administartors have this authority – Administrators also use the system as ordinary users Generalization (actors) 310414 - OOA

  31. Use Case – Deleting Elements • User must first select an element and then send a message to the selection tool requesting for a deletion • Delete Element use case includes the use case for selecting an element 310414 - OOA

  32. <<includes>> relationship • A includes relationship represents a common behavior that is factored out of the use case. – Sequence of behaviour that is used frequently in a number of use cases • This behavior is factored out for reuse, not because it is an exception. 310414 - OOA

  33. The includes Relationship 310414 - OOA

  34. The includes Relationship 310414 - OOA

  35. The extends relationship • Deviation from the normal flow of events of a Use Case is captured as another Use Case – especially if the deviation is significantly important to the system • Use cases representing exceptional flows or additional functionality can extend more than one use case. • An Extends relationship represents relationship between normal and additional (or exceptional) Use Case. 310414 - OOA

  36. The extend relationship 310414 - OOA

  37. Other Examples 310414 - OOA

  38. Example : Diagram Editor 310414 - OOA

  39. Library system example To develop a computer system for a university library. The library currently uses a 1960s program form simple bookkeeping And a card index for user browsing. Develop an interactive system that handle bookkeeping and user browsing. Requirements Some requirements: • Cataloging of Books and journals – Library contains books and journals. – May have several copies of a book. – etc... 310414 - OOA

  40. Library system example (2) • Borrowing – Must keep track of when books and journals are borrowed and returned. – System should produce reminders when a book is overdue. – User can extend loan. – etc... • Searching – User can search for a book by subject, author, title, etc. – User can reserve book. – etc... 310414 - OOA

  41. Library system example (3) • Actors – Librarian – User • Borrower – Journal Borrower – Book Borrower • Browser 310414 - OOA

  42. Library system example (4) • Use Cases – Borrow book – Borrow journal – Update Catalog – Reserve Book – Return book – Return journal – Search an item 310414 - OOA

  43. Library system example (5) 310414 - OOA

  44. Library system example (6) 310414 - OOA

  45. Library system example –use case diagram 310414 - OOA

  46. More use cases – Library System • Issue Reminder • Check Reservation • Reject Loan • …. 310414 - OOA

  47. Summary (Use Case Modeling) • Use Case view contains – Actors : describe the roles users can play – Use Cases : describe the functionality available to them • Scenarios : particular instances of the use case – Basic course of events – Exceptional course of events • Use cases and actors can be related by generalization • <<includes>> relationship allows one use case to be wholly incorporated in another – factor out common behaviour • <<extend>> relationship allows optional functionality to be included in a use case 310414 - OOA

More Related