Tugas Tentang Software Reuse

[Software Reuse] [2014]

16.1. Software Reuse Software reuse adalah proses dimana suatu organisasi mendefinisikan

satu set prosedur operasi yang sistematis untuk menentukan, menghasilkan, mengklasifikasikan, mengambil, dan beradaptasi artefak perangkat lunak untuk tujuan menggunakan mereka dalam kegiatan pembangunan." (Mili et al., 2002). Penggunaan kembali perangkat lunak adalah proses menciptakan sistem perangkat lunak dari sistem perangkat lunak yang ada. Reuse adalah seperti rekening tabungan. Sebelum kita kumpulkan minat, kita harus melakukan deposit, dan semakin kita masukkan ke dalam, semakin besar dividen. Rekayasa perangkat lunak berbasis Reuse adalah strategi rekayasa perangkat lunak di mana proses pembangunan diarahkan untuk menggunakan kembali perangkat lunak yang sudah ada. Meskipun penggunaan kembali diusulkan sebagai strategi pembangunan lebih dari 40 tahun yang lalu (McIlroy, 1968), hanya sejak tahun 2000 bahwa 'pembangunan dengan reuse' telah menjadi norma bagi sistem bisnis baru. Rekayasa perangkat lunak telah lebih fokus pada pengembangan asli tetapi sekarang diakui bahwa untuk mencapai perangkat lunak yang lebih baik, lebih cepat dan biaya lebih rendah, kita membutuhkan proses desain yang didasarkan pada penggunaan kembali perangkat lunak yang sistematis. Ketersediaan perangkat lunak dapat digunakan kembali telah meningkat secara dramatis. Gerakan open source berarti bahwa ada besar dapat digunakan kembali kode dasar tersedia dengan biaya rendah. Rekayasa perangkat lunak berbasis Reuse adalah sebuah pendekatan untuk pembangunan yang mencoba untuk memaksimalkan penggunaan kembali perangkat lunak yang ada. Unit perangkat lunak yang digunakan kembali mungkin ukuran yang berbeda. Sebagai contoh:

Page 2 of 23


a.

Sistem Aplikasi Reuse Seluruh

memasukkan,

sistem tanpa

aplikasi berubah

dapat

digunakan

menjadi

sistem

kembali lain

atau

dengan dengan

mengkonfigurasi aplikasi untuk pelanggan yang berbeda. Atau, keluarga aplikasi yang memiliki arsitektur yang umum, tetapi yang disesuaikan untuk pelanggan tertentu, dapat dikembangkan. b. Komponen Reuse Komponen aplikasi, mulai dari ukuran subsistem ke objek tunggal, dapat digunakan kembali. Sebagai contoh, sistem pencocokan pola yang dikembangkan sebagai bagian dari sistem pengolahan teks dapat digunakan kembali dalam sistem manajemen database. c. Obyek dan Fungsi Reuse

Komponen perangkat lunak yang melaksanakan fungsi tunggal, seperti fungsi matematika, atau kelas objek dapat digunakan kembali. Bentuk reuse, berdasarkan pada library standar, standar, yang umumnya selama 40 tahun terakhir. Banyak library fungsi fungsi dan kelas yang tersedia secara bebas. Anda dapat menggunakan kembali kelas dan fungsi di library ini dengan menghubungkan mereka dengan kode aplikasi baru dikembangkan. Di area seperti algoritma matematika dan grafis, di mana keahlian khusus yang dibutuhkan untuk mengembangkan objek efisien dan fungsi, ini adalah pendekatan yang sangat efektif. Keuntungan dari software reuse adalah bahwa biaya pengembangan secara keseluruhan dapat dikurangi. Sedikit komponen perangkat lunak harus

ditentukan,

dirancang,

dilaksanakan,

dan

divalidasi.

Namun,

pengurangan biaya adalah hanya salah satu keuntungan dari penggunaan kembali.

Page 3 of 23


Di Bawah ini adalah keuntungan dari software reuse: Keuntungan Peningkatan Ketergatungan

Mengurangi Mengurangi Proses Risiko

Keefektifitasan menggunakan spesialis

