UAS Rekayasa Perangkat Lunak

Nama : Faridha Kusuma Wardhani
Nim : 9106.205.301

1. Apa perbedaan software proses dan software produk?

Software Process merupakan sekumpulan aktivitas, metode, praktek, dan berbagai transformasi yang digunakan oleh sekumpulan manusia di dalamnya untuk membangun dan memelihara piranti lunak serta hal-hal yang berkaitan dengannya, misalnya project plan, dokumen desain, code, testing, cases, dan user manual.

Software Process memiliki atribut dan karakteristik seperti :
1. Understandability, yaitu sejauh mana proses secara eksplisit ditentukan dan bagaimana kemudahan definisi proses itu dimengerti.
2. Visibility, apakah aktivitas-aktivitas proses mencapai titik akhir dalam hasil yang jelas sehingga kemajuan dari proses tersebut dapat terlihat nyata/jelas
3. Supportability, yaitu sejauh mana aktivitas proses dapat didukung oleh CASE
4. Acceptability, apakah proses yang telah ditentukan oleh insinyur dapat diterima dan digunakan dan mampu bertanggung jawab selama pembuatan produk perangkat lunak
5. Reliability, apakah proses didesain sedikian rupa sehingga kesalahan proses dapat dihindari sebelum terjadi kesalahan pada produk.
6. Robustness, dapatkah proses terus berjalan walaupun terjadi masalah yang tak diduga
7. Maintainability, dapatkah proses berkembang untuk mengikuti kebutuhan atau perbaikan
8. Rapidity, bagaimana kecepatan proses pengiriman sistem dapat secara lengkap memenuhi spesifikasi.

Software Process Model antara lain : Waterfall Model, Evolutionary Software Process Model (Incremental Model dan Spiral Model), Rapid Application Development, Prothotyping Model, Component Based Develompment Model, Component Based Software Engineering, dan Extreme Programming XP Model.

Sumber :

a. http://mojora.wordpress.com/2006/09/25/pemodelan-dalam-rekayasa-perangkat-lunak/

b. http://lecturer.ukdw.ac.id/othie/bhn2.pdf

2. Bagaimana caranya menilai sebuah software?

Salah satu cara menilai kualitas sebuah produk piranti lunak yaitu dengan melihat sejauh mana penerapan Capability Maturity Model for Software (CMM-SW) pada organisasi piranti lunak yang bersangkutan. Semakin tinggi level penerapan CMM-SW-nya, maka dipastikan akan semakin baik kualitas produksinya.

CMM-SW adalah sebuah metode untuk mengevaluasi dan mengukur tingkat kematangan (maturity) dari proses rekayasa piranti lunak. CMM-SW menyediakan pedoman kepada pengembang piranti lunak tentang bagaimana untuk meningkatkan kontrol terhadap proses mereka dalam membangun dan memelihara piranti lunak, dan tentang bagaimana untuk mengembangkan lebih jauh sebuah kultur rekayasa piranti lunak dan majemen yang baik. CMM-SW didesain sebagai pedoman pengembang piranti lunak dalam memilih strategi peningkatan proses, dengan mengukur kematangan proses yang sedang berjalan dan mengidentifikasi beberapa isu yang paling kritikal sehubungan dengan kualitas piranti lunak dan peningkatan proses.

Dalam pelaksanaan teknisnya, CMM-SW terdiri dari 5 level dilihat dari tingkat kematangan Software Process. Kelima level tersebut terdiri dari Initial (level 1), Repeatable (level 2), Defined (level 3), Managed (level 4), dan Optimizing (level 5).

CMM-SW berorientasi kepada peningkatan proses pada setiap levelnya. Karena pembangunan dan pemeliharaan piranti lunak sangat bergantung kepada prosesnya. Semakin baik prosesnya, maka akan semakin baik pula kualitas outputnya.

Sumber : http://www.hdn.or.id/index.php/artikel/2006/01/06/p40

3. Di dalam pengembangan perangkat lunak ada fase perawatan perangkat lunak, apa yang dilakukan dalam perawatan perangkat lunak?

Yang dilakukan dalam perawatan perangkat lunak adalah dengan melakukan :

a. Perawatan Sistem sesuai dengan SOP yang perlu diikuti oleh tim yang akan menangani sistem setiap harinya. Hal ini juga meliputi pelatihan staf serta perekrutan atau penambahan sistem komputer jika dibutuhkan.

4. Ambil sebuah case study pengembangan perangkat lunak, bagaimana menetapkan harga perangkat lunak?

Menetapkan harga perangkat lunak dapat diketahui dalam membuat Spesifikasi Kebutuhan (Requirement) dengan membuat Spesifikasi Biaya yang dibutuhkan. Salah satunya dengan membuat WBS.

UAS ANALISA DAN DESAIN SISTEM INFORMASI

