Diagram Dalam UML

Diagaram dalam UML merupakan penjelasan secara grafis mengenai elemen-elemen dalam sistem. Dalam UML kita mengenal berbagai macam diagram. Tipe diagram yang berbeda-beda membantu kita untuk melihat sisitem dari perpektif yang berbeda-beda.

Use Case Diagram

Use Case Diagram menjelaskan manfaat sistem jika dilihat menurut pandangan orang yang berada diluar sistem (actor). Diagram ini menunjukkan fungsionalitas suatu sistem atau kelas dan bagaiman sistem berinteraksi dengan dunia luar.

Use case Diagram dapat digunakan selama proses analisis untuk mangngkap requirements sistem dan untuk memahami bagaimana sistem seharusnya bekerja. Selama tahap desain, use case diagram menetapkan perilakau (behavior) sistem saat diimplementasikan. Dalam sebuah model mengkin terdapat satu atau lebih use case diagram.

Class Diagram

Class Diagram memebantu kita dalam visualisasi struktur kelas-kelas dari suatu sistem dan merupakan tipe diagram yang paling banyak dipakai. Class Diagram memperlihatkan hubungan antar kelas dan penjelasan detail tiap-tiap kelas didalam model desain (dalam logical view) dari suatu sistem.

Selama proses analisis, class diagram memperlihatkan atauran-aturan dan tanggung jawab entitas yang menentukan perilaku sistem. Selama tahap desain, class diagram berperan dalam menangkap struktur dari semua kelas yang membentuk arsitektur sistem yang dibuat.

Class diagram merupakan dasar untuk component diagram dan deployment diagram. Dalam sebuah model mungkin terdapat beberapa diagram kelas dengan spesifikasi tersendiri.

Sequence Diagram

Sequence Diagram menjelaskan interaksi objek yang disusun dalam suatu urutan waktu. Diagram ini secara khusus berasosiasi dengan use case. Sequence diagram memperlihatkan tahap demi tahap apa yang seharusnya terjadi untuk menghasilkan sesuatu didalam use case. Tipe diagram ini sebaiknya digunakan diawal tahap desain atau analisis karena kesedeharhanaannya dan mudah untuk dimengerti.

Colaboration Diagram

Colaboration diagram terlihat pada interaksi dan hubungan tertstruktur antarobjek. Tipe diagram ini menkankan pada hubungan (Irelationship) antarobjek, sedangkan sequence diagram menekankan pada urutan kejadian. Dalam satu collaboration diagram terdapat beberapa object, link dan message. Collaboration diagram digunakan sebagai alat untuk menggambarkan interaksi yang menggungkapkan keputusan mengenai perilaku sistem.

Activity Diagram

Activity diagram memodelkan alur kerja (workflow) sebuah proses bisnis dan urutan aktivitas dalam suatu proses. Diagram ini sangat mirip dengan sebuah flowchart karena kita dapat memodelkan sebuah alur kerja dari satu aktifitas ke aktifitas lainnya atau dari satu aktifitas kedalam keadaan sesaat (state). Sering kali bermanfaat bila kitamembuat sebuah activity diagram terlebih dahulu dalam memodelkan sebuah proses untuk membantu kita memahami proses secara keseluruhan. Activity diagram juga sangat berguna ketika kita ingin menggambarkan perilaku pararel atau menjelaskan bagaimana perilaku dalam berbagai use case berinteraksi.

Statechart Diagram

Kita dapat menggunakan statechart diagram untuk memodelkan perilaku dinamis satu kelas atau objek, kejadian yang menyebabakan sebuah transisi dari satu state atau aktivitas kepada yang lainnya, dan aksi yang menyebabkan perubahan satu state atau aktivitas. Statechart diagram khususnya digunakan untuk memodelkan tarap-tarap diskrit dari sebuah siklus hidup objek, sedangkan activity diagram paling cocok digunakan untuk memodelkan urutan aktivity dalam suatu proses.

Component Diagram

Component diagram menggambarkan alokasi semua kelas dan objek kedalam komponen-komponen dalam desain fisik sistem software. Diagram ini memperlihatkan pengaturan dan kebergantungan antara komponen-komponen software, seperti source code, binary code dan komponen tereksekusi (executable components). Kita dapat membuat satu atau lebih componen diagram untuk menggambarkan komponen dan paket atau menerangkan isi dari tiap-tiap paket komponen.

