Software Engineering : Design Engineeing- Component Level Design ( Part 2 )

Artikel berikut merupakan lanjutan artikel sebelumnya yaitu : Software Engineering : Design Engineeing- Component Level Design ( Part 1 )

COMPONENT-LEVEL DESIGN PRINCIPLES

• Open-closed principle
  Suatu modul atau komponen harus terbuka untuk di-extend namun tertutup untuk dimodifikasi. Desainer harus menspesifikasikan komponen dengan cara yang mengijinkannya untuk di-extend tanpa perlu mengubah code internal atau desain pada bagian yang sudah ada di komponen

• Liskov substitution principle
  Subclasses harus dapat di subsitusi untuk base classes. Komponen yang menggunakan base class harus dapat terus berfungsi dengan baik jika subclass dari base class diberikan pada komponen.

• Dependency inversion principle
  Begantung pada abstraksi (interface); tidak bergantung pada concretions. Semakin suatu komponen bergantung pada komponen konkrit lainnya (daripada interface), maka semakin sulit untuk meng-extend komponen tersebut.
• Interface segregation principle
  Banyak client-specific interfaces yang lebih baik daripada interface dengan satu fungsi general (umum). Untuk server class, specialized interfaces harus dibuat untuk melayani kategori utama client. Hanya operasi yang relevan dengan kategori client tertentu yang harus dispesifikasikan pada interface.

COMPONENT-LEVEL DESIGN GUIDELINES

• Komponen

1. Menetapkan konvensi penamaan untuk komponen yang dispesifikasikan sebagai bagian dari model arsitektural, kemudian di-refined dan di-elaborate sebgagai bagian dari model tingkat komponen
2. Mendapatkan nama komponen arsitektural dari problem domain dan memastikan bahwa mereka memiliki arti untuk semua stakeholders yang melihat model arsitektural tersebut (contoh: kalkulator)
3. Menggunakan nama komponen infrastruktur yang mencerminkan arti implementation-specific (contoh: stack)

• Ketergantungan dan pewarisan di UML

1. Memodel ketergantungan apapun dari left ke right dan inheritance dari top (base class) ke bottom (derived classes)
2. Menganggap modelling ketergantungan komponen apapun sebagai interface daripada merepresentasikan mereka sebagai ketergantungan antar komponen langsung

CONDUCTING COMPONENT-LEVEL DESIGN

1. Identifikasi semua design classes yang sesuai dengan problem domain, seperti yang didefinisikan pada model analisis dan model arsitektural
2. Identifikasi semua design classes yang sesuai dengan infrastructure domain (kelas ini biasanya tidak terdapat pada model analisis atau arsitektural, kelas ini mengandung komponen GUI, komponen operating systems, komponen manajemen data, komponen networking, )
3. Elaborate semua design classes yang tidak didapat sebagai reusable component (spesifikasikan message detail (struktur) ketika kelas atau komponen berkolaborasi, identifikasikan interface yang sesuai untuk setiap komponen, elaborate atribut dan definisikan tipe data serta struktur data yang dibutuhkan untuk mengimplementasikan mereka, deskripsikan aliran processing dalam setiap operasi secara detail menggunakan pseudocode atau UML activity diagram)
4. Deskripsikan persistent data sources (database dan file) dan identifikasikan kelas- kelas yang dibutuhkan untuk mengaturnya
5. Kembangkan dan elaborate representasi behavioural untuk suatu kelas atau komponen (dengan cara memperjelas UML state diagram yang dibuat untuk model analisis dan dengan memeriksa semua use case yang relevan dengan design class)
6. Elaborate deployment diagram untuk menyediakan detail implementasi tambahan (ilustrasikan lokasi dari key packages atau kelas komponen dalam sistem dengan menggunakan class instance dan menetapkan hardware spesifik dan operating system environment)
7. Faktorkan semua representasi component-level design dan selalu pertimbangkan alternatif (pertimbangkan semua solusi desain alternatif sebelum menetapkan model desain final, keputusan akhir dapat dibuat menggunakan prinsip desain dan guidelines yang telah )

DATA DESIGN AT COMPONENT-LEVEL

Desain data pada tingkat komponen berfokus pada representasi struktur data yang diakses secara langsung oleh satu atau lebih komponen software. Desain data dimulai pada saat pembuatan model analisis. Beberapa prinsip yang dipertimbangkan untuk menspesifikasikan dan mendesain struktur data adalah:

1. Prinsip analisis sistematis yang diterapkan pada fungsi dan behaviour juga harus diterapkan pada data. Representasi data flow dan konten juga harus dikembangkan dan ditinjau, objek data harus diidentifikasi, organisasi data alternatif harus dipertimbangkan, dan dampak dari data modeling pada desain software harus dievaluasi.
2. Semua struktur data dan operasi yang akan dilakukan pada masing-masing harus diidentifikasi. Desain struktur data yang efisien harus mempertimbangkan operasi yang akan dilakukan pada struktur data
3. Data dictionary harus dibuat dan digunakan untuk mendefinisikan data dan desain program. Data dictionary merepresentasikan hubungan antar object data dan konstrain pada elemen dari suatu struktur data secara eksplisit. Algoritma yang harus memanfaatkan hubungan spesifik dapat lebih mudah didefinisikan jika ada spesifikasi data seperti
4. Keputusan desain data tingkat rendah (low-level data design) harus ditunda sampai akhir dalam proses desain. Proses penyempurnaan bertahap dapat digunakan untuk desain data. Organisasi data keseluruhan dapat didefinisikan pada saat analisis requirements, di-refined saat desain data, dan dispesifikasikan dengan detail saat desain tingkat komponen. Pendekatan top-down pada desain data memberikan keuntungan yang mirip dengan pendekatan top-down pada desain software—atribut struktural utama didesain dan dievaluasi terlebih daulu, sehingga arsitektur dari data dapat ditetapkan.
5. Representasi struktur data hanya boleh diketahui oleh modul-modul yang harus menggunakan data dalam struktur secara langsung. Konsep dari information hiding dan coupling memberikan wawasan penting tentang kualitas desain software. Prinsip ini juga menyinggung pentingnya memisahkan logical view dan physical view dari sebuah object
6. Library yang mengandung struktur data yang berguna dan operasi yang dapat diterapkan pada mereka harus Struktur data dan operasi harus dilihat sebagai sumber daya untuk desain software. Struktur data dapat didesain untuk digunakan ulang (reusability). Library berisi template struktur data (tipe data abstrak) dapat mengurangi spesifikasi dan design effort untuk data.
7. Suatu desain software dan bahasa pemrograman harus mendukung spesifikasi dan realisasi tipe data Implementasi dari struktur data yang kompleks dapat dibuat rumit jika tidak tersedia spesifikasi langsung dari struktur pada bahasa pemrograman yang dipilih. Prinsip-prinsip ini membentuk dasar untuk pendekatan desain data tingkat komponen yang dapat diintegrasikan pada analisis dan aktivitas desain.

CONCLUSION

Proses desain mencakup serangkaian aktivitas yang secara perlahan mengurangi tingkat abstraksi yang merepresentasikan software. Desain tingkat komponen menggambarkan software pada suatu tingkat abstraksi yang sangat dekat dengan code. Pada tingkat komponen, software engineer harus merepresentasikan struktur data, interface, dan algoritma dalam detail yang cukup untuk memandu dalam pembuatan source code bahasa pemrograman. Untuk mencapai hal ini, desainer menggunakan salah satu dari sejumlah notasi desain yang merepresentasikan detail tingkat komponen dalam format berbasis grafik, tabel, atau tulisan. Pemrograman terstruktur adalah filosofi desain prosedural yang membatasi jumlah dan tipe dari logical constructs yang digunakan untuk merepresentasikan detail algoritma. Tujuan dari pemrograman terstruktur adalah untuk membantu desainer dalam mendefinisikan algoritma yang tidak terlalu kompleks sehingga lebih mudah untuk dibaca, dites, dan di-maintain. 

REFERENCES

Pressman, R. 2001. Software Engineering: A Practitioner’s Approach 5^th Edition. McGraw-Hill Pressman, R. 2005. Software Engineering: A Practitioner’s Approach 6^th Edition. McGraw-Hill Puntambekar, A.A. 2008. Software Engineering 1^st Edition. Technical Publications Pune Mishra, Jibitesh. 2012. Software Engineering. Pearson

Author : Yuliana Muksin, Kevin Yatshen, Maurice M. Tin, Leonardo A. Wijanto, Gary R. L. Tobing
Supervised By : Irma Kartika Wairooy, S.Kom., M.T.I