NAMA : FARIDHA KUSUMA WARDHANI
NIM : 9106.205.301
DOSEN : FAJAR BASKORO, S.KOM, MT

PENJELASAN SINGKAT UAS ANALISA DAN DESAIN SISTEM INFORMASI


MOBILE APPLICATION


TRANSAKSI PEMBAYARAN (DIGITAL MONEY/SMART DIGITAL)

• 
  Perancangan Sistem Transaksi Pembayaran Perbankan Melalui Telepon Genggam, dengan sistem yang akan dirancang antara lain :
  1. Pendaftaran Nomor Telepon Genggam untuk Tagihan Pulsa.
  Langkah-langkah dalam perancangan sistem ini adalah :
  Masuk ke URL Bank XYZ.
  Pilih Bahasa yang digunakan.
  Masukkan PIN Kartu ATM Anda.
  Pada Menu Utama, pilih “Pendaftaran E-Banking”.
  Kemudian pilih “Pendaftaran Untuk Pembayaran Tagihan”.
  Kemudian Pilih salah satu transaksi yang diinginkan, “PRABAYAR” atau“PASCABAYAR”.
  Masukkan Kode Area dan Nomor Telepon Genggam.
  Pilih konfirmasi “BENAR”, jika informasi tersebut benar ATAU pilih konfirmasi “SALAH”, jika informasi tersebut salah.
  Bila pilihan pada poin h adalah “BENAR”, maka pada layar telepon genggam, akan muncul pesan : “Pendafataran Nomor Telepon Genggam Untuk Pembayaran Tagihan Pulsa melalui E-Banking telah SELESAI”.
  Bila pilihan pada poin h adalah “SALAH”, maka pada layar telepon genggam akan kembali ke menu tampilan sesuai dengan poin g, yaitu memasukkan Kode Area dan Nomor Telepon Genggam.
  
  2. Pembayaran Tagihan Pulsa Prabayar.
  Langkah-langkah dalam perancangan sistem ini adalah :
  Masuk ke URL Bank XYZ.
  Pilih Bahasa yang digunakan.
  Masukkan PIN Kartu ATM Anda.
  Pada Menu Utama, pilih “Pembayaran Tagihan Pulsa Prabayar”.
  Pada menu Jenis Kartu Prabayar pilih "MENTARI atau SIMPATI atau PROXL atau IM3 SMART".
  Pada Menu Silakan Masukkan Nomor Telepon/Handphone untuk Daftar Pembayaran/Pembelian : INPUT atau MASUKKAN NO HP YG AKAN DIISI PULSA.
  Klik BENAR, Jika No HP yang diinput benar atau klik SALAH, jika No HP yang diinput salah kemudian input No HP yang benar selanjutnya klik BENAR.
  Pilih Pulsa yag akan diisikan, yaitu “Rp. 50.000,00”, “Rp. 100.000,00”, “Rp. 150.000,00” atau “Rp. 200.000,00”
  Jika transaksi pengisian pulsa PRABAYAR selesai, maka pada layar akan muncul pesan : “Transaksi Pembelian Pulsa Prabayar Sebesar (yang telah dipilih) telah BERHASIL”.
  
  
  3. Pembelian Pulsa Pascabayar.
  Langkah-langkah dalam perancangan sistem ini adalah :
  Masuk ke URL Bank XYZ.
  Pilih Bahasa yang digunakan.
  Masukkan PIN Kartu ATM Anda.
  Pada Menu Utama, pilih “Pembayaran Tagihan Pulsa Pascabayar”.
  Pada menu Jenis Kartu Prabayar pilih "MENTARI atau SIMPATI atau PROXL atau IM3 SMART".
  Pada Menu Silakan Masukkan Nomor Telepon/Handphone untuk Daftar Pembayaran/Pembelian : INPUT atau MASUKKAN NO HP YG AKAN DIISI PULSA.
  Klik BENAR, Jika No HP yang diinput benar atau klik SALAH, jika No HP yang diinput salah kemudian input No HP yang benar selanjutnya klik BENAR.
  Pada layar telepon genggam akan tampil tagihan dan operator dari tagihan Anda.
  Pilih pilihan “BENAR” dan transaksi pembayaran pascabayar akan dilanjutkan.
  Jika transaksi pengisian pulsa PASCABAYAR selesai, maka pada layar akan muncul pesan : “Transaksi Pembayaran Tagihan Pulsa Pascabayar Sebesar (yang telah dipilih) telah BERHASIL”.
  
  
  4. Transfer Antar Nasabah.
