BAB II
DASAR TEORI
2.1. UML ( Unified Modelling Language )
UML ( Unified Modelling Language ) merupakan bahasa
pemodelan standart. UML juga memiliki sintaks dan semantic, dalam arti
ada aturan – aturan yang harus diikuti. Bagaimana elemen – elemen yang
dibuat berhubungan satu dengan lainnya harus mengikuti standart yang
ada. UML bukan hanya sekedar diagram, tetapi juga menceritakan
konteksnya. Dalam pengaplikasian UML yaitu merancang perangkat
lunak, sarana komunikasi antara perangkat lunak dengan proses bisnis,
menjabarkan sistem secara rinci untuk analisa dan mencari apa yang
diperlukan sistem, dan juga mendokumentasikan sistem yang ada, proses –
proses yang ada dan dokumentasinya.
2.1.1. Gambaran Umum UML
Gambaran umum mengenai UML dapat dijelaskan
berdasarkan kegunaan dari UML itu sendiri, yaitu:
1. Modeling Language, UML sebagai bahasa untuk pemodelan
system
UML merupakan bahasa pemodelan yang memiliki
pembendaharaan kata dan cara untuk mempresentasikan secara
fokus pada konseptual dan fisik dari suatu sistem. Contoh untuk
sistem software yang intensive membutuhkan bahasa yang
menunjukkan pandangan yang berbeda dari arsitektur sistem, ini
sama seperti menyusun/mengembangkan software development life
cycle. Dengan UML akan memberitahukan kita bagaimana untuk
membuat dan membaca bentuk model yang baik, tetapi UML tidak
dapat memberitahukan model apa yang akan dibangun dan kapan
akan membangun model tersebut. Ini merupakan aturan dalam
software development process.
2. Visualizing, UML sebagai bahasa untuk menggambarkan system
UML tidak hanya merupakan rangkaian simbol grafikal,
cukup dengan tiap simbol pada notasi UML merupakan penetapan
semantik yang baik. Dengan cara ini, satu pengembang dapat
menulis model UML dan pengembang lain atau perangkat yang
sama lainnya dapat mengartikan bahwa model tersebut tidak
ambigu. Hal ini akan mengurangi error yang terjadi karena
perbedaan bahasa dalam komunikasi model konseptual dengan
model lainnya.UML menggambarkan model yang dapat dimengerti
dan dipresentasikan ke dalam model tekstual bahasa pemograman.
Contohnya kita dapat menduga suatu model dari sistem yang
berbasis web tetapi tidak secara langsung dipegang dengan
mempelajaricode dari sistem. Dengan model UML maka kita dapat
memodelkan suatu sistem web tersebut dan direpresentasikan ke
bahasa pemrograman.UML merupakan suatu model eksplisit yang
menggambarkan komunikasi informasi pada sistem. Sehingga kita
tidak kehilangan informasi code implementasi yang hilang
dikarenakan developer memotong coding dari implementasi.
3. Specifying, UML sebagai bahasa untuk menspesifikasikan
sistem
Maksudnya membangun model yang sesuai, tidak ambigu
dan lengkap. Pada faktanya UML menunjukan semua spesifikasi
keputusan analisis, desain dan implementasi yang penting yang
harus dibuat pada saat pengembangan dan penyebaran dari sistem
software intensif.
4. Constructing, UML sebagai bahasa untuk membangun system.
UML bukan bahasa pemograman visual, tetapi model UML
dapat dikoneksikan secara langsung pada bahasa pemograman
visual. Maksudnya membangun model yang dapat di mapping ke
bahasa pemograman seperti java, C++, VB atau tabel pada
database relational atau penyimpanan tetap pada database
berorientasi object.
5. Documenting, UML sebagai bahasa untuk pendokumentasian
system.
Maksudnya UML menunjukan dokumentasi dari arsitektur
sistem dan detail dari semuanya.UML hanya memberikan bahasa
untuk memperlihatkan permintaan dan untuk tes. UML
menyediakan bahasa untuk memodelkan aktifitas dari perencanaan
project dan manajemen pelepasan (release management).
2.1.2. Tujuan penggunaan UML adalah, sebagai berikut:
1. Memodelkan suatu sistem (bukan hanya perangkat lunak) yang
menggunakan konsep berorientasi object
2. Menciptakan suatu bahasa pemodelan yang dapat digunakan
baik oleh manusia maupun mesin.
2.1.3. Diagram – diagram UML
Diagram – diagram pada UML ( Unified Modelling Language )
adalah sebagai berikut :
- Diagram Use case (Use case diagram)
- Diagram Kelas (Class diagram)
- Diagram Paket (Package diagram)
- Diagram Komponen (Component diagram)
- Diagram Deployment (Deployment diagram)
- Diagram Statechart (Statechart diagram)
- Diagram Aktivitas (Activity diagram)
- Diagram interaksi dan sequence (Interaction and Sequence
diagram)
- Diagram komunikasi (Communication diagram)
2.2. Star UML
StarUML adalah sebuah proyek open source untuk
pengembangan secara cepat, fleksibel, extensible, featureful, dan
bebas-tersedia. UML /platform MDA berjalan pada platform Win32.
Tujuan dari proyek StarUML adalah untuk membangun sebuah alat
pemodelan perangkatlunak dan juga platform yang menarik adalah
pengganti alat UML komersial seperti Rational Rose, Together dan
sebagainya.
StarUML mendukung UML (Unified Modeling Language).
Berdasarkan pada UML version 1.4 dan dilengkapi 11 macam
diagram yang berbeda, selanjutnya mendukung notasi UML 2.0 dan
juga mendukung pendekatan MDA (Model DrivenArchitecture)
dengan dukungan konsep UML. StarUML dapat memaksimalkan
produktivitas dan kualitas dari suatu software project.
UML 2.0 itu sendiri adalah UML standar yang terus berkembang
dan dikelola oleh OMG (Object Management Group). Baru-baru ini,
UML 2,0 direlease dan StarUML dukungan UML 2.0 yang akan
mendukung standar terbaru UML.
Untuk dapat menggunakan StarUML tentunya terlebih dahulu
harus melakukan proses penginstalan sebagai berikut :
1. Buka Installer StarUML
Gambar 2. 1. Buka installer StarUML
2. Pilih next
3. Pilih I accept the aggrement lalu pilih next
4. Pilih next lagi
Gambar 2. 2. Pilih next
Gambar 2. 3. Pilih next lagi
Gambar 2. 4. Lalu next lagi untuk memulai penginstalan
5. Lalu StarUML akan diinstal
6. Pilih Finish untuk membuka
7. Tampilan utama StarUML
Gambar 2. 5. Proses penginstallan
Gambar 2. 6. Pilih Finish untuk membuka
Gambar 2. 7. Tampilan utama StarUML
2.3. Use Case Diagram
Use-case diagram merupakan model diagram UML yang
digunakan untuk menggambarkan requirement fungsional yang
diharapkan dari sebuah sistem. Usecase diagram menekankan pada
“siapa” melakukan “apa” dalam lingkungan sistem perangkat lunak akan
dibangun. Use-case diagram sebenarnya terdiri dari dua bagian besar;
yang pertama adalah use case diagram (termasuk gambar use case
dependencies) dan use case description.
Use-case diagram adalah gambaran graphical dari beberapa atau
semua actor, use-case, dan interaksi diantara komponen-komponen
tersebut yang memperkenalkan suatu sistem yang akan dibangun. Use-
case diagram menjelaskan manfaat suatu sistem jika dilihat menurut
pandangan orang yang berada di luar sistem. Diagram ini menunjukkan
fungsionalitas suatu sistem atau kelas dan bagaimana sistem tersebut
berinteraksi dengan dunia luar.
Use-case diagram dapat digunakan selama proses analisis untuk
menangkap requirement system dan untuk memahami bagaimana sistem
seharusnya bekerja. Selama tahap desain, use-case diagram berperan
untuk menetapkan perilaku (behavior) sistem saat diimplementasikan.
Dalam sebuah model mungkin terdapat satu atau beberapa use-case
diagram. Kebutuhan atau requirements system adalah fungsionalitas apa
yang harus disediakan oleh sistem kemudian didokumentasikan pada
model use-case yang menggambarkan fungsi sistem yang diharapkan (use-
case), dan yang mengelilinginya (actor), serta hubungan antara actor
dengan use-case (use-case diagram) itu sendiri.
Use case class digunakan untuk memodelkan dan menyatakan unit
fungsi/layanan yang disediakan oleh sistem (atau bagian sistem:
subsistem atau class) ke pemakai.
Use case dapat dilingkupi dengan batasan sistem yang diberi label
nama sistem.
Use case adalah sesuatu yang menyediakan hasil yang dapat diukur ke
pemakai atau sistem eksternal.
Karakteristik :
Use cases adalah interaksi atau dialog antara sistem dan actor,
termasuk pertukaran pesan dan tindakan yang dilakukan oleh sistem.
Use cases diprakarsai oleh actor dan mungkin melibatkan peran actor
lain. Use cases harus menyediakan nilai minimal kepada satu actor.
Use cases bisa memiliki perluasan yang mendefinisikan tindakan
khusus dalam interaksi atau use case lain mungkin disisipkan.
Use case class memiliki objek use case yang disebut skenario.
Skenario menyatakan urutan pesan dan tindakan tunggal.
Syarat penamaan use case adalah nama didefinisikan sasimpel mungkin
dan dapat dipahami. Ada dua hal utama pada use case yaitu pendefinisian
apa yang disebut aktor dan use case.
Aktor merupakan orang, proses, atau sistem lain yang berinteraksi
dengan sistem informasi yang akan dibuat diluar sistem informasi
yang akan dibuat itu sendiri, jadi walaupun simbol dari aktor adalah
gambar orang , tapi aktor belum tentu merupakan orang.
Usecase merupakan fungsionalitas yang disediakan sistem sebagai
unit-unit yang saling bertuka pesan antar unit atau aktor.
Tabel 2.1. Simbol-Simbol Usecase Diagram
Simbol Deskripsi
Usecase Fungsionalitas yang disediakan sistem
sebagai unit – unit yang saling
bertukar pesan antar unit atau actor,
biasanya dinyatakan dengan
menggunakan kata kerja di awal frase
nama usecase
Aktor Orang,proses, atau sistem lain yang
berinteraksi dengan sistem informasi
yang akan dibuat diluar sistem
informasi yang akan dibuat itu sendiri,
jadi walaupun symbol dari actor
adalah gambar orang, tapi actor belum
tentu merupakan orang. Biasanya
dinyatakan menggunakan kata benda
di awal frase nama aktor
Asosiasi ( Association ) Komunikasi antara aktor dan Usecase
yang berpartisipasi pada usecase atau
usecase memiliki interaksi dengan
aktor.
Ekstensi (external) Relasi usecase tambahan ke sebuah
usecase dimana usecase yang
ditambahkan dapat berdiri sendiri
walau tanpa usecase tambahan itu,
mirip dengan prinsip inheritance pada
pemrograman berorientasi objek,
biasanya usecase tambahan memiliki
nama depan yang sama dengan
usecase yang ditambahkan, misalnya :
Arah panah mengarah pada use case
yang ditambahkan, biasanya usecase
yang menjadi Extend-nya merupakan
jenis yang sama dengan usecase yang
menjadi induknya.
Generalisasi (generalization) Hubungan generalisasi dan spesialisasi
(Umum-Khusus) antara dua buah
usecase dimana fungsi yang satu
adalah fungsi yang lebih umum dari
lainnya, misalnya :
Arah panah mengarah pada usecase
yang menjadi generalisasinya (umum)
Menggunakan / include /uses Relasi usecase tambahan ke sebuah
usecase dimana usecase yang
ditambahkan memerlukan usecase ini
untuk menjalankan fungsinya atau
sebagai syarat dijalankan usecase ini.
Ada dua sudut pandang yang cukup
besar mengenai include di usecase :
Include berarti usecase yang
ditambahkan akan selalu
dipanggil saat usecase tambahan
dijalankan, misalnya :
Include berarti usecase yang
tambahan akan selalu melakukan
pengecekan apakah usecase yang
ditambahkan telah dijalankan
sebelum usecase tambahan
dijalankan, misalnya :
Kedua interprestasi di atas dapat
dianut salah satu atau keduanya
tergantung pada pertimbangan dan
interpretasi yang dibutuhkan.
Untuk lebih jelasnya bagaimanakah bentuk dari use case itu sendiri, maka ini
adalah contoh Use Case Diagram perpustakaan sebagai berikut :
2.4. Class Diagram
Gambar 2. 8. Use Case diagram perpustakaan
Diagram kelas atau class diagram menggambarkan struktur sistem
dari segi pendefinisian kelas-kelas yang akan dibuat untuk membangun
sistem. Kelas memiliki apa yang disebut atribut dan metode atau operasi.
Stribut merupakan variable-variable yang dimiliki oleh suatu kelas
Operasi atau metode adalah fungsi-fungsi yang dimiliki oleh suatu
kelas.
Diagram kelas dibuat agar pembuat program atau programmer
membuat kelas-kelas sesuai rancangan di dalam diagram kelas agar antara
dokumentasi perancangan dan perangkat lunak sinkron. Banyak berbagai
kasus, perancangan kelas yang dibuat tidak sesuai dengan kelas-kelas yang
dibuat pada perangkat lnak, sehingga rtidaklah ada gunanya lagi sebuah
perancangan karena apa yang dirancang dan hasil jadinya tidak sesuai.
Kelas-kelas yang ada pada struktur sistem harus dapat melakukan
fungsi-fungsi sesuai dengan kebutuhan sistem sehingga pembuat perangka
lunak atau programmer dapat membuat kelas-kelas di dalam program
perangkat lunak sesuai dengan perancangan diagram kelas. Susunan
struktur kelas yang baik pada diagram kelas sebaiknya memiliki jenis-jenis
kelas berikut :
Kelas main : kelas yang memiliki fungsi awal dieksekusi ketika
sistem dijalankan
Kelas yang menangani tampilan sistem (view) : kelas yang
mendefinisikan dan mengatur tampilan ke pemakai.
Kelas yang diambil dari pendefinisian use case (cotroller) : kelas
yang menangani fungsi-fungsi yang harus ada diambil dari
pendefinisian use case, kelas ini biasanya disebut dengan kelas
proses yang menangani proses bisnis pada perangkat lunak.
Kelas yang diambil dari pendefinisian data (model).
Kelas yang digunakan untuk memegang atau membungkus data
menjadi sebuah kesatuan yang diambil maupun akan disimpan ke
basis data. Semua tabel yang dibuat di basis data dapat dijadikan
kelas, namun untuk tabel dari hasil relasi atau atribut multivalue
pada ERD dapat dijadikan kelas tersendiri dapat juga tidak
diasalkan pengaksesannya dapat dipertanggungjawabkan atau tetap
ada didalam perancangan kelas.
2.2.1. Penamaan kelas
Masing-masing kelas harus mempunyai nama yang unik.
Sebagian besar organisasi mempunyai konvensi penamaan sendiri
untuk menamakan kelas-kelas yang dibuatnya. Umumnya kelas-
kelas dinamakan menggunakan kata benda tunggal.
Nama kelas tidak menggunkan spasi. Ini dilakukan karena
alasan praktis, dimana beberapa bahasa pemrograman tidak
membolehkan adanya spasi. Hal lainnya yang perlu diperhatikan
adalah bahwa nama kelas hendaknya pendek, cukup untuk
menjelaskan apa yang akan kelas lakukan.
Jadi penamaan kelas sangat tergantung pada organisasi kita.
Jika kita mempunyai kelas yang digunakan dalam organisasi yang
bersangkutan, tetapi yang jelas bahwa hal tersebut harus konsisten
digunakan untuk keseluruhan kelas-kelas yang dibuatnya.
2.2.2. Visibilitas kelas
Pilihan visibilitas menentukan dapat tidaknya sebuah kelas
dilihat dari luar paket. Ada 3 pilihan visibilitas untuk sebuah kelas
yaitu :
1. Public
2. Menyatakan bahwa sebuah kelas dapat dilihat dari kelas-kelas
lainnya dalam system.
3. Protected atau private
4. Menyatakan bahwa sebuah kelas dapat dilihat dari kelas-kelas
majemuk (nested), friends, atau dari kelas itu sendiri.
5. Package atau implementation.
6. Menyatakan bahwa sebuah kelas dapat dilihat hanya oleh kelas
yang lain dalam paket yang sama.
Simbol – symbol untuk membuat class diagram yang ada pada
program StarUML dijelaskan pada table dibawah ini.
Tabel 2.2. Simbol-Simbol Class Diagram
Simbol Deskripsi
Kelas Kelas pada struktur sistem
Antarmuka (Interface) Sama dengan konsep interface dalam
pemrograman berorientasi objek
Asosiasi Relasi antarkelas dengan makna
umum, asosiasi biasanya juga disertai
dengan multiplicity
Asosiasi berarah (directed
association)
Relasi antarkelas dengan makna kelas
yang satu digunakan oleh kelas yang
lain, asosiasi berarah biasanya juga
disertai dengan multiplicity
Generalisasi
(generalization)
Relasi antarkelas dengan makna
generalisasi-spesialisasi (umum-
khusus)
Kebergantungan
(dependency)
Relasi antarkelas dengan makna
kebergantungan antarkelas
Agregasi (Aggregation) Relasi antarkelas dengan makna
semua bagian (whole-part)
Untuk gambar dari class diagram adalah sebagai berikut :
2.5. Sequence Diagram
Diagram sequence menggambarkan kelakuan objek pada use case
dengan mendeskripsikan waktu hidup objek dan message yang dikirimkan
dan diterima antar objek. Oleh karena itu untuk menggambarkan diagram
sequence maka harus diketahui objek – objek yang terlibat dalam sebuah
use case beserta metode – metode yang dimiliki kelas yang diinstasiasi
menjadi objek itu. Membuat diagram sequence juga dibutuhkan untuk
melihat scenario yang ada pada use case.
Diagram sequence biasa digunakan untuk menggambarkan
skenario atau rangkaian langkah – langkah yang dilakukan sebagai
respons dari sebuah event untuk menghasilkan output tertentu. Diawali
Gambar 2. 9. class diagram perpustakaan
dari apa yang men-triger aktivitas tersebut, proses dan perubahan apa saja
yang terjadi secara internal dan output apa yang dihasilkan. Banyaknya
diagram sequence yang harus digambar adalah minimal sebanyak
pendefenisian use case yang memiliki proses sendiri atau yang penting
semua use case yang telah didefinisikan interaksi jalannya pesan sudah
dicakup pada diagram sequence sehingga yang harus dibuat juga semakin
banyak.
Tabel 2.3. Simbol-Simbol Sequence Diagram
Simbol Deskripsi
Objek Menyatakan objek yang
berinteraksi pesan
Garis hidup (Lifeline) Menyatakan kehidupan suatu
objek
Waktu aktif Menyatakan objek dalam keadaan
aktif dan berinteraksi, semua yang
terhubung dengan waktu aktif ini
adalah sebuahtahapan yang
dilakukan di dalamnya. Aktor
tidak memiliki waktu aktif.
Stimulus Menyatakan suatu objek
mengirimkan pesan untuk
menjalankan operasi yang ada
pada objek lain
Sequence Diagram terdiri atas dimensi vertical (waktu) dan
dimensi horizontal (objek-objek yang terkait). Masing – masing objek,
termasuk actor memiliki lifeline vertical. Sequence Diagram berupa
message yang digambarkan terhadap waktu, message digambarkan sebagai
garis berpanah dari satu objek ke objek lainnya. Pada fase berikutnya,
message akan dipetakan menjadi operasi / metode dari class. Activation
bar menunjukan lamanya eksekusi sebuah proses, biasanya diawali
dengan diterimanya sebuah message. Untuk objek – objek yang memiliki
sifat khusus, standart UML mendefinisikan icon khusus untuk objek
boundary, controller dan persistent entity.
Gambar dari Sequence Diagram melihat pustaka adalah seperti dibawah
ini :
lalu untuk sequence diagram memasukkan pustaka sebagai berikut :
Gambar 2. 10. Sequence diagram melihat pustaka
Lalu selanjutnya adalah sequence diagram mengubah anggota berikut ini :
Gambar 2. 11. Sequence diagram memasukkan anggota
Lalu terakhir adalah sequence diagram menghapus anggota
2.6. Activity Diagram
Diagram aktivitas atau activity diagram menggambarkan workflow
(aliran kerja) atau aktivitas dari sebuah sistem atau proses bisnis atau menu
yang ada pada perangkat lunak. Yang perlu diperhatikan disini adalah
bahwa diagram aktivitas menggambarkan sistem bukan apa yang
dilakukan aktor, jadi aktivitas yang dapat dilakukan oleh sistem.
Diagram aktivitas juga banyak digunakan untuk mendefinisikan hal – hal
berikut :
Rancangan proses bisnis dimana setiap urutan aktivitas yang
digambarkan merupakan proses bisnis sistem yang didefinisikan.
Urutan atau pengelompokan tampilan dari sistem / user interface
dimana setiap aktivitas dianggap memiliki sebuah rancangan
antarmuka tampilan.
Rancangan pengujian dimana setiap aktivitas dianggap memerlukan
sebuah pengujian yang perlu didefinisikan kasus ujinya
Rancangan menu yang ditampilkan pada perangkat lunak.
Tabel 2.4. Simbol-Simbol Activity Diagram
Simbol Deskripsi
Status awal (Initial state) Status awal aktivitas sistem, sebuah
diagram aktivitas memiliki sebuah
status awal.
Aktivitas Aktivitas yang dilakukan sistem,
aktivitas biasanya diawali dengan kata
kerja.
Decision Asosiasi jika ada pilihan aktivitas lebih
dari satu
Synchronization (fork, join) Asosiasi untuk menggambarakan
penggabungan (join) maupun
percabangan (fork) aktivitas.
Status Akhir (Final state) Status akhir yang dilakukan sistem,
sebuah diagram aktivitas memiliki
sebuah status akhir.
Swimlane
Atau
Memisahkan organisasi bisnis yang
bertanggung jawab terhadap aktivitas
yang terjadi.
Activity Diagram biasanya dipakai pada Business Modelling untuk
memperlihatkan urutan aktifitas proses bisnis. Struktur diagram ini mirip
Flowchart atau Data Flow Diagram pada perancangan terstruktur. Akan
sangat bermanfaat apabila saat membuat diagram ini terlebih dahulu dalam
memodelkan sebuah proses untuk membantu memahami proses secara
keseluruhan. Activity diagram dibuat berdasarkan sebuah atau beberapa
usecase pada usecase diagram.
Untuk gambar dari Activity Diagram adalah seperti dibawah ini :
2.7. Component Diagram
Diagram komponen atau component diagram dibuat untuk
menunjukan organisasi dan ketergantungan diantara kumpulan komponen
dalam sebuah sistem. Diagram komponen fokus pada komponen sistem
yang dibutuhkan dan ada di dalam sistem. Diagram komponen juga dapat
digunakan untuk memodelkan hal – hal berikut :
Source Code program perangkat lunak
Komponen executable yang dilepas ke user
Basis data secara fisik
Sistem yang harus beradaptasi dengan sistem lain
Gambar 2. 14. Activity diagram
Framework system, framework pada perangkat lunak merupakan
kerangka kerja yang dibuat untuk memudahkan pengembangan dan
pemeliharaan aplikasi, contohnya seperti Struts dari Apache yang
menggunakan prinsip desain Model-View-Controler (MVC)
dimana Source code program dikelompokkan berdasarkan
fungsinya seperti pada gambar berikut ini :
Dimana controller berisi Source code yang menangani request dan
validasi, model berisi source code yang menangani manipulasi data dan
business logic dan view berisi source code yang menangani tampilan.
Komponen dasar yang biasanya ada dalam suatu sistem adalah sebagai
berikut:
Komponen User interface yang menangani tampilan
Komponen Business process yang menangani fungsi-fungsi proses
bisnis.
Komponen data yang menangani manipulasi data
Komponen security yang menangani keamanan sistem.
Komponen lebih terfokus pada penggolongan secara umu fungsi – fungsi
yang diperlukan. Berikut adalah symbol – symbol standart yang biasa
digunakan untuk membuat component diagram dengan StarUML :
Gambar 2. 15. Model view controler
Tabel 2.5. Simbol-Simbol Component Diagram
Simbol Deskripsi
Package Package erupakan sebuah
bungkusan dari satu atau lebih
komponen
Komponen Komponen sistem
Ketergantungan (Dependency) Kebergantungan antar komponen,
arah panah mengarah pada
komponen yang dipakai
Antarmuka / Interface Sama dengan interface pada
pemrograman berorientasi objek,
yaitu sebagai antarmuka
komponen agar tidak mengakses
langsung komponen.
Link Relasi antar komponen
Untuk gambar dari Component Diagram adalah sebagai berikut :
Gambar 2. 16. Component diagram