Architectural Design

1. Pendidikan Teknik Informatika dan Komputer - 2011 Architectural Design Software Engineering Chapter 10 Rekayasa Perangkat Lunak Chapter 10

2. Kelompok 3 092904006 Syaputri Artami S. 092904010 Ayu Anggriani H. 092904011 Rudy Dian Syah 092904030 Zulfadli Sulthan 092904035 Jumiati 092904041 Husnaeni 092904043 Nurhalimah Rekayasa Perangkat Lunak Chapter 10

3. Topics • Penstrukturan sistem • Model kontrol • Dekomposisi modular • Arsitektur spesifik-domain Rekayasa Perangkat Lunak Chapter 10

4. Software architecture • Proses perancangan untuk mengidentifikasi sub-sistem yang membangun sebuah sistem dan merupakan kerangka kerja bagi kontrol dan komunikasi sub-sistem adalah perancangan arsitektural • Hasil dari perancangan ini dideskripsikan sebagai arsitektur perangkat lunak Rekayasa Perangkat Lunak Chapter 10

5. Architectural design • Merupakan tahap awal dari proses perancangan sistem • Merupakan hubungan antara spesifikasi dan proses desain • Sering dilakukan secara paralel dengan beberapa aktifitas spesifikasi • Hal ini melibatkan identifikasi komponen utama sistem dan proses komunikasinya Rekayasa Perangkat Lunak Chapter 10

6. Advantages of explicit architecture • Komunikasi stakeholder • Arsitektur dapat dijadikan sebagai fokus diskusi bagi para pemegang kepentingan (stakeholder) • Analisis sistem • Menganalis apakah sistem dapat memenuhi persyaratan kritis seperti kinerja, keandalan dan keampuan pemeliharaan • Pemakaian ulang berskala besar • Arsitektur mungkin dapat digunakan kembali pada berbagai sistem Rekayasa Perangkat Lunak Chapter 10

7. Architectural design process • Penstrukturan sistem • Sistem distruktur menjadi sejumlah sub-sistem utama dan pengidentifikasian komunikasi antar sub-sistem • Pemodelan kontrol • Model umum hubungan kontrol antara bagian-bagian sistem ditetapkan • Dekomposisi modular • Susb-sistem diidentifikasi dan didekomposisi menjadi modul-modul Rekayasa Perangkat Lunak Chapter 10

8. Sub-systems and modules • Sub-sistem adalah sistem yang berkerja secara independen berdasarkan layanan yang diberikan oleh sub-sistem lainnya • Modul adalah komponen sistem satu atau lebih layanan untuk modul lain tapi umumnya tidak dianggap sebagai sistem yang terpisah Rekayasa Perangkat Lunak Chapter 10

9. Architectural models • Model arsitektur yang berbeda dapat saja dihasilkan selama proses perancangan • Setiap model meyajikan perspektif yang berbeda berdasarkan pada arsitekturnya Rekayasa Perangkat Lunak Chapter 10

10. Architectural models • Model struktural statis menggambarkan komponen sistem utama • Model proses dinamis menggambarkan struktur proses dari sistem • Model interface yang menunjukkan interface sub-sistem • Model hubungan menunjukkan hubungan seperti aliran data antar sub-sistem Rekayasa Perangkat Lunak Chapter 10

11. Architectural styles • Model arsitektur sistem mungkin sesuai dengan model atau gaya arsitektural generik • Kesadaran gaya ini dapat menyederhanakan masalah sistem dalam mendefinisikan arsitekturnya • Namun, banyak sistem besar yang sangat heterogen dan tidak mengikuti perancangan arsitektural tunggal Rekayasa Perangkat Lunak Chapter 10

