1. Quick Look of this chapter

2. 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 darimodel 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

1) Prinsip analisis sistematis diterapkan untuk fungsi juga harusditerapkan pada data

Representasi dari aliran data dan konten juga harus dikembangkandan 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 dataharus ditetapkan dan digunakan

4) Keputusan desain tingkat rendah data harus ditunda sampai akhirdalam proses desain Karena skema top-down Untuk Tentukan secara rinci selama desain komponen-tingkat

5) Representasi struktur data harus hanya diketahui modul yanglangsung menggunakan

6) Sebuah perpustakaan data yang berguna dan operasi harusdikembangkan

7) Desain sebuah perangkat lunak dan bahasa pemrograman harusmendukung spesifikasi

What is architecture style ?

◦ Transformasi pada desain tingkat sistem keseluruhan

◦ Tujuannya adalah untuk membangun struktur untuk semuakomponen 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 menanganibeberapa 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 pusatarsitektur ini

Data store

(repository)

Client

software

Client

software

Client

software

Client

software

Client

software

Client

software

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

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

subprogram

Controller

subprogram

Controller

subprogram

Application

subprogram

Application

subprogram

Application

subprogram

Application

subprogram

Main Program/subprogram architecture

Core

LayerCore

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

LayerComponents

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

Input

processing

output

processing

maintenance

and

self-test

ConveyorLine

SortingSystem

Sortingstation

operator

Bar codereader

Conveyorline

Sortingmechanism

Mainframe

Sortingstation

operator

Bar code

Request Queries

Line speed indicator

Diagnostic data

Shuntcommands

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

Target system

Superordinate systems

Used by

UsePeersUse

ActorsDepend on

Subordinate systems

- Superordinate systems: Untuk menggunakan sistem target sebagai bagian dari beberapa tingkat yang lebih tinggi

- Subordiate systems: Untuk digunakan oleh sistem target dan memberikan data atau pengolahan

- Peer-level: Untuk berinteraksi secara peer-to-peer

- Actors: Entitas (orang, perangkat) yang berinteraksi dengan sistem target

Example of ACD, Fungsi keamanan rumah dari produk SafeHome

Target system :

Security function

Safehome

product

Home

owner

Control

panelSurveillance

function

SensorsSensor

Internet-based

system

UsePeersUse

Actors

Uses

Subordinate systems

Superordinate systems

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

UML relationship for SafeHome security function archtypes

An Architecture Trade-Off Analysis Method

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

Evaluation process for software architecture

1) Collect scenarios

Satu set penggunaan-kasus dikembangkan untuk menyajikan sistem darisudut 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

6) Critique candidate architectures using the sensitivity analysis (in step5)

Berdasarkan hasil langkah 5 dan 6, beberapa arsitektur dapatdimodifikasi dan diwakili secara lebih rinci

Sekarang, kita perlu beberapa transisi dari model analisis untuk berbagaigaya arsitektur

Dua Jenis Metode Pemetaan

1)Transform Flow

Informasi harus masuk dan software keluar dalam bentuk di "dunia luar”

Sebagai contoh, data diketik pada keyboard, nada pada salurantelepon, dan gambar video dalam aplikasi multimedia adalah segalabentuk informasi dunia luar

Data dieksternalisasi tersebut harus diubah menjadi bentuk internaluntuk diproses

Definisi Kata

Aliran Masuk

Jalur yang mengubah data eksternal menjadi data internal

Aliran Keluar

Jalur bahwa data yang masuk melewati transformasi pusat danbergerak "keluar" dari perangkat lunak

2) Aliran Transaksi

Transaction

Sebuah item data tunggal memicu arus informasi

Item data tunggal disebut transaksi

Transaction center

Pusat arus informasi

TTransaction

center

…

Action

paths

... ... ...

...

...Transaction

Transaction flow

Two kinds of mapping method

1)Transform Mapping

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

SoftHome

software

Control

panel

Sensor

Control

Panel

display

Alarm

Telephone

line

User command

and data

Sensor

status

Display

information

Alarm

type

Telephone

Number tones

Context level DFD for the SafeHome security function

