Bab 8

Catatan Kuliah
Rekayasa Perangkat Lunak

(Software Engineering)
Bagian 2
copyright © 2006
R.S. Pressman & Associates, Inc
Hanya digunakan di lingkungan Universtias

Hanya boleh digandakan untuk mahasiswa di lingkungan universitas
yang menggunakan buku Software Engineering: A Practitioner's Approach.
Selain itu dilarang keras menggandakan.
Presentasi, slide atau hardcopy tidak boleh digunakan untuk

short courses, seminar industri, atau kepentingan konsultasi.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with
permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 1
Software Engineering: A Practitioner’s Approach, 6/e
Chapter 8
Pemodelan Analisis
copyright © 1996, 2001, 2005
R.S. Pressman & Associates, Inc.
For University Use Only

May 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.
Analisis Kebutuhan
 Analisis Kebutuhan
 Menentukan karakteristik operasional PL
 Menunjukkan antarmuka PL dengan elemen sistem yang lain
 Membuat batasan yang harus dipenuhi PL
 Analisis Kebutuhan memungkinkan Software Engineer
(disebut analis atau modeler) untuk :
 Memperinci kebutuhan dasar yang dibuat kapada rekayasa
kebutuhan sebelumnya
 Membangun model yang dapat menggambarkan skenario user,
aktivitas fungsional, class masalah dan relasinya, sistem dan
perilaku class, dan aliran data ketika ditransformasikan.
Sebuah Jembatan
system
description
analysis
model
design
model
Aturan-Aturan
 Model harus fokus pada masalah atau domain bisnis.
Tingkat abstraksinya relatif harus lebih tinggi.
 Setiap elemen model analisis sebaiknya memberikan
tambahan pada pemahaman keseluruhan kebutuhan PL dan
menyediakan wawasan pada domain informasi, fungsi dan
perilaku sistem.
 Tunda semua konsideran infrastruktur dan model non
fungsional hingga fase desain.
 Minimalisasi rangkaian melalui sistem.
 Pastikan model analisis menyediakan nilai untuk semua
stakeholder.
 Jaga model sesederhana mungkin.
Analisis Domain
Analisis domain PL adalah identifikasi, analisis, dan
spesifikasi kebutuhan umum dari domain aplikasi
tertentu, yang biasanya digunakan kembali pada
project lain di dalam domain aplikasi yang sama
[Analisis domain berorientasi objek adalah] identifikasi,
analisis dan spesifikasi kemampuan umum,
kemampuan digunakan kembali dalam domain
tertentu dalam istilah-istilah objek, class, subassemblies
dan framework umum
Donald Firesmith
Analisis Domain
 Tentukan domain yang ingin diinvestigasi.
 Kumpulkan contoh representatif aplikasi pada
domain tersebut.
 Analisis setiap aplikasi pada contoh.
 Kembangkan model analisis untuk objek.
Pemodelan Data
 Memeriksa objek data secara
independen terhadap proses
 Fokus perhatikan pada domain data
 Membuat sebuah model pada abstraksi
level konsumen
 Mengindikasikan bagaimana objek data
berhubungan satu dengan yang lain
What is a Data Object?
Object —something that is described by a set
of attributes (data items) and that will be
manipulated 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 system
i.e., the system could not function without
access to instances of the object
each is described by attributes that are
themselves data items
Objek-Objek Umum
Entitas eksternal (printer, user, sensor)
Sesuatu (laporan, display, sinyal)
Kejadian atau event (interupsi, alarm)
orang (manager, engineer, salesperson)
Unit organisasi (divisi, tim)
tempat (lantai pabrik)
struktur (employee record)
Objek Data dan Atribut
Sebuah objek data terdiri dari sekumpulan
atribut yang bertindak sebagai aspek,
kualitas, karakteristik, atau penjelas objek
object: automobile
attributes:
make
model
body type
price
options code
Apakah Relationship?
Relationship – menandakan kaitan, sebuah fakta
yang harus diingat oleh sistem, tidak
dikomputasi atau diturunkan secara mekanis
 several instances of a relationship can exist
 objects can be related in many different ways
Notasi ERD
Satu bentuk umum:
(0, m)
object1 relationship object 2
(1, 1)
attribute
Bentuk Umum yang lain:
object1 relationship
object 2
(0, m) (1, 1)
Membangun Sebuah ERD
 Level 1—modelkan semua objek data (entitas) dan