Deployment Diagram

Setiap model hanya memiliki satu diagram deployment. Diagram ini memperlihatkan pemetaan software kepada hardware.

Package, Streotype dan Ralationship

Package

Package (paket) adalah mekanisme pengelompokan yang digunakan untuk menandakan pengelompokan elemen-elemen model. Sebuah package digunakan untuk memudahkan mengorganisasi elemen-elemen model.

Streotype

Rational Rose memiliki stereotype yang khusus untuk tiap elemen-elemen model yang berbeda. Sebuah stereotype menarangkan subklasifikasi dari sebuah elemen model.

Beberapa stereotype telah didefinisikan oleh Rational Rose tetapi kita dapat mendefinisikan stereotype baru yang digunakan dalam model yang kita buat. Kita dapat mendefinisikan stereotype untuk sebuah elemen model melalui ruang Stereotype yang terdapat dalam jendela Specification elemen tersebut.

Relationship

Relationship (hubungan) adalah koneksi antar model elemen. Assosiation Relationship (hubungan asosiasi) memodelkan koneksi antarobjek dari kelas yang berbeda. Kita dapat menggunakan associaation untuk menunjukkan bahwa suatu objek berkomunikasi dengan objek lainnya. Dalam model assosiation relationship digambarkan sebagai garis lurus dengan mata panah pada satu ujungnya.

Penamaan dalam association relationship sering digunakan untuk menentukan tipe atau tujuan hebungan tersebut.

Aggregation relationship (hubungan agregasi) adalah bentuk khusus asosiasi yang memodelkan hubungan antara dua kelas, yakni suatu kelas disusun oleh kelas lainnya.

Pada gambar diatas, kelas B disebut kelas aggregate. Gambar diatas memperlihatkan B secara fisik dibentuk oleh A atau secara logis B mengandung A.

Bussiness Modeling

UML dapat digunakan untuk memodelkan berbagai jenis sistem, seperti sistem software, sistem hardware, dan organisasi. Namun secara umum, Uml sekarang dapat digunakan untuk dua kepentingan, yaitu untuk membuat model dalam proses software development dan memodelkan bisnis (Bussiness Modeling).

Model bisinis nerupakan sebuah peta sederhana mengenai organisasi. Dalam rekayasa software, model bisnis sangat membantu kita untuk memehami masalah yang harus diselesaikan oleh software yang kita buat.

Beberapa Konsep Dasar dalam Bussiness Modeling

Dalam dunia bisnis dan industri, terdapat banyak sistem manual dan otomatis yang muncul secara regular. Setiap sistem tersebut memiliki satu atau banyak workflow. Bussiness Modeling menggambarkan semua workflow yang terjadi dalam suatu organisasi.

Sacara formal, kita mendefinisikan bussines modeling sebagai segala teknik pemodelan yang digunakan untuk menggambarkan model sebuah bisnis. Bussiness modeling dapat digunakan untuk meninjau, meningkatkan dan membuat sebuah bisnis.

Catatan :

Workflow adalah urutan aktifitas yang menghasilkan suatu nilai objek yang dapat dilihat (observable) bagi suatu pihak atau entitas tertentu.

Tujuan Bussiness Modeling

Dengan dilakukan Bussiness Modeling diharapkan kita :

-          Memahami struktur dan dinamika organisasi

-          Memahami masalah-masalah dalam mencapaui target organisasi dan menemukan potensi untuk kemajuan organisasi

-          Yakin bahwa para customer, end user, dan developer mempunyai sebuah pemahaman yang benar mengenai organisasi.

-          Dapat menurunkan/mendapatkan requirement software aplikasi yang akan kita buat yang diperlukan untuk mendukung pencapaian target organisasi.

Menentukan Requirement

Requirement adalah kondisi atau kemampuan yang harus dipenuhi oleh software aplikasi yang kan dibuat. Requirement untuk software aplikasi dibagi kedalam dua kelompok, yaitu functional requirement dan non-functional requirement.

