Pengenalan UML

Pengenalan UML

Pengenalan UML

UML (Unified Modeling Language) merupakan pengganti dari metode analisis berorientasi objek dan design berorientasi objek(OOA&D) yang dimunculkan sekitar akhir tahun 80-an dan awal tahun 90-an.

UML merupakan gabungan dari metode Booch, Rumbaugh(OMT) dan Jacobson. Tetapi UML ini akan mencakup lebih luas daripada OOA&D. Pada pertengahan pengembangan UML dilakukan standarisasi proses dengan OMG(Object Management Group) dengan harapan UML  akan menjadi bahasa standar pemodelan pada masa yang akan datang.

UML disebut sebagai bahasa pemodelan bukan metode. Kebanyakan metode terdiri paling sedikit prinsip, bahasa pemodelan dan proses. Bahasa pemodelan (sebagian besar grafik) merupakan notasi dari metode yang digunakan untuk mendesain secara cepat.

Bahasa pemodelan merupakan bagian terpenting dari metode. Ini merupakan bagian kunci tertentu untuk komunikasi. Jika anda ingin berdiskusi tentang desain dengan seseorang, maka anda hanya membutuhkan bahasa pemodelan bukan proses yang digunakan untuk mendapatkan desain.

UML merupakan bahasa standar untuk penulisan blueprint software yang digunakan untuk visualisasi, spesifikasi, pembentukan dan pendokumentasian alat-alat dari sistem software.

Sejarah Singkat UML

Bahasa pemodelan berorientasi objek muncul antara sekitar pertengahan tahun 1970-an dan akhir tahun 1980-an yang dikenal dengan bahasa pemograman berorientasi objek dan aplikasi komplek yang berkembang, yang dimulai untuk eksperimen dengan pendekatan alternatif untuk analisis dan desain. Sejumlah metode berorientasi objek bertambah dari kurang lebih 10 sampai lebih dari 50 selama periode 1989 dan 1994. Beberapa user pengguna metode ini menemukan permasalahan dalam bahasa pemodelan ini yang dibutuhkan mereka untuk kelengkapan, sehingga timbul yang dinamakan perang metode. Belajar dari pengalaman, metode generasi baru mulai muncul dengan metode yang terkemuka, seperti Booch, Jacobson’s OOSE(Object Oriented Software Engineering) dan Rumbaugh’s OMT(Object Modelling Technique). Metode penting lainya seperti Fusion, Shler_mellor dan Coad-Yourdan. Setiap metode ini merupakan metode yang lengkap, meskipun setiap metode diakui memiliki kelebihan dan kekurangan. Dalam waktu yang singkat metode Booch paling terasa dalam mendesain dan membangun tahapan project,OOSE memberikan dukungan yang baik untuk use cases seperti cara untuk menjalankan permintaan, analisis dan desain level tinggi, dan OMT-2 sangat berguna untuk analisis dan sistem informasi data intensif.

Banyak ide-ide yang kritis dimulai dari pertengahan tahun 1990-an ketika Grady Booch (Relational Software Corporation), Ivar Jacobson(Objectory) dan James Rumbaugh(General Electric) mulai mengadopsi ide-ide dari metode lainnya yang dikumpulkan yang akhirnya diakui sebagai Metode Object Oriented yang mudah diseluruh dunia. Kemudian mereka termotivasi untuk membangun UML(Unified Modelling Language).

Ada tiga tujuan dibangunnya penyatuan metode tersebut yaitu :

1.      Untuk memodelkan sistem, dari konsep ke bentuk yang cocok dengan menggunakan teknik berorientasi objek.

2.      Untuk menunjukkan skala persoalan yang komplek.

3.      Untuk membangun bahasa pemodelan yang berguna bagi manusia dan mesin.

Perencanaan bahasa untuk digunakan pada analisa dan desain yang berorientasi objek tidak seperti mendesain bahasa pemograman. Pertama, kita harus mengetahui masalah seperti dapatkah bahasa mencakup spesikasi permintaan? Dapatkah bahasa penting untuk pemograman visual? Kedua, kita harus menemukan keseimbangan antara komplek dan kesederhanaan. Bahasa yang terlalu sederhana akan terbatas untuk problem yang luas yang akan dipecahkan. Sedangkan untuk bahasa yang komplek akan berakibat terlalu pengembang pada sistem yang sederhana.

