3. model analysis

7/31/2019 3. Model Analysis

1/54

Chapter 12

Analysis Modeling


2/54

Definisi

serangkaian tugas pemodelan yangmembawa kepada suatu spesifikasi

lengkap dari persyaratan representasi dan

representasi desain yang menyeluruh bagiperangkat lunak yang dibangun


3/54

Sasaran Utama

Menggambarkan apa yang dibutuhkanuntuk pelanggan

Membangun dasar bagi pembuatan

desain perangkat lunak

Membatasi serangkaian persyaratan yang

dapat divalidasi begitu perangkat lunak

dibangun


4/54


5/54

Model Analisis :

Dimana harus memulai? Pernyataan dari ruang lingkup, bisa

diperoleh dari :

Dokumen kerja FAST Kumpulan dari use-cases

pernyataan ruang lingkup harus

diuraikan " menghasilkan domaininfomasi (data, fungsidan perilaku)


6/54

Pernyataan Ruang Lingkup

Gambaran yang relatif singkat dari

sistem yang akan dibangun

menunjukkan data yang mana

merupakan input dan output dan

fungsionalitas dasar

Menunjukkan proses berdasarkan

kondisi (pada tingkat tinggi)

menyatakan kendala dan

pembatasan tertentu


7/54

Mengidentifikasi Objek dan

Operasi mendefinisikan "objek" dengan menggarisbawahi

semua kata bendadalam laporan tertulis lingkup Penghasil/Pengguna data

Tempat dimana data disimpan

composite item-item data mendefinisikan "operasi" dengan double

menggarisbawahi semua kata kerjaaktif proses yang relevan dengan aplikasi

transformasi data

mempertimbangkan yang lain "layanan" yangakan dibutuhkan oleh objek


8/54

Model Datadan

Entity Relationship (E-

R)Diagramming


9/54

Mengapa model Data?

Memeriksa objek data yg independen

terhadap proses

memfokuskan perhatian pada domain

data

membuat membuat model pada

abstraksi dari level customer

menunjukkan bagaimana objek data

berhubungan satu dgn lain


10/54

Apa itu Objek Data?

Objek Data : Sesuatu yangmendeskripsikan kumpulan dari atribut

(item data) yang akan dimanipulasi oleh

perangkat lunak Atribut :


11/54

Apa itu Objek Data?

Objectsomething that is described by a setof attributes (data items) and that will bemanipulated within the software (system)

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

each plays a necessary role in the systemi.e., the system could not function withoutaccess to instances of the object

each is described by attributes that are

themselves data items


12/54

Objek yang Khas

Entitas Luar (printer, user, sensor)Berbagai haloccurrences or events (e.g., interrupt, alarm)

roles (e.g., manager, engineer, salesperson)

organizational units (e.g., division, team)places (e.g., manufacturing floor)

structures (e.g., employee record)


13/54

Objek Data dan Atribut

Sebuah objek data yang berisi satu setatribut yang bertindak sebagai suatuaspek, kualitas, karakter realistis, ataudeskriptor obyek

object: Mobilattributes:

Pembuatanmodel

typeharga..


14/54

What is a Relationship?

relationshipindicates connectedness;a "fact" that must be "remembered"by the system and cannot or is not computedor derived mechanically

several instances of a

relationship can exist

objects can be related in many

different ways


15/54

ERD Notation

(0, m) (1, 1)

object objectrelationship1 2

One common form:(0, m)

(1, 1)

object1 object2relationship

Another common form:

attribute


16/54

Building an ERD

Level 1model all data objects(entities) and their connections to one

another

Level 2model all entities andrelationships

Level 3model all entities,

relationships, and the attributes thatprovide further depth


17/54

The ERD: An Example

(1,1) (1,m)placesCustomer

requestfor service

generates(1,n)

(1,1)

workorder

worktasks

materials

consistsof

lists

(1,1)(1,w)

(1,1)

(1,i)

selectedfrom

standardtask table

(1,w)

(1,1)


18/54

Creating a FlowModel


19/54

The Flow Model

Every computer-based system is aninformation transform ....

computerbasedsystem

input output


20/54

