Ada apa dengan UML?

Kebanyakan orang salah, UML bukanlah Universal Modelling Language, dimana UML tidak
diperuntukkan agar bisa membuat model bagi apa saja (contoh, UML tidak terlalu baik untuk
memodelkan persediaan pasar).UML juga bukanlah Unified Marxist-Leninists, suatu partai
politik di Nepal. UML adalah Unified Modelling Language.
lebih penting adalah, UML merupakan standardized modelling language yang terdiri dari
kumpulan-kumpulan diagram, dikembangkan untuk membantu para pengembang sistem dan
software agar bisa menyelesaikan tugas-tugas seperti:
• Spesifikasi
• Visualisasi
• Desain Arsitektur
• Konstruksi
• Simulasi dan testing
• Dokumentasi
UML dikembangkan sebagai ide dasar untuk mempromosikan hubungan dan produktifitas antara
para pengembang dari object-oriented system.
UML memuaskan kebutuhan yang penting dalam pengembangan software dan sistem.
Pemodelan (modeling) memungkinkan para pengembang bisa berkonsentrasi pada gambaran
yang luas. UML membantu kita melihat dan menyelesaikan masalah-masalah yang sering terjadi.
Ketika kita membuat model, kita membuat suatu abstraksi dari sistem nyata yang sudah ada,
yang memungkinkan kita bisa bertanya tentang model tersebut dan akan kita dapatkan jawaban
yang memuaskan.
Setelah kita puas dengan hasil kerja kita, kita bisa menggunakan model kita bersama dengan
orang lain. Kita bisa menggunakan model kita untuk meminta bantuan dari orang lain yang akan
meningkatkan kerja kita, dan juga dapat saling membantu dengan mengajari orang lain.
Abstracting
Teknik dalam membuat model dari ide kita atau dunia nyata adalah dengan menggunakan
abstraction. Sebagai contoh, map merupakan model dunia – bukanlah miniatur dunia.
Setiap diagram UML yang kita gambar memiliki keterkaitan dengan dunia nyata. Abstraction
dikembangkan sebagai ketentuan untuk dipelajari dan sering digunakan.
Jika kita berpikir UML sebagai map dari dunia yang kita lihat, hampir mendekati. Analogi yang
lebih mendekati adalah merupakan kumpulan dari blueprint yang menampilkan detail yang
cukup dari suatu bangunan untuk memastikan tentang apa sebenarnya bangunan tersebut.
Abstraction model dan diagram juga berguna karena akan menjelaskan lebih rinci detail-detail
yang dibutuhkan (kita tidak perlu mengambar pohon dan mobil dan orang dalam map kita,
karena map kita akan menjadi susah alias tidak praktis untuk dipakai).
Kategori diagram UML
• Structural Diagram: kita menggunakan structural diagram untuk menampilkan blok
bangunanan dari sistem kita – merupakan fitur yang tidak berubah bersama waktu. Diagram ini
menjawab pertanyaan, ada apa disana?
• Behavioral Diagram: kita menggunakan behavioral diagram untuk menampilkan bagaimana
sistem kita merespon permintaan atau apa saja seiring waktu.
• Interaction diagram: merupakan tipe dari behavioral diagram. Kita menggunakan interaction
diagram untuk melukiskan perubahan dari pesan-pesan dalam suatu kolaborasi (kumpulan dari
object-object yang sama) sehingga tujuan bisa tercapai.
• Structural diagram (Class diagram) : Digunakan untuk menampilkan entiti dunia nyata, elemen
dari analisa dan desain, atau implementasi class dan relasinya.
• Structural diagram (Object diagram) : Digunakan untuk menampilkan suatu contoh spesifik
atau ilustrasi dari suatu object serta link nya. Sering digunakan untuk mengindikasikan kondisi
dari suatu even, seperti percobaan atau operasi pemanggilan.
• Structural diagram (Composite structure diagram) : Digunakan untuk menampilkan bagaimana
sesuatu itu dibuat.
• Structural diagram (Deployment diagram) : Digunakan untuk menampilkan arsitektur run-time
dari suatu sistem, kerangka hardware, ruang lingkup software, dan sebagainya.
• Structural diagram (Component diagram) : Digunakan untuk menampilkan organisasi dan
hubungan antar sistem.
• Structural diagram (Package diagram) : Digunakan untuk mengorganisir elemen model dan
menampilkan ketergantungan antara mereka.
• Behavioral diagram (Activity diagram) : Digunakan untuk menampilkan arus data dari
kebiasaan antar object.
• Behavioral diagram (Use case diagram) : Digunakan untuk menampilkan layanan yang bisa
diminta oleh actor dari sistem kita.
• Behavioral diagram (State machine diagram / Protocol state machine diagram) : Digunakan
untuk menampilkan urutan proses dari suatu object dan kondisinya saat ini.
• Interaction diagram (Overview diagram) : Digunakan untuk menampilkan banyak skenario
interaksi (urutan dari kebiasaan) bagi suatu kolaborasi (kumpulan elemen yang sama dan saling
bekerja agar tercapai tujuan yang diinginkan).
• Interaction diagram (Sequence diagram) : Digunakan untuk fokus pada perubahan pesan antara
grup dari suatu object dan urutan pesan tersebut.
• Interaction diagram (Communication diagram) : Digunakan untuk fokus pada perubahan pesan
antara grup dari suatu object dan relasi dari object-object tersebut.
• Interaction diagram (Timing diagram) : Digunakan untuk menampilkan perubahan dan
hubungan terhadap waktu nyata atau terhadap proses sistem.
Karena UML sangatlah fleksibel, kita akan menjumpai berbagai cara dalam meng-kategorikan
diagram kita. Pohon kategori di bawah ini cukup terkenal:
• Static diagram: Menampilkan fitur statis dari sistem. Kategori ini hampir sama dengan
structural diagram.
• Dynamic diagram: Menampilkan bagaimana proses perubahan yang terjadi dalam sistem
sepanjang waktu. Kategori ini mencakup UML state-machine diagram dan timing diagram.
• Functional diagram: Menampilkan detail dari proses dan algoritma. Kategori ini mencakup use
case, interaction, dan activity diagram.
Kita bisa mengembangkan diagram UML untuk menampilkan informasi yang berbeda pada
waktu yang berbeda atau untuk tujuan yang berbeda. Ada banyak kerangka modelling, seperti
Zachman atau DODAF. Berikut pertanyaan standar tentang sistem :
• Siapa yang menggunakan sistem? Menampilkan actor (pengguna sistem) dalam diagram use
case(menampilkan tujuan sistem)
• Dari mana sistem dibuat? Menggambarkan diagram Class untuk menampilkan struktur logis
dan component diagram agar bisa menampilkan struktur fisik.
• Dimana lokasi komponen dalam suatu sistem? Mengindikasikan rencana kita untuk
menentukan lokasi suatu komponen.
• Kapan kejadian penting terjadi? Menampilkan apa yang menyebabkan object kita bisa bereaksi
dan mulai melakukan kerjanya dengan state diagram dan interaction diagram.
• Bagaimana sistem ini bekerja? Menampilkan bagian struktur diagram dan menggunakan
communication diagram untuk menampilkkan interaksi.
Siapa yang memerlukan UML?
Para pengguna UML dibagi dalam kategori:
• Modeler: Modeler mencoba menjelaskan dunia nyata seperti bagaimana mereka melihatnya.
• Designer: Designer mencoba mencari solusi yang memungkinkan, untuk dibandingkan atau
menentukan proses pada aspek yang berbeda.
• Implementer: Implementer membangun solusi menggunakan UML sebagai bagian dari tujuan
implementasi. Kebanyakan program UML sekarang sudah bisa membuat sendiri definisi dari
suatu Class atau Database, seperti kode aplikasi atau user interface. (**)
UML itu cuma Gambar ? Benarkah ?
Well, pertanyaan yang saya pakai mungkin terlalu extreme. Bukan. Maksud saya bukannya
UML itu tidak penting. Tapi ada hal yang lebih penting yaitu OOAD itu sendiri. UML
“hanyalah” gambar yang digunakan sebagai “alat komunikasi” untuk menggambarkan suatu ide
yang abstrak untuk dapat diimplementasikan.
Selain sebagai alat komunikasi, UML juga dapat berfungsi sebagai dokumentsasi dari suatu
design. Jika architect, designer atau developer datang dan pergi dalam suatu project, UML
diagrams dapat dipakai sebagai learning aid untuk memahami suatu system software yang
kompleks.
UML dipilih karena kita butuh standard. Komunikasi bisa lancar kalau semua orang bicara dalam
bahasa yang sama. Demikian halnya UML yang merupakan bahasa dalam bentuk gambar. Misal,
jika kita menggunakan UML class diagram, semua orang yang memahami UML class diagram
dapat mengerti mana attribute, mana responsibility, mana yang public, mana yang protected,
class yang mana implement interface, class mana merupakan generalisasi class lainnya, dan
sebagainya.
Celakanya, orang banyak yang tersesat dalam menggunakan UML ini. Banyak yang membuat
UML menjadi “the real thing”. Padahal, UML itu cuma model dari system yang sebenarnya. Dan
definisi model adalah: “Cheaper imitations of the real thing!”. Jadi, jangan menghabiskan terlalu
banyak waktu “menggambar” UML. Fokuslah pada OOAD. Pada domain objects anda,
kolaborasi antar object, responsibility tiap object, grouping object dan semacamnya. UML itu
Cuma “cheaper model” dari hal-hal tadi.
Dari sini, bagaimana menggunakan UML dapat dibedakan menjadi 3:
1. UML as sketch
2. UML as Blueprint
3. UML as Programming Language
UML as sketch
Dari seluruh hal yang ada pada UML, hanya 20% saja yang akan terpakai dalam 80% effort
analysis, design dan development. Kuncinya adalah selektivitas. Pilih notasi / diagram UML
yang anda butuhkan saja. Gambarkan juga UML untuk hal yang menjadi fokus perhatian pada
suatu saat tertentu. Tidak perlu semuanya.
Dengan demikian, UML dapat anda gambar dengan pensil diatas kertas. Dengan spidol pada
whiteboard. Gambarkan diagram UML di whiteboard, diskusikan bersama team development,
begitu ide development di dapat, langsung coding. Intinya, UML digunakan sebagai media
komunikasi pada saat brainstorming ide design.
UML tadi bisa disimpan, tapi bisa juga dibuang. Terserah anda. Jika anda memakai drawing
tools seperti Visio, anda dapat menyimpan UML tadi sebagai dokumen. Yang lebih menarik,
Visio Enterprise Architect bisa melakukan Reverse Engineer dari code anda. Jadi, anda dapat
menggunakan the code as the documentation of the system.
Saya adalah penganut aliran UML as sketch ini. UML tool favorit saya adalah spidol dan
whiteboards. Yeah, kadang-kadang pakai Visio juga. Sekarang ini saya pakai Visio Enterprise
Architect 2003.
UML as Blueprint
Jika anda membangun gedung pencakar langit atau jembatan, pasti ada arsitek dan insinyur sipil
yang akan menggambar dan mengkalkulasikan semua design. Setelah design jadi, design
dilempar ke kuli bangunan yang akan diawasi para mandor.
UMLdapat digunakan sebagai blueprint seperti halnya design bangunan atau jembatan.
Architect/senior devs membuat UML-nya, lalu developer menulis code berdasarkan design
tersebut. Konsekuensinya, UML yang digunakan harus sedetail-detailnya, selengkap-
lengkapnya.
Problemnya, pada banyak kasus, selama masa development, design bisa berubah mengikuti
kebutuhan bisnis. Nah, jika code harus berubah, logikanya, blueprint juga harus berubah. Me-
maintain blueprint ini bukanlah pekerjaan ringan. Bikin capek! Syukur kalau ada waktu untuk
melakukannya.
Tapi, pada skala project yang besar, dengan development team yang terpisah, UML as blueprint
is the way to go. Tentu saja, pada project skala besar anda pasti menggunakan CASE tool
(Computer Aided Software Engineering). Dengan CASE tool, maintenance blueprint ini akan
lebih ringan. Jika anda tidak punya CASE tool, tetapi memilih menggunakan UML as
blueprint… you just dig your own grave!!!
UML as Programming Language
Yang satu ini menggunakan UML lebih jauh lagi. Design dilakukan dengan UML (tentu saja
dengan CASE tool), lalu dengan UML tadi di-generate skeleton code secara automatis. Nah,
pada skeleton code inilah developer menambah baris-baris code untuk melengkapi skeleton code
tadi. Disini, UML berfungsi sebagai suatu programming language. Untuk melakukan ini, anda
perlu CASE tool yang canggih. CASE tool yang harus men-support Round-trip Engineering.
Microsoft support untuk UML
Sebagai permulaan, saya akan bicara tool Microsoft untuk UML yaitu Visio.
Visio men-support forward engineering. Kita bisa membuat skeleton code dari UML design kita.
Sebaliknya, kita bisa mendapatkan UML (class diagram) dari code kita dengan fasilitas reverse
engineering. Sayangnya, Visio tidak mensupport round-trip engineering. Code hasil generate dari
Visio, jika kita update, lalu kita reverse engineer, anda mendapatkan model UML baru (bukan
yang pertama anda pakai tadi). Lalu dari model yang baru anda dapat ini, anda tidak dapat
melakukan update terhadap UML design ini dan mengharapkan code anda tadi juga terupdate.
Intinya, Visio tidak bisa Round-trip engineering. Dari kenyataan ini, Visio masih termasuk
kategori Drawing tool untuk menggambar UML. Dia belum layak disebut sebagai CASE tool.
Ada banyak CASE tool di pasaran. Tapi… harganya tidak ada yang murah. Yang paling terkenal
adalah dari Rational (sekarang IBM Rational). Saya pernah punya sedikit pengalaman dengan
Rational XDE for Microsoft .NET. Interesting. Tetapi, jika anda tidak punya barang-barang
mewah seperti CASE tool ini, jangan sekali-sekali menggunakan UML sebagai blueprint apalagi
programming language. O ya, CASE tool juga tampaknya tidak terlalu sukses di pasar.
O ya, Visio yang ada sekarang menggunakan UML versi 1.4. Baru-baru ini, OMG (yang
bertugas memaintain UML) merilis UML versi 2.0. Jika anda ingin menggunakan UML versi 2.0
ini, ada stencil untuk Visio yang bisa anda download
di :http://www.phruby.com/stencildownload.html
Tentang UML sendiri, Microsoft melihatnya bahwa UML bukan satu-satunya modeling
language. Microsoft sedang memulai inisiatif DSL (Domain Specific Language). Lalu ada lagi
inisiatif Software Factories, dsb. Sangat menarik untuk kita ikuti perkembangannya. Tetapi
sebelum semua ini jadi kenyataan (he..he.. maksudnya, bisa kita pakai di production), kita stick
dulu di UML. Kita juga lihat apakah DSL ini akan bisa “menggantikan” UML. Apakah DSL bisa
diterima komunitas development. Dan sebagainya..dan sebagainya…
Kembali ke alinea pertama… ada yang lebih penting dari UML atau apapun juga modeling
language lainnya… OOAD! UML itu Cuma gambar.
Konsep OOAD
Diposkan oleh Hendra Divayana on Minggu, 11 April 2010