Step 2. eview dan memperbaiki diagram aliran data untuk perangkat

lunak

Model analisis disempurnakan untuk menghasilkan lebih detail

Configuration information

Control

panel

Sensors

Interact

With

user

Configure

system

Configure

system

Process

password

Display

Message

And status

Monitor

sensors

Control

Panel

display

Alarm

Telephone

line

User command

and dataConfigure

request

Configuration

data

Configuration

data

Display

information

Alarm

type

Telephone

Number tones

Sensor

status

Password

Start

stop

A/D

msg.

Valid ID msg.

Configuration

data

Sensor

information

Level 1 DFD for the SafeHome security function

Configuration information

Interact

With

user

Configure

system

Configure

system

Process

password

Dial

phone

Telephone

number tones

Alarm

data

Sensor

status

Telephone

numberSensor ID,

type

Level 2 DFD that refines the monitor sensors transform

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

Configuration information

Read

sensors

Acquire

response

info

Sensor

status

Establish

Alarm

conditions Select

Phone

number Setup

Connection

To phone

net

Generate

Pulse to

line

Format

display

Generate

display

Generate

Alarm

signal

Level 3 DFD for monitor sensors with flow boundary

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

Input

controller

Alarm

Output

controller

Alarm

Conditions

controller

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

3) Mentransformasi dipetakan ke tingkat subordinary dariarsitektur perangkat lunak

Step 6. Perform “second-level factoring”

Generate

display

Setup

Connection

To phone

net

Generate

Pulses to

line

Format

display Generate

Alarm

Signal

Monitor Sensors

executive

Sensor Input

controller Alarm output

controller

Alarm conditions

controller

Incoming

path

Outgoing

path

Transform

center

Generate alarm

signal

Format

displaySetup connection

To phone net

Generate

display

Generate

Pulse to line

Establish

Alarm

codition

Select

Phone

number

Acquire

Response

info

Acquire

Response

info

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

Response

info

Read

sensors

Establish

Alarm

conditions

Alarm

output

controller

Establish

Alarm

conditions

Establish

Alarm

conditions

Establish

Alarm

conditions

Establish

Alarm

conditionsRefined program structure for monitor 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 dataConfigure

request

Configuration

data

Configuration

data

Display

information

Alarm

type

Telephone

Number tones

Sensor

status

Password

Start

stop

A/D

msg.

Valid ID msg.

Configuration

data

Sensor

information

Level 1 DFD for the SafeHome security function

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

Level 2 data flow diagram for user interaction subsystem

Configuration information

Read

User

command

Read

System

data

Invoke

Command

processing

Build

Configuration

file

Activate/

Deactivate

systemDisplay

Messages

And statusRead

password

Compare

Password

With file

Produce

Invalid

message

User

commands

Command

type Configure

System parameters

and data

Raw

Configuration

data

Formatted

Configuration

data

Configuration

data

Display

information

“Try again”

message

Invalid

password

Four

digits

Password

Password

Start

stop

A/D message

Configuration

data

Valid

password

Level 2 DFD for user interaction subsystem

- The data object (User

command) flows into the

system

- A single data item

(Command type) triggers

the data flow to fan

outward from hub

- So, Transaction oriented

data flow

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

Read

User

command

Read

System

data

Invoke

Command

processing

Build

Configuration

file

Activate/

Deactivate

systemDisplay

Messages

And statusRead

password

Compare

Password

With file

Produce

Invalid

message

Configuration information

User

commands

Command

type Configure

System parameters

and data

Raw

Configuration

data

Formatted

Configuration

data

Configuration

data

Display

information

“Try again”

message

Invalid

password

Four

digits

Password

Password

Start

stop

A/D message

Configuration

data

Valid

password

- Transform characteristic

- Incoming, transform, and

outgoing flow are bounded

- Transform characteristic

- Incoming, transform, and

outgoing flow are bounded

- Transaction center

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

a

b

d

p

bd

c1

q r s

a

q

r

s

q

Incoming

flow

Transform

center

Outgoing

flow

Reception

path

Transaction

control

Dispatcher

Incoming

branch

Dispatch

branch

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

Produce

Invalid

message

Display

Message &

status

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