Component-level Design

Component-level design dibentuk setelah architectural design telah dibuat. Pada tahap ini, data
secara keseluruhan dan strukut program dari perangkat lunak telah ditetapkan. Tujuannya
adalah untuk menerjemahkan model desain menjadi perangkat lunak operasional.
Tetapi tingkat abstraksinya desainnya masih relatif tinggi sedangkan tingkat abstraksi
program operasionalnya rendah. What ist it? Component-level design mendefinisikan
struktur data, algoritma, karakteristik antarmuka dan mekanisme komunikasi yang
dialokasikan kepada setiap komponen dari perangkat lunak.

Who does it?

Software engineer yang mendesain component level design.

Why is it important?
Component level design merepresentasikan bagaimana detil dari kebenaran desain dan
kekonsistenan antara desain satu dengan yang lainnya, seperti data, arsitektur, dan desain
antarmuka perangkat lunak, yang mencakup stuktur data, antarmuka dan algoritma.

What is A Component?
Component adalah sebuah Modular building block untuk perangkat lunak komputer, memliki
peran dalam mendapatkan objektif dan kebutuhan system yang akan dibangun.
Component harus saling berkomunikasi dan berkolaborasi dengan component lainnya
dan juga entitas yang ada diluar cakupan perangkat lunak.

An object-Oriented View
Dalam konteks perangkat lunak object oriented, component bersikan kumpulan
kolaborasi dari class. Setiap class sudah diperinci untuk mencakup semua atribut dan operasi
yang relevan dalam implementasinya. Semua antarmuka yang memperbolehkan class
untuk berkomunikasi dan berkolaborasi dengan class desain lain harus didefinisikan. Untuk
memenuhi ini, dapat dimulai dengan analisis model dan memperinci analisis class untuk
komponen yang berelasi dengan masalah utama dan class infrastruktur untuk komponen
yang menyediakan dukungan servis kepada masalah utama.
The Traditional View
Pada konteks traditional software engineering, component adalah elemen fungsional dari
program yang menyertakan logika pemrosesan, struktur data internal yang dibutuhkan
untuk mengimplementasikan, dan sebuah antarmuka yang memperbolehkan component
untuk dilibatkan dan data dikirim ke dalamnya. Traditional component disebut juga module,
memiliki tiga peran penting:
1) Component control yang mengkoordinasikan keterlibatan komponen masalah domain,
2) Problem domain component yang mengimplementasikan fungsi yang lengkap maupun
parsial yang
dibutuhkan oleh customer,
3) Infrastruktur component yang bertanggung jawab atasfungsi yang mendukung kebutuhan
didalam masalah domain. Seperti pada object oriented component, traditional software
component diperoleh dari model analisis. Dalam kasus ini, rincian elemen komponen dari
model analisis menjadi basis bagi penurunannya. Setiap component merepresentasikan hirarki
komponen yang dipetakan ke dalam hirarki modul. Control component module berada
dekat puncak hirarki (arsitektur program), dan komponen masalah domain cenderung berada
pada bawah hirarki. Untuk mendapatkan keefektifan modul, konsep desain seperti
functional independence diterapkan sebagai komponen yang diperinci.

Process-Related View
Object-Oriented dan traditional view dari component level design yang sudah dijelaskan
sebelumnya mengasumsikan bahwa component didesain dari goresan kasar. Oleh karena itu,
diharuskan untuk membuat komponen baru berdasarkan spesifikasi yang telah didapatkan dari
model requirement. Sehingga akan ada pendekatan lainnya.
Designing Class-Based Components

Basic design Principles

Empat dasar desain prinsip diaplikasikan pada component level design dan sudah secara luas
diadopsi ketika object oriented software engineer diaplikasikan. Motivasi yang mendasari bagi
aplikasi dengan prinsip ini adalah untuk membentuk desain yang bias menerima perubahan dan
dapat mengurangi propagasi efek samping ketika terjadi perubahan. Prinsip yang dapat
digunakan sebagai panduan untuk setiap komponen perangkat lunak yang sedang dikembangkan
:

The open closed principle [OCP] “ komponen modul seharusnya dibuka untuk suatu
penambahan tetapi tertutup bagi pemodifikasian.”. secara sederhananya, komponen harus
dispesifikasikan apakah omponen tersebut diperbolehkan untuk ditambahkan tanpa harus
membuat modifikasi internal (level kode atau logika). Diperlukan sebuah abstraksi yang
bertindak sebagai buffer antara fungsi yang akan ditambahkan dengan design class itu sendiri.

The liskov Substitution Principle [LSP]. “subclass seharusnya bisa disubstitusi untuk class
dasar mereka sendiri.” Komponen yang menggunakan class dasar harus melanjutkan
untuk berfungsi dengan benar jika ada class yang diperoleh dari class dasar diberikan kepada
komponen penggantinya. LSP meminta pada setiap class yang diperoleh dari class dasar harus
menerima kontrak tersirat apapun antara class dasar dan komponen yang menggunakannya.
Kontrak adalah precondition yang harus benar sebelum komponen menggunakan class dasar
dan merupakan postcondition yang harus benar setelah komponen menggunakan class dasar.
Dependency Inversion Principle (DIP).Semakin bergantungnya sebuah component pada
component konkret lain, maka semakin sulit component tersebut dapat berkembang.
Interface Segregation Principle (ISP). Membuat interface yang spesifik untuk melayani
setiap kategori utama dari client. Release Reuse Equivalency Principle (REP). Ketika class atau
component didesign untuk digunakan secara berulang-ulang maka secara implisit sudah
terbentuk kontrak antra developer yang membuat dan orang yang akan menggunakannya.
Developer harus membuat sebuah control system yang mendukung dan mengatur versi lama dari
entitas ketika user mengupgrade ke versi terbaru.
Common Closure Principle (CCP). Class harus dikemas secara kohesif. Bila kelas dikemas
sebagai bagian dari design maka memiliki fungsi atau kebiasaan yang sama. Ketika berubah,
maka class tersebut juga harus mengalami modifikasi. Common Reuse Principle(CRP).
Ketika sebuah package berubah maka release number dar package tersebut juga harus
berubah.

Pedoman Komponen Level Desain

Komponen, arsitektur nama-nama komponen harus digambarkan dari masalah domain dan
mempunyai makna untuk semua stakeholder yang melihat model arsitektur. Interfaces,
interface menyediakan informasi penting tentang komunikasi dan kolaborasi Dependencies and
Inheritance, untuk meningkatkan perhatian, hal yang dapat dilakukan ialah membuat model
ketergantungan dari kiri ke kanan dan mewariskan dari derived classes ke base classes. Sebagai
tambahan, komponen-komponen yang saling ketergantungan harus direpresentasikan melalui
interface. Hal ini membuat sistem lebih dipertahankan.

Cohesion

Kohesi dideskripsikan sebagai “single mindedness” dari komponen. Dalam konteks komponen
level desain untuk sistem object oriented, kohesi menunjukkan komponen atau kelas yang
terenkapsulasi hanya berhubungan dengan komponen lain yang mempunyai ikatan yang
erat dengannya. Lethbridge dan Laganiere mendefenisikan beberapa jenis dari kohesi, antara
lain:

 Fungsional, bagian ini terjadi ketika modul hanya menampilkan satu komputasi yang
langsung memberikan satu hasil.
 Layer, bagian ini terjadi ketika layer yang tinggi mengakses layanan layer yang rendah,
tetapi tidak sebaliknya.
 Communicational, semua operasi dapat mengakses dan menyimpan data yang sama
didefenisikan berada dalam satu kelas.
Coupling
Komunikasi dan kolaborasi adalah elemen penting dari sistem object oriented.Terdapat
masalah ketika jumlah komunikasi dan kolaborasi mengalami kenaikkan, maka
kompleksitas dari sistem juga akan menigkat. Hal ini menyulitkan untuk
mengimplementasikan, menguji, dan memelihara perkembangan software. Coupling ialah
ukuran kualitatif dari derajat kelas yang terhubung dengan kelas lain. Ketika kelas menjadi
saling berketergantungan, maka coupling meningkat. Tujuan utama dari komponen level
desain untuk menjaga coupling tetap rendah. Kelas coupling dapat menjealskan diri sendiri
dalam bermacam-macam cara. Lethbridge dan Laganiere mendefenisikan spectrum dari
kategori coupling:

 Content Coupling
 Control Coupling
 External Coupling