PERANCANGAN DENGAN PEMAKAIAN ULANG · PDF fileMemahami pengertian kerabat aplikasi dan memahami bagaimana kerabat aplikasi merupakan cara yang efektif ... Abstraksi domain yang stabil

PERANCANGAN DENGAN

PEMAKAIAN ULANG

REKAYASA PERANGKAT LUNAK

(SOFTWARE ENGINEERING)

P

T

I

K

Tujuan Memahami keuntungan pemakaian ulang komponen-

komponen perangkat lunak dan beberapa masalah pemakaian ulang dapat muncul

Memahami berbagai tipe komponen yang dapat dipakai ulang dan proses-proses perancangan komponen-komponen untuk pemakaian ulang tersebut

Memahami pengertian kerabat aplikasi dan memahami bagaimana kerabat aplikasi merupakan cara yang efektif dalam pemakaian ulang perangkat lunak

Memahami bagaimana pola merupakan abstraksi tingkat tinggi yang mempromosikan perancangan dengan pemakaian ulang pada pengembangan berorientasi objek

Materi

Pengembangan Berbasis Komponen

Kerabat Aplikasi

Pola Perancangan

Literatur

Sommerville, Ian; Software Engineering, 6th

Addison Wesley Publishing Company, 2001

Pendahuluan • Proses perancangan pada sebagian besar disiplin ilmu didasarkan

pada pemakaian ulang komponen

• Pemakaian ulang perangkat lunak harus diperhitungkan pada saat

perancangan perangkat lunak atau proses rekayasa persyaratan.

• Pemakaian ulang yang oportunistik mungkin dilakukan pada saat

pemrograman, ketika ditemukan komponen yang memenuhi suatu

persyaratan

• Pemakaian ulang yang sistematik menuntut proses perancangan

yang mempertimbangkan bagaimana desain yang sudah ada dapat

dipakai ulang dan secara ekplisit membuat desain berdasarkan

komponen perangkat yang sudah ada.

Pendahuluan

• Rekayasa perangkat lunak yang berbasis pemakaian ulang

merupakan pendekatan terhadap pengembangan yang mencoba

memaksimalkan pemakaian ulang perangkat lunak yang ada.

• Unit perangkat lunak yang dipakai ulang bisa berukuran sangat

berbeda, misalnya:

1) Pemakaian Ulang Sistem Aplikasi

2) Pemakaian Ulang Komponen

3) Pemakaian Ulang Fungsi

• Keuntungan yang jelas dari metode ini adalah diperkecilnya biaya

pengembangan secara keseluruhan.

Pendahuluan

Keuntungan pemakaian ulang perangkat lunak

Keuntungan Keterangan

Keandalan bertambah Komponen yang dipakai ulang, yang telah

digunakan pada system yang berjalan, seharusnya

lebih dapat diandalkan daripada komponen baru.

Komponen ini telah digunakan dan diuji pada

berbagi lingkungan. Kesalahan perancangan dan

implementasi ditemukan dan dihilangkan pada

pemakaia awal komponen tersebut, sehingga

memperkecil jumlah kegagalan pada pemakaian

ulang.

Resiko proses diperkecil Jika suatu komponen telah ada, ketidakpastian

biaya pemakaian ulang menjadi lebih kecil

daripada biaya pengembangan. Ini merupakan

factor penting untuk manajemen proyek karena

memperkecil ketidakpastian dalam estimasi biaya

proyek. Hal ini terutama berlaku ketika komponen-

komponen yang relative besar seperti subsistem

dipakai ulang.

Pendahuluan

Keuntungan Keterangan

Pemakaian spesialis yang efektif Spesialis aplikasi tidak melakukan

pekerjaan yang sama pada berbagai

proyek, tapi mereka dapat mengembangkan

komponen-komponen yang dapat dipakai

ulang, yang mengenkapsulasi pengetahuan

mereka

Pemenuhan standar Beberapa standar, seperti standar interface,

dapat diimplementasikan sebagai satu set

komponen standar.

Pengembangan yang dipercepat Membawa suatu system ke pasar secepat

mungkin, seringkali lebih penting dari biaya

pengembangan keseluruhan. Pemakaian

ulang komponen mempercepat produksi

karena waktu pengembangan dan waktu

validasi dan dipersingkat

Pendahulan

• Ada tiga persyaratan kritis perancangan dan

pengembangan perangkat lunak dengan pemakaian

