Rekayasa Perangkat Lunak

Rangkuman Materi Bab 3 – Bab 5

YANDIKA RESTU WARA - 201131081KELAS A

Sekolah Tinggi Teknik PLN Jakarta

BAB 3

MERUMUSKAN SPESIFIKASI KEBUTUHAN PENGGUNA (USER’S REQUIREMENTS SPECIFICATION)

Untuk menjembatani kepentingan-kepentingan pengguna dalam pengembang, diperlukan seorang perantara (seorang analis sistem) yang tugasnya adalah menerjemahkan apa yang dibutuhkan dan diharapkan oengguna sehingga dimengerti oleh para anggota tim pengembang lainnya (terutama programmer) yang biasanya sangat teknis.

Langkah-langkah spesifikasi kebutuhan yaitu :1. Mendaftarkan kandidat kebutuhan-kebutuhan

2. Memahami konteks sistem

3. Menangkap kebutuhan-kebutuhan fungsional

4. Menangkap kebutuhan-kebutuhan non-fungsional Model Ranah (Domain Model)

Model Ranah merupakan salah satu jenis objek yang terpenting dalam konteks system / perangkat lunak. Objek ranah mempresentasikan sesuatu yang hadir atau event-event yang terjadi saat system / perangkat lunak yang kita kembangkan bekerja. Bentuk umum kelas ranah :

1. Objek-objek bisnis(business object) yang mempresentasikan sesuatu yang dimanipulasi dalam bisnis, seperti menyebutkan beberapa contoh pesanan-pesanan,rekening dan kontrak

2. Objek objek dunia nyata dan konsep –konsep yang perlu dicatat seperti (menyebutkan beberapa contoh) catatan transaksi dan sejarah audit system

3. Event-event yang mungkin terjadi dalam system perangkat lunak seperti login nasabah ke system perangkat lunak,kedatangan pesawat, keergian pesawat, wisuda dan lain lain.

Keguaan dari pemodelan ranah adalah untuk memahami mendeskripsikan kelas-kelas yang terpenting dalam konteks ranah yang telah ditetapkan.Model Bisnis

Model bisnis umumnya dimodelkan menggunakan use case dan model objek.

Model objek bisnis adalah suatu model bagian dalam suatu model bisnis. Ia mendeskripsikan bagaimana masing – masing use case direalisasikan oleh sejumlah entitas bisnis dan unit pekerjaan dalam pekerjaannya. Dikembangkan menggunakan 2 langkah penting berikut ini :

1. Pemodel bisnis (business modeler) seharusnya mempersiapkan model use case bisnis yang mengidentifikasi actor – actor bisnis serta use case bisnis yang akan digunakan oleh actor.

2. Pemodel bisnis seharusnya mengembangkan model objek bisnis yang memuat pekerja, entitas – entitas bisnis, dan unit – unit kerja yang secara bersamaan merealisasikan suatu use case bisnis tertentu. Sasarannya adalah untuk membuat pekerja, entitas bisnis, dan unit- unit kerja yang merealisasikan use case bisnis dengan cara

seefektif mungkin- cepat, akurat , serta rendah biaya.

Spesifikasi kebutuhan tambahan (supplementary requirements) meruapakan spesifikasi kebutuhan non – fungsional yang tidak bisa di hubungkan dengan use case tertentu. Contoh : spesifikasi – spesifikasi yang memiliki imbas pada kinerja , memiliki imbas pada antarmuka, memiliki imbas pada spesifikasi – spesifikasi rancangan fisik dan batasan-batasan arsitektural, memiliki imbas pada batasan – batasan perancangan, serta memiliki imbas pada batasan – batasan implementasi.

Untuk Menangkap Spesifikasi Kebutuhan Sebagai Use Case yaitu dengan menggunakan use case.

Pekerja (worker) adalah posisi dimana seseorang memiliki tanggung jawab tertentu, dimana masing – masing pekerja sesungguhnya merupakan deskripsi tanggung jawab dan perilaku – perilaku yang diharapkan dari pekerja yang bersangkutan.

Analis sistem mengidentifikasi actor dan use case untuk:1. Melakukan pembatasan antara sistem atau perangkat lunak dengan lingkungannya

2. Menggambarkan siapa atau apa yang berinteraksi dengan sistem dan fungsionalitas apa (use case) yang diharapkan dari sistem

3. Menangkap dan mendefinisikan terminologi – terminologi yang umum yang penting untuk membuat deskripsi

rinci use case dalam bentuk kamus .Menemukan Use Case dan Aktor

Actor -> Pertimbangkanlah 2 hal berikut ini. Pertama. sistem/perangkat lunak yang akan kita kembangkan minimal akan memiliki I actor. Kedua, pertimbangkan actor-actor berdasarkan peran-perannya terhadap sistem/perangkat lunak.

Panduan umum untuk menentukan use case :

1. Masing-masing use case yang kelak akan dilaksanakan dengan baik semestinya memberikan 'nilai' tertentu pada actor terkait sehingga actor yang bersangkutan dapat mencapai sasaran tertentu.

2. Dengan mengidentifikasi use case yang menyediakan 'nilai' untuk pengguna-pengguna sistem/perangkat lunak.

kita dapat memastikan bahwa ukuran use casetidak menjadi cerlalu besar.Memprioritaskan Dan Mendeskripsikan Rincian Use Case

Setiap use case pasti memiliki arah aliran/skenario utama (main path). Meski demikian. perhatikan juga lintasan-lintasan alternatif, simpangan-simpangan, atau pengecualian-pengecualian, dad lintasan/skenario utama tersebut. Sebagai contoh, perhatikan lintasan alternatif untuk use case-use case tertentu berikut ini.

1. Actor mungkin memilih lintasan/skenario yang berbeda di sepanjang lintasan/skenario utama yang dimiliki suatu use case. Sebagai contoh, sepanjang use case Pembayaran Kuitansi, actor mungkin memutuskan (baca: memilih) untuk membayar kuitansi yang bersangkutan atau menolaknya.

2. Jika ada lebih dari saw actor yang terlibat dalam suatu use case, aksi yang dilakukan suatu actor mungkin memiliki imbas pada lintasan/ skenario yang dilalui actoryang lainnya.