I. Pengertian dan Konsep OOAD

A. Karakteristik dari Objek

1. Objek

 Objek adalah benda secara fisik dan konseptual yang ada di sekitar kita. Sebuah objek memiliki
keadaan sesaat yang disebut state.
 Objek dapat kongkrit, seperti halnya arsip dalam sistem, atau konseptual seperti kebijakan
penjadwalan dalam multiprocessing pada sistem operasi.
 Dua objek dapat berbeda walaupun bila semua nilai atributnya identik.

Gambar 1. Macam-macam Objek

2. Kelas Objek

Kelas merupakan gambaran sekumpulan Objek yang terbagi dalam atribut, operasi, metode, hubungan,
dan makna yang sama.

 Suatu kegiatan mengumpulkan data (atribut) dan perilaku (operasi) yang mempunyai struktur
data sama ke dalam satu grup.
 Kelas Objek merupakan wadah bagi Objek. Dapat digunakan untuk menciptakan Objek.
 Objek mewakili fakta/keterangan dari sebuah kelas.
 Gambar 2. Kelas dan Objek

B. Karakteritik Metodologi Berorientasi Objek

Metodologi pengembangan sistem berorientasi objek mempunyai tiga karakteristik utama :

1. Encapsulation (Pengkapsulan)

 Encapsulation merupakan dasar untuk pembatasan ruang lingkup program terhadap data yang