koneksinya dengan yang lain
 Level 2—modelkan semua entitas dan relasi
 Level 3—modelkan semua entitas, relasi, dan
atribut yang menyediakan informasi yang lebih
mendalam
ERD: sebuah contoh
request
Customer places
for service
(1,1) (1,m)
(1,1)
standard generates (1,n) work
task table order
(1,1) (1,1) (1,1)
selected work (1,w) consists
from (1,w) tasks of
(1,i)
materials lists
Konsep Object-Oriented
 Harus dipahami untuk menerapkan elemen
berbasis class pada model analisis
 Konsep-konsep kunci:
 Classes dan objects
 Attributes dan operations
 Encapsulation dan instantiation
 Inheritance
Class
• Pemikiran object-oriented dimulai dengan
sebuah class, sering didefinisi sebagai :
– template
– deskripsi umum
– “blueprint” ... Menggambarkan sekelompok item
yang mirip
• sebuah metaclass (sering disebut
superclass)yang membangun hierarki semua
class yang ada
• Sekali sebuah class item ditentukan, instance
spesifik dari class tersebut dapat diidentifikasi
Membangun Class
class name
attributes:
operations
attributes:
operations:
Apakah Class?
occurrences roles
things organizational units
places
external entities
structures
class name
attributes:
operations:
Enkapuslasi/Penyembunyian
Objek mengenkapsulasi
Baik data dan prosedur
Logis yang dibutuhkan
Untuk manipulasi method method
#2
#1
data data
method
method #3
#6
method method
#5 #4
Achieves “information hiding”
Hierarki Class
PieceOfFurniture (superclass)
Table Chair Desk ”Chable"
subclasses of the
instances of Chair
Method
(Operasi, Layanan)
Prosedur yang
terenkapsulasi pada
sebuah class dan
didesain untuk
beroperasi pada satu
atau lebih atribut data
yang ditentukan sebagai
bagian dari class.
Method dipanggil
melalui pesan
Model berbasis Scenario
“[Use-cases] adalah bantuan untuk mendefinisikan apa
yang ada pada sistem (aktor) dan apa yang harus
dilakukan sistem (use-cases).” Ivar Jacobson
(1) Apa yang harus ditulis?
(2) Berapa banyak kita harus menulisnya?
(3) Sedetail apa gambaran kita ?
(4) Bagaimana kita mengatur deskripsi?
Use-Cases
 Sebuah skenario yang menggambarkan
rangkaian kegunaan pada sistem
 actors mewakili peran orang atau piranti yang
dimainkan ketika sistem berfungsi
 users dapat berperan sebagai lebih dari satu
peran dalam sebuah skenario yang ditentukan
Mengembangkan Use-Case
 Apa tugas atau fungsi utama yang harus dilakukan aktor ?
 Sistem Informasi seperti apa yang diperlukan, dihasilkan
atau diubah oleh aktor ?
 Apakah aktor harus menginformasikan sistem tentang
perubahan dalam lingkungan eksternal?
 Informasi apa yang diharapkan aktor dari sistem?
 Apakah aktor menginginkan diberitahu tentang
perubahan yang tidak tersangka?
Use-Case Diagram
Saf e Ho m e
Acce s s cam e ra
s urve illance via t h e cam e ras
Int e rne t
Configure Safe Hom e

s ys t e m param e t e rs
hom e owne r
Se t alarm
Activity Diagram
Melengkapi use-case dengan menyediakan representasi diagram
dari aliran prosedural.
e n t e r pa sswo rd
a nd u se r ID
valid pas s wor ds / ID invalid pas s wor ds / ID
se le c t ma jo r func t ion promp t fo r re e n t ry

