Sequence diagram

Sequence diagram/diagram sekuen menggambarkan kelakuan/perilaku objek pada use case dengan mendeskripsikan waktu hidup objek dan message yang dikirimkan dan diterima antar objek. Oleh karena itu untuk menggambar diagram sekuen maka harus diketahui objek-objek yang terlibat dalam sebuah use case beserta metode-metode yang dimiliki kelas yang diinstansiasi menjadi objek itu.

Banyaknya diagram sekuen yang harus digambar adalah sebanyak pendefinisian use case yang memiliki proses sendiri atau yang penting semua use case yang telah didefinisikan interaksi jalannya pesan sudah dicakup pada diagram sekuen sehingga semakin banyak use case yang didefinisikan maka diagram sekuen yang harus dibuat juga semakin banyak.

Berikut adalah simbol-simbol yang ada pada diagram sekuen:

Diagram Sekuen memiliki ciri yang berbeda dengan diagram interaksi pada Diagram Kolaborasi sebagai berikut :

1. Pada Diagram sekuen terdapat garis hidup objek. Garis hidup objek adalah garis tegas vertikal yang mencerminkan eksistensi sebuah objek sepanjang periode waktu. Sebagian besar objek-objek yang tercakup dalam diagram interaksi akan eksiss sepanjang durasi tertentu dari interaksi, sehingga objek-objek itu diletakkan di bagian atas diagram dengan garis hidup tergambar dari atas hingga bagian bawah diagram. Suatu objek lain dapat saja diciptakan, dalam hal ini garis hidup dimulai saat pesan Create diterima suatu objek. Selain itu suatu objek juga dapat dimusnahkan dengan pesan Destroy, jika kasus ini terjasi, maka garis hidupnya juga berakhir.

2. Terdapat fokus kendali (Focus of Control), berupa empat persegi panjang ramping dan tinggi yang menampilkan aksi suatu objek secara langsung atau sepanjang sub ordinat. Puncak dari empat persegi panjang adalah permulaan aksi, bagian dasar adalah akhir dari suatu aksi (dan dapat ditandai dengan pesan Return). Pada diagram ini mungkin juga memperlihatkan penyarangan (nesting) dan fokus kendali yang disebabkan oleh proses rekursif dengan menumpuk fokus kendali yang lain pada induknya.

Contoh Diagram Sekuen

Dalam kasus akademik yang memiliki program studi teknik informatika dan manajemen informatika, teridentifikasi aktor Mahasiswa dan Dosen, dengan daftar use casenya adalah :
1. Kontrak kuliah
2. Cari data
3. Tambah dt mhs
4. Edit data
5. Cek nilai
Misalkan diagram kelas hasil perancangan dari kasus akademik di atas adalah sebagai berikut :

Diagram kelas kasus contoh akademik universitas

Keterangan diagram kelasnya:

Program Studi: merupakan kelas proses yang diambil dari pendefinisian use case kontrak kuliah yang memiliki spesialisasi T Informatika dan Manajemen Informatika di dalamnya harus juga menangani proses cari data, cek nilai dan hapus data
Mahasiswa : merupakan kelas proses yang diambil dari pendefinisian use case tambah mahasiswa yang didalamnya juga menangani proses cari, hapus, dan list.
Matakuliah : merupakan kelas proses yang diambil dari pendefinisian use case cari data yang di dalamnya harus juga menangani proses edit, tambah, pilih, dan cek nilai

Berikut contoh diagram sequence nya

Diagram sekuen kasus contoh akademik universitas

State Chart Diagram

State chart diagram is one of the five UML diagrams used to model dynamic nature of a system. These define different states of an object during its lifetime. These states are changed by events. State chart diagrams are useful to model reactive systems. The Reactive systems can be defined as a system that responds to external or internal events.

State chart diagram describes the flow of control from one state to another state. The States are defined as a condition in which an object exists and it changes when some event is triggered. The most important purpose of State chart diagram is to model life time of an object from creation to termination.

State chart diagrams are also used for forward and reverse engineering of a system. The main purpose is to model reactive system.

Main usages of State chart diagrams are as follows:

• To model dynamic aspect of a system.
• To model the life time of reactive system.
• To describe the different states of object during its life time.
• Define state machine to model the states of an object.

How to draw State chart Diagram?

State chart diagram is used to describe the states of different objects in its life cycle. The emphasis is given on state changes upon some internal or external events. Such states of objects are important to analyze and implement them accurately.

State chart diagrams are very important for describing the states. The states can be identified as the condition of objects when a particular event occurs.

Before drawing the State chart diagram you must have clarified the following points:

• Identify the important objects which should be analyzed.
• Identify the states.
• Identify the events.

Following is example of State chart diagram where state of Order object is analyzed.

The first state is an idle state from where the process starts. Next states are arrived for events like send request, to confirm request, dispatch order. Such events are responsible for state changes of order object.

During the life cycle of an object (here order object) it goes through the following states and there may be some abnormal exists also. Abnormal exit may occur due to some problem in the system. The entire life cycle is complete then it is considered as the complete transaction as mentioned below.

Initial and the final state of an object is also shown below.

 

Where to use Statechart Diagrams?

From the above discussion we can define the practical applications of a Statechart diagram. The Statechart diagrams are used to model dynamic aspect of a system like other four diagrams disused in this tutorial. It has some distinguishing characteristics for modeling dynamic nature.

Statechart diagram defines the states of a component and these state changes are dynamic in nature. Its specific purpose is to define state changes triggered by events. The events are internal or external factors influencing the system.

Statechart diagrams are used to model states and also events operating on the system. To implement a system it is very important to clarify different states of an object during its life time and statechart diagrams are used for this purpose. These states and events are identified then they are used to model it and these models are used during implementation of the system.

If we look into the practical implementation of Statechart diagram then it is mainly used to analyze the object states influenced by events. Such analysis is helpful to understand the system behaviour during its execution.

So the main usages can be described as:

• To model object states of a system.
• To model reactive system. Reactive system consists of reactive objects.
• To identify the events responsible for the state changes.
• Forward and the reverse engineering.

With quick turnaround time, the site is providing solution to many complex issues with UML State chart Diagram. No matter what your degree or course is, just send the query along with the guidelines and you will get the response in very short time. By submitting after that just makes the payment and within promised time and you will get the solution in your mailbox. An added benefit is that assignments provided by the organizations are easy to understand and can be used for preparation of final exams and charges are very nominal.

Class Diagram

Class diagram adalah diagam yang digunakan untuk menampilkan beberapa kelas serta paket-paket yang ada dalam sistem/perangkat lunak yang sedang kita gunakan.
Class diagram memberi kita gambaran (diagram statis) tentang sistem/perangkat lunak dan relas-relasi yang ada didalamnya.

Definisi Class DiagramClass adalah kumpulan objek-objek dengan dan yang mempunyai struktur umum, behavior umum, relasi umum, dan semantic/kata yang umum. Class-class ditentukan/ditemukan dengan cara memeriksa objek-objek dalam sequence diagram dan collaboration diagram. Sebuah class digambarkan seperti sebuah bujur sangkar dengan tiga bagian ruangan. Class sebaiknya diberi nama menggunakan kata benda sesuai dengan domain/bagian/kelompoknya (Whitten L. Jeffery et al, 2004).

Class Diagram adalah diagram yang menunjukan class-class yang ada dari sebuah sistem dan hubungannya secara logika. Class diagram menggambarkan struktur statis dari sebuah sistem. Karena itu class diagram merupakan tulang punggung atau kekuatan dasar dari hampir setiap metode berorientasi objek termasuk UML (Henderi, 2008). Sementara menurut (Whitten L. Jeffery et al 2004:432) class diagram adalah gambar grafis mengenai struktur objek statis dari suatu sistem, menunjukan class-class objek yang menyusun sebuah sistem dan juga hubungan antara class objek tersebut.

Elemen-eleman class diagram dalam pemodelan UML terdiri dari: Class-class, struktur class, sifat class (class behavior), perkumpulan/gabungan (association), pengumpulan/kesatuan (agregation), ketergantungan (dependency), relasi-relasi turunannya, keberagaman dan indikator navigasi, dan role name (peranan/tugas nama).
Simbol-simbol class diagram
1. Class: Class adalah blok - blok pembangun pada pemrograman berorientasi obyek.Sebuah class digambarkan sebagai sebuah kotak yang terbagi atas 3 bagian. Bagian atas adalah bagian nama dari class. Bagian tengah mendefinisikan property/atribut class. Bagian akhir mendefinisikan methodmethod dari sebuah clas.


2. Association : Sebuah asosiasi merupakan sebuah relationship paling umum antara 2 class dan dilambangkan oleh sebuah garis yang menghubungkan antara 2 class. Garis ini bisa melambangkan tipe-tipe relationship dan juga dapat menampilkan hukum-hukum multiplisitas pada sebuah relationship.(Contoh: One-to-one, one-to-many,many-to-many).


3. Composition: Jika sebuah class tidak bisa berdiri sendiri dan harus merupakan bagian dari class yang lain, maka class tersebut memiliki relasi Composition terhadap class tempat dia bergantung tersebut. Sebuah relationship composition digambarkan sebagai garis dengan ujung berbentuk jajaran genjang berisi/solid.


