makalah 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]

ß Dimensi kandungan aktivitas à	ß Dimensi waktu pengembangan à
	Gambar 1  Tahap-Tahap Pengembangan dalam RUP

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

BAGIAN-BAGIAN DARI UML

            1. Use Case Diagram

Use case adalah abstraksi dari interaksi antara system dan actor. Use case bekerja dengan cara mendeskripsikan tipe interaksi antara user sebuah system dengan sistemnya sendiri melalui sebuah cerita bagaimana sebuah system dipakai.

Diagram Use Case berguna dalam tiga hal :

• Menjelaskan fasilitas yang ada (requirement)
• Komunikasi dengan klien
• Membuat test dari kasus-kasus secara umum\

Kelebihan:

·                     Interaksi antara pengguna dan system lain dengan system yang akan di buat cukup tergambar dengan baik.

·                     Penggambaran dengan sederhana membuat identifikasi kebutuhan dengan use case dapat dengan lebih mudah untuk dipahami.

·                     Pendekatan identifikasi kebutuhan dapat berdasarkan top down (keinginan dari manajemen level atas) maupun bottom up (keinginan pengguna akhir).

·                     Dapat meng-include (memasukkan) fungsionalitas use case lain sebagai bagian dari proses dalam dirinya.

1. Use Case Diagram

Use case adalah abstraksi dari interaksi antara system dan actor. Use case bekerja dengan cara mendeskripsikan tipe interaksi antara user sebuah system dengan sistemnya sendiri melalui sebuah cerita bagaimana sebuah system dipakai.

Diagram Use Case berguna dalam tiga hal :

• Menjelaskan fasilitas yang ada (requirement)
• Komunikasi dengan klien
• Membuat test dari kasus-kasus secara umum\

Kelebihan:

·                     Interaksi antara pengguna dan system lain dengan system yang akan di buat cukup tergambar dengan baik.

·                     Penggambaran dengan sederhana membuat identifikasi kebutuhan dengan use case dapat dengan lebih mudah untuk dipahami.

·                     Pendekatan identifikasi kebutuhan dapat berdasarkan top down (keinginan dari manajemen level atas) maupun bottom up (keinginan pengguna akhir).

·                     Dapat meng-include (memasukkan) fungsionalitas use case lain sebagai bagian dari proses dalam dirinya.

1. Use Case Diagram

Use case adalah abstraksi dari interaksi antara system dan actor. Use case bekerja dengan cara mendeskripsikan tipe interaksi antara user sebuah system dengan sistemnya sendiri melalui sebuah cerita bagaimana sebuah system dipakai.

Diagram Use Case berguna dalam tiga hal :

• Menjelaskan fasilitas yang ada (requirement)
• Komunikasi dengan klien
• Membuat test dari kasus-kasus secara umum\

Kelebihan:

·                     Interaksi antara pengguna dan system lain dengan system yang akan di buat cukup tergambar dengan baik.

·                     Penggambaran dengan sederhana membuat identifikasi kebutuhan dengan use case dapat dengan lebih mudah untuk dipahami.

·                     Pendekatan identifikasi kebutuhan dapat berdasarkan top down (keinginan dari manajemen level atas) maupun bottom up (keinginan pengguna akhir).

·                     Dapat meng-include (memasukkan) fungsionalitas use case lain sebagai bagian dari proses dalam dirinya.

Kelemahan:

• Kekurangan mengenai data masih kurang teridentifikasi dengan baik.

2. Activity Diagram

Activity diagram menyediakan analis dengan kemampuan untuk memodelkan proses dalam suatu sistem informasi. Activity diagram dapat digunakan untuk alur kerja model, use case individual, atau logika keputusan yang terkandung dalam metode individual3. Activity diagram juga menyediakan pendekatan untuk proses pemodelan paralel. Activity diagram lebih lanjut .

Kelemahan:

• Kekurangan mengenai data masih kurang teridentifikasi dengan baik.

2. Activity Diagram

Activity diagram menyediakan analis dengan kemampuan untuk memodelkan proses dalam suatu sistem informasi. Activity diagram dapat digunakan untuk alur kerja model, use case individual, atau logika keputusan yang terkandung dalam metode individual3. Activity diagram juga menyediakan pendekatan untuk proses pemodelan paralel. Activity diagram lebih lanjut .

Kelemahan:

• Kekurangan mengenai data masih kurang teridentifikasi dengan baik.

2. Activity Diagram

Activity diagram menyediakan analis dengan kemampuan untuk memodelkan proses dalam suatu sistem informasi. Activity diagram dapat digunakan untuk alur kerja model, use case individual, atau logika keputusan yang terkandung dalam metode individual3. Activity diagram juga menyediakan pendekatan untuk proses pemodelan paralel. Activity diagram lebih lanjut .

Pada dasarnya, diagram aktifitas canggih dan merupakan diagram aliran data yang terbaru. Secara teknis, diagram aktivitas menggabungkan ide-ide proses pemodelan dengan teknik yang berbeda termasuk model acara, statecharts, dan Petri Nets.

Notasi yang digunakan dalam activity diagram adalah sebagai barikut:

1. Activity: Notasi yang menggambarkan pelaksanaan dari beberapa proses dalam aliran pekerjaan.
2. Transition: Notasi yang digunakan untuk memperlihatkan jalan aliran control dari activity ke activity.
3. Decision: Notasi yang menandakan kontro cabang aliran berdasarkan decision point.
4. Synchronization bars: Aliran kerja notasi ini menandakan bahwa beberapa aktivitas dapat diselesaikan secara bersamaan (pararel).

3. Package Diagram

Package diagram utamanya digunakan untuk mengelompokkan elemen diagram UML yang berlainan secara bersama-sama ke dalam tingkat pembangunan yang lebih tinggi yaitu berupa sebuah paket. Diagram paket pada dasarnya adalah diagram kelas yang hanya menampilkan paket, disamping kelas, dan hubungan ketergantungan, disamping hubungan khas yang ditampilkan pada diagram kelas.

Pada dasarnya, diagram aktifitas canggih dan merupakan diagram aliran data yang terbaru. Secara teknis, diagram aktivitas menggabungkan ide-ide proses pemodelan dengan teknik yang berbeda termasuk model acara, statecharts, dan Petri Nets.

Notasi yang digunakan dalam activity diagram adalah sebagai barikut:

1. Activity: Notasi yang menggambarkan pelaksanaan dari beberapa proses dalam aliran pekerjaan.
2. Transition: Notasi yang digunakan untuk memperlihatkan jalan aliran control dari activity ke activity.
3. Decision: Notasi yang menandakan kontro cabang aliran berdasarkan decision point.
4. Synchronization bars: Aliran kerja notasi ini menandakan bahwa beberapa aktivitas dapat diselesaikan secara bersamaan (pararel).

3. Package Diagram

Package diagram utamanya digunakan untuk mengelompokkan elemen diagram UML yang berlainan secara bersama-sama ke dalam tingkat pembangunan yang lebih tinggi yaitu berupa sebuah paket. Diagram paket pada dasarnya adalah diagram kelas yang hanya menampilkan paket, disamping kelas, dan hubungan ketergantungan, disamping hubungan khas yang ditampilkan pada diagram kelas.