Standar kepatuhan

Mempercepat Pengembangan

Penjelasan Software Reuse, yang telah dicoba dan diuji dalam sistem kerja, harus lebih diandalkan daripada perangkat lunak baru. Desain dan implementasi kesalahannya harus ditemukan dan diperbaiki. Biaya perangkat lunak yang ada sudah diketahui, sedangkan biaya pengembangan selalu masalah pertimbangan. Ini merupakan faktor penting untuk manajemen proyek karena mengurangi margin of error dalam estimasi biaya proyek. Hal ini terutama berlaku ketika komponen perangkat lunak yang relatif besar seperti subsistem digunakan kembali. kembali. Daripada melakukan pekerjaan yang sama berulang-ulang, spesialis aplikasi dapat mengembangkan perangkat lunak yang dapat digunakan kembali yang merangkum pengetahuan mereka.

Beberapa standar, seperti standar user interface interface yang dapat diimplementasikan sebagai satu set komponen dapat digunakan kembali. Misalnya, jika menu dalam user interface yang interface diimplementasikan dengan menggunakan komponen dapat digunakan kembali, semua aplikasi menyajikan format menu yang sama kepada pengguna. Penggunaan user interface interface standar dapat meningkatkan ketergantungan karena pengguna akan membuat kesalahan lebih sedikit ketika disajikan dengan antarmuka yang familiar yang familiar . Membawa sistem ke pasar secepat Page 4 of 23


mungkin sering lebih penting daripada biaya pembangunan secara keseluruhan. Menggunakan kembali perangkat lunak dapat mempercepat produksi sistem karena kedua pengembangan dan waktu validasi dapat dikurangi. Namun, ada biaya dan masalah yang terkait d engan penggunaan kembali. Ada biaya yang signifikan terkait dengan pemahaman apakah komponen cocok untuk digunakan kembali dalam situasi tertentu, dan d alam pengujian komponen yang untuk memastikan kehandalan nya. Biaya-biaya tambahan berarti bahwa pengurangan biaya pengembangan keseluruhan melalui penggunaan kembali mungkin kurang daripada yang diantisipasi. Masalah Meningkatkan Biaya Maintenance

Kurangnya Alat Pendukung

Sindrom “Tidak Ditemukan Disini”

Penjelasan Jika source code atau komponen dari perangkat lunak yang digunakan tidak tersedia, maka biaya maintenance akan meningkat karena unsur – unsur yang digunakan kembali dari system dapat menjadi semakin tidak sesuai dengan perubahan system Beberapa perangkat lunak tidak mendukung pengembangan dengan reuse. Mungkin sulit atau tidak mungkin untuk mengintegrasikan alat-alat ini dengan sistem perpustakaan komponen. Proses perangkat lunak diasumsikan oleh alat-alat ini mungkin tidak mengambil reuse ke rekening. Hal ini terutama berlaku untuk alat-alat yang embedded system mendukung engineering, kurang begitu untuk alat pengembangan berorientasi objek. Beberapa software engineer memilih untuk menulis ulang komponen karena mereka percaya bahwa mereka dapat memperbaikinya. Hal

Page 5 of 23


ini sebagian untuk melakukan dengan kepercayaan dan sebagian hubungannya dengan fakta bahwa menulis software asli dianggap lebih menantang daripada menggunakan kembali software orang lain. Membuat, Memelihara, dan Mengisi library komponen yang Menggunakan Library Komponen Komponen digunakan kembali dan memastikan software pengembang dapat menggunakan library ini ini bisa menjadi mahal. Proses pengembangan harus disesuaikan untuk memastikan bahwa library tersebut tersebut digunakan. Menemukan, Memahami, dan Komponen software harus ditemukan Beradaptasi dengan komponen di library , dipahami dan, kadangreusable kadang, diadaptasikan untuk bekerja di lingkungan yang baru. Engineering harus cukup yakin untuk menemukan komponen di library sebelum mereka termasuk pencarian komponen sebagai bagian dari proses perkembangan normal mereka.

Page 6 of 23


16.1.1 The Reuse R euse Landscape

