Software Architecture

Presentasi berjudul: "Software Architecture"— Transcript presentasi:

1 Software Architecture

2 Perhatikan gambar berikut

3 Hubungan antara Strategi Bisnis, Strategi SI, dan Strategi TI
Untuk merencanakan suatu strategi SI/TI terlebih dahulu perlu di ketahui kondisi lingkungan, arah dan tujuan bisnis perusahaan, informasi apa yang dibutuhkan, peluang dan hambatan bisnis yang dihadapi serta alternatif solusinya. Strategi SI Setelah mengetahui kondisi lingkungan, arah dan tujuan dari kegiatan bisnis perusahaan, maka kita dapat mengevaluasi sistem informasi apa yang sesuai dengan kebutuhan dan mendukung strategi bisnis perusahaan dalam pencapaian visi dan misi perusahaan. Strategi TI Untuk menghasilkan suatu sistem informasi yang strategis bagi perusahaan, maka kita perlu menyeleksi dan memilih secara tepat teknologi apa yang paling sesuai untuk digunakan dalam menunjang sistem informasi tersebut.

4 Enterprise architecture
Tujuan dasar dari sistem arsitektur adalah untuk mendukung lapisan yang lebih tinggi dari arsitektur enterprise.  Di banyak perusahaan,perangkat lunak dan perangkat keras merupakan bagian yang signifikan dari total aset perusahaan. Adalah penting bahwa arsitek perusahaan tidak menyamakan tugas mereka dengan objek, aplikasi, atau mesin yang terdiri dari domain mereka.  Tujuan mendasar adalah untuk mendukung dan memajukan tujuan bisnis dari perusahaan. Hardware dan software benda pada dasarnyabersifat sementara dan hanya ada untuk memajukan tujuan bisnis

5 Pengertian Software Architecture Adalah proses yg mendefinisikan solusi yg terstruktur yang memenuhi kebutuhan teknis dan operasional, disisi lain mengoptimasi quality dari sebuah aplikasi yg meliputi: performance, security, dan manageability.

6 Beberapa trend arsitektur software
Desain yg fleksibel, configurable, dan berorientasi pada experience user (user empowerment).  Penggunaan teknologi terupdate (market maturity) Fleksibilitas dalam desain sehingga aplikasi tsb reuse dan mempermudah maintenance nya (flexible design). Teknik SOA bisa dipergunakan untuk berhubungan (interoperability) dengan aplikasi lain. Mendesain aplikasi dengan memperhatikan trend masa depan (future trend)

7 Enterprise architecture model
Bussiness Information Operational Organizational Architectural Infrastuctural

8 Software Architecture
Arsitektur Software dari sebuah sistem memiliki pengaruh pada kualitas dari arsitektur organisasi/enterprice Sementara desain dari software sistem berkonsentrasi pada terealisasinya/establish fungsi yang dibutuhkan system.

9 Software Architecture
Software Architecture dari sebuah system mensupport semua kebutuhan dari system Sebagai contoh system harus terkoneksi dengan wifi atau terjadi perubahan dari bisnis rule enterprice maka software arsitektur dapat beradaptasi.

10 Apa Software Architecture itu?
Arsitektur Perangkat lunak adalah satu set konsep dan keputusan disain tentang struktur dan tekstur perangkat lunak yang harus dibuat sebelum rancang-bangun untuk memungkinkan kepuasan efektif secara arsitektur kebutuhan berkwalitas dan fungsional yang tegas/eksplisit yang penting dan kebutuhan yang tersembunyi/terkandung pada keluarga produk (product family), masalah (the problem), dan daerah solusi (solution domain)

11 Peran Arsitek Perangkat lunak (The Role of a Software Architect)
Menciptakan/membuat arsitektur perangkat lunak adalah suatu usaha sulit Arsitek perangkat lunak mempunyai pekerjaan yang paling sulit dalam merancang suatu perangkat lunak Ia atau dia harus mempunyai kepercayaan dari semua stakeholders Kepercayaan ini didasarkan pada track record dari proyek yang sukses dikerjakannya dan rasa hormat dari pengembang yang menghormat/peduli padanya sebagai pemimpin teknis

