UML Process

From Requirement
 Software Requirement
• Requirements engineering adalah fase terdepan dari
proses rekayasa perangkat lunak (software
engineering), dimana software requirements
(kebutuhan) dari user (pengguna) dan customer
(pelanggan) dikumpulkan, dipahami dan ditetapkan.

• Kebanyakan kegagalan pengembangan software

disebabkan karena adanya:
– Ketidakkonsistenan (inconsistent),
– Ketidaklengkapan (incomplete), maupun
– Ketidakbenaran (incorrect)
dari requirements specification (spesifikasi kebutuhan)
 Software Requirement
• Studi di The Standish Group mencatat bahwa
prosentase akumulatif kegagalan sebuah
project pengembangan software sebagian
besar disebabkan oleh masalah requirements
dan spesifikasinya [Standish-94].
 Software Requirement - Definisi
• Requirements engineering adalah cabang dari
software engineering yang mengurusi masalah
yang berhubungan dengan: tujuan (dunia
nyata), fungsi, dan batasan-batasan pada
sistem software. Termasuk hubungan faktor-
faktor tersebut dalam menetapkan spesifikasi
yang tepat dari suatu software, proses
evolusinya baik berhubungan dengan masalah
waktu maupun dengan software lain [Zave-97]
 Software Requirement
• Requirements engineering dibagi dalam 3 proses
besar yaitu:
– elicitation,
– specification,
– validation and verification.
• Formula ini kemudian juga dikenal dengan
nama The Three Dimensions of Requirements
Engineering
• Proses requirements engineering ini dilakukan
secara iterasi dengan mengakomodasi adanya
feedback dari customer (user).
Software Requirement

Software Requirement Process

 Requirements Elicitation
• Adalah proses mengumpulkan dan memahami requirements
dari user. Kadang masalah yang muncul berakar dari gap
masalah knowledge domain (perbedaan disiplin ilmu yang
dimiliki). Customer adalah expert pada domain yang
softwarenya ingin dikembangkan (domain specialist), dilain
pihak sang pengembang (requirements analyst) adakalanya
sama sekali buta terhadap knowledge domain tersebut

• Gap knowledge domain tersebut yang diharapkan bisa diatasi

dengan adanya interaksi terus menerus dan berulang (iterasi)
antara pengembang dan customer
 Requirements Specification
• Setelah masalah berhasil dipahami, pengembang
mendeskripsikannya dalam bentuk dokumen spesifikasi.
Spesifikasi ini berisi tentang fitur dan fungsi yang diinginkan
oleh customer, dan sama sekali tidak membahas bagaimana
metode pengembangannya.
• IEEE mengeluarkan standard untuk dokumen spesifikasi
requirements yang terkenal dengan nama IEEE Recommended
Practice for Software Requirements Specifications [IEEE-830].
• Dokumen spesifikasi requirements bisa berisi functional
requirements, performance requirements, external interface
requirements, design constraints, maupun quality
requirements.
 Requirements Validation and
Verification
• Setelah spesifikasi requirements berhasil dibuat,
perlu dilakukan dua usaha:
– Validation (validasi), yaitu proses untuk memastikan
bahwa requirements yang benar sudah ditulis.
– Verification (verifikasi), yaitu proses untuk
memastikan bahwa requirements sudah ditulis
dengan benar.

• Proses validasi dan verifikasi ini melibatkan

customer (user) sebagai pihak yang menilai dan
memberi feedback berhubungan dengan
requirements.
 Requirement (Persyaratan)
• Requirement adalah pernyataan yang
mendefinisikan tujuan atau batasan sistem
yang harus terpenuhi
– Perlu dipahami oleh tim pengembang dan
divalidasi oleh para stakeholder dan pengguna
(user)
– Sebagai kriteria penentuan lolos / gagal yang
dapat diverifikasi oleh tim penguji
– Prioritas yang ditetapkan dalam kaitannya dengan
persyaratan lain
 Requirement (Persyaratan)
