Download ppt - CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Chapter 8 Class will start momentarily. Please Stand By … CS 8532: Advanced Software Engineering

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


Analysis Modeling

Part II

Elements and methods of analysis modeling

Chapter 8


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.


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.


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:


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.


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.


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)


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.


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.


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.


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.


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.


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.



Generalization -Specialization



Composite -Aggregates



Package


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.



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.



Object Relationships


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


Dependency

CameraDisplayWindow

{password}

<<access>>

Figure 8.18, Page 215


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.


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.


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.


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).


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).


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


Sequence Diagram

homeowner control panel sensorssystem sensors

system ready

reading

request lookupcomparing

result

password entered

password = correctrequest activation


lockednumberOfTries > maxTries

selecting

timer > lockedTimeA

A

Figure 8.27 Sequence diagram (partial) for SafeHome security function


Figure 8.21

page 220


State Diagram


Event Trace Diagram

Event trace diagram shows event flow among involved objects to help verify object responsibilities and event flow.


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.


Writing the Software Specifications

Everyone knew exactly what had to be done until someone wrote it down!


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?“



- 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?



- 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.


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.


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


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!