Sebagai contoh, jika kita memiliki sistem pendaftaran untuk kantor dokter, mungkin masuk akal untuk kelompok kelas pasien dengan kelas sejarah medis pasien bersama-sama untuk membentuk paket kelas pasien. Selain itu, dapat berguna untuk membuat paket perawatan yang mengandung gejala penyakit, penyakit, dan obat-obatan khas yang diresepkan untuk mereka. 

4. State Diagram

State diagram menggambarkan urutan keadaan yang dilalui objek dalam suatu kelas, karena suatu kejadian menyababkan suatu perpindahan aktivitas/state. State dari objek adalah penggolongan dari satu atau lebih nilai attribute pada kelas.

Bersifat dinamis. Diagram state ini memperlihatkan statestate pada system, memuat state, transisi, event, serta aktifitas. Diagram ini terutama penting untuk memperlihatkan sifat dinamis dari antarmuka, kelas, kolaborasi dan terutama penting pada pemodelan system – system yang reaktif.

contoh :“Peminjaman Barang””

• Seorang peminjam yang akan meminjam akan mengisi form peminjaman.
• Sistem akan megecek keadaan barang. Barang tersebut tersedia apa tidak, atau barang tersebut dapat di pinjam atau tidak
• Setelah barang tersedia, sistem akan memvalidasi persetujuan peminjaman barang dan menyerahkan barang kepada peminjam. 
• Sistem juga akan mencari informasi tentang barang yang akan dipinjam, maka akan dilakukan permintaan akan informasi barang.
• Jika informasi yang diterima masih kurang, akan dilakukan permintaan ulang sampai seluruh informasi yang dibutuhkan didapatkan.
• Saat informasi sudah cukup, informasi tersebut akan diserahkan kepada peminjam barang tersebut.

5. Sequence Diagram

Sequence diagram menjelaskan interaksi objek yang disusun berdasarkan urutan waktu. Secara mudahnya sequence diagram adalah gambaran tahap demi tahap yang seharusnya dilakukan untuk menghasilkan sesuatu sesuai dengan use case diagram.

Bersifat dinamis. Diagram urutan adalah interaksi yang menekankan pada pengiriman pesan (message) dalam suatu waktu tertentu.

Sequence diagram menekankan penyusunan berbasis waktu untuk kegiatan yang dilakukan dengan satu set dari objek yang berkolaborasi. Sequence diagram sangat berguna dalam membantu analis, memahami spesifikasi real-time dan menggunakan kasus yang rumit (lihat di bawah). Diagram ini dapat diguanakan untuk mendeskripsikan baik secara fisik dan logis interaksi antara objek.

Sebagai contoh, jika kita memiliki sistem pendaftaran untuk kantor dokter, mungkin masuk akal untuk kelompok kelas pasien dengan kelas sejarah medis pasien bersama-sama untuk membentuk paket kelas pasien. Selain itu, dapat berguna untuk membuat paket perawatan yang mengandung gejala penyakit, penyakit, dan obat-obatan khas yang diresepkan untuk mereka. 

4. State Diagram

State diagram menggambarkan urutan keadaan yang dilalui objek dalam suatu kelas, karena suatu kejadian menyababkan suatu perpindahan aktivitas/state. State dari objek adalah penggolongan dari satu atau lebih nilai attribute pada kelas.

Bersifat dinamis. Diagram state ini memperlihatkan statestate pada system, memuat state, transisi, event, serta aktifitas. Diagram ini terutama penting untuk memperlihatkan sifat dinamis dari antarmuka, kelas, kolaborasi dan terutama penting pada pemodelan system – system yang reaktif.

contoh :“Peminjaman Barang””

• Seorang peminjam yang akan meminjam akan mengisi form peminjaman.
• Sistem akan megecek keadaan barang. Barang tersebut tersedia apa tidak, atau barang tersebut dapat di pinjam atau tidak
• Setelah barang tersedia, sistem akan memvalidasi persetujuan peminjaman barang dan menyerahkan barang kepada peminjam. 
• Sistem juga akan mencari informasi tentang barang yang akan dipinjam, maka akan dilakukan permintaan akan informasi barang.
• Jika informasi yang diterima masih kurang, akan dilakukan permintaan ulang sampai seluruh informasi yang dibutuhkan didapatkan.
• Saat informasi sudah cukup, informasi tersebut akan diserahkan kepada peminjam barang tersebut.

5. Sequence Diagram

Sequence diagram menjelaskan interaksi objek yang disusun berdasarkan urutan waktu. Secara mudahnya sequence diagram adalah gambaran tahap demi tahap yang seharusnya dilakukan untuk menghasilkan sesuatu sesuai dengan use case diagram.

Bersifat dinamis. Diagram urutan adalah interaksi yang menekankan pada pengiriman pesan (message) dalam suatu waktu tertentu.

Sequence diagram menekankan penyusunan berbasis waktu untuk kegiatan yang dilakukan dengan satu set dari objek yang berkolaborasi. Sequence diagram sangat berguna dalam membantu analis, memahami spesifikasi real-time dan menggunakan kasus yang rumit (lihat di bawah). Diagram ini dapat diguanakan untuk mendeskripsikan baik secara fisik dan logis interaksi antara objek.

Sebagai contoh, jika kita memiliki sistem pendaftaran untuk kantor dokter, mungkin masuk akal untuk kelompok kelas pasien dengan kelas sejarah medis pasien bersama-sama untuk membentuk paket kelas pasien. Selain itu, dapat berguna untuk membuat paket perawatan yang mengandung gejala penyakit, penyakit, dan obat-obatan khas yang diresepkan untuk mereka. 

4. State Diagram

State diagram menggambarkan urutan keadaan yang dilalui objek dalam suatu kelas, karena suatu kejadian menyababkan suatu perpindahan aktivitas/state. State dari objek adalah penggolongan dari satu atau lebih nilai attribute pada kelas.

Bersifat dinamis. Diagram state ini memperlihatkan statestate pada system, memuat state, transisi, event, serta aktifitas. Diagram ini terutama penting untuk memperlihatkan sifat dinamis dari antarmuka, kelas, kolaborasi dan terutama penting pada pemodelan system – system yang reaktif.

contoh :“Peminjaman Barang””

• Seorang peminjam yang akan meminjam akan mengisi form peminjaman.
• Sistem akan megecek keadaan barang. Barang tersebut tersedia apa tidak, atau barang tersebut dapat di pinjam atau tidak
• Setelah barang tersedia, sistem akan memvalidasi persetujuan peminjaman barang dan menyerahkan barang kepada peminjam. 
• Sistem juga akan mencari informasi tentang barang yang akan dipinjam, maka akan dilakukan permintaan akan informasi barang.
• Jika informasi yang diterima masih kurang, akan dilakukan permintaan ulang sampai seluruh informasi yang dibutuhkan didapatkan.
• Saat informasi sudah cukup, informasi tersebut akan diserahkan kepada peminjam barang tersebut.

5. Sequence Diagram

Sequence diagram menjelaskan interaksi objek yang disusun berdasarkan urutan waktu. Secara mudahnya sequence diagram adalah gambaran tahap demi tahap yang seharusnya dilakukan untuk menghasilkan sesuatu sesuai dengan use case diagram.

Bersifat dinamis. Diagram urutan adalah interaksi yang menekankan pada pengiriman pesan (message) dalam suatu waktu tertentu.