diproses.
 Data dan prosedur atau fungsi dikemas bersama-sama dalam suatu objek, sehingga prosedur
atau fungsi lain dari luar tidak dapat mengaksesnya.
 Data terlindung dari prosedur atau objek lain, kecuali prosedur yang berada dalam objek itu
sendiri.

2. Inheritance (Pewarisan)

 Inheritance adalah teknik yang menyatakan bahwa anak dari objek akan mewarisi data/atribut
dan metode dari induknya langsung.
 Atribut dan metode dari objek dari objek induk diturunkan kepada anak objek, demikian
seterusnya.
 Inheritance mempunyai arti bahwa atribut dan operasi yang dimiliki bersama di anatara kelas
yang mempunyai hubungan secara hirarki.
 Suatu kelas dapat ditentukan secara umum, kemudian ditentukan spesifik menjadi subkelas.
Setiap subkelas mempunyai hubungan atau mewarisi semua sifat yang dimiliki oleh kelas
induknya, dan ditambah dengan sifat unik yang dimilikinya.
 Kelas Objek dapat didefinisikan atribut dan service dari kelas Objek lainnya.
 Inheritance menggambarkan generalisasi sebuah kelas.

3. Polymorphism (Polimorfisme)

 Polimorfisme yaitu konsep yang menyatakan bahwa seuatu yang sama dapat mempunyai
bentuk dan perilaku berbeda.
  Polimorfisme mempunyai arti bahwa operasi yang sama mungkin mempunyai perbedaan dalam
kelas yang berbeda.
 Kemampuan objek-objek yang berbeda untuk melakukan metode yang pantas dalam merespon
message yang sama.
 Seleksi dari metode yang sesuai bergantung pada kelas yang seharusnya menciptakan Objek.

II. Pemodelan Berorientasi Objek

B. Model Berorientasi Objek

Sebuah model objek menangkap struktur statis dari sistem dengan menggambarkan objek dalam
sistem, hubungan antara objek, serta atribut dan operasi yang merupakan karakteristik setiap
kelas dan objek.

Model berorientasi objek lebih mendekati keadaan nyata, dan dilengkapi dengan penyajian grafis
dari sistem yang sangat bermanfaat untuk komunikasi dengan user dan pembuatan dokumentasi
struktur dari sistem.

1. Objek dan Kelas

> Objek

 Objek didefinisikan sebagai konsep, abstraksi atau benda dengan batasan dan arti untuk suatu
masalah.
 Semua objek mempunyai identitas yang berbeda dengan lainnya.
 Istilah identitas berarti bahwa objek dibedakan oleh sifat yang melekat dan bukan dengan uraian
sifat yang dimilikinya.
 Contohnya : kembar identik, walaupun mereka nampak seperti sama, tetapi merupakan dua
orang yang berbeda.
 Kadang-kadang objek berarti suatu barang, maka digunakan istilah object instance, dan object
class untuk menunjukkan satu grup dari barang yang sama.

> Kelas

 Suatu object class menggambarkan kumpulan dari objek yang mempunyai sifat (atribut),
perilaku umum (operasi), relasi umum dengan objek lain dan semantik umum.
 Contoh : Orang, perusahaan , binatang, proses adalah objek.
 Setiap orang mempunyai umur, IQ, dan mungkin pekerjaan. Setiap proses mempunyai pemilik,
prioritas, list dari sumber daya yang dibutuhkan.
 Objek dan object class sering sama sebagai benda dalam deskripsi masalah.

2. Diagram Objek
Diagram objek melengkapi notasi grafik untuk pemodelan objek, kelas dan relasinya dengan yang lain.
Diagram objek bermanfaat untuk pemodelan abstrak dan membuat perancangan program.

> Kelas dan Objek

Konsep fundamental dalam analisis berorientasi objek adalah objek itu sendiri. Sebuah objek
adalah sebuah entitas yang mencakup data dan metode.

Kelas merupakan satu atau lebih objek dengan persamaan atribut dan metode, sedangkan kelas-
&-objek adalah kelas dengan satu atau lebih objek di dalamnya. Nama kelas adalah kata benda
tunggal, atau kata sifat dan kata benda. Nama dari kelas-&-objek harus dapat menjelaskan objek
tunggal dari suatu kelas.

Gambar 3. Notasi untuk kelas dan kelas-&-objek

> Struktur Objek dan Hirarki Kelas

- Struktur kelas dibagi dua macam, yaitu Whole-Part Structure dan Gen-Spec Structure.

 Whole-Part Structure memperlihatkan hirarki dari suatu kelas sebagai komponen dari kelas lain
yang disebut juga sub objek. Contohnya, kelas Mobil adalah Whole dan komponennya Mesin,
Rangka, dan lain-lain, merupakan Part1, Part 2, …, Part n.
 Gambar 4. Notasi untuk whole-part structure

 Gen-Spec Structure memperlihatkan kelas sebagai spesialisasi dari kelas di atasnya. Kelas yang
mempunyai sifat umum disebut Generalization, Superclass atau Topclass, sedangkan kelas yang
mempunyai sifat khusus disebut Specialization.

Gambar 5. Notasi untuk gen-spec structure

Contohnya, kelas Mobil adalah Generalization, sedangkan Sedan, Truk, Minibus, dan lain-lain
merupakan Specizlization1, Specialization2, …, Specialization n, yaitu kelas yang mempunyai sifat
khusus.

