Sw Engg L5 Analysis Models1

8/8/2019 Sw Engg L5 Analysis Models1

http://slidepdf.com/reader/full/sw-engg-l5-analysis-models1 1/60

1

IT607IT607 -- Software EngineeringSoftware Engineering

Kavi AryaKavi Arya

KReSIT, IITKReSIT, IIT--BombayBombay



2

Analysis ModelingAnalysis Modeling

Adapted from ³Software Engineering: A Practitioner¶s Approach, 6/e´ Adapted from ³Software Engineering: A Practitioner¶s Approach, 6/e´



3

Requirements AnalysisRequirements Analysis

Requirements analysisRequirements analysis specifies software¶s operational characteristicsspecifies software¶s 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 engineer Requirements analysis allows the software engineer

(called an(called an analyst analyst or or modeler modeler in this role) to:in this role) to: elaborate on basic requirements established during earlier elaborate 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 class

behavior, and the flow of data as it is transformed.behavior, and the flow of data as it is transformed.



A BridgeA Bridge

te

de cripti

l idel

de ig

del



5

Rules of ThumbRules of Thumb

The model should focus on requirements that are visibleThe model should focus on requirements that are visiblewithin 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 overallEach element of the analysis model should add to an overallunderstanding of software requirements and provide insightunderstanding of software requirements and provide insightinto the information domain, function and behavior of theinto the information domain, function and behavior of thesystem.system.

Delay consideration of infrastructure and other nonDelay 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 allBe certain that the analysis model provides value to allstakeholders.stakeholders.

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



6

Domain AnalysisDomain Analysis

Software domain analysis is the identification, analysis,Software domain analysis is the identification, analysis,

and specification of common requirements from aand specification of common requirements from a

specific application domain, typically for reuse onspecific application domain, typically for reuse on

multiple projects within that application domain . . .multiple projects within that application domain . . .

[Object[Object--oriented domain analysis is] the identification,oriented domain analysis is] the identification,analysis, and specification of common, reusableanalysis, and specification of common, reusable

capabilities within a specific application domain, incapabilities within a specific application domain, in

terms of common objects, classes, subassemblies, andterms of common objects, classes, subassemblies, and

frameworks . . .frameworks . . .

D onald Firesmith



7

Domain AnalysisDomain Analysis

Define the domain to be investigated.Define the domain to be investigated.

Collect a representative sample of applications inCollect a representative sample of applications in

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



8

Data ModelingData Modeling

examines data objects independently of examines data objects independently of

processingprocessing

focuses attention on the data domainfocuses attention on the data domain creates a model at the customer¶s levelcreates a model at the customer¶s level

of abstractionof abstraction

indicates how data objects relate to oneindicates how data objects relate to one

another another



9

What is a Data Obje t?What is a Data Obje t?

Obj ect Obj ect ²²something that is described by a setsomething that is described by a setof attributes (data items) and that will beof attributes (data items) and that will bemanipulated within the software (system)manipulated within the software (system)

eacheach 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 withouti.e., the system could not function withoutaccess to instances of the objectaccess to instances of the object

each is described by attributes that areeach is described by attributes that arethemselves data itemsthemselves data items



10

Ty i al Obje tsTy i al Obje tsexternal 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)

places places (e.g., manufacturing floor)(e.g., manufacturing floor)

structuresstructures (e.g., employee record)(e.g., employee record)



11

Data Obje ts and AttributesData Obje ts and Attributes A data object contains a set of attributes that A data object contains a set of attributes that

act as an aspect, quality, characteristic, or act as an aspect, quality, characteristic, or

descriptor of the objectdescriptor of the object

obje t: automobileobje t: automobileattributes:attributes:

makemakemodelmodelbody ty ebody ty e

ri eri eo tions odeo tions ode



12

What is a Relationshi ?What is a Relationshi ?relationshiprelationship ²²indicates ³connectedness´;indicates ³connectedness´;a "fact" that must be "remembered"a "fact" that must be "remembered"by the system and cannot or is not computedby the system and cannot or is not computed

or derived mechanicallyor derived mechanically

several instances of a relationship canseveral instances of a relationship can

existexist

objects can be related in many differentobjects can be related in many different

waysways



13

ERD NotationERD Notation

(0, m) (1, 1)

obje tobje t obje tobje trelationshirelationshi11 22

One common form:One common form:

(0, m)(0, m)

(1, 1)(1, 1)

obje tobje t11 obje tobje t22

relationshirelationshi

Another common form: Another common form:

attributeattribute



14

Building an ERDBuilding an ERD

Level 1Level 1²²model all data objects (entities) and their model all data objects (entities) and their

³connections´ to one another ³connections´ to one another Level 2Level 2²²model all entities and relationshipsmodel all entities and relationships