Sequence diagram menekankan penyusunan berbasis waktu untuk kegiatan yang dilakukan dengan satu set dari objek yang berkolaborasi. Sequence diagram sangat berguna dalam membantu analis, memahami spesifikasi real-time dan menggunakan kasus yang rumit (lihat di bawah). Diagram ini dapat diguanakan untuk mendeskripsikan baik secara fisik dan logis interaksi antara objek.

Sebagai contoh, jika kita memiliki sistem pendaftaran untuk kantor dokter, mungkin masuk akal untuk kelompok kelas pasien dengan kelas sejarah medis pasien bersama-sama untuk membentuk paket kelas pasien. Selain itu, dapat berguna untuk membuat paket perawatan yang mengandung gejala penyakit, penyakit, dan obat-obatan khas yang diresepkan untuk mereka. 

4. State Diagram

State diagram menggambarkan urutan keadaan yang dilalui objek dalam suatu kelas, karena suatu kejadian menyababkan suatu perpindahan aktivitas/state. State dari objek adalah penggolongan dari satu atau lebih nilai attribute pada kelas.

Bersifat dinamis. Diagram state ini memperlihatkan statestate pada system, memuat state, transisi, event, serta aktifitas. Diagram ini terutama penting untuk memperlihatkan sifat dinamis dari antarmuka, kelas, kolaborasi dan terutama penting pada pemodelan system – system yang reaktif.

contoh :“Peminjaman Barang””

• Seorang peminjam yang akan meminjam akan mengisi form peminjaman.
• Sistem akan megecek keadaan barang. Barang tersebut tersedia apa tidak, atau barang tersebut dapat di pinjam atau tidak
• Setelah barang tersedia, sistem akan memvalidasi persetujuan peminjaman barang dan menyerahkan barang kepada peminjam. 
• Sistem juga akan mencari informasi tentang barang yang akan dipinjam, maka akan dilakukan permintaan akan informasi barang.
• Jika informasi yang diterima masih kurang, akan dilakukan permintaan ulang sampai seluruh informasi yang dibutuhkan didapatkan.
• Saat informasi sudah cukup, informasi tersebut akan diserahkan kepada peminjam barang tersebut.

5. Sequence Diagram

Sequence diagram menjelaskan interaksi objek yang disusun berdasarkan urutan waktu. Secara mudahnya sequence diagram adalah gambaran tahap demi tahap yang seharusnya dilakukan untuk menghasilkan sesuatu sesuai dengan use case diagram.

Bersifat dinamis. Diagram urutan adalah interaksi yang menekankan pada pengiriman pesan (message) dalam suatu waktu tertentu.

Sequence diagram menekankan penyusunan berbasis waktu untuk kegiatan yang dilakukan dengan satu set dari objek yang berkolaborasi. Sequence diagram sangat berguna dalam membantu analis, memahami spesifikasi real-time dan menggunakan kasus yang rumit (lihat di bawah). Diagram ini dapat diguanakan untuk mendeskripsikan baik secara fisik dan logis interaksi antara objek.

Pada contoh

sequence diagram diatas digambarkan contoh use case investasi perdagangan. Pada diagram tersebut obyek yang berinteraksi adalah user, userinterface sistem, dan interface terhadap sistem eksternal.Pada diagram tersebut terlihat aliran secara umum,yakni :

1. User memilih account investment.
2. Kemudian, sistem akan mengirimkan pesan pada sistem investor untukmelakukan query harga saham dari investasi pada account user.
3. Sistem akan menampilkan harga saham pada account investasi user.
4. User memilih investasi dan jumlah saham yang akan dijual.
5. Sistem akan mengirimkan pesan kepada sistem investor untukmenyampaikan permintaan untuk menjual saham yang telah ditentukan oleh user.

6. Class Diagram (Class Diagram)

Class adalah dekripsi kelompok obyek-obyek dengan property, perilaku (operasi) dan relasi yang sama. Sehingga dengan adanya class diagram dapat memberikan pandangan global atas sebuah system. Hal tersebut tercermin dari class- class yang ada dan relasinya satu dengan yang lainnya. Sebuah sistem biasanya mempunyai beberapa class diagram. Class diagram sangat membantu dalam visualisasi struktur kelas dari suatu system.

Bersifat statis. Diagram ini memperlihatkan himpunan kelas-kelas, antarmuka, kolaborasi-kolaborasi, serta relasi-relasi. Diagram ini umum dijumpai pada pemodelan system berorientasi objek.

Kelas Diagram berfungsi untuk menjelaskan tipe dari object sistem dan hubungannya dengan object yang lain. Object adalah nilai tertentu dari setiap attribute kelas entity. Pada penggambaran kelas diagram ada dikenal dengan kelas analisis yaitu kelas ber-stereotype. Tapi yang biasanya dipakai adalah kelas diagram tanpa stereotype.

Kelemahan:

• Sulit untuk penentuan antara atribut atau kelas, sering terjadi kesalahan
• Pengimplementasian struktur data sukar dilakukan

Class memiliki 3 area pokok :

1. Name (dan stereotype);
2. Attribute;
3. Method.

Kelemahan:

• Sulit untuk penentuan antara atribut atau kelas, sering terjadi kesalahan
• Pengimplementasian struktur data sukar dilakukan

Class memiliki 3 area pokok :

1. Name (dan stereotype);
2. Attribute;
3. Method.

Kelemahan:

• Sulit untuk penentuan antara atribut atau kelas, sering terjadi kesalahan
• Pengimplementasian struktur data sukar dilakukan

Class memiliki 3 area pokok :

1. Name (dan stereotype);
2. Attribute;
3. Method.

7. Communication Diagram

Communication diagram menggambarkan interaksi antar objek seperti sequence diagram, tetapi lebih menekankan pada peran masing-masing objek. Setiap message memiliki sequence number, dimana message dari level tertinggi memiliki Nomor 1. Diagram membawa informasi yang sama dengan diagram Sequence, tetapi lebih memusatkan atau memfokuskan pada kegiatan obyek dari waktu pesan itu dikirimkan.

Contoh : Diagram Collaboration “Pemesanan kamar di Hotel”

.

8. Composite Structure Diagram

Diagram struktur komposit adalah diagram yang menunjukan struktur internal classifier, termasuk poin interaksinya ke bagian lain dari system. Hal ini menunjukkan konfigurasi dan hubungan bagian, yang bersama-sama melakukan perilaku classifier. Diagram struktur komposit merupakan jenis diagram struktur yang statis dalam UML, yang menggambarkan struktur internal kelas dan kolaborasi.

Struktur komposit dapat digunakan untuk menjelaskan:

• Struktur dari bagian-bagian yang saling berkaitan;
• Run-time struktur yang saling berhubungan.

9. Object Diagram

Object diagram merupakan sebuah gambaran tentang objek-objek dalam sebuah system pada satu titik waktu. Karena lebih menonjolkan perintah-perintah dari pada class, object diagram lebih sering disebut sebagai sebuah diagram perintah.

Object diagram sangat mirip dengan diagram kelas. Perbedaan utama adalah bahwa diagram objek menggambarkan objek dan hubungan mereka. Tujuan utama dari diagram objek adalah untuk memungkinkan analis untuk mengungkap rincian tambahan kelas. Dalam beberapa kasus, pernyataan variabel dari sebuah class diagram dapat membantu pengguna atau analis dalam menemukan atribut tambahan yang relevan, hubungan, dan atau operasi, atau mungkin menemukan bahwa beberapa atribut, hubungan, atau operasi yang salah tempat.