3. Sistem/perangkat lunak mungkin dapat mendcteksi asupan-asupan yang diberikan suatu actor.

4. Sumber daya sistem/perangkat lunak tertentu mungkin mengalami malfungsi di mana hal ini mencegah sistem/perangkat lunak bekerja secara semestinya.

Deskripsi use case seharusnya dilakukan dengan mempertimbangkan hal-hal berikut ini.

1. Deskripsi use case seharusnya mendefinisikan 'keadaan' awal yang merupakan prakondisi untuk use case yang bersangkutan.

2. Bagaimana dan kapan use case berawal (aksi pertama yang harus dilaksanakan).

3. Urutan yang dikehendaki (jika ada) aksi-aksi mana yang hares dilaksanakan. Pada contoh Gambar 3.15. urutan aksi dinyatakan dengan penomoran.

4. Bagaimana dan kapan use caseberakhir.

5. Lintasan-lintasan alternatif dari lintasan baku.

6. Interaksi sistem/perangkat lunak dengan actor-actor dan bagaimana mereka Baling bertukar 'pesan'.

7. Penggunaan objek-objek, nilai-nilai, dan serangkaian sumber daya yang ada dalam sistem/perangkat lunak yang sedang dikembangkan. Dengan kata lain. kita mendeskripsikan urutan aksi dalam suatu use case clan memberikan nilai-nilai pada atribut-atribut use case.

8. Kita hares secara eksplisit mendeskripsikan apa yang sistem lakukan (aksi-aksi yang is lakukan) dan apa yang dilakukan actor-actor. Kim perlu memisahkan tanggungjawab-tanggungjawab actor-actor. Jika tidak, deskripsi use case menjadi tidak cukup teliti untuk digunakan sebagai spesifikasi sistem.

1. Para ahli seperti Russel J. Abbort serta Grady Booch (Richard C. Lee dan William M. Tephfenhart, 1999) menyarankan penggunaan kata benda (Inggris : noun) sebagai baris untuk penentuan kelas / objek. Langkah-langkahnya adalah sbagai berikut :

a Dapatkan pernyataan-pernyataan dari spesifikasi use case (perhatikan Gambar 3.15) untuk mendapatkan pernyataan informal mengenai aplikasi yang akan dikembangkan.

b Gunakan kata benda ata kata ganti kata benda untuk mengidentifikasi objek-objek serta kelas-kelas. Kata benda dapat berupa kata benda tunggal (Adi, Ana, dia, aku, gitarku, komputerku, pacarku, pianoku, dsb)

2. Identifikasi kelas/objek dapat juga dilakukan dengan mcnggunakan kanu CRC (Class Respodbility Colisboration) yang pertama kali diperkenalkan oleh Rehecca Wirffs-Broek (Ali Rahrawi, 1999). Rebecca percaya bahwa

identifikasi objek dan kelas adalah aktivitas manusia yang dapat distimulasi dengan penggunaan kertas kecil manusia yang dapat distimulasi dengan penggunaan kertas kecil (kartu CRC). Telah dibuktikan bahwa kanu CRC akan merangsang pengembang yang berpengalaman. kreatif, sena memiliki intuisi untuk dapat mengidentifikasi objek serta kelas dengan cepat. Langkah-langkah yang dapat dilakukan dengan bantuan kanu CRC adalah sebagai berikut.

a Pada kartu CRC, dokumentasikan nama kelas dan daftarkan tanggung-jawabnya masing-masing (baca: layanan yang dia sediakan) sena kolaboratornya (kelas/objek yang dibutuhkan kelas/objek yang bersangkutan untuk dapat memenuhi tanggung-jawabnya).

b Identifikasi objek sena kelas yang hilang, yang seharusnya ditambahkan pada kartu CRC. Secara spesifik, cari tanggung jawab yang tidak dapat dialokasikan pada kelas yang sudah ada. Selain itu, temukan kolaborator-kolaborator yang belum terkait dengan kelas-kelas yang ada.

Keunggulan teknik ini adalah murah dan mudah digunakan. Juga, metode ini merangsang komunikasi dan terbuka dilakukan oleh orang-orang yang belum berpengalaman. Sayangnya, teknik ini lebih sesuai untuk berpikir tentang kelas/objek daripada mengidentifikasinya.

1. Kelas-kelas yang redundan. Jika 2 kelas menyimpan informasi yang sama, kita akan satukan menjadi satu keias yang iebih representatif

2. Kelas yang tidak relevan. Jika kelas tidak diperlukan dalam aplikasi sebaiknya dia dihilangkan3. Kelas seharusnya spesifik

4. Atribut-Atribut. Beberapa dari kandidat-kandidat kelas kadang-kadang bisa dan lebih tepat dikelompokkan sebagai atribut

5. Operasi. Kadang-kadang suatu kandidat kelas bisa digolongkan menjadi kelas pada model-model yang lain.

6. Penamaan. Setiap kelas harus diberi nama dengan cara yang baik; nama yang mencerminkan jenis kelas serta hubungannya dengan kelas yang lain

Adapun teknik-teknik dasar yang bisa digunakan adalah:

1. Membuat diagram 'state' (statechart diagram) untuk mendeskripsikan 'keadaan' yang terjadi dalam suatu use caseSerta transisi-transisi yang terjadi antar-state

2. Membuat diagram aktivitas yang bisa digunakan untuk mendeskripsikan transisi antara-state dengan cara yang lebih rinci sebagai urutan aktivitas – aktivitas dan/ atau aksi – aksi.

3. Diagram – diagram interaksi (sequence diagram dan/ atau diagram kolaborasi) dapat digunakan untuk mendeskripsikan bagaimana suatu use case berinteraksi dengan actornya yang berpatisipasi di dalamnya.

4. Membuat diagram 'state' (statechart diagram) untuk mendeskripsikan 'keadaan' yang terjadi dalam suatu use caseserta transisi-transisi yang terjadi antar-state

5. Membuat diagram aktivitas yang bisa digunakan untuk mendeskripsikan transisi antara-state dengan cara yang lebih rinci sebagai urutan aktivitas – aktivitas dan/ atau aksi – aksi.