Level 3Level 3²²model all entities, relationships, and themodel all entities, relationships, and the

attributes that provide further depthattributes that provide further depth



15

The ERD: An Exam leThe ERD: An Exam le

(1,1)(1,1) (1,m)(1,m)la esla esCustomer Customer

requestrequestfor servi efor servi e

generatesgenerates (1,n)(1,n)

(1,1)(1,1)

workworkorder order

workworktaskstasks

materialsmaterials

onsistsonsistsof of

listslists

(1,1)(1,1)(1,w)(1,w)

(1,1)

(1,i)(1,i)

sele tedsele tedfromfrom

standardstandardtask tabletask table

(1,w)(1,w)

(1,1)(1,1)



16

Obje tObje t--Oriented Con e tsOriented Con e ts

Must be understood to apply classMust be understood to apply class--basedbased

elements of the analysis modelelements of the analysis model

Key concepts:Key concepts:

Classes and objectsClasses and objects

Attributes and operations Attributes and operations

Encapsulation and instantiationEncapsulation and instantiation

InheritanceInheritance



17

ClassesClasses

objectobject--oriented thinking begins with theoriented thinking begins with thedefinition of adefinition of a class,class, often defined as:often defined as: ± ± templatetemplate

± ± generalized descriptiongeneralized description

± ±

³blueprint´ ... describing a collection of ³blueprint´ ... describing a collection of similar itemssimilar items

aa metaclassmetaclass (also called a(also called a superclasssuperclass))establishes a hierarchy of classesestablishes a hierarchy of classes

once a class of items is defined, aonce a class of items is defined, a

specific instance of the class can bespecific instance of the class can beidentifiedidentified



18

Building a ClassBuilding a Class

class name

attributes:

operations:

attributes:

operations



19

What is a Class?What is a Class?

external entities

things

occurrenc es roles

organizational units

plac es

str uc tures

c lass name

attributes:

operations:



20

En a sulation/HidingEn a sulation/Hiding

The 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



21

Class Hierar hyClass Hierar hy

Chair Table Desk ´Chable"

instanc es of Chair

Piec eOfFurniture (super c lass)

subc lasses of the



22

MethodsMethods

(a.k.a. O erations, Servi es)(a.k.a. O erations, Servi es) An executable proc edure that is enc apsulated in a c lass and is designed to operate on one or more data attributes that are defined as part of the c lass.

A method is invoked via message passing.



23

S enarioS enario--Based ModelingBased Modeling

³[Use³[Use--cases] are simply an aid to defining what existscases] are simply an aid to defining what exists

outside the system (actors) and what should beoutside the system (actors) and what should be

performed by the system (useperformed by the system (use--cases).´ Ivar Jacobsoncases).´ Ivar 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?



24

UseUse--CasesCases

a scenario that describes a ³thread of usage´ for a scenario that describes a ³thread of usage´ for

a systema system

actorsactors represent roles people or devices play asrepresent roles people or devices play as

the system functionsthe system functions usersusers can play a number of different roles for acan play a number of different roles for a

given scenariogiven scenario



25

Develo ing a UseDevelo ing a Use--CaseCase

What are the main tasks or functions that are performed byWhat are the main tasks or functions that are performed by

the actor?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 changes inWill the actor have to inform the system about changes inthe external environment?the external environment?

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

Does the actor wish to be informed about unexpectedDoes the actor wish to be informed about unexpected

changes?changes?



26

Use CaseUse Case

Describes how an end user interacts with a system under a specificset of circumstances.

Described from end-users point of view. It is the highest levelabstraction of the users interaction with the system.

Identify different Actors that interact with the system.

Primary Actors interact with the system to avail its services.

Secondary Actors support the system so that primary actors can dotheir work.

Ex:- System Administrator in railway reservation system



27

Use CaseUse Case (contd. . .)(contd. . .)

Information needed for developing effective use cases

Primary and secondary actor(s). Actors goals.

Main tasks performed by the actors.

Exceptions that might occur during an actors interaction with thesystem.

Ex:- what happens if the reservation system goes down after thereservation is made, but before the ticket is issued.

System information that the actor produces / acquires / changes.



28

UseUse--Case DiagramCase Diagram

homeowner

ccess c me r

s r eill nce i the

Inter ne t

onf i r e f eHome

s stem r meters

et l r m

c mer s

SafeHome



29

Activity DiagramActivity Diagram

Supplements the useSupplements the use--case by providing a diagrammaticcase by providing a diagrammaticrepresentation of procedural flowrepresentation of procedural flow

enter password

and user I

selec t ma¡

o r f u n c t i o n

valid passwords/ I

p r o m p t f o r r e e n t r y

invalid passwords/ I

input tr ies remain

no input

tr ies remain

selec t sur ve i l l ance

other functions