Bersifat statis. Diagram ini mempelihatkan objek-objek serta relasi-relasi antar objek. Diagram objek memperlihatkan instansiasi statis dari segala sesuatu yang dijumpai pada diagram kelas.

10. Timing Diagram

Memperlihatkan interaksi ketika tujuan utama diagram adalah waktu. Menggambarkan perubahan dalam state atau kondisi dari pengelompokkaninstance atau tugas berlebihan. Biasanya dipakai untuk memperlihatkan perubahan dalam state objectberlebihan dalam merespon ke external events. Dipakai untuk memperlihatkan perilaku dari sebuah/ beberapa object melaluiperiode waktu.

Ada 2 jenisTiming diagram yaitu 

1. Concise/simple notation: Dipakai untuk mengeksplorasi sebuah/beberapa object melalui periode waktu
2. Robust notation

Diagram tersebut akan menjadi ideal ketika kita mampu menyeimbangkan ke-6 elemen yang ada, bukan menariknya ke satu atau dua arah saja. Tiap orang biasanya punya satu elemen yang dominan, tinggal bagaimana mengoptimalkan elemen-elemen yang lain saja.

11. Component Diagram

Diagram ini bila dikombinasikan dengan diagram penyebaran dapat digunakan untuk menggambarkan distribusi fisik dari modul perangkat lunak melalui jaringan. Misalnya, ketika merancang sistem client-server, hal ini berguna untuk menunjukkan mana kelas atau paket kelas akan berada pada node klien dan mana yang akan berada di server.

Diagram komponen juga dapat berguna dalam merancang dan mengembangkan sistem berbasis komponen. Karena berfokus pada analisis sistem berorientasi objek dan desain.

12. Deployment Diagram

Deployment diagram menggambarkan detail bagaimana komponen di deploy dalam infrastruktur system, dimana komponen akan terletak (pada mesin, server atau piranti keras), bagaimana kemampuan jaringan pada lokasi tersebut, spesifikasi server, dan hal-hal lain yang bersifat fisikal. Hubungan antar node ( misalnya TCP/IP) dan requirement dapat juga didefinisikan dalam diagram ini.

13. Interaction Overview Diagram

Interaction Overview Diagram adalah pecangkolan secara bersama antara activity diagram dengan sequence diagram. Interaction Overview Diagram dapat dianggap sebagai activity diagram dimana semua aktivitas diganti dengan sedikit sequence diagram, atau bisa juga dianggap sebagai sequence diagram yang dirincikan dengan notasi activity diagram yang digunakan untuk menunjukkan aliran pengawasan.

7. Communication Diagram

Communication diagram menggambarkan interaksi antar objek seperti sequence diagram, tetapi lebih menekankan pada peran masing-masing objek. Setiap message memiliki sequence number, dimana message dari level tertinggi memiliki Nomor 1. Diagram membawa informasi yang sama dengan diagram Sequence, tetapi lebih memusatkan atau memfokuskan pada kegiatan obyek dari waktu pesan itu dikirimkan.

Contoh : Diagram Collaboration “Pemesanan kamar di Hotel”

.

8. Composite Structure Diagram

Diagram struktur komposit adalah diagram yang menunjukan struktur internal classifier, termasuk poin interaksinya ke bagian lain dari system. Hal ini menunjukkan konfigurasi dan hubungan bagian, yang bersama-sama melakukan perilaku classifier. Diagram struktur komposit merupakan jenis diagram struktur yang statis dalam UML, yang menggambarkan struktur internal kelas dan kolaborasi.

Struktur komposit dapat digunakan untuk menjelaskan:

• Struktur dari bagian-bagian yang saling berkaitan;
• Run-time struktur yang saling berhubungan.

9. Object Diagram

Object diagram merupakan sebuah gambaran tentang objek-objek dalam sebuah system pada satu titik waktu. Karena lebih menonjolkan perintah-perintah dari pada class, object diagram lebih sering disebut sebagai sebuah diagram perintah.

Object diagram sangat mirip dengan diagram kelas. Perbedaan utama adalah bahwa diagram objek menggambarkan objek dan hubungan mereka. Tujuan utama dari diagram objek adalah untuk memungkinkan analis untuk mengungkap rincian tambahan kelas. Dalam beberapa kasus, pernyataan variabel dari sebuah class diagram dapat membantu pengguna atau analis dalam menemukan atribut tambahan yang relevan, hubungan, dan atau operasi, atau mungkin menemukan bahwa beberapa atribut, hubungan, atau operasi yang salah tempat.

Bersifat statis. Diagram ini mempelihatkan objek-objek serta relasi-relasi antar objek. Diagram objek memperlihatkan instansiasi statis dari segala sesuatu yang dijumpai pada diagram kelas.

10. Timing Diagram

Memperlihatkan interaksi ketika tujuan utama diagram adalah waktu. Menggambarkan perubahan dalam state atau kondisi dari pengelompokkaninstance atau tugas berlebihan. Biasanya dipakai untuk memperlihatkan perubahan dalam state objectberlebihan dalam merespon ke external events. Dipakai untuk memperlihatkan perilaku dari sebuah/ beberapa object melaluiperiode waktu.

Ada 2 jenisTiming diagram yaitu 

1. Concise/simple notation: Dipakai untuk mengeksplorasi sebuah/beberapa object melalui periode waktu
2. Robust notation

Diagram tersebut akan menjadi ideal ketika kita mampu menyeimbangkan ke-6 elemen yang ada, bukan menariknya ke satu atau dua arah saja. Tiap orang biasanya punya satu elemen yang dominan, tinggal bagaimana mengoptimalkan elemen-elemen yang lain saja.

11. Component Diagram

Diagram ini bila dikombinasikan dengan diagram penyebaran dapat digunakan untuk menggambarkan distribusi fisik dari modul perangkat lunak melalui jaringan. Misalnya, ketika merancang sistem client-server, hal ini berguna untuk menunjukkan mana kelas atau paket kelas akan berada pada node klien dan mana yang akan berada di server.

Diagram komponen juga dapat berguna dalam merancang dan mengembangkan sistem berbasis komponen. Karena berfokus pada analisis sistem berorientasi objek dan desain.

12. Deployment Diagram

Deployment diagram menggambarkan detail bagaimana komponen di deploy dalam infrastruktur system, dimana komponen akan terletak (pada mesin, server atau piranti keras), bagaimana kemampuan jaringan pada lokasi tersebut, spesifikasi server, dan hal-hal lain yang bersifat fisikal. Hubungan antar node ( misalnya TCP/IP) dan requirement dapat juga didefinisikan dalam diagram ini.

13. Interaction Overview Diagram

Interaction Overview Diagram adalah pecangkolan secara bersama antara activity diagram dengan sequence diagram. Interaction Overview Diagram dapat dianggap sebagai activity diagram dimana semua aktivitas diganti dengan sedikit sequence diagram, atau bisa juga dianggap sebagai sequence diagram yang dirincikan dengan notasi activity diagram yang digunakan untuk menunjukkan aliran pengawasan.

                                                               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]

