Transcript CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Chapter 8 Analysis Modeling Part II Elements and methods of analysis modeling.

CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Chapter 8
Analysis Modeling
Part II
Elements and methods of analysis modeling
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Step 1: Class Modeling
(for OO Analysis)
• Identify analysis classes by examining the problem statement
• Use “grammatical pars” to identify potential classes
• Identify the attributes of each class
• Identify operations that manipulate the attributes
Note that this is the approach we’ll follow for modeling
our class projects. Refer to this set of slides when
working on your Analysis Model. Refer to SRS
Components document and use project requirements
template on the website.
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Analysis Classes: what 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 – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
CRC Modeling Method
CRC modeling involves selecting classes, defining their
responsibilities, and identifying collaborations among classes.
Class name:
Class type: (e.g., device, property, role, event, ...)
Class characteristics: (e.g., tangible, atomic, concurrent, ...)
Responsibilities:
Collaborators:
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Selecting Analysis 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 – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Be Aware of Class Types
• Entity classes, also called model or business classes, are
extracted directly from the problem statement (e.g., FloorPlan
and Sensor).
• Boundary classes are used to create the interface (e.g.,
interactive screen or printed reports) that the user sees and
interacts with when using the software.
• Controller classes manage a “unit of work” from start to finish.
That is, controller classes can be designed to manage
– the creation or update of entity objects;
– the instantiation of boundary objects as they obtain information
from entity objects;
– complex communication between sets of objects;
– validation of data communicated between objects or between the
user and the application.
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Defining Class Responsibilities - 1
Class responsibility implies attributes and operations (i.e., needed
content such that the class performs its intended function as per
the scope statement or system narrative).
Suggested guideline (OO principles) for allocating responsibilities to a
class:
1. System intelligence should be evenly distributed across classes.
- Uneven distribution of responsibilities may lead to few
dominant classes (avoid high coupling)
- If a class has a long list of responsibilities, try to divide it
to subclasses (facilitate maintainability)
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Defining Class Responsibilities - 2
2. Each responsibility should be stated as generally as possible,
so that polymorphism is utilized (generic methods, different
implementations).
3. Information and the behavior related to the class should reside
within the same class, so that encapsulation is utilized (data
and their methods are in the same object).
4. Information about one thing should be localized with a single
class, not distributed across multiple classes. Thus, a class
should be complete (maximum cohesion, minimize coupling).
5. Responsibilities should be shared among related classes, when
appropriate. Thus, achieving needed collaborations.
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Identifying Class Collaborations - 1
Collaboration is required when a class cannot fulfill all of its
responsibility on its own (i.e., the class doesn’t have methods
to manipulate its attributes).
Potential relationships:
part-of: This is a subclass relationship (part of an aggregate)
e.g., class engine is part (subclass) of class car.
e.g., class sensor is part (subclass) of class controls panel.
has-knowledge-of: This is true when a class requires information
from another class that is not a sub/parent class.
e.g., class Engine_Status read engine temperature value from
class Temperature_Sensor.
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Identifying Class Collaborations - 2
depends-upon: This is true when dependency exists and not
achieved via part-of or has-knowledge-of relationship.
e.g., class Transmission may depend upon class Engine.
e.g., class student_schedule may depend on class
offered_courses.
For a potential class, the names of collaborator classes and their
relationships are recorded on the index card.
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Reviewing the CRC 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 – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Reviewing the CRC 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 – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Devise Class Hierarchy
Class hierarchy is a graphical presentation of class relationships
(called class model)
At a higher level, the system is represented by subsystems
(packages in UML, page 216) and their relationships (dashed
and solid arrows in UML). For example, Car system may include
the subsystems Engine, Body, Powertrain, and Electronics.
Various notations are available for class modeling (Booch,
Coad/Yourdon, Rumbaugh).
UML offers various class diagrams for different relationships,
including generalization/specialization, aggregation, realization,
and dependency.
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Class Hierarchy Diagram - 1
Generalization Specialization
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Class Hierarchy Diagram - 2
Composite Aggregates
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Class Hierarchy Diagram - 3
Package
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Step 2: Object Relationship Modeling - 1
Object relationship modeling focus on the various relationships
between objects of the system (in addition to class
relationships) (derived from ER modeling).
Potential relationships: part of, contains, produces, coordinates,
composed of, transmits to, polls, controls, reads from,
manages, next to, etc… (verbs and verb phrases)
Grammatical pars of the scope statement (use-case
descriptions) identifies such relationships (verbs), which in
turn are recorded on the index cards.
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Object Relationship Modeling - 2
Steps for deriving an object relationship model:
1. From the index cards, draw objects of the system or
(subsystem) with unlabeled lines.
2. From the index cards, evaluate responsibilities and
collaborators for object relationships. Label the lines on the
diagram and indicate the relationship direction.
3. Evaluate each labeled relationship for cardinality and
modality (similar to ERD).
Repeat these steps for every subsystems.
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Object Relationship Diagram
Object Relationships
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Multiplicity Diagram
Wa ll
Figure 8.17
1
1
1
page 215
is used to build
0..* is used to build
1..*
W a llSe gm ent
is used to build
Window
Doo r
0..*
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Dependency Diagram
Camera
DisplayWindow
<<access>>
{password}
Figure 8.18, Page 215
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Step 3: Behavior Modeling
Object behavior modeling represents the dynamic view of the
system (i.e., system responses to external events).
Object behavior modeling consists of two models:
1. Behavior modeling of the various states of each object
2. Behavior modeling of the entire system
This is the approach we are using to model our class
projects. Refer to the previous and this set of slides
when working on your Analysis Model. Refer to SRS
Components document and use project requirements
template on the website.
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Object Behavior
Modeling states of an object:
An objects may be associated with different states represented
by the values of its attributes. Events (exchange of
information) result in changing the values of attributes.
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Object Behavior Model
To create the object behavior model, the analyst must perform
the following steps:
- Evaluate all use-cases to fully understand the sequence of
interactions within the system.
- Identify events that drive the interaction sequence and
understand how these events relate to specific objects.
- Create an event sequence for each use-case.
- Build a state diagram for the system.
- Review the behavioral model to verify accuracy and
consistency.
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
State Representation
In the context of behavioral modeling, two different
characterizations of states must be considered:
- the state of each class as the system performs its function
and
- the state of the system as observed from the outside as the
system performs its function
The state of a class takes on both passive and active
characteristics:
- A passive state is simply the current status an object’s
attributes.
- The active state of an object indicates the current status of
the object as it undergoes a continuing transformation or
processing (in response to events/triggers).
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
The State of a System
•
•
•
•
State: a set of observable circumstances that characterizes
the behavior of a system at a given time.
State transition: the movement from one state to another.
Event: an occurrence that causes the system to exhibit
some predictable form of behavior.
Action: process that occurs as a consequence of making a
transition.
Diagrams:
•
Sate Diagram: representation of an object’s states.
•
Sequence Diagram: representation of behavior flow among
classes (derived form use-case).
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
State Diagram - ControlPanel Class
t imer < lockedTime
t imer > lockedTime
locked
password = incorrect
& numberOfTries < maxTries
Figure 8.20
page 219
comparing
reading
numberOfTries >maxTries
key hit
password
ent ered
do: validatePassword
password = correct
select ing
act ivat ion successful
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Another State Diagram
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Sequence Diagram
cont rol panel
homeowner
system
ready
A
sensors
sensors
system
reading
password entered
comparing
request lookup
result
Figure 8.21
password = correct
request activation
numberOfTries > maxTries
locked
page 220
A
timer > lockedTime
selecting
activation successful
Figur e 8 .2 7 Sequence diagr am ( part ial) f or
activation successful
Saf eHome secur ity f unct ion
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Event Trace Diagram
Event trace diagram shows event flow among involved
objects to help verify object responsibilities and event flow.
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Event Flow Diagram
Selects Stay/away
Enter password
Control
panel
Homeowner
Ready for next action
Ready for activation/deactivation
System
Ready
Beep sounded
Sensors activated/deactivated
Red light on
Indicates beep
Activate/deactivate sensors
Red light request
System
Event flow diagram shows input and output events for
each object involved in the represented use-case.
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Writing the Software Specifications
Everyone knew exactly
what had to be done
until someone wrote it
down!
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Specifications Guidelines - 1
- Use a layered format that provides increasing detail as "layers"
deepen.
- Use consistent graphical notation and apply textual terms
consistently (stay away from aliases).
- Be sure to define all acronyms.
- Be sure to include a table of contents; ideally, include an index
and/or a glossary.
- Write in a simple, unambiguous style (see "editing suggestions"
on the following slide).
- Always put yourself in the reader's position, "Would I be able to
understand this if I wasn't intimately familiar with the system?“
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Specifications Guidelines - 2
- Be on the lookout for persuasive connectors, ask why?
keys: certainly, therefore, clearly, obviously, it follows that ...
- Watch out for vague terms.
keys: some, sometimes, often, usually,ordinarily, most, mostly ...
- When incomplete lists are given, be sure all items are understood.
keys: etc., and so forth, and so on, such as
- Be sure stated ranges don't contain unstated assumptions.
e.g., Valid codes range from 10 to 100. Integer? Real? Hex?
- Beware of vague verbs such as handled, rejected, processed, ...
- Beware "passive voice" statements.
e.g., The parameters are initialized. By what?
- Beware "dangling" pronouns.
e.g., The I/O module communicated with the data validation module
and its control flag is set. Whose control flag?
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Specifications Guidelines - 3
- When a term is explicitly defined in one place, try substituting the
definition for other occurrences of the term.
- When a structure is described in words, draw a picture.
- When a structure is described with a picture, try to redraw the picture
to emphasize different elements of the structure.
- When symbolic equations are used, try expressing their meaning
in words.
- When a calculation is specified, work at least two examples.
- Look for statements that imply certainty, then ask for proof (e.g.,
always, every, all, none, never).
- Search behind certainty statements. Be sure restrictions or limitations
are realistic.
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Your Class Project - SRS Document - 1
First draft: Use-Case and Class modeling (3/3/09)
Final draft: Object and Behavior modeling (3/17/09)
High expectation: completeness, quality, and professionalism.
Must include:
- 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 analysis
classes, draw “conceptual” UML class inheritance diagram showing
relationships among classes, and provide class descriptions in table
format.
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Your Class Project - SRS Document - 2
- Sequence Diagrams
Draw UML sequence diagram for each use-case. Derived from
“Event Flow” section of use-case descriptions.
- Object Collaboration Modeling
Draw UML object collaboration diagram(s) to show how objects
interact with each other. Interactions are based on methods
invocations among objects.
- Object Behavior Modeling
Draw UML state diagram(s) for the system to show what events
make the system transition from one state to another. States are
derived from actions performed classes.
See Chapter 8 slides and “SRS Components” handout on the website.
Use project requirements template posted on the website.
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Suggested Problems
Consider working the following problems from chapter 8
(textbook, page 224) for review purpose:
8.1, 8.2, 8.4, 8.5, 8.6, 8.7, 8.8, 8.11, 8.17, and 8.19
NO submission is required. Work them for yourself!