Analisis Berorientasi Objek : Perubahan Model Analisis ke Desain

PERUBAHAN MODEL ANALISIS KE MODEL DESIGN

Tujuan dari model analisis adalah untuk mewakili mendasari masalah bisnis domain sebagai satu set berkolaborasi benda.
Dengan kata lain, kegiatan analisis mendefinisikan kebutuhan fungsional. Untuk mencapai hal ini, kegiatan analisis mengabaikan kebutuhan non fungsional seperti kinerja dan system isu lingkungan (misalnya, pemrosesan terdistribusi atau terpusat, masalah user interface, dan masalah database). Sebaliknya, tujuan utama dari model desain adalah untuk meningkatkan kemungkinan berhasil memberikan suatu sistem yang mengimplementasikan kebutuhan fungsional dengan cara yang terjangkau dan mudah dipelihara. Oleh karena itu, dalam desain sistem, kita mengatasi kedua kebutuhan fungsional dan nonfungsional.

Factoring adalah proses memisahkan modul ke modul yang berdiri sendiri dalam dan dari dirinya sendiri. Modul baru dapat menjadi kelas baru atau metode baru. Sebagai contoh, ketika meninjau satu set kelas, mungkin menemukan bahwa mereka memiliki satu set sama atribut dan metode

Abstraksi dan perbaikan adalah dua proses terkait erat dengan penawaran factoring.Abstraksi dengan penciptaan ide-tingkat yang lebih tinggi dari satu set ide. Mengidentifikasi kelas Karyawan merupakan contoh abstrak dari satu set kelas yang lebih rendah ke yang lebih tinggi. Dalam beberapa kasus, Proses akan mengidentifikasi kelas abstrak, sedangkan dalam situasi lain, akan mengidentifikasi tambahan Proses perbaikan adalah kebalikan dari proses abstraksi.

Partisi dan Kolaborasi Berdasarkan semua factoring  piutang, penyulingan, dan abstrak yang dapat terjadi pada sistem berkembang,ukuran tipis dari representasi sistem dapat membebani baik pengguna dan pengembang. dititik ini dalam evolusi sistem, mungkin masuk akal untuk membagi representasi menjadi set partisi. Partisi A adalah setara berorientasi obyek subsistem, di mana subsistem adalah penguraian dari suatu sistem yang lebih besar dalam sistem komponen (misalnya, akuntansi)

Layers

Untuk berhasil berkembang model analisis sistem ke model desain sistem, kita harus menambahkan informasi lingkungan sistem. Cara yang berguna untuk melakukan hal ini, tanpa overloading pengembang, adalah dengan menggunakan Layers.

Berdasarkan Smalltalk arsitektur MVC yang inovatif, banyak lapisan perangkat lunak yang berbeda telah diusulkan, lapisan berikut yang menjadi dasar arsitektur perangkat lunak: Pondasi, Problem Domain, Manajemen Data, Human-Computer Interaction and Physical Architecture.

Fondasi  : lapisan dasar adalah, dalam banyak hal, lapisan yang sangat menarik. Ini berisi kelas yang diperlukan untuk setiap aplikasi berorientasi objek ada. Mereka termasuk kelas yang mewakili tipe data dasar (misalnya, bilangan bulat, bilangan real, karakter, string), kelas yang mewakili struktur data dasar, kadang-kadang disebut sebagai kelas kontainer (misalnya, daftar, pohon, grafik, set, tumpukan, antrian), dan kelas yang mewakili abstraksi yang berguna, kadang-kadang disebut sebagai kelas utilitas (misalnya, tanggal, waktu, uang). Hari ini, kelas yang ditemukan pada lapisan ini biasanya disertakan dengan lingkungan pengembangan berorientasi objek.

Problem Domain : banyak masalah yang perlu diatasi ketika merancang kelas, tidak peduli di mana lapisan mereka muncul. Misalnya, ada isu-isu yang berkaitan dengan factoring, kohesi dan kopling, connascence, enkapsulasi, penggunaan yang tepat dari warisan dan polimorfisme, kendala, spesifikasi kontrak, dan desain metode rinci.

Manajemen Data :  Lapisan manajemen data membahas masalah-masalah yang melibatkan kegigihan objek yang terdapat dalam sistem. Jenis-jenis kelas yang muncul pada lapisan kesepakatan ini dengan bagaimana objek dapat disimpan dan diambil. Kelas-kelas yang terkandung dalam lapisan ini memungkinkan kelas domain masalah untuk menjadi independen dari penyimpanan yang digunakan dan, karenanya, meningkatkan portabilitas sistem berkembang. Beberapa masalah yang berkaitan dengan lapisan ini meliputi pilihan format penyimpanan (seperti database relasional, objek / relasional, dan objek) dan optimalisasi penyimpanan (seperti clustering dan pengindeksan).

Human-Computer Interaction : interaksi lapisan berisi kelas yang terkait dengan View dan ide Pengawas dari Smalltalk. Tujuan utama dari lapisan ini adalah untuk menjaga spesifik implementasi antarmuka pengguna yang terpisah dari kelas domain masalah. Hal ini meningkatkan portabilitas sistem berkembang. Kelas khas ditemukan pada lapisan ini termasuk kelas yang dapat digunakan untuk mewakili tombol, jendela, bidang teks, scroll bar, kotak cek, daftar drop-down, dan banyak kelas lain yang mewakili elemen interface.

Physical Architecture : layer addres Physical Architecture bagaimana perangkat lunak akan dijalankan pada komputer tertentu dan jaringan. Dengan demikian, lapisan ini termasuk kelas yang berhubungan dengan komunikasi antara perangkat lunak dan sistem operasi komputer dan jaringan. Misalnya, kelas yang membahas bagaimana berinteraksi dengan berbagai port pada komputer tertentu termasuk dalam lapisan ini. Lapisan ini juga termasuk kelas yang berinteraksi dengan apa yang disebut aplikasi middleware, seperti CORBA OMG dan Microsoft DCOM dan arsitektur NET yang menangani objek terdistribusi.

sumber referensi :

Alan Dennis, Barbara Haley Wixon, David Tegarden, Systems Analysis and Design: an Object-Oriented Approach with UML 2.0, John Wiley and Sons, 2005