Sequence Diagram

Sequence Diagram

Sequence Diagram adalah salah satu diagram UML yang digunakan pada tahap mendesain sistem yang akan dikerjakan. Hampir sama dengan Communication Diagram, Sequence Diagram berguna untuk menunjukan interaksi - interaksi terhadap object class yang ada didalam sistem. Yang membedakan dengan , Communication Diagram adalah, Communication Diagram menunjukan bagaimana urutan atau alur dari proses sistem untuk mencapai tujuan, Sedangkan Sequence Diagram menunjukan .
alur hidup object dari mulai object dieksekusi sampai berhenti

Gambar 1 : Contoh Sequence Diagram
Sequence Diagram biasanya mewakili satu buah use case dalam use case diagram. Sehingga, sebuah use case dapat dibuat Sequence Diagramnya dan kadang kala juga terdapat aktor didalam Sequence Diagram seperti gambar diatas.

Komponen Penyusun Sequence Diagram.

Adapun komponen penyusun dari sequence diagram adalah sebagai berikut :
  • Actor
Komponen ini hampir serupa dengan Actor yang ada pada use case yaitu komponen yang mewakili user yang menggunakan sistem atau sistem luar yang menggunakan sistem.
Gambar 2 : Actor


  • Lifeline
Lifeline merupakan interpretasi dari sebuah entitas yang ada didalam sistem. Entitas ini bisa berupa objek class atau class. Actor sendiri juga merupakan lifeline dimana actor merupakan lifeline yang berada diluar dari sistem. Lifeline pada umumnya digambargan dengan persegi panjang dengan garis kebawah yang menggambarkan waktu eksekusi. Penamaan untuk entitas objek yaitu :<nama object>:<nama kelas>  sedangkan untuk entitask kelas yaitu  : :<nama kelas>
Gambar 4 : Lifeline berupa kelas

Gambar 3 : Lifeline berupa Objek



  • Message
Message merupakan sebuah event dimana lifeline mengirim atau menerima sesuatu dari lifeline lainnya. Messge biasanya berupa fungsi dari objek. Message digambargan dengan anak panah. Untuk message yang memberikan kembalian, digambarkan dengan anak panah putus - putus.

Gambar 4 : Contoh Message

Gambar 5: Contoh message yang memberikan kembalian



  • Activation box
Merupakan komponen persegi panjang kebawah yang menunjukan lamanya sebuah lifeline berinteraksi dengan lifeline lain. Message keluar dan masuk melalui Activation box. Lamanya lifeline berinteraksi dilihat dari panjangnya activation box. Semakin panjang, semakin lama waktu yang diperlukan suatu lifeline untuk berinteraksi dengan lifeline lain. Dalam bahasa lainnya juga ddisebut execution.

  • Create Message
Merupakan Message yang bertujuan untuk membuat sebuah lifeline (object) baru. Dalam pemrograman diinterpretasikan sebagai insert data.
Gambar 6 : Create Message

  •  Destroy Message

Merupakan Message yang bertujuan untuk menghapus sebuah lifeline (object). Dalam pemrograman diinterpretasikan sebagai delete data. Pada proses delete, pada bagian paling bawah lifeline yang akan dihapus diberikan tanda silang sebagai tanda bahwa lifeline sudah dihapus.

Gambar 7 : Destroy Message

  • Alternative
Berguna memberikan pilihan atau alternative pilihan message mana yang akan dijalankan. Bentuknya seperti operasi kondisional pada bahasa pemrograman. Penggunaannya sendiri adalah dengan membagi daerah menjadi beberapa bagian dan diberi penjelasan untuk tiap - tiap kondisi yang harus dipenuhi agar message dapat dijalankan. (untuk lebih jelasnya lihat gambar 8).
Gambar 8 : Alternative Operator

  • Loop
Berguna untuk melakukan pengulangan eksekusi message. Bentuknya seperti operasi "while" pada bahasa pemrograman. Penggunaannya sendiri adalah dengan membuat daerah yang akan menjalankan operasi loop, disertai dengan keterangan kondisi pengulangannya. Pada contoh gambar 9, operasi diulangi sebanyak 10 kali.
Gambar 9 : Loop operator