• 
  
  KTP ONLINE
  
  
  SARANA KOMUNIKASI DAN PENDIDIKAN (CONTOH : LIBRARY)
  Dalam sub bab ini ditampilkan deskripsi dan rancangan sistem dari sebuah PERPUSTAKAAN. Rancangan sistem yang dibuat :
  a. Business Use Case Diagram
  b. Use Case Diagram
  c. Sequence Diagram
  d. State Diagram
  e. Collaboration Diagram
  f. Class Diagram
  
  Yang berperan sebagai actor dalam perancangan sistem Perpustakaan adalah :
  a. Anggota
  b. Non Anggota
  c. Petugas
  d. Buku
  
  Sistem yang dirancang antara lain :
  a. Peminjaman Buku
  b. Pengembalian Buku
  c. Pencarian Buku
  d. Maintenance Buku
  Yang belum ada dalam perancangan sistem ini adalah Maintenance AnggotaPenjelasan lebih jauh mengenai perancangan sistem PERPUSTAKAAN, ditampilkan dalam blog dengan main title “LIBRARY”.
  
  
  
  

6. Class Diagram Library

LIBRARY

Class Diagram

5. Collaboration Diagram Library

LIBRARY

Collaboration Diagram

4. State Diagram Library

LIBRARY

State Diagram
       -State Diagram “Mencari”

             -State Diagram “Meminjam”


                  -State Diagram “Mengembalikan”

3. Sequence Diagram Library

LIBRARY


Sequence Diagram
        -Requirement Pencarian


-Requirement "Pinjaman" 


-Sequence Diagram “Peminjaman” 

-Requirement “Pengembalian” 


-Sequence Diagram “Pengembalian” 

-Requirement “Maintenance Buku” 

-Sequnce Diagram “Maintenance Buku” 

-Requrement “Maintenance Anggota” 

-Sequence Diagram “Maintenance Anggota”

-Requirement “Laporan”

-Sequence Diagram “Laporan”

2. Use Case Diagram Library

Use Case Diagram 


Documentation :

Use Case “ Meminjam ”



Use Case “ Mengembalikan ”

Use Case “ Mencari ”


Use Case “ Maintenance Buku ”


Use Case “ Maintenance Anggota ”

1. Business Use Case Diagram Library

Bussiness Use Case Diagram

5. FINDING CLASSES

What is Object ?
Object adalah representasi entity, sesuatu yang nyata atau konsep. Object dapat menyatakan sesuatu yang konkrit seperti : Denny, Komputerku, atau konsep seperti proses kimia, transaksi bank, order pembelian. Masing-masing object dalam sistem mempunyai karakteristik state, behaviour, dan identity.

State, Behaviour, and Identity
State suatu object adalah salah satu kondisi yang mungkin. State suatu object secara tipikal berubah menurut perubahan waktu, ia didefinisikan sebagai set of properties (attributes).
Behaviour menentukan bagaimana sebuah object merespon permintaan object lain. Behaviour diimplementasikan sebagai set operations. Sebagai contoh add a student, delete a student.
Identity bermakna bahwa masing-masing object adalah unik.

Entity Class
Class Entity memodelkan informasi dan tingkah laku yang umumnya long lived. Requirement analysis berurusan dengan entity class. Tipe class ini merefleksikan real world entity atau mungkin diperlukan untuk melakukan pekerjaan-pekerjaan internal pada sistem. Secara tipikal ditemukan pada awal fase elaborasi dan sering disebut class domain.
Boundary classes menangani komunikasi antara sistem dengan sekelilingnya dan menyediakan interface ke user atau sistem yang lain.
Control Classes mengkoordinasikan kejadian yang diperlukan untuk merealisasikan behaviour yang dispesifikasikan dalam use case. Control classes sebagai running atau executing use case yang mempresentasikan dynamic use case.

Packages
Sistem yang terdiri banyak class, maka diperlukan mekanisme untuk mengelompokkan mereka supaya lebih mudah menggunakannya, mudah memeliharanya dan mudah menggunakannya kembali.

4.INHERITANCE & ASSOCIATION CLASS

Inheritance
Inheritance didefinisikan sebagai sebuah relationship antara class dimana satu class men-share struktur dan operasi untuk satu atau beberapa class. Hirarki abstraksi dibuat dimana subclass mewarisi satu atau beberapa superclass. Subclass akan mewarisi semua atribut, operasi yang didefinisikan dalam superclass. Jadi atribut dan operasi yang didefinisikan pada level tertinggi dapat hirarki dapat diwarisi oleh semua class dalam level bawah.
Ada dua cara untuk mencari inheritance yaitu generalization dan specialization yang digunakan pada sistem dalam fase pengembangan.

Generalization
Generalization menyediakan kemampuan untuk membuat superclass yang mama membungkus struktur dan behavior untuk beberapa class. Class diuji atribut dan operasinya.

Specialization
Specialization menyediakan kemampuan untuk membuat subclass yang mepresentasikan perbaikan pada superclass.
Assosiation Classes
Relationship mungkim mempunyai structure dan behavior. Ini benar jika transaksi informasi adalah antara dua objek dan bukan antar objek itu sendiri.