- Atribut
Atribut menggambarkan data yang dapat memberikan informasi mengenai kelas atau objek
dimana atribut tersebut berada.

Gambar 6. Notasi untuk atribut

- Metode

Metode (method) disebut juga service atau operator adalah prosedur atau fungsi seperti yang terdapat
dalam bahasa Pascal pada umumnya, tetapi cara kerjanya agak berlainan. Metode adalah subprogram
yang tergabung dalam objek bersama-sama dengan atribut. Metode dipergunakan untuk pengaksesan
terhadap data yang terdapat dalam objek tersebut.

Gambar 7. Notasi untuk metode

- Pesan (Message)
Message merupakan cara untuk berhubungan antara satu objek dengan objek lain. Suatu pesan
dikirimkan oleh suatu objek kepada objek tertentu dapat digambarkan dengan anak panah.
 Gambar 8. Notasi untuk message

III. UML (Unified Modelling Language)

Unified Modelling Language (UML) adalah sebuah “bahasa” yg telah menjadi standar dalam
industri untuk visualisasi, merancang dan mendokumentasikan sistem piranti lunak. UML
menawarkan sebuah standar untuk merancang model sebuah sistem. Dengan menggunakan UML
kita dapat membuat model untuk semua jenis aplikasi piranti lunak, dimana aplikasi tersebut
dapat berjalan pada piranti keras, sistem operasi dan jaringan apapun, serta ditulis dalam bahasa
pemrograman apapun. Tetapi karena UML juga menggunakan class dan operation dalam konsep
dasarnya, maka ia lebih cocok untuk penulisan piranti lunak dalam bahasa bahasa berorientasi
objek seperti C++, Java, C# atau VB.NET. Walaupun demikian, UML tetap dapat digunakan
untuk modeling aplikasi prosedural dalam VB atau C. Seperti bahasa-bahasa lainnya, UML
mendefinisikan notasi dan syntax /semantik. Notasi UML merupakan sekumpulan bentuk khusus
untuk menggambarkan berbagai diagram piranti lunak. Setiap bentuk memiliki makna tertentu,
dan UML syntax mendefinisikan bagaimana bentuk-bentuk tersebut dapat dikombinasikan.
Notasi UML terutama diturunkan dari 3 notasi yang telah ada sebelumnya: Grady Booch OOD
(Object-Oriented Design), Jim Rumbaugh OMT (Object Modeling Technique), dan Ivar
Jacobson OOSE (Object-Oriented Software Engineering). Sejarah UML sendiri cukup panjang.
Sampai era tahun 1990 seperti kita ketahui 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 group/perusahaan lain yang menggunakan
metodologi yang berlainan.

Apa itu UML mas Arief?

April 21, 2010 admin 1 comment
BAGIAN-BAGIAN UML

Bagian-bagian utama dari UML adalah view, diagram, model element, dan general mechanism.

a. View

View digunakan untuk melihat sistem yang dimodelkan dari beberapa aspek yang
berbeda. View bukan melihat grafik, tapi merupakan suatu abstraksi yang berisi sejumlah
diagram.

Beberapa jenis view dalam UML antara lain: use case view, logical view, component view,
concurrency view,dan deployment view.

b. Use case view

Mendeskripsikan fungsionalitas sistem yang seharusnya dilakukan sesuai yang

diinginkan external actors. Actor yang berinteraksi dengan sistem dapat berupa user atau sistem
lainnya.

View ini digambarkan dalam use case diagramsdan kadang-kadang dengan activity

diagrams. Viewini digunakan terutama untuk pelanggan, perancang (designer), pengembang
(developer), dan penguji sistem (tester).

c. Logical view

Mendeskripsikan bagaimana fungsionalitas dari sistem, struktur statis (class,

object,danrelationship ) dan kolaborasi dinamis yang terjadi ketika object mengirim pesan
ke object lain dalam suatu fungsi tertentu.

View ini digambarkan dalam class diagrams untuk struktur statis dan dalam state, sequence,

collaboration, dan activity diagram untuk model dinamisnya. View ini digunakan untuk
perancang (designer) dan pengembang (developer).

d. Component view

Mendeskripsikan implementasi dan ketergantungan modul. Komponen yang merupakan tipe

lainnya dari code module diperlihatkan dengan struktur dan ketergantungannya juga alokasi
sumber daya komponen dan informasi administrative lainnya.

View ini digambarkan dalam component view dan digunakan untuk pengembang (developer).

e. Concurrency view

Membagi sistem ke dalam proses dan prosesor.View ini digambarkan dalam diagram dinamis
(state, sequence, collaboration, dan activity diagrams) dan diagram implementasi
(component dan deployment diagrams) serta digunakan untuk pengembang (developer),
pengintegrasi (integrator), dan penguji (tester).

f. Deployment view

Mendeskripsikan fisik dari sistem seperti komputer dan perangkat (nodes) dan bagaimana
hubungannya dengan lainnya.

View ini digambarkan dalam deployment diagramsdan digunakan untuk pengembang

(developer), pengintegrasi (integrator), dan penguji (tester).

g. Diagram

Diagram berbentuk grafik yang menunjukkan simbol elemen model yang disusun untuk
mengilustrasikan bagian atau aspek tertentu dari sistem. Sebuah diagram merupakan bagian dari
suatu view tertentu dan ketika digambarkan biasanya dialokasikan untuk view tertentu. Adapun
jenis diagram antara lain :

1. Use Case Diagram

Use case adalah abstraksi dari interaksi antara system dan actor. Use case bekerja dengan cara
mendeskripsikan tipe interaksi antara user sebuah system dengan sistemnya sendiri melalui
sebuah cerita bagaimana sebuah system dipakai. Use casemerupakan konstruksi untuk
mendeskripsikan bagaimana system akan terlihat di mata user. Sedangkan use case diagram
memfasilitasi komunikasi diantara analis dan pengguna serta antara analis dan client.

2. Class Diagram

Class adalah dekripsi kelompok obyek-obyek dengan property, perilaku (operasi) dan relasi yang
sama. Sehingga dengan adanya class diagram dapat memberikan pandangan global atas sebuah
system. Hal tersebut tercermin dari class- class yang ada dan relasinya satu dengan yang lainnya.
Sebuah sistem biasanya mempunyai beberapa class diagram. Class diagram sangat membantu
dalam visualisasi struktur kelas dari suatu system.

3. Component Diagram

Component software merupakan bagian fisik dari sebuah system, karena menetap di komputer
tidak berada di benak para analis. Komponent merupakan implementasi software dari sebuah
atau lebih class. Komponent dapat berupa source code, komponent biner, atau executable
component. Sebuah komponent berisi informasi tentang logic class atau class yang
diimplementasikan sehingga membuat pemetaan dari logical view ke component view.Sehingga
component diagram merepresentasikan dunia riil yaitu component software yang mengandung
component, interface dan relationship.

4. Deployment Diagram
Menggambarkan tata letak sebuah system secara fisik, menampakkan bagian-bagian software
yang berjalan pada bagian-bagian hardware, menunjukkan hubungan komputer dengan perangkat
(nodes) satu sama lain dan jenis hubungannya. Di dalam nodes,executeable
component dan object yang dialokasikan untuk memperlihatkan unit perangkat lunak yang
dieksekusi oleh node tertentu dan ketergantungan komponen.

5. State Diagram

Menggambarkan semua state (kondisi) yang dimiliki oleh suatu object dari suatu class dan

