52
1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Chapter 8 Analysis Analysis Modeling Modeling

1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

  • View
    228

  • Download
    4

Embed Size (px)

Citation preview

Page 1: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

1SWE311_Ch08 (071) Software & Software Engineering

Chapter 8Chapter 8Analysis ModelingAnalysis Modeling

Page 2: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

2SWE311_Ch08 (071) Software & Software Engineering

Analysis Model ObjectivesAnalysis Model Objectives

Describe what the customer requires. Describe what the customer requires.

Establish a basis for the creation of a software design. Establish a basis for the creation of a software design.

Devise a set of requirements that can be validated once the Devise a set of requirements that can be validated once the software is built.software is built.

Page 3: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

3SWE311_Ch08 (071) Software & Software Engineering

Analysis Model GuidelinesAnalysis Model Guidelines Analysis products must be highly maintainable, especially the software Analysis products must be highly maintainable, especially the software

requirements specification. requirements specification.

Problems of size must be dealt with using an effective method of Problems of size must be dealt with using an effective method of partitioning. partitioning.

Graphics should be used whenever possible. Graphics should be used whenever possible.

Differentiate between the logical (essential) and physical (implementation) Differentiate between the logical (essential) and physical (implementation) considerations. considerations.

Find something to help with requirements partitioning and document the Find something to help with requirements partitioning and document the partitioning before specification. partitioning before specification.

Devise a way to track and evaluate user interfaces. Devise a way to track and evaluate user interfaces.

Devise tools that describe logic and policy better than narrative text. Devise tools that describe logic and policy better than narrative text.

Page 4: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

4SWE311_Ch08 (071) Software & Software Engineering

Requirements AnalysisRequirements Analysis Requirements analysis Requirements analysis

specifies software’s operational characteristicsspecifies software’s operational characteristics

indicates software's interface with other system elements indicates software's interface with other system elements

establishes constraints that software must meetestablishes constraints that software must meet

Requirements analysis allows the software engineer (called an Requirements analysis allows the software engineer (called an analystanalyst or or modelermodeler in this role) to: in this role) to: elaborate on basic requirements established during earlier requirement elaborate on basic requirements established during earlier requirement

engineering tasksengineering tasks

build models that depict user scenarios, functional activities, problem build models that depict user scenarios, functional activities, problem classes and their relationships, system and class behavior, and the flow classes and their relationships, system and class behavior, and the flow of data as it is transformed. of data as it is transformed.

Page 5: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

5SWE311_Ch08 (071) Software & Software Engineering

A BridgeA Bridge

system description

analysis model

design model

Page 6: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

6SWE311_Ch08 (071) Software & Software Engineering

Analysis Model Rules of ThumbAnalysis Model Rules of Thumb The model should focus on requirements that are visible The model should focus on requirements that are visible

within the problem or business domain. The level of within the problem or business domain. The level of abstraction should be relatively high. abstraction should be relatively high.

Each element of the analysis model should add to an overall Each element of the analysis model should add to an overall understanding of software requirements and provide insight understanding of software requirements and provide insight into the information domain, function and behavior of the into the information domain, function and behavior of the system.system.

Delay consideration of infrastructure and other non-Delay consideration of infrastructure and other non-functional models until design. functional models until design.

Minimize coupling throughout the system. Minimize coupling throughout the system. Be certain that the analysis model provides value to all Be certain that the analysis model provides value to all

stakeholders. stakeholders. Keep the model as simple as it can be. Keep the model as simple as it can be.

Page 7: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

7SWE311_Ch08 (071) Software & Software Engineering

Object-Oriented ConceptsObject-Oriented Concepts

Must be understood to apply class-based elements of Must be understood to apply class-based elements of the analysis modelthe analysis model

Key concepts:Key concepts: Classes and objectsClasses and objects

Attributes and operationsAttributes and operations

Encapsulation and instantiationEncapsulation and instantiation

InheritanceInheritance

Page 8: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

8SWE311_Ch08 (071) Software & Software Engineering

What is a Class?What is a Class?

external entities

things

occurrences roles

organizational units

places

structures

class name

attributes:

operations:

Page 9: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

9SWE311_Ch08 (071) Software & Software Engineering