3. PENGERTIAN BERORIENTASI OBJEK

Yang dimaksud dengan object oriented adalah bahwa kita mengorganisasi perangkat lunak sebagai kumpulan dari objek-objek diskrit yang bekerja sama antara data structure dan behaviour. Paradigma perancangan berorientasi objek, antara lain sebagai berikut :
Abstraction
Inheritance
Polymorphism
Encapsulation
Message Sending
Assosiations
Aggregation

Object and Class
Object, yang konkrit atau tidak, adalah segala sesuatu di sekitar kita. Objek-objek yang menyusun dunia ini. Amir, Ali dan Andi adalah contoh objek dari class manusia. Object mempunyai attribute dan operation. Attribute dari object diatas adalah umur, tinggi, berat dan sebagainya. Sedangkan operation dari object diatas adalah makan, minum, tidur, membaca dan sebagainya.
Class adalah sebuah kategori dari objek-objek yang mempunyai attribute dan operation yang sama.

Abstraction
Abstraction secara sederhana dikatakan filter property objek-objek dan operasi. Tipe yang berbeda dari persoalan memerlukan nilai informasi yang berbeda, sehingga hanya atribut-atribut dan operasi yang diperlukan saja yang didefinisikan. Metode ini dikenal dengan istilah abstraction dari suatu objek.

Inheritance
Object adalah instance suatu kelas, maka object mempunyai semua karakteristik dari suatu kelas. Atribut dan operasi yang ditentukan dalam class akan ter-inheritance ke masing-masing object dalam kelas tersebut.
Class dapat juga mewarisi sifat-sifat class lainnya. Washing machine, regrigenerator, microwave ovens, radio, televisi adalah class peralatan listrik, mereka mewarisi atribut dari class peralatan misalnya type, dan mewarisi operasi misalnya turn on dan turn off.

Polymorphism
Kadang-kadang sebuah operasi mempunyai nama yang sama pada class yang berbeda. Sebagai contoh, membuka jendela, membuka pintu, membuka surat kabar, membuka percakapan. Dalam masing-masing persoalan dapat dilakukan operasi yang berbeda-beda. Misalnya, suatu operasi dengan nama yang sama, tetapi jika dikenakan pada objek yang berbeda akan mengakibatkan operasi yang berbeda.
Encapsulation
Ketika seseorang menonton televisi, biasanya seseorang tersebut tidak memperhatikan tentang kompleksitas rangkaian elektronika yang ada di dalamnya, mereka tidak memperdulikan bagaimana rangkaian elektronika itu bekerja, mereka hanya memperhatikan tombol-tombol apa saja yang bisa digunakan untuk mengoperasikannya. Konsep ini dikenal dengan istilah encapsulation, yaitu menyembunyikan operasi-operasinya dari dunia luar dan dari objek-objek lainnya.
Message Sending
Bagaimana objek-objek dalam sistem berkerja besama-sama. Mereka melakukannya dengan mengirimkan pesan dari salah satu object ke object yang lainnya. Suatu object mengirimkan pesan ke object lainnya untuk melakukan sebuah operasi, juga dapat menerima pesan dari object lainnya untuk melakukan operasi.

Association
Sebagai contoh, saat seseortang menyalakan televisi, maka menurut terminologi object oriented, seseorang tersebut sedang ber-assosiasi dengan televisi. Kadang-kadang sebuah object mungkin diassosiasikan dengan object lainnya dalam lebih dari satu cara. Sebuah class dapat diassosiasikan dengan lebih dari satu class.



Aggregation
Komputer terdiri dari CPU, keyboard, mouse, monitor, harddisk, modem, printer dan sebagainya. Di dalam CPU terdapat card grafic, sound card dan sebagainya. Komputer adalah sebuah aggregation, meliputi hubungan yang kuat antara object dan object-object sebagai komponennya. Ini dikenal dengan composition.

2. PENGANTAR UNIFIED MODELLING LANGUAGE

UML adalah salah satu tools yang paling penting :
Akurat
Konsisten
Mudah dikomunikasikan
Mudah untuk diubah
UML tidak hanya sekedar memodelkan sistem sebagai kumpulan object, tetapi juga menjelaskan apa yang dapat dilakukan oleh sistem, bagaimana sistem memenuhi fungsinya. UML tidak hanya memberikan standarisasi dalam notasi/diagram, melainkan menjelaskan juga aturan hubungan antar komponen.
UML terdiri atas sejumlah elemen-elemen grafik yang mengkombinasikan ke dalam bentuk diagram. UML mempunyai aturan untuk mengkombinasikan elemen-elemennya. Tujuan dari diagram-diagram ini adalah untuk menghasilkan multiple view dari sistem, dan kumpulan dari view disebut dengan model. Model UML dari suatu sistem suatu saat seperti sebuah model skala dari bangunan. Penting untuk diperhatikan bahwa model UML menjelaskan apa yang diajukan sistem untuk dikerjakan, bukan bagaimana cara mengimplementasikannya. Akan diberikan sekilas tentang komponen-komponen UML :