12 Peran Arsitek Perangkat lunak
Arsitek harus mampu berkomunikasi dengan semua komponen dalam suatu organisasi / perusahaan/enterprice Arsitek harus memiliki kemampuan dalam mendisain,kemampuan teknologi, dan mengerti/faham tentang aplikasi rancang-bangun perangkat lunak Arsitek harus mampu melayari melalui/sampai dengan politik organisatoris untuk mendapatkan proyek itu Arsitek Perangkat lunak harus seorang pemimpin, penasihat, dan berani membuat keputusan

13 Mengapa kita butuh Arsitektur PL?
Sama halnya peta, tujuan dari arsitektur PL adalah untuk mengabarkan/menginformasikan pemahaman perancangan sistem kepada pembaca tujuan dari arsitektur perangkat lunak adalah untuk mengkomunikasikan suatu gagasan. membawa pembaca ke dalam perangkat lunak dan menjelaskan konsep yang penting. membantu mereka memahami aspek yang penting dari sistem dan memberi mereka nilai rasa suatu sistem tanpa benar-benar melihat kedalamnya.

14 Layer Presentation UI Component: Elemen visual untuk mendisplay informasi ke user dan menerima input. UI Process Component: Menyediakan code yg berisi behavior & struktur aplikasi yg penempatannya terpisah dari UI. Beberapa hal yg patut dipertimbangkan dalam mendesain layer ini: Communication Caching Composition Exception Management Navigation User Experience User Interface Validation

15 Layer Bisnis   Terdiri dari: 1. Application Facade : (Optional) Menyediakan interface ke komponen business logic, diantaranya dengan menggabungkan beberapa operasi bisnis ke sebuah operation. Ini mengurangi dependency krn  external caller tidak perlu mengetahui detail komponen bisnis dan teknik interaksinya. 2. Business Logic Component : Fokus pada retrieving, processing, transformation & management data.     Termasuk dalam kategori ini adalah: Business Workflow Component Business Entity Component Step untuk membuat business Layer adalah: Membuat high level design nya Design kompoenen bisnisnya Design komponen entiti bisnis Design workflow nya

16 Desain Data Menerjemahkan ERD di tahap analisa kebutuhan menjadi model data/ informasi dalam sudut pandang pengguna atau customer. Tambahan: Dalam Power Designer dikenal sebagai Physical Data Modelling (PDM).

17 Gaya Arsitektur Data centered Data-centered architecture
Suatu data store menjadi pusat di antara komponen lain yang mengaksesnya dalam rangka untuk update, tambah habis atau ubah data. Data store tersebut adalah repository pusat. Tiap komponen yang mengakses data berdiri sendiri sehingga memungkinkan adanya tambahan komponen tanpa mengganggu komponen lain. Contoh arsitektur ini seperti pada Gambar 9.1

18 Gaya Arsitektur Data-flow Architecture
Dimanfaatkan untuk menggambarkan input data yang diubah melalui serangkaian penghitungan dan manipulasi untuk menjadi output. Seperti pada Gambar 9.2 pipa dan filter menggambarkan aliran data dan komponen yang mengubah aliran data sehingga input menjadi output.

19 Gaya Arsitektur Call and return : menggambarkan hubungan antara program utama dan sub program. Object oriented : membungkus data dan operasi menjadi satu. Berlapis/ layered.

20 Desain Arsitektur Perangkat Lunak

21 Peran Arsitek Perangkat lunak
Arsitek harus mampu berkomunikasi dengan semua komponen dalam suatu organisasi / perusahaan/enterprice Arsitek harus memiliki kemampuan dalam mendisain,kemampuan teknologi, dan mengerti/faham tentang aplikasi rancang-bangun perangkat lunak Arsitek harus mampu melayari melalui/sampai dengan politik organisatoris untuk mendapatkan proyek itu Arsitek Perangkat lunak harus seorang pemimpin, penasihat, dan berani membuat keputusan

22 Mengapa kita butuh Arsitektur PL?
Sama halnya peta, tujuan dari arsitektur PL adalah untuk mengabarkan/menginformasikan pemahaman perancangan sistem kepada pembaca tujuan dari arsitektur perangkat lunak adalah untuk mengkomunikasikan suatu gagasan. membawa pembaca ke dalam perangkat lunak dan menjelaskan konsep yang penting. membantu mereka memahami aspek yang penting dari sistem dan memberi mereka nilai rasa suatu sistem tanpa benar-benar melihat kedalamnya.

