Rpl 9 Creating An Architectural Design

  Software Architecture 3. Data Design 4. Architectural Styles and Patterns 5. Architectural Design 6. Assessing Alternative Architecture Designs 7. Mapping Data Flow into a Software Architecture 8. Summary

   What is it ?

  ◦ Desain arsitektur merupakan

   Untuk mewakili struktur data & komponen Program  Mempertimbangkan

 Struktur dan sifat dari komponen sistem



  Hubungan timbal balik antara komponen sistem 

  Siapa yang melakukannya? ◦

  Software engineer ◦

  Specialists  Ketika sistem yang besar dan kompleks

   Mengapa penting ?

  ◦ Misalnya, ketika membangun rumah

  

 Ada perlu memiliki blueprint untuk membangun

 Ini memberi Anda gambaran besar

   Apa langkah-langkahnya ?

  ◦ 1) Desain Data

  ◦ 2) Representasi struktur arsitektur sistem

   Apakah produk kerja ?

  ◦ Arsitektur Data

  ◦ Struktur Program

  ◦ Properti Komponen Dan Hubungannya

   Apa arsitektur? Ketika kita membahas arsitektur bangunan,

  ◦  Cara di mana berbagai komponen bangunan yang terintegrasi untuk membentuk suatu kesatuan yang utuh

   Untuk memenuhi kebutuhan Ketika kita membahas perangkat lunak,

  ◦  Struktur komponen software  Hubungan antara komponen-komponen

   Mengapa Arsitektur Penting? Untuk mengaktifkan untuk komunikasi antara para stakeholder

  ◦ Untuk menyoroti keputusan desain yang akan memiliki dampak pada

  ◦ sukses rekayasa perangkat lunak Untuk membentuk suatu model intelektual banding relatif kecil dari

  ◦ bagaimana sistem terstruktur dan bagaimana komponen bekerja sama

   Apa desain data ? Untuk menerjemahkan objek data yang didefinisikan sebagai bagian dari

  ◦

model analisis ke dalam struktur data pada komponen perangkat lunak

   Desain Data di Tingkat Arsitektur Salah satu desain contoh di tingkat arsitektur, data warehouse

  ◦ 

  Desain Data di Tingkat Komponen Wasserman telah mengusulkan seperangkat prinsip ◦

  diterapkan pada data  Representasi dari aliran data dan konten juga harus dikembangkan

dan Ulasan organisasi data alternatif harus dipertimbangkan

  2) Semua struktur data dan operasi harus diidentifikasi Struktur data yang efisien harus mempertimbangkan operasi

  

3) Sebuah mekanisme untuk mendefinisikan isi dari setiap objek data

harus ditetapkan dan digunakan

  

4) Keputusan desain tingkat rendah data harus ditunda sampai akhir

dalam proses desain

   Karena skema top-down Untuk Tentukan secara rinci selama desain komponen-tingkat

  

5) Representasi struktur data harus hanya diketahui modul yang

langsung menggunakan

  

6) Sebuah perpustakaan data yang berguna dan operasi harus

dikembangkan

  

7) Desain sebuah perangkat lunak dan bahasa pemrograman harus