12. Architecture attributes • Kinerja • Melokalisasi operasi-operasi kritis untuk meminimalkan komunikasi antar sub-sistem • Keamanan • Menggunakan arsitektur berlapis, dan menempatkan aset terpenting pada lapisan terdalam • Keselamatan • Mengisolasi keselamatan tethadap komponen-komponen kritis • Ketersediaan • Menyertakan redudan komponen tanpa menghentikan sistem • Kemampuan pemeliharaan • Menggunakan komponen kecil dan berdiri sendiri dan dapt diganti sesegera mungkin Rekayasa Perangkat Lunak Chapter 10

13. System structuring • Behubungan dengan dekomposisi sistem ke interaksi sub-sistem • Perancangan arsitektural biasanya dinyatakan dalam blok diagram yang menyajikan gambaran dari struktur sistem • Beberapa model-spesifik menunjukkan cara sub-sistem berbagi data, distribusi dan antarmuka satu sama lain yang dapat dibangun Rekayasa Perangkat Lunak Chapter 10

14. Packing robot control system Rekayasa Perangkat Lunak Chapter 10

15. The repository model • Sub-sistem melakukan pertukaran data. Hal ini dimungkinkan dengan 2 cara: • Data disimpan pada sebuah pusat database atau repository yang dapat diakses oelh semua sub-sistem • Setiap sub-sistem memelihara database sendiri dan dapat dipertukarkan dengan sub-sistem lain dengan mengirimkan message kepadanya • Dalam hal berbagi data dalam jumlah yang sangat besar, model repository yang paling fleksible untuk digunakan Rekayasa Perangkat Lunak Chapter 10

16. CASE toolset architecture Rekayasa Perangkat Lunak Chapter 10

17. Repository model characteristics • Kelebihan • Cara yang efisien berbagi data dalam jumlah besar • Sub-sistem tidak perlu tahu bagaimana data yang diproduksi oleh manajemen terpusat. Misalanya backup, keamanan dll. • Model berbagi data berbentuk skema repository • Kekurangan • Sub-sistem harus setuju pada model data repository. Hal ini merupakan komporomi antara kebutuhan-kebutuhan khusus dari setiap alat bantu • Evolusi data sulit dan mahal • Model repository memaksakan kebijakan yang sama untuk semua sub-sistem • Mungkin sulit untuk mendistribusikannya secara efektif ke sejumlah mesin. Rekayasa Perangkat Lunak Chapter 10

18. Client-server architecture • Model sistem terdistribusi menunjukkan bagaimana data dan pengolahannya didistribusikan ke berbagai komponen • Stand-alone server menyediakan layan khusus seperti pencetakan, manajemen data, dll. • Client yang mengakses layanan tersebut • Dengan teknologi jaringan, client di mungkinkan untuk dapat mengakses server Rekayasa Perangkat Lunak Chapter 10

19. Film and picture library Rekayasa Perangkat Lunak Chapter 10

20. Client-server characteristics • Kelebihan • Distribusi data langsung • Efektif dengan menggunkan sistem jaringan. • Mudah untuk menambah server baru atau meng-upgrade server yang ada. • Kekurangan • Tidak ada model berbagi data yang sama sehingga sub-sistem menggunakan organisasi data yang berbeda. Pertukaran data menjadi tidak efisien dalam kasus ini. • Diperlukan manajemen redudansi data disetiap server. • Tidak ada pusat registrasi nama server dan servisnya. Hal ini menyebabkan kesulitan mengetahui apakah server dan layan tersedia atau tidak Rekayasa Perangkat Lunak Chapter 10

21. Abstract machine model • Digunakan untuk model interfacing sub-sistem • Model ini mengorganisir sistem menjadi serangkaian lapisan yang masing-masing menyediakan serangkaian layanan • Mendukung pengembangan sub-sistem secara incremental pada lapisan yang berbeda. Ketika antar muka lapisan dirubah, hanya lapisan terdekat yang dipengaruhinya • Namun, sangat sulit untuk struktur sistem seperti ini Rekayasa Perangkat Lunak Chapter 10

22. Version management system Rekayasa Perangkat Lunak Chapter 10