4. Dependency : Kadangkala sebuah class menggunakan class yang lain. Hal ini disebut dependency. Umumnya penggunaan dependency digunakan untuk menunjukkan operasi pada suatu class yang menggunakan class yang lain. Sebuah dependency dilambangkan sebagai sebuah panah bertitik-titik. 


5. Aggregation : Aggregation mengindikasikan keseluruhan bagian relationship dan biasanya disebut sebagai relasi.





Keterangan:
• Class / table departemen memiliki ber-Agregasi dengan class / table pegawai,alasannya karena departemen dapat berdiri sendiri tanpa ada pegawai tetapi kinerjanya tidak sempurna. Banyak pegawai dapat bekerja pada satu departemen jadi many to 1.
• Class/table transaksi tidak dapat berdiri sendiri tanpa adanya class/table produk. Begitu juga dengan table produk tidak bisa berdiri sendiri tanpa adanya departemen.
• Banyak pelanggan dapat melakukan banyak tansaksi
• 1 transaksi dapat mencakup banyak produk.

 Penamaan kelas

Masing-masing kelas harus mempunyai nama yang unik. Sebagian besar organisasi mempunyai konvensi penamaan sendiri untuk menamakan kelas-kelas yang dibuatnya. Umumnya kelas-kelas dinamakan menggunakan kata benda tunggal.

Nama kelas tidak menggunkan spasi. Ini dilakukan karena alasan praktis, dimana beberapa bahasa pemrograman tidak membolehkan adanya spasi. Hal lainnya yang perlu diperhatikan adalah bahwa nama kelas hendaknya pendek, cukup untuk menjelaskan apa yang akan kelas lakukan.

Jadi penamaan kelas sangat tergantung pada organisasi kita. Jika kita mempunyai kelas yang digunakan dalam organisasi yang bersangkutan, tetapi yang jelas bahwa hal tersebut harus konsisten digunakan untuk keseluruhan kelas-kelas yang dibuatnya.

-          Visibilitas kelas

Pilihan visibilitas menentukan dapat tidaknya sebuah kelas dilihat dari luar paket. Ada 3 pilihan visibilitas untuk sebuah kelas yaitu :

1.      Public

2.      Menyatakan bahwa sebuah kelas dapat dilihat dari kelas-kelas lainnya dalam system.

3.      Protected atau private

4.      Menyatakan bahwa sebuah kelas dapat dilihat dari kelas-kelas majemuk(nested), friends, atau dari kelas itu sendiri.

5.      Package atau implementation.

6.      Menyatakan bahwa sebuah kelas dapat dilihat hanya oleh kelas yang lain dalam paket yang sama.

-          Multiplicity kelas

Multiplicity memberikan gambaran ebuah instant yang akan ditampung dalam kelas. Misalnya, dalam kelas pegawai, kita mungkin mempunyai beberapa instant, satu untuk Ani, satu untuk Ina, satu untuk Nana dan seterusnya. Sehingga Multiplicity untuk kelas pegawai diset n. Pada kelas control, Multiplicity diset 1, karena pada saat aplikasi berjalan hanya satu kelas.

Beberapa jenis Multiplicity kelas.

Table Multiplicity untuk kelas :

Multiplicity	Arti
n (default)	Banyak
0..0	Nol
0..1	Nol atau Satu
0..n	Nol atau Banyak
1..1	Tepat satu
1. .n	Satu atau banyak

Table Notasi Multiplicity menggunakan kustomisasi

Format	Arti
	Tepat
..	Antara
..	Atau nol
,
, ..	Tepat atau antara dan
.. , ..	Antara dan atau antara dan

-          Paket

Paket digunakan unruk mengelompokkan kelas-kelas yang mempunyai kesamaan. Dalam UML, digambarkan sebagai berikut :

Ada beberapa cara mengelompokkan kelas-kelas dalam paket, tetapi bagaimanapun juga,  kelas-kelas dapat dikelompokkan dalam paket yang sama tergantung dari keinginan kita sendiri. Salah satu pendekatan yang dapat digunakan adalah berdasarkan Stereotype-nya. Dengan pendekatan ini, dapat dibuat satu paket untuk kelas-kelas entitas, dan satu kelas untuk  kelas-kelas control.

Pendekatan lainnya yang dapat digunakan adalah dengan fungsionalitasnya. Misalnya, kita punya paket security untuk kelas-kelas yang digunakan menangani keamanan system.