ß Dimensi kandungan aktivitas à	ß Dimensi waktu pengembangan à
	Gambar 1  Tahap-Tahap Pengembangan dalam RUP

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

BAGIAN-BAGIAN DARI UML

            1. Use Case Diagram

Use case adalah abstraksi dari interaksi antara system dan actor. Use case bekerja dengan cara mendeskripsikan tipe interaksi antara user sebuah system dengan sistemnya sendiri melalui sebuah cerita bagaimana sebuah system dipakai.

Diagram Use Case berguna dalam tiga hal :

• Menjelaskan fasilitas yang ada (requirement)
• Komunikasi dengan klien
• Membuat test dari kasus-kasus secara umum\

Kelebihan:

·                     Interaksi antara pengguna dan system lain dengan system yang akan di buat cukup tergambar dengan baik.

·                     Penggambaran dengan sederhana membuat identifikasi kebutuhan dengan use case dapat dengan lebih mudah untuk dipahami.

·                     Pendekatan identifikasi kebutuhan dapat berdasarkan top down (keinginan dari manajemen level atas) maupun bottom up (keinginan pengguna akhir).

·                     Dapat meng-include (memasukkan) fungsionalitas use case lain sebagai bagian dari proses dalam dirinya.

1. Use Case Diagram

Use case adalah abstraksi dari interaksi antara system dan actor. Use case bekerja dengan cara mendeskripsikan tipe interaksi antara user sebuah system dengan sistemnya sendiri melalui sebuah cerita bagaimana sebuah system dipakai.

Diagram Use Case berguna dalam tiga hal :

• Menjelaskan fasilitas yang ada (requirement)
• Komunikasi dengan klien
• Membuat test dari kasus-kasus secara umum\

Kelebihan:

·                     Interaksi antara pengguna dan system lain dengan system yang akan di buat cukup tergambar dengan baik.

·                     Penggambaran dengan sederhana membuat identifikasi kebutuhan dengan use case dapat dengan lebih mudah untuk dipahami.

·                     Pendekatan identifikasi kebutuhan dapat berdasarkan top down (keinginan dari manajemen level atas) maupun bottom up (keinginan pengguna akhir).

·                     Dapat meng-include (memasukkan) fungsionalitas use case lain sebagai bagian dari proses dalam dirinya.

1. Use Case Diagram

Use case adalah abstraksi dari interaksi antara system dan actor. Use case bekerja dengan cara mendeskripsikan tipe interaksi antara user sebuah system dengan sistemnya sendiri melalui sebuah cerita bagaimana sebuah system dipakai.

Diagram Use Case berguna dalam tiga hal :

• Menjelaskan fasilitas yang ada (requirement)
• Komunikasi dengan klien
• Membuat test dari kasus-kasus secara umum\

Kelebihan:

·                     Interaksi antara pengguna dan system lain dengan system yang akan di buat cukup tergambar dengan baik.

·                     Penggambaran dengan sederhana membuat identifikasi kebutuhan dengan use case dapat dengan lebih mudah untuk dipahami.

·                     Pendekatan identifikasi kebutuhan dapat berdasarkan top down (keinginan dari manajemen level atas) maupun bottom up (keinginan pengguna akhir).

·                     Dapat meng-include (memasukkan) fungsionalitas use case lain sebagai bagian dari proses dalam dirinya.

Kelemahan:

• Kekurangan mengenai data masih kurang teridentifikasi dengan baik.

2. Activity Diagram

Activity diagram menyediakan analis dengan kemampuan untuk memodelkan proses dalam suatu sistem informasi. Activity diagram dapat digunakan untuk alur kerja model, use case individual, atau logika keputusan yang terkandung dalam metode individual3. Activity diagram juga menyediakan pendekatan untuk proses pemodelan paralel. Activity diagram lebih lanjut .

Kelemahan:

• Kekurangan mengenai data masih kurang teridentifikasi dengan baik.

2. Activity Diagram

Activity diagram menyediakan analis dengan kemampuan untuk memodelkan proses dalam suatu sistem informasi. Activity diagram dapat digunakan untuk alur kerja model, use case individual, atau logika keputusan yang terkandung dalam metode individual3. Activity diagram juga menyediakan pendekatan untuk proses pemodelan paralel. Activity diagram lebih lanjut .

Kelemahan:

• Kekurangan mengenai data masih kurang teridentifikasi dengan baik.

2. Activity Diagram

Activity diagram menyediakan analis dengan kemampuan untuk memodelkan proses dalam suatu sistem informasi. Activity diagram dapat digunakan untuk alur kerja model, use case individual, atau logika keputusan yang terkandung dalam metode individual3. Activity diagram juga menyediakan pendekatan untuk proses pemodelan paralel. Activity diagram lebih lanjut .

Pada dasarnya, diagram aktifitas canggih dan merupakan diagram aliran data yang terbaru. Secara teknis, diagram aktivitas menggabungkan ide-ide proses pemodelan dengan teknik yang berbeda termasuk model acara, statecharts, dan Petri Nets.

Notasi yang digunakan dalam activity diagram adalah sebagai barikut:

1. Activity: Notasi yang menggambarkan pelaksanaan dari beberapa proses dalam aliran pekerjaan.
2. Transition: Notasi yang digunakan untuk memperlihatkan jalan aliran control dari activity ke activity.
3. Decision: Notasi yang menandakan kontro cabang aliran berdasarkan decision point.
4. Synchronization bars: Aliran kerja notasi ini menandakan bahwa beberapa aktivitas dapat diselesaikan secara bersamaan (pararel).

3. Package Diagram

Package diagram utamanya digunakan untuk mengelompokkan elemen diagram UML yang berlainan secara bersama-sama ke dalam tingkat pembangunan yang lebih tinggi yaitu berupa sebuah paket. Diagram paket pada dasarnya adalah diagram kelas yang hanya menampilkan paket, disamping kelas, dan hubungan ketergantungan, disamping hubungan khas yang ditampilkan pada diagram kelas.

Pada dasarnya, diagram aktifitas canggih dan merupakan diagram aliran data yang terbaru. Secara teknis, diagram aktivitas menggabungkan ide-ide proses pemodelan dengan teknik yang berbeda termasuk model acara, statecharts, dan Petri Nets.

Notasi yang digunakan dalam activity diagram adalah sebagai barikut:

1. Activity: Notasi yang menggambarkan pelaksanaan dari beberapa proses dalam aliran pekerjaan.
2. Transition: Notasi yang digunakan untuk memperlihatkan jalan aliran control dari activity ke activity.
3. Decision: Notasi yang menandakan kontro cabang aliran berdasarkan decision point.
4. Synchronization bars: Aliran kerja notasi ini menandakan bahwa beberapa aktivitas dapat diselesaikan secara bersamaan (pararel).

3. Package Diagram

Package diagram utamanya digunakan untuk mengelompokkan elemen diagram UML yang berlainan secara bersama-sama ke dalam tingkat pembangunan yang lebih tinggi yaitu berupa sebuah paket. Diagram paket pada dasarnya adalah diagram kelas yang hanya menampilkan paket, disamping kelas, dan hubungan ketergantungan, disamping hubungan khas yang ditampilkan pada diagram kelas.

