Diagram UML

Diagram UML

Terdiri dari 13 diagram yang di kelompokan dalam 3 katagori macam- macam diagram:

• Structure diagram  yaitu kumpulan diagram yang di gunnakan untuk menggambar suatu trstruktur statis dari system yang di modelkan.
• Behaviore diagram yaitu kumpulan diagram yang digunakkan untuk menggambar kelakuan system atau rangkaian perubahan yang terjadi pada sebuah system.
• Intraction diagram yaitukumpulan diagram yang di gunakan untuk menggambar interaksi system  antara subsistem pada suatu system
• Class diagram Menggambarkan struktur system dari segi pendefinisian kelas2 yang akan di buat untuk membangun system
• Attribute merupakan variable-variabe yang di miliki oleh suatu kelas
• Operasi atau metode merupakan fungsi- fungsi yang dimiliki pada suatu kelas.

Jenis –jenis kelas berikut :

·         Kelas main

kelas yang memiliki fungsi awal eksekusi ketika system di jalankan.

·         Kelas yang menangani tampilan system

Kelas yang mendifinisikan kelas dan mengatur tampilan ke pemakai.

·         Kelas yang di ambil dari pendefinisian use case (controller)

Kelas yang menagnggani fungsi-fungsi yang harus ada diambil dari pendifinisian use case

·         Kelas yang di ambil dari pendifinisian data (model).

Kelas yang diggunakkan untuk memeggang atau membungkus data menjadi sebuah kesatuan yang diambil maupun akan disimpan  ke basis data.

Objek diagram.

Diagram objek menggambarkan struktur system dari segi penamaan objek dan jalannya objek dalam system.

Component diagram.

Component diagram dibuat untuk menunjukan.organisasi dan ketergantungan diantara kumpulan-kumpulan komponen dalam sebuah system. Diagram komponen juga dapat memodelkan hal-hal berikut :

·         Soarce code program perangkat lunak

·         Komponen executeable yang di lepas ke user

·         Basis data secara fisik

·         System yang harus beradaptasi oleh sistem lainnya

·         Framework system framework pada perangkat lunak merupakan kerangka kerja yang dibuat untuk memudahkanpengembangan dan pemeliharaan  aplikasi.

Composite structure diagram

Diagram ini dapat di gunakan untuk menggambar struktur dari bagian-bagian yang saling terhubung maupun mendeskripsikan struktur pada saat berjalan runtime dari instance yang saling terhubung.

Peckage diagram

Menyediakan cara mengumpulkan elemen-elemen yang saling terkait dalam diagram UML.

Deployment diagram

Menunjukan konfigurasi komponen dalam proses eksekusi aplikasi

Use Case Diagram

Use case atau diagram use case merupakan pemodelan untuk kelakuan (Behavior) system informasi yang akan dibuat . Use Case mediskripsikan sebuah interaksi antara satu atau lebih actor dengan system informasi yang akan dibuat.

Use case yaitu pendefinisian apa yang di sebut actor  dan use case.

•    Actor merupakan orang ,proses atau system lain yang berinteraksi dengan system informasi yang akan di buat di luar system informasi
•    Use case merupakan fungsionalitas yang disediakan system sebagai unit unit yang saling bertukar pesan antara unit atau actor.

Activity Diagram

Diagram activity atau activity diagram menggambarkan workflow (aliran kerja) atau activitas dari sebuah system atau proses bisnis atau menu yang ada pada perangkat lunak.

Diagram aktivtas juga banyak digunakan untuk mengidentifikasikan hal-hal berikut:

• ·      Rancangan proses bisnis dimana setiap urutan aktivitas yang digambarkan merupakan proses bisnis system yang di identivikasikan.
• ·      Urutan untuk mengkelompokan  tampilan dari system /user interface dimana setiap activitas dianggap memiliki sebuah rancangan antarmuka tampilan.
• ·      Rancangan penguji dimana setiap aktivitas dianggap memerlukan sebuah pengujian yang di perlukan definisikan khusus ujinya.
• ·      Rancangan menu yang di tampilkan pada perangkat lunak.

Sequence Diagram

Diagram sequence menggambarkan kelakuan objek pada use case dengan mendeskripsikan waktu hidup objek dan message yang dikirimkan dan diterima antar objek.

Communicatian diagram

Diagram komunikasi menggambarkan interaksi antar objek /bagian dalam bentuk urutan pengiriman pesan.

Timing diagram.

Timing diagram merupakan diagram yang focus pada penggambaran terkait batasan waktu.

Interaction Overview Diagram

Diagram aktivitas yang berfungsi untuk menggambarkan sekempulan urutan aktivitas. Pada interaction diagram adalah interaction occurrence dan interaction element.

1.      Interaction Occurrence

Interaction occurance atau kejadian interaksi adalah referensi untuk diagram interaksi yang ada.

2.      Interaction Element

Interaction element atau elemen interaksi mirip interaction occurrence. Perbedaannya element ini menampilkan isi diagram yang direferensikan langsung.

Design pettern

Design pettern adalah suatu bagian dari teknologi pemograman berorientasi objek.pola disain adalah solusi yang sudah teruji (best practice) untuk menyelesaikan permasalahan pemograman.

Cara membuat pola sebuah disain komponen yang baik adalah dengan memperhatikan kemungkinan perubahan system yang mungkin terjadi dimasa mendatang 

Anti pettern

Anti pettern merupakan pola yang dihasilkan dari penelusuran solusi-solusi yang buruk yang pernah digunakan untuk mencari solusi yang baik. Anti pettern lebih kepada mengambil pelajaran pada kegagalan-kegagalan yang pernah dialami sebelumya dan bagaimana cara memperbaikinya.

Berikut adalah contoh-contoh kesalahan yang digunakan untuk memperbaiki pola pemograman

Berorientasi objek:

1.      Spaghetti code (kode spageti)

Banyak kode program yang tidak efisien dan diulang-ulang biasanya terjadi karena programmer membuat program dengan asal jalan tanpa memahami konsep pemograman itu sendiri

Penyebabnya terjadi spaghetti code:

·         Lone ranger programmer (pembuatan program solo, tanpa tim)

·         Dokumentasi kuno dan tak lengkap

·         Melibatatkan pembuatan program yang sering ragu-ragu

Cara memperbaikinya (Refactoring)

Memiah-miah fungsi yang digunnakan ke dalam sub kelas atau membuat super kelas untuk memilih kode.

2.      Stovepipe system (system pipa computer)

Keterkaitan klass yang tidak jelas ,sehingga ada beberapa kelas yang sebenarnya secara implesit melakukan fungsi yang sama.

Penyebab terjadinya Stovepipe system:

·         Impelemntasi kode program tidak sesuai dengan dokumentasi

·         Analisis yang tidak terbiasa dengan integrasi dan aspek-aspek kunci dan pembuatan perangkat lunak.

Cara memperbaiki (Refactoring).

 Mengelompokkan fungsi-fungsi pada kelas menggunakan antarmuka dengan memperhatikan keterkaitan antar kelas.

3.      Analisi paralyisis

Memperlihatkan ketidak seiimbangan upaya pada fase analisis dari sebuah proyek.

Penyebab analysis paralysis :

·         Koordinasi tim analisis yang tidak baik

·         Pemaksaan penyelesaian analiysis sebelum proses disain

·         Terpaku pada paradigm baru dan sudut pandang yang berbeda-beda.

Cara memperbaikinya (refactoring):

·         Tidak menggunakan banyak analsi

·         Memperkerjakan arsitek perangkat lunak yang professional

·         Menyediakan prototype untuk analisis