6. Diagram – diagram interaksi (sequence diagram dan/ atau diagram kolaborasi) dapat digunakan untuk mendeskripsikan bagaimana suatu use case berinteraksi dengan actornya yang berpatisipasi di dalamnya.

Menstrukturkan Model Use Case

Pada umumnya, model use case perlu distruktur-kan lebih lanjut untuk mengadopsi fakta-fakta berikut ini :

1. Seringkali perlu untuk membuat deskripsi-deskripsi use case yang bersifat umum kemudian membagikannya ke use case-use case yang lebih spesifik.

2. Seringkali perlu untuk mengekstraksi deskripsi-deskripsi use case tambahan yang perlu dilakukan untuk memperluas deskrripsi-deskripsi use case yang lebih spesifik.

3. Seringkali perlu untuk membuat deskripsi-deskripsi use case yang bersifat umum kemudian membagikannya ke use case-use case yang lebih spesifik.

4. Seringkali perlu untuk mengekstraksi deskripsi-deskripsi use case tambahan yang perlu dilakukan untuk memperluas deskrripsi-deskripsi use case yang lebih spesifik.

Menemukan Use Case Dan Actor

BAB IV

ANALISA DAN PERENCANAAN SISTEM MENGGUNAKAN METODE USDP

Spesifikasi Kebutuhan Yang Digambarkan

Tujuan dari tahapan analisis yang kita bahas dalam bab ini adalah untuk menyelesaikan permasalah yang belum terselesaikan dengan cara melakukan analisis spesifikasi kebutuhan secara mendalam.Model Analisis

Sangat membantu analisis sistem untuk memperhalus spesifikasi kebutuhan sistem perangkat lunak

Memungkinkan analisis sistem untuk berfikir tentang struktur internal sistem perangkat lunak, termasuk didalamnya sumber daya sistem perangkat lunak yang dibagikan.

Membantu analisis sistem untuk menstrukturkan spesifikasi kebutuhan Langkah-Langkah Analisis

Karakteristik-karakteristiknya adalah:

1. Kelas-kelas analisis yang dibuat oleh analsisi sistem pada dasarnya berfokus pada penanganan spesifikasi kebutuhan fungsional dan menunda penanganan spesifikasi nonfungsional.

2. Kelas-kelas analisis yang dibuat oleh analisis sistem jarang mendefisikan atau menyediakan antar muka untuk suatu operasi serta penandanya.

3. Kelas analis yang dibuat oleh anlisis sistem juga mendefinisikan atribut-atribut.

4. Kelas-kelas analisis yang dibuat oleh analisis sistem pada umumnya juga memiliki relasi 1 dengan yang lainnya. 5. Kelas-kelas analisis yang dibuat oleh analis sistem pada dasarnya memiliki 3 stereotype.

Boundary Class

Kelas pembatas ( boundary class) digunakan untuk memodelkan interaksi antara sistem perangkat lunak dengan actornya.Entity Class

Class entitas digunakan untuk memodelkan informasi yang berumur relatif panjang dalam sistem. Kelas-kelas entitas memodelkan informasi dan perilaku terkait dari sejumlah konsep penting seperti individu, objek dunia nyata, atau even yang terjadi didunia nyata.Control Class

Kelas-kelas kendali mulai merepresentasikan kordinasi, urutan, transaksi, dan kendali ke objek lainnya dan sering digunakan untuk membungkus kendali yang berhubungan dengan satu use case tertentu yang sifatnya spesifik.Realisasi Use Case

Analisis sistem perangkat lunak sesunggunya adalah kolaborasi dalam model analisis yang mencoba mendeskripsikan bagaimana suatu use case yang sifatnya spesifikPaket-Paket Analisis

Paket-paket analisis sebaiknya bersifat kohesif dan bersifat saling terlepas. Juga, secara umum paket-paket analisis memiliki karakteristik berikut ini:

1. Paket-paket analisis dapat merepresentasikan pemisahan dari perhatian analisis.

2. Paket-paket analisis sebaiknya dibuat berdasarkan pada spesifikasi kebutuhan fungsional dan berbasis pada ranah permasalahan.

3. Paket-paket analsis berada pada bagian model perancangan. Paket Layanan (Servies Packages)

Disamping menyediakan use case pada aktornya, setiap sistem perangkat lunak juga menyediakan layanan tertentu pada penggunanya.

1. Use case menspesifikasikan urutan aksi-aksi yang diawali oleh tindakan aktor.

2. Layanan servis merepresentasikan sejumlah aksi koheren yang berhubungan dengan fungsionalitas yang dimanfaatkan oleh beberapa usecase.

3. Saat suatu use case direalisasikan oleh analisis sistem, satu atau lebih paket layanan mungkin menjadi partisipan dalam realisasi.

4. Paket layanan sering memiliki ketergantungan yang sangat rendah terhadap paket layanan yang lainnya.

5. Paket layanan biasanya relevan untuk satu atau sedikit actor. Pandangan Arsitektural Model Analisis

Bentukan-bentukan pada model analisis dibawah ini dapat dipertimbangkan secara signifikan sebagai arsitektur system.

1. Dekomposisi model analisis menjadi paket-pake analisis dan kebergantungan-kebergantungannya(dependency).

2. Kelas-kelas analisis kunci seperti kelas-kelas entitas yang membungkus fenomena penting dari ranah permasalahan.

3. Realisasi use case yang merealisasikan beberapa fungsionalitas yang penting serta kritis. Pekerja (Worker) Analisis

Tugasnya antara lain memastikan bahwa model analisis secara keseluruhan benar, konsisten, serta mudah dibaca oleh anggota tim pengembang yang lainnya. Untuk system/pengarang lunak yang berukuran besar dan kompleks tanggung jawabnya mungkin, setelah iterasi, lebih bersifat pemeliharaan.

Aliran Kerja Analisis

diawali oleh arsitek yang mulai melakukannya dengam melakukan identifikasi paket-paket analisis yang utama, dengan sedikit mengabaikan kelas-kelas entitas. Kemudian, perekayasa use case merealisasikan masing-masing use case dengan penekanan pada aspek statis system. Terakhir, spesifikasi-spesifikasi kebutuhan kemudian akan dispesifikasi lebih lanjut oleh perekayasa komponen dan diintgrasikan ke dalam masing-masing kelas dengan meembuat serangkaian tanggung jawab yang konsisten, serta membuat atribut-atribut, serta relasi-relasi, untuk masing-masing kelas. Selama tahap analisis, arsitek system terus menerus berusaha menemukan paket-paket analisis yang baru, kelas-kelas analisis baru, serta spesifikasi-spesifikasi kebutuhan umum yang baru.