23 Overview of Layered Application Umumnya penggunaan layering dalam suatu aplikasi meliputi 3 layer utama: Presentation, Business & Data Layer. Sedangkan untuk Services Layer ada diantara Business & Presentation Layer. Langkah -2 mendisain untuk sistem berbasis layer ini adalah: Memilih strategi layer yg tepat / yg diperlukan Memutuskan cara mendistribusikan layer dan komponen Menentukan apakah akan memecah layer Merumuskan aturan interaksi masing-masing layer Mengidentifikasikan Crosscutting Concern (Fungsional umum) spt: logging, caching, validation, authentication, & exception management Mendefinisikan interface masing-2 layer Memilih strategy deployment Memilih protokol komunikasi

24 Apa Software Architecture itu?
Arsitektur Perangkat lunak suatu program atau sistem komputasi adalah struktur atau struktur sistem, yang meliputi komponen perangkat lunak, Properti dari komponen juga terlihat nyata, serta hubungan diantarnya (komponen PL). Arsitektur perangkat lunak adalah struktur sistem dari suatu program atau sistem komputer yang terdiri dari komponen-komponen perangkat lunak, ciri yang tampak secara eksternal dari komponen-komponen tersebut, serta hubungan antar komponen tersebut. Istilah ini juga merujuk pada dokumentasi arsitektur perangkat lunak suatu sistem.

25 Desain Arsitektur Arsitektur perangkat lunak adalah struktur sistem yang menggambarkan komponen perangkat lunak, properties-nya dan relasi diantaranya. Arsitektur perangkat lunak terdiri dari desain data dan desain arsitektur.

26 Arsitektur Perangkat lunak
Ada tiga keuntungan perancangan dan dokumentasi arsitektur perangkat lunak dengan ekspliit. Yaitu : Komunikasi dengan stakeholder yang sangat diperlukan untuk melihat kebutuhan sistem pasar. Analisa Sistem yang sangat diperlukan untuk memenuhi persyaratan kritis seperti kinerja, kehandalan dll Pemakaian ulang berskala besar.

27 Arsitektur Perangkat lunak
kegiatan-kegiatan yang dilakukan untuk proses perancangan arsitektural adalah Penstrukturan sistem. Sistem distruktur menjadi sejumlah subsistem utama dimana suatu subsistem merupakan unit perangkat lunak yang indepnden. Komunikasi antar subsistem juga dimodelkan. Pemodelan control. Menetapkan hubungan control antar bagian-bagian sistem. Dekomposisi modular. Setiap subsistem diuraikan menjadi modul-modul selain itu harus ditentukan tip emodul dan interkoneksinya.

28 Arsitektur Perangkat lunak
Output proses perancangan arsitektur adalah dokumen desain arsitektur. Dokumen ini terdiri dari sejumlah representasi grafis model sistem.

29 Arsitektur Perangkat lunak
Model arsitektur yang dapat dikembangkan adalah : Model struktur taktis, yang menunjukkan subsistem-subsistem yang dikembangkan sebagai unut yang terpisah. Model proses dinamis, yang menunjukkan bagaimana sistem diorganisasi menjadi proses-proses pada saat run-time. Organisasi ini bisa berbeda dari mode statis. Model interface, yang mendefinisikan layanan yang disediakan oleh setiap subsistem melalui interface umum. Model hubungan, yang menunjukkan hubungan aluran data diantara subsistemsubsistem.

30 Arsitektur Perangkat lunak
Aritektur sistem mempengaruhi kinerja, bobot, kemampuan distribusi dan kemampuan dipeliharanya suatu sistem. Gaya dan arsitektur tertentu yang dipilih untuk aplikasi tergantung pada persyaratan sistem non fungsional yaitu: Kinerja Kinerja ini merupakan persyaratan kritis yang berarti arsitektur harus dirancang untuk melokalisasi operasi-operasi kritis dalam subsistem. Keamanan Kemanan harus dibuat untuk melindungi asset-aset yang penting dan validasi keamanan juga harus dibuat. Keselamatan Keselamatam ini berhubungan dengan pengurangan biaya dan masalah validasi keamanan dan disediaknnya sistem proteksi yang berhubungan Kemampuan dipelihara