Gambar 16.1. The Reuse Landscape

Mengingat array ini teknik untuk digunakan kembali, pertanyaan kuncinya adalah "yang merupakan teknik yang paling tepat untuk digunakan dalam situasi tertentu?" Jelas, ini tergantung pada persyaratan untuk sistem yang dikembangkan, teknologi dan aset dapat digunakan kembali tersedia, dan keahlian dari tim pengembangan. Faktor-faktor utama yang harus Anda pertimbangkan ketika merencanakan penggunaan kembali adalah: a. Jadwal pengembangan software Jika perangkat lunak tersebut harus dikembangkan dengan cepat, Anda harus mencoba untuk menggunakan kembali off-the-shelf sistem daripada komponen individu. Ini adalah besar-grain aset dapat digunakan kembali. Meskipun cocok dengan kebutuhan mungkin tidak sempurna, pendekatan ini meminimalkan jumlah pembangunan yang dibutuhkan.

Page 7 of 23


b. Masa waktu software yang diharapkan Jika Anda sedang mengembangkan sebuah sistem lama seumur hidup, Anda harus fokus pada pemeliharaan sistem. Anda seharusnya tidak hanya berpikir tentang manfaat langsung dari penggunaan kembali tetapi juga implikasi jangka panjang. c. Latar belakang, keterampilan, dan pengalaman dari tim pengembangan Semua teknologi reuse cukup kompleks dan Anda perlu cukup banyak waktu untuk memahami dan menggunakannya secara efektif. Oleh karena itu, jika tim pengembangan memiliki keterampilan di daerah tertentu, ini mungkin di mana Anda harus fokus. d. Kekritisan perangkat lunak dan kebutuhan non-fungsional non-fungsional Untuk sistem kritis yang harus disertifikasi oleh regulator eksternal, Anda mungkin harus membuat kasus ketergantungan untuk sistem (dibahas dalam Bab 15). Hal ini sulit jika Anda tidak memiliki akses ke kode sumber dari perangkat lunak. Jika perangkat lunak Anda memiliki persyaratan kinerja yang ketat, mungkin mustahil untuk menggunakan strategi seperti penggunaan kembali berbasis-generator, di mana Anda menghasilkan kode dari domain representasi tertentu dapat digunakan kembali dari suatu sistem. Sistem ini sering menghasilkan kode yang relatif tidak efisien. e. Aplikasi domain Dalam beberapa domain aplikasi, seperti manufaktur dan informasi medis sistem, ada beberapa produk generik yang dapat digunakan kembali dengan mengkonfigurasi mereka untuk situasi lokal. Jika Anda bekerja di domain seperti itu, Anda harus h arus selalu mempertimbangkan ini sebagai pilihan. f.

Platform yang digunakan oleh sistem akan berjalan Beberapa model komponen, seperti NET, khusus untuk platform

Microsoft. Demikian pula, sistem aplikasi generik mungkin platform-spesifik

Page 8 of 23


dan Anda mungkin hanya dapat menggunakan kembali ini jika sistem Anda dirancang untuk platform yang sama. Pendekatan yang mendukung system reuse adalah: Pendekatan Pola Arsitektural Arsitektural

Penjelasan Arsitektur perangkat lunak standar yang mendukung jenis umum dari sistem aplikasi yang digunakan sebagai dasar aplikasi. Pola Desain Abstraksi generik yang terjadi di seluruh aplikasi yang direpresentasikan sebagai pola desain menunjukkan objek – objek abstrak dan objek nyata dan interaksi. Pengembangan Component-based Sistem yang dikembangkan dengan mengintegrasikan komponen (kumpulan objek) yang sesuai dengan standar komponen model. Framework Aplikasi Kumpulan class abstrak dan konkret disesuaikan dan diperluas untuk membuat sistem aplikasi. Sistem Pembukus Warisan Sistem warisan yang 'dibungkus' dengan mendefinisikan satu set antarmuka dan menyediakan akses ke sistem warisan ini melalui antarmuka ini. Sistem yang Berorientasi pada Sistem yang dikembangkan dengan Layanan menghubungkan layanan bersama, yang dapat disediakan dari eksternal. Jajaran Produk Perangkat Lunak Sebuah tipe aplikasi ini secara umum meliputi arsitektur biasa sehingga dapat disesuaikan untuk pelanggan yang berbeda. COTS product reuse Sistem yang dikembangkan dengan mengkonfigurasi dan mengintegrasikan sistem aplikasi yang sudah ada. . System ERP Sistem berskala besar yang merangkum fungsi bisnis generik dan aturan dikonfigurasi untuk sebuah organisasi.