ClassesClasses• object-oriented thinking begins with the definition object-oriented thinking begins with the definition

of a of a class,class, often defined as: often defined as:– templatetemplate

– generalized descriptiongeneralized description

– “ “blueprint” ... describing a collection of similar itemsblueprint” ... describing a collection of similar items

• a a metaclassmetaclass (also called a (also called a superclasssuperclass) establishes a ) establishes a hierarchy of classeshierarchy of classes

• once a class of items is defined, a specific once a class of items is defined, a specific instance of the class can be identified instance of the class can be identified

Page 10: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

10SWE311_Ch08 (071) Software & Software Engineering

Class DiagramsClass Diagrams

A class diagram defines the classes of objects in the system, A class diagram defines the classes of objects in the system, the attributes and operations of the classes, and the the attributes and operations of the classes, and the relationships between classes.relationships between classes.

Page 11: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

11SWE311_Ch08 (071) Software & Software Engineering

ObjectsObjects

An object is a concept, abstraction, or thing with well-defined An object is a concept, abstraction, or thing with well-defined boundaries and meaning for an application. boundaries and meaning for an application.

An object represents an entity, either real-world or conceptual.An object represents an entity, either real-world or conceptual.

In the UML, an object is represented as a rectangle, and the In the UML, an object is represented as a rectangle, and the name of the object is underlined.name of the object is underlined.

Object Name

Page 12: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

12SWE311_Ch08 (071) Software & Software Engineering

Building a ClassBuilding a Class

class name

attributes:

operations:

attributes:

operations

Page 13: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

13SWE311_Ch08 (071) Software & Software Engineering

ClassesClasses

A class is a description of a group of objects with common A class is a description of a group of objects with common properties (attributes), and common behavior (operations).properties (attributes), and common behavior (operations).

In the UML, a class is represented as a compartmentalized In the UML, a class is represented as a compartmentalized rectangle.rectangle.

Class Name

Attributes

Operations

Page 14: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

14SWE311_Ch08 (071) Software & Software Engineering

Encapsulation/HidingEncapsulation/HidingThe object encapsulatesboth data and the logicalprocedures required tomanipulate the data

Achieves “information hiding”

method # 1

data

method # 2

method # 4

method # 5

method # 6

method # 3

Page 15: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

15SWE311_Ch08 (071) Software & Software Engineering

MethodsMethods(Operations, Services)(Operations, Services)

An executable procedure that is encapsulated in a class and is designed to operate on one or more data attributes that are defined as part of the class.A method is invoked via message passing.

Page 16: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

16SWE311_Ch08 (071) Software & Software Engineering

Relationships between ClassesRelationships between Classes

AssociationAssociation

Aggregation and compositionAggregation and composition

Generalization/specializationGeneralization/specialization

Page 17: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

17SWE311_Ch08 (071) Software & Software Engineering

Association between ClassesAssociation between Classes

An An associationassociation defines a relationship between two or more defines a relationship between two or more classes.classes. Example: Student Example: Student Works onWorks on CourseProject CourseProject

Page 18: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

18SWE311_Ch08 (071) Software & Software Engineering

Multiplicity of AssociationsMultiplicity of Associations The The multiplicitymultiplicity of an association specifies how many of an association specifies how many

instances of one class may relate to a single instance of instances of one class may relate to a single instance of another class.another class.

Examples: one-to-one, one-to-many, many-to-many, Examples: one-to-one, one-to-many, many-to-many, numerically specified association, etc.numerically specified association, etc.

Page 19: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

19SWE311_Ch08 (071) Software & Software Engineering

Association ClassesAssociation Classes An An association classassociation class is a class that models an association is a class that models an association

between two or more classes.between two or more classes.

It is most useful in many-to-many associations.It is most useful in many-to-many associations.

The attributes of the association class are the attributes of the The attributes of the association class are the attributes of the association.association.

Page 20: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

20SWE311_Ch08 (071) Software & Software Engineering

Aggregation RelationshipsAggregation Relationships IS-PART-OF relationshipsIS-PART-OF relationships

Page 21: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

21SWE311_Ch08 (071) Software & Software Engineering

Composition RelationshipsComposition Relationships Composition is a stronger type of aggregationComposition is a stronger type of aggregation