Akhirnya, dapat digunakan kombinasi dua pendekatan diatas. Paket dapat dibuat bersarang, dimana satu paket mengandung paket lainnya. Pada level tertinggi, dapat dikelompokkan berdasarkan fungsionalitasnya, kemudian diikuti dengan sub fungsionalitasnya lainnya atau dengan stereotype-nya.

Interaction Diagrams

Interaction diagrams are models that describe how a group of objects collaborate in some behavior - typically a single use-case. The diagrams show a number of example objects and the messages that are passed between these objects within the use-case.
I'll illustrate the approach with the following simple use-case. In this behavior the order entry window sends a prepare message to an order. The order then sends prepare to each order line on the order. The order line first checks the stock item, and if the check returns true it removes stock from the stock item. If stock item falls below the reorder level it requests a new delivery.
Interaction diagrams come in two forms, both present in the UML. The first form is the sequence diagram. In this form objects are shown as vertical lines with the messages as horizontal lines between them. This form was first popularized by Jacobson. The diagram below shows this form in its UML notation. The sequence of messages is indicated by reading down the page.

Figure 1: A sequence diagram.
The second form of the interaction diagram is the collaboration diagram. Here the example objects are shown as icons. Again arrows indicate the messages sent in the use case. This time the sequence is indicated by a numbering scheme. Simple collaboration diagrams simply number the messages in sequence. More complex schemes use a decimal numbering approach to indicate if messages are sent as part of the implementation of another message. In addition a letter can be used to show concurrent threads.

Figure 2: A collaboration diagram.
One of the great strengths of an interaction diagram is its simplicity. It is difficult to write much about interaction diagrams because they are so simple. They do, however, have weaknesses, the principal one is that although they are good at describing behavior: they do not define it. They typically do not show all the iteration and control that is needed to give an computationally complete description. Various things have been done to try and remedy this. Jacobson uses pseudo-code in conjunction with sequence charts to provide a more executable model. Others have added various diagrammatic notations to increase the model's execuatability. Many of these are included in the UML.
I have mixed feelings about these trends towards greater executability. To me, the beauty of interaction diagrams is their simplicity, and much of these additional notations lose this in their drive to computational completeness. Thus I would encourage you not to rush to the more complex forms of interaction diagrams, you may find that the simpler ones give you the best value.

When to Use Them

Interaction diagrams should be used when you want to look at the behavior of several objects within a single use case. They are good at showing the collaborations between the objects, they are not so good at precise definition of the behavior.
If you want to look at the behavior of a single object across many use-cases, use a state transition diagram. If you want to look at behavior across many use cases or many threads, consider an activity diagram.

Activity diagram

Activity diagram adalah representasi grafis dari workflow dari kegiatan dan tindakan bertahap  dengan dukungan untuk pilihan, iterasi dan concurrency. Dalam Unified Modeling Language , diagram aktivitas dimaksudkan untuk model kedua proses komputasi dan organisasi (yaitu workflow). Activity diagram menunjukkan aliran keseluruhan kontrol. 
Activity diagram dibangun dari sejumlah bentuk, dihubungkan dengan panah. Jenis Bentuk yang paling penting: 

• persegi panjang bulat merupakan tindakan;
• berlian merupakan keputusan;
• bar mewakili awal (split) atau akhir (bergabung) kegiatan bersamaan;
• lingkaran hitam merupakan awal (initial state) dari alur kerja;
• lingkaran hitam dikelilingi mewakili akhir (keadaan akhir).

Panah dijalankan dari awal menuju akhir dan merupakan urutan kegiatan terjadi. 
Oleh karena itu mereka dapat dianggap sebagai bentuk flowchart . Teknik flowchart Khas kekurangan konstruksi untuk mengekspresikan concurrency . Namun, bergabung dan simbol perpecahan dalam diagram aktivitas hanya menyelesaikan ini untuk kasus-kasus sederhana, makna dari model tersebut adalah tidak jelas kapan mereka sewenang-wenang dikombinasikan dengan keputusan atau loop.

  
Sementara di UML 1.x, diagram aktivitas adalah bentuk khusus dari diagram negara, di UML 2.x, diagram aktivitas yang reformalized harus didasarkan pada Petri net -seperti semantik, meningkatkan cakupan situasi yang dapat dimodelkan menggunakan diagram aktivitas. Perubahan ini menyebabkan banyak UML diagram aktivitas 1.x untuk ditafsirkan berbeda dalam UML 2.x

Simbol Activity Diagram 

Simbol Activity Diagram

Use Case Diagram

 Use Case merupakan sebuah komponen wajib dalam program, dengan adanya use case pengguna dapat melihat gambaran dari kegunaan aplikasi tersebut.

 Pengertian Use Case