Referensi : 

https://www.uml-diagrams.org/sequence-diagrams.html

https://www.uml-diagrams.org/sequence-diagrams-combined-fragment.html

https://www.uml-diagrams.org/interaction-message.html

https://ratnokustiawan.wordpress.com/2011/01/06/sequence-diagram/

Collaboration Diagram

Communication Diagram/Interaction Diagram

Communication Diagram atau Collaboration Diagram atau disebut juga Interacton Diagram adalah salah satu diagram UML yang digunakan pada tahap mendesain sistem yang akan dikerjakan sesuai kebutuhan user. Tujuan dari Communication Diagram adalah untuk menunjukan interaksi - interaksi terhadap object class yang ada didalam sistem. Selain menunjukan interaksi - interaksi setiap object class yang ada didalam sistem, Communication Diagram juga menunjukan bagaimana urutan atau alur dari proses sistem untuk mencapai tujuan.
Gambar 1 : Collaboration diagram



Didalam Collaboration Diagram terdapat lifeline yang merupakan user/sistem lain sampai kepada tujuan (head).

masing - masing object saling berinteraksi menggunakan message yang merupakan fungsi dari kelas yang berinteraksi serta terdapat garis panah yang menunjukan arah interaksi object.


Gambar 2 : message dan arah interaksi

angka yang terdapat disamping message merupakan penanda tugas yang dikerjakan. masing - masing tugas tersebut memiliki urutan atau step - step yang menunjukan langkah - langkah untuk mencapai tujuan. Misal dari angka 1 ke 1.1, 1.2, 1.3 dst atau dari angka 2, 2.1, 2.2, 2.3.

Guard

Guard pada Collaboration diagram merupakan kondisi dimana sebuah message pada object dijalankan. Penulisan guard adalah dengan menuliskan kondisi yang membuat message dijalankan didalam kurung bracket.

Contoh penulisan : [batal beli] -> menunjukan bahwa message akan dijalakan jika user batal membeli barang.

Contoh penggunaan guard dapat dilihat pada gambar 1. ketika user sudah melakukan pencarian di inventory, maka user melakukan pencarian buku (find_book) maka yang akan dilakukan user jika tertarik dengan buku tersebut ([interested]) maka user akan melihat buku. (Ingat urutan tugas pada penomoran message. dari 1 ke 1.1 lalu ke 1.2 dan ke 1.3). jika user memutuskan untuk membeli ([decide to buy]) maka user akan memasukan buku ke dalam shoping chart.

Gambar 3 : Penggunaan Guard

Iteration

Terkadang, pemanggilan fungsi pada object dapat dilakukan secara berulang kali. Pada Collaboration Diagram memungkinkan untuk memodelkan pemanggilan fungsi secara berulang. Message atau fungsi yang dapat dipanggil berulang ditandai dengan tanda "*" di awal nama message.

Batas pengulangan message tidak ditentukan. Bila memang ditentukan, biasanya dituliskan dengan pseudo-code atau bahasa pemrograman. Contoh : *[k=1..12] print_message(). berarti message atau fungsi print_message() diulang sebanyak 12 kali.

Gambar 4 : pengulangan menggunakan pseudo code. pengulangan sebanyak n -kali


Contoh pada gambar 1 menunjukan bahwa message pencarian buku (find_books) dapat dilakukan berulang kali.

 Sumber referensi :
https://www.slideshare.net/ramakantsoni/lecture-7-collaboration-diagram

http://agilemodeling.com/style/collaborationDiagram.htm

http://www.agilemodeling.com/artifacts/communicationDiagram.htm

https://www.slideshare.net/fahad_uaar/collaboration-diagram

https://www.slideshare.net/ASHOKKUMARPALAKI/lecture-6-collaboration-diagrams 

http://slideplayer.com/slide/7117097/

https://www.uml-diagrams.org/communication-diagrams.html