Class Diagram
Pikirkan sesuatu di seputar kita. Kita mungkin melihat bahwa benda-benda dapat dimasukkan dalam kategori tertentu (mobil, furniture, mesin cuci, dan sebagainya). Kita mereferensikan bahwa kategori-kategori diatas sebagai sebuah class. Class adalah sebuah kategori dari kumpulan sesuatu yang mempunyai kemiripan attribute dan behaviour (tingkah laku).
Sebagai contoh class mesin cuci mempunyai attribute seperti brand name, model, serial number, capacity. Behaviour untuk sesuatu dalam class mesin cuci termasuk operasi menambah cucian, menambah detergent, hidupkan mesin dan amnil pakaian.

Object Diagram
Object adalah instance dari sebuah class-sesuatu yang spesifik yang mempunyai nilai dari attribute dan behaviour. Contoh : mesin cuci mempunyai brand name : Laundatorium, model name : Washmeister, serial number : GLS577774 dan capacity 16 kg.

Use Case Diagram
Use case adalah penjelasan tingkah laku sistem menurut pandangan user. Simbol little stick yang menghubungkan ke user disebut dengan actor. Simbol ellips mempresentasikan use case. Actor yang menginisial use case dapat berupa orang, sesuatu atau sistem yang lain.
State Diagram
Suatu object bisa berada dalam keadaan yang berbeda. Seseorang bisa mengalami masa baru lahir, bayi, kanak-kanak, remaja, dewasa dan masa tua. Sebuah elevator bisa berada dalam kondisi bergerak, naik, berhenti, atau bergerak turun. Mesin cuci bisa berada dalam kondisi soak, wash, rinse, spin atau off state.

Sequence Diagram
Class diagram dan Object diagram mempresentasikan static information. Dalam sistem fungsional, object berinteraksi dengan object lainnya dan interaksi ini terjadi sepanjang waktu. Sequence Diagram menunjukkan dinamik yang berdasarkan waktu dari interaksi mereka.
Melanjutkan contoh mesin cuci yang lalu, komponen dari mesin cuci meliputi water pipe (untuk memasukkan air baru), drum (bagian untuk menempatkan pakaian) dan drain. Apa yang akan terjadi pada saat kita menggunakannya? Asumsikan bahwa kita telah memberikan atau melakukan operasi add pakaian, add deterjen, dan add turn on. Urutan langkah-langkah sebagai berikut :
1.Air memasuki drum melalui water pipe.
2.Drum berhenti/diam selama 5 (lima) menit.
3.Air berhenti masuk.
4.Drum berputar bolak-balik selama 15 menit.
5.Air sabun meninggalkan drum melalui drain.
6.Air masuk drum lagi.
7.Drum melanjutkan putaran bolak-balik lagi.
8.Air berhenti masuk.
9.Air bilasan keluar melalui drain.
10.Drum berhenti berputar, pekerjaan selesai.

Collaboration Diagram
Elemen-elemen dalam suatu sistem bekerja bersama-sama untuk mencapai tujuannya dan bahasa modelling harus memiliki suatu cara untuk mempresentasikannya. Collaboration Diagram didesain untuk tujuan ini.

Activity Diagram
Aktifitas yang terjadi pada use case atau di dalam tingkah laku object secara tipikal pada sequence, sebagaimana dalam sebelas langkah terdahulu.

Component Diagram
Component Diagram dan Deployment Diagram adalah kelengkapan dalam sistem komputer (implementasi). Pengembangan perangkat lunak modern menciptakannya melalui komponen-komponen yang mana secara jelas didasarkan pada usaha-usaha pengembangan dengan menggunakan tim.

Deployment Diagram
Dalam Deployment Diagram menunjukkan arsitektur secara fisik dari sistem yang berbasis komputer. Dapat terdiri dari komputer dan peralatan-peralatan lainnya.

1. PERENCANAAN SISTEM

PERENCANAAN SISTEM

Proyek sistem informasi harus direncanakan dengan baik, meliputi :

1.Identifikasi
2.Klasifikasi
3.Peringkat
4.Pemilihan
Beberapa metodologi perencanaan sistem :

1.SWOT (Strength, Weakness, Opportunity, Threats)
Strength dan Weakness berkaitan dengan kondisi internal perusahaan yang meliputi bidang manajemen, produksi, SDM, marketing, R&D, dan sebagainya. Opportunity dan Threats berkaitan dengan kondisi eksternal perusahaan meliputi bidang ekonomi, sosial, politik dan faktor teknologi.
2.VCM (Value Chain Model)
Merupakan evaluasi apakah dengan sistem informasi yang dibuat, memberikan keuntungan kompetitif melalui analisis berantai dari suatu organisasi, mulai dari bahan baku sampai dengan produk jadi, pengiriman sampai kepada konsumen.
3.BPR (Business Process Reengineering)
Suatu organisasi harus menemukan kembali kelemahan-kelemahan pada organisasinya dan membebaskan dari hal yang bersifat struktur hirarki, dekomposisi dan prinsip-prinsip operasional yang sekarang masih digunakan (unit-unit vertikal).
4.ISA (Information System Architecture).

