DOMAIN MODELLING

UML (Unified Modeling Language) adalah sebuah "bahasa" yg telah menjadi standar dalam industri untuk visualisasi, merancang dan mendokumentasikan sistem piranti lunak. UML menawarkan sebuah standar untuk merancang model sebuah sistem.

¢  Dalam pengembangan software berbasis Object-Oriented pasti sering terjadi adanya masalah-masalah.

¢  Pemecahan masalah utama dari Object Oriented biasanya dengan penggambaran dalam bentuk model (Domain Modelling).

¢  Oleh karena itu orang-orang yang berminat dalam mempelajari UML harus mengetahui dasar-dasar mengenai Object Oriented Solving. 

Memahami istilah dalam OOP / PBO

¢  Obyek : komponen di dalam sebuah program

¢  Property : karakteristik yang dimiliki obyek

¢  Method : aksi yang dapat dilakukan oleh obyek

¢  Event : kejadian yang dapat di alami oleh obyek

Tahapan Pembuatan Model Domain

¢  Pada tahap ini jangan dipikir terlalu dalam hal2 terkait atribut-atributnya. fokus saja pada objek utama

¢  Cukup ada ”generalization (is a)” dan “aggregation (has a)” relationship

¢  Lakukan dalam waktu yang terbatas, karena domain model belumlah final, bisa berubah sesuai tahapan saat proses pemodelan berlangsung

¢  Domain model berbeda dengan data model, jangan terjebak pada aliran data.

3+1 Komponen Utama Model Domain

¢  Domain Classes - Setiap Kelas Domain menunjukkan jenis obyek

¢  Attributes - Entitas

¢  Associations - Relasi antara dua buah kelas domain atau lebih.

¢  Additional Rules - Aturan kompleks yang tidak dapat ditampilkan dengan simbologi maka ditampilkan dengan catatan terlampir.

KONSEP OOP DAN ADBO

Konsep OOP (dasar)

o  Class : cetakan object

o  Object : instance object

o  Instance variabel : atribut object       

o  Method :  perilaku object

o  Constructor : inisialisasi object

CLASS dibuat untuk menciptakan OBJECT

Contoh : 

o  Buat class Mhs

Instance variabel : npm, nama, ipk

Method : cetak

Jawab :

class Mhs {

                private int npm;

                private String nama;

                private double ipk;

                public Mhs(int a, String b, double c){

                                this.npm = a;

                                this.nama = b;

                                this.ipk = c;

                }

    public void cetak(){

      System.out.println(npm+", "+nama+", "+ipk);

    }

 }

o  Pengkapsulan : mengabungkan data dan prosedur dalam object 

o  Pewarisan : menambahkan fungsionalitas dengan membuat subclass baru 

o  Polimorfisme :

• “banyak bentuk”
•  mengijinkan pesan diinterpretasikan berbeda
•  overloading (signature berbeda : jumlah, urutan, tipe)
•  overriding (signature sama persis dengan milik class super)

o    Abstract class

•  class yang menyimpan aspek generic dari sub class
• tanpa implementasi
• tidak memiliki body, body digantikan dengan (;)

o  Concrete class

•  subclass dari abstract class
•  mengimplementasikan abstract class
•  tradisional/ structured fokus pada proses atau data
• object oriented fokus pada object (kolaborasi keduanya)
• ADBO à pedekatan analisa dan desain pengembangan software yang fokus pada object
• Menguraikan big problem à small problem

Konsep ADBO  ?

o  Use case driven : saat analisa memperhatikan use case

o  Architecture centric : saat desain memperhatikan arsitektur fungsional, static, dynamic dari sistem

o  Iterative & Incremental (berulang dan bertambah ) :mudah untuk dipakai ulang ataupun diupgrade

ICONIX PROCESS

INTRODUCTION TO ICONIX PROCESS

    Sebelum mempraktekkan ICONIX process ini, ada baiknya kita memahami terlebih dahulu mengenai teori UML (Unified Language Modelling). Karena ICONIX process ini membutuhkan pemahaman akan konsep tersebut.

ICONIX PROCESS ?

ICONIX merupakan salah satu model dari rekayasa perangkat lunak yang dapat digunakan untuk pengembangan sebuah software.

TAHAPAN PROSES ICONIX

Tahapan dari proses ICONIX terdiri dari empat tahap, yaitu :

1.    Requirements

a)        Functional requirements

Mengumpulkan segala kebutuhan fungsional yang diperlukan dalam pembuatan perangkat lunak. Kebutuhan fungsional dari perangkat lunak merupakan modal utama dalam pengembangan perangkat lunak. Semua kebutuhan dalam pengembangan perangkat lunak dikumpulkan menjadi satu bagian. Kemudian dilakukan analisis mengenai kebutuhan fungsional dan kubutuahan non fungsional.

b)        Domain modeling

Domain modeling merupakan pondasi dari bagian static dari UML. Domain modeling didapatkan dari mengekstrak kata benda yang didapatkan dari Functional requirements. Kata benda yang didapatkan saling dihubungkan sesuai kebutuhan dari perangkat lunak.

c)   Behavioral requirements/ Use Case modeling