Use case diagram adalah suatu model yang dangat fungsional dalam sebuah sistem yang menggunakan actor dan use case. Sedangkan pengertian dari use case sendiri adalah layanan atau fungsi-fungsi yang tersedia pada sistem untuk penggunannya.

Use case diagram menggambarkan efek fungsionalitas yang telah diharapkan oleh sistem.  Use case diagram dapat sangat membantu bila kita sedang menyusun requitment sebuah sistem, mengkomunikasikan sebuah rancangan aplikasi dengan konsumen, serta merancang test case untuk semua feature yang ada pada sistem. aturannya, sebuah use case dapat di masukan lebih dari use case lain, sehingga duplikasi fungsionalitas dapat dihindaro dengan cara menarik keluar fungsional yang common.

Deskripsi Use Case Diagram

1. Sebuah use case merupakan dimana sebuah sistem dapat digunakan untuk memenuhi satu atau lebih kebutuhan dari pemakai.

2. Use case sendiri merupakan fase awal yang sangat tepat untuk setiap fase pengen\mbangan sistem berbasis objek, design testing, dan dokumentasi.

3. Use case sendiri menggambarkan kebutuhan sistem sendiri dilihat dari sudut pandang diluar sistem.

4. Use case sendiri menentukan nilai yang diberikan sistem kepada pemakai.

5. Use case hanya menetapkan apa seharusnya yang dikerjakan oleh sisy\tem, yaitu menyangkut dengan kebutuhan fungsional sistem.

6. Use case sendiri tidak menen tukan dengan kebutuhan nonfungsional. Dimaksut dengan kebutuhan nonfungsional misal bahasa pemrograman, sasaran kerja dan lain sebagainya.

Macam komponen-komponen use case diagram

1. Actor

Sebenernya Actor bukanlah bagiandari diagram, namun untuk dapat terciptanya suatu use case diagram diberikan beberapa actor dimana actor tersebut menjelaskan seseorang atau sesuatu (sperti perangkat, system lain) yang berinteraksi dengan system. Sebuah actor mungkin hanya memberikan informasi inputan pada system, hanya menerima informasi dari system atau keduanya menerima dan member informasi pada system, actor hanya berinteraksi dengan use case tetapi tidak memiliki control atas use case. Actor digambarkan secara umum atau spesifik, dimana untuk membedakannya anda dapat menggunakan relationship.

Ada beberapa kemungkinan yang menyebabkan actor tersebut terkait dengan system antara lain :

1. Yang berkepentingan terhadap system dimana adanya arus informasi baik yang diterima maupun yang dia inputkan ke system.  
2. Orang ataupun pihak yang akan mengelola system tersebut. 
3. External resource yang digunaka oleh system
4. System lain yang berinteraksi dengan system yang akan dibuat

2. Use Case

Use case merupakan gambaran fungsional dari suatu sistem, sehingga antara konsumen dan pengguna sistem paham dan mengerti mengenai kegunaan sistem yang akan dibangun.

Relasi dalam Use Case

Berikut adalah relasi dalam use case dan kegunaannya :

Assoclation = hubungan link antar element-element.

Generalization atau biasa disebut dengan inheritance (pewarisan), adalah sebuah elemen yang merupakan spesifikasi dari elemen lainnya

Dependency merupakan elemen tergantung dari beberapa cara kepada elemen-elemen lainnya.

Aggregation adalah bentuk asosiation dimana sebuah elemen berisi elemen lainnya.

Contoh Use Case Diagram

Berdasarkan kasus diatas, maka dapat dijabarkan dalam suatu pemodelan Use case. Model use case ini terdiri dari aktor dan kasus penggunaan. Aktor mewakili pengguna sistem yang berinteraksi dengan sistem tersebut. Penggunaan use case ini mewakili perilaku dari sistem, skenario bahwa sistem berjalan melalui tanggapan dari seorang aktor. Use case pada kasus pemanfaatan sistem pakar seleksi karyawan menggunakan metode Tsukamoto sesuai dengan gambar.

Pada use case diatas, maka dapat mendeskripsikan hal-hal sebagai berikut ini:

1. Admin dan User merupakan aktor.

2. Admin dan User melakukan login pada aplikasi sistem pakar seleksi karyawan menggunakan metode Tsukamoto.

3. Admin dan User melakukan pemasukan data pada aplikasi sistem pakar seleksi karyawan menggunakan metode Tsukamoto.

4. Admin dan User melihat data yang telah dimasukkan.

5. Admin dapat melakukan pengubahan range nilai.