BAB 1
PENDAHULUAN
A. Latar Belakang
Objek
adalah kombinasi antara struktur data dan perilaku dalam satu entitas dan mempunyai nilai tertentu yang
membedakan entitas tersebut. Pengertian berorientasi
objek berarti pengorganisasian perangkat lunak sebagai kumpulan dari objek tertentu yang memiliki struktur
data dan perilakunya. Konsep fundamental dalam
analisis sistem berorientasi objek adalah objek itu sendiri.
UML
(Unified Modeling Language) adalah metode pemodelan (tools / model) secara visual sebagai sarana untuk
merancang dan atau membuat software berorientasi
objek dan memberikan standar penulisan sebuah sistem untuk pengembangan sebuah software yang
dapat menyampaikan beberapa informasi untuk
proses implementasi pengembangan software.
Karena
berorientasi objek makasemua elemen dan diagram berbasiskan pada paradigma object oriented, oleh karena itu
UML dapat secara langsung dihubungkan ke
berbagai bahasa pemograman atau bahkan dihubungkan secara langsung ke dalam sebuah object – oriented database.
B. Tujuan
Tujuan dari pembuatan makalah ini
adalah :
1. Menjelaskan
tentang sistem berorientasi objek
2. Menjelaskan
tentang UML (Unified Modeling Language)
3. Hubungan
sistem berorientasi objek dengan UML (Unified Modeling Language)
BAB II
PEMBAHASAN
A. Sistem
Berorientasi Objek
Pemrograman
berorientasi objek (Inggris: object-oriented programming disingkat OOP)
merupakan paradigma pemrograman yang berorientasikan kepada objek. Semua data
dan fungsi di dalam paradigma ini dibungkus dalam kelas-kelas atau objek-objek.
Bandingkan dengan logika pemrograman terstruktur. Setiap objek dapat menerima
pesan, memproses data, dan mengirim pesan ke objek lainnya,
Model
data berorientasi objek dikatakan dapat memberi fleksibilitas yang lebih,
kemudahan mengubah program, dan digunakan luas dalam teknik piranti lunak skala
besar. Lebih jauh lagi, pendukung OOP mengklaim bahwa OOP lebih mudah
dipelajari bagi pemula dibanding dengan pendekatan sebelumnya, dan pendekatan
OOP lebih mudah dikembangkan dan dirawat.
Konsep
dasar dari Pemrograman Berorientasi Objek Pemrograman orientasi-objek
menekankan konsep berikut:
1.
Kelas — kumpulan atas definisi data dan
fungsi-fungsi dalam suatu unit untuk suatu tujuan tertentu. Sebagai contoh
'class of dog' adalah suatu unit yang terdiri atas definisi-definisi data dan
fungsi-fungsi yang menunjuk pada berbagai macam perilaku/turunan dari anjing.
Sebuah class adalah dasar dari modularitas dan struktur dalam pemrograman
berorientasi object. Sebuah class secara tipikal sebaiknya dapat dikenali oleh
seorang non-programmer sekalipun terkait dengan domain permasalahan yang ada,
dan kode yang terdapat dalam sebuah class sebaiknya (relatif) bersifat mandiri
dan independen (sebagaimana kode tersebut digunakan jika tidak menggunakan
OOP). Dengan modularitas, struktur dari sebuah program akan terkait dengan
aspek-aspek dalam masalah yang akan diselesaikan melalui program tersebut. Cara
seperti ini akan menyederhanakan pemetaan dari masalah ke sebuah program
ataupun sebaliknya.
2.
Objek - membungkus data dan fungsi
bersama menjadi suatu unit dalam sebuah program komputer; objek merupakan dasar
dari modularitas dan struktur dalam sebuah program komputer berorientasi objek.
3.
Abstraksi - Kemampuan sebuah program
untuk melewati aspek informasi yang diproses olehnya, yaitu kemampuan untuk
memfokus pada inti. Setiap objek dalam sistem melayani sebagai model dari
"pelaku" abstrak yang dapat melakukan kerja, laporan dan perubahan
keadaannya, dan berkomunikasi dengan objek lainnya dalam sistem, tanpa
mengungkapkan bagaimana kelebihan ini diterapkan. Proses, fungsi atau metode
dapat juga dibuat abstrak, dan beberapa teknik digunakan untuk mengembangkan
sebuah pengabstrakan.
4.
Enkapsulasi - Memastikan pengguna
sebuah objek tidak dapat mengganti keadaan dalam dari sebuah objek dengan cara
yang tidak layak; hanya metode dalam objek tersebut yang diberi izin untuk
mengakses keadaannya. Setiap objek mengakses interface yang menyebutkan
bagaimana objek lainnya dapat berinteraksi dengannya. Objek lainnya tidak akan
mengetahui dan tergantung kepada representasi dalam objek tersebut.
Polimorfisme
melalui pengiriman pesan. Tidak bergantung kepada pemanggilan subrutin, bahasa
orientasi objek dapat mengirim pesan; metode tertentu yang berhubungan dengan
sebuah pengiriman pesan tergantung kepada objek tertentu di mana pesan tersebut
dikirim. Contohnya, bila sebuah burung menerima pesan "gerak cepat",
dia akan menggerakan sayapnya dan terbang. Bila seekor singa menerima pesan
yang sama, dia akan menggerakkan kakinya dan berlari. Keduanya menjawab sebuah
pesan yang sama, namun yang sesuai dengan kemampuan hewan tersebut. Ini disebut
polimorfisme karena sebuah variabel tungal dalam program dapat memegang
berbagai jenis objek yang berbeda selagi program berjalan, dan teks program
yang sama dapat memanggil beberapa metode yang berbeda di saat yang berbeda
dalam pemanggilan yang sama. Hal ini berlawanan dengan bahasa fungsional yang
mencapai polimorfisme melalui penggunaan fungsi kelas-pertama.
Dengan
menggunakan OOP maka dalam melakukan pemecahan suatu masalah kita tidak melihat
bagaimana cara menyelesaikan suatu masalah tersebut (terstruktur) tetapi
objek-objek apa yang dapat melakukan pemecahan masalah tersebut. Sebagai contoh
anggap kita memiliki sebuah departemen yang memiliki manager, sekretaris,
petugas administrasi data dan lainnya. Misal manager tersebut ingin memperoleh
data dari bag administrasi maka manager tersebut tidak harus mengambilnya
langsung tetapi dapat menyuruh petugas bag administrasi untuk mengambilnya.
Pada kasus tersebut seorang manager tidak harus mengetahui bagaimana cara
mengambil data tersebut tetapi manager bisa mendapatkan data tersebut melalui
objek petugas adminiistrasi. Jadi untuk menyelesaikan suatu masalah dengan
kolaborasi antar objek-objek yang ada karena setiap objek memiliki deskripsi
tugasnya sendiri.
Bahasa pemrograman yang mendukung
OOP antara lain:
Visual Foxpro
Java
C++
Pascal (bahasa pemrograman)
Visual Basic.NET
SIMULA
Smalltalk
Ruby
Python
PHP
C#
Delphi
Eiffel
Perl
Adobe Flash AS 3.0
B. UML (Unified
Modeling Language)
Sampai era
tahun 1990 puluhan metodologi pemodelan berorientasi objek telah bermunculan di
dunia. Diantaranya adalah: metodologi booch, metodologi coad, metodologi OOSE,
metodologi OMT, metodologi shlaer-mellor, metodologi wirfs-brock, dsb. Masa itu
terkenal dengan masa perang metodologi (method war) dalam pendesainan
berorientasi objek. Masing-masing metodologi membawa notasi sendiri-sendiri,
yang mengakibatkan timbul masalah baru apabila kita bekerjasama dengan
kelompok/perusahaan lain yang menggunakan metodologi yang berlainan.
Dimulai
pada bulan Oktober 1994 Booch, Rumbaugh dan Jacobson, yang merupakan tiga tokoh
yang boleh dikata metodologinya banyak digunakan mempelopori usaha untuk
penyatuan metodologi pendesainan berorientasi objek. Pada tahun 1995 direlease
draft pertama dari UML (versi 0.8). Sejak tahun 1996 pengembangan tersebut
dikoordinasikan oleh Object Management Group (OMG – http://www.omg.org).
UML
menyediakan 10 macam diagram untuk memodelkan aplikasi berorientasi objek,
yaitu:
Use Case Diagram untuk
memodelkan proses bisnis.
Conceptual Diagram untuk
memodelkan konsep-konsep yang ada di dalam aplikasi.
Sequence Diagram untuk
memodelkan pengiriman pesan (message) antar objects.
Collaboration Diagram untuk
memodelkan interaksi antar objects.
State Diagram untuk
memodelkan perilaku objects di dalam sistem.
Activity Diagram untuk
memodelkan perilaku Use Cases dan objects di dalam system.
Class Diagram untuk
memodelkan struktur kelas.
Object Diagram untuk
memodelkan struktur object.
Component Diagram untuk
memodelkan komponen object.
Deployment Diagram untuk
memodelkan distribusi aplikasi.
Use Case Diagram
Use case diagram menggambarkan
fungsionalitas yang diharapkan dari sebuah
sistem. Yang ditekankan adalah
“apa” yang diperbuat sistem, dan bukan “bagaimana”.
Sebuah use case merepresentasikan sebuah interaksi antara aktor dengan sistem. Use case merupakan
sebuah pekerjaan tertentu, misalnya login ke sistem,
meng-create sebuah daftar belanja, dan sebagainya.
Seorang/sebuah aktor adalah sebuah
entitas manusia atau mesin yang berinteraksi
dengan sistem untuk melakukan
pekerjaan-pekerjaan tertentu.
Use case diagram dapat sangat membantu bila kita sedang menyusun requirement sebuah sistem,
mengkomunikasikan rancangan dengan klien, dan merancang
test case untuk semua feature yang ada pada sistem.
Sebuah use case dapat meng-include
fungsionalitas use case lain sebagai bagian
dari proses dalam dirinya. Secara umum
diasumsikan bahwa use case yang
di-include akan dipanggil setiap kali use case yang meng-include
dieksekusi secara normal.
Sebuah use case dapat di-include
oleh lebih dari satu use case lain, sehingga duplikasi fungsionalitas dapat dihindari dengan cara menarik
keluar fungsionalitas yang
common.
Sebuah use case juga dapat
meng-extend use case lain dengan behaviour-nya sendiri.
Sementara
hubungan generalisasi antar use case menunjukkan bahwa use case yang satu merupakan
spesialisasi dari yang lain.
Contoh
use case diagram :
Class
Diagram
Class adalah
sebuah spesifikasi yang jika diinstansiasi akan menghasilkan sebuah objek dan merupakan inti dari
pengembangan dan desain berorientasi objek. Class menggambarkan keadaan
(atribut/properti) suatu sistem, sekaligus menawarkan
layanan untuk memanipulasi keadaan tersebut
(metoda/fungsi).
Class diagram
menggambarkan struktur dan deskripsi class, package dan objek beserta hubungan satu sama
lain seperti containment, pewarisan, asosiasi, dan lain-lain.
Class
memiliki tiga area pokok :
1.
Nama (dan stereotype)
2.
Atribut
3.
Metoda
Atribut dan metoda
dapat memiliki salah satu sifat berikut :
Private, tidak dapat dipanggil
dari luar class yang bersangkutan
Protected, hanya dapat dipanggil
oleh class yang bersangkutan dan anak-anak yang mewarisinya
Public, dapat dipanggil oleh
siapa saja
Class
dapat merupakan implementasi dari sebuah interface, yaitu class
abstrak yang hanya memiliki metoda. Interface
tidak dapat langsung diinstansiasikan,
tetapi harus diimplementasikan dahulu menjadi sebuah class. Dengan demikian interface
mendukung resolusi metoda pada saat run-time.
Sesuai dengan perkembangan class model, class
dapat dikelompokkan menjadi package. Kita juga dapat membuat
diagram yang terdiri atas package.
Hubungan
Antar Class
- Asosiasi, yaitu hubungan statis antar class. Umumnya
menggambarkan class yang memiliki atribut berupa class lain,
atau class yang harus mengetahui eksistensi class lain.
Panah navigability menunjukkan arah query antar class.
- Agregasi, yaitu hubungan yang menyatakan bagian (“terdiri
atas..”).
- Pewarisan, yaitu hubungan hirarkis antar class. Class
dapat diturunkan dari class lain dan mewarisi semua atribut dan
metoda class asalnya dan menambahkan fungsionalitas baru, sehingga
ia disebut anak dari class yang diwarisinya. Kebalikan dari
pewarisan adalah generalisasi.
4. Hubungan dinamis, yaitu rangkaian pesan (message) yang di-passing
dari satu class kepada class lain. Hubungan dinamis dapat
digambarkan dengan menggunakan sequence diagram yang akan dijelaskan
kemudian.
Contoh
class diagram :
Statechart
Diagram
Statechart diagram menggambarkan transisi dan perubahan keadaan (dari satu state ke state
lainnya) suatu objek pada sistem sebagai akibat dari stimuli yang diterima. Pada umumnya statechart diagram
menggambarkan class tertentu (satu class
dapat memiliki lebih dari satu statechart diagram).
Dalam UML, state digambarkan
berbentuk segiempat dengan sudut membulat
dan memiliki nama sesuai kondisinya saat itu. Transisi antar state umumnya memiliki kondisi guard
yang merupakan syarat terjadinya transisi yang bersangkutan,
dituliskan dalam kurung siku. Action yang dilakukan sebagai akibat dari event tertentu dituliskan dengan
diawali garis miring.
Titik awal dan akhir digambarkan
berbentuk lingkaran berwarna penuh dan berwarna
setengah.
Contoh statechart
diagram :
Activity
Diagram
Activity diagrams
menggambarkan berbagai alir aktivitas dalam sistem yang sedang dirancang, bagaimana masing-masing alir berawal, decision
yang mungkin terjadi, dan bagaimana
mereka berakhir. Activity diagram juga dapat menggambarkan proses paralel yang mungkin terjadi pada beberapa
eksekusi.
Activity diagram
merupakan state diagram khusus, di mana sebagian besar state adalah action dan
sebagian besar transisi di-trigger oleh selesainya state sebelumnya (internal processing).
Oleh karena itu activity diagram tidak menggambarkan
behaviour internal sebuah sistem (dan interaksi antar subsistem) secara eksak, tetapi lebih
menggambarkan proses-proses dan jalur-jalur aktivitas dari level atas secara umum.
Sebuah aktivitas dapat
direalisasikan oleh satu use case atau lebih. Aktivitas menggambarkan proses yang berjalan,
sementara use case menggambarkan bagaimana
aktor menggunakan sistem untuk melakukan aktivitas.
Sama seperti state, standar
UML menggunakan segiempat dengan sudut membulat
untuk menggambarkan aktivitas.
Decision digunakan untuk menggambarkan
behaviour pada kondisi tertentu. Untuk mengilustrasikan proses- proses paralel (fork dan join)
digunakan titik sinkronisasi yang dapat berupa titik, garis horizontal atau vertikal.
Activity diagram dapat
dibagi menjadi beberapa object swimlane untuk menggambarkan objek mana yang bertanggung jawab untuk aktivitas
tertentu.
Contoh activity
diagram tanpa swimlane:
Sequence
Diagram
Sequence diagram
menggambarkan interaksi antar objek di dalam dan di sekitar sistem (termasuk pengguna, display, dan
sebagainya) berupa message yang digambarkan
terhadap waktu. Sequence diagram
terdiri atar dimensi vertikal (waktu)
dan dimensi horizontal (objek-objek yang terkait).
Sequence diagram biasa
digunakan untuk menggambarkan skenario atau rangkaian
langkah-langkah yang dilakukan sebagai respons dari sebuah event untuk menghasilkan output tertentu.
Diawali dari apa yang men-trigger aktivitas tersebut, proses dan perubahan apa saja yang
terjadi secara internal dan output
apa yang dihasilkan.
Masing-masing objek,
termasuk aktor, memiliki lifeline vertikal.
Message
digambarkan sebagai garis berpanah dari satu objek ke objek lainnya. Pada fase desain berikutnya, message
akan dipetakan menjadi operasi/metoda
dari class.
Activation bar
menunjukkan lamanya eksekusi sebuah proses, biasanya diawali dengan diterimanya sebuah message.
Untuk objek-objek yang memiliki
sifat khusus, standar UML mendefinisikan icon
khusus untuk objek boundary, controller dan persistent entity.
Contoh sequence
diagram :
Collaboration
Diagram
Collaboration diagram juga
menggambarkan interaksi antar objek seperti sequence
diagram, tetapi lebih menekankan pada peran masing-masing objek dan bukan pada waktu penyampaian message.
Setiap message memiliki sequence
number, di mana message dari level tertinggi
memiliki nomor 1. Messages dari level yang sama memiliki prefiks yang sama.
Component
Diagram
Component diagram menggambarkan
struktur dan hubungan antar komponen
piranti lunak, termasuk
ketergantungan (dependency) di antaranya.
Komponen piranti lunak adalah modul
berisi code, baik berisi source code maupun binary code, baik library maupun executable, baik yang muncul pada
compile time, link time, maupun
run time. 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:
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), bagaimana kemampuan jaringan pada lokasi tersebut, spesifikasi server, dan
hal-hal lain yang bersifat fisikal
Sebuah node adalah server, workstation,
atau piranti keras lain yang digunakan
untuk men-deploy komponen
dalam lingkungan sebenarnya. Hubungan
antar node (misalnya TCP/IP) dan requirement
dapat juga didefinisikan dalam
diagram ini.
Contoh deployment
diagram :
Langkah-Langkah
Penggunaan UML
Berikut ini adalah
tips pengembangan piranti lunak dengan menggunakan UML:
- Buatlah daftar business process dari level tertinggi untuk
mendefinisikan aktivitas dan proses yang mungkin muncul.
- Petakan use case untuk tiap business process untuk
mendefinisikan dengan tepat fungsionalitas yang harus disediakan oleh
sistem. Kemudian perhalus use case diagram dan lengkapi dengan requirement,
constraints dan catatan-catatan lain.
- Buatlah deployment diagram secara kasar untuk
mendefinisikan arsitektur fisik sistem.
- Definisikan requirement lain (non-fungsional, security
dan sebagainya) yang juga harus disediakan oleh sistem.
- Berdasarkan use case diagram, mulailah membuat activity
diagram.
- Definisikan objek-objek level atas (package atau domain)
dan buatlah sequence dan/atau collaboration diagram untuk
tiap alir pekerjaan. Jika sebuah use case memiliki kemungkinan alir
normal dan error, buatlah satu diagram untuk masing-masing alir.
- Buarlah rancangan user interface model yang menyediakan
antarmuka bagi pengguna untuk menjalankan skenario use case.
- Berdasarkan model-model yang sudah ada, buatlah class diagram.
Setiap package atau domain dipecah menjadi hirarki class
lengkap dengan atribut dan metodanya. Akan lebih baik jika untuk setiap class
dibuat unit test untuk menguji fungsionalitas class dan
interaksi dengan class lain.
- Setelah class diagram dibuat, kita dapat melihat
kemungkinan pengelompokan class menjadi komponen-komponen. Karena
itu buatlah component diagram pada tahap ini. Juga, definisikan tes
integrasi untuk setiap komponen meyakinkan ia berinteraksi dengan baik.
- Perhalus deployment diagram yang sudah dibuat. Detilkan
kemampuan dan requirement piranti lunak, sistem operasi, jaringan,
dan sebagainya. Petakan komponen ke dalam node.
- Mulailah membangun sistem. Ada dua pendekatan yang dapat
digunakan :
- Pendekatan use case, dengan
meng-assign setiap use case kepada tim pengembang tertentu
untuk mengembangkan unit code yang lengkap dengan tes.
- Pendekatan komponen, yaitu meng-assign
setiap komponen kepada tim pengembang tertentu.
- Lakukan uji modul dan uji integrasi serta perbaiki model berserta
codenya. Model harus selalu sesuai dengan code yang aktual.
- Piranti lunak siap dirilis.
Tool Yang Mendukung UML
Saat ini banyak sekali tool
pendesainan yang mendukung UML, baik itu tool komersial
maupun opensource. Beberapa
diantaranya adalah:
·
Rational Rose (www.rational.com)
·
Together (www.togethersoft.com)
·
Object Domain (www.objectdomain.com)
·
Jvision (www.object-insight.com)
·
Objecteering (www.objecteering.com)
·
MagicDraw (www.nomagic.com/magicdrawuml)
·
Visual Object Modeller (www.visualobject.com)
BAB III
PENUTUP
A. Kesimpulan
UML adalah
tools untuk merancang atau membuat software berorientasi objek. Dengan 10 macam diagram untuk
memodelkan aplikasi berorientasi
objek dengan fungsi yang berbeda.
DAFTAR PUSTAKA