keadaan yang menyebabkan state berubah. Kejadian dapat berupa object lain yang mengirim
pesan. State class tidak digambarkan untuk semua class, hanya yang mempunyai
sejumlah state yang terdefinisi dengan baik dan kondisi class berubah oleh stateyang berbeda.

6. Sequence Diagram

Sequence Diagram digunakan untuk menggambarkan perilaku pada sebuah scenario.

Kegunaannya untuk menunjukkan rangkaian pesan yang dikirim antara object juga interaksi
antaraobject, sesuatu yang terjadi pada titik tertentu dalam eksekusi sistem.

7. Collaboration Diagram

Menggambarkan kolaborasi dinamis sepertisequence diagrams. Dalam menunjukkan pertukaran

pesan, collaboration diagrams menggambarkan objectdan hubungannya (mengacu ke konteks).
Jika penekannya pada waktu atau urutan gunakansequencediagrams, tapi jika penekanannya
pada konteks gunakan collaboration diagram.

8. Activity Diagram

Menggambarkan rangkaian aliran dari aktivitas, digunakan untuk mendeskripsikan aktifitas yang
dibentuk dalam suatu operasi sehingga dapat juga digunakan untuk aktifitas lainnya seperti use
caseatau interaksi.

Tujuan Penggunaan UML

1. Memberikan bahasa pemodelan yang bebas dari berbagai bahas pemrograman dan proses
rekayasa.
2. Menyatukan praktek-praktek terbaik yang terdapat dalam pemodelan.
3. Memberikan model yang siap pakai, bahsa pemodelan visual yang ekspresif untuk
mengembangkan dan saling menukar model dengan mudah dan dimengerti secara umum.
4. UML bisa juga berfungsi sebagai sebuah (blue print) cetak biru karena sangat lengkap dan detail.
Dengan cetak biru ini maka akan bias diketahui informasi secara detail tentang coding program
atau bahkan membaca program dan menginterpretasikan kembali ke dalam bentuk diagram
(reserve enginering).
Pengantar Unified Modelliing Language (UML)

Pendahuluan

Saat ini piranti lunak semakin luas dan besar lingkupnya, sehingga tidak bisa lagi dibuat asal-
asalan. Piranti lunak saat ini seharusnya dirancang dengan memperhatikan hal-hal seperti
scalability , security , dan eksekusi yang robust walaupun dalam kondisi yang sulit. Selain itu
arsitekturnya harus didefinisikan dengan jelas, agar bug mudah ditemukan dan diperbaiki,
bahkan oleh orang lain selain programmer aslinya. Keuntungan lain dari perencanaan arsitektur
yang matang adalah dimungkinkannya penggunaan kembali modul atau komponen untuk
aplikasi piranti lunak lain yang membutuhkan fungsionalitas yang sama. Pemodelan ( modeling )
adalah proses merancang piranti lunak sebelum melakukan pengkodean ( coding ). Model piranti
lunak dapat dianalogikan seperti pembuatan blueprint pada pembangunan gedung. Membuat
model dari sebuah sistem yang kompleks sangatlah penting karena kita tidak dapat memahami
sistem semacam itu secara menyeluruh. Semakin komplek sebuah sistem, semakin penting pula
penggunaan teknik pemodelan yang baik. Dengan menggunakan model, diharapkan
pengembangan piranti lunak dapat memenuhi semua kebutuhan pengguna dengan lengkap dan
tepat, termasuk faktor-faktor seperti scalability, robustness, security , dan sebagainya.
Kesuksesan suatu pemodelan piranti lunak ditentukan oleh tiga unsur, yang kemudian terkenal
dengan sebuan segitiga sukses ( the triangle for success ). Ketiga unsur tersebut adalah metode
pemodelan ( notation ), proses ( process ) dan tool yang digunakan.

Memahami notasi pemodelan tanpa mengetahui cara pemakaian yang sebenarnya (proses) akan
membuat proyek gagal. Dan pemahaman terhadap metode pemodelan dan proses disempurnakan
dengan penggunaan tool yang tepat.

Apa itu UML

Unified Modelling Language (UML) adalah sebuah “bahasa” yg telah menjadi standar dalam
industri untuk visualisasi, merancang dan mendokumentasikan sistem piranti lunak. UML
menawarkan sebuah standar untuk merancang model sebuah sistem. Dengan menggunakan UML
kita dapat membuat model untuk semua jenis aplikasi piranti lunak, dimana aplikasi tersebut
dapat berjalan pada piranti keras, sistem operasi dan jaringan apapun, serta ditulis dalam bahasa
pemrograman apapun. Tetapi karena UML juga menggunakan class dan operation dalam konsep
dasarnya, maka ia lebih cocok untuk penulisan piranti lunak dalam bahasa bahasa berorientasi
objek seperti C++, Java, C# atau VB.NET. Walaupun demikian, UML tetap dapat digunakan
untuk modeling aplikasi prosedural dalam VB atau C. Seperti bahasa-bahasa lainnya, UML
mendefinisikan notasi dan syntax /semantik. Notasi UML merupakan sekumpulan bentuk khusus
untuk menggambarkan berbagai diagram piranti lunak. Setiap bentuk memiliki makna tertentu,
dan UML syntax mendefinisikan bagaimana bentuk-bentuk tersebut dapat dikombinasikan.
Notasi UML terutama diturunkan dari 3 notasi yang telah ada sebelumnya: Grady Booch OOD
(Object-Oriented Design), Jim Rumbaugh OMT (Object Modeling Technique), dan Ivar
Jacobson OOSE (Object-Oriented Software Engineering). Sejarah UML sendiri cukup panjang.
Sampai era tahun 1990 seperti kita ketahui puluhan metodologi pemodelan berorientasi objek
telah bermunculan di dunia. Diantaranya adalah: metodologi booch [1], metodologi coad [2],
metodologi OOSE [3], metodologi OMT [4], metodologi shlaer-mellor [5], metodologi wirfs-
brock [6], 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 group/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). Tahun 1997 UML versi 1.1 muncul, dan saat ini versi
terbaru adalah versi 1.5 yang dirilis bulan Maret 2003. Booch, Rumbaugh dan Jacobson
menyusun tiga buku serial tentang UML pada tahun 1999 [7] [8] [9]. Sejak saat itulah UML
telah menjelma menjadi standar bahasa pemodelan untuk aplikasi berorientasi objek.

Konsepsi Dasar UML

Dari berbagai penjelasan rumit yang terdapat di dokumen dan buku-buku UML. Sebenarnya
konsepsi dasar UML bisa kita rangkumkan dalam gambar dibawah.

Major Area View Diagrams Main Concepts

static view class diagram class, association, generalization,
structural
dependency, realization, interface
use case view use case diagram use case, actor, association,
  extend, include, use case
generalization
  implementation component component, interface,
view diagram dependency, realization
dynamic statechart
state machine view diagram state, event, transition, action
  state, activity, completion
actifity view activity diagram transition, fork, join
  interaction, object, message,
sequence diagram activation
interaction view
  colaborating collaborating, interaction,
diagram collaboration rule, message
model
managemen model management
t view class diagram package, subsystem, model
constraint, stereotype, tagged
extensibility all all values
Abstraksi konsep dasar UML yang terdiri dari structural classification , dynamic behavior , dan
model management , bisa kita pahami dengan mudah apabila kita melihat gambar diatas dari
Diagrams . Main concepts bisa kita pandang sebagai term yang akan muncul pada saat kita
membuat diagram. Dan view adalah kategori dari diagaram tersebut. Lalu darimana kita mulai ?
Untuk menguasai UML, sebenarnya cukup dua hal yang harus kita perhatikan:

1. Menguasai pembuatan diagram UML

2. Menguasai langkah-langkah dalam analisa dan pengembangan dengan UML

Tulisan ini pada intinya akan mengupas kedua hal tersebut.

UML adalahDitulis Oleh : Grenalio Kristian PerdanaApa itu UML?

Intoducing UML.
Hal pertama yang perlu kita ketahui adalah apa sebenarnya UML?. Kebanyakan orang salah, UML
bukanlah Universal Modelling Language, dimana UML tidak diperuntukkan agar bisa membuat model
bagi apa saja (contoh, UML tidak terlalu baik untuk memodelkan persediaan pasar).

UML juga bukanlah Unified Marxist-Leninists, suatu partai politik di Nepal. UML adalah Unified
Modelling Language.
Di atas mungkin bukanlah bagian terpenting yang perlu diketahui. Yang lebih penting adalah, UML
merupakan standardized modelling language yang terdiri dari kumpulan-kumpulan diagram,
dikembangkan untuk membantu para pengembang sistem dan software agar bisa menyelesaikan tugas-
tugas seperti:

• Spesifikasi

• Visualisasi

• Desain Arsitektur

• Konstruksi

• Simulasi dan testing

• Dokumentasi

UML dikembangkan sebagai ide dasar untuk mempromosikan hubungan dan produktifitas antara para
pengembang dari object-oriented system.

Memahami kemampuan UML

UML memuaskan kebutuhan yang penting dalam pengembangan software dan sistem. Pemodelan
(modelling) memungkinkan para pengembang bisa berkonsentrasi pada gambaran yang luas. UML
membantu kita melihat dan menyelesaikan masalah-masalah yang sering terjadi. Ketika kita membuat
model, kita membuat suatu abstraksi dari sistem nyata yang sudah ada, yang memungkinkan kita bisa
bertanya tentang model tersebut dan akan kita dapatkan jawaban yang memuaskan.
Setelah kita puas dengan hasil kerja kita, kita bisa menggunakan model kita bersama dengan orang lain.
Kita bisa menggunakan model kita untuk meminta bantuan dari orang lain yang akan meningkatkan
kerja kita, dan juga dapat saling membantu dengan mengajari orang lain.
Abstracting
Teknik dalam membuat model dari ide kita atau dunia nyata adalah dengan menggunakan abstraction.
Sebagai contoh, map merupakan model dunia – bukanlah miniatur dunia.
Setiap diagram UML yang kita gambar memiliki keterkaitan dengan dunia nyata. Abstraction
dikembangkan sebagai ketentuan untuk dipelajari dan sering digunakan.
Jika kita berpikir UML sebagai map dari dunia yang kita lihat, hampir mendekati. Analogi yang lebih
mendekati adalah merupakan kumpulan dari blueprint yang menampilkan detail yang cukup dari suatu
bangunan untuk memastikan tentang apa sebenarnya bangunan tersebut. Abstraction model dan
diagram juga berguna karena akan menjelaskan lebih rinci detail-detail yang dibutuhkan (kita tidak perlu
mengambar pohon dan mobil dan orang dalam map kita, karena map kita akan menjadi susah alias tidak
praktis untuk dipakai).

Kategori diagram UML

• Structural Diagram: kita menggunakan structural diagram untuk menampilkan blok bangunanan dari
sistem kita – merupakan fitur yang tidak berubah bersama waktu. Diagram ini menjawab pertanyaan,
ada apa disana?

• Behavioral Diagram: kita menggunakan behavioral diagram untuk menampilkan bagaimana sistem kita
merespon permintaan atau apa saja seiring waktu.

• Interaction diagram: merupakan tipe dari behavioral diagram. Kita menggunakan interaction diagram
untuk melukiskan perubahan dari pesan-pesan dalam suatu kolaborasi (kumpulan dari object-object
yang sama) sehingga tujuan bisa tercapai.

• Structural diagram (Class diagram) : Digunakan untuk menampilkan entiti dunia nyata, elemen dari
analisa dan desain, atau implementasi class dan relasinya.

1. Structural diagram (Object diagram) : Digunakan untuk menampilkan suatu contoh spesifik atau
ilustrasi dari suatu object serta link nya. Sering digunakan untuk mengindikasikan kondisi dari suatu
even, seperti percobaan atau operasi pemanggilan.

2. Structural diagram (Composite structure diagram) : Digunakan untuk menampilkan bagaimana

sesuatu itu dibuat.

3. Structural diagram (Deployment diagram) : Digunakan untuk menampilkan arsitektur run-time dari
suatu sistem, kerangka hardware, ruang lingkup software, dan sebagainya.

4. Structural diagram (Component diagram) : Digunakan untuk menampilkan organisasi dan hubungan
antar sistem.

5. Structural diagram (Package diagram) : Digunakan untuk mengorganisir elemen model dan
menampilkan ketergantungan antara mereka.

6. Behavioral diagram (Activity diagram) : Digunakan untuk menampilkan arus data dari kebiasaan antar
object.

7. Behavioral diagram (Use case diagram) : Digunakan untuk menampilkan layanan yang bisa diminta
oleh actor dari sistem kita.

8. Behavioral diagram (State machine diagram / Protocol state machine diagram) : Digunakan untuk
menampilkan urutan proses dari suatu object dan kondisinya saat ini.

9. Interaction diagram (Overview diagram) : Digunakan untuk menampilkan banyak skenario interaksi
(urutan dari kebiasaan) bagi suatu kolaborasi (kumpulan elemen yang sama dan saling bekerja agar
tercapai tujuan yang diinginkan).

10. Interaction diagram (Sequence diagram) : Digunakan untuk fokus pada perubahan pesan antara grup
dari suatu object dan urutan pesan tersebut.

11. Interaction diagram (Communication diagram) : Digunakan untuk fokus pada perubahan pesan
antara grup dari suatu object dan relasi dari object-object tersebut.

12. Interaction diagram (Timing diagram) : Digunakan untuk menampilkan perubahan dan hubungan
terhadap waktu nyata atau terhadap proses sistem.

Karena UML sangatlah fleksibel, kita akan menjumpai berbagai cara dalam meng-kategorikan diagram
kita. Pohon kategori di bawah ini cukup terkenal:

• Static diagram: Menampilkan fitur statis dari sistem. Kategori ini hampir sama dengan structural
diagram.

• Dynamic diagram: Menampilkan bagaimana proses perubahan yang terjadi dalam sistem sepanjang
waktu. Kategori ini mencakup UML state-machine diagram dan timing diagram.
• Functional diagram: Menampilkan detail dari proses dan algoritma. Kategori ini mencakup use case,
interaction, dan activity diagram.

Kita bisa mengembangkan diagram UML untuk menampilkan informasi yang berbeda pada waktu yang
berbeda atau untuk tujuan yang berbeda. Ada banyak kerangka modelling, seperti Zachman atau
DODAF. Berikut pertanyaan standar tentang sistem :

• Siapa yang menggunakan sistem? Menampilkan actor (pengguna sistem) dalam diagram use
case(menampilkan tujuan sistem)

• Dari mana sistem dibuat? Menggambarkan diagram Class untuk menampilkan struktur logis dan
component diagram agar bisa menampilkan struktur fisik.

