Transcript CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Class Project OOA Document Here is what you need to do for.

CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Class Project
OOA Document
Here is what you need to
do for your class project SRS...
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
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
OO Analysis
OO Design
Implementation
OO Testing
Deployment
Class
Modeling
Object
Relationship
Modeling
Object
Behavior
Modeling
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
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
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
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).
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
3. Draw Use-Case Diagrams
Page 191.
Saf eHome
Access camera
surveillance via t he
Int ernet
Conf igure Saf eHome
syst em paramet ers
homeowner
Set alarm
cameras
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
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)
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
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.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
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.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
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.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
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.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
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.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
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.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
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.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
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.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
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.