Requirement dibagi menjadi 2 (dua):
1. Functional Requirement (persyaratan fungsional)
“Functional requirements define what the system or
application will do”
2. Non-functional Requirement (persyaratan non
fungsional)
“A software requirement that describes not what the
software will do, but how the software will do it, for
example software performance requirements, software
external interface requirements, design constraints, and
software quality attributes” IEEE Definition
Non Functional Requirement (NFR)
• Persyaratan perangkat lunak yang
menggambarkan bagaimana perangkat lunak
akan melakukannya, misalnya, persyaratan
kinerja perangkat lunak, persyaratan antarmuka
eksternal perangkat lunak, dan atribut kualitas
perangkat lunak.

• Persyaratan nonfungsional sulit untuk diuji oleh

karena itu, mereka biasanya dievaluasi secara
subyektif
 Contoh Functional & Non Functional
• Contoh Functional & Non Functional requirements
dalam pengembangan Mobile Application:
• Functional Requirement:
– Cross platform compatible and works on most mobile
browser
– Integrates a selected number of popular social networking
sites in one place
– Communicates with social networking APIs
– Uses login and OAuth mechanisms to authorize
– Records and monitors social networking activity
– Stores the data locally Displays total statistics for the user
 Contoh Functional & Non Functional
• Non functional requirements
– Record statistics accurately
– Fast navigation
– Flexibility to choose which sites they want to integrate
out of 3 and do not always have to use all 3. For
example; the user should still be able to use Facebook
and Twitter in the App and leave out YouTube (if they
are not interested inYouTube).
– App should be able to function with chosen sites.
– Should be flexible in terms of being able to integrate
other popular social networking sites too
– Should be available to users to use anytime
 Analisis Berorientasi Objek
Analisis Berorientasi Objek
• Berfokus pada pendefinisian kelas-kelas dan cara
bagaimana mereka saling bekerjasama satu
dengan yang lainnya untuk memenuhi kebutuhan
para pelanggan.

• Pada Paradigma Analysis Design Unified Modeling

Language (UML) merupakan perkakas (tools)
yang digunakan untuk melakukan pemodelan
berorientasi objek
 What is the UML?
• UML: Unified Modeling Language
• UML dapat digunakan untuk memodelkan semua
proses dalam siklus hidup pengembangan dan
seluruh teknologi implementasi yang berbeda
• UML adalah bahasa standar untuk
memvisualisasikan,menspesifiksi, konstruksi, dan
mendokumentasikan artifak dari sistem
perangkat lunak
• UML adalah suatu alat komunikasi untuk team
dan para stakeholders
 Object-oriented Systems

UML Diagram dibagi menjadi 3 kategori:

1. Structure diagrams
2. Behavior diagrams
3. Interaction diagrams
 Structure diagrams
Termasuk pada Structure Diagram meliputi:
• Class diagrams
• Composite structure diagrams
• Component diagrams
• Deployment diagrams
• Object diagrams
• Package diagrams
Structure diagrams
 Behavior diagrams
Termasuk pada Behavior diagrams meliputi:
1. Activity diagrams
2. Use case diagrams
3. State machine diagrams
 Interaction diagrams
Termasuk pada Interaction diagrams meliputi:
1. Sequence diagrams
2. Timing diagrams
3. Communication diagrams
4. Interaction overview diagrams
 UML Process (Kendal, 2011)
1. Sebuah use case diagram, menggambarkan bagaimana sistem
yang digunakan. Analis memulai dengan use case diagram
2. Sebuah activity diagram, menggambarkan aliran keseluruhan
kegiatan. Setiap use case dapat membuat satu diagram
aktivitas
3. Sequence diagram, menunjukkan urutan kegiatan dan
hubungan kelas. Setiap use case dapat membuat satu atau
lebih sequence diagram
4. Class diagrams, menunjukkan kelas dan hubungan. Sequence
diagram digunakan untuk menentukan kelas
5. Statechart diagram, menunjukkan keadaan transisi. Setiap kelas
dapat membuat statechart diagram, yang berguna untuk
menentukan class method
(Kendall and Kendall, 2011)
STATE MACHINE DIAGRAM
 State Machine Diagram