The The partpart objects are created, live, and die together with the objects are created, live, and die together with the whole.whole.

Page 22: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

22SWE311_Ch08 (071) Software & Software Engineering

Generalization/Specialization RelationshipsGeneralization/Specialization Relationships

IS-A relationshipsIS-A relationships

Page 23: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

23SWE311_Ch08 (071) Software & Software Engineering

Class HierarchyClass Hierarchy

ChairTable Desk ”Chable"

instances of Chair

PieceOfFurniture (superclass)

subclasses of the

Page 24: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

24SWE311_Ch08 (071) Software & Software Engineering

Class-Based ModelingClass-Based Modeling

Identify analysis classes by examining the problem Identify analysis classes by examining the problem statementstatement

Use a “grammatical parse” to isolate potential classesUse a “grammatical parse” to isolate potential classes Identify the attributes of each classIdentify the attributes of each class Identify operations that manipulate the attributesIdentify operations that manipulate the attributes

Page 25: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

25SWE311_Ch08 (071) Software & Software Engineering

Analysis ClassesAnalysis Classes External entitiesExternal entities (e.g., other systems, devices, people) that produce or consume (e.g., other systems, devices, people) that produce or consume

information to be used by a computer-based system.information to be used by a computer-based system. ThingsThings (e.g, reports, displays, letters, signals) that are part of the information (e.g, reports, displays, letters, signals) that are part of the information

domain for the problem.domain for the problem. Occurrences or eventsOccurrences or events (e.g., a property transfer or the completion of a series of (e.g., a property transfer or the completion of a series of

robot movements) that occur within the context of system operation.robot movements) that occur within the context of system operation. RolesRoles (e.g., manager, engineer, salesperson) played by people who interact with (e.g., manager, engineer, salesperson) played by people who interact with

the system.the system. Organizational unitsOrganizational units (e.g., division, group, team) that are relevant to an (e.g., division, group, team) that are relevant to an

application.application. PlacesPlaces (e.g., manufacturing floor or loading dock) that establish the context of the (e.g., manufacturing floor or loading dock) that establish the context of the

problem and the overall function of the system.problem and the overall function of the system. StructuresStructures (e.g., sensors, four-wheeled vehicles, or computers) that define a class (e.g., sensors, four-wheeled vehicles, or computers) that define a class

of objects or related classes of objects.of objects or related classes of objects.

Page 26: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

26SWE311_Ch08 (071) Software & Software Engineering

Selecting Classes—CriteriaSelecting Classes—Criteria

needed servicesneeded services

multiple attributesmultiple attributes

common attributescommon attributes

common operationscommon operations

essential requirementsessential requirements

retained informationretained information

Page 27: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

27SWE311_Ch08 (071) Software & Software Engineering

Class DiagramClass DiagramSystem

program() display() reset() query() modify() call()

systemID verificationPhoneNumber systemStatus delayTime telephoneNumber masterPassword temporaryPassword numberTries

Class name

attributes

operations

Page 28: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

28SWE311_Ch08 (071) Software & Software Engineering

Class DiagramClass DiagramFloorPlan

determineType () positionFloorplan scale() change color()

type name outsideDimensions

Camera

determineType () translateLocation () displayID() displayView() displayZoom()

type ID location fieldView panAngle ZoomSetting

WallSegment

type startCoordinates stopCoordinates nextWallSement

determineType () draw()

Window

type startCoordinates stopCoordinates nextWindow

determineType () draw()

is placed within

Wall

type wallDimensions

determineType () computeDimensions ()

Door

type startCoordinates stopCoordinates nextDoor

determineType () draw()

is part of

is used to buildis used to build

is used to build

Page 29: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

29SWE311_Ch08 (071) Software & Software Engineering

Class TypesClass Types Entity classesEntity classes, also called, also called model model or or businessbusiness classes, are extracted classes, are extracted

directly from the statement of the problem (e.g., FloorPlan and Sensor). directly from the statement of the problem (e.g., FloorPlan and Sensor).

Boundary classesBoundary classes are used to create the interface (e.g., interactive are used to create the interface (e.g., interactive screen or printed reports) that the user sees and interacts with as the screen or printed reports) that the user sees and interacts with as the software is used. software is used.