Sebagai contoh, jika kita memiliki sistem pendaftaran untuk kantor dokter, mungkin masuk akal untuk kelompok kelas pasien dengan kelas sejarah medis pasien bersama-sama untuk membentuk paket kelas pasien. Selain itu, dapat berguna untuk membuat paket perawatan yang mengandung gejala penyakit, penyakit, dan obat-obatan khas yang diresepkan untuk mereka. 

4. State Diagram

State diagram menggambarkan urutan keadaan yang dilalui objek dalam suatu kelas, karena suatu kejadian menyababkan suatu perpindahan aktivitas/state. State dari objek adalah penggolongan dari satu atau lebih nilai attribute pada kelas.

Bersifat dinamis. Diagram state ini memperlihatkan statestate pada system, memuat state, transisi, event, serta aktifitas. Diagram ini terutama penting untuk memperlihatkan sifat dinamis dari antarmuka, kelas, kolaborasi dan terutama penting pada pemodelan system – system yang reaktif.

contoh :“Peminjaman Barang””

• Seorang peminjam yang akan meminjam akan mengisi form peminjaman.
• Sistem akan megecek keadaan barang. Barang tersebut tersedia apa tidak, atau barang tersebut dapat di pinjam atau tidak
• Setelah barang tersedia, sistem akan memvalidasi persetujuan peminjaman barang dan menyerahkan barang kepada peminjam. 
• Sistem juga akan mencari informasi tentang barang yang akan dipinjam, maka akan dilakukan permintaan akan informasi barang.
• Jika informasi yang diterima masih kurang, akan dilakukan permintaan ulang sampai seluruh informasi yang dibutuhkan didapatkan.
• Saat informasi sudah cukup, informasi tersebut akan diserahkan kepada peminjam barang tersebut.

5. Sequence Diagram

Sequence diagram menjelaskan interaksi objek yang disusun berdasarkan urutan waktu. Secara mudahnya sequence diagram adalah gambaran tahap demi tahap yang seharusnya dilakukan untuk menghasilkan sesuatu sesuai dengan use case diagram.

Bersifat dinamis. Diagram urutan adalah interaksi yang menekankan pada pengiriman pesan (message) dalam suatu waktu tertentu.

Sequence diagram menekankan penyusunan berbasis waktu untuk kegiatan yang dilakukan dengan satu set dari objek yang berkolaborasi. Sequence diagram sangat berguna dalam membantu analis, memahami spesifikasi real-time dan menggunakan kasus yang rumit (lihat di bawah). Diagram ini dapat diguanakan untuk mendeskripsikan baik secara fisik dan logis interaksi antara objek.

Sebagai contoh, jika kita memiliki sistem pendaftaran untuk kantor dokter, mungkin masuk akal untuk kelompok kelas pasien dengan kelas sejarah medis pasien bersama-sama untuk membentuk paket kelas pasien. Selain itu, dapat berguna untuk membuat paket perawatan yang mengandung gejala penyakit, penyakit, dan obat-obatan khas yang diresepkan untuk mereka. 

4. State Diagram

State diagram menggambarkan urutan keadaan yang dilalui objek dalam suatu kelas, karena suatu kejadian menyababkan suatu perpindahan aktivitas/state. State dari objek adalah penggolongan dari satu atau lebih nilai attribute pada kelas.

Bersifat dinamis. Diagram state ini memperlihatkan statestate pada system, memuat state, transisi, event, serta aktifitas. Diagram ini terutama penting untuk memperlihatkan sifat dinamis dari antarmuka, kelas, kolaborasi dan terutama penting pada pemodelan system – system yang reaktif.

contoh :“Peminjaman Barang””

• Seorang peminjam yang akan meminjam akan mengisi form peminjaman.
• Sistem akan megecek keadaan barang. Barang tersebut tersedia apa tidak, atau barang tersebut dapat di pinjam atau tidak
• Setelah barang tersedia, sistem akan memvalidasi persetujuan peminjaman barang dan menyerahkan barang kepada peminjam. 
• Sistem juga akan mencari informasi tentang barang yang akan dipinjam, maka akan dilakukan permintaan akan informasi barang.
• Jika informasi yang diterima masih kurang, akan dilakukan permintaan ulang sampai seluruh informasi yang dibutuhkan didapatkan.
• Saat informasi sudah cukup, informasi tersebut akan diserahkan kepada peminjam barang tersebut.

5. Sequence Diagram

Sequence diagram menjelaskan interaksi objek yang disusun berdasarkan urutan waktu. Secara mudahnya sequence diagram adalah gambaran tahap demi tahap yang seharusnya dilakukan untuk menghasilkan sesuatu sesuai dengan use case diagram.

Bersifat dinamis. Diagram urutan adalah interaksi yang menekankan pada pengiriman pesan (message) dalam suatu waktu tertentu.

Sequence diagram menekankan penyusunan berbasis waktu untuk kegiatan yang dilakukan dengan satu set dari objek yang berkolaborasi. Sequence diagram sangat berguna dalam membantu analis, memahami spesifikasi real-time dan menggunakan kasus yang rumit (lihat di bawah). Diagram ini dapat diguanakan untuk mendeskripsikan baik secara fisik dan logis interaksi antara objek.

Sebagai contoh, jika kita memiliki sistem pendaftaran untuk kantor dokter, mungkin masuk akal untuk kelompok kelas pasien dengan kelas sejarah medis pasien bersama-sama untuk membentuk paket kelas pasien. Selain itu, dapat berguna untuk membuat paket perawatan yang mengandung gejala penyakit, penyakit, dan obat-obatan khas yang diresepkan untuk mereka. 

4. State Diagram

State diagram menggambarkan urutan keadaan yang dilalui objek dalam suatu kelas, karena suatu kejadian menyababkan suatu perpindahan aktivitas/state. State dari objek adalah penggolongan dari satu atau lebih nilai attribute pada kelas.

Bersifat dinamis. Diagram state ini memperlihatkan statestate pada system, memuat state, transisi, event, serta aktifitas. Diagram ini terutama penting untuk memperlihatkan sifat dinamis dari antarmuka, kelas, kolaborasi dan terutama penting pada pemodelan system – system yang reaktif.

contoh :“Peminjaman Barang””

• Seorang peminjam yang akan meminjam akan mengisi form peminjaman.
• Sistem akan megecek keadaan barang. Barang tersebut tersedia apa tidak, atau barang tersebut dapat di pinjam atau tidak
• Setelah barang tersedia, sistem akan memvalidasi persetujuan peminjaman barang dan menyerahkan barang kepada peminjam. 
• Sistem juga akan mencari informasi tentang barang yang akan dipinjam, maka akan dilakukan permintaan akan informasi barang.
• Jika informasi yang diterima masih kurang, akan dilakukan permintaan ulang sampai seluruh informasi yang dibutuhkan didapatkan.
• Saat informasi sudah cukup, informasi tersebut akan diserahkan kepada peminjam barang tersebut.

5. Sequence Diagram

Sequence diagram menjelaskan interaksi objek yang disusun berdasarkan urutan waktu. Secara mudahnya sequence diagram adalah gambaran tahap demi tahap yang seharusnya dilakukan untuk menghasilkan sesuatu sesuai dengan use case diagram.

Bersifat dinamis. Diagram urutan adalah interaksi yang menekankan pada pengiriman pesan (message) dalam suatu waktu tertentu.

