Unified Modelling Language
( Sebuah Telaah Referensi )
Abstract, the shifting of software development orientation. From the ordered software to an object was ariring various methodology in conucting analysis and software design. This matter makes Boach. Rambaugh and Ivar Jacobson to collaborate in regard to create a language that can brigde variour thore methodolog. This language is then to be called as Unified Modelling Language and stood for UML
Abstrak, bergesernya orientasi pembangunan perangkat lunak dari terstruktur ke objek telah memunculkan berbagai metodologi dalam melakukan analisis dan desain perangkat lunak. Hal ini melatarbelakangi Boach, Rambaugh dan Ivar Jacobson untuk berkolaborasi dalam rangka menciptakan sebuah bahasa yang menjebatani berbagai metodologi tersebut. Bahasa ini kemudian diberi nama Unified Modelling Language yang disingkat dengan UML
1. Latar Belakang
Unified Modelling Language atau lazim disebut dengan UML adalah sebuah bahasa yang digunakan dalam Analisis dan Desain Berorientasu Object. Bahasa ini dikembangkan untuk memberikan standar notasi terhadap berbagai metodologi yang diterapkan dalam OOAD. UML merupakan bahasa pemodelan yang dihasilkan oleh kolaborasi tiga orang yang telah memberikan metodologi untuk OOAD yang telah ada sebelumnya, yakni Grady Booch ( Object Oriented Design Methodology ), James Rumbaugh ( Object Modelling Technique ), dan Ivar Jacobson ( Object Oriented Software Engineering ). Penciptaan UML dimaksudkan untuk memberikan solusi terhadap tiga permasalahan pokok yang umum dihadapi dalam pengembangan sistem dengan paradigma berorientasi object, yakni pemodelan sistem, sistem-sistem yang mission critical dan bahasa pemodelan yang dapat menjembatani pemikiran manusia dan mesin.
2. Overview UML
Dalam kaitannya sebagai bahasa standar, maka terdapat empat aspek pokok yang diberikan oleh UML, yakni :
a. Visualisasi
b. Spesifikasi
c. Konstruksi
d. Dokumentasi
a. Visualisasi
Visualisasi adalah proses menggambarkan blueprint suatu sistem secara grafis. Visualisasi terdiri dari beberapa komponen ,interface, dan koneksi-koneksi yang ada dalam sistem tersebut. Tujuan dari visualisasi ini adalah agar permasalahan lebih mudah untuk dipahami dan dikomunikasikan. UML adalah kumpulan dari simbol- simbol di dalam notasi UML merupakan suatu semantik yang terdefinisi dengan baik. Dalam kaitan sebagai bahasa untuk visualisasi, maka ada dua model yang dapat dikerjakan di dalam UML, yakni :
1. Business Modelling, merupakan teknik-teknik yang digunakan untuk menggambarkan model sebuah bisnis. Terdapat dua jenis business modelling, yakni business use case model dan business object model. Business object model menggambarkan realisasi dari business use case model.
2. Model untuk rekayasa sistem merupakan teknik grafis untuk menggambarkan sistem yang akan dibangun secara keseluruhan. Model ini bertujuan untuk :
a. Mendefinisikasi reguerements yang dibutuhkan dalam perekayasaan sistem.
b. Melihat bagaimana komponen-komponen saling berinteraksi
c. Memudahkan komunikasi antar anggota tim perekayasaan dalam memahami pemasalahan
b. Spesifikasi
Dalam konteks sebagai bahasa untuk spesifikasi, UML ditujukan untuk membangun suatu model yang persis, tidak ambigu dan komplet. Spesifikasi dalam UML dimaksudkan untuk semua bagian penting pada tahap analisis, desain dan implementasi. Dalam hal ini spesifikasi harus diputuskan dan dibuat dalam pembangunan sistem perangkat lunak.
c. Konstruksi
UML bukanlah sebuah bahasa pemprograman visual, tetapi merupakan model bahasa yang dapat secara langsung dihubungkan dengan berbagai varitas bahasa pemprograman. Kondisi ini dimasudkan agar model-model yang ada dalam UML dapat dipetakan secara langsung ke sebuah bahasa pemprograman seperti Java, C ++, dan lain sebagainya. Disamping itu model-model di dalam UML juga dapat dipetakan ke dalam sebuah database relasional atau Object Oriented Database.
d. Dokumentasi
UML dialamatkan kepada dokumentasi dari arsitektur sistem dan semua artifact secara detail dari Perangkat Lunak . UML juga menyediakan suatu bahasa untuk mengungkapkan requirements dan pengajuan. Selanjutnya, UML menyediakan sebuah bahasa untuk memodelkan aktivitas dari perencanaan proyek dan release management.
3. Prinsip-Pridinsip UML
Berkaitan dengan prinsip, maka terdapat empat prinsip yang ada didalam UML, yakni :
a. Pemilihan apakah model-model yang dibuat memiliki suatu pengaruh yang besar
terhadap bagaimana sebuah permasalahan dipecahkan dan bagaimana sebuah penyelesaian
ditentukan.
b. Setiap model dapat diekspresikan pada level-level yang berbeda dan dibuat secara cermat.
c. Model-model terbaik memiliki koneksi untuk realitas
d. Model tidak tunggal cukup maksudnya adalah setiap sistem nontrivial merupakan pendekatan dari sebuah himpunan sederhana model- model yang hampir bebas.
4. Konseptual UML
Untuk memahami UML dibutuhkan form suatu model suatu konsep dari sebuah bahasa dan ini membawa kepada tiga elemen dasar, yaitu : The UML basic building blocks, rules that dictate how those building blocks may be put together dan some common mechanism that apply throughout the UML.
4.1 The UML Basic Building Blocks
Vocabulary UML mencakup tiga macam building blocks, yaitu :
a. Things, dalam kaitannya dengan things, maka dapat ditinjau dari empat pokok, yaitu :
1. Structur Things, adalah kata benda dari model-model UML. Merupakan bagian statik dari sebuah model, elemen-elemennya mempresentasikan salah satu dari konseptual atau fisik. Terdapat tujuh macam struktur things yang meliputi :
a. Class, sebuah kelas adalah deskripsi dari sebuah himpunan objek yang memiliki kesamaan atribut,operasi, relasi dan semantik. Secara grafis sebuah kelas diterjahkan sebagai sebuah persegi yang didalamnya terdapat nama kelas, atribut dan operasi. Ilustrasi dari sebuah kelas dapat dilihat dari gambar berikut :
<=== Nama kelas
<=== Atribut
<=== Operasi / Methoda
Gambar 3.1 Kelas
b. Interface, adalah suatu kumpulan dari operasi yang menentukan sebuah layanan dari sebuah kelas atau komponen. Sebuah interface selanjutnya melukiskan kelakuan eksternal dari suatu elemen. Sebuah interface dapat mewakili sebuah kelas atau komponen atau hanya sebuah bagian dari tingkah laku. Interface mendefinisikan sebuah himpunan spesifikasi operasi. Secara grafis interface diterjemahkan dengan sebuah lingkaran bersama-sama dengan namanya.
Ispelling <===== Nama Interface
c. Collaboration, mendefinisikan suatu intraksi dari sekumpulan objek dalam melakukan pekerjaan secara bersama. Collaboration diagram digunakan sebagai alat keputusan tentang perilaku sistem. Secara grafis collaboration diterjemahkan dengan sebuah ellips ( lingkaran ) yang memiliki garis terputus-putus.
<=== nama collaboration
d. Use Case, adalah suatu gambaran dari himpunan serangkaian kemampuan aksi yang dapat diberikan oleh sistem atau disebut juga dengan gambaran fungsional sistem jika dipandang oleh user yang berada diluar sistem ( actor ). Use case digunakan sebagai kerangka behavioral dari things di dalam model. Sebuah use case direalisasikan oleh collaboration. Secara grafis use case diterjemahkan dengan sebuah ellips
<=== nama use case
5. Active Class, adalah sebuah kelas yang objek-objeknya digunakan oleh satu atau lebih proses atau thread. Lebih lanjut active class juga dapat berupa inisial dari aktivitas kontrol. Selain itu active class dapat berupa class except, yaitu kelas yang object-objectnya merepsentasikan elemen-elemen yang lain. Secara grafis active class diterjemahkan seperti diagram class, tetapi memiliki garis kasar yang memiliki garis terputus-putus
<=== nama kelas
<=== atribut
<=== operasi / methode
6. Componen, adalah sebuah physical dan bagian yang dapat diganti dari sebuah sistem sesuai dengan realisasi dari himpunan interface. Sebuah komponen secara khusus merepsentasikan physical packging dari elemen logic yang lain, seperti sebuah kelas, interface dan collaboration. Secara grafis component diterjemahkan dengan persegi panjang dengan label ( tabs ) dan di dalamnya terdapat nama dari component tersebut.
<== nama componen
7. Node, adalah sebuah elemen fisik yang ada pada saat run time dan merepsentasikan sebuah resource computational, secara umum memiliki paling sedikit beberapa memori dan seringkali menunjukkan kemampuan pemprosesan. Sebuah himpunan componen dapat terletak pada satu node dan dapat juga berpindah dari satu node ke node yang lain. Secara grafis node diterjemahkan dengan kubus di dalamnya terdapat nama dari node tersebut.
nama node
b. Behavioral Things, adalah bagian-bagian dinamik dari model-model UML. Behavioral things dapat dibagi menjadi :
1. Interaction, adalah sebuah behavioral yang terdiri dari kumpulan pesan ( message ) yang saling bertukaran antar himpunan objek dalam suatu konteks khusus untuk menyelesaikan suatu maksud tertentu. Sebuah interfection melibatkan sejumlah elemen, yakni pesan, urutan aksi dan link.. Intraction terdiri dari dua macam, yaitu sequence diagram dan collaboration diagram, gambar yang digunanakan sebagai notasi untuk sebuah pesan.
display
2. State Machine, merupakan suatu behaviour yang menetapkan urut-urutan keadaaan suatu objek atau suatu interaction dari awal sampai akhir selama lifetime respon terhadap berbagai kejadian dan tanggapannya untuk kejadian-kejadian itu. State machine melibatkan berbagai elemen yang lain, termasuk didalam state machine, transisi ( aliran server nama node orderform.java nama component display 6 dari state ke state ), events ( things yang men-trigger suatu transmisi ) dan aktivitas ( tanggapan pada suatu transisi ). State machine secara grafis digambarkan sbk :
c. Grouping Things, merupakan bagian organisasi dari UML, dalam hal ini ada satu macam grouping things, yakni yang diberi nama package. Sebuah package merupakan suatu mekanisme kegunaan umum untuk mengelompokkan elemen-elemen ke dalam suatu group. Structure things, behavioral things dan grouping things yang lain secara lengkap dapat diletakkan ke dalam suatu package. Package tidak sama dengan component. Package semata-mata yang ada waktu pemgangunan perangkat lunak. Secara grafis package diterjemahkan dengan tabbed folder yang selalu diberi nama.
Sebagai illustrasi dapat digambarkan sebagai berikut :
nama packege
d. Annotation Things, adalah bagian-bagian yang bersifat menjelaskan ( explanatory ) didalam UML. Bagian ini menggambarkan, menjelaskan dan berisi komentar-komentar tentang berbagai elemen di dalam model. Notasi yang digunakan untuk menggambarkan lampiran ulasan atau kumpulan ulasan adalah persegi yang di ikuti oleh lipatan ke dalam salah satu sudutnya
3. Arsitektur, adalah kumpulan keputusan signifikasi tentang :
a. Organisasi dari sebuah sistem perangkat lunak.
b. Pemilihan elemen-elemen struktur dan interfece-nya oleh sistem adalah nyaman
c. Behavioral sistem ditetapkan didalam kolaborasi antar elemen-elemen.
d. Komposisi dari struktur dan behavioral elemen-elemen ke dala subsistem yang lebih luas.
e. Corak arsitektur mengarahkan organisasi:elemen-elemen statik dan dinamik, interfacenya, kolaborasinya dan komposisinya.
Arsitektur perangkat lunak tidak hanya menyangkut tentang struktur dan behavioral, tetapi juga berkaitan dengan pemakaian, fungsionalitas, kemampuan, kekenalan ( resilience ), reuse, komprehensif, ekonomis dan teknologi mendesak serta trade-offs dan perhatian estetis.
Use case view dari sebuah sistem meliputi use case-use case yang menggambarkan behavioral dari sistem yang tampak oleh pemakai ( end user ), analisis, dan tester. View ini bukanlah benar-benar menetapkan organisasi dari sebuah sistem perangkat lunak. Tetapi use case ada untuk menetapkan bentuk arsitektur sistem. Dengan UML aspek statik dari view ini diberikan oleh diagram interaction, diagram statecart dan diagram activity.
Diagram view, dari sebuah sistem meliputi kelas, interface, dan collaboration. View ini utamanya mendukung requirement fungsional dari sistem, yang berarti menyediakan layanan sistem untuk pemakainya ( end user ). Dengan UML aspek statik dari view ini diberikan oleh diagram kelas dan diagram object, sedangkan aspek dinamik diberikan oleh diagram interaction, diagram statecart dan diagram activity.
Process view dari sebuah sistem meliputi thread dan proses-proses yang berbentuk konkruen dan mekanisme sinkronisasi sistem. View ini utamanya ditujukan untuk performansi, scability, dan throughput dari sistem. Dengan UML aspek statik dan dinamik dari view ini diberikan oleh diagram yang sama dengan aspek statik dan dinamik pada view desain, tetapi difokuskan pada active class yang mempresentasikan thread-thread dan proses-proses.
Implementasi view dari sebuah sistem meliputi komponen dan file yang digunakan untuk memasang dan peluncuran sistem secara fisik. View ini utamanya ditujukan untuk manajemen konfigurasi dari peluncuran sistem, membuat komponen-komponen bebas dan file dapat dipasang dalam bermacam-macam jalan untuk membuat sistem berjalan. Dengan UML aspek statik dari view ini diberikan oleh diagram component. Sedangkan untuk aspek dinamik diberikan diagram interaction, diagram statecart dan diagram activity.
Development view, dari sebuah sistem meliputi node dan topologi perangkat keras sistem pada saat eksekusi sistem. View ini utamanya ditujukan untuk distribusi, pengiriman, pemasangan dari berbagai pembuatan sistem fisik. Dengan UML aspek statik dari view ini diberikan oleh diagram-diagram deplayment, sedangkan aspek dinamik diberikan oleh diagram interaction, diagram statecart dan diagram activity.
4. Siklus Hidup Pembangunan Perangkat Lunak
Pada dasarnya UML tidak terlalu terkait dengan siklus hidup pembangunan perangkat lunak. Walaupun demikian untuk memperoleh sisi positif yang lebih banyak dari UML, maka hal-hal berikut ini perlu dipertimbangkan, yakni:
a. Use case driven
b. Arsithecture centric
c. Interative and incremental
Use case driven, menunjukkan use case-use case yang digunakan sebagai artifact utama untuk memperlihatkan behavioral dari sistem, validasi dan verifikasi arsitektur sistem, pengujian sistem dan komunikasi antar stakeholder pada proyek perangkat lunak
Arsithecture centric menunjukkan sebuah arsitektur sistem, digunakan sebagai artifact utama untuk konseptual, mengkonstruksi, mengelola dan menyusunan sistem secara terus menerus dalam rangka pengembangan sistem yang berkelanjutan.
Interative process, adalah pengaturan secara terus menerus secara terintegrasi dari arsitektur sistem untuk release-release berikutnya. Dalam hal ini masing-masing release baru akan menambah perbaikan terhadap release sebelumnya. Disamping itu, juga harus diperhatikan bersama-sama dengan interative process dan incremental process adalah pengendalian resiko. Hal ini dimasudkan agar dalam pengembangan release baru perlu difokuskan pada pemecahan dan pereduksian resiko yang signifikan dalam rangka mencapai keberhasilan proyek pengembangan perangkat lunak. Use case driven, arsithecture centric dan interative/incremental process dapat berhubungan satu sama lain dalam setiap fase pembangunan perangkat lunak, yakni fase iception, fase elaboration, fase contruction dan fase transition.
Daftar Pustaka
Al Bahra Bin Ladjamudin, Rekayasa Perangkat Lunak, Graha Ilmu, Yogyakarta, 2006
Bahrami,Ali. Object Systems Developmen. McGraw-Hill Companies, Inc.Singapore.1999
Gomma Hasan, Designing Concurent, Distributed, and Real Time Aplication With UML. Addison Wesley. Unit States
of America,2000