mendukung spesifikasi

   What is architecture style ? Transformasi pada desain tingkat sistem keseluruhan

  ◦ Tujuannya adalah untuk membangun struktur untuk semua

  ◦ komponen dari sistem

   What is architecture pattern ? Transformasi pada desain tingkat arsitektur

  ◦ Berbeda dari gaya dalam sejumlah cara yang mendasar

  ◦  Ruang lingkup pola kurang luas  Berfokus pada satu aspek dari arsitektur  Untuk memberlakukan aturan pada arsitektur

  Menggambarkan bagaimana perangkat lunak akan menangani  beberapa aspek fungsionalitas

   Untuk cenderung untuk mengatasi masalah perilaku tertentu

   Sebuah Taksonomi/Klasifikasi Singkat Styles Arsitektur arsitektur data-berpusat

  ◦  Sebuah menyimpan data (misalnya, file atau database) berada di pusat arsitektur ini

  Client software Client

  Client software software

  Data store (repository)

  Client Client software software

  Client

   Data-flow architecture

  A pipe and filter structure ◦

   Filter: Sebuah set komponen  Pipe: Untuk menghubungkan antar komponen Untuk mengirimkan data dari satu komponen ke yang berikutnya

  

  Filter Filter Filter

  Filter Filter Filter Filter Filter

   Call and return architecture Relatif mudah untuk memodifikasi dan skala

  ◦ Dua substyles ada

  ◦  Main program/subprogram architecture  Struktur program klasik

   "Program Utama" memanggil sejumlah komponen program  Remote procedure call architecture  Komponen arsitektur program utama / sub pada jaringan

  Main Program

  Controller Controller Controller subprogram subprogram subprogram Application Application Application Application

  Core Layer

  Core Layer

   Object-oriented architecture

  ◦ Komponen sistem merangkum data dan operasi

  ◦ Komunikasi antara komponen dicapai melalui lewat pesan

  

Layered architecture

  Core Layer

  Utility Layer

  Application Layer

  User Interface Layer

  Components

   Representing the System in Context

  ◦ In chapter 6, the system context diagram

   Mewakili arus informasi ke dalam dan keluar dari sistem, user interface, dan pengolahan dukungan yang relevan user interface processing Conveyor Line Sorting System

  Sorting station operator

  Bar code reader Conveyor line

  Sorting mechanism Mainframe

  Bar code Request Queries Line speed indicator Diagnostic data

  Shunt commands

   Representing the System in Context In this chapter,

  ◦  To use an architectural context diagram (ACD)

 Untuk model cara di mana perangkat lunak berinteraksi dengan

entitas eksternal untuk batas-batasnya

  Superordinate systems Superordinate systems: Untuk menggunakan

• -

  sistem target sebagai bagian dari beberapa tingkat yang lebih tinggi Subordiate systems: Untuk digunakan oleh -

  Used by

  sistem target dan memberikan data atau pengolahan Peer-level: Untuk berinteraksi secara peer-to- - peer

  Target system Use

  Actors: Entitas (orang, perangkat) yang berinter

• -

  Use

  Peers

  aksi dengan sistem target

  Actors Depend on

   Example of ACD, Fungsi keamanan rumah dari produk SafeHome

  Superordinate systems Safehome Internet-based product system

  Control panel Target system : Surveillance

  Security function function Use

  Home Use

  Peers owner Actors

  Uses Sensor Sensors

   Defining Archetypes An archetype is a class or pattern

  ◦  Untuk mewakili abstraksi inti untuk desain arsitektur

  Example of the SafeHome home security function ◦

   Node Input dan output unsur fungsi keamanan rumah (ex, berbagai

   sensor, indikator alarm)

   Detector  Semua peralatan penginderaan yang feed informasi ke dalam sistem target Indicator

    Semua mekanisme untuk menunjukkan bahwa kondisi alarm yang terjadi pengawas

   Controller  Mekanisme yang memungkinkan mempersenjatai atau melucuti dari node

   Defining Archetypes

Example of the SafeHome home security function

  ◦

  Controller Node

  Detector Indicator Communication with

   An Architecture Trade-Off Analysis Method

  ◦ The Software Engineering Institute (SEI) has developed an architecture trade-off analysis method (ATAM)

   Evaluation process for software architecture

  1) Collect scenarios  Satu set penggunaan-kasus dikembangkan untuk menyajikan sistem dari sudut pandang pengguna

  2) Menampilkan Persyarata, kendala, dan deskripsi lingkungan 3) Describe the architectural styles/pattern 4) Evaluasi atribut kualitas dengan mempertimbangkan setiap atribut 

  Penilaian meliputi kehandalan, kinerja, keamanan, pemeliharaan, fleksibilitas, testability, portabilitas, usabilitas, dan interoperabilitas 5) Mengidentifikasi sensitivitas atribut kualitas untuk berbagai atribut arsitektur 

  Membuat perubahan kecil dalam arsitektur  Dan kemudian menentukan seberapa sensitif atribut kualitas

  5)

 Berdasarkan hasil langkah 5 dan 6, beberapa arsitektur dapat

