Macam-macam Diagram UML dan Water Fall

Tugas Mandiri

Etika Profesi
Minggu ke-2
Nama: Muhammad Azhari
Nim     : 41810010082
Kelas : Selasa, 10:45, T-402
Blog   : tugaskommasazhari.blogspot.com

Use Case Diagram

          Menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”, Menggambarkan kebutuhan system dari sudut pandang user. Menggambarkan hubungan antara use case dan actor

          Secara umum use case adalah:

·        Pola perilaku system

·        Urutan transaksi yang berhubungan yang dilakukan oleh satu actor

Use case diagram terdiri dari

·        Use case

·        Actors

·        Relationship

·        System boundary boxes (optional)

·        Packages (optional)

          Use case diberi nama yang menyatakan apa hal yang dicapai dari hasil interaksinya dengan actor.

          Use case dinotasikan dengan gambar (horizontal ellipse). Nama use case boleh terdiri dari beberapa kata dan tidak boleh ada 2 use case yang memiliki nama yang sama.

          Actor menggambarkan orang, system atau external entitas / stakeholder yang menyediakan atau menerima informasi dari system.

          Associations digunakan untuk menggambarkan bagaimana actor terlibat dalam use case.

 Class Diagram    

          Class diagram menggambarkan struktur dan deskripsi class, package dan objek beserta hubungan satu sama lain seperti hubungan dinamis, pewarisan, asosiasi, dan agregasi. Sesuai dengan perkembangan class model, class dapat dikelompokkan menjadi package.

Class memiliki tiga area pokok :                                                                                    

 1. Nama Class                                                                                                 

2. Atribut                                                                                                       

3. Metoda

Contoh Class Buku terdiri dari :

– Atribut : judul, pengarang

– Method : ambilJenis(), ambilHalaman();

Sifat Class Diagram Atribut dan metoda dapat memiliki salah satu sifat berikut :

·        Private Private, tidak dapat dipanggil dari luar  , tidak dapat dipanggil dari luar class  class yang  yang  bersangkutan.

·        Protected, hanya dapat dipanggil oleh class yang bersangkutan dan anak-anak yang mewarisinya.

·        Public, dapat dipanggil oleh siapa saja.

Class Diagram mempunyai 3 komponen, antara lain:

1. Entity Classes : Segala sesuatu (concrete, conceptual, event, and state) dapat dijadikan suatu entity dalam suatu Class.                                                              2. Interfaces Classes : Class dapat merupakan implementasi dari sebuah interface, yaitu class abstrak yang hanya memiliki metoda.                         3. Control Classes : Merupakan suatu class yang difungsikan untuk mengatur Entity Classes dan Interfaaces Classes.

Statechart Diagram

          Statechart diagram menggambarkan transisi dan perubahan keadaan (dari satu state ke state lainnya) suatu objek pada sistem sebagai akibat dari stimuli yang diterima.

          Pada umumnya statechart diagram menggambarkan class tertentu (satu class dapat memiliki lebih dari satu statechart diagram).

•         Action ( aktifitas: menjalankan atau membuat state berubah) yang dilakukan sebagai akibat dari event ( penyebab terjadinya perubahan ) tertentu dituliskan dengan diawali garis miring.

     •         Kategori action :

1.     Entry : apa yang terjadi ketika system memasuk state

2.     Do  : apa yang terjadi ketika system berada dalam state

3.     Exit : apa yang terjadi ketika system meninggalkan state

     Dalam UML, state digambarkan berbentuk segiempat dengan sudut membulat (rounded rectangle) dan memiliki nama sesuai kondisinya saat itu.

•         Titik awal (start state)  digambarkan sebagai lingkaran berwarna  penuh

•         Titik akhir (end state)  akhir digambarkan berbentuk lingkaran  berwarna setengah di pusat lingkaran .

•         Transisi antar state digambarkan garis anak panah .

Symbolnya

Activity Diagram

• Menggambarkan proses bisnis dan urutan aktivitas dalam sebuah proses
• Dipakai pada business modeling untuk memperlihatkan urutan aktifitas proses bisnis
• Struktur diagram ini mirip flowchart atau Data Flow Diagram pada perancangan terstruktur
• Activity diagram dibuat berdasarkan sebuah atau beberapa use case pada use case diagram.
• Activity menggambarkan sebuah pekerjaan/tugas dalam workflow.

Pada UML, activity digambarkan dengan simbol belah ketupat=‘lozenge’ (horizontal top and bottom with convex sides).