• State Machine Diagram merupakan teknik yang
umum digunakan untuk menggambarkan
behavior sebuah sistem
• Berbagai bentuk State telah ada sejak tahun
1960-an dan teknik berorientasi objek yang paling
awal mengadopsinya untuk menampilkan
behavior
• Dalam pendekatan berorientasi objek, State
Machine Diagram digambarkan untuk suatu Kelas
tunggal yang menunjukkan behavior sebuah
objek tersebut
Notasi State Machine Diagram
 Story
• Dalam suatu kastil yang gelap tersimpanlah
barang-barang berharga dalam suatu lemari
besi. Untuk menunjukkan lubang kunci pada
lemari besi tersebut, harus menggunakan
obor sebagai media penerangan. Hal ini
berlaku bila pintu dalam keadaan tertutup.
Jika lubang kunci sudah terlihat, kunci dapat
dimasukkan untuk membuka lemari besi.
Sebagai prosedur keamanan, lemari tersebut
dapat terbuka jika obor terpasang. Namun jika
obor tsb tidak terpasang, maka akan kastil
akan mengeluarkan monster.
 Example State Machine Diagram
Lemari besi tertutup
Buka
Note:
State
Kunci diputar[Obor
terpasang] / Membuka lemari
besi

Obor diambil [Pintu tertutup] /

Tunggu Terkunci
Menunjukkan lubang kunci

Note: Note: Kunci diputar[Obor tidak

Titik Awal Point / terpasang] / Mengeluarkan
(Start) Transisi monster

Note:
Note:
Titik akhir
Event [Guard] / Activity
(end)
 Penjelasan
• Diagram di atas menunjukkan adanya 3 (tiga) State: Tunggu,
Terkunci, dan Buka.
• Diagram di atas juga menjelaskan mengenai aturan-aturan
untuk berpindah dari satu State ke State lain (Aturan tertulis
dalam Transisi)
• Transisi menunjukkan pergerakan dari suatu State ke State
lain. Transisi memiliki label yang terdiri dari 3 (tiga) bagian:
event [guard] / activity
• Event berupa trigger/pemicu terjadinya peralihan pada state
• Guard menunjukkan adanya kondisi (jika mensyaratkan
adanya kondisi) dalam bentuk boolean
• Activity merupakan behavior yang dieksekusi selama transisi
 Penjelasan [lanj]
• Dalam state Tunggu jika obor diambil dengan pintu
tertutup, maka akan melakukan aktivitas
menunjukkan lubang kunci dan pindah ke state
terKunci

• Pada state Terkunci jika kunci diputar dengan kondisi

obor terpasang maka akan melakukan aktivitas
membuka lemari besi, namun jika kunci diputar
dengan kondisi obor tidak terpasang maka akan
mengeluarkan monster dan selesai
 State
UML mendefinisikan beberapa macam State:
• Simple State
• Composite State
 Simple State
• Suatu Simple State merupakan state yang
tidak memiliki substate, region
• Simple State boleh memiliki Compartment
(ruang), compartment beserta Ruang Aktivitas
Internal / Internal aktivities compartment

Simple state Waiting for Customer Input.

 Simple State
Internal activities compartment
• Terdapat beberapa label sudah ada pada
sistem yang tidak boleh digunakan
• Beberapa lebel tersebut meliputi:
– Entry
– Do
– Exit

Simple state Waiting for Customer Input dengan nama dan ruang
aktivitas internal (entry dan exit)
 Composite State
Composite State didefinisikan sebagai state yang
memiliki substates (nested states)
Composite State terdiri dari 2 (dua) jenis:
1. Simple Composite State: memuat hanya 1 region
2. Orthogonal Composite State: memiliki lebih dari
1 region

Simple composite state Serving Customer has

two substates.
 Contoh Online Banking System
• Contoh model diagram untuk login yang
merupakan bagian dari Online Banking
System.
• Logging in terdiri atas masukan input Social
Security Number dan Personal Id Number
yang berlaku, lalu memutuskan kesahan dari
informasi tersebut.
 Contoh Online Banking System