Semua pilihan metodologi diatas, berkonsentrasi pada effectiveness (doing the right things=mengerjakan hal yang tepat) daripada hanya sekesar efficiency (doing things right=mengerjakan sesuatu dengan tepat).
Sistem untuk 3 (tiga) level management, antara lain:
1.Strategik  Mendukung kegiatan organisasi dengan tujuan jangka panjang (Data Mining, Knowledge Management). Contoh : Market dan Sales Analisis, Product Planning.
2.Taktikal  Kebijakan yang mendukung kegiatan organisasi dalam jangka pendek (Data Warehouse, OLAP). Contoh Analisis Budget, Inventory Schedulling.
3.Operasional  Aktifitas sehari-hari dan hanya mendukung kegiatan produksi (Database, Proses transaksi). Contoh : Invoice, Payroll dan Accounting.

Desain yang berorientasi pada Objek

Pengantar
Object-oriented design (OOD) dipakai untuk mentransformasikan model analisa yang dikembangkan dalam object-oriented analysis ke suatu model desain yang berfungsi sebagai blue-print untuk pembuatan perangkat lunak. Berbeda dengan metode desain perangkat lunak konvensional, OOD menghasilkan suatu desain yang memiliki beberapa level modularity. Komponen-komponen sistem utama diorganisasikan dalam subsistem-subsistem. Data dan operasi untuk memanipulasi data tersebut di-encapsulasi sebagai object.

Object-oriented design memiliki kemampuan untuk menerapkan empat konsep desain perangkat lunak utama, yaitu:
1.abstraction
2.information hiding
3.functional independence
4.modularity
Semua metode desain perangkat lunak memang bertujuan untuk bisa menerapkan ke-empat konsep tersebut diatas, tetapi hanya OOD yang menyediakan mekanisme yang memungkinkan para desainer untuk menerapkannya dengan tingkat kekompleksan yang lebih ringan.


OOD Methods
Berikut ini adalah ringkasan dari beberapa OOD methods yang cukup populer:
1.Booch Method
2.Coad and Yourdon Method
3.Jacobson Method
4.Rumbaugh Method
5.Wirfs-Brock Method

OOD Method dari Booch tetap memakai micro dan macro-development processes seperti pada OOA method-nya. Berikut ini adalah ringkasan dari OOD micro-development process dari Booch:
1.Perencanaan Arsitektur
2.Desain taktis
3.Perencanaan Release

OOD Method dari Coad dan Yourdon dikembangkan dengan cara mempelajari bagaimana cara kerja dari para desainer sistem object-oriented yang efektif. Pendekatan yang dipakai tidak hanya untuk aplikasi, tetapi juga termasuk infrastruktur dari aplikasi. Berikut ini adalah ringkasan dari OOD Method dari Coad dan Yourdon:
1.Komponen domain permasalahan
2.Komponen interaksi manusia
3.Komponen manajemen task
4.Komponen manajemen data

OOD Method dari Jacobson menekankan pada traceability dari OOSE analysis model. Ringkasan proses OOD dari Jacobson adalah:
1.Pertimbangkan adaptasi untuk model analisa yang ideal supaya bisa cocok dengan lingkungan sistem yang sesungguhnya.
2.Buat block-block sebagai desain object utama. Block adalah abstraksi desain yang memungkinkan representasi dari aggregate objects (object yang terdiri dari object-object lainnya).
3.Buat diagram interaksi yang menunjukkan bagaimana block-block tersebut berkomunikasi.
4.Block-block tersebut diorganisasi dalam bentuk subsistem.
5.Review hasil desain tersebut.



Rumbaugh Method, yang juga dikenal dengan nama Object Modeling Technique (OMT) mencakup aktivitas desain yang memungkinkan dilakukannya desain dengan dua level abstraksi yang berbeda. Desain sistem difokuskan pada layout komponen yang dibutuhkan untuk membangun produk / sistem yang lengkap. Desain object menekankan pada layout detail dari individu object. Ringkasan proses OOD dari Rumbaugh adalah:
1.Mengembangkan desain sistem.
2.Mengembangkan desain object.
3.Mengimplementasikan mekanisme kontrol yang didefinisikan pada desain sistem.
4.Memperbaiki struktur dari class untuk memperkuat inheritance.
5.Mendesain messaging untuk mengimplementasikan hubungan antar object (asosiasi).
6.Mengelompokkan class dan asosiasi-nya ke dalam module-module.