Controller classesController classes manage a “unit of work” [UML03] from start to manage a “unit of work” [UML03] from start to finish. That is, controller classes can be designed to manage finish. That is, controller classes can be designed to manage

the creation or update of entity objects; the creation or update of entity objects;

the instantiation of boundary objects as they obtain information from entity the instantiation of boundary objects as they obtain information from entity objects; objects;

complex communication between sets of objects; complex communication between sets of objects;

validation of data communicated between objects or between the user and validation of data communicated between objects or between the user and the application. the application.

Page 30: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

30SWE311_Ch08 (071) Software & Software Engineering

ResponsibilitiesResponsibilities

System intelligence should be distributed across classes to best System intelligence should be distributed across classes to best address the needs of the problemaddress the needs of the problem

Each responsibility should be stated as generally as possibleEach responsibility should be stated as generally as possible

Information and the behavior related to it should reside within Information and the behavior related to it should reside within the same classthe same class

Information about one thing should be localized with a single Information about one thing should be localized with a single class, not distributed across multiple classes.class, not distributed across multiple classes.

Responsibilities should be shared among related classes, when Responsibilities should be shared among related classes, when appropriate. appropriate.

Page 31: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

31SWE311_Ch08 (071) Software & Software Engineering

Example: Class DiagramExample: Class Diagram

Page 32: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

32SWE311_Ch08 (071) Software & Software Engineering

Scenario-Based ModelingScenario-Based Modeling

““[Use-cases] are simply an aid to defining what [Use-cases] are simply an aid to defining what exists outside the system (actors) and what exists outside the system (actors) and what should be performed by the system (use-cases).” should be performed by the system (use-cases).” Ivar JacobsonIvar Jacobson

(1) What should we write about?(1) What should we write about?

(2) How much should we write about it?(2) How much should we write about it?

(3) How detailed should we make our description? (3) How detailed should we make our description?

(4) How should we organize the description?(4) How should we organize the description?

Page 33: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

33SWE311_Ch08 (071) Software & Software Engineering

Use-Use-CasesCases

a scenario that describes a “thread of a scenario that describes a “thread of usage” for a systemusage” for a system

actorsactors represent roles people or devices represent roles people or devices play as the system functionsplay as the system functions

usersusers can play a number of different roles can play a number of different roles for a given scenariofor a given scenario

Page 34: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

34SWE311_Ch08 (071) Software & Software Engineering

Developing a Use-CaseDeveloping a Use-Case

What are the main tasks or functions that are What are the main tasks or functions that are performed by the actor?performed by the actor?

What system information will the the actor acquire, What system information will the the actor acquire, produce or change?produce or change?

Will the actor have to inform the system about Will the actor have to inform the system about changes in the external environment?changes in the external environment?

What information does the actor desire from the What information does the actor desire from the system?system?

Does the actor wish to be informed about unexpected Does the actor wish to be informed about unexpected changes?changes?

Page 35: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

35SWE311_Ch08 (071) Software & Software Engineering

Use-Case DiagramUse-Case Diagram

homeowner

Access camera surveillance via the

Internet

Configure SafeHome system parameters

Set alarm

cameras

SafeHome

Page 36: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

36SWE311_Ch08 (071) Software & Software Engineering

Activity DiagramActivity DiagramSupplements the use-case by providing a diagrammatic representation Supplements the use-case by providing a diagrammatic representation of procedural flowof procedural flow

enter password and user ID

select major function

valid passwords/ ID

prompt for reentry

invalid passwords/ ID

input tries remain

no inputtries remain

select surveillance

other functions may also be

selected

thumbnail views select a specif ic camera

select camera icon

prompt for another view

select specific camera - thumbnails

exit this function see another camera

view camera output in labelled window

Page 37: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

37SWE311_Ch08 (071) Software & Software Engineering

Swimlane DiagramsSwimlane Diagrams

Allows the modeler to Allows the modeler to represent the flow of represent the flow of activities described by the activities described by the use-case and at the same time use-case and at the same time indicate which actor (if there indicate which actor (if there are multiple actors involved are multiple actors involved in a specific use-case) or in a specific use-case) or analysis class has analysis class has responsibility for the action responsibility for the action described by an activity described by an activity rectanglerectangle