dimodifikasi dan diwakili secara lebih rinci

   Sekarang, kita perlu beberapa transisi dari model analisis untuk berbagai gaya arsitektur

   Dua Jenis Metode Pemetaan

  

 Informasi harus masuk dan software keluar dalam bentuk di "dunia

luar”

   Sebagai contoh, data diketik pada keyboard, nada pada saluran telepon, dan gambar video dalam aplikasi multimedia adalah segala bentuk informasi dunia luar

   Data dieksternalisasi tersebut harus diubah menjadi bentuk internal untuk diproses

   Definisi Kata  Aliran Masuk

 Jalur yang mengubah data eksternal menjadi data internal

 Aliran Keluar

  Jalur bahwa data yang masuk melewati transformasi pusat dan 

   Transaction  Sebuah item data tunggal memicu arus informasi  Item data tunggal disebut transaksi 

  Transaction center  Pusat arus informasi

  T

  Transaction center

  …

  Action paths

  ...

  Transaction

   Two kinds of mapping method

   Satu set langkah-langkah desain yang memungkinkan DFD (data flow diagram) dalam gaya arsitektur tertentu

   Untuk menggambarkan pendekatan ini, contoh fungsi keamanan SafeHome

Untuk memetakan data flow diagram ke dalam arsitektur, langkah-

   langkah desain berikut

   Step 1. Ulasan model sistem yang mendasar  Mewakili produsen eksternal dan konsumen data

  Control Display

  Panel User command information display

  Control and data panel

  Alarm type Alarm SoftHome software

  

 Step 2. eview dan memperbaiki diagram aliran data untuk perangkat

lunak

 Model analisis disempurnakan untuk menghasilkan lebih detail

  Control Configure

  Configuration User command panel system data and data

  Configure Configuration information request

  Interact Configuration

  With data user

  Start stop Configure

  Control Password system

  Panel A/D Display display msg. information

  Display Process Valid ID msg.

  Message password And status

  Alarm Sensor

  Configuration Alarm information data type Configuration information Interact

  With user Configure system

  Configure system Process password

  Dial phone Telephone number tones

  Alarm data Sensor

  Telephone number Sensor ID, type

  Alarm type Sensor information

  Sensor ID, type, location

  Configuration data

   Step 3. Tentukan apakah DFD memiliki transformasi atau karakteristik aliran transaksi Evaluating Level 3 DFD,   No distinct transaction center is implied  So, transform characteristic will be assumed

  Generate Configuration information display

  Read sensors Format

  Acquire display response

  Generate info Alarm signal

  Establish Alarm conditions

  Select

  

 Step 4. mengisolasi transformasi pusat dengan menetapkan batas-

batas aliran masuk dan keluar

   Step 5. Perform “first-level factoring”

 Hasil pemfaktoran ini dalam top-down mendistribusikan kontrol

 Top-level: Melakukan Pengambilan keputusan

 Middle-level: melakukan kontrol dan melakukan dalam jumlah

sedang kerja

   Low-level: melakukan sebagian input, perhitungan, dan hasil outputnya

  

 DFD dipetakan ke panggilan dan kembali (Main / sub Program

arsitektur) arsitektur

  

Step 5. Perform “first-level factoring”

  Monitor Sensors executive

  Sensor Alarm

  Alarm Incoming Information Processing controller

  Outgoing Information Processing controller

  Transform Flow controller Step 6. Melakukan 

  “second-level factoring”

 Pemetaan transformasi individual dari DFD ke dalam modul yang

tepat dalam arsitektur

  1) Dimulai pada transformasi Batas Pusat 2) Pindah keluar sepanjang jalan masuk dan keluar

  arsitektur perangkat lunak

  

