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.