Activity Diagram

Mengenal Activity Diagram

Activity Diagram adalah salah satu diagram yang ada pada UML yang menggambarkan langkah - langkah aktifitas yang dilakukan oleh user dan menunjukan kapan user harus melakukan aktifitas tersebut.

Activity Diagram berada 1 level di atas use case diagram. Artinya, activity diagram menjeleskan bagaimana use case berjalan dan aktivitasnya.

Contoh Activity Diagram

Komponen Pada Activity Diagram

Komponen pada activity diagram


Pada pembuatan dan perancangan activity diagram, ada beberapa komponen yang diperlukan. Adapun beberapa komponen dasar yang digunakan adalah :

  • Start point/initial node : Pada titik ini, aktivitas dimulai
  • Action/Activity : Komponen ini menggambarkan aktivitas/aksi yang berjalan. Actifity dituliskan oleh kata aktif.
  • End point/activity final : Titik dimana aktifitas selesai dikerjakan.
Simbol komponen Activity Diagram.

  • Decision : berfungsi untuk melakukan percabangan dengan syarat kondisi tertentu yang harus terpenuhi. Dalam decision, cabang yang dihasilkan boleh lebih dari dua kondisi. Pada decision, kondisi yang harus terpenuhi dituliskan pada garis yang keluar dari decision.
  • Decision pun dapat digunakan untuk melakukan perulangan. (Seperti do-while).
Penggunaan decision sebagai perulangan.

  • Fork dan Join : Fork dan join digunakan untuk aktifitas yang berjalan bersamaan (concurrent activity).

Concurrent Activity (Aktifitas Yang Berjalan Bersamaan)

Dalam sebuah aktifitas didalam sistem, biasanya ada aktifitas yang berjalan secara beramaan. Contohnya adalah pada sistem makanan cepat saji. Ketika customer memesan makanan, maka aktifitas membuat makanan dan minuman dilakukan secara bersamaan. Pada kondisi tersebut, maka pada activity diagram digambarkan dengan komponen fork dan join.

Fork dan join
Fork dan join berbeda dengan decision meskipun sama - sama melakukan percabangan. Pada decision, aktifitas yang dijalankan adalah yang memenuhi syarat dari decision yang ditentukan. Sedangkan pada fork dan join, aktifitas dijalankan secarah bersamaan.

ada beberapa ketentuan dan syarat pada penggunaan Fork dan Join :

  • Jumlah garis keluar yang keluar dari fork harus sama dengan garis yang masuk kedalam join dalam satu concurrent activity.
  • tidak boleh ada activity yang masuk ke dalam join yang tidak berasial dari fork dalam satu concurrent activity.
  • tidak boleh ada deretan activity yang berasal dari fork yang tidak masuk kedalam join dalam satu concurrent activity.

Swimlane

Dalam sebuah urutan/rangkaian aktivitas didalam sistem, kebanyakan melibatkan lebih dari satu aktor/user. Untuk memisahkan aktivitas - aktivitas berdasarkan aktor/user yang bertanggung jawab maka harus dibuat swimlane untuk memisahkan activity berdasarkan user.

Swimlane berbentuk seperti tabel dimana setiap activity untuk tiap - tiap actor/user dipisahkan oleh kolom.

Pembagian activity berdasarkan actor/user menggunakan swimlane




UML Uses Case Diagram (Pertemuan 2 Bag.2)

Uses Case Diagram

Contoh Use Case diagram

Setelah memahami Tentang UML, maka sekarang akan dibahas salah satu diagram yang digunakan dalam UML. Yaitu Uses case diagram.

Seperti yang sudah dijelaskan pada bagian pertama, uses case diagram adalah model diagram UML untuk mengilustrasikan hubungan antara system dengan user. Dengan kata lain, use case diagram menunjukan "siapa" dan "apa" yang dilakukan pada sistem yang akan dibuat.

Keuntungan Use Case