31 Model Repositori Model Client Server Sistem Event-Driven Model interrupt-driven Dekomposisi Modular.

32 Model Repositori Subsistem yang membentuk sistem harus saling bertukar informasi sehingga dapat bekerja lebih efktif. Ada dua cara untuk melakukannya yaitu: Semua data bersama disimpan pada database pusat sehingga dapat diakses oleh semua subsistem. Model ini disebut model repository. Setiap subsistem memelihara database sendiri. Data dipertukarkan dengan subsistem lain dengan mengirimkan message . Keuntungan model repository yang dipakai bersama adalah : Repositori yang dipakai bersama merupakan cara yang lebih efesien sebab dengan cara ini tidak perlu ada transmisi data secara eksplisit antar sitem. Subsistem harus menyetujuai model data repository. Karena akan sulit jika mengintegrasikan subsistem baru jika model datanya tidak sesuai dengan sistem yang ada. Subsistem yang menghasilkan data tidak perlu mempermaslahkan bagaimana data dipakai oleh sub sistem lian. Evolusi mungkin sulit karena informasi dengan volume besar dibangkitkan dari model data yang disetujui. Tersentralisasinya kegiatan seperti backup, keamanan, control akses, dan pemulihan error. Subsistem yang berbeda bisa memiliki persyartan yang berbeda untuk keamanan, recovery, dan backup. Model repository memaksakan kebjakan yang sama untuk semua subsistem. Tidak mudah untuk mendistribusikan repository ke sejumlah mesin, karena mungkin ada redudansi data dan ketidakkonsistenan.

33 Model Client Server Model arsitektur client-server merupakan model sistem terdistribusi yang menunjukkan bagaimana data dan pemrosesan didistribusikan pada sejumlah prosessor. Komponen utama model ini adalah: Satu set server stand alone yang memberikan layanan ke subsistem yang lain. Satu atau lebih set klient yang meminta layanan yang diberikan oleh server. Klien-klien ini biasanya adalah subsistem. Teradapat beberapa instance program klien yang dieksekusi secara bersama Klien mungkin harus tahu nama server-server yang tersedia dan layanan yang diberikan server. Tapi server tidak perlu tahu identitas pelanggan msupun berapa banyak pelanggan yang ada. Pelanggan mengakses layanan yang disesiakan server melalui panggilan prosedur jarak jauh ( remote procedure call).

34 Model Client Server Keuntungan dari model C/S adalahmodel ini merupakan arsitektur sistem yang terdistribusi. Tidak sukar untuk menambahkan server baru dan mengintegrasikan dengan sistem atau mengaupgrade server tanpa mempengaruhi bagian lain dari sistem.

35 Dekomposisi Modular Setelah arsitektur selesai dibuat dilanjutkan dengan proses perancangan arsitektural yaitu menguraikan (dekomposisi) subsistem menjadi modul-modul. Ada dua model yang dapat digunakan untuk dekomposisi modul yaitu: Model Berorientasi Objek, dimana sistem diuraikan menjadi serangkaian objek yang berkomunikasi. Model Aliran Data, sistem diuraikan menjadi modul-modul fungsional yang menerima input dan mentransformasikan menjadi data output. Ini disebut juga pendekatan pipeline.

36 Model Objek Model berorientasi objek menstruktur sistem menjadi serangkaian objek yang terhubung dengan interface. Objek memanggil layanan yang diberikan oleh objek lain. Gambar berikut menunjukkan contoh model objek suatu pemrosesan faktur. Sistem dapat mengeluarkan faktur untuk pelanggan, menerima pembayaran, mengeluarka resi. Tanda panah terputus putus menunjukkan objek memakai atribut atau layanan yang disediakan oleh objek lain. Pada contoh ini ada kelas Invoice yang memiliki berbagai operasi . Kelas ini menggunakan kelas lain untuk merepresentasikan pelangga, pembayaran dan resi.