Analisis Arsitektural

Manfaat analisis arsitektural adalah untuk lebih menjelaskan modal analisis danarsitekturnya dengam melakukan identifikasi paket-paket analisis, dengan sedikit mengabaikan kelas analisis, serta mengidentifikasi spesifikasi-spesifikasi kebutuhan khusus

Alokasi yang baik suatu use cae ke suatu paket yang bersifat spesifik pada dasarnya mencakup hal-hal penting berikut ini.

1. Use case yang diperlukan untuk mendukung suatu proses bisnis yang bersifat spesifik

2. Use case yang diperlukan untuk mendukung actor system yang bersifat spesifik

3. Use case-use case yang saling berhubungan melalui proses generalisasi dan relasi perluasan

Mengidentifikasi Paket-Paket Analisis Mengidentifikasi Paket-Paket Layanan

Mendefinisikan Kebergantungan Antarpaket Proses Analisis Mengidentifikasi Spesifikasi Kebutuhan Khusus

Adalah spesifikasi kebutuhan yang terjadi selama proses analisis dilakukan dapat ditangani dengan cara yang sesuai padatahapan-tahapan perancangan dan implementasinya selanjutnya. Contohnya adalah batasan-batasan pada beberapa hal dibawah ini:

1. Persistensi

2. Penyebaran dan konkurensi

3. Fitur-fitur keamanan

4. Toleransi kesalahan

5. Pengelolaan transaksi

Analisis Use Case Analisis use case bertujuan untuk:

1. Mengidentifikasi kelas-kelas analisis yang memiliki objek-objek dengan tujuan untuk melaksanakan aliran event suatu use case

2. Menyebarkan perilaku uese case untuk objek-objek yang saling berinteraksi

3. Memenangkan kebutusan khusus pada realisasi suatu use case. Beberapa hal di di bawah ini perlu diperhatikan saat analis sistem mengembangkan diagram kolaborasi.

1. Use case dipanggil dan diaktfikan oleh pesan yang terkirim dari actor ke kelas pembatas sistem/perangkat lunak.

2. Masing-masing kelas analisis yang teridentifikasi dari langkah sebelumnya paling tidak memiliki satu obejk yang berpartisipasi dalam diagram kolaborasi

3. Pesan-pesan tidak perlu langsung dipetakan ke operasi-operasi tertentu karena kita tidak menspesifikasi operasi untuk kelas analisis.

4. Tautan dalam diagram kolaborasi seringkali merupakan intance asosiasi antar kelas analisis

5. Urutan kerjadian dalan diagram kolaborasi belum menjadi fokus utama dapat diabaikan jika analis sistem merasa kesulitan untuk memeliharanya.

6. Diagram kolaborasi semestinya menangani semua relasi use case yang direalisasikan. Analisis Kelas Dan Asosiasi Antarkelas

Setelah menganalisis use case, langkah selanjutnya adalah menganalisis kelas-kelas analisis, yang bertujuan untuk:

1. Mengidentifikasi dan memelihara serangkaian tanggung jawab kelas analisis berdasarkan perannya dalam realisasi use case

2. Mengidentifikasi dan memelihara atribut-atribut dan relasi-relasi yang ada dalam kelas-kelas analisis

3. Menangkap spesifikasi-spesifikasi kebutuhan khusus pada realisasi kelas-kelas analisis. Penggunaan agregasi

1. Konsep agregasi menyatakan suatu kelas yang dimuat kelas lainnya . 2. Konsep agregasi menyatakan suatu kelas tersusun oleh kelas-kelas lainyya.

3. Konsep agregasi membenuk koleksi objek secara konseptual. Analisis Paket

Dalam tahap terakhir aliran kerja tahap analisis, kita seringkali perlu melakukan analis paket. Tujuan utamanya adalah sebagai berikut:

1. Memastikan agar paket-paket analisis sebisa mungkin bersifat mandiri dari paket-paket yang lainnya. 2. Memastikan paket-paket analisis memenuhi tujuannya untuk merealisasikan kelas-kelas ranah

3. Mendeskripsikan kebergantungan-kebergantunagn sedemikian rupa sehingga imbas perubahan-perubahan yang

akan terjadi di masa yang akan datang bisa diperkirakanPerancangan Sistem

Model analisis pada dasarnya mencakup didalamnya elemen-elemen sebagai berikut:1. Paket-paket analisis, paket-paket layanan, dan kebergantungan-kebergantungan, serta isinya masing-masing.

2. Kelas-kelas analisis, tanggungjawab-tanggungjawab mereka, atribut-atribut mendasat yang memiliki kelas-kelas analisis, relasi-relasi antar kerlas analisis, serta spesifikasi-spesifikasi kebutuhan khusus masing-masing kelas analisis

3. Realisasi use case akan melokalisasi perubahan-perubahan pada use case.

4. Penampilan arsitektural model analisis.

Model Perancangan

adalah model objek yang mendeskripsikan realisasi fisik use case dengan cara berfokus pada bagaimana spesifikasi-spesfikasi kebutuhan fungsional dan non-fungsional, bersama dengan batasan-batasan lain yang berhubungan dengan lingkungan implementasi, memiliki imbas langsung pada pertimbangan-pertimbangan pada aktivitas-aktivitas yang dilakukan pada tahap implementasi.

Kelas Perancangan

merupakan abstraksi langsung dari kelas-kelas atau kontruksi yang serupa dengan kelas-kelas yang ada pada tahap implementasi sistem/perangkat lunak. Abstraksi ini pada umunya mencakup hal-hal berikut.

1. Bahasa yang digunakan sama dengan bahasa pemrograman berorientasi objek yang digunakan pada tahap implementasi.

2. Visibility atribut-atribut serta operasi-operasi kelas perancangan sering dispesifikasi sesuai dengan pola penggunanya.