Page 9 of 23


Sistem generik dirancang sehingga mereka dapat dikonfigurasi untuk kebutuhan pelanggan sistem tertentu. Library Program Kelas dan fungsi librari yang menerapkan abstraksi umum digunakan untuk digunakan kembali. Model-driven engineering Software direpresentasikan sebagai model domain dan implementasi model independen dan kode yang dihasilkan dari model ini. Program generators Sebuah sistem generator yang memiliki ilmu dari jenis aplikasi dan digunakan untuk menghasilkan sistem dalam domain dari pengguna disediakan model sistem. Aspect-oriented Komponen bersama yang dijalin Pengembangan software menjadi sebuah aplikasi di tempat yang berbeda ketika program dikompilasi. Aplikasi vertikal dikonfigurasi

yang

dapat

16.1.2 Application Frameworks Frameworks adalah entitas cukup besar yang dapat digunakan kembali. Frameworks berada di suatu tempat antara system dan komponen reuse. Frameworks adalah desain sub-sistem yang terdiri dari kumpulan kelas abstrak

dan konkret dan antarmuka di antara mereka. Sub-sistem diimplementasikan dengan menambahkan komponen untuk mengisi bagian dari desain dan dengan instantiating class abstrak dalam frameworks. Frameworks mendukung desain ulang bahwa mereka menyediakan

arsitektur frameworks untuk aplikasi serta penggunaan kembali kelas khusus dalam sistem. Arsitektur didefinisikan oleh kelas objek dan interaksi mereka. Kelas digunakan kembali secara langsung dan dapat diperpanjang menggunakan fitur seperti pewarisan. framework dapat framework Bahkan, sebuah framework dapat menggabungkan beberapa framework

lainnya, di mana masing-masing dirancang untuk mendukung pengembangan

Page 10 of 23


bagian dari aplikasi. Anda dapat menggunakan framework untuk membuat aplikasi lengkap atau untuk melaksanakan bagian dar i aplikasi, seperti antarmuka pengguna grafis. Ada tiga kelas dari framework : 1. Framework Infrastruktur Infrastruktur Sistem Framework ini mendukung pengembangan infrastruktur sistem

seperti komunikasi, antarmuka pengguna, dan kompiler (Schmidt, 1997). 2. Framework Integrasi Middleware

Terdiri dari serangkaian standar dan kelas objek yang terkait yang mendukung komunikasi komponen dan pertukaran informasi. Contoh dari jenis framework termasuk NET Microsoft dan Enterprise Java Beans (EJB). Framework ini ini memberika m emberikan n dukungan untuk model komponen standar.

3. Framework Apli Apli kasi Enterprise. Enterprise. Ini berkaitan dengan domain aplikasi tertentu seperti telekomunikasi atau sistem keuangan (Baumer, et al., 1997). Ini menanamkan aplikasi pengetahuan domain dan mendukung pengembangan aplikasi pengguna akhir. Framework aplikasi aplikasi web (WAFS) adalah jenis yang lebih baru dan sangat

penting dari framework . WAFS yang mendukung pembangunan website dinamis kini banyak tersedia. Arsitektur dari WAF W AF biasanya didasarkan pada Model-ViewController (MVC) pola komposit (Gamma et al., 1995 ).

Page 11 of 23


Gambar 16.2. Pola Model-View-Controller Pola MVC awalnya diusulkan pada 1980-an sebagai pendekatan untuk desain GUI yang memungkinkan untuk beberapa presentasi dari sebuah objek dan gaya yang terpisah dari interaksi interaksi dengan masing-masing presentasi presentasi tersebut. Hal ini memungkinkan untuk pemisahan negara aplikasi dari antarmuka framework MVC pengguna ke aplikasi. Sebuah framework MVC mendukung penyajian data dalam