enter password and user ID

select major function

valid passwords/ ID

prompt for reentry

invalidpasswords/ ID

input tries

remain

no input

tries remain

select surveillance

other functions may also be

selected

thumbnail views select a specif ic camera

select camera icon

generate video output

select specific camera - thumbnails

exit thisfunction

see

anothercamera

homeowner c amera int erf ac e

prompt foranother view

view camera output in labelled window

Page 38: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

38SWE311_Ch08 (071) Software & Software Engineering

Class-Responsibility-Collaborator Class-Responsibility-Collaborator (CRC) Modeling(CRC) Modeling

Analysis classes have “responsibilities”Analysis classes have “responsibilities” ResponsibilitiesResponsibilities are the attributes and operations encapsulated by the are the attributes and operations encapsulated by the

classclass

Analysis classes collaborate with one anotherAnalysis classes collaborate with one another CollaboratorsCollaborators are those classes that are required to provide a class are those classes that are required to provide a class

with the information needed to complete a responsibility. with the information needed to complete a responsibility. In general, a collaboration implies either a request for information or a In general, a collaboration implies either a request for information or a

request for some action.request for some action.

Page 39: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

39SWE311_Ch08 (071) Software & Software Engineering

CRC ModelingCRC Modeling

Class:

Description:

Responsibility: Collaborator:

Class:

Description:

Responsibility: Collaborator:

Class:

Description:

Responsibility: Collaborator:

Class: FloorPlan

Description:

Responsibility: Collaborator:

incorporates walls, doors and windows

shows position of video cameras

defines floor plan name/type

manages floor plan positioning

scales floor plan for display

scales floor plan for display

Wall

Camera

Page 40: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

40SWE311_Ch08 (071) Software & Software Engineering

Reviewing the CRC ModelReviewing the CRC Model All participants in the review (of the CRC model) are given a subset of the CRC model index All participants in the review (of the CRC model) are given a subset of the CRC model index

cards.cards.

Cards that collaborate should be separated (i.e., no reviewer should have two cards that Cards that collaborate should be separated (i.e., no reviewer should have two cards that collaborate).collaborate).

All use-case scenarios (and corresponding use-case diagrams) should be organized into All use-case scenarios (and corresponding use-case diagrams) should be organized into categoriescategories..

The review leader reads the use-case deliberatelyThe review leader reads the use-case deliberately.. As the review leader comes to a named object, she passes a token to the person holding As the review leader comes to a named object, she passes a token to the person holding

the corresponding class index card.the corresponding class index card. When the token is passed, the holder of the class card is asked to describe the responsibilities When the token is passed, the holder of the class card is asked to describe the responsibilities

noted on the cardnoted on the card.. The group determines whether one (or more) of the responsibilities satisfies the use-case The group determines whether one (or more) of the responsibilities satisfies the use-case

requirement.requirement. If the responsibilities and collaborations noted on the index cards cannot accommodate the use-If the responsibilities and collaborations noted on the index cards cannot accommodate the use-

case, modifications are made to the cardscase, modifications are made to the cards.. This may include the definition of new classes (and corresponding CRC index cards) or 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.the specification of new or revised responsibilities or collaborations on existing cards.

Page 41: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

41SWE311_Ch08 (071) Software & Software Engineering

Analysis PackagesAnalysis Packages

Various elements of the analysis model (e.g., use-cases, analysis classes) Various elements of the analysis model (e.g., use-cases, analysis classes) are categorized in a manner that packages them as a groupingare categorized in a manner that packages them as a grouping

The plus sign preceding the analysis class name in each package indicates The plus sign preceding the analysis class name in each package indicates that the classes have public visibility and are therefore accessible from that the classes have public visibility and are therefore accessible from other packages.other packages.

Other symbols can precede an element within a package. Other symbols can precede an element within a package. A minus sign indicates that an element is hidden from all other packages A minus sign indicates that an element is hidden from all other packages

and and a # symbol indicates that an element is accessible only to packages a # symbol indicates that an element is accessible only to packages

contained within a given package.contained within a given package.

Page 42: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

42SWE311_Ch08 (071) Software & Software Engineering

Analysis PackagesAnalysis Packages

Environment