37 Model Objek Keuntungan pendekatan berorientasi objek diantaranya:
Karena objek-objek terkopel (coupled) secara longgar, maka implementasi objek dapat dimodifikasi tanpa mempengaruhi objek lainnya. Objek merupakan gambaran dari dunia nyata sehingga sistem lebih mudah dimengerti. Objek dapat digunakan ulang (reusable). Kelemahan pendekatan berorientasi objek diantaranya: Dalam memakai layanan, objek harus mengacu nama dan interface ke objek lain secara eksplisit. Jika ada perubahan maka akan mengakibatkan dampak bagi user objek yang lain. Kadang-kadangentitas yang kompleks susah direpresentasikan sebagai objek.

38 Model Aliran Data Pada model aliran data (Data Flow Diagram) transformasi memproses input menjadi output. Contoh untuk model ini dapat dilihat pada gambar berikut dimana sebuah organisasi telah mengeluarkan faktur kepada pelanggan. Sekali seminggu pembayaran yang telah dilakukan dipasangkan dengan fakturnya. Untuk fkatur yang telah dibayara diberikan resi. Dan yang belum dibayar diberikan perngatan .

39 Model Aliran Data Keuntungan :
Mudah dimengerti karena sistem dilihat dari sudut input dan output sistem. Mendukung pemakaian ulang Urutan proses sistem lebih mudah dipahami Kelemahan: Butuh format secara umum Lebih sulit menggabungkan dengan format GUI

40 Sistem Event-Driven Model control Event-Driven dikendalikan oleh event yang dibangkitkan secara eksternal. Event tidak hanya berarti sinyal biner. Event bisa merupakan sinyal yang dapat mengambil nilai berapapun Ada dua model Event-Driven yaitu: Model Broadcast Model interrupt-driven

41 Sistem Event-Driven Model Broadcast
Pada model ini suatu event melakukan penyiaran (broadcast) event ke semua subsistem. Setiap subsistem akan meneriam event tersebut. Hal tersebut dapat dilihat pada gambar berikut.

42 Sistem Event-Driven Model interrupt-driven
Model ini digunakan pada sistem real time dimana interrupt eksternal dideteksi oleh sebuah interrupt handler. Interup-interupt ini akan diteruskan ke komponen lain untuk diolah. Gambar berikut dari model interrupt drivent ini dapat dilihat pada gambar

43 Sistem Event-Driven Pada gambar tersebut ada sejumlah tipe interrupt yang diketahui,yang didefinisikan handler untuk setiap tipenya. Setiap tipe interrupt dihubungkan dengan lokasi memory di mana alamat handler disimpan. Ketika interrupt dengan tipe tertentu diterima, suatu saklar perangkat keras mengakibatkan control ditransfer langsung ke handlernya. Handler interrupt ini kemudian dapat memulai atau menghentikan proses lain sebagai tanggapan terhadap event yang disinyalkan oleh interrupt tersebut. Keuntungan dari model ini adalah dimungkinkannya tanggapan yang sangat cepat terhadap event yang akan diimplementasikan. Sedangkan kerugiannya adalah pemrogramannya menjdi kompleks dan validasinya menjadi sulit.

44 Software Architecture document

45 Introduction Pengenalan Dokumen Arsitektur Software secara keseluruhan. Mencakup tujuan, ruang lingkup, definisi, akronim, singkatan, referensi, dan ikhtisar Dokumen Arsitektur Software. Purpose Dokumen ini memberikan gambaran komprehensif dari arsitektur sistem, menggunakan sejumlah pandangan arsitektur yang berbeda untuk menggambarkan aspek yang berbeda dari sistem. Hal ini dimaksudkan untuk menangkap dan menyampaikan keputusan arsitektur yang signifikan yang telah dibuat pada sistem. Bagian ini mendefinisikan peran atau tujuan dari Dokumen Arsitektur Software, dalam dokumentasi proyek secara keseluruhan, dan secara singkat menggambarkan struktur dokumen.

46 Definitions, Acronyms and Abbreviations
Scope Sebuah deskripsi singkat dari Dokumen Arsitektur Software yang berlaku. Definitions, Acronyms and Abbreviations Sub bagian menyediakan definisi semua istilah, akronim, dan singkatan yang dibutuhkan untuk benar menafsirkan Dokumen Arsitektur Software.

47 Perencanaan Analisis Perancangan Implementasi