may alsobe

select ed

thumbnail views select a specific camera

selec t ca mera i con

p r o m p t f o r

a n o t h e r v i e w

selec t spec i f i c

camera - thumbnai l s

e¢

it t his functionsee another camera

v i e w c a m e r a o u t p u t

i n l abel led w indow



30

Swimlane DiagramsSwimlane Diagrams Allows the modeler to represent the flow of activities described by the use Allows the modeler to represent the flow of activities described by the use--case and at thecase and at the

same time indicate which actor (if there are multiple actors involved in a specific usesame time indicate which actor (if there are multiple actors involved in a specific use--case)case)or analysis class has responsibility for the action described by an activity rectangleor analysis class has responsibility for the action described by an activity rectangle

e n t e r p a s s w o r d

and user ID

s e l e c t m a j o r f u n c t i o n

valid password s/ID

p r o m p t f o r r e e n t r y

invalid

password s/ID

input tr ies

remain

n o i n p u t

tr ies remain

selec t sur ve i ll ance

other func t i ons

may also b e

selected

thu mbn ail views select a sp ecific camera

s e l e c t c a m e r a i c o n

g e n e r a t e v i d e o

o u t p u t

s e l e c t s p e c i f ic

c a m e r a - t h u m b n a i l s

exit th is

func t i on

see

another

camera

h o m e o w n e r c a m e r a i n t e r f a c e

p r o m p t f o r

a n o t h e r v i e w

v i e w c a m e r a o u t p u t

i n l abel led w indow



31

Fl ow Fl ow- -Oriented Model ing Oriented Model ing

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 thatis the diagrammatic form that

is usedis usedConsidered by many to be an µold school¶ approach, flowConsidered by many to be an µold school¶ 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



32

The Flow ModelThe Flow ModelEvery computer Every computer--based system is anbased system is an

information transform ....information transform ....

com uter com uter basedbasedsystemsystem

in utin ut out utout ut



33

Flow Modeling NotationFlow Modeling Notation

external entityexternal entity

rocessrocess

data flowdata flow

data storedata store



34

External EntityExternal Entity

A roducer or consumer of dataA roducer or consumer of data

Examples: a person, a device, a sensor Examples: a person, a device, a sensor

Another example: computer Another example: computer--basedbased

systemsystem

Data must always originate somewhereData must always originate somewhere

and must always be sent to something and must always be sent to something



35

ProcessProcess

A data transformer (changes in utA data transformer (changes in utto out ut)to out ut)

Examples: compute taxes, determine area,Examples: compute taxes, determine area,

format report, display graphformat report, display graph

Data must always be processed in someData must always be processed in some

way to achieve system f unctionway to achieve system f unction



36

Data FlowData Flow

Data flows through a system, beginningData flows through a system, beginning

as in ut and be transformed into out ut.as in ut and be transformed into out ut.

com utecom ute

triangletriangle

areaarea

basebase

heightheight

areaarea



37

Data StoresData StoresDataData is often stored for later use.is often stored for later use.

looklook--uu

sensor sensor

datadata

sensor #sensor #

re ort requiredre ort required

sensor #, ty e,sensor #, ty e,location, agelocation, age

sensor datasensor data

sensor number sensor number

ty e,ty e,

location, agelocation, age



38

Data Flow Diagramming:Data Flow Diagramming:

GuidelinesGuidelines all icons must be labeled with meaningfulall icons must be labeled with meaningful

namesnames

the DFD evolves through a number of the DFD evolves through a number of

levels of detaillevels of detail

always begin with a context level diagramalways begin with a context level diagram

(also called level 0)(also called level 0)

always show external entities at level 0always show external entities at level 0

always label data flow arrowsalways label data flow arrows

do not represent procedural logicdo not represent procedural logic



39

Constructing a DFDConstructing a DFD²²II review the data model to isolate data objectsreview the data model to isolate data objects

and use a grammatical parse to determineand use a grammatical parse to determine³operations´³operations´

determine external entities (producers anddetermine external entities (producers andconsumers of data)consumers of data)

create a level 0 DFDcreate a level 0 DFD



40

Level 0 DFD Exam leLevel 0 DFD Exam le

user user rocessingrocessingrequestrequest

videovideosour cesour ce NTSCNTSC

video signalvideo signal

digitaldigitalvideovideorocessor rocessor

requestedrequestedvideovideo

signalsignal monitor monitor



41

Constructing a DFDConstructing a DFD²²IIII

write a narrative describing the transformwrite a narrative describing the transform

parse to determine next level transformsparse to determine next level transforms

³balance´ the flow to maintain data flow³balance´ the flow to maintain data flow

continuitycontinuity

develop a level 1 DFDdevelop a level 1 DFD

use a 1:5 (approx.) expansion ratiouse a 1:5 (approx.) expansion ratio