3. Relasi-relasi dimana kelas perancangan terlibat dengan kelas-kelas lainnya sering memiliki makna yang bersifat langsung saat kelas yang bersangkutan diimplementasikan.

4. Metode-metode kelas perancangan pada umunya memiliki pemetaan langsung ke metode-metode yang ada pada kelas implementasi.

5. Kelas perancangan bisa saj amenunda penanganan beberapa spesifikasi untuk aktivitas implementasi selanjutnya.

6. Kelas-kelas perancangan cukup sering diberi strereotype yang dapat dipetakan ke konstruksi bahasa pemograman objek yang dipilih.

7. Suatu kelas perancangan dapat merealisasikan antarmuka-antarmuka seperti bahasa pemrograman berorientasi objek yang akan digunakan.

8. Suatu kelas perancangan dapat saja berupa kelas aktif. Realisasi Perancangan

Merupakan kolaborasi di dalam model perancangan yang mendeskripsikan bagaimana use case yang bersifat spesifik direalisasikan dalam terminologi kelas-kelas perancangan dan objek-objeknya.

Kelas-kelas aktif dapat, sebagai alternatif, berada di model prosesnya sendiri, alih-alih berada pada model perancangan.Aliran Event-Event Perancangan

1. Aliran event-event perancangan suatu realisisasi use case tidak bersifat lokal pada sequence diagram yang ebrsifat spesifik.

2. Label-label (yaitu penanda-penanda atau deskripsi-deskripsi aksi-aksi selama aktivasi) untuk suatu sequence

diagram pada umumnya bersifat lokal pada diagram interaksi yang bersangkutan.Spesifikasi Kebutuhan Implementasi Dan Perancangan Subsistem

Spesifikasi-spesifikasi kebutuhan implementasi bersifat deskripsi tekstual pada dasarnya menghimpun spesifikasi-spesifikasi untuk sistem/perangkat lunak yang sedang dikembangkan, seperti spesifikasi-spesifikasi kebutuhan non-fungsional, yang hampir serlalu ada pada realisasi use case.

Subsistem-subsistem perancangan sebaiknya mengikuti panduan umum sederhana berikut ini.

1. Subsistem-subsistem perancangan dapat merepresentasikan pemisahan perhatian perarancangan.

2. Lapsian-lapisan aplikasi yang paling atas dan subsistem-subsistemnya dalam model perancangan seringkali

memiliki jalur pelacakan langsung ke paket-paket analisis dan/atau kelas-kelas analisis.

3. Subsistem-subsistem perancangan pada umumnya bisa merepresentasikan komponen-komponen berukuran besar dalam implementasi sistem; komponen-komponen yang menyediakan beberapa antarmuka yang dibuat untuk menghubungkannya dengan komponen-komponen yang berukuran lebih kecil.

4. Subsistem-subsistem perancangan dapat merepresentasikan produk-produk/bagian-bagian sistem/perangkat

lunak yang dapat digunakan ulang dengan cara mengemasnya.Subsistem Layanan

Subsistem-subsistem layanan (service subsystem) pada umumnya digunakan pada peringkat paling bawah pada hierarki subsistem perancangan dengan alasan bahwa paket-paket layanan yang digunakan dalam model analisis pada dasarnya dibuat untuk mempersiapkan perubahan-perubahan layanan –layanan mandiri dengan melokalisasi perubahan-perubahan pada subsistem-subsistem layanan yang berhubungan.

Antarmuka (Interface)

Antarmuka pada adsarnya menyediakan pemisahan spesifikasi fungsionalitas suatu operasi dari implementasinya dalam bentuk metode-metode yanga da dalam kelas-kelas perancangan.Deskripsi Arsitektur

Deskripsi arsitektur memuat pandangan arsitektural dari model perancangan. Berikut ini dalah elemen-elemen model perancangan yang biasanya dipertimbangkan sebagai arsitektur sebuah sistem/perangkat lunak.

1. Dekomposisi model perancangan menjadi subsistem-subsistem, antarmuka-antarmuka, serta kebergantungan-kebergantungan di antara mereka.

2. Kelas-kelas perancangan kunci seperti kelas-kelas yang secara arsitektural terlacak antara kelas-keals analisis, kelas-kelas aktif dan kelas0kelas perancnagan.

3. Realisasi use case-perancangan yang merealisasikan fungsionalitas-fuingsionalitas yang penting dan kritis yang diperlukan untuk mengembangkan sistem/perangkat lunakd alam tahapan awal siklus hidup pengembangan sistem (SLDC), yang mencakup did alamnya banyak kelas-kelas perancangan yang mungkin implementasinya melintas beberapa sistem, atau melibatkan keals-kelas perancangan kunci seperti yang telah kita bahas sebelumnya.

Perancangan Arsitektural

Kegunaan perancangan arsitektural adalah memberi gambaran garis besar model-model perancangan dan deployment dan arsitekturnya dengan mengidentifikasi hal-hal berikut ini.

1. Simpul-simpul komputer dan konfigurasi-konfigurasi jaringan. 2. Subsistem-subsistem dan antarmuka-antarmukanya.

3. Kelas-kelas perancangan yang secara arsitektur signifikan untuk sistem/perangkat lunak yangs edang dikembangkan, termasuk di dalamnya kelas-kelas aktif.

4. Mekanisme perancangan generim yang menangani spesifikasi-spesifikasi kebutuhan yang sifatnya umum, seperti spesifikasi-spesifikasi klebutuhan persistensi, distribusi, kinerja, dan sebagainya, seperti yang ditangkap

untuk kelas-kelas analisis dan realisasi unse case-analisis selama tahapan analisis.Identifikasi Simpul-Simpul Dan Konfigurasi-Konfigurasi Jaringan

Dalam hal ini, konfigurasi-konfigurasi jaringan pada dasarnya mencakup di dalamnya beberapa hal penting berikut ini.

1. Simpul komputer mana yang terlibat dan bagaimana kapasistas pemrosesan serta ukuran memori yang dimilikinya?

2. Bagaimana jenis koneksi antarsimpul dan protokol-protokol komunikasi yang digunakan? Berapa bandwidtnya, bagaimana keandalannya, serta bagaimana kualitasnya?

3. Apakah ada kebutuhan untuk kapasistas pemrosesan yang redundan, modus penanganan kesalahan, migrasi