Sequence diagram menekankan penyusunan berbasis waktu untuk kegiatan yang dilakukan dengan satu set dari objek yang berkolaborasi. Sequence diagram sangat berguna dalam membantu analis, memahami spesifikasi real-time dan menggunakan kasus yang rumit (lihat di bawah). Diagram ini dapat diguanakan untuk mendeskripsikan baik secara fisik dan logis interaksi antara objek.

Sebagai contoh, jika kita memiliki sistem pendaftaran untuk kantor dokter, mungkin masuk akal untuk kelompok kelas pasien dengan kelas sejarah medis pasien bersama-sama untuk membentuk paket kelas pasien. Selain itu, dapat berguna untuk membuat paket perawatan yang mengandung gejala penyakit, penyakit, dan obat-obatan khas yang diresepkan untuk mereka. 

4. State Diagram

State diagram menggambarkan urutan keadaan yang dilalui objek dalam suatu kelas, karena suatu kejadian menyababkan suatu perpindahan aktivitas/state. State dari objek adalah penggolongan dari satu atau lebih nilai attribute pada kelas.

Bersifat dinamis. Diagram state ini memperlihatkan statestate pada system, memuat state, transisi, event, serta aktifitas. Diagram ini terutama penting untuk memperlihatkan sifat dinamis dari antarmuka, kelas, kolaborasi dan terutama penting pada pemodelan system – system yang reaktif.

contoh :“Peminjaman Barang””

• Seorang peminjam yang akan meminjam akan mengisi form peminjaman.
• Sistem akan megecek keadaan barang. Barang tersebut tersedia apa tidak, atau barang tersebut dapat di pinjam atau tidak
• Setelah barang tersedia, sistem akan memvalidasi persetujuan peminjaman barang dan menyerahkan barang kepada peminjam. 
• Sistem juga akan mencari informasi tentang barang yang akan dipinjam, maka akan dilakukan permintaan akan informasi barang.
• Jika informasi yang diterima masih kurang, akan dilakukan permintaan ulang sampai seluruh informasi yang dibutuhkan didapatkan.
• Saat informasi sudah cukup, informasi tersebut akan diserahkan kepada peminjam barang tersebut.

5. Sequence Diagram

Sequence diagram menjelaskan interaksi objek yang disusun berdasarkan urutan waktu. Secara mudahnya sequence diagram adalah gambaran tahap demi tahap yang seharusnya dilakukan untuk menghasilkan sesuatu sesuai dengan use case diagram.

Bersifat dinamis. Diagram urutan adalah interaksi yang menekankan pada pengiriman pesan (message) dalam suatu waktu tertentu.

Sequence diagram menekankan penyusunan berbasis waktu untuk kegiatan yang dilakukan dengan satu set dari objek yang berkolaborasi. Sequence diagram sangat berguna dalam membantu analis, memahami spesifikasi real-time dan menggunakan kasus yang rumit (lihat di bawah). Diagram ini dapat diguanakan untuk mendeskripsikan baik secara fisik dan logis interaksi antara objek.

Pada contoh

sequence diagram diatas digambarkan contoh use case investasi perdagangan. Pada diagram tersebut obyek yang berinteraksi adalah user, userinterface sistem, dan interface terhadap sistem eksternal.Pada diagram tersebut terlihat aliran secara umum,yakni :

1. User memilih account investment.
2. Kemudian, sistem akan mengirimkan pesan pada sistem investor untukmelakukan query harga saham dari investasi pada account user.
3. Sistem akan menampilkan harga saham pada account investasi user.
4. User memilih investasi dan jumlah saham yang akan dijual.
5. Sistem akan mengirimkan pesan kepada sistem investor untukmenyampaikan permintaan untuk menjual saham yang telah ditentukan oleh user.

6. Class Diagram (Class Diagram)

Class adalah dekripsi kelompok obyek-obyek dengan property, perilaku (operasi) dan relasi yang sama. Sehingga dengan adanya class diagram dapat memberikan pandangan global atas sebuah system. Hal tersebut tercermin dari class- class yang ada dan relasinya satu dengan yang lainnya. Sebuah sistem biasanya mempunyai beberapa class diagram. Class diagram sangat membantu dalam visualisasi struktur kelas dari suatu system.

Bersifat statis. Diagram ini memperlihatkan himpunan kelas-kelas, antarmuka, kolaborasi-kolaborasi, serta relasi-relasi. Diagram ini umum dijumpai pada pemodelan system berorientasi objek.

Kelas Diagram berfungsi untuk menjelaskan tipe dari object sistem dan hubungannya dengan object yang lain. Object adalah nilai tertentu dari setiap attribute kelas entity. Pada penggambaran kelas diagram ada dikenal dengan kelas analisis yaitu kelas ber-stereotype. Tapi yang biasanya dipakai adalah kelas diagram tanpa stereotype.

Kelemahan:

• Sulit untuk penentuan antara atribut atau kelas, sering terjadi kesalahan
• Pengimplementasian struktur data sukar dilakukan

Class memiliki 3 area pokok :

1. Name (dan stereotype);
2. Attribute;
3. Method.

Kelemahan:

• Sulit untuk penentuan antara atribut atau kelas, sering terjadi kesalahan
• Pengimplementasian struktur data sukar dilakukan

Class memiliki 3 area pokok :

1. Name (dan stereotype);
2. Attribute;
3. Method.

Kelemahan:

• Sulit untuk penentuan antara atribut atau kelas, sering terjadi kesalahan
• Pengimplementasian struktur data sukar dilakukan

Class memiliki 3 area pokok :

1. Name (dan stereotype);
2. Attribute;
3. Method.

7. Communication Diagram

Communication diagram menggambarkan interaksi antar objek seperti sequence diagram, tetapi lebih menekankan pada peran masing-masing objek. Setiap message memiliki sequence number, dimana message dari level tertinggi memiliki Nomor 1. Diagram membawa informasi yang sama dengan diagram Sequence, tetapi lebih memusatkan atau memfokuskan pada kegiatan obyek dari waktu pesan itu dikirimkan.

Contoh : Diagram Collaboration “Pemesanan kamar di Hotel”

.

8. Composite Structure Diagram

Diagram struktur komposit adalah diagram yang menunjukan struktur internal classifier, termasuk poin interaksinya ke bagian lain dari system. Hal ini menunjukkan konfigurasi dan hubungan bagian, yang bersama-sama melakukan perilaku classifier. Diagram struktur komposit merupakan jenis diagram struktur yang statis dalam UML, yang menggambarkan struktur internal kelas dan kolaborasi.

Struktur komposit dapat digunakan untuk menjelaskan:

• Struktur dari bagian-bagian yang saling berkaitan;
• Run-time struktur yang saling berhubungan.

9. Object Diagram

Object diagram merupakan sebuah gambaran tentang objek-objek dalam sebuah system pada satu titik waktu. Karena lebih menonjolkan perintah-perintah dari pada class, object diagram lebih sering disebut sebagai sebuah diagram perintah.

Object diagram sangat mirip dengan diagram kelas. Perbedaan utama adalah bahwa diagram objek menggambarkan objek dan hubungan mereka. Tujuan utama dari diagram objek adalah untuk memungkinkan analis untuk mengungkap rincian tambahan kelas. Dalam beberapa kasus, pernyataan variabel dari sebuah class diagram dapat membantu pengguna atau analis dalam menemukan atribut tambahan yang relevan, hubungan, dan atau operasi, atau mungkin menemukan bahwa beberapa atribut, hubungan, atau operasi yang salah tempat.