ulang sebagai berikut :

1. Komponen yang dapat dipaki ulang dan sesuai, harus

mungkin ditemukan.

2. Pemakaian ulang komponen harus pasti bahwa

komponen-komponen tersebut akan bekerja.

3. Komponen tersebut harus memiliki dokumentasi yang

berhubungan untuk pemakai ulang memahaminya dan

mengadaptasinya ke aplikasi yang baru.

Pendahuluan

• Pemakaian ulang berbasis generator

Pendahuluan

• Keterangan Pemakaian ulang berbasis generator

Alternatif bagi pandangan berorientasi komponen pemakaian ulang

adalah pandangan generator.

. Pada pendekatan terhadap pemakaian ulang ini, pengetahuan

yang dapat dipakai ulang di tangkap pada system generator

program yang dapat deprogram dalam bahasa berorientasi domain.

. Dengan menggunakan informasi ini, suatu system perangkat lunak

operasional dapat dibangkitkan. Pemakaian ulang berbasis

generator hanya mungkin jika abstraksi domain dan pemetaannya

pada kode eksekusi dapat diidentifikasi.

Pengembangan Berbasis

Komponen • Pendekatan berbasis pemakaian ulang terhadap

pengembangan sistem perangkat lunak.

• Komponen lebih abstrak dari kelas objek dan dianggap

sebagai penyedia layanan yang berdiri sendiri.

• Ketika sistem membutuhkan layanan, sistem memanggil

komponen untuk menyediakan layanan tersebut tanpa

peduli dimana komponen tersebut berjalan atau bahasa

pemrograman yang dipakai untuk mengembangkannya.


Komponen • Penggambaran suatu komponen sebagai penyedia

layanan menekankan dua karakteristik kritis dari

komponen yang dapat dipakai ulang.

1. Komponen merupakan entitas yang dapat dieksekusi

dan independen.

2. Komponen mengeluarkan interface mereka dan semua

interaksi melalui interface tersebut. Interface komponen

dinyatakan dalam operasi yang diparameterisasi dan

status internalnya tidak akan diperlihatkan


Komponen • Komponen didefinisikan oleh interfacenya dan, dalam kasus yang

paling umum dianggap memiliki dua interface yang berhubungan.

Biar lebih jelas dibawah ini merupakan interface komponen


Komponen • Interface komponen ada dua :

Interface provides, interface yang mendefinisikan

layanan uang disediakan oleh komponen tersebut.

Interface requires inteface yang menspesifikasikan

layanan apa yang harus tersedia dari sistem yang

memakai komponen itu. Jika tidak disediakan maka

komponen tidak akan bekerja


Komponen • Pengembangan Layanan Percetakan


Komponen • Keterangan gambar pengembangan layanan percetakan

Dalam hal ini, layanan yang disediakan adalah layanan untuk

mencetak sebuah dokumen, untuk menemukan status antrian yang

berhubungan dengan suatu printer tertentu, untuk mencatat dan

menghapus sebuah printer dengan komponen layanan pencetakan,

untuk memindahkan tugas pencetakan .

Persyaratan untuk komponen ini adalah bahwa platform yang

mendasarinya harus menyediakan layanan yan dinamakan

GetPDFile untuk mengambil file deskripsi printer untuk suatu tipe

printer dan layanan yang bernama PrintInt yang mentransfer

command ke printer yang spesifikasi


Komponen • Komponen-komponen bisa eksis pada tingkat abstraksi

yang berbeda –beda, dari subrutin library yang

sederhana sampai seluruh aplikasi.

• Mayer (1999) mengidentifikasi lima tingkat abstraksi:

1. Abstaksi data, komponen mengimplementasi satu

fungsi, mis fungsi matematika.

2. Pengelompokkan Kasual, komponen sekumpulan

entitas yang berhubungan longgar yang mungkin

berupa deklarasi data, fungsi dsb


Komponen • Lanjutan…

3. Abstraksi Data, komponen mempresentasikan

abstraksi data atau kelas perangkat lunak bahasa

berorientasi objek.

4. Abstraksi Cluster, komponen merupakan sekumpulan

kelas yang berhubungan yang bekerja sama kadang

dinamakan kerangka kerja.

5. Abstraksi Sistem komponen merupakan sistem yang

sepenuhnya berdiri sendiri.


Komponen • Pengembangan berorientasi komponen dapat diintegrasikan ke

