Pertemuan 10 RPL

                
                                      ARCHITECTURAL DESIGN

    Why Architecture?
Arsitektur bukan perangkat lunak operasional. Sebaliknya, ini adalah representasi yang memungkinkan insinyur perangkat lunak untuk:

1. menganalisis efektivitas desain dalam memenuhi persyaratan yang dinyatakan
2. mempertimbangkan alternatif arsitektur pada tahap ketika membuat perubahan desain masih relatif mudah, dan
3. mengurangi risiko yang terkait dengan pembangunan perangkat lunak.

Mengapa Arsitektur Penting?

1.  Representasi arsitektur perangkat lunak adalah enabler untuk komunikasi antara semua pihak (pemangku kepentingan) yang tertarik dalam pengembangan sistem berbasis komputer.
2. Arsitektur menyoroti keputusan desain awal yang akan memiliki dampak mendalam pada semua pekerjaan rekayasa perangkat lunak yang mengikuti dan, yang penting, pada keberhasilan akhir sistem sebagai entitas operasional.
3.  Arsitektur "merupakan mode yang relatif kecil, dapat dipahami secara intelektual tentang bagaimana sistem disusun dan bagaimana komponen-komponennya bekerja bersama" [BAS03].

    Deskripsi Arsitektur

Ø  Masyarakat Komputer IEEE telah mengusulkan IEEE-Std-1471-2000, Praktek yang Direkomendasikan untuk Deskripsi Arsitektur Sistem Perangkat Lunak-Intensif, [IEE00]

·         untuk membangun kerangka kerja konseptual dan kosakata untuk digunakan selama desain arsitektur perangkat lunak,

·         untuk memberikan pedoman terperinci untuk mewakili deskripsi arsitektur, dan

·         untuk mendorong praktik desain arsitektur yang baik.

Ø  Standar IEEE mendefinisikan deskripsi arsitektur (AD) sebagai "kumpulan produk untuk mendokumentasikan arsitektur."

·         Deskripsi itu sendiri diwakili menggunakan beberapa pandangan, di mana setiap pandangan adalah "representasi dari keseluruhan sistem dari perspektif seperangkat keprihatinan [pemangku kepentingan] terkait."

       Architectural Genres

Ø  Genre menyiratkan kategori tertentu dalam domain perangkat lunak keseluruhan.

Ø  Dalam setiap kategori, Anda menemukan sejumlah subkategori.

·         Misalnya, dalam genre bangunan, Anda akan menemukan gaya umum berikut: rumah, kondominium, gedung apartemen, gedung perkantoran, gedung industri, gudang, dan sebagainya.

·         Dalam setiap gaya umum, gaya yang lebih spesifik mungkin berlaku. Setiap gaya akan memiliki struktur yang dapat digambarkan menggunakan seperangkat pola yang dapat diprediksi.

Architectural Styles

Setiap gaya menggambarkan kategori sistem yang mencakup: (1) satu set komponen (misalnya, database, modul komputasi) yang melakukan fungsi yang diperlukan oleh suatu sistem, (2) satu set konektor yang memungkinkan "komunikasi, koordinasi dan kerja sama" di antara komponen, (3) kendala yang menentukan bagaimana komponen dapat diintegrasikan untuk membentuk sistem, dan (4) model semantik yang memungkinkan perancang memahami sifat keseluruhan sistem dengan menganalisis properti yang diketahui dari bagian-bagian penyusunnya.

§  Arsitektur yang berpusat pada data

§  Arsitektur aliran data

§  Panggil dan kembalikan arsitektur

§  Arsitektur berorientasi objek

§  Arsitektur berlapis

Layered Architecture

Architectural Patterns

1.      Concurrency — aplikasi harus menangani banyak tugas dengan cara yang mensimulasikan paralelisme

§  pola manajemen proses sistem operasi

§  pola penjadwal tugas

2.      Kegigihan — Data tetap ada jika data bertahan melewati proses yang membuatnya. Dua pola umum:

§  pola sistem manajemen basis data yang menerapkan kemampuan penyimpanan dan pengambilan DBMS ke arsitektur aplikasi

§  pola persistensi tingkat aplikasi yang membangun fitur kegigihan ke dalam arsitektur aplikasi

3.      Distribusi - cara di mana sistem atau komponen dalam sistem berkomunikasi satu sama lain dalam lingkungan terdistribusi

§  Pialang bertindak sebagai 'perantara' antara komponen klien dan komponen server.

Architectural Design

Ø  Perangkat lunak harus ditempatkan dalam konteks

§  desain harus mendefinisikan entitas eksternal (sistem lain, perangkat, orang) yang berinteraksi dengan perangkat lunak dan sifat interaksi

Ø  Seperangkat arketipe arsitektur harus diidentifikasi

§  Arketipe adalah abstraksi (mirip dengan kelas) yang mewakili satu elemen perilaku sistem

Ø  Perancang menentukan struktur sistem dengan mendefinisikan dan memperbaiki komponen perangkat lunak yang menerapkan setiap arketipe

Architectural Complexity (Kompleksitas Arsitektur)