OOD Method dari Wirfs-Brock menekankan pada proses yang berkelanjutan dari tahap analisa ke tahap desain. Ringkasan proses OOD dari Wirfs-Brock adalah:
1.Membuat protokol untuk tiap class. Protokol adalah deskripsi formal dari message-message yang dikenal oleh suatu class.
2.Membuat spesifikasi desain untuk tiap class.
3.Membuat spesifikasi desain untuk tiap subsistem.

Meskipun istilah dari tahapan proses dari tiap OOD method diatas berbeda, secara keseluruhan, proses OOD cukup konsisten. Untuk melakukan OOD, seorang software engineer harus melakukan tahapan umum berikut ini:
1.Setiap subsistem dideskripsikan ke dalam bentuk yang mudah untuk diimplementasikan.
2.Mendesain object.
3.Mendesain message.
4.Review model dari desain. Langkah-langkah diatas diulangi bila perlu.


Tranlasi OOA ke OOD
OOA dan OOD seringkali sulit untuk dibedakan. Intinya, OOA adalah aktivitas klasifikasi. Suatu masalah dianalisa dalam rangka untuk menentukan class-class dari object yang bisa diterapkan dalam solusi yang hendak dikembangkan. Analisis juga menentukan hubungan antar object (relationship) dan behavior-nya.

OOD memungkinkan software engineer untuk mengetahui object-object yang dihasilkan oleh tiap class dan hubungan antar object. Selain itu, OOD menggambarkan bagaimana hubungan antar object bisa dilakukan, bagaimana behavior dari object diimplementasikan dan bagaimana komunikasi antar object diimplementasikan.

Model Analisa

Model Desain
Class

object
Attribute

struktur data
Method

algoritma
Relationship

messaging
Behavior

kontrol

Figure 13-1. Menterjemahkan model analisa ke model desain

OOD dipakai untuk menterjemahkan model OOA (model dari real world) ke model yang mudah untuk diimplementasikan dalam suatu perangkat lunak. Proses OOD bisa dideskripsikan sebagai suatu piramid empat layer. Layer dasar difokuskan pada desain dari subsistem yang mengimplementasikan fungsi-fungsi utama dari sistem. Layer class dipakai untuk men-spesifikasikan arsitektur object secara keseluruhan dan hirarki class yang dibutuhkan untuk mengimplementasikan sistem. Layer message dipakai untuk menunjukkan hubungan / kerja-sama antar object bisa dilakukan. Layer tanggung-jawab (responsibility layer) dipakai untuk mengidentifikasikan attribute dan operasi dari setiap class.



Kesimpulan
Meskipun terdapat banyak OOD method, semuanya sesuai dengan piramid desain dan memiliki dua level abstraksi:
desain dari sistem dan subsistem
desain dari object secara individu

Empat komponen yang dibahas dalam desain subsistem:
komponen domain permasalahan
komponen interaksi manusia
komponen manajemen task
komponen manajemen data
Komponen domain permasalahan dipakai untuk mengimplementasikan kebutuhan dari customer. Komponen lainnya dipakai untuk desain infrastruktur dari perangkat lunak sehingga bisa beroperasi dengan efektif.

Proses desain object difokuskan pada deskripsi dari struktur data yang mengimplementasikan attribute dari class, algoritma untuk mengimplementasikan operasi, dan message yang memungkinkan hubungan / kerja-sama antar object.


Referensi
Pressman, chapter 21

Analisa yang Berorientasi pada Objek

Pengantar
Object-oriented analysis bertujuan untuk mendefinisikan semua class (beserta relationship dan behavior-nya) yang berhubungan dengan problem yang hendak diselesaikan. Untuk itu, langkah-langkah yang harus dilakukan adalah:
1.Diskusi antara customer dan software engineer tentang basic user requirements.
2.Identifikasi class (termasuk definisi attributes dan methods).
3.Spesifikasi hierarchy dari class.
4.Representasi relationship antar object.
5.Pemodelan object behavior.
6.Langkah 1 sampai 5 diulang sampai model selesai dikembangkan.


OOA Methods
Teknologi object yang semakin populer telah melahirkan banyak sekali Object-oriented Analysis Methods (OOA methods). Setiap method memiliki suatu proses untuk menganalisa suatu sistem atau produk, sekumpulan model sebagai output dari proses tersebut, dan suatu notasi untuk mengembangkan model-model tersebut. Berikut ini adalah ringkasan dari beberapa OOA methods yang cukup populer:
1.Booch Method
2.Coad and Yourdon Method
3.Jacobson Method
4.Rumbaugh Method
5.Wirfs-Brock Method