berbagai cara dan memungkinkan interaksi dengan masing-masing presentasi tersebut. Bila data tersebut dimodifikasi melalui salah satu presentasi, model system berubah dan pengendali yang terkait dengan setiap tampilan

memperbarui presentasi mereka. Sebagai contoh, sebuah kerangka kerja MVC termasuk pola Observer, pola Strategi, pola komposit, dan sejumlah orang lain. Sifat umum pola dan penggunaan dari kelas abstrak dan d an konkret memungkinkan untuk diperpanjang. Framework aplikasi aplikasi web biasanya menggabungkan satu atau lebih khusus framework yang mendukung fitur aplikasi spesifik. Meskipun masing-masing framework meliputi fungsi yang sedikit berbeda, sebagian besar framework

aplikasi web mendukung fitur berikut:

Page 12 of 23


1. Keamanan WAFS mungkin termasuk kelas untuk membantu menerapkan otentikasi pengguna (login) dan kontrol akses untuk memastikan bahwa pengguna hanya dapat mengakses mengakses diizinkan dii zinkan fungsi dalam sistem. 2. halaman web dinamis Kelas disediakan untuk membantu Anda menentukan halaman web template dan untuk mengisi ini dinamis dengan data dari sistem database. 3. Dukungan Basis Data Framework biasanya biasanya tidak tida k termasuk database melainkan menganggap menganggap

bahwa database yang terpisah, seperti MySQL, akan digunakan. Framework dapat memberikan kelas yang menyediakan antarmuka abstrak ke database yang berbeda. 4. Manajemen Sesi Kelas untuk membuat dan mengelola sesi (sejumlah interaksi dengan sistem oleh pengguna) biasanya bagian dari WAF. 5. Interaksi Pengguna Kebanyakan web framework sekarang memberikan dukungan AJAX (Holdener, 2008), yang memungkinkan lebih halaman web interaktif yang akan dibuat. Framework generik dan diperluas untuk membuat aplikasi yang lebih

spesifik atau sub-sistem. Mereka menyediakan arsitektur framework untuk sistem. Memperluas framework melibatkan melibatkan dengan menambahkan kelas konkrit yang mewarisi operasi dari kelas abstrak dalam rangka dan menambahkan framework . metode yang disebut dalam menanggapi peristiwa yang diakui oleh framework

Page 13 of 23


Masalah dengan framework ini adalah kerumitannya yang berarti bahwa dibutuhkan waktu yang lama l ama untuk menggunakannya secara efektif.

Gambar 16.3. Inversi Kontrol dalam Framework Namun, framework biasanya lebih umum daripada produk software , yang berfokus pada keluarga tertentu dari sistem aplikasi. Misalnya, Anda dapat menggunakan framework berbasis web untuk membangun berbagai jenis aplikasi berbasis web. Salah satunya mungkin produk software yang mendukung meja bantuan berbasis web. ' Help desk product line' mungkin lebih khusus untuk memberikan jenis dukungan khusus help desk. Framework merupakan pendekatan yang efektif untuk menggunakan

kembali, tetapi mahal untuk memperkenalkan ke dalam proses pengembangan perangkat lunak. Mereka dasarnya kompleks dan dapat memakan waktu beberapa bulan untuk belajar menggunakannya. Ini bisa sulit dan mahal untuk mengevaluasi framework yang tersedia untuk memilih yang paling sesuai. Debugging aplikasi berbasis framework sulit karena Anda mungkin tidak framework berinteraksi. Ini adalah masalah umum mengerti bagaimana metode framework

Page 14 of 23


dengan software yang dapat digunakan kembali. Alat debugging dapat memberikan informasi tentang komponen sistem

reuse,

yang seorang