UML dimulai secara resmi pada oktober 1994, ketika Rumbaugh bergabung dengan Booch pada Relational Software Coorporation. Proyek ini mengfokuskan pada penyatuan metode Booch dan OMT. Versi 0.8 merupakan Metode Penyatuan yang direlease pada bulan oktober 1995. Dalam waktu yang sama Jacobson bergabung dengan Ralational dan cakupan dari UML semakin luas sampai diluar perusahaan OOSE. Dokumentasi UML versi 0.9 akhirnya direlease 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 software melihat kalau UML merupakan strategi dari bisnisnya. Kemudian dibangunlah UML Consortium dengan beberapa organisasi yang akan menyumbangkan sumber dayanya untuk bekerja mengembangkan dan melengkapi UML.

Disini beberapa patner 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 Colaboration 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 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 3.1 dengan disertai dengan user guide dan memberikan technical cleanup.

Gambaran dari UML

¤   UML sebagai Bahasa Pemodelan

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.

¤   UML sebagai bahasa untuk Menggambarkan Sistem(Visualizing)

UML tidak hanya merupakan rangkaian simbol grafikal, cukup dengan tiap simbol pada notasi UML merupakan penetapan simantik 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 dipresentasikan ke bahasa pemogranan.

UML merupakan suatu model ekaplisit yang menggambarkan komunikasi informasi pada sistem. Sehingga kita tidak kehilangan informasi code implementasi yang hilang dikarenakan developer memotong coding dari implementasi.

¤   UML sebagai bahasa untuk Menspesifikasikan Sistem (Specifying)

Maksudnya membangun model yang sesuai, tidak ambigu dan lengkap. Pada faktanya UML menunjukan semua spesifikasi keputusan analisis, desin dan implementasi yang penting yang harus dibuat pada saat pengembangan dan penyebaran dari sistem software intensif.

¤   UML sebagai bahasa untuk Membangun Sistem(Constructing)

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 objek.      

¤   UML sebagai bahasa untuk Pendokumentasian Sistem (Documenting)

Maksudnya UML menunjukan dokumentasi dari arsitektur sistem dan detail dari semuanya.UML hanya memberikan bahsa untuk memperlihatkan permintaan dan untuk tes. UML menyediakan bahasa untuk memodelkan aktifitas dari perencanaan project dan menejemen pelepasan (release management).

Area Penggunaan UML

UML 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

Namun UML tidak terbatas untuk pemodelan software. Pada faktanya UML banyak untuk memodelkan sistem nonsoftware seperti:

-          Aliran kerja pada sistem perundangan.

-          Struktur dan Kelakuakn dari sistem Kepedulian Kesehatan Pasien

-          Desain Hardware dll.

Tujuan Penggunaan UML

1.       memodelkan suatu sistem (bukan hanya perangkat lunak) yang menggunakan konsep berorientasi objek.

2.       menciptakan suatu bahasa pemodelan yang dapat digunakan baik oleh manusia maupun mesin.

Diagram dalam UML

Diagram berbentuk grafik yang menunjukan simbol elemen model yang disusun utuk mengilustrasikan bagain atau aspek tertentu dari sistem. Sebuah model sistem biasanya mempunyai beberapa diagram untuk setiap jenisnya.

Adapun jenis – jenis diagram antara lain :

1. Use Case Diagram

Menggambarkan sejumlah eksternal actor dan hubungannya ke Use Case yang diberikan oleh sistem. Use Case digambarkan hanya yang dilihat dari luar oleh actor (keadaan lingkungan sistem yang dilihat user) dan bagaimana fungsi yang ada didalam sistem.

2. Class Diagram

Menggambarkan struktur statis class dalam sistem. Class merepresentsikan sesuatu yang ditangani oleh sistem. Class dapat dihubungkan dengan lainnya melalui sejumlah cara : assasiated (terhubung satu dengan yang lain), dependent (satu class tergantung / menggunakan class yang lainnya), specialiized (satu class merupakan spesialisasi dari class lainnya), atau packaged (grup bersama sebagai suatu unit).

3. Sequence Diagram

Menggambarkan kolaborasi dinamis antar sejumlah object. Kegunaanya untuk menunjukkan rangkaian pesan yang dikirim antara objek juga  interaksi antara object.

4. Collaboration Diagram

Menggambarkan kolaborasi dinamis seperti sequence diagram. Dalam menjukkan pertukaran pesan, collaboration diagram menggambarkan object dan hubungannya (mengacu ke konteks). Jika penekanannya pada waktu atau urutan gunakkan sequence diagram, tetapi jika penekanannya pada konteks gunakan collaboration diagram.

5. State Chart Diagram