Bersifat statis. Diagram ini mempelihatkan objek-objek serta relasi-relasi antar objek. Diagram objek memperlihatkan instansiasi statis dari segala sesuatu yang dijumpai pada diagram kelas.

10. Timing Diagram

Memperlihatkan interaksi ketika tujuan utama diagram adalah waktu. Menggambarkan perubahan dalam state atau kondisi dari pengelompokkaninstance atau tugas berlebihan. Biasanya dipakai untuk memperlihatkan perubahan dalam state objectberlebihan dalam merespon ke external events. Dipakai untuk memperlihatkan perilaku dari sebuah/ beberapa object melaluiperiode waktu.

Ada 2 jenisTiming diagram yaitu 

1. Concise/simple notation: Dipakai untuk mengeksplorasi sebuah/beberapa object melalui periode waktu
2. Robust notation

Diagram tersebut akan menjadi ideal ketika kita mampu menyeimbangkan ke-6 elemen yang ada, bukan menariknya ke satu atau dua arah saja. Tiap orang biasanya punya satu elemen yang dominan, tinggal bagaimana mengoptimalkan elemen-elemen yang lain saja.

11. Component Diagram

Diagram ini bila dikombinasikan dengan diagram penyebaran dapat digunakan untuk menggambarkan distribusi fisik dari modul perangkat lunak melalui jaringan. Misalnya, ketika merancang sistem client-server, hal ini berguna untuk menunjukkan mana kelas atau paket kelas akan berada pada node klien dan mana yang akan berada di server.

Diagram komponen juga dapat berguna dalam merancang dan mengembangkan sistem berbasis komponen. Karena berfokus pada analisis sistem berorientasi objek dan desain.

12. Deployment Diagram

Deployment diagram menggambarkan detail bagaimana komponen di deploy dalam infrastruktur system, dimana komponen akan terletak (pada mesin, server atau piranti keras), bagaimana kemampuan jaringan pada lokasi tersebut, spesifikasi server, dan hal-hal lain yang bersifat fisikal. Hubungan antar node ( misalnya TCP/IP) dan requirement dapat juga didefinisikan dalam diagram ini.

13. Interaction Overview Diagram

Interaction Overview Diagram adalah pecangkolan secara bersama antara activity diagram dengan sequence diagram. Interaction Overview Diagram dapat dianggap sebagai activity diagram dimana semua aktivitas diganti dengan sedikit sequence diagram, atau bisa juga dianggap sebagai sequence diagram yang dirincikan dengan notasi activity diagram yang digunakan untuk menunjukkan aliran pengawasan.

7. Communication Diagram

Communication diagram menggambarkan interaksi antar objek seperti sequence diagram, tetapi lebih menekankan pada peran masing-masing objek. Setiap message memiliki sequence number, dimana message dari level tertinggi memiliki Nomor 1. Diagram membawa informasi yang sama dengan diagram Sequence, tetapi lebih memusatkan atau memfokuskan pada kegiatan obyek dari waktu pesan itu dikirimkan.

Contoh : Diagram Collaboration “Pemesanan kamar di Hotel”

.

8. Composite Structure Diagram

Diagram struktur komposit adalah diagram yang menunjukan struktur internal classifier, termasuk poin interaksinya ke bagian lain dari system. Hal ini menunjukkan konfigurasi dan hubungan bagian, yang bersama-sama melakukan perilaku classifier. Diagram struktur komposit merupakan jenis diagram struktur yang statis dalam UML, yang menggambarkan struktur internal kelas dan kolaborasi.

Struktur komposit dapat digunakan untuk menjelaskan:

• Struktur dari bagian-bagian yang saling berkaitan;
• Run-time struktur yang saling berhubungan.

9. Object Diagram

Object diagram merupakan sebuah gambaran tentang objek-objek dalam sebuah system pada satu titik waktu. Karena lebih menonjolkan perintah-perintah dari pada class, object diagram lebih sering disebut sebagai sebuah diagram perintah.

Object diagram sangat mirip dengan diagram kelas. Perbedaan utama adalah bahwa diagram objek menggambarkan objek dan hubungan mereka. Tujuan utama dari diagram objek adalah untuk memungkinkan analis untuk mengungkap rincian tambahan kelas. Dalam beberapa kasus, pernyataan variabel dari sebuah class diagram dapat membantu pengguna atau analis dalam menemukan atribut tambahan yang relevan, hubungan, dan atau operasi, atau mungkin menemukan bahwa beberapa atribut, hubungan, atau operasi yang salah tempat.

Bersifat statis. Diagram ini mempelihatkan objek-objek serta relasi-relasi antar objek. Diagram objek memperlihatkan instansiasi statis dari segala sesuatu yang dijumpai pada diagram kelas.

10. Timing Diagram

Memperlihatkan interaksi ketika tujuan utama diagram adalah waktu. Menggambarkan perubahan dalam state atau kondisi dari pengelompokkaninstance atau tugas berlebihan. Biasanya dipakai untuk memperlihatkan perubahan dalam state objectberlebihan dalam merespon ke external events. Dipakai untuk memperlihatkan perilaku dari sebuah/ beberapa object melaluiperiode waktu.

Ada 2 jenisTiming diagram yaitu 

1. Concise/simple notation: Dipakai untuk mengeksplorasi sebuah/beberapa object melalui periode waktu
2. Robust notation

Diagram tersebut akan menjadi ideal ketika kita mampu menyeimbangkan ke-6 elemen yang ada, bukan menariknya ke satu atau dua arah saja. Tiap orang biasanya punya satu elemen yang dominan, tinggal bagaimana mengoptimalkan elemen-elemen yang lain saja.

11. Component Diagram

Diagram ini bila dikombinasikan dengan diagram penyebaran dapat digunakan untuk menggambarkan distribusi fisik dari modul perangkat lunak melalui jaringan. Misalnya, ketika merancang sistem client-server, hal ini berguna untuk menunjukkan mana kelas atau paket kelas akan berada pada node klien dan mana yang akan berada di server.

Diagram komponen juga dapat berguna dalam merancang dan mengembangkan sistem berbasis komponen. Karena berfokus pada analisis sistem berorientasi objek dan desain.

12. Deployment Diagram

Deployment diagram menggambarkan detail bagaimana komponen di deploy dalam infrastruktur system, dimana komponen akan terletak (pada mesin, server atau piranti keras), bagaimana kemampuan jaringan pada lokasi tersebut, spesifikasi server, dan hal-hal lain yang bersifat fisikal. Hubungan antar node ( misalnya TCP/IP) dan requirement dapat juga didefinisikan dalam diagram ini.

13. Interaction Overview Diagram

Interaction Overview Diagram adalah pecangkolan secara bersama antara activity diagram dengan sequence diagram. Interaction Overview Diagram dapat dianggap sebagai activity diagram dimana semua aktivitas diganti dengan sedikit sequence diagram, atau bisa juga dianggap sebagai sequence diagram yang dirincikan dengan notasi activity diagram yang digunakan untuk menunjukkan aliran pengawasan.