pengembang tidak mengerti. 16.2 Jajaran Produk Perangkat Lunak Jajaran produk perangkat lunak atau keluarga aplikasi adalah aplikasi dengan fungsi generik yang dapat disesuaikan dan dikonfigurasi untuk digunakan dalam konteks tertentu. Sebuah Jajaran produk perangkat lunak adalah seperangkat aplikasi dengan arsitektur yang umum dan komponen bersama, dengan masing-masing aplikasi khusus untuk mencerminkan kebutuhan yang berbeda. Jajaran produk perangkat lunak biasanya muncul dari aplikasi yang ada. Artinya, sebuah organisasi mengembangkan aplikasi kemudian, ketika sistem serupa diperlukan, informal menggunakan kembali kode dari ini dalam aplikasi baru.

Proses

yang

sama

digunakan

sebagai

aplikasi

sejenis

lainnya

dikembangkan. Namun, perubahan cenderung struktur aplikasi korup demikian, karena lebih banyak kasus baru dikembangkan, menjadi semakin sulit untuk membuat versi baru. Oleh karena itu, keputusan untuk merancang Jajaran produk generik kiranya dibuat. Ini m elibatkan mengidentifikasi mengidentifikasi fungsi umum dalam kasus produk dan termasuk ini dalam aplikasi dasar, yang kemudian digunakan untuk pengembangan di kemudian hari. . Aplikasi berbasis ini sengaja disusun untuk menyederhanakan menyederhanakan penggunaan kembali dan konfigurasi ulang. Framework aplikasi dan jajaran produk perangkat lunak tentu saja memiliki banyak kesamaan. Keduanya mendukung arsitektur dan komponen umum, dan membutuhkan pengembangan baru untuk membuat versi tertentu dari sistem. Perbedaan utama antara pendekatan ini adalah sebagai berikut:

Page 15 of 23


1)

Framework Aplikasi mengandalkan fitur berorientasi objek seperti pewarisan dan polimorfisme untuk menerapkan ekstensi untuk kerangka. Umumnya, kode framework tidak diubah dan modifikasi yang mungkin terbatas pada apa pun yang diperbolehkan oleh framework. jajaran produk perangkat lunak tidak selalu dibuat menggunakan pendekatan berorientasi objek. Komponen aplikasi berubah, dihapus, atau ditulis ulang. Tidak ada batasan, pada prinsipnya setidaknya, untuk perubahan yang dapat dibuat .

2)

Framework aplikasi yang terutama difokuskan pada penyediaan teknis daripada dukungan spesifik domain. Misalnya, ada framework aplikasi untuk membuat aplikasi berbasis web. S ebuah jajaran produk software biasanya embeds domain dan platform info rmasi yang rinci. Misalnya, mungkin ada jajaran produk perangkat lunak yang bersangkutan dengan aplikasi berbasis web untuk pengelolaan catatan kesehatan. kesehatan.

3)

Jajaran produk perangkat lunak sering mengontrol aplikasi untuk peralatan. Misalnya, mungkin ada jajaran produk perangkat lunak untuk keluarga printer. Ini berarti bahwa jajaran produk harus menyediakan

dukungan

untuk

perangkat

keras

antarmuka.

framework aplikasi biasanya software-oriented dan mereka jarang memberikan memberikan dukungan d ukungan untuk perangkat keras antarmuka.

4)

Jajaran produk perangkat lunak yang terdiri dari keluarga aplikasi yang terkait, yang dimiliki oleh organisasi yang sama. Ketika Anda membuat aplikasi baru, titik awal Anda anggota terdekat dari keluarga aplikasi, bukan aplikasi inti generik.

Jika Anda mengembangkan jajaran produk perangkat lunak menggunakan bahasa pemrograman berorientasi objek, maka Anda dapat menggunakan framwork aplikasi sebagai dasar untuk sistem. Anda membuat inti dari jajaran produk

dengan

memperluas

framework

dengan

komponen

tertentu

Page 16 of 23


menggunakan mekanisme built-in versi sistem untuk pelanggan yang berbeda diciptakan. Berbagai jenis spesialisasi jajaran produk perangkat lunak dapat dikembangkan: 1)