Flow Modeling Notation

external entity

process

data flow

data store


21/54

External Entity

A producer or consumer of data

Examples: a person, a device, a sensor

Another example: computer-basedsystem

Data must always originate somewhereand must always be sent to something


22/54

Process

A data transformer (changes inputto output)

Examples: compute taxes, determine area,

format report, display graph

Data must always be processed in someway to achieve system function


23/54

Data Flow

Data flows through a system, beginsas input and is transformed into output.

computetriangle

area

base

height

area


24/54

Data Stores

Data is often stored for later use.

look-up

sensordata

sensor #

report required

sensor #, type,location, age

sensor data

sensor number

type,location, age

Data Flow Diagramming:


25/54

Data Flow Diagramming:

Guidelines

all icons must be labeled withmeaningful names

the DFD evolves through a

number of levels of detail always begin with a context

level diagram (also called level

0) always show external entities at


26/54

Constructing a DFDI

review ERD to isolate data objectsand grammatical parse todetermine operations

determine external entities(producers and consumers of data)

create a level 0 DFD


27/54

Level 0 DFD Example

userprocessing

request

videosource NTSC

video signal

digitalvideo

processor

requestedvideosignal

monitor


28/54

Constructing a DFDII

write a narrative describing thetransform

parse to determine next level

transforms balance the flow to maintain

data flow continuity

develop a level 1 DFD use a 1:5 (approx.) expansion

Th D t Fl Hi h


29/54

The Data Flow Hierarchy

Pa b

x y

p1

p2

p3

p4 5

a

b

c

de

f

g

level 0

level 1

Fl M d li N t


30/54

Flow Modeling Notes

each bubble is refined until itdoes just one thing

the expansion ratio decreases

as the number of levelsincrease

most systems require between

3 and 7 levels for an adequateflow model

a single data flow item (arrow)

DFD A L k Ah d


31/54

Maps into

DFDs: A Look Ahead

analysis model

design model

Real-Time Analysis


32/54

Real Time AnalysisMethods

each introduces its own notation,but all

propose an approach for

representing control and separating itfrom data

provide a mechanism for specifying

events, states, and distributed

processing

begin at the analysis level and work

to derive rocessor assi nments

Real-Time Analysis


33/54

Real Time Analysis& Design Methods

Gomaa, H., Software Design Methods for

Concurrent and Real-Time Systems,Addison-Wesley, 1995.

Harel, D. et al, "STATEMATE: A Working

Environment for the Development of

Complex Reactive Systems, IEEE Trans.Software Engineering, vol. 16, no. 3, April,

1990, pp. 403-414.

Hatley, D.J. and I.A. Pirbhai, Strategies for

Real-Time System Specification, DorsetHouse, 1987.

Selic, B., G. Gullekson, and P. Ward, Real-

-


34/54

BehavioralModeling

and ProcessSpecification

B h i l M d li


35/54

Behavioral Modeling

Outsideworld

Application

events behavior


36/54

The States of a System

statea set of observablecircum-stances that

characterizes the behavior of a

system at a given time

state transitionthe

movement from one state to

another

eventan occurrence that

causes the system to exhibit

Behavioral Modeling


37/54

Behavioral Modeling

make a list of the different states

of a system (How does the

system behave?)

indicate how the system makes atransition from one state to

another (How does the system

change state?) indicate event

State Transition Diagram


38/54

State Transition DiagramNotation

state

new state

event causing transition

action that occurs

a e rans on


39/54

Diagramreadingoperator

commands

making copies reloading paper

problem state

fullinvoke read-op-input

full and startinvoke manage-copying

copies doneinvoke read-op-input

emptyinvoke reload paper

jammedinvoke problem-diagnosis

not jammedinvoke read-op-input

The Control Model


40/54

The Control Modelthe control flow diagram is "superimposed" on the DFDand shows events that control the processes noted inthe DFD

control flowsevents and control itemsare noted by

dashed arrows

a vertical bar implies an input to or output from a controlspec (CSPEC) a separate specification thatdescribes 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 datacondition

a dashed arrow entering a process implies a controlinput read directly by the process