Functional requirement menentukan tindakan yang harus dapat dimainkan sebuah software aplikasi. Requirement ini sering dimodelkan dalam bentuk use-case-use-case dalam use-case model. Eunctional requirement juga menentukan masukan dan keluaran dari sebuah software aplikasi. Functional requirement mencakup fitur, kemampuan (capabilities) dan faktor security  software aplikasi.

Non-Functional requirement menggambarkan atribut dari software aplikasi dan lingkungannya. Requirement ini biasanya masuk di dalam use-case dan tercakup dalam sifat (property) use-case tersebut.

Non-Functional requirement dibagi menjadi :

-          Usability requirement, mencakup faktor manusia (user), segi estetika, konsistensi dalam user interface, help, wizard, materi training dan sebagainya.

-          Reliability requirement, mencakup frekuensi kesalahan, segi akurasi, rata-rata selang waktu antarkesalahan dan sebagainya.

-          Performance requirement, menentukan kondisi dalam functional requirement. Sebagai contoh, untuk suatu aksi tertentu maka harus ditentukan parameter untuk menetukan kecepatan, efisiensi, akurasi, waktu respon dan sebagainya.

-          Supportability requirement, mencakup kemampuan melakukan testing, perluasan cakupan, adaptasi, perwatan, perbaikan dan sebagainya.

Use-Case Model

Use-Case Model adalah model yang menggambarkan requirements software dalam bentuk use-case-use-case. Use-Case Model dibuat untuk mengidentifikasikan fungsionalitas yang penting secara arsitektural dari software yang akan dibuat dan lingkungannya.

Dalam suatu proyek rekayasa software, ketika mendapat persetujuan dari customer mengenai user case model yang ditawarkan, ini berarti bahwa aplikasi yang akan kita bagun sesuai dengan yang dikehendaki customer, Kita dapat mediskusikan aplikasi yang sedang dibangun dengan customer selama proses pembuatan. Dalam hal ini use-case model berperan sebagai “perjanjian” bersama tentang aplikasi yang akan dibuat.

Use-case model juga digunakan sebagai sebuah masukan yang penting selama dalam proses analisis, desain dan testing. Use-case model terdiri dari satu atau beberapa use-case diagram.

Use-case diagram

Use-case diagram mnggambarkan secara grafis perilaku software aplikasi menurut prespektif user dari software aplikasi tersebut. Sebuah use-case diagram  mengandung  actor, Use-case, interaksi antara actor dan use-case

Actor

Actor menggambarkan pengguna software aplikasi (user). Actor membantu memberikan suatu gambaran jelas tentang apa yang harus dikerjakan software aplikasi.

Use-case

Use-case menggambarkan perilaku software aplikasi, termasuk didalamnya interaksi antara actor dengan software aplikasi tersebut.

Secara umum use-case adalah :

-          Pola perilaku software aplikasi

-          Urutan transaksi yang berhubungan yang dilakukan oleh satu actor dengan software aplikasi.

-          Sistem atau benda yang memberikan sesuatu yang bernilai kepada actor.

Use-case dibuat berdasarkan keperluan actor. Use-case harus merupakan apa yang dikerjakan software aplikasi. Bukan bagaimana software aplikasi mengerjakannya. Setiap use-case harus diberi nama yang menyatakan apa hal yang dicapai dari hasil interaksinya dengan actor. Use-case boleh terdiri dari beberapa kata dan tidak boleh ada dua use-caseyang memiliki nama yang sama. Kita dapat memberikan deskripsi tentang suatu use-case delam jendela dokumentasi untuk memperjelas maksud use-case tersebut.

Secara grafis use-case dinotasikan menjadi use-case konkret dan use-case abstrak. Use-case konkret adalah use-case yang dibuat langsung karena keperluan aktor. Actor dapat melihat dan berinsiatif terhadapnya. Use-case abstrak adalah use-case yang tidak pernah berdiri sendiri. Use-case abstrak senantiasa termasuk didalam (include), diperluas dari (extend), atau memperumum (generalize) use-case lainnya.

Model Analisis

Kelas dalam Model Analisis

Elemen model yang terdapat dalam model analisis disebut kelas analisis (analysis class). Kelas analisis adalah kelas ber-stereotype “boundary”, “contoh” atau “entity” yang menggambarkan sebuah konsep awal mengenai “benda” dalam sistem aplikasi yang memiliki tanggung jawab dan perilaku.

