TUGAS 13 DIAGRAM UML & METODE WATERFALL

.    

13 DIAGRAM UML & METODE WATERFALL

13 Diagram UML

Model-Model Diagram UML

Kumpulan 13 Diagram UML

1.       Diagram Use Case

Diagram use case adalah deskripsi fungsi dari sebuah sistem dariperspektif/sudut pandang para pengguna sistem. Use case mendefinisikan “apa”yang dilakukan oleh sistem dan elemen elemennya, bukan “bagaimana” sistemdan elemen-elemennya saling berinteraksi. Use case bekerja denganmenggunakan “scenario”, yaitu deskripsi urutan-urutan langkah yang menerangkan apa yang dilakukan pengguna terhadap sistem maupun sebaliknya. Diagram  use case mengidentifikasikan fungsionalitas yang dipunyai oleh sistem(use case), user yang berinteraksi dengan sistem (actor) dan asosiasi/keterhubungan antara user dengan fungsionalitas sistem. Komponen notasi dasar yang dipunyai oleh diagram use case adalah actor, use-case, dan association. Berikut adalah notasi yang terdapat pada diagram use case. Diagram use case memiliki sebuah model khusus yang terbatas untuk kondisi tertentu yang disebut stereotype. Untuk menunjukkan stereotype digunakan symbol “<<”  diawalnya dan ditutup dengan “>>” diakhirnya. Terdapat dua stereotype paling sering digunakan dalam use case diagram yaitu <<extend>> dan <<include>> <<extend>> digunakan untuk menunjukkan bahwa satu use case merupakantambahan fungsional dari use case yang lain jika kondisi atau syarat tertentu dipenuhi. Sedangkan <<include>> digunakan untuk menggambarkan bahwa suatu use case seluruhnya merupakan fungsionalitas dari use case lainnya.

Contoh : Use Case Diagram

2.      Diagram Activity

Diagram activity digunakan untuk mendokumentasikan alur kerja pada sebuah sistem, yang dimulai dari pandangan business level hingga ke operational level. Pada dasarnya, diagram activity merupakan variasi dari diagram state machine. Diagram activity mempunyai peran seperti halnya flowchart, akan tetapi perbedaannya dengan flowchart adalah diagram activity bisa mendukung perilaku parallel sedangkan flowchart tidak bisa.

Contoh : Activity Diagram

3.      Diagram Sequence

Diagram Sequence mendokumentasikan komunikasi/interaksi antar kelaskelas. Diagram ini menunjukkan sejumlah objek dan message (pesan) – yang diletakkan diantara objek-objek didalam use case. Perlu diingat bahwa di dalam diagram ini, kelas-kelas dan aktor-aktor diletakkan dibagian atas diagram dengan urutan dari kiri ke kanan dengan garis lifeline yang diletakkan secara vertical terhadap kelas dan aktor.

Contoh : Sequence Diagram

4.      Diagram Class

Diagram Class adalah sebuah spesifikasi yang jika diinstansiasi akan menghasilkan sebuah objek dan merupakan inti dari pengembangan dan desain berorientasi objek. Class diagram mendeskripsikan jenis-jenis objek dalam sistem dan berbagai macam hubungan statis yang terdapat pada mereka. Class menggambarkan keadaan (atribut/properti) suatu sistem, sekaligus menawarkan layanan untuk memanipulasi keadaan tersebut (metoda/fungsi).

Contoh : Class Diagram

5.       Diagram Component

Komponen perangkat lunak adalah bagian fisik dari sebuah sistem yang menetap di komputer. komponen merupakan implementasi software dari sebuah class. Komponen bisa berupa tabel, file data, file exe, file DLL, dokumen, dll. Diagram component mengandung komponen, interface dan relationship. Komponen diagram ini digunakan pada saat pengembang ingin memecah sistem menjadi komponen-komponen dan ingin menampilkan hubungan-hubungan mereka dengan antarmuka atau pemecahan komponen menjadi struktur yang lebih rendah. Secara umum dapat disimpulkan bahwa component diagram yang digunakan untuk menjelaskan kebergantungan antar beragam komponenkomponen software seperti misalnya kebergantungan antara file-file executable dengan file-file sumbernya (source file) dll.

Contoh : Component Diagram

6.       Diagram Deployment

Diagram deployment menunjukkan tata letak sebuah sistem secara fisik, menampakkan bagian-bagian software yang berjalan pada bagian-bagian hardware yang digunakan untuk mengimplementasikan sebuah sistem dan keterhubungan antara komponen-komponen hardware tersebut. Diagram deployment dapat digunakan pada bagian-bagian awal proses perancangan sistem untuk mendokumentasikan arsitektur fisik sebuah sistem.

Contoh : Deployment Diagram

7.       Diagram State(State Machine Diagram)

