3. model analysis
TRANSCRIPT
-
7/31/2019 3. Model Analysis
1/54
Chapter 12
Analysis Modeling
-
7/31/2019 3. Model Analysis
2/54
Definisi
serangkaian tugas pemodelan yangmembawa kepada suatu spesifikasi
lengkap dari persyaratan representasi dan
representasi desain yang menyeluruh bagiperangkat lunak yang dibangun
-
7/31/2019 3. Model Analysis
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
-
7/31/2019 3. Model Analysis
4/54
-
7/31/2019 3. Model Analysis
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)
-
7/31/2019 3. Model Analysis
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/31/2019 3. Model Analysis
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
-
7/31/2019 3. Model Analysis
8/54
Model Datadan
Entity Relationship (E-
R)Diagramming
-
7/31/2019 3. Model Analysis
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
-
7/31/2019 3. Model Analysis
10/54
Apa itu Objek Data?
Objek Data : Sesuatu yangmendeskripsikan kumpulan dari atribut
(item data) yang akan dimanipulasi oleh
perangkat lunak Atribut :
-
7/31/2019 3. Model Analysis
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
-
7/31/2019 3. Model Analysis
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)
-
7/31/2019 3. Model Analysis
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..
-
7/31/2019 3. Model Analysis
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
-
7/31/2019 3. Model Analysis
15/54
ERD Notation
(0, m) (1, 1)
object objectrelationship1 2
One common form:(0, m)
(1, 1)
object1 object2relationship
Another common form:
attribute
-
7/31/2019 3. Model Analysis
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
-
7/31/2019 3. Model Analysis
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)
-
7/31/2019 3. Model Analysis
18/54
Creating a FlowModel
-
7/31/2019 3. Model Analysis
19/54
The Flow Model
Every computer-based system is aninformation transform ....
computerbasedsystem
input output
-
7/31/2019 3. Model Analysis
20/54
Flow Modeling Notation
external entity
process
data flow
data store
-
7/31/2019 3. Model Analysis
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
-
7/31/2019 3. Model Analysis
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
-
7/31/2019 3. Model Analysis
23/54
Data Flow
Data flows through a system, beginsas input and is transformed into output.
computetriangle
area
base
height
area
-
7/31/2019 3. Model Analysis
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:
-
7/31/2019 3. Model Analysis
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
-
7/31/2019 3. Model Analysis
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
-
7/31/2019 3. Model Analysis
27/54
Level 0 DFD Example
userprocessing
request
videosource NTSC
video signal
digitalvideo
processor
requestedvideosignal
monitor
-
7/31/2019 3. Model Analysis
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
-
7/31/2019 3. Model Analysis
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
-
7/31/2019 3. Model Analysis
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
-
7/31/2019 3. Model Analysis
31/54
Maps into
DFDs: A Look Ahead
analysis model
design model
Real-Time Analysis
-
7/31/2019 3. Model 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
-
7/31/2019 3. Model 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-
-
-
7/31/2019 3. Model Analysis
34/54
BehavioralModeling
and ProcessSpecification
B h i l M d li
-
7/31/2019 3. Model Analysis
35/54
Behavioral Modeling
Outsideworld
Application
events behavior
-
7/31/2019 3. Model Analysis
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
-
7/31/2019 3. Model Analysis
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
-
7/31/2019 3. Model Analysis
38/54
State Transition DiagramNotation
state
new state
event causing transition
action that occurs
a e rans on
-
7/31/2019 3. Model Analysis
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
-
7/31/2019 3. Model Analysis
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
-
7/31/2019 3. Model Analysis
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)
-
7/31/2019 3. Model Analysis
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
-
7/31/2019 3. Model Analysis
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
-
7/31/2019 3. Model Analysis
44/54
p(PSPEC)
PSPEC
narrative
pseudocode (PDL)equationstablesdiagrams and/or charts
bubble
A Design Note
-
7/31/2019 3. Model Analysis
45/54
A Design Note
one or more components"in the software designPSPEC
Creating Mini-Specs
-
7/31/2019 3. Model Analysis
46/54
Creating Mini Specs
SoftwareSpecification
The Data Dictionary
-
7/31/2019 3. Model Analysis
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
-
7/31/2019 3. Model Analysis
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
-
7/31/2019 3. Model Analysis
49/54
yNotation
=
+
[ ]
{ }
( ... )
* ... text ...*
n
Meaning
is composed of
and
either-or
n repetitions of
optional data
delimits a comment
Data Dictionary Example
-
7/31/2019 3. Model Analysis
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
-
7/31/2019 3. Model Analysis
51/54
Writing the Software Specificatio
Everyone knew exactlywhat had to be doneuntil someone wrote itdown!
Specification Guidelines
-
7/31/2019 3. Model Analysis
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?"
Specification Guidelines
-
7/31/2019 3. Model Analysis
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?
Specification Guidelines
-
7/31/2019 3. Model Analysis
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