Class%20Project - PowerPoint PPT Presentation

About This Presentation
Title:

Class%20Project

Description:

Title: PowerPoint Presentation Author: CSIS Last modified by: Dr. Hisham Haddad Created Date: 3/27/2000 8:44:20 PM Document presentation format: On-screen Show (4:3) – PowerPoint PPT presentation

Number of Views:51
Avg rating:3.0/5.0
Slides: 16
Provided by: CSIS155
Category:

less

Transcript and Presenter's Notes

Title: Class%20Project


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

2
  • 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/Structuringusecas
    eswithgoals

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 authors 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.
Write a Comment
User Comments (0)
About PowerShow.com