Menggambarkan semua state (kondisi) yang dimiliki oleh suatu object dari suatu class dan kejadian yang menyebabkan state berubah secara dinamis

6. Activity Diagram

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

7. Component Diagram

Menggambarkan struktur fisik kode dari komponen. Komponen dapat berupa source code, komponen biner, atau executable component. Sebuah komponen berisi tenatang logic class atau class yang diimplementasikan sehingga membuat pemetaan dari logical view ke component view.

8. Deployment Diagram

Menggambarkan arsitektur fisik dari perangkat keras dan perangkat lunak sistem, menunjukkan hubungan komputer dengan perangkat (nodes) satu sama lain dan jenis hubungannya. Di dalam nodes, executable, component dan object yang dialokasikan untuk memperlihatkan unit perangkat lunak yang dieksekusi oleh node tertentu dan ketergantungan komponen.

UML dan RUP

Unified Modelling Language (UML) adalah bahasa pemodelan yang menggunakan konsep orientasi objek. UML dibuat oleh Grady Booch, James Rumbaugh, dan Ivar Jacobson di bawah bendera Rational Software Corp [ERI98]. 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.

Rational Unified Process (RUP) adalah metodologi pengembangan perangkat lunak yang dibangun dengan visi memudahkan pengontrolan dan meningkatkan kualitas perangkat lunak yang dibangun. RUP memanfaatkan sepenuhnya notasi yang ada dalam UML [WEI01].

Hubungan antara UML dan RUP adalah UML menyediakan notasi-notasi pemodelan, sedangkan RUP menggunakan notasi-notasi yang disediakan dalam UML tersebut.

Tahap-Tahap Pengembangan dalam RUP [WEI01]

Pada RUP, tahap pengembangan dideskripsikan dalam dua dimensi, yaitu

·         Sumbu horisontal, merepresentasikan waktu dan aspek dinamis dari proses, dan diekspresikan dalam bentuk siklus, tahap, iterasi, dan tonggak (milestone)

·         Sumbu vertikal, merepresentasikan aspek statis dari proses, bagaimana proses dideskripsikan dalam bentuk aktivitas, artifak, pekerja, dan alur kerja.

Tujuan dan sasaran tiap tahap pengembangan :

a.       Tahap Permulaan (Inception)

·         Mendapatkan kesepahaman dari stakeholder terhadap sasaran siklus pengembangan

·         Menetapkan ruang lingkup dan batas dari proyek pengembangan, memperkirakan total biaya dan jadwal untuk keseluruhan proyek, serta memperkirakan semua resiko potensial proyek pengembangan

b.      Tahap Perluasan (Elaboration)

·         Membuat garis dasar arsitektur sistem untuk menyediakan landasan yang stabil  bagi upaya perancangan dan implementasi dalam tahap konstruksi.

c.       Tahap Konstruksi (Construction)

·         Melakukan klarifikasi kebutuhan yang masih tersisa dan melengkapi pembangunan sistem berdasarkan arsitektur yang ditetapkan.

·         Secara berulang dan bertambah (iterative and incremental) membangun produk yang lengkap, yang siap dialihkan kepada komunitas penggunanya.

d.      Tahap Peralihan (Transition)

·         Memastikan bahwa perangkat lunak telah tersedia bagi para pengguna akhir (end user), termasuk pengujian untuk persiapan. Pada tahap ini, umpan-balik pengguna harus berfokus pada isu-isu fine-tuning, konfigurasi,  dan ketergunaan

·         Rekayasa spesifik-penyebaran, seperti cut over, pengemasan komersial, pelatihan personil lapangan, serta berbagai aktivitas perbaikan, seperti pembetulan bug, peningkatan kinerja dan ketergunaan, dan sebagainya

Secara umum effort dan jadwal pengerjaan untuk setiap tahap pengembangan adalah sebagai berikut :

	Inception	Elaboration	Construction	Transition
Effort	5 %	20 %	65 %	10 %
Schedule	10 %	30 %	50 %	10 %

TABEL 1 Effort dan schedule setiap tahap pengembangan

Alur Utama Pengembangan dalam RUP [WEI01]

Alur utama pengembangan petangkat lunak dalam RUP serta model yang digunakan dalam setiap alur utama tersebut adalah sebagai berikut :

Gambar 2  Alur Utama Pengembangan dalam RUP

Secara umum effort pengerjaan untuk setiap alur utama pengembangan adalah sebagai berikut :

	Business Engineering	Requirement Analysis	Analysis and Design	Implementation
Effort	8,75 %	19,75 %	27,75 %	43,75 %

