chapter 8 analysis modeling - aalborg universitetpeople.cs.aau.dk/~ivan/soe2005f/soemm6.pdf ·...

These coursew are materials are to be used in conjunction w ith Soft ware Engineering: A Pract it ioner’s Approach,6/e and are provided w ith permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 1

Software Engineering: A PractitionerSoftware Engineering: A Practitioner’’s Approach, 6/es Approach, 6/e

Chapter 8Chapter 8Analysis ModelingAnalysis Modeling

copyright © 1996, 2001, 2005

R.S. Pressman & Associates, Inc.

For University Use OnlyMay be reproduced ONLY for student use at the university level

when used in conjunction with Software Engineering: A Practitioner's Approach.Any other reproduction or use is expressly prohibited.


Requirements AnalysisRequirements Analysis

Requirements analysisRequirements analysis specifies softwarespecifies software’’s operational characteristicss operational characteristics indicates software's interface with other system elementsindicates software's interface with other system elements establishes constraints that software must meetestablishes constraints that software must meet

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

requirement engineering tasksrequirement engineering tasks build models that depict user scenarios, functional activities,build models that depict user scenarios, functional activities,

problem classes and their relationships, system and classproblem classes and their relationships, system and classbehavior, and the flow of data as it is transformed.behavior, and the flow of data as it is transformed.


A BridgeA Bridge

system

description

analysis

model

design

model


Rules of ThumbRules of Thumb The model should focus on requirements that are visible within theThe model should focus on requirements that are visible within the

problem or business domain. The level of abstraction should beproblem or business domain. The level of abstraction should berelatively high.relatively high.

Each element of the analysis model should add to an overallEach element of the analysis model should add to an overallunderstanding of software requirements and provide insight intounderstanding of software requirements and provide insight intothe information domain, function and behavior of the system.the information domain, function and behavior of the system.

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

Minimize coupling throughout the system.Minimize coupling throughout the system. Be certain that the analysis model provides value to allBe 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.


Domain AnalysisDomain Analysis

Define the domain to be investigated.Define the domain to be investigated. Collect a representative sample of applicationsCollect a representative sample of applications

in the domain.in the domain. Analyze each application in the sample.Analyze each application in the sample. Develop an analysis model for the objects.Develop an analysis model for the objects.


Data ModelingData Modeling

examines data objects independently ofexamines data objects independently ofprocessingprocessing

focuses attention on the data domainfocuses attention on the data domain creates a model at the customercreates a model at the customer’’s levels level

of abstractionof abstraction indicates how data objects relate to oneindicates how data objects relate to one

anotheranother


What is a Data Object?What is a Data Object?

ObjectObject ——something that is described by a setsomething that is described by a setof attributes (data items) and that will be of attributes (data items) and that will be manipulated within the software (system)manipulated within the software (system)