Boundary

Kelas Boundary adalah kelas yang memodelkan interaksi antara satu atau lebih actor dengan sistem. Kelas boundary memodelkan bagian dari sistem yang bergantung pada pihak lain disekitarnya dan merupakan pembatas dengan dunia luar. Kelas Boundary dapat berupa :

-          User interface yang merupakan sarana komunikasi antara sistem dengan user, misalnya jendela (window) dalam GUI

-          System Interface yang merupakan sarana komunikasi antara sistem dengansistem informasi lainnya misalnya communication protocol.

-          Device interface yang merupakan sarana komunikasi antara sistem dengan device (alat), seperti printer, sensor dan sebagainya.

Control

Kelas control digunakan untuk memodelkan perilaku mengatur, khusus untuk satu atau beberapa use-case saja. Control Object (instance dari kelas control) biasanya mengontorol objek lain. Perilaku sebuah control object erat hubungannya dengan realisasi suatu use-case tertentu. Control object menjalankan realisasi dari use-case tersebut. Tidak semua use case memerlukan control object.

Entity

Kelas entity (entitas) memodelkan informasi yang harus disimpan oleh sistem. Kelas entity memperlihatkan struktur data dari sebuah sistem. Oleh karena itu, kelas ini membantu kita untuk memahami apa yang kira-kira akan ditawarkan oleh sistem kepada user.

Entity object (instance dari kelas entity) biasanya bersifat pasif dan tetap (tidak berubah-ubah). Tanggung jawab utama objek ini adalah untuk menyimpan dan mengatur informasi dalam sistem.

Statechart Diagram

Statechart diagram memperlihatkan berbagai state (keadaan sesaat) yang dilalui sebuah objek, dan kejadian-kejadian yang menyebabkan sebuah transisi dari satu state ke state lainnya, dan aksi yang mengakibatkan suatu perubahan state.

Elemen-elemen statechart diagram biasa muncul yaitu :

-          State (keadaan sesaat)

-          Start (keadaan awal) dan End (keadaan akhir)

-          Transition (transisi)

-          Action Entry, Do dan Exit

Staet menjelaskan keadaan tertentu suatu objek selama masa hidupnya selama memenuhi syarat atau kondisi tertentu atau menunggu suatu event (kejadian). Start dan end menggambarkan permulaan dan akhir dari suatu proses. Transition adalah hubungan antar dua state yang menunjukan kapan sebuah objek dapat bergerak pada state lainnya, manakala bertemu dengan suatu kondisi  tetrtentu. Dalam statecahrt diagram, sebuah transisi kepada elemen itusendiri adalh serupa dengan sebuah transisi state, tetapi tidak memindahkan “pusat perhatian” atau sebuah transisi denganstate asala dan state target yang sama. Dalam statechart diagram tiap-tiap state dapat mengandung beberapa aksi didalamnya (internal action). Aksi menggambarkan sebuah tugas yang terdapat dalam sebuah state, yaitu On Entry, On Exit, Do, On Event.

Aksi On Entry merupakan tugas yang harus dilakukan suatu object ketika objek tersebut memasuki state tersebut. Aksi On Exit merupakan tugas yang harus dibuat suatu objek ketika objek tersebut keluar dari state tersebut. Aksi Do merupakan tugas yang harus dibuat suatu objek ketika berada dalam state dan harus terus-menerus dikerjakan sampai keluar dari state tersebut. Aksi On Event merupakan tugas untuk memicu suatu aksi hanya jika suatu event tertentu diterima. Aksi On Event tidak memicu aksi lain dan juga transisi kepada dirinya (self transition). Self transition membuat aksi entry dan exit.

Implementasi

Model desain (Design Model) merupkan abstraksi dari penerapan (implementasi) suatu sisitem software. Model design digunakan untuk menyusun desain software agar kita mendapatkan bukti bahwa desain software tersebut dibuat sebaik mungkin. Model desain tersusun atas semua kelas-kelas desain, paket desain, beserta kolaborasi dan relationship antarelemen.

Model Desain

Model desain mnggambarkan software dalam bentuk objek-objek untuk menjelaskan realisasi dari use case – use case. Model desain juga menggambarkan software dalam bentuk objek-objek, tetapi dalam tingkat abstraksi yang lebih mendekati source code.