• Start state dengan tegas menunjukkan dimulainya suatu workflow pada sebuah activity diagram.
• Hanya ada satu start state dalam sebuah workflow.
• Pada UML, start state digambarkan dengan simbol lingkaran yang solid.
• End state menggambarkan akhir atau terminal dari pada sebuah activity diagram.
• žBisa terdapat lebih dari satu end state pada sebuah activity diagram.
• Pada UML, end state digambarkan dengan simbol sebuah bull’s eye.

Sequence Diagram

          Kelas diagram menunjukkan hubungan statis yang terjadi antara satu

objek dengan objek yang lain. Sequence Diagram menunjukkan suatu

scenario yang dinamis.

          Squence diagram digunakan untuk mendeskripsikan pola komunikasi

antar objek. Squence diagram mengambarkan urutan waktu dari aliran

pemanggilan pada suatu method. Squence diagram berhubungan erat dengan Use Case diagram, dimana 1 Use Case akan menjadi 1 Sequence Diagram.

Symbol

Dalam squence diagram terdapat 2 symbol yaitu :

• Actor : Digunakan untuk menggambarkan pengguna system

• LifeLine : Digunakan untuk menggambarkan kelas dan objek

Relasi

Dalam squence diagram terdapat 3 relasi yaitu :

• Create : Relasi ini digunakan untuk melakukan inisialisasi suatu objek.

• Synchronous : Relasi ini digunakan untuk memaggil operasi atau method yang dimiliki oleh suatu objek. Synchronous mengharuskan kita menyelesaikan 1 proses baru kemudian memanggil proses berikutnya.

• Asynchronous : Relasi ini digunakan untuk memanggil operasi atau method yang dimiliki oleh suatu objek. Asynchronous memberikan kita fasilitas untuk menjalankan proses lain ketika proses sebelumnya belum selesai.

Collaboration Diagram

·        Merupakan cara alternatif untuk menampilkan suatu skenario

·        Menampilkan interaksi obyek yang terorganisasi di sekitar obyek dan hubungannya dengan obyek yang lain.

Berisi

·        Obyek, yang digambarkan dalam rectangle

·        Link antar obyek, diperlihatkan sebagai garis yang menghubungkan dengan obyek lain.

·        Message ditunjukkan sebagai teks dan panah yang mengarah dari client ke supplier.

           Collaboration Diagram mendeskripsikan pola interaksi antar object. Diagram ini menunjukkan object-object yang terlibat dalam interaksi melalui link dan message yang dikirim antar object.

Object dapat direpresentasikan:

·        NamaObject:NamaClass

·        NamaObject

·        NamaClass

Link adalah hubungan antar object yang dapat digunakan untuk mengirim message. Link digambarkan dengan garis solid antar dua object

Message : pengertiannya sama dengan message pada sequence diagram

Deployment Diagram

Berisi:

—  Node

—  Relasi : dependensi, asosiasi

—  Tambahan: catatan (note) dan batasan (constraint)

Fungsi:

—  Model statik distribusi komponen pada perangkat keras

          Deployment/physical diagram menggambarkan detail bagaimana komponen di-deploy dalam infrastruktur sistem, di mana komponen akan terletak (pada mesin, server atau piranti keras apa), bagaimana kemampuan jaringan pada lokasi tersebut, spesifikasi server, dan hal-hal lain yang bersifat fisikal

          Sebuah node adalah server, workstation, atau piranti keras lain yang digunakan untuk men-deploy komponen dalam lingkungan sebenarnya. Hubungan antar node (misalnya TCP/IP) dan requirement dapat juga didefinisikan dalam diagram ini.

 Penggunaan:

—  Memodelkan embedded system : perangkat lunak yang mengontrol device

—  Memodelkan client-server system

—  Memodelkan fully distributed system

  

Component Diagram

•      Component diagram menggambarkan struktur dan hubungan antar komponen piranti lunak, termasuk ketergantungan (dependency) di antaranya.

•      Komponen piranti lunak adalah modul berisi code, baik berisi source code maupun binary code, baik library maupun executable, baik yang muncul pada compile time, link time, maupun run time.

•      Pada umumnya komponen terbentuk dari beberapa class dan/atau package, tapi dapat juga dari komponen-komponen yang lebih kecil.

•      Komponen dapat juga berupa interface, yaitu kumpulan layanan yang disediakan sebuah komponen untuk komponen lain.

Package Diagram