dalam proses pengembangan sistem dengan menggunakan

kegiatan pemakaian ulang yang spesifik sebagaimana gambar

dibawah ini.


Komponen • Keterangan proses pemakaian ulang oportunistik

Perancang system menyelesaikan perancangan tingkat tinggi dan

spesifikasi kompomen desain tersebut. Spesifikasi ini digunakan

untuk menemukan komponen yang akan dipakai ulang. Spesifikasi

ini mungkin dimasukkan pada tingkat arsitektural atau pada

perancangan yang lebih rinci.


Komponen • Mungkin kesulitan utama dalam pengembangan berbasis komponen

adalah masalah pemeliharan dan evolusinya.

• Biasanya source code komponen tidak tersedia dan berubahnya

persyaratan aplikasi, tidak mungkin bagi kita untuk mengubah

komponen demi merefleksikan persyaratan-persyaratan ini.

• Pilihan untuk mengubah persyarata pada tahap ini, untuk

menyesuaikan dengan komponen yang tersedia, biasanya tidak

mungkin karena aplikasi sudah dipakai.

• Diperlukan pekerjaan tambahan untuk memakai ulang komponen

dan, dengan berlalunya waktu, hal ini mengakibatkan biaya

pemeliharaan bertambah.


Komponen • Pengembangan dengan pemakaian ulang


Komponen • Pengembangan dengan pemakaian ulang

• Pada pengembangan yang didorong oleh pemakaian ulang,

persyratan system dimodifikasi menurut komponen pemakaian

ulang (reusable) yang tersedia.

• Desain juga di dasarkan atas komponen-komponen yang tersedia

itu. Ini berarti bahwa mungkin saja harus terjadi kompromi

persyaratan.

• Desain mungkin kurang efisien dari desain khusus. Namun biaya

pengembangan yang lebih kecil, pengiriman system yang lebih

cepat, dan keandalan system yang bertambah seharusnya dapat

mengkompensasi hal ini.

Kerangka Kerja Aplikasi

• Kerangka kerja (atau kerangka kerja aplikasi) merupakan desain

subsistem yang terdiri dari sekumpulan yang abstrak dan konkret,

dan berbagai interface diantara mereka (Wirfs-Brock dan Johnson,

1990).

• Rincian khusus mengenai subsistem aplikasi sistem

diimplementasikan dengan menambahkan komponen dan

menyediakan implementasi yang konkret dari kelas abstrak pada

kerangka kerja.

• Kerangka kerja jarang merupakan aplikasi sendiri. Aplikasi

biiasanya dibangun dengan mengintegrasikan sejumlah kerangka

kerja.


• Fayad dan Schmidt (1997) menfidentifikasikan tiga kelas

kerangka kerja:

1. Kerangka kerja infrastruktur sistem. Kerangka kerja ini

mendukung pengembangan infrastruktur sistem seperti

komunikasi, interface user dan compiler. (Schmidt,

1997).

2. Kerangka kerja integrasi middleware ( perangkat

menengah ). Kerangka kerja ini terdiri dari satu set

standar dan kelas objek yang berhubungan yang

mendukung komunikasi dan pertukaran informasi

komponen.


• Lanjutan…

3. Kerangka kerja aplikasi perusahaan ini berhubungan

dengan domain aplikasi yang spesifik seperti sistem

telekomunikasi atau finansial(Baumer et al., 1997).

Kerangka kerja ini memiliki pengetahuan domain

aplikasi dan mendukung pengembangan aplikasi end-

user. Kerangka ini berhubungan dengan kerabat

aplikasinya.


• Kerangka kerja Model View-Controller


• Keterangan Kerangka kerja Model View-Controller

• Salah satu kerangka kerja yang paling dikenal dan banyak

digunakan untuk perancangan GUI adalah kerangka kerja MVC.

• kerangka kerja ini pada awalnya diusulkan sebagai pendekatan

terhadap perancangan GUI yang memungkinkan presentasi multipel

dari sebuah objek dan gaya interaksi yang berbeda dengan setiap

presentasi ini

• Kerangka kerja MVC mendukung presentasi data dengan cara-cara

yang berbeda dan interaksi yang terpisah dengan setiap presentasi

ini.

• Ketika data dimodifikasi melalui salah satu dari presentasi tersebut,

semua presentasi lain diupdate.

