1 / 15

Class Project OOA Document Here is what you need to do for your class project SRS...

Class Project OOA Document Here is what you need to do for your class project SRS. OO Analysis OO Design Implementation OO Testing Deployment. Object Behavior Modeling. Object Relationship Modeling. Class Modeling. Know the Key Components of OOA Static components: - classes

williamrawlings
Download Presentation

Class Project OOA Document Here is what you need to do for your class project SRS...

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. Class Project OOA Document Here is what you need to do for your class project SRS...

  2. OO Analysis OO Design Implementation OO Testing Deployment Object Behavior Modeling Object Relationship Modeling Class Modeling Know the Key Components of OOA Static components: - classes class attributes (to define object states) class relationships (to define object operations/messages) Dynamic components: - interactions among objects (object communications) - control events that cause state transitions

  3. 1. Develop Use-Cases Developing use-cases: - What are the main tasks (functions) that the actors performs? - What system information will the actor acquire, produce or change? - Will the actor have to inform the system about changes in the external environment? - What information does the actor desire from the system? - Does the actor wish to be informed about unexpected changes? “Must read” report “Structuring Use Cases with Goals” at: http://alistair.cockburn.us/Structuring+use+cases+with+goals

  4. 2. Document Your Use-Cases Document each use-case using the table template given in the “SRS Components” document on the website. Compare our table to the author’s approach on page 188, and the example on page 190).

  5. 3. Draw Use-Case Diagrams Page 191.

  6. 4. Identify Analysis Classes • For each use-case description, apply “grammatical pars” to identify potential classes • Identify the attributes of each class • Identify operations that manipulate the attributes Use index cards (or simply a notepad) to document your analysis of each use-case. One card (or one page) for each potential class with its name, responsibilities, and collaborations with other classes. See Chapter 8 slides on guidelines for defining class responsibilities and collaborations (relationships: inheritance, association, dependency)

  7. What Potential Analysis Classes to Look For • External entities (e.g., other systems, devices, people) that produce or consume information to be used by a computer-based system. • Things(e.g., reports, displays, letters, signals) that are part of the information domain for the problem. • Occurrences or events (e.g., a property transfer or the completion of a series of robot movements) that occur within the context of system operation. • Roles (e.g., manager, engineer, salesperson) played by people who interact with the system. • Organizational units (e.g., division, group, team) that are relevant to an application. • Places(e.g., manufacturing floor or loading dock) that establish the context of the problem and the overall function of the system. • Structures (e.g., sensors, four-wheeled vehicles, or computers) that define a class of objects or related classes of objects.

  8. 5. Select Candidate Classes A selection criteria for potential objects (classes): • Retained information: Does the system need to know about the object? • Needed services: Does the object provide needed operations? • Multiple attributes: Does the object have multiple attributes? • Common attributes: Do attributes apply to all instances of the object? • Common operations: Do operations apply to all instances of the object? • Essential requirements: Does the object represent essential entity of the system? An object that satisfies these criteria is a potential candidate for inclusion in the CRC model.

  9. Review the Index Cards - 1 Reviewing CRC index cards can be done in different ways. • All participants in the review (of the CRC model) are given a subset of the CRC model index cards. • Cards that collaborate should be separated (i.e., no reviewer should have two cards that collaborate). • All use-case scenarios (and corresponding use-case diagrams) should be organized into categories. • The review team leader reads the use-case deliberately. • As the review leader comes to a named object, he/she passes a token to the person holding the corresponding class index card.

  10. Review the Index Cards - 2 • When the token is passed, the holder of the class index card is asked to describe the responsibilities noted on the card. • The group determines whether one (or more) of the responsibilities satisfies the use-case requirement. • If the responsibilities and collaborations noted on the index cards cannot accommodate the use-case, modifications are made to the cards. • This may include the definition of new classes (and corresponding CRC index cards) or the specification of new or revised responsibilities or collaborations on existing cards.

  11. 6. Describe Your Classes Use table format to describe each identified class. The table template is provided in the revised SRS template. Draw a “conceptual” UML class inheritance diagram showing relationships among classes.

  12. 7. Collaboration and Behavior Modeling Draw UML object collaboration diagrams. Show how potential objects of your class will collaborate (i.e., call each others methods) Draw UML state or state chart diagram(s) for either each class or for the entire system. Show what events make a class (or the system) to transition from one state to another. Draw UML sequence diagram for each use-case. The sequence diagram is derived from the “Event Flow” section of use-case description.

  13. 7. Assemble the SRS Document - 1 Use revised template posted on the website. - Use-Case Modeling Identify your actors/users of the system, define usage scenarios, define the event flow for each scenario, draw UML use-case diagrams, and provide use-case descriptions in table format. - Class Modeling Apply CRC method (chapter 8) to use-cases to identify classes, draw “conceptual” UML class inheritance diagram showing relationships among classes, and provide class descriptions in table format. - Object Collaboration Modeling Draw UML object collaboration diagrams to show how objects interact with each other. Interactions are based on methods invocations among objects.

  14. 7. Assemble the SRS Document - 2 - Object Behavior Modeling Draw UML state diagram for each class to show what events make a class to transition from one state to another. States are derived from actions performed by the class. - Sequence Diagrams Draw UML sequence diagram for each use-case. Derived from “Event Flow” section of use-case descriptions.

  15. Submission Requirements See chapter 8 slides for more details. Review the “SRS Components” handout on the website. Use the revised SRS template posted on the website. First draft: Wed 10/14/09 (electronic copy ONLY - via email) Use-case modeling only. Sections 1 and 2 of the posted SRS template. Final submission: Wed 10/28/09 (printed and electronic copies) Completed SRS document. High expectation of completeness, quality, and professionalism. Review your final document carefully as per guidelines toward the end of chapter 8 slides.

More Related