23. Control models • Model struktural tidak seharusnya mencakup informasi kontrol. Hal ini berkenaan dengan kontrol aliran data antar sub-sistem • Kontrol tersentralisasi • Satu sub sistem memiliki tanggung jawab menyeluruh untuk mengontrol dan memulai dan menghentikan sub-sistem lainnya • Kontrol berbasis-event • Setiap sub-sistem menanggapi event yang dibangkitkan secara eksternal dari sub-sistem lain atau dari lingkungan sistem itu sendiri Rekayasa Perangkat Lunak Chapter 10

24. Centralised control • Merupakan sub-sistem yang ditujukan sebagai pengendali dan memiliki tanggungjawab untuk mengatur eksekusi sub-sistem lainnya • Model call-return • Model subrutin top-down yang biasa, dimana kontrol kontrol dimulai dari puncak hirarki subrutin dan diteruskan ktingkat yang lebih bawah. Model ini diterapkan pad sistem sekuensial • Model manajer • Model ini diterapkan pada sistem konkuren. Sebuah komponen sistem mengontrol proses penghentian, memulai dan koordinasi proses-proses sistem lainnya. Model ini diimplementasikan sebagai statement case Rekayasa Perangkat Lunak Chapter 10

25. Call-return model Rekayasa Perangkat Lunak Chapter 10

26. Real-time system control Rekayasa Perangkat Lunak Chapter 10

27. Event-driven systems • Model kontrol event-driven dikendalikan oleh event yang dibangkitkan secara eksternal dimana timing event berada diluar kontrol proses yang menangani event tersebut • Model kontrol event-driven • Model Broadcast. Sebuah event dibroadcast ke semua sub-sistem. Setiap sub-sistem yang dapat menangani event ini akan menanggapinya. • Model interrupt-driven. Digunakan pada sistem real-time dimana interupt eksternal dideteksi oleh sebuah intterupt handler dan kemudian diteruskan ke komponen lain untuk diolah Rekayasa Perangkat Lunak Chapter 10

28. Broadcast model • Efektif dalam mengintegrasikan sub-sistem pada komputer yang berbeda dalam jaringan • Sub-sitem didaftarkan untuk event-event tertentu, Ketika hal ini terjadi makan kontrol akan ke sub-sistem yang dapat meangani event tersebut • Kebijakan kontrol tidak tertanam dalam pesan dan event handler. Sub-sistem mengerjakan event yang sesuai dengan fungsinya • Namun, sub-sistem tidak tahu apa dan kapan event itu harus ditangani Rekayasa Perangkat Lunak Chapter 10

29. Selective broadcasting Rekayasa Perangkat Lunak Chapter 10

30. Interrupt-driven systems • Digunakan pada sistem real-time dimana respon cepat terhadap event penting • Ada jenis interrupt yang dikenali, yang didefiniskan handler untuk setiap tipenya • Setiap tipe intterupt dihubungkan dengan lokasi memori dimana alamt handler disimpan • Memungkinkan respon yang cepat tapi kompleks untuk program dan validasi yang sulit Rekayasa Perangkat Lunak Chapter 10

31. Interrupt-driven control Rekayasa Perangkat Lunak Chapter 10

32. Modular decomposition • Another structural level where sub-systems are decomposed into modules • Two modular decomposition models covered • An object model where the system is decomposed into interacting objects • A data-flow model where the system is decomposed into functional modules which transform inputs to outputs. Also known as the pipeline model • If possible, decisions about concurrency should be delayed until modules are implemented Rekayasa Perangkat Lunak Chapter 10

33. Modular decomposition • Level struktrural lain diman sub-sistem di dekomposisi menjadi sebuah modul • Model Dekomposisi modular : • Model berorientasi objek. Sistem diuraikan menjadi serangkaian objek yang berkomunikasi • Model Aliran data. Sistem diuraikan menjadi modul-modul fungsional yang mengubah input menjadi ouput. Biasa disebut pipilining • Jika mungkin, keputusan tentang konkuransi harus ditunda sampai modul diimplementasikan Rekayasa Perangkat Lunak Chapter 10

