Sejarah UML
UML dimulai secara resmi pada oktober 1994, ketika Rumbaugh bergabung
dengan Booch pada Relational Software Corporation. Proyek ini
memfokuskan pada penyatuan metode Booch dan OMT. UML versi 0.8 merupakan
metode penyatuan yang dirilis pada bulan Oktober 1995. Dalam waktu yang
sama, Jacobson bergabung dengan Relational dan cakupan dari UML semakin
luas sampai diluar perusahaan OOSE. Dokumentasi UML versi 0.9 akhirnya
dirilis pada bulan Juni 1996. Meskipun pada tahun 1996 ini melihat dan
menerima feedback dari komunitas Software Engineering . Dalam waktu
tersebut, menjadi lebih jelas bahwa beberapa organisasi perangkat lunak
melihat UML sebagai strategi dari bisnisnya. Kemudian dibangunlah UML
Consortium dengan beberapa organisasi yang akan menyumbangkan sumber
dayanya untuk bekerja, mengembangkan, dan melengkapi UML.
Di sini beberapa partner yang berkontribusi pada UML 1.0, diantaranya
Digital Equipment Corporation, Hewlett-Packard, I-Logix, Intellicorp,
IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Relational,
Texas Instruments dan Unisys. Dari kolaborasi ini dihasilkan UML 1.0
yang merupakan bahasa pemodelan yang ditetapkan secara baik, expressive,
kuat, dan cocok untuk lingkungan masalah yang luas. UML 1.0 ditawarkan
menjadi standarisasi dari Object Management Group (OMG). Dan pada
Januari 1997 dijadikan sebagai standar bahasa pemodelan
Antara Januari–Juli 1997 gabungan group tersebut memperluas
kontribusinya sebagai hasil respon dari OMG dengan memasukkan Adersen
Consulting, Ericsson, ObjectTimeLimeted, Platinum Technology, Ptech,
Reich Technologies, Softeam, Sterling Software dan Taskon. Revisi dari
versi UML (versi 1.1) ditawarkan kepada OMG sebagai standarisasi pada
bulan Juli 1997. Dan pada bulan September 1997, versi ini dierima oleh
OMG Analysis dan Design Task Force (ADTF) dan OMG ArchitectureBoard. Dan
Akhirnya pada Juli 1997 UML versi 1.1 menjadi standarisasi.
Pemeliharaan UML terus dipegang oleh OMG Revision Task Force (RTF)
yang dipimpin oleh Cris Kobryn. RTP merilis editorial dari UML 1.2 pada
Juni 1998. Dan pada tahun 1998 RTF juga merilis UML 1.3 disertai dengan
user guide dan memberikan technical cleanup.
Pengertian UML
UML adalah bahasa untuk menspesifikasi, memvisualisasi, membangun dan
mendokumentasikan artifacts (bagian dari informasi yang digunakan atau
dihasilkan oleh proses pembuatan perangkat lunak, artifact tersebut
dapat berupa model, deskripsi atau perangkat lunak) dari sistem
perangkat lunak, seperti pada pemodelan bisnis dan sistem non perangkat
lunak lainnya [HAN98]. Selain itu UML adalah bahasa pemodelan yang
menggunakan konsep orientasi object. UML dibuat oleh Grady Booch, James
Rumbaugh, dan Ivar Jacobson di bawah bendera Rational Software Corp
[HAN98]. UML menyediakan notasi-notasi yang membantu memodelkan sistem
dari berbagai perspektif. UML tidak hanya digunakan dalam pemodelan
perangkat lunak, namun hampir dalam semua bidang yang membutuhkan
pemodelan..
Gambaran Umum UML
Gambaran umum mengenai UML dapat dijelaskan berdasarkan kegunaan dari UML itu sendiri, yaitu:
1. Modeling Language, UML sebagai bahasa untuk pemodelan sistem
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 sistem
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 mempelajari
code 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.
1. 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.
2. Constructing, UML sebagai bahasa untuk membangun sistem
UML bukan bahasa pemograman visual, tetapi model UML dapat
dikoneksikan secara langsung pada bahasa pemograman visual. Maksudnya
membangun model yang dapat dimapping ke bahasa pemograman seperti java,
C++, VB atau tabel pada database relational atau penyimpanan tetap pada
database berorientasi object.
3. Documenting, UML sebagai bahasa untuk pendokumentasian sistem
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).
Ø Area dan Tujuan Penggunaan UML
UML (Unified Modeling Language) digunakan paling efektif pada domain seperti:
- Sistem Informasi Perusahaan
- Sistem Perbankan dan Perekonomian
- Bidang Telekomunikasi
- Bidang Transportasi
- Bidang Penerbangan
- Bidang Perdagangan
- Bidang Pelayanan Elekronik
- Bidang Pengetahuan
Bidang Pelayanan Berbasis Web Terdistribusi
UML tidak terbatas untuk pemodelan software saja. Pada faktanya UML
banyak digunakan untuk memodelkan sistem non-software seperti:
Aliran kerja pada sistem perundangan.
Struktur dan kelakuan dari Sistem Kepedulian Kesehatan Pasien
Desain hardware dll.
Struktur dan kelakuan dari Sistem Kepedulian Kesehatan Pasien
Desain hardware dll.
Tujuan penggunaan UML adalah, sebagai berikut:
- Memodelkan suatu sistem (bukan hanya perangkat lunak) yang menggunakan konsep berorientasi object
- Menciptakan suatu bahasa pemodelan yang dapat digunakan baik oleh manusia maupun mesin.
Keunggulan menggunakan UML dibandingkan menggunakan metodologi terstruktur:
- Uniformity
Pengembang cukup menggunakan 1 metodologi dari tahap analsis hingga
perancangan. Memungkinkan merancang komponen antarmuka secara
terintegrasi bersama perancangan PL dan perancangan struktur data
- Understandability
Kode yang dihasilkan dapat diorganisasi kedalam kelas-kelas
yangberhubungan dengan masalah sesungguhnya sehingga lebih mudah untuk
dipahami.
- Stability
Kode program yang dihasilkan relatif stabil sepanjang waktu, karena mendekati permasalahan yang sesungguhnya.
- Reusability
Dengan metodologi berorientasi objek, dimungkinkan penggunaan ulang kode, sehingga pada akhirnya akan sangat
mempercepat waktu pengembangan perangkat lunak (atau sistem informasi).
Berikut jenis - jenis diagram pada uml :
A. Use Case Diagram
Use case diagram menggambarkan fungsionalitas yang
diharapkan dari sebuah sistem. Yang ditekankan adalah “apa” yang
diperbuat sistem, dan bukan “bagaimana”. Sebuahuse case merepresentasikan sebuah interaksi antara aktor dengan sistem. Use casemerupakan 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 menyusunrequirement 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 kaliuse 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 casejuga 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.
B. Class Diagram
Class adalah sebuah spesifikasi yang jika diinstansiasi akan
menghasilkan sebuah objek dan merupakan inti dari pengembangan dan
desain berorientasi objek. Classmenggambarkan keadaan
(atribut/properti) suatu sistem, sekaligus menawarkan layanan untuk
memanipulasi keadaan tersebut (metoda/fungsi). Class diagrammenggambarkan 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 classyang memiliki atribut berupa class lain, atau class yang harus mengetahui eksistensi class lain. Panah navigability m enunjukkan arah query antar class .
- Agregasi, yaitu hubungan yang menyatakan bagian (“terdiri atas..”).
- Pewarisan, yaitu hubungan hirarkis antar class . Class dapat diturunkan dari classlain 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.
- Hubungan dinamis, yaitu rangkaian pesan ( message ) yang di- passing dari satuclass kepada class lain. Hubungan dinamis dapat digambarkan dengan menggunakan sequence diagram yang akan dijelaskan kemudian.
C. Statechart Diagram
Statechart diagram menggambarkan transisi dan perubahan keadaan (dari satu state kestate 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 antarstate umumnya memiliki kondisi guard yang merupakan syarat terjadinya transisi yang bersangkutan, dituliskan dalam kurung siku. Action yang dilakukan sebagai akibat darievent tertentu
dituliskan dengan diawali garis miring. Titik awal dan akhir
digambarkan berbentuk lingkaran berwarna penuh dan berwarna setengah.
D. 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 diagramkhusus, 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 satuuse 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.
E. 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, memilikilifeline 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 .
F. 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 manamessage dari level tertinggi memiliki nomor 1. Messages dari level yang sama memiliki prefiks yang sama.
G. 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 librarymaupun 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.
H. Deployment Diagram
Deployment/physical diagram menggambarkan detail bagaimana komponen di- deploydalam
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.
Tidak ada komentar:
Posting Komentar