n  kompleksitas keseluruhan dari arsitektur yang diusulkan dinilai dengan mempertimbangkan ketergantungan antara komponen dalam arsitektur [Zha98]

§  Berbagi dependensi merupakan hubungan ketergantungan antara konsumen yang menggunakan sumber daya yang sama atau produsen yang memproduksi untuk konsumen yang sama.

§  Ketergantungan dependensi merupakan hubungan ketergantungan antara produsen dan konsumen sumber daya.

§  Ketergantungan dependensi merupakan kendala pada aliran relatif kontrol di antara serangkaian kegiatan.

Pertemuan 9 RPL

     

                                                     KONSEP DESAIN

     Mitch Kapor, pencipta Lotus 1-2-3, mempresentasikan “manifesto desain perangkat lunak” di Dr. Dobbs Journal. Dia berkata: Desain perangkat lunak yang baik harus menunjukkan:

-          Ketegasan: Suatu program tidak boleh memiliki bug yang menghambat fungsinya.

-          Komoditas: Suatu program harus sesuai untuk tujuan yang dimaksudkan.

-          Delight: Pengalaman menggunakan program harus menyenangkan.

Design and Quality

-          desain harus mengimplementasikan semua persyaratan eksplisit yang terkandung dalam model analisis, dan harus mengakomodasi semua persyaratan implisit yang diinginkan oleh pelanggan.

-          desain harus menjadi panduan yang dapat dibaca dan dimengerti bagi mereka yang menghasilkan kode dan bagi mereka yang menguji dan kemudian mendukung perangkat lunak.

-          desain harus memberikan gambaran lengkap dari perangkat lunak, menangani data, domain fungsional, dan perilaku dari perspektif implementasi.

Prinsip-prinsip Desain

-          Proses desain seharusnya tidak mengalami 'penglihatan terowongan.'

-          Desain harus dapat dilacak ke model analisis.

-          Desain seharusnya tidak menemukan kembali roda.

-          Desain harus "meminimalkan jarak intelektual" antara perangkat lunak dan masalah seperti yang ada di dunia nyata.

-          Desain harus menunjukkan keseragaman dan integrasi.

-          Desain harus terstruktur untuk mengakomodasi perubahan.

-          Desain harus terstruktur untuk terdegradasi dengan lembut, bahkan ketika data, peristiwa, atau kondisi operasi yang menyimpang ditemukan.

-          Desain bukan coding, coding bukan desain.

-          Desain harus dinilai kualitasnya saat dibuat, bukan setelah fakta.

-          Desain harus ditinjau untuk meminimalkan kesalahan konseptual (semantik)

Fundamental Concepts

·         Abstraksi — data, prosedur, control

·         Arsitektur — struktur keseluruhan perangkat lunak

·         Pola— ”menyampaikan esensi” dari solusi desain yang terbukti

·         Pemisahan masalah — masalah rumit apa pun bisa lebih mudah ditangani jika dibagi menjadi beberapa bagian

·         Modularitas — kompartementalisasi data dan fungsi

·         Menyembunyikan — antarmuka yang dikendalikan

·         Independensi fungsional — fungsi pikiran tunggal dan kopling rendah

·         Refinement — elaborasi detail untuk semua abstraksi

·         Aspek — mekanisme untuk memahami bagaimana persyaratan global memengaruhi desain

·         Refactoring — teknik reorganisasi yang menyederhanakan desain

·         Kelas Desain — sediakan detail desain yang akan memungkinkan kelas analisis diimplementasikan

       Design Classes

1     .      Kelas analisis disempurnakan selama desain untuk menjadi kelas entitas

2     .      Kelas batas dikembangkan selama desain untuk membuat antarmuka (mis., Layar interaktif atau laporan tercetak) yang dilihat dan berinteraksi dengan pengguna saat perangkat lunak digunakan.

Ø  Kelas batas dirancang dengan tanggung jawab mengelola cara objek entitas diwakili kepada pengguna.

3    .      Kelas-kelas pengendali dirancang untuk dikelola

Ø  pembuatan atau pembaruan objek entitas;

Ø  Instansiasi objek batas ketika mereka memperoleh informasi dari objek entitas;

Ø  komunikasi yang kompleks antara set objek;

Ø  validasi data yang dikomunikasikan antar objek atau antara pengguna dan aplikasi. 

      Design Model Elements

1     .      Elemen data

Ø  Model data -> struktur data

Ø  Model data -> arsitektur basis data

2    .      Elemen arsitektur

Ø  Domain aplikasi

Ø  Kelas analisis, hubungan mereka, kolaborasi dan perilaku diubah menjadi realisasi desain

Ø  Pola dan "gaya" (Bab 9 dan 12)

3    .      Elemen antarmuka

Ø  antarmuka pengguna (UI)

Ø  antarmuka eksternal ke sistem, perangkat, jaringan atau produsen lain atau konsumen informasi

Ø  antarmuka internal antara berbagai komponen desain.

4       .      Elemen komponen

5    .      Elemen penyebaran