·        Memperlihatkan bagaimana elemen model diorganisasikan/dikelompokkan ke dalam packages

·        Biasanya dipakai pada use case diagram atau class diagram

·        Packages digambarkan sebagai sebuah direktori (file folders) yang berisi model-model elemen

·        Packages dapat diterapkan pada sembarang diagram UML

·        Walaupun package secara resmi bukanlah diagram UML, namun kegunaannya cukup signifikan

·        Penjelasan package diagram pada masing-masing diagram UML

·        Packages dibuat untuk :

n  Menggambarkan high level overview kebutuhan system

n  Menggambarkan high level overview design

n  Memecah sebuah diagram yang mempunyai banyak bubbles

n  Mengorganisasikan source code programming

 Object Diagram

          Sebuah diagram objek dalam Unified Modeling Language (UML), adalah diagram yang menunjukkan pandangan lengkap atau sebagian dari struktur sistem yang dimodelkan pada waktu tertentu.

Sebuah diagram Obyek berfokus pada beberapa set tertentu contoh objek dan atribut, dan hubungan antara contoh. Satu set berkorelasi diagram objek memberikan wawasan tentang bagaimana pandangan sewenang-wenang sistem diharapkan berkembang dari waktu ke waktu. Diagram objek yang lebih konkret daripada diagram kelas, dan sering digunakan untuk memberikan contoh, atau bertindak sebagai kasus uji untuk diagram kelas. Hanya aspek-aspek model yang menarik saat ini perlu ditampilkan pada diagram objek.

instance spesifikasi

          Setiap obyek dan link pada diagram objek diwakili oleh sebuah InstanceSpecification. Hal ini dapat menunjukkan classifier obyek (misalnya kelas abstrak atau beton) dan nama instance, serta atribut dan fitur struktural lainnya menggunakan slot. Slot masing-masing sesuai dengan atribut tunggal atau fitur, dan mungkin termasuk nilai entitas tersebut.

          Sebagai contoh, mempertimbangkan salah satu cara yang mungkin produksi pemodelan deret Fibonacci.

Pada diagram objek UML pertama di sebelah kanan, contoh dalam spesifikasi contoh paling kiri bernama v1, memiliki IndependentVariable sebagai classifier nya, memainkan peran dalam NMinus2 FibonacciSystem, dan memiliki slot untuk atribut val dengan nilai 0. Obyek kedua bernama v2, adalah IndependentVariable kelas, memainkan peran NMinus1, dan memiliki val = 1. Obyek DependentVariable bernama v3, dan memainkan peran N. Contoh paling atas, spesifikasi contoh anonim, memiliki FibonacciFunction sebagai classifier, dan mungkin memiliki nama contoh, peran, dan slot, tetapi ini tidak ditampilkan di sini. Diagram juga mencakup tiga link bernama, ditampilkan sebagai baris. Link adalah contoh dari asosiasi.

Water Fall

            Nama model ini sebenarnya adalah “Linear Sequential Model”. Model ini sering disebut dengan “classic life cycle” atau model waterfall. Model ini adalah model yang muncul pertama kali yaitu sekitar tahun 1970 sehingga sering dianggap kuno, tetapi merupakan model yang paling banyak dipakai didalam Software Engineering (SE). Model ini melakukan pendekatan secara sistematis dan urut mulai dari level kebutuhan sistem lalu menuju ke tahap analisis, desain, coding, testing / verification, dan maintenance. Disebut dengan waterfall karena tahap demi tahap yang dilalui harus menunggu selesainya tahap sebelumnya dan berjalan berurutan.

Model Water Fall

Penjelasanya

·         System / Information Engineering and Modeling. Permodelan ini diawali dengan mencari kebutuhan dari keseluruhan sistem yang akan diaplikasikan ke dalam bentuk software. Hal ini sangat penting, mengingat software harus dapat berinteraksi dengan elemen-elemen yang lain seperti hardware, database, dsb. Tahap ini sering disebut dengan Project Definition.

·         Software Requirements Analysis. Proses pencarian kebutuhan diintensifkan dan difokuskan pada software. Untuk mengetahui sifat dari program yang akan dibuat, maka para software engineer harus mengerti tentang domain informasi dari software, misalnya fungsi yang dibutuhkan, user interface, dsb. Dari 2 aktivitas tersebut (pencarian kebutuhan sistem dan software) harus didokumentasikan dan ditunjukkan kepada pelanggan.