proses, pemeliharaan salinan data 9data backup), dan sebagainya?Kelas-Kelas Aktif

Cara-cara mempertimbangkan spesifikasi-spesifikasi kebtuhan sistem/perangkat lunak sebagai berikut.

1. Kinerja serta spesifikasi kebutuhan ketersediaan untuk para actor yang berintekrasi dengan sistem/perangkat lunak.

2. Sebaran komponen-komponen sistem/perangkat lunak ke simpul-simpul komputer. Perancangan Use Case

Tujuan umum dari perancangan suatu use case adalah sebagai berikut.

1. Mengidentifikasi kelas-kelas perancangan dan subsistem-subsistemn yang intancenya diperlukan untuk terlaksananya aliran event-event suatu use case.

2. Menebarkan perilaku use case ke objek-objek perancangan dan subsistem yang saling berinteraksi.

3. Mengidentifikasikan spesifikasi-spesifikasi kebutuhan pada operasi-operasi yang ada pada kelas-kelas perancangan dan yang ada pada subsistem dan mengidentifikasikan spesifikasi –spesifikasi antarmuka kelas perancangan dan subsistem subsistem itu.

4. Menangkap spesifikasi-spesifikasi kebutuhan implementasi untuk suatu use case. Mengidentifikasi kelas-kelas perancangan yang berpartisipasi

1. Mempelajari kelas-kelas analisis yang berpartisipasi dalam realisasi use case analisis yang terkait. Identifikasi kelas-kelas perancangan yang dapat langsung dilacak ke kelas-kelas analisis.

2. Mempelajari spesifikasi-spesifikasi kebutuhan khusus realisasi use case terkait. Identifikasi kelas-kelas perancangan yang merealisasikan spesifikasi-spesifikasi kebutuhan khus tersebut.

3. Sebagai hasilnya, kelas-kelas perancangan yang diperlukan seharusnya diidentifikasi, dan beberapa perekayasa komponen seharusnya bertanggung jawab atas pelaksanaan realisasinya.

4. Jika kelas-kelas perancangan yang digunakan untuk merancang use case tertentu tidak juga berhasi ditemukan, perekayasa use case seharusnya mengomunikasikannya kepada rsitek sistem atau ke perekayasa komponen sebab kelas-kelas perancangan yang diperlukan seharusnya diidentifikasi dengan benar dan hal ini pada

dasarnya merupakan tanggung jawab perekayasa komponen.Mendeskripsikan interaksi objek-objek perancangan

Berikut ini hal-hal yang perlu diperhatikan saat analisis sistem merencanakan untuk membuat sequence diagram

1. Use case pada umumnya akan diawali dengan pengiriman pesan dari suatu intance actor ke objek perancangan tertentu.

2. Masing-asing kelas perancangan yang dapat diidentifikasi dari langkah-langkah sebelumnya semestinya digambarkan sebagai objekl-objek yang saling berpartisipasi dalam sequence diagram.

3. Pesan-pesan dikirimkan di antara garis-garis hidup untuk merealisasikan use case.

4. Urutan dalam sequence diagram seharusnya menjadi fokuds utama karena realisasi use-case perancangan sesungguhnya merupakan asupan utama dalam saat use case yang bersangkutan kelak diimplementasikan.

5. Gunakan label-label dan aliran event-event perancangan untuk melengkapi dan menjelaskan squence diagram yang telah kita buat.

6. Sequence diagram seharusnya menangani semua realisasi yang ada pada use case yang direalisasikan. Mengidentifikasi subsistem serta antarmuka yang berpartisipasi

Suatu realisai use case perancangan bisa dideskripsikan pada berbagai peringkat dalam hirarki subsitem. Untuk memulainya, merupakan hal yang penting untuk mengenali dan mengidentifikasi subsistem perancangan yang diperlukan untuk nmerealisasikan use case analisis dengan cara-cara yang terlihat di bawah ini.

1. Mempelajari kelas-kelas analisis yang berpartisipasi dalam realisasi use case analisis terkait. Identifikasi paket-paket analisis yang memuat kelas-kelas analisis, kemudian identifikasi subsitem perancangan yang dapat dilacak langsung ke paket-paket analis tadi.

2. Mempelajari spesifikasi kebutuhan khus suatu realisasi use case analisis. Identifikasi kelas-kelas perancangan yang merealisasikan spesifikasi khus tersebut, kemudian identifikasi subsistem perancangan yang akan memuat kelas-kelas perancangan tadi.

3. Kumpulkan subsistem-subsistem perancangan yang berpartisipasi dalam realisasi use case dalam bentuk diagram kelas yang secara langsung berasosiasi dengan realisasi dan gunakan diagram kelas ini untuk memperhatikan kebergantungan-kebergantungan antarsubsistem pernacangan dan antarmuka subsistem

perancangan yang ada dalam realisasi use case.Mendeskrisikan interaksi antarsubsistem

Setelah mendapatkan gambaran garis besar subsistem perancangan yang diperlukan untuk merealisasikan use case tertentu, perancangan sistem juga perlu mendeskripsikan bagaimana objek-objek dari kelas-kelas perancangan yang termuat dalam subsitem itu saling berinteraksi pada peringkat subsistem. Saat melakukannya, analisis sistem menggunakan pendekatan yang cukup serupa dengan yang telah di bahas sebelumnya, dengan sedikit perbedaan seperti yang terdaftar di bawah ini.

1. Garis hidup dalam sequence diagram yang kita buat kali ini lebih memperlihatkan subsistem-subsistem perancangan. Alih-alih objek perancangan.

2. Masing-masing subsistem perancangn yang telah terdefinisi memiliki paling sedikit satu garis hidup yang telah menyatakan kehadirannya dalam sequence diagram.

3. Jika pesan-pesan diarahkan menjadi suatu operasi yang memiliki suatu antarmuka,mungkin lebih sesuai untuk mengkualifikasi pesan yang bersangkutan dalam bentuk antarmuka yang menyediakan operasi.

Perancangan kelas