+Tree+Landscape+Road+Wall+Bridge+Building+VisualEffect+Scene

Characters

+Player+Protagonist+Antagonist+SupportingRole

RulesOfTheGame

+RulesOfMovement+ConstraintsOnAction

package name

Page 43: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

43SWE311_Ch08 (071) Software & Software Engineering

Behavioral ModelingBehavioral Modeling

The behavioral model indicates how software will respond to external The behavioral model indicates how software will respond to external events or stimuli. To create the model, the analyst must perform the events or stimuli. To create the model, the analyst must perform the following steps:following steps:

Evaluate all use-cases to fully understand the sequence of interaction within the Evaluate all use-cases to fully understand the sequence of interaction within the system.system.

Identify events that drive the interaction sequence and understand how these events Identify events that drive the interaction sequence and understand how these events relate to specific objects.relate to specific objects.

Create a sequence for each use-case.Create a sequence for each use-case.

Build a state diagram for the system.Build a state diagram for the system.

Review the behavioral model to verify accuracy and consistency.Review the behavioral model to verify accuracy and consistency.

Page 44: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

44SWE311_Ch08 (071) Software & Software Engineering

State RepresentationsState Representations

In the context of behavioral modeling, two different In the context of behavioral modeling, two different characterizations of states must be considered: characterizations of states must be considered: the state of each class as the system performs its function andthe state of each class as the system performs its function and the state of the system as observed from the outside as the system the state of the system as observed from the outside as the system

performs its functionperforms its function

The state of a class takes on both passive and active The state of a class takes on both passive and active characteristics [CHA93]. characteristics [CHA93]. A A passive statepassive state is simply the current status of all of an object’s is simply the current status of all of an object’s

attributes.attributes. The The active stateactive state of an object indicates the current status of the object as of an object indicates the current status of the object as

it undergoes a continuing transformation or processing. it undergoes a continuing transformation or processing.

Page 45: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

45SWE311_Ch08 (071) Software & Software Engineering

State Diagram for the ControlPanel ClassState Diagram for the 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

Page 46: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

46SWE311_Ch08 (071) Software & Software Engineering

The States of a SystemThe States of a System statestate—a set of observable circum-stances —a set of observable circum-stances

that characterizes the behavior of a system at that characterizes the behavior of a system at a given timea given time

state transitionstate transition—the movement from one —the movement from one state to anotherstate to another

eventevent—an occurrence that causes the system —an occurrence that causes the system to exhibit some predictable form of behaviorto exhibit some predictable form of behavior

actionaction—process that occurs as a consequence —process that occurs as a consequence of making a transitionof making a transition

Page 47: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

47SWE311_Ch08 (071) Software & Software Engineering

Behavioral ModelingBehavioral Modeling

make a list of the different states of a system make a list of the different states of a system (How does the system behave?)(How does the system behave?)

indicate how the system makes a transition from indicate how the system makes a transition from one state to another (How does the system one state to another (How does the system change state?)change state?) indicate eventindicate event

indicate actionindicate action

draw a draw a state diagram or a sequence diagramstate diagram or a sequence diagram

Page 48: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

48SWE311_Ch08 (071) Software & Software Engineering

Sequence DiagramSequence 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

Page 49: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

49SWE311_Ch08 (071) Software & Software Engineering

Writing the Software SpecificationWriting the Software Specification

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

Page 50: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

50SWE311_Ch08 (071) Software & Software Engineering

Specification GuidelinesSpecification Guidelinesuse a layered format that provides increasing detail as the "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 pages) always put yourself in the reader's position, "Would I be able to understand this if I wasn't intimately familiar with the system?"

Page 51: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

51SWE311_Ch08 (071) Software & Software Engineering

Specification GuidelinesSpecification GuidelinesBe 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 lists are given, but not completed, 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 contol flag is set. Whose control flag?

Page 52: 1 SWE311_Ch08 (071) Software & Software Engineering Chapter 8 Analysis Modeling

52SWE311_Ch08 (071) Software & Software Engineering

Specification GuidelinesSpecification Guidelines

When a term is explicitly defined in one place, try substituting the definition forother 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 keys; always, every, all, none, never Search behind certainty statements—be sure restrictions or limitations are realistic