42

The Data Flow Hierar chyThe Data Flow Hierar chy

PPaa bb

xx yy

11

22

33

44 55

aa

bb

cc

ddee

f f

gg

level 0level 0

level 1level 1



43

Flow Modeling NotesFlow Modeling Notes

each bubble is refined until it does justeach bubble is refined until it does just

one thingone thing

the expansion ratio decreases as thethe expansion ratio decreases as the

number of levels increasenumber of levels increase most systems require between 3 and 7 most systems require between 3 and 7

levels for an adequate flow modellevels for an adequate flow model

a single data flow item (arrow) may bea single data flow item (arrow) may be

expanded as levels increase (dataexpanded as levels increase (data

dictionary provides information)dictionary provides information)



44

Process S ecification (PSPEC)Process S ecification (PSPEC)

PS PECPS PEC

narrativenarrative

pseudoc ode (PDL)pseudoc ode (PDL)

equationsequations

tablestables

diagrams and / or c hartsdiagrams and / or c harts

bubblebubble



45

Maps intoMaps into

DFDs: A Look AheadDFDs: A Look Ahead

analysis modelanalysis model

design modeldesign model



46

Use Case (Railway exam le revisited)Use Case (Railway exam le revisited)

Reservation

Cancellation

Bulk Reservations

Enquiry

Traveler

Travel Agent

Financial Gateway



47

Use Case : NotationsUse Case : Notations

UML is the industry standard notation for graphical modeling of systems.

Actor Use CaseSystem / Sub System

Association / Interaction

Compulsory interaction, the functionality at the pointed end must

be used at least once



48

Use CasesUse Cases : reservation: reservation

Each use case should be accompanied with a standard templatecontaining the following info:

primary actor

goal

preconditions

scenario

exceptions

data produced / consumed / changed

priority etc.,



49

Use Case : reservationUse Case : reservation

Use Case 1 : Traveler makes a reservation

1. Traveler enters the details: train number/name, date of journey, class,source station, destination station, name etc.

2. Reservation system asks for payment information

3. Traveler enters the debit / credit card details

4. Travelers reservation is confirmed.

Exception case -1 :

If the train number / name is invalid, prompt the traveler to enter correct values

before proceeding to step 2.

Exception case-2 :

If traveler doesnt have sufficient funds in his account, either prompt the user toenter the details of another account or stop processing the request.





51

System modeling ers ectivesSystem modeling ers ectives

Information

models system in terms of the information it consumes and

produces

Functional

models the system as a collection of functionalities

Behavioral

models the system as a state machine



52

Analysis ModelingAnalysis Modeling

The focus of the analysis is to identify what the system should do, in order tomeet stakeholders requirements.

what functions must the system perform ?

what information the system requires ?

what information the system produces ?

what behavior must the system exhibit ?

what interface should be defined ?

what constraints apply ? etc.,



53

Analysis modelingAnalysis modeling TechniquesTechniques

Structured Analysis

System is an information transformer

Object Oriented Analysis

System is a collection of objects and interactions among these

objects



54

Structured AnalysisStructured Analysis

It considers data and the processes that transform the data asseparate entities.

Data objects are modeled in a way that defines their attributes andrelationships.

Processes are modeled in a manner that show how they transformdata as data objects flow through the system.

DataObject-1

ProcessData

Object-2



55

Structured Analysis TechniquesStructured Analysis Techniques

Data Flow Diagrams

Control Flow Diagrams

Processing Narratives



56

Data Flow Diagrams (DFDs)Data Flow Diagrams (DFDs)

It models a system from information and functional modelingperspectives at the same time.

It takes an input-process-output view of a system.

DFD is represented in a hierarchical manner, where each subsequent level uncovers more and more information about the system.



57

DFDDFD :: NotationsNotations

T1

d1 A data object, d1

A transformation, T1

External System / entity

Data source / sink



58

LevelLevel--0 DFD /0 DFD / context diagramcontext diagram

This highest level DFD represents the system as a whole.

Railway reservationSystem

Traveler

Travel Agent

ClerkSystem Admin

IVR

Financial Gateway

ReservationCancellationEnquiry etc.

Reservation, cancellation,enquiry, concessions etc

Backup, Recovery, and Admin commands

Data

Financial Data



59

LevelLevel--1 DFD1 DFD

Reservation

Cancellation

Enquiry

TravelerFinancial Gateway

Reservation & Train data

ClerkSystem Admin

Travel Agent

IVR

Reservation system



60

LevelLevel--2 DFD2 DFD

Verify data

Check Balance

Make reservation

Traveler

Travel details

Verify availability

Train code, Dateof journey etc.

Fare amount, Account no

Data Store Financial Gateway

Documents

Sw Engg L5 Analysis Models1