Step 6. Perform “second-level factoring”

  Generate display Setup

Format display Generate

  Connection To phone net

  Generate Pulses to line

  Alarm Signal

  Monitor Sensors executive Sensor Input controller

  Alarm output controller Alarm conditions controller

  Incoming path Outgoing path

  Transform center Generate alarm

  Format Setup connection

  Establish Select Acquire

  Response

   Step 7. Perbaiki arsitektur pertama-iterasi menggunakan desain heuristic untuk meningkatkan kualitas perangkat lunak  Untuk menyaring untuk kohesi yang baik, kopling minimal, tanpa kesulitan, dan dipelihara tanpa kesulitan

  Monitor Sensors executive

  Acquire Establish Alarm Response Alarm output info conditions controller

  Establish Establish Establish Alarm Alarm Alarm

  Read conditions conditions conditions sensors Transaction Mapping ◦

   A single data item triggers one of a number of information flows  The single data item is called transaction

 This Mapping will be illustrated by considering the SafeHome user

interaction system  Design steps for transaction mapping

   Step 1. Review the fundamental system model  Level 1 data flow for this mapping

  Control panel Sensors

  Interact With user

  Configure system Configure system

  Process password Display

  Message And status

  Monitor sensors Control

  Panel display Alarm

  Telephone line Configuration information

  User command and data Configure request

  Configuration data Configuration data

  Display information Alarm type

  Sensor status Password

  Start stop A/D msg. Valid ID msg.

  Configuration data Sensor information

   Step 2. Review and refine data flow diagram for the software

 Level 2 data flow diagram for user interaction subsystem

  User Raw

  System parameters Build commands Configuration and data Configuration data

  Read Read file

  System User

  Formatted data Command command

  Configuration Configure type data

  Configuration information Invoke

  Command

• The data object (User

  Start Configuration processing command) flows into the stop data system

  Password Activate/

• A single data item

  A/D message Deactivate

  (Command type) triggers system the data flow to fan

  Display outward from hub Password

  Messages Read

  Display

• So, Transaction oriented

  Configuration Valid And status password information data flow data password

  Four

  

 Step 3. Determine whether the DFD has transform or transaction

flow characteristic  Transaction flow characteristic

 Step 4. Identify the transaction center and the flow characteristic

along each of the action paths  The transaction center lies at the origin of a number of actions paths

   The incoming path and all action path must also be isolated

• Transaction center

  Valid password

  A/D message Configuration data

  Password Start stop

  Four digits Password

  “Try again” message Invalid

  Configuration data Display information

  Formatted Configuration data

  Raw Configuration data

  Configure System parameters and data

  User commands Command type

  Invalid message Configuration information

  With file Produce

  Compare Password

  And status Read password

  Display Messages

  Activate/ Deactivate system

  Build Configuration file

  Invoke Command processing

  Read System data

  Read User command

• Transform characteristic
• Transform characteristic
• Incoming, transform, and outgoing flow are bounded

   Step 5. Map the DFD in a program structure amenable to transaction processing  Mapped into incoming branch and dispatch branch  Incoming branch: Along incoming path  Dispatch branch: Start transaction center

  Transaction a control

  Incoming b branch

  Incoming Reception

  Dispatcher b flow d path

  Dispatch d branch a p c

  1 Transform

  q center q r s

   Step 6. Factor and refine the transaction structure and the structure of each action path

  User Interaction path

  Read User command

  Invoke Command

  Processing System

  Configuration Controller

  Activate/ Deactivate system

  Password Processing

  Controller Read

  System data Build

  Configuration file Read password

  Compare Password

  With file Password

  Output controller

   Step 7. Refine the first-iteration architecture using design heuristics for improved software quality

 To consider module independence, practicality, and maintainability

   Arsitektur perangkat lunak memberikan

  ◦ Sebuah melihat secara keseluruhan atas sistem yang akan dibangun