Manfaat dari perancangan kelas adalah untuk membuat kelas-kelas perancangan yang memenuhi peranmya dalam realisasi use case dan spesifikasi kebutuhan. Hal ini mencakup pemeliharaan kelas perancangan itu sendiri danaspek-aspek yang penting dari kelas perancangan seperti yang terdaftar di bawah ini :

1. Operasi-operasi yang di milikinya 2. Atribut yang di milikinya

3. Relasirelasi antar kelas perancangan

4. Metode metode yang merealisasikan operasi-operasi

5. State yang terlihat

6. Kebergantungan-kebergantungan pada mekanisme-mekanisme perancangan generik 7. Spesifikasi kebutuhan yang relevanpada tahap implementasi.

8. Realisasi yang benar setiap antarmuka

BAB 5

TAHAPAN IMPLEMENTASI DAN PENGUJIAN

Tujuan utama tahap implementasi adalah mengimplementasikan arsitektur dan perancangan sistem secara keseluruhan. Lebih spesifik, tujuan dan tahap implementasi adalah untuk hal-hal yang tertulis di bawah ini.

1. Melakukan integrasi sistem seperti yang seharusnya terjadi pada setiap iterasi. Pendekatan kita sebagai analis sistem saat ini adalah bersifat inkremental (penambahan sedikit demi sedikit), dimana hasilnya adalah sistem/perangkat lunak yang diimplementasikan secara bertahap melalui bagian - bagian yang ukurannya kecil serta mudah dikelola.

2. Menebarkan sistem/perangkat lunak dengan memetakan komponen - komponen yang dapat dieksekusi ke dalam simpul - simpul yang ada pada model deployment. Hal mi terutama berbasis pada kelas - kelas aktif yang sebelumnya sudah ditemukan dalam tahap perancangan.

3. Mengimplementasikan kelas - kelas perancangan dan subsistem - subsistem yang ditemukan dalam tahap perancangan. Pada umumnya, kelas - kelas perancangan bisa langsung diimplementasikan dalam bentuk komponen - komponen berkas yang memuat kode sumber dalam bahasa pemrograman berorientasi objek yang dipilih.

4. Mempersiapkan pengujian terhadap komponen - komponen sistem/perangkat lunak dan kemudian mengintegrasikannya dengan melakukan kompilasi dan mengaitkannya pada satu atau lebih berkas - berkas yang

dapat dieksekusi sebelum mereka akhirnya diuji secara utuh (dalam bentuk sistem/perangkat lunak terintegrasi).Model Implementasi

Model implementasi sesungguhnya mendeskripsikan bagaimana elemen-elemen dalam model perancangan. Dalam hal ini, dikenal beberapa stereotype untuk komponen-komponen yaitu:

1. <<executable>> adalah program-program komputer yang dapat berjalan di simpul-simpul komputer.

2. <<file>> pada dasarnya merupakan suatu berkas yang memuat kode-kode sumber (source code) atau data.

3. <<library>> adalah berkas-berkas statis atau pustaka-pustaka dinamis.

4. <<table>> merupakan tabel-tabel dalam sistem basis data yang digunakan.

5. <<document>> merupakan dokumen. Subsistem

Mengorganisasi komponeri-komponen model implementasi ke bagian-bagian yang lebih mudah untuk dipaharni serta dikelola. Paket-paket pada Iingkungan implementasi seperti :

1. Suatu package dalam bahasa pemrograman Java.

2. Suatu project dalam bahasa pemrograman Visual Basic aau C#.

3. Suatu directoiy berkas-berkas dalam proyek-proyek bahasa pemrograman C++. Antarmuka (Interface)

1. Dekomposisi model implementasi menjadi subsstem-subsistem.

2. Komponen-komponen kunci, seperti komponen-komponeri yang dapat dilacak ke kelas-kelas perancangan. Adapun manfaat dan implementasi arsitektural sistem/perangkat lunak adaIah untuk menggambaran model implementasi dan arsitekturnya dengan cara mengidentifikasi komponen-komponen yang secara arsitektur penting.

Mengintegrasikan Sistem Adapun beberapa kriteria untuk pengembangan ‗build‘yang menerus mncakup beberapa hal berikut mi.

1. ‗Build‘ seharusnya menambahkan ftingsionaIitas-fungsionalitas tertentu pada ‗build‘sebelumnya dengan mengimplementasikan use case dan/atau skenario lengkap.

2. ‗Build‘ sebaiknya tidak melibatkan terlalu bariyak komponen-komponen barn. Jika hal mi terjadi mungkin akan sangat sulk mengintegrasikan ‗build‘ dan juga terlalu- ‗berat‘ (baca: sukar) untuk melaksanakan pengujian integrasi.

3. ‗Build‘ seharusnya berbasis pada ‗build‘ sebelumnya dan ‗build‘ yang bersangkutan sebaiknya berkembang ke

‗atas‘ pada sisi-sisi hierarki subsistem berlapis.

Mengimplementasikan Subsistem

Manfaat dan mengimplementasikan subsistem adalah untuk memastikan bahwa subsistem-subsistem memenuhi perannya dalam masing-masing ‗build. Suatu subsistern dikatakan memenuhi kegunaannya saat spesifikasispesifikasi kebutuhan (use case dan/atau skenario) diimplementasikan dalam ‗build‘ tersebut dan semua imbas pada subsistem secara benar diimplementasikan oleh komponen-komponen di dalam -subsistem tersebut.Implementasi Kelas-Kelas Perancangan Menjadi Kode Program

Sebelumnya kita telah menyinggung seclikit tentang filosofi pengujian. Dalam bagian mi dan selanjutnya (yang kita sebut sebagai aliran kerja pengujian). kita melakukan verifikasi hasil tahapan implementasi menggunakan baik ‗builo‖internal maupun ‗build‘antara, untuk rnenghasilkan versi akhir (final) yang kelak akan diluncurkan ke pihak-pihak luar yang akan memanfaatkan sistem/perangkat lunak yang dikembangka n. Lebi h spesifik. tujuan aktivitas-aktivitas pengujian adalah untuk hal-hal yang terdaftar berikut mi.

1. Merencanakan pengujian-pengujian yang diperlukan dalam masingmasing iterasi, termasuk pengujian-pengujian integrasi dan penguji.an-pengujian sistemlperangkat lunak secara keseluruhan. Pengujian integrasi hams dilakukan untuk masing-masing ‗build‘di daiam setiap iterasi, sementara pengujian sistem (baca: perangkat lunak yang utuh) pada prinsipnya hanya akan dilakukan pada bagian akhir iterasi.