Spesialisasi Platform Versi aplikasi yang dikembangkan untuk platform yang berbeda. Sebagai contoh, versi aplikasi mungkin ada untuk Windows, Mac OS, dan platform Linux. Dalam hal ini, fungsi aplikasi biasanya tidak berubah; hanya komponen-komponen yang antarmuka dengan perangkat keras dan sistem operasi yang dimodifikasi. dimodifikasi.

2)

Spesialisasi Lingkungan Versi Versi aplikasi yang dibuat untuk menangani menangani lingkungan kerjadan kerjadan dan perangkat periferal tertentu. Sebagai contoh, sistem untuk layanan keadaan darurat mungkin ada dalam versi yang berbeda, tergantung pada sistem komunikasi. Dalam hal ini, komponen sistem berubah untuk mencerminkan fungsi peralatan komunikasi yang d igunakan.

3)

Spesialisasi Fungsional Versi

aplikasi

kebutuhan

diciptakan

yang

berbeda.

untuk

pelanggan

Sebagai

contoh,

tertentu

memiliki

sistem

otomasi

perpustakaan dapat dimodifikasi tergantung pada apakah itu digunakan di perpustakaan umum, perpustakaan referensi, atau perpustakaan

universitas.

Dalam

hal

ini,

komponen

yang

melaksanakan fungsi dapat dimodifikasi dan komponen baru ditambahkan ke sistem 4)

Proses spesialisasi Sistem ini disesuaikan untuk mengatasi proses bisnis yang spesifik. Sebagai contoh, sistem pemesanan dapat disesuaikan untuk mengatasi proses pemesanan terpusat dalam satu perusahaan dan proses didistribusikan di negara lain.

Page 17 of 23


Arsitektur dari jajaran produk perangkat lunak sering mencerminkan aplikasi tertentu, gaya arsitektur umum atau pola Arsitektur harus disusun sedemikian rupa untuk memisahkan sub-sistem yang berbeda dan untuk memungkinkan mereka untuk dimodifikasi. Arsitektur juga harus memisahkan entitas dan deskripsi mereka dan tingkat yang lebih tinggi dalam entitas sistem akses melalui deskripsi bukan langsung. Sistem pengiriman ini adalah contoh dari arsitektur pengelolaan sumber daya (Gambar 16.4). Anda dapat melihat bagaimana struktur empat lapisan ini dipakai pada Gambar 16.5, yang menunjukkan modul yang mungkin dimasukkan dalam jajaran produk sistem pengirim. Komponen pada tiap tingkat dalam sistem jajaran produk adalah sebagai sebagai berikut:

Gambar 16.4 arsitektur sistem alokasi sumber daya

Page 18 of 23


Gambar 16.5 arsitektur jajaran produk dari sistem dispatcher Komponen pada tiap tingkat dalam sistem jajaran produk adalah sebagai berikut: 1. Pada tingkat UI, ada komponen untuk tampilan operator dan komunikasi; 2.Di tingkat I / O manajemen, ada komponen yang menangani otentikasi, pelaporan

dan

rute

perencanaan;

3 Di tingkat manajemen sumber daya, ada komponen untuk lokasi kendaraan dan pengiriman, mengelola Status kendaraan dan insiden logging; 4. Database mencakup peralatan, kendaraan dan p eta database.

Page 19 of 23


Gambar 16.6 Produk Produk contoh pengembangan Gambar 16.6 menunjukkan langkah-langkah yang terlibat dalam memperluas jajaran produk perangkat lunak untuk membuat aplikasi baru. Langkah-langkah yang terlibat dalam proses umum ini adalah sebagai berikut: 1) Memperoleh persyaratan pemangku kepentingan Anda mungkin mulai dengan persyaratan proses rekayasa normal. Namun, karena sistem sudah ada, Anda akan perlu untuk menunjukkan sistem dan bereksperimen pemangku kepentingan dengan

itu,

mengungkapkan

kebutuhan

mereka

sebagai