Kerangka Kerja Aplikasi • Aplikasi yang dibangun dengan menggunakan kerja bisa menjadi

dasar untuk pemakaian ulang lebih jauh melalui konsep kerabat

aplikasi.

• Masalah yang mendasar dengan kerangka kerja adalah

kompleksitas bawaannya dan waktu yang diperlukan untuk belajar

menggunakannya.

• Mungkin dibutuhkan beberapa bulan untuk memahami kerangka

kerja sepenuhnya.

• Pada organisasi besar, beberapa perekayasa perangkat lunak

menjadi spesialis kerangka kerja.

• Tidak ada keraguan bahwa pendekatan ini merupakan pendekatan

yang efektif terhadap pemakaian ulang tetapi biaya pengenalan

yang tinggi membatasi pemakaian secara luas

Pemakaian Ulang Produk

COTS • Istilah produk COTS (Commersial Off The Self/Komersil

dan Siap Beli) dapat, pada prinsipnya, berlaku bagi

komponen manapun yang ditawarkan oleh vendor pihak

ketiga.

• Istilah COTS digunakan untuk mengacu produk perangkat

lunak sistem.

• Fungsionalitas dari COTS ialah sistem ini lebih luas dari

komponen khusus, keuntungan yang potensial melalui

pemakaian ulang akan bertambah.

• Sistem database mungkin merupakan contoh yang paling

baik dari COTS


COTS • Pada prinsipnya, penggunaan sistem COTS

berskala besar sama dengan penggunaan

komponen yang lebih khusus lainnya.

• Namun demikian, kenyataan bahwa produk-

produk ini biasanya merupakan sistem besar

dan seringkali dijual sebagai sistem yang

terpisah dan berdiri sendiri membawa masalah

tambahan.


COTS • Boehm (1999) membahas empat masalah dengan

integrasi sistem COTS :

Tidak adanya kontrol terhadap fungsionalitas dan

kinerja.

Masalah dengan kemampuan antar operasi sistem

COTS

Tidak ada kontrol terhadap evolusi sistem

Dukungan dari vendor COTS


COTS • Keuntungan pemakaian ulang produk COTS sangat

signifikan karena sistem-sistem ini memberikan begitu

banyak fungsionalitas bagi pemakai ulang.

• Usaha implementasi yang berbulan-bulan atau bahkan

bertahun-tahun dapat dipersingkat jika sistem yang ada

dipakai ulang dan waktu pengembangan sistem pun

diperkecil secara drastis.

• Dengan kenyataan bahwa penyerahan sistem yang

cepat merupakan persyaratan utama untuk banyak

sistem.

Pengembangan Komponen

Untuk Pemakaian Ulang • Proses pengembangan komponen yang ideal harus

merupakan proses berbasis pengalaman, dimana

komponen pemakaian ulang khusus dibuat dari

komponen yang ada yang telah dipakai ulang dengan

cara yang oportunis.

• Dengan menggunakan pengetahuan mengenai masalah

pemakaian ulang dan diadaptasi komponen yang

dibutuhkan untuk mendukung pemakaian ulang, versi

komponen yang lebih dapat dipakai ualng dan dibuat


Untuk Pemakaian Ulang • Ada berbagai karakteristik komponen yang

menghasilkan kemampuan untuk dipakai ulang:

1. Komponen harus merefleksikan abstraksi domain yang

stabil. Abstraksi domain yang stabil merupakan konsep

mendasar pada domain aplikasi yang berubah

perlahan.

2. Komponen harus menyembunyikan cara statusnya

direprensentasikan dan harus menyediakan operasi

yang memungkinkan status tersebut diakses dan dial-

up date


Untuk Pemakaian Ulang • Lanjutan…

• Komponen harus seindependen mungkin. Idealnya, sebuah

komponen harus berdiri sendiri sehingga komponen tidak

memerlukan komponen harus berdiri sendiri sehingga komponen

tidak memerlukan komponen lain untuk beroperasi. Yang paling

baik dilakukan adalah meminimasi ketergantungan ini, terutama jika

ada ketergantungan pada komponen-komponen yang dapat

berubah seperti fungsi sistem operasi.

• Semua eksepsi harus merupakan bagian dari interface komponen.

Komponen tidak boleh menangani eksepsi sendiri karena aplikasi

yang berbeda akan memiliki persyaratan yang berbeda untuk

penanganan eksepsi.