ot her f unct ions
m ay als o be
s elect ed
input t r ies r em ain
se le c t su rve illa nc e
no input
t r ies r em ain
t hum bnail views s elect a s pecif ic cam er a
se le c t spe c ific
se le c t c a me ra ic o n
c a me ra - t h umbna ils
v ie w c a me ra o ut pu t
in la be lle d win dow
pro mp t for
a n ot he r vie w
exit t his f unct ion s ee anot her cam er a
Swimlane Diagrams
Memungkinkan untuk menampilkan aliran aktivitas yang digambarkan oleh use-case, dan
di saat yang sama mengindikasikan aktor yang mana, atau class analisis yang mempunyai
tanggungjawab terhadap tindakan yang digambarkan oleh kotak aktivitas
home owne r c a m e ra i n t e rf a c e
e n t e r pa s s wo rd
a nd u s e r ID
valid p as s wo r d s / ID
in valid
p as s wo r d s / ID
s e le c t m a jo r fu nc t ion
o t h er f u n ct io n s p rom p t fo r re e n t ry
m ay als o b e
s elect ed
in p u t t r ies
s e le c t s urv e illa nc e r em ain
n o in p u t
t r ies r em ain
t h u m b n ail views s elect a s p ecif ic cam er a
s e le c t s pe c ific
s e le c t c a m e ra ic on
c a m e ra - t h um b na ils
ge ne ra t e vide o
o ut pu t
v ie w c a m e ra ou t put p rom p t fo r
in la b e lle d wind ow a no t h e r vie w
exit t h is
f u n ct io n
s ee
an o t h er
cam er a
Pemodelan berorientasi aliran
Menampilkan bagaimana objek data ditransformasi
ketika mereka bergerak di dalam sistem
Sebuah data flow diagram (DFD) merupakan bentuk
diagram yang digunakan
Walaupun dianggap pendekatan kuno, pemodelan
berorientasi aliran menyediakan pandangan unik
terhadap suatu sistem. Dia tetap layak digunakan untuk
mendukung analisis elemen model lainnya.
Model Aliran
Setiap sistem berbasis komputer
Adalah sebuah transformasi informasi
computer
input based output
system
Notasi Model Aliran
Entitas Eksternal
proses
Aliran data
Penyimpanan data
Entitas Eksternal
Produsen atau konsumen sebuah data
Contoh : seseorang, piranti, sensor

Contoh lain : sistem berbasis komputer
Data harus selalu berawal dari suatu tempat dan

Harus selalu dikirim pada sesuatu
Proses
Sebuah transformer data
(mengubah input menjadi output)
Contoh: menghitung pajak, menentukan luas,

Memformat laporan, menampilkan grafik
Data harus selalu diproses dalam bentuk tertentu
Untuk menerima fungsi sistem
Aliran Data
Data mengalir melalui sebuah sistem dimulai

Sebagai input dan ditransformasi menjadi
output
base
compute
area
triangle
height area
Menyimpan Data
Data disimpan untuk digunakan lagi.
sensor #
sensor #, type,
look-up location, age
sensor
report required data
type,
location, age
sensor number
sensor data
Petunjuk menggambar DFD
 Semua icon harus diberi nama yang

bermakna jelas
 DFD berkembang dalam beberapa
tingkatan
 Selalu dimulai dengan sebuah context
level diagram (level 0)
 Selalu menunjukkan entitas eksternal pada
level 0
 Selalu berinama panah aliran data
 Jangan menampilkan prosedur logika
Aturan Dalam Pembuatan DFD
 Antar entitas tidak boleh ada relasi
 Tidak boleh ada aliran data antara entitas eksternal dan
data store
 Satu aliran data boleh mengalirkan beberapa paket data
 Aliran data selalu diawali / diakhiri oleh proses
Membangun sebuah DFD—I
 Mereview model data untuk mengisolasi objek
data dan gunakan parsing gramatikal untuk
menentukan “Operasi”
 Menentukan entitas eksternal (produsen dan
konsumen data)
 Membuat level 0 DFD
Contoh Level 0 DFD
processing
user request requested
video
digital signal
video monitor
processor
video
source NTSC
video signal
Membangun DFD—II
 Tulis sebuah narasi yang menggambarkan

transformasi
 Parsing untuk menentukan transformasi
tingkat berikutnya
 “seimbangkan” aliran untuk menjaga aliran
data
 Bangun level 1 DFD
 Gunakan rasio 1:5 (perkiraan)
Hierarki Aliran Datang
a b
x P y level 0
a c p2
p1
f
d p4 5 b
p3 e g
level 1
Catatan untuk DFD
 Setiap lingkaran harus dipecah hingga
dia hanya melakukan hanya SATU hal
 Rasio ekspansi menurun sesuai dengan
jumlah level yang meningkat
 Kebanyakan sistem membutuhkan
antara 3 hingga level 7 untuk model
aliran yang cukup.
 Sebuah item aliran data (panah) dapat
