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