Catatan Kuliah
Rekayasa Perangkat Lunak
(Software Engineering)
Software Engineering: A Practitioner’s Approach, 6/e
Chapter 8
Pemodelan Analisis
copyright © 1996, 2001, 2005
R.S. Pressman & Associates, Inc.
M. Idham Ananta Timur, S.T., M.Kom
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.
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 kapda rekayasa
kebutuhan sebelumnya
Membangun model yang dapat menggambarkan skenario user,
Sebuah Jembatan
syste m
de scription
analysis
mode l
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.
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
Analisis Domain
Tentukan domain yang ingin diinvestigasi.
Kumpulkan contoh representatif aplikasi pada
domain tersebut.
Analisis setiap aplikasi pada contoh.
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
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
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)
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
Apakah Relationship?
Relationship
–
menandakan kaitan, sebuah
fakta yang harus diingat oleh sistem, tidak
dikomputasi atau diturunkan secara mekanis
Notasi ERD
(0, m)
(1, 1)
object
relationship
object
1
2
Satu bentuk umum:
(0, m)
(1, 1)
object
1
relationship
object
2
Bentuk Umum yang lain:
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
ERD: sebuah contoh
(1,1)
places
(1,m)
Customer
request
for service
generates
(1,n)
task table
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
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
Apakah Class?
external entities
things
occurrences
roles
organizational units
places
structures
class name
attributes:
Enkapuslasi/Penyembunyian
Objek mengenkapsulasi
Baik data dan prosedur
Logis yang dibutuhkan
Untuk manipulasi
data
Hierarki Class
Chair
Table
Desk
”Chable"
instances of Chair
PieceOfFurniture (superclass)
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.
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 ?
Use-Cases
Sebuah skenario yang menggambarkan
rangkaian kegunaan pada sistem
actors mewakili peran orang atau piranti yang
dimaikan ketika sistem berfungsi
users dapat berperan sebagai lebih dari satu
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
Use-Case Diagram
homeowner
Access camera surveillance via t he
Int ernet
Conf igure Saf eHome syst em paramet ers
Set alarm
cameras
Activity Diagram
Melengkapi use-case dengan menyediakan representasi diagram
dari aliran prosedural.
ent er password and user ID
selec t major f unc t ion
valid passwor ds/ ID
prompt f or reent ry
invalid passwor ds/ ID
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
ent er pas sword
select surveillance
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
Model Aliran
Setiap sistem berbasis komputer
Adalah sebuah transformasi informasi
computer
based
system
Notasi Model Aliran
Entitas Eksternal
proses
Aliran data
Entitas Eksternal
Produsen atau konsumen sebuah data
Contoh : seseorang, piranti, sensor
Contoh lain : sistem berbasis komputer
Proses
Sebuah transformer data
(mengubah input menjadi output)
Contoh: menghitung pajak, menentukan luas,
Memformat laporan, menampilkan grafik
Aliran Data
Data mengalir melalui sebuah sistem dimulai
Sebagai input dan ditransformasi menjadi
output
compute
triangle
area
base
height
Menyimpan Data
Data disimpan untuk digunakan lagi.
look-up
sensor
data
sensor #
report required
sensor #, type,
location, age
sensor data
sensor number
type,
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
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)
Contoh Level 0 DFD
user
processing
request
video
source
video signal
NTSC
digital
video
processor
requested
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
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
Spesifikasi Proses (PSPEC)
PSPEC
naratif
pseudocode (PDL)
persamaan
tabel
Diagram dan atau grafik
Maps into
Setelah DFD?
analysis 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
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
Control Flow Diagram
read
operator
input
manage
copying
display panel enabled
beeper on/off
start
Control Specification (CSPEC)
CSPEC dapat berupa:
state diagram
(sequential spec)
state transition table
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
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
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.
Kriteria memilih class
Layanan yang dibutuhkan
Beberapa atribut
Atribut umum
Operasi umum
Class Diagram
verific ationPhoneNumber sy stemStatus
delayTime telephoneNumber mas terPassw ord temporaryPass word numberTries
Class name
attributes
Class Diagram
is placed wit hin
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
Pemodelan CRC
Clas s:
Description:
Re sponsibility:
Collaborator:
Clas s:
Description:
Re sponsibility:
Collaborator:
Clas s:
Description:
Re sponsibility:
Collaborator:
Clas s:
FloorPlan
Description:
Re sponsibility:
Collaborator:
incorporates w alls, doors and w indow s show s position of video cameras defines floor plan name/type manages floor plan positioning scales f loor plan for display scales f loor plan for display
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;
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
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
Composite Aggregate Class
Player
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
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
Multiplicity
WallSegm ent Window Door Wall
is used to build is used to build
is used to build 1..*
1 1 1
Dependencies
Camera
Displa yWindow
{passw ord}
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
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.
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
State Diagram for the ControlPanel Class
password = incorrect & numberOfTries < maxTriespassword = correct
act iv at ion successful key hit
do: validat ePassw ord
numberOfTries > maxTries t imer < lockedTime
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
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
Sequence Diagram
select in g t imer > lo cked Time
A A
Figure 8 .2 7 Sequence diagram (part ial) f or Saf eHome securit y f unct ion