control flows do not physically activate/deactivate theprocessesthis is done via the CSPEC

Control Flow Diagram


41/54

Control Flow Diagram

readoperator

input managecopying

reloadprocess

performproblem

diagnosis

createuser

displays

empty

jammed

full

display panel enabled

beeper on/off

start

problemlight

copies done

Control Specification (CSPEC)


42/54

Control Specification (CSPEC)

The CSPEC can be:

state transition diagram(sequential spec)

state transition table

decision tables

activation tables

combinatorial spec

Guidelines for Building a CSPEC


43/54

Guidelines for Building a CSPEClist all sensors that are "read" by the software

list all interrupt conditions

list all "switches" that are actuated by the operator

list all data conditions

recalling the noun-verb parse that was applied to thesoftware statement of scope, review all "control items"

as possible CSPEC inputs/outputsdescribe the behavior of a system by identifying itsstates; identify how each state is reached and definethe transitions between states

focus on possible omissions ... a very common error in

specifying control, e.g., ask: "Is there any other way Ican get to this state or exit from it?"

Process Specification


44/54

p(PSPEC)

PSPEC

narrative

pseudocode (PDL)equationstablesdiagrams and/or charts

bubble

A Design Note


45/54

A Design Note

one or more components"in the software designPSPEC

Creating Mini-Specs


46/54

Creating Mini Specs

SoftwareSpecification

The Data Dictionary


47/54

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 thevalues that control data can take, e.g., "on," or "off"

a repository that also contains "where-used" / "howused" information

a notation that can be represented manually, but isbest developed using CASE tools

Building a Data Dictionary


48/54

g yName:

Aliases:

Where used:

How used:

Description:

Format:

the primary name of the composite data item

other names for the data item

data transforms (processes) that use thecomposite data item

the role of the data item (input, output,temporary storage, etc.)

a notation for representing content (presentedon next slide)

specific information about data types, pre-setvalues (if known)

Data Dictionary Notation


49/54

yNotation

=

+

[ ]

{ }

( ... )

* ... text ...*

n

Meaning

is composed of

and

either-or

n repetitions of

optional data

delimits a comment

Data Dictionary Example


50/54

telephone numberintegrated

officephonesystem

Name:

Aliases:

Where/Howused:

Description:

Format:

telephone number

phone number, number

read-phone-number (input)display-phone-number (output)analyze-long-distance-calls (input)

telephone no. = [ local extension | outs ide no. | 0 ]outside no. = 9 + [ service code | domestic no. ]serv ice code = [ 211 | 411 | 611 | 911 ]domestic no. = ( ( 0 ) + area code ) + loc al numberarea code = *three numeral designator*

Build the requirements dictionary:

alphanumeric data

system output

Writing the Software Specificatio


51/54

Writing the Software Specificatio

Everyone knew exactlywhat had to be doneuntil someone wrote itdown!

Specification Guidelines


52/54

use a layered format that provides increasing detailas the "layers" deepen

use consistent graphical notation and apply textualterms 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 "editingsuggestions" on the following pages)

always put yourself in the reader's position, "WouldI be able to understand this if I wasn't intimately

familiar with the system?"



53/54

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 lists are given, but not completed, be sure all items are understoodkeys: etc., and so forth, and so on, such as

Be sure stated ranges don't contain unstated assumptionse.g., Valid codes range from 10 to 100. Integer? Real? Hex?

Beware of vague verbs such as handled, rejected, processed, ...

Beware "passive voice" statementse.g., The parameters are initialized. By what?

Beware "dangling" pronounse.g., The I/O module communicated with the data validation module and

its contol flag is set. Whose control flag?



54/54

pWhen a term is explicitly defined in one place, trysubstituting the definition for other occurrences of the term

When a structure is described in words, draw a pictureWhen a structure is described with a picture, try to redrawthe picture to emphasize different elements of the structure

When symbolic equations are used, try expressing theirmeaning in words

When a calculation is specified, work at least twoexamples

Look for statements that imply certainty, then ask for proofkeys: always, every, all, none, never

Search behind certainty statementsbe sure restrictions

or limitations are realistic

3. model analysis

Documents