REKAYASA ULANG STANDAR UML 1.3 KE UML 2.0 I Made Murwantara, S.Si., M.Kom* Abstract UML Standard improve from UML 1.3 to UML 2.0. As a tool, UML has capability fo specification and verification. Proven model is shaped into formal model. Thos verified model can be proven theoretically using formal method. Semi-form approach is mostly used because of it's practically easy and non-fully mathematics The software development activity always increases based on user needs.
1. PENDAHULUAN Unified Modeling Language (UML) merupakan bahasa yang dipergunakan untuk mendesain "blueprint" dari suatu piranti lunak. UML sebagai bahasa memiliki kemampuan dalam mendesain secara sistematis dan konsisten pada pengembangan sistem secara lengkap {full) maupun secara terpisah {partial). Model adalah suatu gambaran abstrak mengenai suatu permasalahan yang komplek atau terstruktur oleh sesuatu yang tidak penting, sehingga permasalahan dapat lebih mudah dimengerti. Melihat pernyataan tersebut maka UML juga menyediakan notasi yang sangat "robust", dimana model tersebut dibentuk dari hasil analisis menjadi desain. UML dengan kemampuannya ditargetkan untuk sistem besar yang rumit. Permasalahan yang sering timbul dalam hal kompleksitas (tahap kerumitan) ini adalah penggunaan semantic yang kurang tepat, sedangkan pemodelan pada suatu sistem besar yang rumit membutuhkan penggunaan teknik pemodelan yang menyediakan mekanisme manajemen terhadap kompleksitas. Kemampuan tersebut diperlukan untuk melakukan deteksi permasalahan lebih cepat pada tahapan desain dan requirement. Hal yang paling signifikan adalah prinsip formal dan "rigor" yang memfasilitasi kemampuan deteksi permasalahan pada requirement dan desain masih memiliki peluang untuk dikembangkan lebih lanjut. UML sebagai tool memiliki kemampuan melakukan spesifikasi dan verifikasi, tidak hanya bidang piranti lunak tetapi mencakup hampir segala hal termasuk sistem prosedur dan bisnis proses. Kehandalan ini menghasilkan suatu model yang dapat dibuktikan secara teoritis {verified).
' Dosen Tetap Fakultas llmu Komputer UPH Rekayasa Ulang Standar UML 1.3 ke UML 2.0 (I Made Murwantara)
21
Manufacturing
E-Commerce
g
Space *
Transportation
• Telecom
Healthcare
More... Gambar 1. Model Driven Architecture (MDA) [1]
Penggunaan UML dalam penyelesaian permasalahan pada pemodelan mencakup banyak bidang, seperti terlihat pada gambar 1. Pada bidang-bidang yang memiliki kompleksitas yang cukup tinggi, UML memiliki kemampuan untuk ekstraksi permasalahan dilanjutkan dengan melakukan pemilahan berdasarkan domain permasalahan dan diakhiri dengan suatu verifikasi dari model yang dihasilkan. Kemampuan untuk melakukan pemilahan memudahkan pengguna dalam memfokuskan model dan metode penyelesaian yang diinginkan, dengan kata lain target yang ingin dicapai dapat di-drive agar dapat memenuhi tujuan yang diinginkan. Pada bidang industri, penerapan UML saat ini mencapai taraf matang, dimana peningkatan produktivitas dalam proses industri telah mempergunakan UML sebagai alat bantu dalam melakukan pemodelan dan analisa terhadap tujuan yang ingin dicapai. Manajemen proyek sebagai contoh, merupakan model yang kompleks, menggunakan kemampuan diagram dalam UML, pengguna dapat mengekstrak informasi milestone, penjadwalan, penggunaan bahan dan pembiayaan sebagai obyek yang dapat dipilah. Kompleksitas analisa sebagai kemampuan yang diharapkan dari suatu alat bantu, diterapkan mempergunakan notasi dan model matematis. OCL {object constraint language) diterapkan sebagai specifier dalam melakukan spesifikasi terhadap obyek yang telah didapat dan Formal Method dengan kemampuan pemodelan matematikanya menghasilkan pembuktian dan pengujian terhadap model dengan lebih pasti. Formalisasi, verifikasi dalam suatu bentuk pemodelan akan menjadi lengkap ketika pembuktian terhadap kebenaran suatu desain terhadap teori dapat dibuktikan secara empiris.
2. PENDEKATAN Perkembangan desain dan metodologi pada pengembangan piranti lunak telah mencapai tingkat kompleksitas sangat tinggi. Kebutuhan untuk menyelesaikan kompleksitas yang ada perlu dilakukan pendekatan yang tepat dan akurat. Penelitian yang dilaksanakan mencakup pekerjaan teori dan praktis, dimana dasar pemikiran ini dituangkan dalam bentuk metodologi seperti terlihat pada gambar 3.
22 Jurnal llmiah llmu Komputer, Vol. 2 No. 3 September 2004: 21-28
Captured UMLTool Coding
UML
Corrected
Semi-Formal Approach
Formalized FM
Formal Model
Gambar 2. Interaksi Kelengkapan UML
Identifikasi permasalahan melalui requirement gathering process merupakan hal awal yang dilakukan untuk mendapatkan gambaran lengkap dari permasalahan yang sebenarnya. Hasil identifikasi ini kemudian dimodelkan kedalam bentuk desain UML, tahapan ini disebut semi formal seperti diperlihatkan pada gambar 3. Model yang telah dibentuk dibuktikan dalam bentuk Formal Model, dimana bentuk analisa yang telah dilakukan diuji kebenarannya terhadap requirement dan dibuktikan secara matematis. Output dari Formal Model merupakan perbaikan dari desain yang telah dikerjakan pada semi-formal approach yang kemudian diubah kembali menjadi UML. Model UML setelah dilakukan proofing dalam model formal dan verifikasi, kemudian dapat di-generate menjadi suatu barisan kode program yang diharapkan telah siap digunakan Fitur dari metodologi yang hendak dibangun ini memiliki beberapa kemampuan antara lain: 1 Memberikan tampilan pada bentuk UML diagram. 2. Memiliki kemampuan untuk melakukan desain UML diagram 3. Melakukan reasoning terhadap suatu UML diagram. 4. Melakukan proofing terhadap suatu UML diagram. 5. Menghasilkan kode program berdasarkan model. 6. Mampu beradaptasi (interchangeable) dengan tool yang ada, seperti Rational Rose.
c
> Requirement Definition
^
w
Formal Specification
hi
w
Formal Transformation
fe w
Integration & Testing
Gambar 3. Proses pemodelan Formal Method
Rekayasa Ulang Standar UML 1.3 ke UML 2.0 (I Made Murwantara)
23
3. GAMBARAN LENGKAP Piranti lunak {software) adalah program atau kumpulan instruksi atau data yang memberitahu sebuah komputer untuk mengerjakan sesuatu. Piranti lunak ini dapat dibagi menjadi dua kategori besar: piranti lunak sistem {system software) dan piranti lunak aplikasi {application software). Sistem operasi {operating system) termasuk dalam piranti lunak sistem, sementara program yang mengerjakan tugas-tugas khusus, seperti spreadsheets, word processor adalah piranti lunak aplikasi. Penelitian ini terfokus pada suatu metoda pendekatan pembuatan sebuah piranti lunak aplikasi. Tata cara pembuatan piranti lunak lebih sering dikenal sebagai proses pemodelan pembuatan piranti lunak {software process model). Ada banyak model yang biasa digunakan pada proses pemodelan pembuatan piranti lunak, seperti model air terjun {water fall process model), (pengembangan secara evolusi {evolutionary development), dan pengembangan dengan sistem formal {formal system development). Masih ada beberapa model lagi dalam proses pemodelan pembuatan piranti lunak. Penelitan ini lebih cenderung menggunakan pendekatan pengembangan dengan sistem (semi-)formal. Secara umum aktifitas pengembangan piranti lunak adalah spesifikasi, desain, validasi dan evolusi. Aktifitas spesifikasi adalah aktiftas mengumpulkan dan menuliskan seluruh kebutuhan dari piranti lunak, sehingga piranti lunak yang dibuat mempunyai tingkat kejelasan yang cukup untuk dibuat desainnya, seperti yang diinginkan oleh penggunanya. Aktiftas desain adalah proses pembuatan piranti lunak. Hasil dari aktifitas desain ini akan diuji kebenarannya pada aktifitas validasi. Aktifitas evolusi diperlukan karena piranti lunak tidak dapat dibuat kemudian selesai atau langsung dapat diterima oleh pengguna. Proses penyempurnaan piranti lunak ini dilakukan pada aktifitas evolusi. Aktifitas pengembangan piranti lunak akan terus berkembang sesuai dengan kebutuhan pengguna. Semua aktiftas ini termasuk dalam penelitian ini. Pengembangan piranti lunak dengan sistem formal mensyaratkan keterlibatan metoda formal {formal method). Metoda formal memungkinkan pembuatan piranti lunak dengan tingkat kehandalan yang lebih baik, karena spesifikasi dari piranti lunak dapat diuji kebenarannya secara matematis. Sehingga dapat menurunkan kebutuhan pengujian pada aktifitas validasi. Pada prakteknya metoda formal, lebih susah diserap dan diterapkan oleh pembuat program {programmer), karena membutuhkan proses belajar {learning curve) yang lebih panjang sehingga metoda pendekatan dengan semi-formal lebih banyak dipilih. Pendekatan semi-formal ini biasanya mengunakan diagram. Pada saat ini state-of-the-art dari diagram yang digunakan adalah Unified Modeling Language (UML). Spesifikasi dari UML diatur oleh Object Management Group (OMG). OMG adalah badan nirlaba yang mendefinisikan secara lengkap obyek (object) dan semua yang berhubungan dengan obyek. UML adalah de-facto diagram yang digunakan oleh pengembang piranti lunak dunia.
4. PERBANDINGAN STANDAR UML 1.3 KE UML 2.0 Bentuk komparasi yang dilakukan adalah membandingkan peer-to-peer terhadap modifikasi yang terjadi pada standar UML 1.3. UML 2.0 telah mendefinisikan obyek sebagai suatu instance mempergunakan Instance Specification Metaclass, sementara Instance Specification adalah suatu elemen dari model yang berupa bagian dari package dan bisa berhubungan dengan pengklasifikasi lainnya. 24 Jurnal llmiah llmu Komputer, Vol 2 No 3 September 2004: 21-28
UML 1.3 mendefinisikan bahwa slot merupakan aturan yang harus dilaksanakan oleh metaclass sebagai representasi hubungan antara suatu attribute dan instance. UML 2.0 menyebut metaclass dari AttributeLink yang berubah menjadi slot, dimana slot adalah suatu tempat untuk memenuhi suatu nilai. Setiap slot terhubung ke suatu fitur terstruktur pada pengklasifikasi.
Sn»etei» Ottfram
Diagram
Ac tlwily Diagram
Ofc|*il Diagram
c « m p • i lie Structure 0 l a yr a ITI
Package Diagram
U t o Cata Diagram
Stats M a c n i a c Diagram
intataetiit'i P. 'J grain
Sequent* D4ag»m
Oi-*rvt«« Li-jyrim
ii p . n. 'n.v. ,\ U • it
liming Diagram
Gambar 4, Taxonomy UML 2.0 [2]
Diagram (
—
Sialic Structure
1 Use Case (li;i£ijm
4
1 Sequence diagram
1 t'tilLihnmlion
1 Slalccharl diagram
1 Activity diagram
A
1 Class Diagram
Implementation diagram
| Object Diagram
t~ Component Diagram
A Deployment Diagram
Gambar 5 Taxonomi UML 1.3 [3]
Rekayasa Ulang Standar UML 1.3 ke UML 2.0 (I Made Murwantara)
25
Tabel 1. Perbandingan Class Diagram
UML 1.3 Notasi Beberapa fitur kunci, attribute, operation dan asosiasi yang berhubungan dengan suatu class sebenarnya didefinisikan untuk pengklasifikasi and inherit oleh suatu class Attribute class untuk mendefinisikan data yang dimiliki oleh suatu class Attribute Suatu static atau class di desain oleh garis bawah Tidak ada notasi untuk exception
Status Tetap Menjadi
UML 2.0 Reorganisasi dengan MOF Notasi Ditujukan langsung ke Class
Menjadi
Suatu class dapat terdiri interface, asosiasi dan signal
Menjadi
Tidak dikatakan secara jelas bahwa suatu attribute static diberi garis bawah exception
Menjadi
dari
4.1. PERBANDINGAN MODEL INTERAKSI Interaksi model obyek pada UML 2.0, terdapat pembaharuan pada beberapa diagram yang berelasi, dimana pada UML 1.3 tidak didefinisikan secara jelas. Level pada diagram menunjukkan beberapa alasan untuk dilakukan evaluasi terhadap interaksi saat melakukan desain suatu sistem.
Tabel 2. Perbandingan Behavioral Diagram antara UML 1 3 and UML 2 0
UML 1.3 Sequence Diagram Collaboration Diagram Statechart Diagram
Tetap Menjadi Menjadi Baru Baru
UML 2.0 Sequence Diagram Communication Diagram State Machine Diagram Interaction Overview Diagram Timing Diagram
Sequence Diagram tidak berubah antara UML 1.3 dan UML 2.0. Collaboration Diagram diubah menjadi Communication Diagram. Communication Diagram adalah suatu pandangan struktural pada message diantara obyek. Statechart Diagram diubah menjadi Sfate Machine Diagram dimana diagram ini sama seperti Collaboration Diagram dengan penekanan pada kombinasi message mempergunakan layout visual terhadap hubungan antara obyek dan ini adalah bagian yang hilang dari Sequence Diagram.
26 Jurnal llmiah llmu Komputer, Vol. 2 No. 3 September 2004: 21-28
Tabel 3. Notasi Activity Diagram dalam UML 1 3 dan UML 2.0
UML1.3 Action state
Keterangan UML 2.0 Action dengan kondisi awal, kondisi UML 2.0 akhir dan parameter mengembangkan deskripsi suatu aktifitas. Subactivity state Activity, dengan kondisi awal dan UML 2.0 kondisi akhir. Mengembangkan deskripsi suatu aktifitas Decision dan merge DecisionNode dan MergeNode Call state Aktifitas lain Swimlanes Partisi Nama baru, fungsi dasar sama ObjectFlowState ObjectNode dan ObjectFlow Pengiriman dan penerimaan Ditangani oleh ObjectNodes Signal Deferred events Fork and join ForkNode dan JoinNode UML2.0dua icon digabung menjadi satu. Finalstate ActivityFinalNode and FlowFinalNode Transition ActivityEdge InterruptibleActivityRegion Baru di UML 2.0. Datastore Baru di UML 2.0 Dua diagram baru pada pemodelan obyek yang berinteraksi adalah: Interaction Overview Diagram yang merupakan pandangan level atas pada suatu himpunan interaksi yang dikombinasikan ke dalam urutan logika, termasuk pengendalian aliran saat terjadi interaksi. Timing Diagram adalah suatu diagram yang dipilih sebagai pendesain untuk mengerjakan spesifikasi terhadap constraint waktu pada saat pengiriman dan penerimaan message pada suatu interaksi. Pada Statechart Diagram, perubahan utama pada UML 2.0 terhadap UML 1.3 adalah upaya untuk memisahkan semantik pada Activity Diagram dari semantik Sfafe Machine. 4.2. PERBANDINGAN PEMODELAN ARSITEKTUR DARI APLIKASI UML 2.0 melakukan perubahan pada vocabulary untuk pemodelan bersifat runtime. UML 1.3 menyatakan bahwa suatu komponen dipergunakan untuk menyelesaikan spesifikasi dari suatu requirement menjadi elemen fisik software dan elemen fisik pada suatu implementasi. UML 2.0 mempergunakan struktur paralel, isi dari struktur komponen untuk mendefinisikan requirement pada setiap elemen fisik piranti lunak. Artifact di definisikan sebagai bagian dari implementasi suatu komponen. Setiap bagian struktur paralel untuk komponen dan artifact mempergunakan pola yang sama dengan pendahulunya.
Rekayasa Ulang Standar UML 1.3 ke UML 2.0 (I Made Murwantara)
27
Spesifikasi Deployment tidak terdapat pada UML 1.3, Spesifikasi Deployment secara grafis ditampilkan sebagai suatu pengklasifikasi berbentuk segiempat yang terdapat pada suatu component artifact. 5. KESIMPULAN Standar UML 2.0 memiliki banyak perbedaan dengan UML 1.3 terutama pada interaction diagram dan behavior dalam model. Perubahan utama pada UML 2.0 terhadap UML 1.3 adalah upaya untuk memisahkan semantik pada Activity Diagram dari semantik State Machine. Pengembangan piranti lunak dengan sistem formal mensyaratkan keterlibatan metoda formal (formal method). Metoda formal memungkinkan pembuatan piranti lunak dengan tingkat kehandalan yang lebih baik, karena spesifikasi dari piranti lunak dapat diuji kebenarannya secara matematis. Sehingga dapat menurunkan kebutuhan pengujian pada aktifitas validasi. Perbandingan secara lengkap didokumentasikan dalam Technical Report [5] 6. STATUS PENELITIAN Tulisan ini dapat dipaparkan pada jurnal berkat penelitian mandiri yang dikerjakan penulis bersama dengan Dr. (Eng) Pujianto Yugopuspito. Penelitian yang dilakukan telah mencapai tahapan konsep yang siap diterjemahkan ke dalam bentuk model dan design tool. Bahasa pemrograman Python akan digunakan dalam tahapan berikutnya pada penelitian ini. Judul penelitian adalah "Kelengkapan UML (UML Completeness)" yang berupaya menghasilkan produk berupa tool untuk desain model UML dengan mengikuti standar UML 2.0 mempergunakan kaidah Open Source. Daftar Pustaka [1] OMG (Object Management Group), Model Driven Architecture, http://www.omg.org, 2003. [2] OMG (Object Management Group), UML 2.0 Superstructure Specification, April 30, 2004. [3] OMG (Object Management Group), UML 1.3 Superstructure Specification, June 1999. [4] SELIC, Bran, IBM Software Group, Rational Software, Bubbles of Steel: A preview of UML 2.0 and MDA, 2001 [5] I Made Murwantara dan Pujianto Yugopuspito, Perbandingan Standar UML 1.3 dan UML 2.0, Technical Report FIK-UPH No. 1/2004, Universitas Pelita Harapan.
28 Jurnal llmiah llmu Komputer, Vol. 2 No. 3 September 2004: 21-28