Booch Method memakai prinsip “micro development process” dan “macro development process”. Dalam proses micro, didefinisikan sekumpulan task dalam tahap analisa yang akan dipakai kembali pada tahap-tahap dari proses macro. Berikut ini adalah ringkasan OOA micro development process dari Booch :
1.Identifikasi class dan object
2.Identifikasi semantik dari class dan object
3.Identifikasi relationship antar class dan object
4.Melakukan beberapa perbaikan / penyempurnaan
5.Implementasi class dan object (dalam konteks OOA, adalah penyelesaian model dari tahap analisa)

Coad and Yourdon Method sering dianggap sebagai OOA method yang paling mudah untuk dipelajari. Notasi pemodelan yang dipakai relatif sederhana. Pedoman untuk mengembangkan model juga tidak bertele-tele. Berikut ini adalah ringkasan proses OOA dari Coad and Yourdon:
1.Identifikasi object dengan menggunakan kriteria “apa yang dicari?”
2.Definisi suatu struktur generalization-specification
3.Definisi struktur whole-part
4.Identifikasi subject (representasi komponen subsystem)
5.Definisi attributes
6.Definisi services

Jacobson Method juga dikenal dengan nama OOSE (object-oriented software engineering). Jacobson Method sebenarnya adalah Objectory Method (juga dikembangkan oleh Jacobson) yang sudah disederhanakan. Method ini memakai penekanan pada use case (deskripsi/skenario yang menggambarkan interaksi user dengan produk/sistem). Ringkasan proses OOA dari Jacobson:
1.Identifikasi user dari sistem dan semua kewajibannya.
2.Mengembangkan model dari requirements
3.Mengembangkan model analisa.

Rumbaugh et al, mengembangkan Object Modeling Technique (OMT) untuk tahap analisa, system design dan object-level design. Tahap analisa menghasilkan tiga model, yaitu:
object model (representasi dari object, class, hierarchy dan relationship)
dynamic model (representasi dari behavior object dan system)
functional model (representasi flow dari sistem yang mirip high-level DFD)
Ringkasan proses OOA dari Rumbaugh:
1.Mendefinisikan ruang lingkup dari problem
2.Mengembangkan object model
3.Mengembangkan dynamic model
4.Mengembangkan functional model

Wirfs-Brock Method tidak memberikan batasan yang jelas antara task-task dari tahap analisa dan desain, tetapi memakai proses yang terus berlanjut yang dimulai dari evaluasi spesifikasi customer sampai proposal desain selesai. Ringkasan task yang berhubungan dengan OOA dari Wirfs-Brock:
1.Evaluasi spesifikasi customer
2.Menggunakan grammar untuk mencari candidat class dari spesifikasi
3.Memilah class untuk mencari super-class
4.Mendefinisikan kewajiban tiap class
5.Menerapkan kewajiban tiap class
6.Identifikasi relationship antar class
7.Mendefinisikan kerjasama antar class berdasarkan kewajibannya
8.Mengembangkan representasi hierarchy dari class untuk menunjukkan inheritance
9.Mengembangkan graph gabungan (keseluruhan) dari sistem

Meskipun istilah dan langkah-langkah dari tiap OOA method diatas berbeda, proses OOA secara umum cukup mirip, Untuk melakukan object-oriented analysis, seorang software engineer harus melakukan langkah-langkah umum berikut ini:
1.Memahami requirement dari customer untuk sistem OO
1.1.Identifikasi skenario atau use cases
1.2.Mengembangkan model dari requirement
2.Memilih class dan object dengan menggunakan requirement dasar sebagai pedoman
3.Identifikasi attribute dan operation untuk tiap object dari sistem
4.Mendefinisikan struktur dan hierarchy untuk mengorganisasi class
5.Mengembangkan object-relationship model
6.Mengembangkan object-behavior model
7.Review OO analysis model dengan use cases/skenario


Use Case
Use Case (atau skenario) dipakai untuk menjelaskan bagaimana sistem akan dipakai. Untuk membuat use case, analis harus mengidentifikasi orang / device yang akan memakai sistem / produk. Orang / device yang akan memakai sistem ini disebut actor. Secara formal, actor adalah apa saja yang berkomunikasi dengan sistem/produk dan bukan merupakan bagian dari sistem itu sendiri (eksternal terhadap sistem). Jacobson menyarankan beberapa pertanyaan yang harus bisa dijawab oleh use case:
Apa fungsi utama dari actor-actor yang ada?
Informasi sistem apa yang akan dibutuhkan, dihasilkan atau diubah oleh actor?
Apakah actor harus memberitahu sistem tentang perubahan pada lingkungan eksternal?
Informasi apa yang diinginkan actor dari sistem?
Apakah actor ingin diberitahu tentang perubahan yang tidak terduga?
Secara umum, suatu use case adalah suatu keterangan tertulis sederhana yang menjelaskan peranan dari actor pada saat berinteraksi dengan sistem.

Referensi
Pressman, chapter 21