State Machine Diagram menelusuri individu-individu objek melalui keseluruhan daur hidupnya, menspesifikasi semua urutan yang mungkin dari pesan-pesan yang akan diterima objek tersebut bersama-sama dengan tanggapan atas pesan-pesan tersebut. Diagram State menggambarkan transisi dan perubahan keadaan suatu objek dalam sistem sebagai akibat dari stimuli yang diterima. Pada umumnya diagram ini menggambarkan class tertentu. State diagram membantu analis, perancang dan pengembang untuk memahami perilaku objek dalam sistem.

Contoh : Diagram State(State Machine Diagram)

8.      Diagram Composite (Composite Structure Diagram)

Composite Structure Diagram adalah diagram untuk menunjukkan dekomposisi secara hierarkis sebuah class ke sebuah struktur internal. Hal ini memungkinkan untuk memecah objek yang kompleks menjadi bagian-bagian yang kecil.

Contoh : Composite Structure Diagram

9.       Diagram Object

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

Contoh : Object Diagram

10.  Diagram Package

Package diagram adalah sebuah bentuk pengelompokan yang memungkinkan untuk mengambil setiap bentuk di UML dan mengelompokkan elemen-elemen dalam tingkatan unit yang lebih tinggi. Kegunaan package yang paling umum adalah untuk mengelompokkan class.

Contoh : Package Diagram

11.  Diagram Communication

Collaboration diagram juga menggambarkan interaksi antar objek seperti sequence diagram, tetapi lebih menekankan pada peran masing-masing objek dan bukan pada waktu penyampaian message. Setiap message memiliki sequence number, di mana message dari level tertinggi memiliki nomor 1. Messages dari level yang sama memiliki prefiks yang sama..

Contoh : Communication Diagram

12.  Diagram Interaction Overview

Interaction Overview Diagram adalah pencangkokan 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.

Contoh : Interacion Overview Diagram

13.  Diagram Timing

Timing Diagram adalah bentuk lain dari interaction diagram, dimana focus utamanya lebih ke waktu. Timing diagram sangat berdaya guna dalam menunjukkan faktor pembatas waktu diantara perubahan state pada objek yang berbeda.

 

Contoh : Timing Diagram

.          Waterfall

Waterfall  adalah kegiatan dasar seperti spesifikasi , pengembangan validasi, evolusi dan merepresentasikannya sebagai fase-fase proses yang berbeda seperti spesifikasi persyaratan, perancangan perangkat lunak , implementasi , pengujian dan seterusnya.

Kelebihan dari metode waterfall

1.       Setiap tahap dikerjakan dengan lengkap dan jelas.

2.       Dokumentasi sangat baik.

3.       Model proses waterfall menngusulkan sebuah pendekatan kepada perkembangan perangkat lunak yang sistematik dan sekuensial yang mulai pada tingkat dan kemajuan sistem pada seluruh analisis, desain, kode, pengujian, dan pemeliharaan. Dan dimodelkan setelah siklus rekayasa konvensiaonal, dimana model sekuensial linier ataupun waterfall proses melingkupi aktivitas-aktivitas sebagai berikut:

       a.       Rekayasa dan pemodelan sistem/informasi.

       b.      Analisis kebutuhan perangkat lunak.

       c.       Desain

       d.      Generasi kode

       e.      Pengujian

f.        Pemeliharaan

4.       Ketika semua kebutuhan sistem dapat didefinisikan secara utuh , eksplisit, dan benar di awal project, maka software engineering dapat berjalan dengan baik dan tanpa masalah.Meskipun seering klai kebutuhan system tidak dapat didefinisikan seeksplisit yang diinginkan, tetapi paling tidak, problen pada kebutuhan system diawal project lebih ekonomis dalam hal uang (lebih murah), usaha, dan waktu yang terbuang lebih sedikit jika dibandingkan problem yang muncul pada tahap-tahap selanjutnya.

5.       Efisiensi waktu dan teknis kerja.

       Kelemahan dari metode waterfall

Kelemahan dari pada metode/model adalah perlu adanya informasi yang lengkap pada setiap tahapnya, dan bukan sesuatu hal yang mudah untuk mendapatkan informasi tersebut. Pada prakteknya, sering tidak mungkin untuk menulis dokumentasi kebutuhan yang lengkap sebelum dibangun prototipe. Sehingga yang terjadi adalah “kerja dua kali”, membuat prototipe, kemudian dari prototipe diperoleh informasi kebutuhan dan barulah dibangun sistem final.

Sebagai contoh tahap desain harus menunggu selesainya tahap sebelumnya yaitu tahap requirement. Secara umum tahapan pada model waterfall dapat dilihat pada gambar berikut :

Gambar di atas adalah tahapan umum dari model proses ini. Akan tetapi Roger S. Pressman memecah model ini menjadi 6 tahapan meskipun secara garis besar sama dengan tahapan-tahapan model waterfall pada umumnya. Berikut adalah penjelasan dari tahap-tahap yang dilakukan di dalam model ini menurut Pressman:

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