Untuk Pemakaian Ulang • Untuk membuat komponen-komponen ini dapat dipakai

ulang, biasanya perlu dibuat sebuah wrapper(pembungkus).

• Wrapper menyembunyikan kompleksitas kode yang

mendasarinya dan menyediakan interface untuk komponen

eksternal untuk mengakses layanan yang diberikan.

• Membuat komponen yang dapat dipakai ulang menuntut

adanya interface yang sederhana dan minimal yang mudah

dimengerti.

• Kemampuan pemakaian ulang menambah kompleksitas

dan dengan demikian mengurangi pemahaman komponen.

Kerabat Aplikasi

• Sebuah kerabat aplikasi atau kalur produk

merupakansatu set aplikasi yang memiliki arsitektur

spesifik domain.

• Inti umum dari kerabat aplikasi dipakai ulang setiap kali

dibutuhkan aplikasi baru.

• Pengembangan baru bisa melibatkan penulisan

beberapa komponen tambahan dan adaptasi beberapa

komponen pada aplikasi untuk memenuhi permintaan

baru.

Kerabat Aplikasi

• Ada berbagai jenis spesialisasi kerabat aplikasi yang

dapat dikembangkan.

Spesialisasi Platform, dimana berbagai versi aplikasi

dikembangkan untuk berbagai platform.

Spesialisasi Konfigurasi, dimana berbagai versi aplikasi

dibuat untuk menangani berbagai piranti periferal.

Spesialisasi Fungsional, dimana berbagai versi aplikasi

dibuat untuk pelanggan dengan persyaratan yang

berbeda.

Kerabat Aplikasi

• Untuk mengilustrasikan pendekatan terhadap pemakaian ulang ini

dapat dilihat gambar arsitektur sistem manajemen inventaris.

Kerabat Aplikasi

• Keterangan gambar sistem manajemen sumber daya generik

Mengilustrasikan arsitektur system untuk manajemen

inventaris. System manajemen inventarisdigunakan oleh

organisasi untuk dapat mengetahui asset mereka setiap

saat.

System ini harus menyediakan fasilitas seperti (add)

kemampuan untuk menambkan sumberdaya ke inventaris,

(remove) kemampuan untuk mengambil sumberdaya dari

inventaris, (query) kemmampuan unntuk mencari dan

(browse) menelusuri inventaris, dan (create report)

kemampuan untuk membuat laporan.

Kerabat Aplikasi

• Dalam implmentasi dari manajemen sumber daya ada

pada gambar dibawah ini yaitu sistem perpustakaan

Kerabat Aplikasi

• Keterangan gambar sitem perpustakaan

Pembuatan sistem ini melibatkan penambahan fasilitas

baru untuk mengeluarkan dan mengembalikan sumber

daya dan memungkinkan user pada sistem, fasilitas ini

ditunjukkan disebelah kanan pada gambar.

Pada umumnya, pengembangan aplikasi dengan

mengadaptasi versi generik dari aplikasi tersebut

memiliki arti bahwa sebagian besar kode aplikasi dipakai

ulang.

Kerabat Aplikasi

• Gambar dibawah ini menunjukkan langkah-langkah yang terdapat

dalam adaptasi kerabat aplikasi untuk membuat aplikasi baru.

• Detil proses ini mungkin berbeda secara radikal, tergantung pada

domain aplikasi dan lingkungan organisasi sistem.

Kerabat Aplikasi

• Keterangan gambar pengembangan anggota kerabat

Elisitasi persyaratan stakeholder, biasanya langkah ini

melibatkan demonstrasi dan eksperimen dengan system

tersebut dan menyatakan persyaratan sebagai

modifikasi yang diperlukan

Pilih anggota kerabat yang paling sesuai, persyaratan

dianalisis dan anggota kerabat yang paling sesuai untuk

persyaratan-persyaratan ini dipilih untuk dimodifikasi.

Negosiasi ulang persyaratan, ada negosiasi ulang

persyaratan untuk meminimmasi perubahan yang

diperlukan.

Kerabat Aplikasi

• Lanjutan…

Adaptasi system yang sudah ada, modul-modul baru

dikembangkan untuk system yang sudah ada dan

modul-modul system yang telah ada diadaptasibuntuk

memenuhi persyratan-persyaratan baru.

Serahkan anggota kerabat yang baru. anggota kerabat

aplikasi yang baru diserahkan kepada pelanggan. Pada