TABEL 2 Effort pengerjaan untuk setiap alur utama pengembangan

Beberapa Alat Bantu dalam RUP  [WEI01]

Beberapa alat bantu yang digunakan dalam RUP adalah :

1. Tahap Business Engineering/Business Modelling

·         Business Use Case Model

Model ini digunakan untuk menggambarkan atau mendeskripsikan bagaimana proses bisnis dari sistem yang akan dikembangkan (existing system) dalam terminologi use case. Diagram yang digunakan dalam pemodelan ini adalah Business Use Case Diagram.

·         Business Object Model

Model ini digunakan untuk menggambarkan bagaimana realisasi dari setiap business use case pada business use case diagram. Dari setiap business use case dibreakdown sehingga dapat diketahui entitas apa saja yang ada dalam business use case tersebut. Entitas-entitas ini akan menjadi kandidat kelas dalam Class Diagram.

2. Tahap Requirement Analysis

·         Use Case Model

Model ini digunakan untuk menggambarkan kebutuhan-kebutuhan atau fitur-fitur yang harus dimiliki oleh sistem yang baru. Diagram yang digunakan dalam pemodelan ini adalah Use Case Diagram.

3. Tahap Analysis and Design 

·         Design Model

Model ini digunakan untuk menggambarkan bagaimana analisis dan desain sistem yang baru. Dari setiap use case pada use case diagram dibreakdown untuk mengetahui bagaimana realisasi dari use case tersebut. Realisasi use  case dapat dimodelkan dengan beberapa diagram, yaitu Class Diagram (own by Use Case Realization) serta Interaction Diagram. Sedangkan desain sistem digambarkan dengan Class Diagram.

4. Tahap Implementation

·         Implementation Model

Model ini digunakan untuk menggambarkan bagaimana implementasi terhadap desain dari sistem yang baru. Salah satu diagram yang digunakan dalam pemodelan ini adalah Database Diagram.

Bagaimana modul ini digunakan?

Modul ini tersusun atas teori mengenai UML, petunjuk pemakaian Rational Rose untuk membuat diagram-diagram pada UML, contoh kasus UML ( Sistem Registrasi STT Telkom ), jurnal praktikum dan proyek UML.

1.      Praktikan diharapkan mempersiapkan diri mempelajari dan memahami teori atau konsep UML.

2.      Langkah selanjutnya adalah praktikan memilih salah satu metodologi pengembangan perangkat lunak yang menggunakan UML sebagai visual modelling-nya. Dalam modul ini diperkenalkan Rational Unified Process sebagai salah satu metodologi pengembangan perangkat lunak yang menggunakan UML sebagai visual modelling-nya. Praktikan diperkenankan menggunakan metodologi lainnya.

3.      Pada setiap modul praktikan akan dibimbing untuk memakai Rational Rose sebagai salah satu tools pemodelan UML.

4.      Pada setiap modul, praktikan akan mengerjakan jurnal praktikum dimana pertanyaan yang diajukan berasal dari study kasus yang digunakan sebagai contoh dalam setiap modul dan  kasus khusus yang telah ditentukan.

5.      Pada akhir praktikum, semua praktikan akan mempresentasikan proyek/tugas besar praktikum berupa hasil rekayasa pengembangan perangkat lunak menggunakan UML sampai dengan tahap design perangkat lunak.

Check Model (Tools Menu)

Perhatian :  Pada beberapa kasus tidak dilakukan check model, hal ini didasari atas adanya perbedaan  antara konsep UML dengan Check Model ?  Kesimpulannya, tidak harus dilakukan check model.

Check Model dibuat untuk memeriksa apakah model yang dibuat pada banyak unit konsisten satu dengan yang lainnya. Hal ini khususnya berguna ketika parallel development berjalan pada banyak unit, karena sangat mungkin unit-unit yang berbeda tidak sinkron satu dengan yang lain.

Check Model akan memeriksa referensi sebagai berikut :

·         Ke supplier ( lihat anonim supplier pada package relationship di modul 2 ) dari sembarang relationship, has, uses, instantiation, metaclass, logical package import, module visibility, connection, dsb.

·         Dari sebuah view pada sebuah diagram ke sebuah item di model

·         Dari sebuah logical package ke component package yang berasosiasi dengannya dan dari sebuah modul ke class yang berasosiasi dengannya.

·         Dari sebuah object ke class yang berasosiasi dengannya.

·         Dari sebuah message pada sebuah object diagram ke sebuah operasi dalam sebuah class.

·         Dari dynamic semantic dalam sebuah operasi ke scenario diagram