2. Membuat perancangan pengujian dan melakukan implementasi pengujian dengan cara membuat kasus-kasus pengujian yang menspesifikasi apa yang hams diuji, serta membuat prosedur-prosedur pengujian yang pada dasarnya menspesifikasi bagaimana cara melakukan pengujian-pengujian, serta (jika memang memungkinkan) membuat komponen-komponen pengujian yang dapat melakukan pengujianpengujian secara otomatis.

3. Melakukan berbagai pengujian dan secara sistematis menangani hasil dan masing-masing pengujian yang dilakukan. ‗Build‘yang diketahui memiliki cacat akan diuji-ulang dan kemun,gkinan alcan dikirim kembali ke aliran kerja implementasi yang menghasilkannya sehingga cacat tersebut bisa diperbaiki oleb perekayasa komponen yang memang bertugas untuk hal ini.

Model Pengujjian

Berikut ini kita daftarkan kasus-kasus pengujian yang paling umum.

1. Kasus oengujian yang menspesifikasi bagaiuana melakukan pengujian suatu use case atau suatu skenario yang bersifat spesifIk. Beberapa kasus pengujian memverifikasi hasil dan interaksi yang terjadi di antara para actor dengan sistem/perangkat lunak yang dikembangkan, yaitu memverifikasi apakah kondisi awal (pre-condition) dan kondisi akhir (post-condition) yang dispesifikasi oleh use case terpenuhi, serta juga memverifikasi apakah urutan aksi-aksi (baca: flow-of-events) yang dispesifikasi oleh use case memang diikuti. Perhatikan di sini bahwa filosofi pengujian yang diikuti adalah ―black-box testing‘.

2. Kasus pengujian yang menspesifikasi bagaimana melakukan pengujian realisasi use case-perancangan atau melakukan pengujian pada suatu skenario realisasi yang bersifat spesifik. Kasus pengujian cii sini mencakup di dalamnya verifikasi interaksi antarkomponen yang mengimplementasikan suatu use case tertentu. Perhatikan di sini bahwa fliosofI pengujian yang diikuti adalah ―white-box testing?.

Kasus-kasus pengujian lainnya dapat digunakan untuk menguji sistem perangkat lunak secara keseluruhan. Beberapa contohnya adalah:

1. Installation test yang memverifikasi apakah sistem/perangkat lunak dapat diinstal pada platform pengguna dan apakah sistem!perangkat lunak yang bersangkutan dapat beroperasi dengan baik setelah terinstal.

2. Configuration test yang memverifIkasi apakah sistem!perangkat lunak bekerja dengan baik pada berbagai konfigurasi yang berbeda (misalnya konfigurasi-konfigurasi jaringan komputer yang berbeda).

3. Negative test yang mencoba untuk menemukan hal-hal yang mengakibatkan kegagalan sistem/perangkat lunak.

4. Stress test yang mengidentifikasi permasalahan-perinasalahan yang mungkin muncul saat sumber daya komputasi yang dimiliki nya (misalnya penggunaan waktu kerja prosesor dan alokasi memori) terlampaui.

Prosedur-Prosedur Pengujian

Selanjutnya, kita akan membahas prosedur-prosedur pengüjian yang sangat erat hubungannya dengan kasus pengujian yang telah kita bahas sebelumnya. Prosedur pengujian pada dasarnya menspesifIkasi bagaimana caranya melakukan saw atau lebih kasus-kasus pengujian atau bagian dan kasus pengujian. Sebagai contoh, suatu prosedur pengujian mungkin berupa suatu perintah untuk suatu individu yang berkaitan dengan bagaimana melaksanakan kasus pengujian secara manual, atau barangkali merupakan spesifikasi bagaimana cara berinteraksi dengan kakas pengujian otomatis untuk membuat komponen-komponen pengujian yangPengujjian Integrasi

Selain kasus-kasus pengujian serta prosedur-prosedur pengujian yang telah kita bahas di atas, untuk sistem/perangkat lunak yang sangat besar‘ kompleks, sangat pentirig juga untuk melakukan pengujian integrasi. yaitu pengujian yang akan

memastikan apakah komponen-komponen dalam sistem/perangkat lunak berinteraksi dengan cara yang sesuai dengan yang diharapkan. Dalam hal mi. kebanya-kan kasus-kasus pengujian dapat diturunkan langsung dan realisasi use case-perancangan, karena realisasi use case-perancangan mi rnendeskripsikan bagairnana kelas-kelas dan objek-objek (juga kompo nen-komponen) saling ben titeraksi untuk merealisasikan suatu use case tertentu. Dalam hal mu, pereka— yasa pengujian semestinya inembuat sejumiah kasus pengujian yang memungkinkan sasaran pengujian dapat dicapai dengan usaha sekecilkecilnya. Untuk melakukan hal mi, perancang pengujian harus inenemukan sejumlah kasus pengujian dengan tumpang-tindih seminirnal mungkin, di mana masing-masing pengujian mengikuti realisasi use case pada lintasan skenario yang paling penting saja.

Perancangan Dan Implementasi Pengujan

Dalam kasus sistern-sistem. perang1at lunak yang berukuran sangat besar dan kompleks. perekayasa pengujian seringkaii perlu juga melakukan pengujian integrasi. yang tujuannya adalah sebagaimana yang terdaftar di bawah mi.

1. Melakukan pengujian-pengujian integrasi yang relevan pada ‗build‘ pada iterasi tertentu dengan cara secara manual melaksanakan p rosedur-prosedur pengujian u ntuk masing-masing kasus pengujian atau denga n inengeksekusi komponen-komponen pengujian yang akan melakukan otomatisasi prosedur-prosedur pengujian.

2. Membandingkan hasil-hasil pengujian dengan hasil-hasil yang diharapkan dan mengarialisis simpangan-simpangan yang terjadi (jika ada).

3. Melaporkan cacat-cacat pada cistem/perangkat lunak (pka ada) kepada perekayasa komponen yang bertanggung jawab pada pembuatan komponen-komponen