dikembangkan seiring dengan
meningkatnya level (data dictionary
menyediakan informasi ini)
Spesifikasi Proses (PSPEC)
Lingkaran
PSPEC
naratif
pseudocode (PDL)
persamaan
tabel
Diagram dan atau grafik
Setelah DFD?
analysis model
Maps into
design model
Control Flow Diagram
 Menggambarkan “events” dan proses yang mengelola
event
 Sebuah “event” adalah kondisi boolean yang dipastikan
dengan :
 Mendaftar semua sensor yang dibaca oleh software.
 Mendaftar semua kondisi interupsi.
 Mendaftar semua "switches" yang dipicu oleh sebuah operator.
 Mendaftar semua kondisi data.
 Memanggil kembali parser kata benda/kerja yang diaplikasikan
pada narasi proses, mereview semua “item kendali” sebagai
input/output CSPEC.
Model Kendali
• control flow diagram berada “di atas” DFD dan menunjukkan event yang
mengendalikan proses-proses yang terdapat pada DFD
• Aliran kendali—event dan item kendali– ditandai dengan panah putus-
putus
• Sebuah tiang vertikal menggambarkan input menuju atau output dari
sebuah control spec (CSPEC) — spesifikasi terpisah yang menggambarkan
bagaimana kendali ditangani
• Sebuah panah putus-putus memasuki tiang vertikal adalah input menuju
CSPEC
• Sebuah panah putus-putus meninggalkan proses menggambarkan kondisi
data
• Sebuah panah putus-patas memasuki sebuah proses menggambarkan
sebuah kendali input yang dibaca langsung oleh proses
• Aliran kendali tidak secara fisik mengaktifkan/menonaktifkan proses, hal
ini dilakukan melalui CSPEC
Control Flow Diagram
copies done
beeper on/off full
read
operator
input manage
problem
start copying light
empty
reload create
process user
displays
perform
problem
diagnosis
display panel enabled
jammed
Control Specification (CSPEC)
CSPEC dapat berupa:
state diagram
(sequential spec)
state transition table

combinatorial spec
decision tables
activation tables
Panduan Membangun CSPEC
Lihat semua sensor yang “dibaca” oleh PL
Lihat semua kondisi interupsi
Lihat semua "switches" yang diaktifkan oleh operator
Lihat semua kondisi data
Melihat parsing kata benda/kerja yang diterapkan pada

Statemen software atau lingkupnya, mereview semua item kendali
Sebagai input/output CSPEC yang mungkin
Menggambarkan perilaku sebuah sistem dengan identifikasi
Keadaan; menentukan bagaimana setiap keadaan mencapai dan
Menentukan transisi antar keadaan
Fokus pada kemungkinan kehilangan/tidak tercantum...

Kesalahan umum dalam menentukan kendali, misalnya
"Is there any other way I can get to this state or exit from it?"
Pemodelan berbasis Class
 Tentukan analisis class dengan memeriksa
pernyataan masalah(problem statement)
 Gunakan parsing gramatikal untuk memilah class
potensial
 Kenali atribut tiap class
 Kenali operasi yang memanipulasi atribut-atribut
tersebut
Class Analisis
 Entitias external (contoh : sistem lain, piranti, orang) yang menghasilkan atau
menggunakan informasi yang digunakan oleh sistem berbasis komputer.
 Benda (contoh : laporan, display, surat, sinyal) yang merupakan bagian dari
domain informasi untuk masalah.
 Kejadian atau event (contoh : transfer properti atau pelengkapan urutan
gerakan robot) yang terjadi di dalam konteks sistem operasi.
 Peran (contoh : manajer, insinyur, sales) yang diperankan orang yang
berinteraksi dengan sistem.
 Unit Organisasi (contoh : divisi, kelompok, tim) yang relevan terhadap
aplikasi.
 Tempat (contoh : lantai pabrik, pelabuhan muatan) yang membangun
konteks masalah dan fungsi keseluruhan sistem.
 Struktur (contoh : sensor, kendaraan 4WD, komputer) yang terdiri dari