·         Design. Proses ini digunakan untuk mengubah kebutuhan-kebutuhan diatas menjadi representasi ke dalam bentuk “blueprint” software sebelum coding dimulai. Desain harus dapat mengimplementasikan kebutuhan yang telah disebutkan pada tahap sebelumnya. Seperti 2 aktivitas sebelumnya, maka proses ini juga harus didokumentasikan sebagai konfigurasi dari software.

·         Coding. Untuk dapat dimengerti oleh mesin, dalam hal ini adalah komputer, maka desain tadi harus diubah bentuknya menjadi bentuk yang dapat dimengerti oleh mesin, yaitu ke dalam bahasa pemrograman melalui proses coding. Tahap ini merupakan implementasi dari tahap design yang secara teknis nantinya dikerjakan oleh programmer.

·         Testing / Verification. Sesuatu yang dibuat haruslah diujicobakan. Demikian juga dengan software. Semua fungsi-fungsi software harus diujicobakan, agar software bebas dari error, dan hasilnya harus benar-benar sesuai dengan kebutuhan yang sudah didefinisikan sebelumnya.

·         Maintenance. Pemeliharaan suatu software diperlukan, termasuk di dalamnya adalah pengembangan, karena software yang dibuat tidak selamanya hanya seperti itu. Ketika dijalankan mungkin saja masih ada errors kecil yang tidak ditemukan sebelumnya, atau ada penambahan fitur-fitur yang belum ada pada software tersebut. Pengembangan diperlukan ketika adanya perubahan dari eksternal perusahaan seperti ketika ada pergantian sistem operasi, atau perangkat lainnya.

Kelebihan dan kekurangan :

·         Perubahan sulit dilakukan karena sifatnya yang kaku.

·         Karena sifat kakunya, model ini cocok ketika kebutuhan dikumpulkan secara lengkap sehingga perubahan bisa ditekan sekecil mungkin. Tapi pada kenyataannya jarang sekali konsumen/pengguna yang bisa memberikan kebutuhan secara lengkap, perubahan kebutuhan adalah sesuatu yang wajar terjadi.

·         Waterfall pada umumnya digunakan untuk rekayasa sistem yang besar dimana proyek dikerjakan di beberapa tempat berbeda, dan dibagi menjadi beberapa bagian sub-proyek.

Fase-fase menurut Sommerville

Penjelasannya :

1.         Requirements Analysis and Definition (Analisis dan Definisi Persyaratan)

l  Mengumpulkan kebutuhan secara lengkap, kemudian di analisis

l  Didefinisikan kebutuhan yang harus dipenuhi oleh program yang akan dibangun

l  Fase ini harus dikerjakan secara lengkap untuk bisa menghasil desain yg lengkap

l  Pelayanan, batasan, dan tujuan sistem ditentukan melalui konsultasi dengan user sistem.

2.         System and Software Design (Perancangan sistem dan Perangkat Lunak)

l  Desain dikerjakan stelah kebutuhan selesai dikumpulkan secara lengkap

l  Proses perancangan sistem membagi persyaratan dalam sistem perangkat keras atau perangkat lunak. Menentukan arsitektur sistem secara keseluruhan.

3.         Implementation and Unit System (Implementasi dan pengujian unit)

l  Desain program diterjemahkankedalam kode-kode dg menggunakan bahasa pemrograman yang sudah ditentukan.

l  Program yang dibangun langsung diuji baik secara unit

l  Perancangan perangkat lunak direalisasikan sebagai serangkaian program atau unit program. Pengujian unit melibatkan verifikasi bahwa setiap unit telah memenuhi spesifikasinya.

4.         Integration and System Testing (Integrasi dan Pengujian Sistem)

l  Penyatuan unit program kemudian uji secara keseluruhan

l  Unit program atau program individual diintegrasikan dan diuji sebagai sistem yang lengkap untuk menjamin bahwa persyaratan sistem telah dipenuhi. Setelah pengujian sistem, PL dikirim ke User.

5.         Operation and Maintenance (Operasi dan Pemeliharaan)

l  Mengoperasikan program dilingkunganya dan melakukan pemeliharaan seperti menyesuaian/perubahan dengan situasi sebenarnya.

l  Biasanya merupakan fase siklus yg paling lama (walaupun tidak seharusnya). Sistem diinstall dan di pakai.

l  Pemeliharaan mencakup koreksi dan berbagai error yg tdk ditemukan pada tahap2 sebelumnya, perbaikan atas implementasi unit sistem dan pengembangan pelayanan sistem.