• Logging in dapat dibagi menjadi empat
tahapan proses, yaitu :
– Getting SSN (masukkan SSN),
– Getting PIN (masukkan PIN),
– Validating (periksa kesahannya), dan
– Rejecting (keluar).
Online Banking System
• Proses peralihan digambarkan dengan panah
dari satu state ke yang lainnya. Event
(peristiwa) atau condition (keadaan) yang
menyebabkan perubahan dituliskan pada
samping panah
• Diagram ini mengandung dua self-transition
(transisi sendiri), satu pada getting SSN dan
lainnya pada getting PIN
• Keadaan awal Start (black circle /lingkar
hitam) adalah dummy (model) untuk memulai
action (kegiatan). Keadaan akhir juga keadaan
model yang menghentikan kegiatan
• Aksi yang terjadi sebagai hasil dari suatu
peristiwa atau keadaan ditandai dalam bentuk
/action.
• Pada Validating State, obyek tidak menunggu
peristiwa dari luar untuk menyebabkan suatu
perubahan. Sebagai gantinya melakukan suatu
activity (aktifitas). Hasil dari aktifitas tersebut
menentukan keadaan berikutnya dari obyek
tersebut.
SEQUENCE & COLLABORATION
DIAGRAM
Example Sequence Hotel Reservation
 Penjelasan Sequence
• Gambar di atas adalah diagram Sequence
untuk pembuatan Hotel Reservation. Obyek
yang mengawali urutan message adalah
‘aReservation Window
• ‘Reservation window’ mengirim pesan
makeReservation() ke ‘HotelChain’. Kemudian
‘HotelChain’ mengirim pesan yang sama ke
‘Hotel’. Bila ‘Hotel’ punya kamar kosong, maka
dibuat ‘Reservation’ dan ‘Confirmation’.
 Penjelasan Sequence
• Pada gambar diagram , terlihat bahwa ‘Hotel’
telah melakukan pemanggilan diri sendiri
untuk pemeriksaan jika ada kamar kosong.
Bila benar, maka ‘Hotel’ membuat
‘Reservation’ dan ‘Confirmation’.
• Pemanggilan diri sendiri disebut dengan
iterasi. Expression yeng dikurung dengan “[ ]”,
adalah condition (keadaan kondisi).
• Diagram Collaboration juga merupakan
diagram interaction.
• Diagram membawa informasi yang sama
dengan diagram Sequence, tetapi lebih
memusatkan atau memfokuskan pada
kegiatan obyek dari waktu pesan itu
dikirimkan
Collaboration Diagram
PACKAGE DIAGRAM
 Package Diagram
• Untuk mengatur pengorganisasian diagram
Class yang kompleks, dapat dilakukan
pengelompokan kelas-kelas berupa package
(paket-paket).
• Package adalah kumpulan elemen-elemen
logika UML. Gambar di bawah ini mengenai
model bisnis dengan pengelompokan kelas-
kelas dalam bentuk paket-paket
Contoh Package Diagram
COMPONENT DIAGRAM
 Component Diagram
• Component diagram menggambarkan struktur dan
hubungan antar komponen piranti lunak, termasuk
ketergantungan (dependency) di antaranya.
• Komponen piranti lunak adalah modul baik berisi
source code, binary code, library maupun executable
• Pada umumnya komponen terbentuk dari beberapa
class dan/atau package, tapi dapat juga dari
komponen-komponen yang lebih kecil.
• Komponen dapat juga berupa interface, yaitu
kumpulan layanan yang disediakan sebuah
komponen untuk komponen lain.
Contoh Component Diagram
applet1.class applet1.java

Demo.html applet2.class applet2.java

logo.gif
DEPLOYMENT DIAGRAM
 Deployment Diagram
• Deployment/physical diagram menggambarkan detail
bagaimana komponen di-deploy dalam infrastruktur
sistem, di mana komponen akan terletak (pada mesin,
server atau piranti keras apa)
• Sebuah node adalah server, workstation, atau piranti
keras lain yang digunakan untuk men-deploy
komponen dalam lingkungan sebenarnya. Hubungan
antar node (misalnya TCP/IP) dapat didefinisikan
dalam diagram ini.
• Artifak merupakan manifestasi fisik dari perangkat
lunak yang di-deploy. Atifak dapat berupa file-file
seperti .exe, binary, jar, assemby, script, file data, file
konfigurasi, dokuman html dsb
Contoh Deployment Diagram
Contoh Deployment