tugas tentang software reuse

[Software Reuse] [2014]

Page 1 of 23

REKAYASA PERANGKAT LUNAK

SOFTWARE REUSE

Oleh :

1. Ahmad Zaenal Muttaqin 1211503493

2. Christian Yonathan S 1211501075

3. Demmy Dwi Ramadhan 1211500176

4. Eddo Careera Iriyanto Putra 1211501877

5. Ivanny Silviana Santoso 1211501885

6. M. Kailani Ridwan 1211503568

JURUSAN ILMU KOMPUTER

FAKULTAS MATEMATIKA DAN ILMU PENGETAHUAN ALAM

UNIVERSITAS GADJAH MADA

2014


Page 2 of 23

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 3 of 23

a. Sistem Aplikasi Reuse

Seluruh sistem aplikasi dapat digunakan kembali dengan

memasukkan, tanpa berubah menjadi sistem lain atau 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, yang umumnya selama 40

tahun terakhir. Banyak library 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 4 of 23

Di Bawah ini adalah keuntungan dari software reuse:

Keuntungan Penjelasan

Peningkatan Ketergatungan 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.

Mengurangi Proses Risiko 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.

Keefektifitasan menggunakan spesialis

Daripada melakukan pekerjaan yang sama berulang-ulang, spesialis aplikasi dapat mengembangkan perangkat lunak yang dapat digunakan kembali yang merangkum pengetahuan mereka.

Standar kepatuhan Beberapa standar, seperti standar user interface yang dapat diimplementasikan sebagai satu set komponen dapat digunakan kembali. Misalnya, jika menu dalam user interface yang diimplementasikan dengan menggunakan komponen dapat digunakan kembali, semua aplikasi menyajikan format menu yang sama kepada pengguna. Penggunaan user interface standar dapat meningkatkan ketergantungan karena pengguna akan membuat kesalahan lebih sedikit ketika disajikan dengan antarmuka yang familiar.

Mempercepat Pengembangan Membawa sistem ke pasar secepat


Page 5 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 dengan penggunaan kembali.

Ada biaya yang signifikan terkait dengan pemahaman apakah komponen cocok

untuk digunakan kembali dalam situasi tertentu, dan dalam 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 Penjelasan

Meningkatkan Biaya Maintenance 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

Kurangnya Alat Pendukung 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 mendukung embedded system engineering, kurang begitu untuk alat pengembangan berorientasi objek.

Sindrom Tidak Ditemukan Disini Beberapa software engineer memilih untuk menulis ulang komponen karena mereka percaya bahwa mereka dapat memperbaikinya. Hal


Page 6 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 Menggunakan Library Komponen

Mengisi library komponen yang digunakan kembali dan memastikan pengembang software dapat menggunakan library ini bisa menjadi mahal. Proses pengembangan harus disesuaikan untuk memastikan bahwa library tersebut digunakan.

Menemukan, Memahami, dan Beradaptasi dengan komponen reusable

Komponen software harus ditemukan di library, dipahami dan, kadang-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 7 of 23

16.1.1 The Reuse 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 8 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

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 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 9 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 Penjelasan

Pola Arsitektural 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 Layanan

Sistem yang dikembangkan dengan 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 10 of 23

Aplikasi vertikal yang dapat dikonfigurasi

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.

Pengembangan Aspect-oriented software

Komponen bersama yang dijalin menjadi sebuah aplikasi di tempat yang berbeda ketika program dikompilasi.

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.

Bahkan, sebuah framework dapat menggabungkan beberapa framework

lainnya, di mana masing-masing dirancang untuk mendukung pengembangan


Page 11 of 23

bagian dari aplikasi. Anda dapat menggunakan framework untuk membuat

aplikasi lengkap atau untuk melaksanakan bagian dari aplikasi, seperti antarmuka

pengguna grafis. Ada tiga kelas dari framework:

1. Framework 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 memberikan dukungan untuk model komponen standar.

3. Framework Aplikasi 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 web (WAFS) adalah jenis yang lebih baru dan sangat

penting dari framework. WAFS yang mendukung pembangunan website dinamis

kini banyak tersedia. Arsitektur dari WAF biasanya didasarkan pada Model-View-

Controller (MVC) pola komposit (Gamma et al., 1995).


Page 12 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 dengan masing-masing presentasi tersebut.

Hal ini memungkinkan untuk pemisahan negara aplikasi dari antarmuka

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 konkret memungkinkan untuk diperpanjang.

Framework 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 13 of 23

1. Keamanan

WAFS mungkin termasuk kelas untuk membantu menerapkan

otentikasi pengguna (login) dan kontrol akses untuk memastikan bahwa

pengguna hanya dapat mengakses diizinkan 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 tidak termasuk database melainkan 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 dengan menambahkan kelas konkrit

yang mewarisi operasi dari kelas abstrak dalam rangka dan menambahkan

metode yang disebut dalam menanggapi peristiwa yang diakui oleh framework.


Page 14 of 23

Masalah dengan framework ini adalah kerumitannya yang berarti bahwa

dibutuhkan waktu yang lama 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

mengerti bagaimana metode framework berinteraksi. Ini adalah masalah umum


Page 15 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 melibatkan 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 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 16 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. Sebuah jajaran produk

software biasanya embeds domain dan platform informasi yang rinci.

Misalnya, mungkin ada jajaran produk perangkat lunak yang

bersangkutan dengan aplikasi berbasis web untuk pengelolaan

catatan 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 dukungan 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 17 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.

2) Spesialisasi Lingkungan

Versi aplikasi yang dibuat untuk menangani lingkungan 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 digunakan.

3) Spesialisasi Fungsional

Versi aplikasi diciptakan untuk pelanggan tertentu memiliki

kebutuhan yang berbeda. Sebagai contoh, 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 18 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 berikut:

Gambar 16.4 arsitektur sistem alokasi sumber daya


Page 19 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 peta database.


Page 20 of 23

Gambar 16.6 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 21 of 23

5) 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 dikonfigurasi ulang dan

konfigurasi ini mungkin melibatkan menambahkan atau menghapus komponen

dari sistem, mendefinisikan parameter dan kendala untuk komponen sistem, dan

termasuk pengetahuan tentang proses bisnis. Konfigurasi ini dapat terjadi pada

berbagai tahap dalam proses 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 22 of 23

Gambar 16.7 Konfigurasi 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 23 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.

tugas tentang software reuse

Documents