• Dimana lokasi komponen dalam suatu sistem? Mengindikasikan rencana kita untuk menentukan lokasi
suatu komponen.

• Kapan kejadian penting terjadi? Menampilkan apa yang menyebabkan object kita bisa bereaksi dan
mulai melakukan kerjanya dengan state diagram dan interaction diagram.

• Bagaimana sistem ini bekerja? Menampilkan bagian struktur diagram dan menggunakan
communication diagram untuk menampilkkan interaksi.

Siapa yang memerlukan UML?

Para pengguna UML dibagi dalam kategori:

• Modeler: Modeler mencoba menjelaskan dunia nyata seperti bagaimana mereka melihatnya.

• Designer: Designer mencoba mencari solusi yang memungkinkan, untuk dibandingkan atau
menentukan proses pada aspek yang berbeda.

• Implementer: Implementer membangun solusi menggunakan UML sebagai bagian dari tujuan
implementasi. Kebanyakan program UML sekarang sudah bisa membuat sendiri definisi dari suatu Class
atau Database, seperti kode aplikasi atau user interface.
Software Apa yang Nyaman Untuk UML..?

UML saat ini lagi ngetren digunakan untuk analisa maupun rekayasa perangkat lunak. Cara
pandangnya yang berorientasi objek menjadikan UML sebagai sebuah permodelan sistem yang
sesuai dengan era pemrograman komputer saat ini. UML memberikan kemudahan dalam
melakukan analisa suatu sistem, selain itu kemudahannya untuk dimengerti oleh kalangan yang
belum mengenal analisa dan perancangan sistem juga menjadikan UML sebagai sebuah
terobosan baru. Cara pandangnya yang tidak harus pakem seperti pada permodelan pemrograman
terstruktur menjadikan UML turut lebih diminati.
Berbagai pengembang software berlomba membuat sebuah tool yang dapat merancang
permodelan sistem dengan UML. Dari yang bersifat gratis sampai yang harus membayar
segudang rupiah telah ada menanti kita. So, seperti biasa tinggal kita sendiri yang menentukan
software mana yang mau kita jadikan tool favourite untuk UML. Dari beberapa software untuk
melakukan permodelan diantaranya adalah :

Relational Rose
Mungkin tool ini yang sangat sering kita dengan sebagai software untuk perancangan dengan
model UML. Ehm…. mungkin karena kemudahannya dan berjalan di Microsoft Windows
sehingga tool ini menjadi favourite. Relational Rose telah memiliki banyak sekali fitur untuk
permodelan UML yang terkandang malah membingungkan pengguna. Hal yang mungkin kurang
saya gemari adalah Relational Rose memberikan patokan runtutan dalam menganalisa. Eh… jadi
paten dech… nggak bisa ngembangin kreatifitas.

With Class
Walaupun namanya tidak sepopuler Relational Rose namun With Class juga merupakan software
permodelan UML yang menarik. Lagi-lagi software ini juga harus merogoh kocek agak dalam.
Namun, bagi yang hanya ingin mencoba With Class menyediakan versi Trial. Lumayan kalau
jatah analisa kita 1 bulan kan pas…!

UML Plugin di NetBeans IDE

Seperti biasa NetBeans IDE yang didukung oleh Sun Microsystem mempunyai banyak sekali
plugin, yang termasuk diantaranya adalah UML Plugin. Emmmmm… bagus sich, tapi berat
banget loadingnya…. apalagi kalau dipasang pada komputer pas-pasan … minta ampun dech…
Tapi lumayan powerfull karena selain include dengan NetBeans yang so pasti dekat dengan
JAVA.

DIA
Nah, kalau ini biasanya jalan di sistem operasi LINUX. DIA merupakan software untuk
menggambar diagram. Walaupun bukan spesialis UML, tetapi DIA telah menyediakan plugin
UML yang dapat kita gunakan free. Apalagi runningnya yang tergolong ringan patut untuk kita
perhitungkan sebagai tool permodelan dengan UML.

Umbrello
Nah, kalau ini spesialis UML di sistem operasi LINUX. Selain ringan dalam pemakaian,
Umbrello juga lengkap untuk membuat permodelan diagram-diagram UML. Em… walaupun
belum selengkap Relational Rose, namun Umbrello dapat menjadi pilihan yang tepat. Apalagi
kita ndak lagi dikekang harus dengan metode seperti apa dalam merancang sebuah sistem.
Pengertian USE CASE

Deskripsi singkat tentang USE CASE

 Perilaku sistem adalah bagaimana sistem beraksi dan bereaksi. Perilaku ini merupakan
aktifitas sistem yang bisa dilihat dari luar dan bisa diuji.
 Perilaku sistem ini dicapture di dalam USE CASE. USE CASE sendiri mendeskripsikan
sistem, lingkungan sistem, serta hubungan antara sistem dengan lingkungannya.

Defenisi Use Case

 Deskripsi dari sekumpulan aksi sekuensial yang ditampilkan sistem yang menghasilkan
yang tampak dari nilai ke actor khusus. Use Case digunakan untuk menyusun behavioral
things dalam sebuah model. Use case direalisasikan dengan sebuah collaboration. Secara
gambar, sebuah use case digambarkan dengan sebuah ellips dengan garis penuh, biasanya
termasuk hanya namanya, seperti gambar berikut :

 Representasi atau model yang digunakan dalam Rekayasa Perangkat Lunak untuk
menggambarkan fungsional requirement suatu sistem.
 Sekelompok skenario pengguna yang menggambarkan alur penggunaan sistem.
 Setiap skenario digambarkan dari sudut pandang “aktor”, seseorang atau piranti yang
berinteraksi dengan perangkat lunak dalam berbagai cara.
 Suatu Use Case adalah suatu sekuensial aksi yang dilakukan oleh sistem, yang akan
secara bersama-sama, memproduksi hasil yang dibutuhkan oleh pengguna sistem. Use
Case mendefinisikan alur proses sepanjang sistem berbasis pada kegunaan sebagaimana
yang biasa dilakukan (secara manual).

Contoh sederhana:
Konsumen pesan tiket pesawat
Contoh lebih lengkap:
Use Case pada Sistem Rumah Sakit

Kegunaan Use Case adalah untuk menspesifikasikan konteks sistem, menggambarkan kebutuhan
sistem, memvalidasikan arsitektur sistem, menjalankan implementasi dan meng-generate test
case.

Include
Keterhubungan secara include antar use case menunjukkan bahwa use case asal secara eksplisit
memasukkan perilaku dari use case lain yang ditunjuk oleh use case tersebut. Included use case
tidak pernah berdiri sendiri, tetapi hanya merupakan bagian dari beberapa use case yang lebih
besar yang diikutinya. Keterhubungan use case secara include pada dasarnya merupakan sebuah
contoh dari pendelegasian - sekumpulan dari tanggung jawab sebuah sistem diambil dan
ditangkap di dalam satu tempat (included use case) - kemudian bagian lainnya dari sistem (use
case yang lain) memasukkan kumpulan tanggung jawab yang baru setiap saat mereka
memerlukan fungsi-fungsi use case tersebut.

