Proses model khusus menggunakan banyak fitur yang diperoleh dari satu atau beberapa model tradisional yang telah dijelaskan sebelumnya. Namun, model tersebut umumnya dipilih ketika pendekatan rekayasa perangkat lunak yang sangat spesifik atau terbatas telah dipilih. Dengan demikian, model proses khusus dirancang untuk memenuhi kebutuhan khusus yang tidak dapat dipenuhi oleh model tradisional.
1.1 Component-Based Development
Commercial off-the-shelf (COTS) software components dibangun oleh vendor sebagai produk yang dapat menghadirkan fungsionalitas tertentu, dan dilengkapi dengan antarmuka yang terdefinisi dengan baik sehingga komponen tersebut dapat diintegrasikan ke dalam perangkat lunak yang akan dibuat. Model pengembangan berbasis komponen menggabungkan beberapa fitur dari model spiral. Model tersebut merupakan pendekatan evolusioner yang membutuhkan proses pengulangan dalam pembuatan perangkat lunak. Namun, model pengembangan berbasis komponen memanfaatkan aplikasi dari komponen perangkat lunak yang sudah dikemas sebelumnya.
Proses pemodelan dan konstruksi dimulai dengan mengidentifikasi calon komponen. Komponen-komponen tersebut dapat dirancang sebagai modul perangkat lunak konvensional, kelas berorientasi objek, atau paket kelas. Meskipun teknologi pembuatan komponennya berbeda-beda, model pengembangan berbasis komponen memiliki tahapan yang sama (diterapkan dengan menggunakan pendekatan evolusi), yaitu:
- Produk berbasis komponen yang tersedia diteliti dan dievaluasi untuk domain aplikasi yang dimaksud.
- Pertimbangan dilakukan terhadap masalah integrasi komponen.
- Arsitektur perangkat lunak direncanakan agar dapat menampung komponen-komponen tersebut.
- Komponen-komponen tersebut diintegrasikan ke dalam arsitektur.
- Dilakukan pengujian menyeluruh untuk memastikan bahwa fungsionalitas yang tepat dapat tercapai.
Penerapan model pengembangan berbasis komponen akan memungkinkan penggunaan kembali perangkat lunak dan memberikan manfaat yang dapat diukur bagi insinyur perangkat lunak. Dalam hal ini, tim rekayasa perangkat lunak dapat memperoleh pengurangan waktu siklus pengembangan dan biaya proyek dengan mengadopsi budaya penggunaan kembali komponen.
1.2 The Formal Methods Model
Model metode formal terdiri dari serangkaian aktivitas yang bertujuan untuk membuat spesifikasi matematis formal perangkat lunak komputer. Dengan menggunakan notasi matematis yang ketat, metode formal memungkinkan pengguna untuk menentukan, mengembangkan, dan memverifikasi sistem berbasis komputer. Beberapa organisasi pengembangan perangkat lunak saat ini menerapkan variasi dari pendekatan ini yang dikenal sebagai rekayasa perangkat lunak ruang bersih.
Ketika digunakan dalam pengembangan perangkat lunak, metode formal dapat membantu mengatasi banyak masalah yang sulit diatasi oleh paradigma rekayasa perangkat lunak lainnya. Dalam hal ini, ambiguitas, ketidaklengkapan, dan ketidakkonsistenan dapat diidentifikasi dan diperbaiki lebih mudah melalui analisis matematis yang sistematis, daripada hanya dengan tinjauan ad hoc. Selain itu, ketika metode formal digunakan dalam desain, mereka dapat digunakan untuk memverifikasi program dan menemukan kesalahan yang mungkin tidak terdeteksi.
Walaupun tidak banyak digunakan, model metode formal memiliki potensi untuk menghasilkan perangkat lunak yang bebas dari kesalahan. Meski begitu, beberapa orang mengkhawatirkan penerapannya di lingkungan bisnis:
- Saat ini, pengembangan model formal membutuhkan waktu dan biaya yang cukup besar.
- Diperlukan pelatihan yang komprehensif karena tidak semua pengembang perangkat lunak memiliki latar belakang yang dibutuhkan untuk menerapkan metode formal.
- Mengkomunikasikan model kepada pelanggan yang tidak memiliki latar belakang teknis yang memadai bisa menjadi suatu tantangan.
Meskipun ada kekhawatiran, metode formal telah dianut oleh sebagian pengembang perangkat lunak yang membangun aplikasi yang kritis terhadap keselamatan.
1.3 Aspect-Oriented Software Development
Kompleksitas pembuatan perangkat lunak selalu melibatkan fitur, fungsi, dan konten informasi yang di-localize. Fitur-fitur ini dimodelkan sebagai komponen seperti kelas-kelas berbasis objek dan kemudian dikembangkan dalam kerangka sistem. Dalam sistem komputer modern yang semakin kompleks, perhatian khusus diberikan pada properti tertentu seperti keamanan atau toleransi kesalahan yang mempengaruhi keseluruhan arsitektur. Kekhawatiran lain dapat mempengaruhi fungsi, seperti penerapan aturan bisnis, atau bersifat sistemik seperti sinkronisasi tugas atau manajemen memori.
Jika beberapa kekhawatiran melibatkan beberapa fitur, fungsi, dan informasi dari sebuah sistem, maka masalah tersebut disebut sebagai masalah lintas sektoral. Karakteristik aspek menentukan masalah lintas sektoral yang mempengaruhi arsitektur perangkat lunak. Pendekatan Aspect-oriented software development (AOSD) atau aspect-oriented programming (AOP), merupakan suatu paradigma rekayasa perangkat lunak baru yang memberikan proses dan pendekatan metodologis untuk mendefinisikan, menentukan, merancang, dan membangun aspek, yaitu "mekanisme di luar subrutin dan pewarisan untuk melokalkan ekspresi keprihatinan lintas sektoral".
Grundy membahas secara lebih lanjut tentang aspek dalam konteks aspect-oriented component engineering (AOCE):
Dalam rekayasa komponen berorientasi aspek (AOCE), konsep irisan horizontal digunakan untuk karakterisasi sifat lintas sektoral dari komponen perangkat lunak yang didekomposisi secara vertikal, disebut "aspek". Aspek sistemik meliputi antarmuka pengguna, kerja kolaboratif, distribusi, persistensi, manajemen memori, pemrosesan transaksi, keamanan, integritas, dan lain-lain. Komponen dapat memiliki satu atau lebih "detail aspek" yang berkaitan dengan aspek tertentu, seperti mekanisme tampilan dan keterjangkauan yang dapat diperluas untuk aspek antarmuka pengguna, atau pembangkitan peristiwa, pengangkutan, dan penerimaan untuk aspek distribusi. Detail aspek memiliki sejumlah properti yang berkaitan dengan karakteristik fungsional dan/atau non-fungsional dari detail tersebut.
Proses pengembangan perangkat lunak berorientasi aspek masih belum matang. Namun, kemungkinan besar proses tersebut akan mengadopsi karakteristik model evolusioner dan konkuren. Model evolusi cocok karena aspek diidentifikasi dan dibangun secara independen. Sifat paralel dari pengembangan bersamaan juga sangat penting karena aspek memengaruhi komponen perangkat lunak secara langsung, meskipun dibangun secara terpisah. Oleh karena itu, penting untuk memastikan komunikasi yang efektif antara aktivitas rekayasa dan konstruksi aspek dan komponen melalui komunikasi asinkron.
Untuk membahas pengembangan perangkat lunak berorientasi aspek secara terperinci, sebaiknya merujuk pada buku yang secara khusus mengulas topik tersebut.
Source: Pressman, Roger S. 2010. Software engineering : A Practitioner’s Approach (7th. Edition). New York: McGraw-Hill Higher Education.
Comments
Post a Comment