Pertemuan 8 RPL

      
       REQUIREMENT MODELING : FLOW, BEHAVIOR, PATTERNS, AND WEBAPPS

       1.      Requirements Modeling Strategies

-          Satu pandangan requirement modelling, yang disebut analisis terstruktur, mempertimbangkan data dan proses yang mengubah data sebagai entitas yang terpisah.

-          Objek data dimodelkan dengan cara yang mendefinisikan atribut dan hubungan mereka.

-          Proses yang memanipulasi objek data dimodelkan dengan cara yang menunjukkan bagaimana mereka mengubah data sebagai objek data mengalir melalui sistem.

-          Pendekatan kedua untuk analisis yang dimodelkan, yang disebut analisis berorientasi objek, berfokus pada definisi kelas dan cara mereka berkolaborasi satu sama lain untuk mempengaruhi persyaratan pelanggan.

2.        Flow-Oriented Modeling

-          Merupakan bagaimana objek data ditransformasikan saat mereka bergerak melalui system

-          data flow diagram (DFD) adalah bentuk diagram yang digunakan

-          Dianggap oleh banyak orang sebagai pendekatan "jadul", tetapi terus memberikan pandangan tentang sistem yang unik — itu harus digunakan untuk melengkapi elemen model analisis lainnya.

  External Entity

-          Produser atau konsumen data

-          Contoh: seseorang, perangkat, sensor

-          Contoh lain: berbasis computer system

-          Data harus selalu berasal dari suatu tempat dan harus selalu dikirim ke sesuatu

  Process

-          Trafo data (mengubah input untuk output)

-          Contoh: menghitung pajak, menentukan area, format laporan, grafik tampilan

-          Beberapa data harus selalu diproses cara untuk mencapai fungsi system

  

 Data Flow

è Data mengalir melalui suatu sistem, dimulai sebagai input dan ditransformasikan menjadi output.

 Data Stores

è Data sering disimpan untuk digunakan nanti.

Pertemuan 7 RPL

                                           REQUIREMENT MODELING

Requirement Modelling dalam rekayasa perangkat lunak pada dasarnya adalah tahap perencanaan aplikasi atau sistem perangkat lunak. Secara umum, proses akan dimulai ketika bisnis atau entitas (misalnya, lembaga pendidikan) mendekati tim pengembangan perangkat lunak untuk membuat aplikasi atau sistem dari awal atau memperbarui yang sudah ada. Pemodelan kebutuhan terdiri dari beberapa tahap, atau 'pola': pemodelan berbasis skenario, pemodelan data, pemodelan berorientasi aliran, pemodelan berbasis kelas dan pemodelan perilaku. Setiap tahapan / pola ini meneliti masalah yang sama dari perspektif yang berbeda.

Requirement Modelling

-          Scenario

-          Information

-          Analysis classes

Contoh : ERD

Requirement Analysis

·         Menjelaskan karakteristik perangkat lunak

·         Dilihat dari interface

·         Memperbolehkan melakukan beberapa hal :

-          Elaborasi

-          Membangun user scenario, dipresentasikan dengan use case/ UML

A Bridge

Rules of Thumb

-          Setiap elemen model analisa bisa mudah dipahami karena kebutuhan dapat menjadi informasi

-          Meminimalisasi adanya ketergantungan hubungan

-          Model analisa bisa digunakan untuk stakeholder

Domain Analysis

-          Domain yang nanti diinvestigasi , dikoleksi menjadi representasi aplikasi

-          Analisa model kemudian dikembangkan

Pertemuan 6 RPL

MEMAHAMI REQUIREMENT

        ·         Inception :

-          Mengetahui masalah dasarnya

-          Menentukan siapa yang mendapat solusi tersebut

-          Mencari solusi secara alami

-          Perlu ada komunikasi antara customer dan developer

·         Elicitation :

-          Mengetahui kebutuhan stakeholder

-          Permasalahan yang berkaitan dengan kestabilan

·         Elaboration : berfokus pengembangan model kebutuhan

·         Negosiation : bagaimana bentuk negosiasi antara customer dan developer

·         Spesification : penulisan dokumen, pembuatan prototype

·         Validation : ada missing informasi atau tidak, realistis/tidak

·         Requirement Management : ketika ada perubahan masih bisa handle

1.      Inception

§  Mengidentifikasi stakeholder :

-          Siapa yang mendapatkan solusi?

§  Melihat dari banyak sudut pandang

§  Bekerja dengan adanya kolaborasi, karena perangkat lunak butuh direview/ dikembangkan

§  Beberapa pertanyaan :

-          Manfaat ekonomi dari solusi?

-          Apakah ada sumber lain terhadap solusi yang dibutuhkan?

2.      Eliciting Requirement

§  Perlu diadakan meeting antara engineer dan customer

§  Perlu adanya aturan untuk persiapan

§  Perlu dibuat agenda

§  Perlu fasilitator

§  Membuat dokumentasi

§  Melihat tujuan :

-          Mengidentifikasi masalah

-          Dalam negosiasi ditentukan perangkat persyaratan

3.      Quality Function Deployment

§  Function deployment

§  Information deployment

§  Task deployment

§  Value analysis