34. Object models • Struktur sistem menjadi serangkaian objek yang terhubung longgar dengan interface yang terdefinisi dengan baik • Dekomposisi berorientasi-objek berkaitan dengan identifikasi kelas objek, atribut dan operasinya • Ketika diimplementasikan, objek dibuat dari kelas-kelas ini dan beberapa model kontrol digunakan untuk mengkoordinasikan operasi suatu objek Rekayasa Perangkat Lunak Chapter 10

35. Invoice processing system Rekayasa Perangkat Lunak Chapter 10

36. Data-flow models • Funngsi utamanya adalah mentransformasikan input menjadi output • Kadangkala disebut pipeline dan filter, mengikuti istilah yang dipakai pada sistem Unix • Varian model ini umum digunakan. Ketika transformasi bersifar sekuensial dengan data yang diproses dalam batch, model arsitektural ini merupakan model sekuensial batch • Tidak cocok untuk sistem yang interaktif Rekayasa Perangkat Lunak Chapter 10

37. Invoice processing system Rekayasa Perangkat Lunak Chapter 10

38. Domain-specific architectures • Model arsitektural yang yang spesifik bagi suatu domain aplikasi • Tipe model arsitektural spesifik-domain • Model Generik yang merupakan abstraksi dari sejumlah sisem riil. Model ini meng-enkapsulasi karakteristik utama dari sistem. • Model referensi, yang lebih abstrak dan mendeskripsikan kelas sistem yang lebih besar dan membandingkan arsitektur yang berbeda • Model generik biasanya diturunkan secara ‘bottom-up’dari sistem yang sudah ada; sedangkan model referensi diturunkan secara ‘top-down’. Rekayasa Perangkat Lunak Chapter 10

39. Generic models • Model compiler merupakan contoh yang paling terkenal dari model arsitektural generik • Penganalisa leksikal • Tabel simbol • Penganalisa sintaks • Pohon sintaks • Penganalisa semantik • Generator kode • Model Compiler generik dapat diatur berdasarkan model arsitektural yang berbeda Rekayasa Perangkat Lunak Chapter 10

40. Compiler model Rekayasa Perangkat Lunak Chapter 10

41. Language processing system Rekayasa Perangkat Lunak Chapter 10

42. Reference architectures • Model referensi berasal dari studi domain aplikasi bukan dari sistem yang ada • Dapat digunakan sebagai dasar untuk implementasi sistem atau untuk membandingkan sistem yang berbeda. Karena berfungsi sebagai standar terhadap sistem yang dapat dievaluasi • Model OSI adalah model berlapis untuk sistem komunikasi. Rekayasa Perangkat Lunak Chapter 10

43. OSI reference model Application Rekayasa Perangkat Lunak Chapter 10

44. Key points(1) • Arsitektur perangkat lunak merupakan kerangka kerja fundamental bagi penstrukturan sistem seperti model struktural, model kontrol dan model dekomposisi • Sistem yang besar jarang mengikuti satu model arsitektural • Model dekomposisi sistem meliputi model repository, model client-server, dan model mesin abstrak (virtual machine) • Model Kontrol meliputi kontrol tersentralisasi dan model event-driven. Rekayasa Perangkat Lunak Chapter 10

45. Key points (2) • Model dekomposisi modular meliputi Model aliran data dan Model objek • Model arsitektural spesifik-domain merupakan abstraksi terhadap domain aplikasi. Model ini dibangun dari sistem yang sudah ada, atau model referensi yang merupakan model ideal dan abstrak dari domain Rekayasa Perangkat Lunak Chapter 10

46. Thank you....!!! Rekayasa Perangkat Lunak Chapter 10