Use case ringkas, sederhana, dan dipahami oleh berbagai pihak. Sehingga, desainer sistem dan stakeholder dapat memahami sistem yang sedang dibuat.
Selain itu, Use case mengatur sejumlah aktivitas dalam process yaitu : Pembuatan dan validasi model desain, perencanaan iterasi, pembuatan dokumentasi bagi pengguna dan Sistem deployment.
Use case juga membantu sinkronisasi isi model yang berbeda.

Komponen - komponen dasar pada use case

Dalam diagram use case, terdapat 2 komponen dasar yang menyusunnya. Yaitu :

  • Actor

    Actor merupakan komponen yang berada diluar sistem. Actor adalah user yang menggunakan sistem atau  orang/komponen yang berinteraksi dengan sistem. Actor digambarkan dengan stickman (ilustrasi orang - orangan).
    Komponen Actor
  • Use Case

    Use case merupakan gambaran model dari aktivitas/aksi yang ada didalam sistem yang dibuat. Komponen use case dapat menunjukan aktivitas - aktivitas apa saja yang terjadi didalam sistem yang dibuat dan secara tidak langsung dapat menunjukan tujuan dari sistem yang dibuat. Use case adalah gambaran sistem dari sudut pandang pengguna (Actor) sehingga biasanya use case merupakan kegiatan - kegiatan atau aktivitas - aktivitas yang dikerjakan oleh user (Actor) walaupun terkadang use case juga dapat merupakan "apa" yang dikerjakan oleh bagian dari sistem. Use case digambarkan berbentuk oval.
    Komponen Use case
Kedua komponen tersebut nantinya akan saling berhubungan didalam sistem. Hubungan - hubungan dari kedu akomponen tersebutlah yang nantinya akan menggambarkan bagaimana sebuah sistem berinteraksi. Selain itu, ada beberapa jenis komponen lagi yang terdapat dalam use case diagram.

Komponen pada Use Case Diagram

Dependency (Jenis - jenis hubungan antar use case)

Ada beberapa aturan dan jenis - jenis hubungan dalam masing - masing komponen dalam use case diagram.
  • Actor setidak - tidaknya harus terhubung minimal dengan 1 use case
  • Actor bisa terhubung dengan lebih dari 1 use case
  • Use case bisa terhubung lebih dari 1 Actor 
Contoh Hubungan Komponen pada Use Case Diagram
  • Terdapat 1 hubungan yang disebut Generalization. dala generalization, semua komponen yang terhubung dengan komponen induknya juga dimiliki oleh komponen turunannya. Komponen turunan juga dapat terhubung dengan komponen/use case yang lain.
Generalization pada aktor
  • Selain generalization, terdapat 1 hubungan lagi yang hanya terdapat pada komponen use case yaitu extend. dalam hubungan extend terdapat dua use case yaitu extended (arah panah "dari") dan extending (arah panah "ke"). Dalam kasus extend, use case extended mendapatkan tambahan use case extending.Use case extending tidak selalu harus ada dan terhubung pada use case extended (biasanya terdapat syarat - syarat khusus agar use case extending dapat digunakan bersamaan dengan use case extended). Dengan kata lain, use case yang terhubung boleh dieksekusi, boleh tidak. Contohnya pada use case diagram dibawah, ketika customer melihat barang, maka customer dapat memesan barang.
  • Setelah extend, terdapat lagi yang namanya include. Berbeda dengan extend, pada kasus include, included (arah panah "ke") adalah use case yang wajib ada untuk melengkapi including (arah panah "dari"). Contohnya pada use case diagram dibawah adalah, ketika aktor admin ingin mengakses/melakukan use case isi data barang, maka admin harus melakukan use case Login
Contoh penggunaan extend dan include
 Untuk lebih jelasnya, dapat kunjungi link dibawah ini.

http://creately.com/blog/diagrams/use-case-diagram-tutorial/
http://creately.com/blog/diagrams/use-case-diagram-relationships/
http://creately.com/blog/diagrams/use-case-diagram-guidelines/

RUP dan UML (Pertemuan 2 Bag.1)

RUP (Rational Unified Process)

