cs 8532: adv. software eng. – spring 2007 dr. hisham haddad chapter 8 class will start...
TRANSCRIPT
CS 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
Chapter 8
Class will
start momentarily.
Please Stand By …
CS 8532: Advanced Software Engineering
Dr. Hisham Haddad
CS 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
Analysis Modeling
Part II
Elements and methods of analysis modeling
Chapter 8
CS 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
Section 8.7: Class-Based 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 the revised SRS template on the website.
CS 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
Analysis Classes• 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 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
CRC Modeling
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 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
Selecting 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 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
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 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
Defining 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 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
Defining 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 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
Identifying 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 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
Identifying 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 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
Reviewing the CRC Model - 1Reviewing 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 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
Reviewing the CRC Model - 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 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
Class Hierarchy Diagram - 1
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 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
Class Hierarchy Diagram - 2
Generalization -Specialization
CS 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
Class Hierarchy Diagram - 3
Composite -Aggregates
CS 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
Class Hierarchy Diagram - 4
Package
CS 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
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 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
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 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
Object Relationship Modeling - 3
Object Relationships
CS 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
Multiplicity
WallSegment Window Door
Wall
is used to buildis used to build
is used to build1..*
1 1 1
0..* 0..*
Figure 8.17
page 215
CS 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
Dependency
CameraDisplayWindow
{password}
<<access>>
Figure 8.18, Page 215
CS 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
Section 8.8: Behavior Modeling(for OO Analysis)
Like Structured Analysis modeling, object behavior modeling represents the dynamic view of the system (i.e., system responses to external events).
Unlike Structured Analysis behavior modeling, 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 the revised SRS template on the website.
CS 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
Object Behavior Modeling - 1
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 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
Object Behavior Modeling - 2
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 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
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 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
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 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
State Diagram for ControlPanel Class
reading
locked
selecting
password entered
comparing
password = incorrect & numberOfTries < maxTries
password = correct
activation successful
key hit
do: validatePassword
numberOfTries > maxTries
timer < lockedTime
timer > lockedTime
Figure 8.20
page 219
CS 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
Sequence Diagram
homeowner control panel sensorssystem sensors
system ready
reading
request lookupcomparing
result
password entered
password = correctrequest activation
activation successful
lockednumberOfTries > maxTries
selecting
timer > lockedTimeA
A
Figure 8.27 Sequence diagram (partial) for SafeHome security function
activation successful
Figure 8.21
page 220
CS 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
State Diagram
CS 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
Event Trace Diagram
Event trace diagram shows event flow among involved objects to help verify object responsibilities and event flow.
CS 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
Event Flow Diagram
Homeowner
SystemReady
System
Ready for next actionReady for activation/deactivation
Beep soundedSensors activated/deactivated
Red light on
Controlpanel
Selects Stay/awayEnter password
Indicates beepActivate/deactivate sensorsRed light request
Event flow diagram shows input and output events for each object involved in the represented use-case.
CS 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
Writing the Software Specifications
Everyone knew exactly what had to be done until someone wrote it down!
CS 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
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 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
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 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
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 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
Your Project - SRS Document - 1Due Friday 3/16/2007, by 5:00PM.
High expectation of 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 classes, draw “conceptual” UML class inheritance diagram showing
relationships among classes, and provide class descriptions in table format.
CS 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
SRS Document - 2
- Object Collaboration Modeling Draw UML object collaboration diagrams to show how objects
interact with each other. Interactions are based on methods invocations among objects.
- 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.
See Chapter 8 slides and “SRS Components” handout on the website. Use the revised SRS template posted on the website
CS 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad
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!