beberapa objek class atau objek-objek class yang terkait
Kriteria memilih class
Menyimpan informasi
Layanan yang dibutuhkan
Beberapa atribut
Atribut umum
Operasi umum
Kebutuhan esensial
Class Diagram
Class name
System
systemID
verificationPhoneNumber
systemStatus attributes
delayTime
telephoneNumber
masterPassword
temporaryPassword
numberTries
program()
display()
reset()
query() operations
modify()
call()
Class Diagram
Flo o rPlan
type
name
outs ideDimens ions
determineType ( )
pos itionFloorplan
s cale( )
change color( )
is pla c e d wit hin
is pa rt of
Ca m e ra Wa ll
t yp e t ype
ID wa llDim e ns ion s
loc a t io n
fie ld Vie w
p a nAn gle
Zoom Se t t ing
determineType ( )
computeDimens ions ( )
d e t e rm ine Typ e ()
t ra n s la t e Loc a t ion ()
d is p la yID()
d is p la yVie w()
d is p la yZo om ()
is us e d t o build is us e d t o build
is us e d t o build
Wa llSe gm e nt Window Door
t y pe t y pe t y pe
s t a rt Coo rdina t e s s t a rt Co ordina t e s s t a rt Coo rdina t e s
s t opCoord in a t e s s t op Coo rdin a t e s s t opCoord in a t e s
n e xt Wa llSe m e n t n e x t Win dow n e xt Doo r
determineType ( ) determineType ( ) determineType ( )

draw( ) draw( ) draw( )
Pemodelan CRC
 Class-class analisis memiliki “tanggung-jawab”
 Tanggungjawab adalah atribut-atribut dan operasi-operasi yang
terenkapsulasi oleh class
 Class-class analisis berkolaborasi satu dengan yang lain
 Collaborators adalah class-class yang dibutuhkan untuk
menyediakan sebuah class dengan informasi yang dibutuhkan
untuk memenuhi tanggung jawabnya.
 Secara umum, sebuah kolaborasi berakibat permintaan
informasi atau permintaan beberapa aksi/operasi.
Pemodelan CRC
Class:
Class:
Description:
Class:
Description:
Class: FloorPlan
Description:
Responsibility:
Description: Collaborator:
Responsibility: Collaborator:
defines floor plan name/type
manages floor plan positioning
scales floor plan for display
scales floor plan for display
incorporates walls, doors and windows Wall
shows position of video cameras Camera
Tipe-tipe Class
 Class entitas, sering disebut class model atau bisnis, yang
diekstrak langsung dari statemen permasalahan (contoh :
Sensor).
 Class perbatasan digunakan untuk membuat interface (contoh : layar
interaktif, atau laporan cetak) dimana user melihat dan berinteraksi
dengannya selama PL digunakan.
 Class kendali mengelola “unit kerja [UML03] dari awal sampai
akhir. Class kendali dapat didesain mengelola :
 Pembuatan atau update objek entitas;
 Inisiasi objek perbatasan sebagaimana mereka mendapatkan
informasi dari objek entitas;
 Komunikasi kompleks antara sekumpulan objek;
 Validasi data yang dikomunikasikan antara user dan aplikasi.
Responsibilities
 System intelligence should be distributed across classes
to best address the needs of the problem
 Each responsibility should be stated as generally as
possible
 Information and the behavior related to it should reside
within the same class
 Information about one thing should be localized with a
single class, not distributed across multiple classes.
 Responsibilities should be shared among related classes,
when appropriate.
Kolaborasi
 Class memenuhi tanggung jawabnya dengan satu diantara dua cara
:
 Sebuah class dapat menggunakan operasinya sendiri untuk
memanipulasi atributnya masing-masing atau
 Sebuah class dapat berkolaborasi dengan class lainnya.
 Kolaborasi membuat relasi antara class
 Kolaborasi dapat diidentifikasi dengan menentukan apakah sebuah
class dapat memenuhi tanggung jawabnya masing-masing
 Tiga relasi umum yang berbeda antar class [WIR90]:
 is-part-of relationship
 has-knowledge-of relationship
 depends-upon relationship
Composite Aggregate Class
Player
PlayerHead PlayerBody PlayerArms PlayerLegs
Review model CRC
 Semua peserta dalam review (model CRC) diberikan sebuah subset dari kartu index
model CRC.
 Kartu yang berkolaborasi harus terpisah (tidak boleh ada reviewer yang memiliki dua kartu
yang berkolaborasi).
 Semua skenario use-case (dan diagram use case terkait) harus diorganisasi dalam
kategori-kategori.
 Pemimpin review membaca use-case secara hati-hati.
 Ketika pemimpin review sampai pada objek, dia akan memberi tanda kepada person yang