Rational Unified Process (RUP) adalah proses perekayasaan perangkat lunak yang memfokuskan pada analisa kebutuhan dan desain.RUP dibuat oleh Rational Software, salah satu divisi yang ada pada IBM sejak tahun 2003. RUP ditujukan untuk menjamin kualitas perangkat lunak yang dikembangkan agar memenuhi kebutuhan user. RUP juga merupakan kerangka proses yang dapat diadaptasi dan diperluas untuk memenuhi kebutuhan organisasi.

RUP juga merupakan pengembangan perangkat lunak yang berulang (iterative) sehingga, setiap fase terdapat proses pengulangan.

Sejarah

Adapun sejarah perkembangan RUP adalah :
  • Rational Machines (Paul Levy dan Mike Devlin, 1981)
Menyediakan Tools untuk pengembangan software engineering Terintegrasi dengan ADA Programming Laguage
  • Grady Booch
Object Oriented Design (OOD)
  • Oktober 1994 : James Rumbough
Object MOdeling TEchnique (OMT)
  • Musim gugur 1995 : Ivar Jacobson
Object Oriented Software Engineering (OOSE)
  • Rational Machines
  • 20 Februari 2003 Rational Machines dijual ke IBM seharga US$2.1 billion
Dalam menjalankan prosesnya, RUP dibagi menjadi 2 dimensi proses yaitu waktu (Sumbu Y) yang berisikan pembagian fase dan iterasi pada tiap - tiap siklus dan komponen proses (Sumbu X) yang berisi langkah - langkah proses



Setiap fase dapat berisi beberapa iterasi sampai target kebutuhan fase tersebut terpenuhi atau tercapai.

Fase - fase pada RUP

pada pelaksanaannya, didalam RUP terdapat 4 fase yaitu :
  1. Inception

    menetapkan visi / tujuan project. Pada bagian ini ditentukan bagaimana model bisnis yang akan dijalankan. Selain itu juga ditetapkan batasan - batasan pada sistem yang akan dikerjakan. Pada fase ini pulalah kebutuhan - kebutuhan (requirements) user sudah didapatkan.
  2. Elaboration

    Merencanakan aktivitas dan resource yang dibutuhkan dan menentukan fitur - fitur dan desain arsitektur. Pada fase ini, desain rancangan sistem mulai dibentuk. Pada fase ini pula arsitektur sistem diputuskan dan resiko - resiko sudah mulai dikurangi atau dicari solusinya.
  3. Construction

    Mulai membangun software. Pada fase ini, pembuatan program mulai dilaksanakan. proses testing software pun dilaksanakan pada bagian ini.
  4. Transition

    Memsuplay produk software yang telah dibuat kepada komunitas user. Pada fase ini, dimulai pemasangan perangkat lunak dan training atau pelatihan kepada user - user yang menggunakan sistem yang dibuat

Proses aktivitas pada RUP

Pada pengerjaannya, inti dari alur aktivitas proses dibagi menjadi 6 bagian. Yaitu :
  • Business Modeling

    mengidentifikasi kemampuan sistem yang akan dibuat dan keinginan user. Pada tahap ini dicari tahu bagaimana model bisnis yang akan dibuat. Pada tahap ini wawancara dan observasi terhadap proses bisnis dilakukan.
  • Requirement

    Sebuah narasi tujuan bersama tentang kebutuhan fungsional dan kebutuhan non fungsional.
  • Analysis and Design

    Gambaran tentang bagaimana sistem akan dibuat pada tahap implementasi.
  • Implementation

    Proses coding dengan hasip berupa exe.
  • Test

    Verifikasi sistem secara menyeluruh.
  • Deployment

    Meliputi pemasangan sistem dan training user.

Untuk penjelasan lebih lengkap mengenai RUP, Dapat dilihat di Rational Software White Paper Milik IBM.

Sequence Diagram

Sequence Diagram Sequence Diagram adalah salah satu diagram UML yang digunakan pada tahap mendesain sistem yang akan dikerjakan. Hampir ...