tahap ini anda harus mendokumentasikan fitur-fitur

kuncinya sehingga dapat dipakai ulang sebagai dasar

untuk pengenmbangan system lainnya di masa datang

Kerabat Aplikasi

• Dengan beberapa pengecualian kerabat aplikasi

biasanya muncul dari aplikasi yang sudah ada. Yaitu

organisasi mengembangkan aplikasi dan kemudian

ketika dibutuhkan sebuah aplikasi baru menggunakan

aplikasi baru menyebabkan proses ini berkelanjutan.

• Namun demikian karena perubahan cenderung merusak

struktur aplikasi pada suatu tahap diambil keputusan

khusus untuk merancang kerabat aplikasi yang generik.

Pola Rancangan

• Satu cara untuk mengatasi masalah ini adalah

memakai ulang rancangan yang lebih abstrak

yang tidak mencakup rincian implmentasi.

• Rancangan ini kemudian diimplementasi khusus

untuk menyesuaikan dengan persyaratan

aplikasi.

Pola Rancangan

• Pola rancangan (Gamma et al…1995) diturunkan dari ide

dikemukakan oleh Christopus Alexander(Alexander et al,.1977)

yang mengusulkan bahwa ada pola tertentu pada rancangan

pembangunan yang umum dan sekaligus memuaskan dan efektif.

• Pola merupakan deskripsi masalah dan inti solusinya sehingga

solusi tersebut dapat dipakai ulang pada setting yang berbeda.

• Pada perancangan perangkat lunak, pola rancangan telah

dihubungkan dengan desain berorientasi objek.

• Pola ini seringkali bergantung pada karakteristik objek inheritansi

dan polimorfisme untuk memberikan generalitas.

Pola Rancangan

• Gamma et el., (1995) mendefinisikan empat elemen yang penting

pada pola rancangan:

1. Nama yang merupakan referensi yang bermakna terhadap pola

2. Deskripisi area masalah yang menjelaskan kapan pola tersebut

dapat diterapkan.

3. Deskripsi solusi yang mendeskripisikan bagian-bagian solusi

perancangan, hubungannya dan tanggung jawabnya.

4. Pernyataan konsekuensi hasil dan pengukuran perapan pola

tersebut.

Pola Rancangan

• Penggunaan pola hanya merupak bentuk yang sangat

efektif dari pemakaian ulang, tetapi cara ini memiliki

biaya pengenalan yang tinggi untuk proses

perancangannya dan hanya dapat dipakai oleh

programmer yang berpengalaman.

• Pola hanya sesuai dengan programmer yang

berpengalaman karena mereka mengenali situasi

generik di mana suatu pola dapat diterapkan.

Hal-Hal Penting • Perancangan dengan pemakaian ulang melibatkan perancangan

perangkat lunak disekitar contoh perancangan bagus yang tersedia

dan melibatkan juga pemakaian komponen komponen perangkat

lunak jika ada.

• Keuntungan pemakaian ulang perangkat lunak adalah biaya yang

lebih rendah, pengembangan perangkat lunak yang lebih cepat dan

resiko yang lebih kecil. Keandalan sistem bertambah dan spesialis

dapat bekerja lebih efektif dengan berkonsentrasi pada kepakaran

mereka pada perancangan komponen yang dapat dipakai ulang.

• Pemakai ulang produk COTS berkenaan dengan pemakaian ulang

sistem berskala besar dan siap dibeli. Produk-produk ini

memberikan banyak fungsionalitas dan pemakaian ulangnya dapat

secara radikal memperkecil biaya waktu dan pengembangan.

Hal-Hal Penting

• Komponen-komponen perangkat lunak yang telah

dirancang untuk dipakai ulang harus independen, harus

merefleksikan abstraksi domain yang stabil, harus

menyediakan akses ke status melalui operasi interface

dan tidak boleh menangani eksepensi sendiri.

• Kerabat aplikasi adalah aplikasi yang berhubungan

yang dikembangkan dari satu atau lebih aplikasi dasar

• Pola desain adalah abstraksi tingkat tinggi yang

mendokumentasikan solusi desain yang berhasil.

Terima Kasih

Documents

PERANCANGAN DENGAN PEMAKAIAN ULANG · PDF fileMemahami pengertian kerabat aplikasi dan memahami bagaimana kerabat aplikasi merupakan cara yang efektif ... Abstraksi domain yang stabil