each each instanceinstance of an object (e.g., a book) of an object (e.g., a book) can be identified uniquely (e.g., ISBN #) can be identified uniquely (e.g., ISBN #)

each plays a necessary role in the systemeach plays a necessary role in the systemi.e., the system could not function without i.e., the system could not function without access to instances of the objectaccess to instances of the objecteach is described by attributes that are each is described by attributes that are themselves data itemsthemselves data items


Typical ObjectsTypical Objects

external entitiesexternal entities (printer, user, sensor)(printer, user, sensor)thingsthings (e.g, reports, displays, signals) (e.g, reports, displays, signals) occurrences or eventsoccurrences or events (e.g., interrupt, alarm)(e.g., interrupt, alarm)rolesroles (e.g., manager, engineer, salesperson)(e.g., manager, engineer, salesperson)organizational unitsorganizational units (e.g., division, team) (e.g., division, team)placesplaces (e.g., manufacturing floor) (e.g., manufacturing floor) structuresstructures (e.g., employee record)(e.g., employee record)


Data Objects and AttributesData Objects and AttributesA data object contains a set of attributes thatA data object contains a set of attributes thatact as an aspect, quality, characteristic, oract as an aspect, quality, characteristic, ordescriptor of the objectdescriptor of the object

object: automobileobject: automobileattributes:attributes: make make model model body type body type price price options code options code


What is a Relationship?What is a Relationship?

relationshiprelationship ——indicates indicates ““connectednessconnectedness””; ; a "fact" that must be "remembered" a "fact" that must be "remembered" by the system and cannot or is not computed by the system and cannot or is not computed or derived mechanicallyor derived mechanically

several instances of a relationship canseveral instances of a relationship canexistexist

objects can be related in many differentobjects can be related in many differentwaysways


ERD NotationERD Notation

(0, m) (1, 1)

objectobject objectobjectrelationshiprelationship11 22

One common form:One common form:

(0, m)(0, m)

(1, 1)(1, 1)

objectobject11 objectobject22relationshiprelationship

Another common form:Another common form:attributeattribute


Object-Oriented ConceptsObject-Oriented Concepts

Must be understood to apply class-basedMust be understood to apply class-basedelements of the analysis modelelements of the analysis model

Key concepts:Key concepts: Classes and objectsClasses and objects Attributes and operationsAttributes and operations Encapsulation and instantiationEncapsulation and instantiation InheritanceInheritance


Flow-Oriented ModelingFlow-Oriented Modeling

Represents how data objects are transformed at theyRepresents how data objects are transformed at theymove through the systemmove through the system

A A data flow diagram (DFD)data flow diagram (DFD) is the diagrammatic form is the diagrammatic formthat is usedthat is used

Considered by many to be an Considered by many to be an ‘‘old schoolold school’’ approach, flow- approach, flow-oriented modeling continues to provide a view of theoriented modeling continues to provide a view of thesystem that is uniquesystem that is unique——it should be used to supplementit should be used to supplementother analysis model elementsother analysis model elements


The Flow ModelThe Flow ModelEvery computer-based system is an Every computer-based system is an information transform ....information transform ....

computercomputerbasedbased

systemsysteminputinput outputoutput

1

Analysis Model Structure

DataObject

Description

ProcessSpecification

(PSPEC)

ControlSpecification

(CSPEC)

EntityRelationship

Diagram

Data FlowDiagram

State-TransitionDiagram

Data Dictionary

Data model

• data objects

• relationships

• ERDs

Functional model

• data transforms

• DFDs

Behavioral model

• events and states

• STDs

2

The elements: data flow

dividend

number

address

streetaddress

city

state

postcode

values can becopied

values can besplit

a data flow

3

The elements: actors

actor

an actor isa produceror a consumerof data flows

window

an actor formsa source or a sink — and issometimes termeda terminator

size location

Actors are objects

4

The elements: Data Stores

a data store is aplace where datavalues can be stored and retrievedlater

data storeData stores are objects

5

Flows

Customer

Verify

password

Update

account

amount

cash

codedpassword

balancepassword ok

6

The Functional Model: The DFD

process

externalentity

dataitem

event flow,control item

data/control store

A terminator is a producer or a consumer of data flows

number address

streetaddress

city

state

postcode

a data store is a place where data values can be stored and retrieved later

7

Nested Data Flow Diagrams

PatientNurse

Nurse

Patient monitoring

system

Patientlog

vital signs

Report

Warningmessage

Log datarequest

for report

8

Patient Monitoring System

Patient

Nurse

Nurse

LocalMonito-

ring

Patientlog

Vital signs

Report

Warningmessage

Log data

Requestfor report

CentralMonito-

ring

Updatelog

Reportgenerator

Patient bounds

Patient dataVital signsbounds

Formattedpatient data

Log data

9

Getting Started

Example

• Manufacturing cell software controls a robot by generation of position coordinates that are transmitted to the robot. An operator inputs commands that cause the manufacturing cell software to read positioning and control commands from an NC command file. Components to be assembled are held in parts fixtures that activate robot control functions once each fixture contains a part ...

Use nouns to isolate external entities, data items and stores

Use verbs to help isolate processes (bubbles)

10

Creating a Context Diagram

Level 0 Flow Model (also called a “context diagram”)

partsfixtures

operator

NC unitsoftware

robot

operator

part ID

operatorcommands

positioncoordinates

operatordisplay

NC command file

positioning andcontrol commands

11

DFD Questions

Q: How does the NC unit software transform input to output?

A: Lower DFD levels will provide details.

Q: What are "operator commands”

A: Another notional tool - the data dictionary - will help to describe.

Q: Where are processing details?

A: A PSPEC ("structured English") and other notational tools are used.

12

Refining to Level 1

monitorfixturestatus

readoperator

input

read NCblocks

producerobot

command

computeposition

data

adjustswitch

settings

NC command fileNC block

operatorcommands

part ID

operatordisplay

part priority

validatedinput

positioningand controlcommand

positioncoordinates

controlstatusdisplay

rawposition

controlcommand

parts

fixtures

operator

NC unit

software

robot

operator

part ID

operator

commands

position

coordinates

operator

display

NC command file

positioning and

control commands

13

Process & Control Models DFDs

PSPECs

CFDs

CSPECs

Process Model

Control Model

data input

data input

processactivators data

conditions

control inputcontrol output

14

Data Conditions

PSPECif absolute tank pressure > max pressure

thenset above pressure to "true”

elseset above pressure to "false";begin conversion algorithm x-Ol a;

compute converted pressure;end

endif

check &convertpressure

check &convertpressure

above pressure

Control flowData flow

maxpressure

absolute tankpressure

convertedpressure

The PSPEC can be:• narrative• PDL• equations• tables• diagrams and/or charts

15

The Control Model

• the control flow diagram is "superimposed" on the DFD and shows events that control the processes noted in the DFD

• control flows - events and control items - are noted by dashed arrows

• a vertical bar implies an input to or output from a control spec (CSPEC) - a separate specification that describes how control is handled

• a dashed arrow entering a vertical bar is an input to the CSPEC

• a dashed arrow leaving a process implies a data condition

• a dashed arrow entering a process implies a control input read directly by the process

• control flows do not physically activate/deactivate the processes - this is done via the CSPEC

16

Control Flow Diagram

repro fault

The CSPEC can be:• state transition diagram• state transition table• decision tables• activation tables

managecopying

reloadpaper perform

problemdiagnosis

readoperator

input produceuser

displays

copies done

start/stop

paper feed status(jammed, empty)

alarm

full

input to theCSPEC

output fromthe CSPEC

combinatorial spec

17

Decision Tables: example

Fixed rate account

Variable rate account

Consumption < 100 Kwh

Consumption > 150 Kwh

Minimum monthly charge

Schedule A Billing

Schedule B Billing

Other treatment

1 2 3 4 5

T T F F F

F F T T F

T F T F

F T F T

X

X X

X

X

18

The Data Dictionary

• a quasi-formal grammar for describing the content of data that the software will process and create

• a notation for describing control data and the values that control data can take, e.g., “on ,“ or “off”

• a repository that also contains “where-used” / “how used” information

• a notation that can be represented manually, but is best developed using CASE tools

19

Data Dictionary

= is composed of

+ and

() optional

{} iteration

[ | ] either - or

* ..text ...* comment

{ }n n repetitions of

( … ) delimits a comment

NAME = TITLE + {FIRST_NAME} + LAST_NAME

TITLE = [Mr.|Ms.]

FIRST_NAME = {LEGAL-CHARACTER}

FIRST_NAME = {LEGAL-CHARACTER}

LEGAL-CHARACTER = [A-Z|a-z|'|-| ]

20

Data Dictionary Example

integratedofficephonesystem

telephone number system output

Name: telephone number

Aliases: phone number, number

Where/How used: read-phone-number (input)

display-phone-number (output)

analyze-long-distance-calls (input)

Description: telephone no. = [ local extension | outside no. | 0 ]

outside no. = 9 + [ service code | domestic no. ] service code = [ 211 | 411 | 611 | 911 ] domestic no. = ( (0) + area code ) + local number area code = *three numeral designator*

Format: alphanumeric data

Build the requirements dictionary:

21

Modern Structured Analysis

An Illustration

22

Structured Analysis

The environmental model

• Statement of purpose

• Context diagram

• Event list

The behavioral model

• Data flow diagrams

• Process Specification

23

Journal administration:

The computer based system is used for administration of the information necessary to publish the Scandinavian Journal of Information Systems (SJIS). This includes registration of new subscribers, billing, mailing, and registration of subscriber data.

The Environmental ModelStatement of Purpose

! A brief, concise textual statement of the purpose of the

system.

! Clarifies the boundaries of the system - what will be

taken care of by the system, and what will not?

24

The Environmental Model Context Diagram

SJIS

Subscribers

Bookkeeping Bank

Agents

Payments

Balance

Issues

Pay- ment

Orders

Invoices

Money transfer

Terminators

New subscriber

25

1. Person or institution enters subscription.

2. Agent enters subscription on behalf of a person or institution.

3. The bank reports a money transfer.

4. Bookkeeping receives details on payments.

5. Agent cancels subscription.

6. Issue is sent to subscriber.

7. Invoice is sent to agent.

8. Invoice is sent to subscriber directly.

9. Subsciption is cancelled.

10. Subscriber pays amount due

11. .....

SJIS:

The Environmental Model Event List

A list of the "stimuli" that occur in the outside world and to which the system must respond.

26

x y

z

pStore

6

process"name"

A flow tells the system that an event has

occurred

Output to

terminator

Necessary data in order to process

data flow X

Stores data related to asynchronous and

interdependent events. Used for communication between

processes

The Behavioral Model: Dataflow

Models of Event Responses

27

SJIS: Event 10

Subscriber pays amount due

Payment

Transactions

Registrationof

payments

Subscriber

Issuing data

Subscriberdata

Bookkeeping

Debit

Termination

Subscriber file

28

Event Responses Are Combined Into

One Data flow Diagram

29

Upward Leveling of Data flow Diagrams

=

12

3

4

5

6

12

3

.6

.5

.47

Processes 4, 5, and 6 are united into a new process 7. Processes 4, 5, and 6 are pushed one level down.

30

Data Flow HierarchyF

f1

A B

f2

f3

f4 f5

f6

f7

V

W

X

Y

Z

P

Q

R

B

A

f41 f43

f44f42

f45

X

Y

Z

31

Process Specification

At the lowest level a process is described in structured

English, flowcharts or similar.

FIND Subscriber in Subscribers based on Subscriber#.IF not found: ERROR(Subscriber unknown)ELSE

FIND invoicedata for Subscriber#.IF no pending invoice:

ERROR(No pending invoice)ELSE mark invoice as paid.WRITE debitinfo to bookkeeping.

32

Tool Requirements

• Support in modeling complex and systems related problems.

• Support building correct, complete and consistent models.

• Support building a simple and understandable model of a system.

• Help balance between details and overview.

33

DFDs: A Look Ahead

Maps intoanalysis model

design model


Class-Based ModelingClass-Based Modeling

Identify analysis classes by examining theIdentify analysis classes by examining theproblem statementproblem statement

Use a Use a ““grammatical parsegrammatical parse”” to isolate potential to isolate potentialclassesclasses

Identify the attributes of each classIdentify the attributes of each class Identify operations that manipulate the attributesIdentify operations that manipulate the attributes


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 robot (e.g., a property transfer or the completion of a series of robot

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

system.system. Organizational unitsOrganizational units (e.g., division, group, team) that are relevant to an application. (e.g., division, group, team) that are relevant to an 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 of (e.g., sensors, four-wheeled vehicles, or computers) that define a class of

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


Selecting ClassesSelecting Classes——CriteriaCriteria

needed servicesneeded services

multiple attributesmultiple attributes

common attributescommon attributes

common operationscommon operations

essential requirementsessential requirements

retained informationretained information


Class DiagramClass DiagramSystem

program()

display()

reset()

query()

modify()

call()

systemID

verificationPhoneNumber

systemStatus

delayTime

telephoneNumber

masterPassword

temporaryPassword

numberTries

Class name

attributes

operations


Class DiagramClass DiagramFloorPlan

determineType()positionFloorplan

scale()change color()

typenameoutsideDimensions

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


CRC ModelingCRC Modeling

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

the classthe class

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

class with the information needed to complete a responsibility.class with the information needed to complete a responsibility.

In general, a collaboration implies either a request forIn general, a collaboration implies either a request forinformation or a request for some action.information or a request for some action.


CRC ModelingCRC Modeling

Class:

Description:

Responsibility: Collaborator:

Class:

Description:


Class:

Description:


Class: FloorPlan

Description:


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


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


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?


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

3

The Planning Game

• Business writes a story describing desired functionality

• Stories are written on index cards

• Development estimates stories

• Velocity determines number of stories per iteration

• Business splits and prioritizes stories and determines the composition of releases

• Velocity is measured and adjusted every iteration

• Customer steers development

4

Planning Game

User stories = lightweight use cases

2-3 sentences on a file card that:

• The customer cares about

• Can be reasonably tested

• Can be estimated & prioritized

5

Stories are promises for Conversation

• Stories are made up of two components

• The written card

• The series of conversations

• Between customer and programmers

• The conversation will be captured as additional documentation that will be attached to the story

• Design sessions

• Acceptance tests

• Application code

6

Sample Stories (from XP Installed)

7

... Sometimes we need to split a story

chapter 8 analysis modeling - aalborg universitetpeople.cs.aau.dk/~ivan/soe2005f/soemm6.pdf ·...

Documents