Use Case modeling merupakan bagian dari proses ICONIX yang menjelaskan tentang segala hal yang dilakukan oleh pengguna dari sistem. Proses ini menjelaskan tentang segala hal yang dilakukan oleh pengguna dan hubungan terhadap tanggapan dari sistem. Dalam proses ini, desain perangkat lunak diharapkan dijelaskan secara rinci karena perangkat lunak didedikasikan berdasarkan kebutuhan pengguna.

d)    Milestone 1 : Requirements Review

     Peninjauan ulang dilakukan sebagai berikut :

   i.  Memastikan bahwa bahwa use case text telah sesuai dengan kebutuhan pengguna.

   ii. Memastikan bahwa domain model telah menunjukkan hubungan yang benar. 

   iii. Memastikan bahwa use case telah terorganisir dalam satu paket.

2.   Analysis and Preliminary Design

a)   Robustness analysis

Analisis dilakukan dengan cara membuat robustness diagram yang menghubungkan antara analisis dan desain.

b)  Update domain model

Pengubahan domain model yang telah dibuat sesuai dari hasil robustness analysis. Pengubahan dilakukan dengan menambahkan class yang tidak ada, menghilangkan ambiguitas, dan menambahkan atribut pada domain object.

c)   Tulis kembali use case yang telah dibuat.

d)   Milestone 2 : Preliminary Design Review (PDR)

Dilakukan analisis mengenai kecocokan use case text dengan robustness diagram, dan memastikan semua entitas yang terdapat pada robustness diagram telah diperbaharui di domain model.

3. Detailed Design

a)   Sequence Diagram

Sequence Diagram merupakan digram alir yang disusun berdasarkan robustness diagram. Diagram ini dibuat untuk setiap use case. Tujuan dari dibuatnya diagram ini adalah untuk mengalokasikan behavior ke class.

b)   Update domain model

Perubahan domain model berdasarkan hasil Sequence Diagram. Pada perubahan ini terdapat penambahan operasi pada domain object.

c)   Milestone 3 : Critical Design review (CDR)

Peninjauan ulang dilakukan dengan memastikan bahwa desain telah memenuhi semua kebutuhan dari hasil identifikasi sebelumnya.

4.   Implementation

a)   Coding/Unit testing

Pada tahap ini mulai dilakukan proses coding berdasarkan hasil pengembangan model yang telah disusun sebelumnya. Jika proses coding telah dilaksanakan maka dapat dilakukan pengujian.

b)   Integration and scenario testing

Dilakukan pengujian secara integrasi dan sesuai dengan skenario. Pengujian yang dilakukan dapat berupa black box testing maupun white box testing.

c)   Perform code review dan model update 

 Melakukan analisa kode program dari hasil pengujian dan melakukan perubahan dari hasil analisa.

 KESIMPULAN

Iconix proses yaitu suatu metode dimana tidak terlalu banyak membahas pada analisa, design maupun implementasi programnya. Namun lebih melihat kepada kebutuhan pengguna serta menyederhanakan proses tersebut, sehingga proses pengembangan perangkat lunak akan menjadi lebih efisien.

                        DAFTAR PUSTAKA :

§Rosenberg, Doug., & Stephen, Matt. 2007. Use Case Driven Object Modelling with UML. New York : Apress.

§https://thesolidsnake.wordpress.com/tag/iconix-process/

§http://informatika.web.id/pengertian-uml.htm

§http://alfianilarizky.blogspot.com/2011/04/iconix-process.html

SDLC ( System Development Life Cycle )

    Metode siklus hidup pengembangan sistem atau system development life cycle memepunyai beberapa tahapan sesuai dengan namanya, SDLC dimulai dari suatu tahapan sampai tahapan terakhir dan kembali lagi ketahapan awal membentuk suatu siklus atau daur hidup.

Tahapan-tahapan dalam metode SDLC adalah sebagai berikut.

1.  Mengidentifikasi masalah, peluang, dan tujuan
2. Menentukan syarat-syarat informasi
3. Menganalisis kebutuhan system
4. Merancang sistem yang direkomendasikan
5. Mengembangkan dan mendokumentasikan perangkat lunak
6. Menguji dan mempertahankan system 
7. Mengimplementasikan dan mengevaluasi sistem

        Siklus SDLC dijalankan secara berurutan, mulai dari langkah pertama hingga langkah keenam. Setiap langkah yang telah selesai harus dikaji ulang, kadang-kadang bersama expert user, terutama dalam langkah spesifikasi kebutuhan dan perancangan sistem untuk memastikan bahwa langkah telah dikerjakan dengan benar dan sesuai harapan. Jika tidak maka langkah tersebut perlu diulangi lagi atau kembali ke langkah sebelumnya.

Kaji ulang yang dimaksud adalah pengujian yang sifatnya quality control, sedangkan pengujian di langkah kelima bersifat quality assurance. Quality control dilakukan oleh personal internal tim untuk membangun kualitas, sedangkan quality assurance dilakukan oleh orang di luar tim untuk menguji kualitas sistem. Semua langkah dalam siklus harus terdokumentasi. Dokumentasi yang baik akan mempermudah pemeliharaan dan peningkatan fungsi sistem