memegang kartu index class yang terkait.
 Ketika tanda dikirimkan, pemilik kartu class diminta untuk menggambarkan tanggung
jawab yang tertulis di kartu tersebut.
 Kelompok menentukan satu (atau lebih) tanggung jawab yang memenuhi kebutuhan use-case.
 Jika tanggung jawab dan kolaborasi yang tertera pada kartu index tidak dapat
mengakomodasi use-case, modifikasi dilakukan pada kartu tersebut.
 Hal ini termasuk definisi class baru (dan kartu index CRC) atau spesifikasi baru atau revisi
mengenai tanggung jawab, atau kolaborasi kartu yang sudah ada.
Asosiasi dan Dependensi
 Dua class analisis sering berhubungan satu dengan yang

lain dalam beberapa pola
 Dalam UML relasi ini sering disebut asosiasi
 Asosiasi dapat didapatkan dengan mengenali multiplicity (istilah
cardinality digunaikan dalam pemodelan data
 Dalam banyak instans, relasi client-server ada diantara
dua class analisis.
 Dalam kasus ini, class client tergantung pada class server dalam
suatu cara dan relasi dependensi terjadi
Multiplicity
Wa ll
1 1 1
is used to build is used to build
1..* 0..* is used to build 0..*
Wa llSe g m e n t Win d o w Do o r
Dependencies
DisplayWindow Camera
<<access>>
{password}
Analisis Paket
 Beberapa model analisis (use-case, class analisis) dikategorisasi
dalam sebuah pola yang mempaketkan mereka dalam kelompok
 Tanda plus di dalam nama class analisis dalam setiap paket
menandakan bahwa class-class tersebut mempunyai visibilitas
publik dan karena itu dapat diakses dari paket lain.
 Simbol lain dapat mendahului elemen di dalam paket. Tanda minus
menandakan bahwa elemen disembunyikan dari semua paket, dan
tanda # menandakan bahwa elemen hanya dapat diakses oleh paket
yang berada di dalam paket tersebut.
Analysis Packages
p ackag e n am e
Environm e nt
+Tree
+Landscape
+Road
+Wall
+Bridge
+Building Rule s OfThe Gam e
+VisualEffect
+Scene +RulesOfMovement
+ConstraintsOnAction
Ch aract e rs
+Player
+Protagonist
+Antagonist
+SupportingRole
Pemodelan Perilaku
 Model perilaku menggambarkan bagaimana PL merespon event
atau stimulan eksternal. Untuk model tersebut, analis harus
melakukan langkah-langkah berikut :
 Evaluasi semua use-case untuk mendapatkan pemahaman menyeluruh
tentang urutan interaksi di dalam sistem.
 Mengenali event yang mengendalikan urutan interaksi dan
memahamibagaimana event mempunyai relasi terhadap objek spesifik.
 Membuat urutan untuk setiap use-case.
 Membangun state diagram untuk sistem.
 Review model behavioral untuk memverifikasi akurasi dan konsistensi
Representasi Keadaan
 Dalam konteks pemodelan perilaku, dua karakter
keadaan harus diperhatikan :
 Keadaan setiap class ketika sistem menjalankan fungsinya, dan
 Keadaan sistem ketika diobservasi dari luar sebagaimana sistem
menjalankan fungsinya.
 Keadaan class mengambil baik karakter aktif maupun
pasif [CHA93].
 Sebuah keadaan pasif adalah status saat ini dari semua atribut
objek.
 Keadaan aktif dari sebuah objek menggambarkan status saat ini
pada objek tersebut ketika menjalankan transformasi atau
proses.
State Diagram for the ControlPanel Class
t im e r < lo cke d Time
t ime r > lo cke d Time lo cke d
p as s wo rd = in co rre ct
& n u mb e rOfTrie s < m axTrie s
re ad in g co m p arin g n u mb e rOfTrie s > maxTrie s

ke y h it
p as s wo rd
e n t e re d do: va lida t e Pa s s w ord
p as s wo rd = co rre ct
s e le ct in g
act iv at io n s u cce s s fu l
Keadaan-Keadaan Sistem
 state—sekumpulan keadaan terobservasi
yang menggambarkan perilaku sistem
pada satu waktu
 state transition—perubahan dari satu
keadaan ke keadaan yang lain
 event—sebuah kejadian yang
menyebabkan sistem melakukan
perilaku yang sudah diprediksi
sebelumnya
 action—proses yang terjadi sebagai
konsekuensi membuat transisi
Pemodelan Perilaku
 Membuat daftar keadaan sistem yang

berbeda (Bagaimana perilaku sistem ?)
 Menggambarkan bagaimana sistem
membuat transisi dari satu keadaan ke
keadaan yang lain.indicate how the system
makes a transition from one state to another
(Bagaimana sistem mengubah keadaan?)
 mengenali event
 Mengawali action
 Menggambar sebuah state diagram atau
sequence diagram
Sequence Diagram
h o meo w n er co n t ro l p an el s ys t em ssen
enssoors
rs
s ys t em read in g
A
read y
p as s w o rd en t ered
req u es t lo o ku p
co mp arin g
res u lt
pa s s wo rd = c orre c t
num be rOfTrie s > m a x Trie s req u es t act ivat io n
lo cked
t imer > lo cked Time

A
s elect in g
act ivat io n s u cces s fu l act ivat io n s u cces s fu l
Figure 8 .2 7 Se que nc e dia gra m (pa rt ia l) for Saf e Hom e s e c urit y func t ion
Menulis Spesifikasi PL
Setiap orang harus
tahu pasti apa yang
harus dilakukan
hingga seseorang
menuliskannya !
Tugas
 Buatlah sebuah paper yang menjelaskan tentang UML
beserta contoh kasusnya, minimal 15 halaman, spasi 1.5,
kertas Quarto, sampul mika biru tua.
 Kriteria penilaian :
 Validitas/kebenaran
 Kelengkapan
 Kompleksitas kasus
Panduan Spesifikasi
use a layered format that provides increasing deta
as the "layers" deepen
use consistent graphical notation and apply textua

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?"
Panduan Spesifikasi
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 understoo
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 toInteger?
100. Real? Hex?
handled,
Beware of vague verbs such as 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 an
its contol flag is Whose
set. control flag?
Panduan Spesifikasi
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

Bab 8

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Bab 8

Diunggah oleh

Hak Cipta:

Format Tersedia

Catatan Kuliah

Rekayasa Perangkat Lunak

Hanya digunakan di lingkungan Universtias

Presentasi, slide atau hardcopy tidak boleh digunakan untuk

For University Use Only

 objects can be related in many different ways

 Level 1—modelkan semua objek data (entitas) dan

Achieves “information hiding”

Table Chair Desk ”Chable"

Configure Safe Hom e

valid pas s wor ds / ID invalid pas s wor ds / ID

se le c t ma jo r func t ion promp t fo r re e n t ry

t hum bnail views s elect a s pecif ic cam er a

exit t his f unct ion s ee anot her cam er a

t h u m b n ail views s elect a s p ecif ic cam er a

Produsen atau konsumen sebuah data

Contoh : seseorang, piranti, sensor

Data harus selalu berawal dari suatu tempat dan

Contoh: menghitung pajak, menentukan luas,

Data mengalir melalui sebuah sistem dimulai

 Semua icon harus diberi nama yang

 Tulis sebuah narasi yang menggambarkan

display panel enabled

state transition table

Melihat parsing kata benda/kerja yang diterapkan pada

Fokus pada kemungkinan kehilangan/tidak tercantum...

is pla c e d wit hin

Wa llSe gm e nt Window Door

determineType ( ) determineType ( ) determineType ( )

PlayerHead PlayerBody PlayerArms PlayerLegs

 Dua class analisis sering berhubungan satu dengan yang

is used to build is used to build

1..* 0..* is used to build 0..*

t ime r > lo cke d Time lo cke d

re ad in g co m p arin g n u mb e rOfTrie s > maxTrie s

 Membuat daftar keadaan sistem yang

t imer > lo cked Time

act ivat io n s u cces s fu l act ivat io n s u cces s fu l

use consistent graphical notation and apply textua

be sure to define all acronyms

be sure to include a table of contents; ideally,

write in a simple, unambiguous style (see "editing

always put yourself in the reader's position, "Would

When a structure is described in words, draw a picture

When a structure is described with a picture, try to redraw

When symbolic equations are used, try expressing their

When a calculation is specified, work at least two

Search behind certainty statements—be sure restrictions

Anda mungkin juga menyukai