Kelas Desain

Sebuah kelas merupakan suatu gambaran mengenai himpunan objek yang memiliki tanggung jawab, relationship, operasi, atribut dan sematik yang sama. Kelas desain menggambarkan sebuah abstraksi satu atau berbagai kelas dalam implementasi. Nama umtuk tiap-tipa kelas desain bergantung pada bahasa program yang berpadanan dengan kelas tersebut dalam implementasi. Suatu kelas desain dapat memiliki beberapa operasi dan atribut.

Operasi

Satu-satunya jalan agar objek lain dapt mengakses, atau mempengaruhi atribut atatu relationship daro sebuah objek adalah melalui operasi (operation) yang dimilikinya. Operasi dari sebuah objek didefinisikan oleh kelas dari objek tersebut. Suatu perilaku tertentu dari sebuh objek dapat dimainkan melaluioperasi, yang mungkin mempengaruhi atribut dan relationship yang dimiliki objek tersebut dan menyebabkan operasi yang lain dimainkan juga.

Parameter

Sebuah operasi dapat memiliki satu atau beberapa parameter (argument). Tiap-tiap parametermemiliki sebuah nama dari type. Kita dapat menggunkan sintaks bahsa yag akan digunakan dalam implementasi untuk menentukan operasi dan parameter-parameternya sedemikian, sehingga semuanya telah dibuat dalam “bahasa implementasi”  ketika kita memulia coding.

Opretion Visibility

Sebuah operasi dapat memiliki visibility :

-          Public : operasi yang dapat digunakan oleh elemen model yang lainnya. Digunakan hanya ketika sebuah operasi diperlukan oleh kelas lainnya.

-          Protected : operasi yang “tampak” hanya oleh kelas itu sendiri, subkelasnya atu “teman” kelas tersebut (bergantung pada bahasa yang dipakainya).  Visibility ini merupakan default dari setiap operasi yag kita buat. Visibility ini melindungi operasi dari penggunaan oleh kelas-kelas luar yang meningkatkan kelonggaran perilaku encapsulation.

-          Private : operasi hanya dapat dijangkau oleh kelas itu sendiri dan oleh “teman” kelas tersebut. Visibility ini digunakan ketika ingin mencegah subkelas dari mewarisi operasi tersebut.

-          Implementation : operasi hanya dapat dijangkau dalam kelas itu sendiri. Digunakan jika hanya kelas itu sendiri yang dapat menggunakan operasi tersebut.

Atribut

Sebuah atribut adalah sifat yang diberi nama dari sebuah obyek. Atribut diberi nama dengan kata benda yang menggambarkan peran atribut dalam hubungannya dengan objek tersebut. Sebuah atribut dapat memiliki sebuah nilai awal ketika objek tersebut dibuat.

Atribut Visibility

Atribut dapat memiliki Visibility sebagai berikut :

-          Public : atribut dapat “dilihat” ( visible) dari dalam dan dari luar paket yang mengandung kelas yang bersangkutan

-          Protected : atribut hanya visible oleh kelas itu sendiri, subkelasnya atau “teman” kelas tersebut (bergantung kepada bahasa).

-          Private : atribut hanya visible oleh kelas itu sendiri dan “teman” kelas tersebut.

-          Implementation : atribut hanya visible oleh kelas itu sendiri.

Interface

Interface adalah sebuah elemen model yang mendefinisikan sebuah himpunan dari berbagai perulaku (operasi) yang ditawarkan oleh sebuah kelas, subsistem, atau komponen (ketiga elemen ini sering disebut sebagai classifier).

Sebuah interface dalam Rational Rose (UML) adalah sebuah kelas dengan stereotype “interface”.

Class Utility

Sebuah class utility menggambarkan sebuah himpunan servis yang disediakan oleh sebuah modul dalam sistem software yang sedang dibangun. Sebuah class utility dipetakan kedalam sebuah module.

Property yang dimilikinya dipetakan sebagai variable module, public ataupun private, dan method yang dimilikinya dipetakan sebagai method baik public ataupun private dari modul tersebut.

untuk selanjutnya baca juga uml sistem informasi penyewaan kaset