modifikasi fungsi yang disediakan. 2) Pilih sistem yang sudah ada dan yang paling cocok dengan persyaratan Ketika membuat anggota baru dari jajaran produk, Anda bisa mulai dengan productinstance terdekat. Persyaratan dianalisis dan anggota keluarga yang adalah yang paling cocok dipilih untuk modifikasi. 3) persyaratan renegosiasi Sebagai rincian lebih lanjut dari perubahan yang diperlukan muncul dan proyek yang direncanakan, mungkin ada beberapa persyaratan negosiasi ulang untuk meminimalkan perubahan yang diperlukan. 4) Beradaptasi sistem yang ada Modul baru dikembangkan untuk sistem yang ada dan modul sistem yang ada disesuaikan untuk memenuhi persyaratan baru.

Page 20 of 23


5) Memberikan Memberikan anggota keluarga baru Contoh baru dari jajaran produk dikirim ke pelanggan. Pada tahap ini, Anda harus mendokumentasikan fitur utamanya sehingga mungkin digunakan sebagai dasar untuk pengembangan sistem lain di masa depan. Lini produk perangkat lunak yang dirancang untuk di konfigurasi konfigurasi ulang dan konfigurasi ini mungkin melibatkan menambahkan atau menghapus komponen dari sistem, mendefinisikan parameter dan kendala u ntuk komponen sistem, dan termasuk pengetahuan tentang proses bisnis. Konfigurasi ini dapat terjadi pada berbagai tahap dalam proses p roses pembangunan: 1. Konfigurasi desain waktu Organisasi yang mengembangkan perangkat lunak dapat memodifikasi produk umum secara garis inti dengan mengembangkan, memilih, atau mengadaptasi komponen untuk menciptakan sistem baru untuk pelanggan. 2. Konfigurasi penyebaran waktu Sebuah sistem generik dirancang untuk konfigurasi oleh pelanggan atau konsultan yang bekerja dengan pelanggan. Pengetahuan tentang kebutuhan spesifik pelanggan dan lingkungan operasi sistem tertanam dalam satu set file konfigurasi yang digunakan oleh sistem generik. Ketika sistem dikonfigurasi pada saat desain, pemasok dimulai dengan baik sistem generik atau contoh produk yang sudah ada. Dengan memodifikasi dan memperluas modul pada sistem ini, mereka menciptakan sistem khusus yang memberikan fungsionalitas pelanggan yang diperlukan. Hal ini biasanya melibatkan perubahan dan memperluas kode program dari sistem sehingga fleksibilitas yang lebih besar mungkin dibandingkan dengan konfigurasi penyebaran waktu.

Page 21 of 23


Gambar 16.7 Konfigurasi penyebaran-waktu penyebaran-waktu Konfigurasi penyebaran waktu melibatkan menggunakan alat konfigurasi untuk membuat suatu konfigurasi sistem tertentu yang tercatat dalam database dikonfigurasi atau sebagai set file konfigurasi (Gambar 16.7). Sistem akan mengeksekusi untuk berkonsultasi dengan database ketika menjalankan sehingga fungsinya dapat khusus untuk konteks pelaksanaannya. Ada beberapa tingkat konfigurasi penyebaran waktu yang dapat diberikan dalam suatu sistem: 1.

Komponen seleksi, di mana Anda memilih modul dalam suatu sistem yang menyediakan fungsionalitas yang diperlukan. Misalnya, dalam sistem informasi pasien, Anda dapat memilih komponen manajemen gambar yang memungkinkan Anda untuk menghubungkan gambar medis (x-ray, CT scan, dll) untuk rekam medis pasien.

2.

Workflow dan aturan definisi, di mana Anda menentukan alur kerja (bagaimana informasi diproses, tahap demi tahap) dan aturan validasi yang harus berlaku untuk informasi yang dimasukkan oleh pengguna atau yang dihasilkan oleh sistem.

Page 22 of 23


3.

Definisi Parameter, di mana Anda menentukan nilai-nilai parameter sistem tertentu yang mencerminkan contoh aplikasi yang Anda ciptakan. Misalnya, Anda dapat menentukan panjang maksimum kolom untuk data input oleh pengguna atau karakteristik perangkat keras yang melekat pada sistem.

Page 23 of 23

Tugas Tentang Software Reuse

Recommend Documents