Extend
Keterhubungan use case secara extend menunjukkan bahwa use case yang ditunjuk merupakan
perluasan perilaku dari use case asal. Use case asal dapat berdiri sendiri, tetapi untuk kondisi
tertentu perilaku use case tersebut dapat diperluas oleh perilaku dari use case lain. Hubungan
perluasan digunakan untuk memodelkan bagian dari use case yang dapat dilihat oleh user
sebagai perilaku yang dapat dipilih dari sistem. Hubungan perluasan juga dapat digunakan untuk
memodelkan sub aliran yang terpisah-pisah yang hanya dapat dijalankan dalam kondisi tertentu.
Pada akhirnya, hubungan perluasan use case untuk memodelkan beberapa aliran yang dapat
dimasukkan dalam titik tertentu.
Manfaat Model Use Case

 Digunakan untuk berkomunikasi dengan end user dan domain expert
o Menyediakan buy-in pada tahap awal pengembangan sistem.
o Memastikan pemahaman yang tepat tentang requirement / kebutuhan sistem.
 Digunakan untuk mengidentifikasi
o Siapa yang berinteraksi dengan sistem dan apa yang harus dilakukan sistem.
o Interface yang harus dimiliki sistem.
 Digunakan untuk ferifikasi
o Semua requirement yang telah dicapture.
o Tim pengembang memahami requirement.

Macam-macam Use Case

 Narative Form
Bentuk teks bebas dalam format paragraph.
 Scenerio Form
Penjelasan penulisan use case dari sudut pandang actor.
 Conversation Form
Dialog antara actor dan sistem yang menunjukkan interaksi antar keduanya.
 Perbandingan Bentuk Use Case

Format Penulisan Use Case

Tiap Use Case memiliki:

 Precoditions, yang harus dipertemukan agar use cases dapat bekerja dengan sukses.
 Postconditions, mendefinisikan kondisi-kondisi dimana use cases berakhir.
 Postconditions mengidentifikasi hasil yang dapat diobservasi dan status akhir dari sistem
setelah use case telah komplit.
 Flow of events, yang mendefinisikan aksi pengguna dan respon sistem terhadap aksi yang
dilakukan. Flow of events merupakan kompresi dari skenario normal, yang
mendefinisikan tingkah laku umum dari sistem untuk use case, dan cabang-cabang
alternatif, dimana bagian lain yang telah tersedia dapat digunakan oleh use case.

Use Case dan Test Cases akan bekerja dengan baik dalam dua cara, yaitu:

 Jika use case dari sistem komplit, akurat dan jelas, maka pembuatan test cases dapat
dilakukan secara langsung.
 Jika use case tidak dalam kondisi yang baik, maka pembuata test cases akan membantu
dalam melakukan debug terhadap test cases.
Modul Use Case
Mulai dengan kondisi atau kejadian normal biasa:

 Acuhkan pengecualian, alternatif, dll.
 Use case harus dinamai dan perspektif pengguna sebagai kata kerja aktif.
 Menunjukkan deskripsi tujuan dari use case dan defenisi fungsionalitas tingkat
tinggi.
Model Use Case

 Model untuk melengkapi system requirements

 Tahapan awal "system development":

o Requirement: sistim belum terinci

o Representasi: user perspektif

"What the system will/should do ?"

 Starting point: OO analysis & design activities

 Garis besar terdiri dari: "actors" dan "use cases"

Actors

 Types yang mewakili: users yang berinteraksi dengan sistim

 Users: di luar dari sistim, batasan apa yang akan diharapkan dari sistim

o Pengertian users => types of activities performed by external entity

o Sekumpulan individu  dapat dianggap sebagai satu user (same role)

 Actors: manusia, external hardware, atau sistim yang lain

Use Case

 Types yang mewakili: behaviour, sifat / karakteristik dan fungsi sistim

 Dikembangkan sesuai dengan keinginan "actor"

 Dapat diterjemahkan sebagai bentuk eksekusi pemakaian sistim

o Interaksi dan fungsi yang diharapkan dari sistim

o Flow events response dari sistim

Contoh : ATM Cashier Application

 Actor: Klien Bank

 Bagaimana interaksi dengan aplikasi di ATM ?
Fasilitas apa saja yang dapat diberikan oleh Bank kepada Klien Bank

 User cases:
o Tarikan Uang
o Deposit Uang
o Transfer Antar Rekening

 Actor: apa saja yang berinteraksi (memberikan dan menerima data atau events) dengan
sistim
o Actor dapat mewakili sekelompok klien bank (yang mempunyai karut ATM)
 o Satu klien dapat menggunakan ATM tersebut untuk berbagai keperluan =>
berbagai actors yang berbeda
o Peranan actor ditentukan use case mana saja yang digunakan oleh actor tersebut
 Interaksi ? tidak lain mengirim dan menerima messages (data, events)
o Hubungan antara actor dan use case: <<communication>> associations

Use Case: Transactions

 Definisi: use case adalah urutan transaksi/proses yang dilakukan oleh sistim, dimana
menghasilkan sesuatu yang dapat dilihat/diamati oleh actor tertentu

 Problem: bagaimana memilih use case yang tepat (terdapat banyak kejadian interaksi
antar actor dan system) ?
o Definisi di atas => "instance" kejadian yang penting dan dapat dipilah sangat
relevan dengan kegiatan actors
o Pilih use case type yang mewakili instance tersebut
o Dari definisi "menghasilkan sesuatu yang dapat dilihat oleh actor" => use case
harus cukup besar karena berhubungan dengan kegiatan actor
o Transaksi: sekumpulan aksi, keputusan, dan messages yang diberikan kepada
actors secara konsisten
o Actor tertentu: peranan utama, karena hasil use case harus berhubungan dengan
actor tersebut, berhubungan dengan task tertentu

Contoh

Use case: Tarikan Uang

 Klien Bank memberikan identifikasi dirinya

 Klien Bank memilih atau memberikan input berapa banyak uang yang akan diambil dari
rekening.  Sistim memberikan persetujuan dan mengijinkan berapa banyak uang yang
dapat diambil
 Sistim mengeluarkan uang tersebut dan mengurangi jumlah uang tersebut dari rekening

Reuse Use Case : <<uses>>

 Untuk sistim yang besar: terdapat use case yang sifatnya sama

 Kelompok use case ini dapat  dibuat : "generalizations" yang mewakili kelompok tsb.

o Dapat dianggap sebagai "inheritance" 

 o Digunakan simbol: <<uses>>

 Contoh: <<uses>> use case A menggunakan use case B berarti instance A dapat
melakukan semua sifat dari instance B

o Sebagai contoh: semua transaksi ATM berhubungan dengan pemindahan uang

dari satu rekening ke rekening lain.

 Dapat menggunakan use case yang telah ada: Transfer Keuangan sebagai "abstract" use
case.

Transfer Keuangan use case memberikan deskripsi cara debit dan kredit dari berbagai account
yang berbeda.

Reuse Use Case : <<extends>>

 Sering use case dapat dikembangkan (ditambahkan) dari use case yang telah ada

 Penambahan ini untuk memberikan spesialisasi atau inheritance

 Jadi jika disebut use case A "extends" use case B : maka instance tersebut mengikuti use
case A dan pada satu saat akan mengikuti use case B, setelah mengikuti B dapat
kembali ke use case A.

 Contoh: Klien Bank dapat diberikan fasilitas untuk mengambil uang dalam bentuk
overdraft.

Untuk kasus dimana Klien Bank mengambil overdraft maka terdapat sifat khusus use
case yang harus ditangani oleh "Manajemen Overdraft" 

Atau dapat disebut: use case Manajemen Overdarft merupakan "extends" dari use case
Tarikan Uang.
 

Contoh Lain: