1. Trang chủ
  2. » Tất cả

08-ch11-arch design-se8

39 2 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 39
Dung lượng 752 KB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Nội dung

Kiến trúc phần mềm• Thiết kế kiến trúc là quy trình thiết kế nhằm nhận diện – Các hệ thống con cấu thành nên một hệ thống, và – Framework cho việc điều khiển và liên lạc giữa các hệ thốn

Trang 1

Công nghệ phần mềm

Thiết kế kiến trúc

Trang 2

• Giới thiệu ba kiểu kiến trúc dành cho tổ chức,

phân rã, và điều khiển (organisation,

decomposition and control)

• Các kiến trúc tham khảo dùng để giao tiếp và so sánh kiến trúc

Trang 4

Kiến trúc phần mềm

• Thiết kế kiến trúc là quy trình thiết kế nhằm nhận diện

– Các hệ thống con cấu thành nên một hệ thống, và

– Framework cho việc điều khiển và liên lạc giữa các hệ thống – Kết quả là một mô tả về kiến trúc phần mềm

Trang 5

• Bao gồm việc nhận diện các thành phần hệ

thống chính và giao tiếp giữa chúng

5

Trang 6

Ưu điểm của kiến trúc

• Giao tiếp với stakeholder

– Stakeholder của hệ thống có thể dùng kiến trúc làm trọng tâm thảo luận

• Phân tích hệ thống

– Phân tích xem có thể làm cho hệ thống thỏa mãn các yêu cầu phi chức năng hay không.

• Tái sử dụng quy mô lớn

– Có thể tái sử dụng kiến trúc giữa nhiều hệ thống.

Trang 7

Cấu trúc hóa hệ thống

• Là việc phân rã hệ thống thành những hệ thống con tương tác với nhau

• Thiết kế kiến trúc thường được diễn đạt bằng

một block diagram trình bày tổng quan về cấu trúc hệ thống

• Các mô hình cụ thể hơn cho biết các hệ thống con chia sẻ dữ liệu và phân tán như thế nào,

interface giữa các hệ thống con cũng có thể

được phát triển

7

Trang 8

Packing robot control system

Packing

Packing system

Packaging selection system

Packaging selection system

Trang 9

Box and line diagrams

• Rất trừu tượng – chúng không mô tả bản chất của quan hệ giữa các thành phần cũng như các

tính chất nhìn được từ bên ngoài của các hệ

thống con

• Tuy nhiên, hữu ích khi giao tiếp với stakeholder

và cho việc lập kế hoạch dự án

9

Trang 10

Architectural design decisions

• Architectural design is a creative process so the process differs depending on the type of system being developed

• However, a number of common decisions span all design processes

Trang 11

Các quyết định thiết kế kiến trúc

• Có kiến trúc ứng dụng tổng quát nào có thể dùng được?

• Hệ thống sẽ được phân tán như thế nào?

• Các kiểu kiến trúc nào thích hợp?

• Dùng cách tiếp cận nào để cấu trúc hóa hệ thống?

• Hệ thống sẽ được phân rã thành module như thế nào?

• Đánh giá thiết kế kiến trúc như thế nào?

• Kiến trúc nên được viết tài liệu như thế nào?

11

Trang 12

Các mô hình kiến trúc

• Dùng để ghi tài liệu một thiết kế kiến trúc

• Mô hình cấu trúc tĩnh mô tả các thành phần chính của

• Mô hình quan hệ chẳng hạn mô hình data-flow mô tả

quan hệ giữa các hệ thống con

• Mô hình phân tán mô tả các hệ thống con được phân tán tại các máy tính như thế nào

Trang 13

System organisation

• Phản ánh chiến lược cơ bản để cấu trúc một hệ thống

• Ba kiểu tổ chức được dùng rộng rãi:

– A shared data repository style;

– A shared services and servers style;

– An abstract machine or layered style.

13

Trang 14

The repository model

• Các hệ thống con phải trao đổi dữ liệu Có thể thực hiện theo hai các:

– Dữ liệu dùng chung được đặt tại CSDL hoặc repository trung tâm và tất cả các hệ thống con đều có thể truy cập;

– Mỗi hệ thống con giữ CSDL riêng và truyền dữ liệu một cách tường minh cho các hệ thống con khác.

• Khi cần chia sẻ lượng dữ liệu lớn, mô hình chia sẻ kiểu repository được dùng rộng rãi nhất.

Trang 15

CASE toolset architecture

15

Project repository

Design editor

Design editor

Code generator

Code generator

Program editor

Program editor

Design editor

Design editor

Code generator

Code generator

Design

translator

Design

translator

Trang 16

Đặc điểm của mô hình

repository

• Ưu điểm

– Các hiệu quả để dùng chung lượng dữ liệu lớn;

– Các hệ thống con không cần quan tâm dữ liệu được tạo như thế nào

– Công việc quản lý như backup, bảo mật, được tập trung.

– Mô hình dùng chung được công bố dưới dạng repository schema.

• Nhược điểm

– Các hệ thống con phải thống nhất về một mô hình dữ liệu

repository Thỏa hiệp là tất yếu;

– Tiến hóa dữ liệu là khó khăn và chi phí cao;

– Không có phạm vi cho các chính sách quản lý cụ thể;

Trang 17

Client-server model

• Mô hình hệ thống phân tán trong đó dữ liệu và xử

lý dữ liệu được phân bố cho nhiều component

Trang 18

Film and picture library

Internet Client 1 Client 2

Web server

Film and photo info.

Web server

Film and photo info.

Video server

Film clip files

Video server

Film clip files

Picture server

Digitalized photos

Picture server

Digitalized photos

Trang 19

Đặc điểm mô hình client-server

• Ưu điểm

– Dữ liệu được phân tán một cách rõ ràng dễ hiểu;

– Sử dụng hiệu quả các hệ thống nối mạng

– Có thể đòi hỏi phần cứng rẻ hơn;

– Dễ bổ sung server mới hoặc nâng cấp các server cũ.

• Nhược điểm

– Không có mô hình dữ liệu dùng chung nên các hệ thống con phải dùng các tổ chức dữ liệu riêng Việc trao đổi dữ liệu có thể không hiệu quả;

– Quản lý dư thừa đặt tại mỗi server;

– Không có đăng kí trung tâm cho tên và dịch vụ - có thể khó tìm xem hiện có những server và dịch vụ nào.

19

Trang 20

Abstract machine (layered) model

Mô hình phân tầng

• Dùng để mô hình giao diện giữa các hệ thống con.

• Tổ chức hệ thống thành tập các layer (hoặc abstract

machines) mỗi layer cung cấp một tập các dịch vụ.

• Hỗ trợ phát triển tăng dần đối với các hệ thống con tại các layer khác nhau Khi một layer thay đổi, chỉ có layer sát nó bị ảnh hưởng.

• Tuy nhiên việc cấu trúc các hệ thống theo kiểu này

thường không tự nhiên.

Trang 21

Version management system

Trang 22

Các phong các phân rã mô-đun

• Các phong cách phân rã các hệ thống con thành các mô-đun

• Không có phân biệt cứng nhắc giữa tổ chức hệ thống con và phân rã mô-đun

Trang 23

Sub-systems and modules

• Cung cấp dịch vụ cho các thành phần khác

• Thường không được coi là một hệ thống riêng biệt.

23

Trang 24

Phân rã mô-đun

• Một mức cấu trúc khác mà trong đó các hệ thống con được phân rã thành các mô-đun

• Hai mô hình phân rã mô-đun:

– Mô hình đối tượng

• Hệ thống được phân rã thành các đối tượng tương tác với nhau

– Mô hình pipeline hoặc data-flow

• Hệ thống được phân rã thành các mô-đun chức năng – các mô-đun biến đổi input thành output

• Nếu có thể, các quyết định về việc các mô-đun có chạy song song hay không nên được để cho đến khi cài đặt

Trang 25

Mô hình đối tượng

• Cấu trúc hệ thống thành một tập các đối tượng ghép nối lỏng lẻo với nhau (loosely coupled)

thông qua các giao diện được định nghĩa rõ

ràng

• Việc phân rã xác định các lớp đối tượng, các

thuộc tính và thao tác của chúng

• Khi cài đặt, các đối tượng được tạo từ các lớp này và một số hình thức điều khiển được sử

dụng để đồng bộ hóa hoạt động của các đối

tượng

25

Trang 26

Invoice processing system

issue () sendReminder () acceptPayment() sendReceipt ()

invoice#

date amount customer

invoice#

date amount customer#

Trang 27

Object model (dis)advantages

• Ưu điểm

– Có tính kết nối lỏng (loosely coupled) nên cài đặt các đối tượng có thể được sửa đổi mà không ảnh hưởng các đối tượng khác

– Gần gũi với các đối tượng ngoài đời thực

– Các ngôn ngữ hướng đối tượng được sử dụng rộng rãi

• Nhược điểm

– Việc thay đổi giao diện đối tượng có thể gây ra vấn đề – Có thể khó dùng đối tượng để biểu diễn các thực thể phức tạp, trừu tượng

27

Trang 28

Function-oriented pipelining

• Các tiến trình biến đổi input để tạo output

• Có thể gọi là pipe model và filter model

• Không thực sự thích hợp cho các hệ thống

tương tác

Trang 29

Invoice processing system

Issue receipts

Find payments due

Receipts

Issue payment reminder

Reminders

Invoices Payments

Trang 30

Pipeline model (dis)advantages

• Ưu điểm

– Hỗ trợ tái sử dụng các tiến trình biến đổi

– Là tổ chức trực quan cho việc giao tiếp với

stakeholder

– Dễ bổ sung các tiến trình mới

– Tương đối đơn giản để cài đặt thành hệ thống tuần tự hoặc song song

• Nhược điểm

– Đòi hỏi định dạng chung cho việc chuyển dữ liệu

Trang 31

Các kiểu điều khiển

• Dùng cho luồng điều khiển giữa các hệ thống con

• Phân biệt với mô hình phân rã hệ thống

• Điều khiển tập trung

– Một hệ thống con có trách nhiệm chung cho điều khiển

việc khởi động và dừng các hệ thống con khác

• Event-based control – điều khiển dựa sự kiện

– Mỗi hệ thống con cần đáp ứng một số sự kiện bên ngoài

do các hệ thống khác tạo ra hoặc từ môi trường hệ thống

31

Trang 32

Điều khiển tập trung

• Một hệ thống con chỉ huy ( control sub-system) giữ trách nhiệm quản lý việc chạy các hệ thống con khác

• Call-return model

– Mô hình chương trình con top-down, trong đó điều khiển bắt đầu

từ đỉnh cây phân cấp và di chuyển theo hướng đi xuống Áp

dụng cho các hệ thống tuần tự (sequential systems).

• Manager model

– Áp dụng cho các hệ thống song song Một thành phần hệ thống điều khiển việc tắt, bật và đồng bộ hóa các tiến trình hệ thống khác Có thể cài đặt trong các hệ thống tuần tự như dạng câu lệnh case

Trang 33

Call-return model

33

Main program

Main program

Routine 3 Routine 2

Routine 1

Routine 1.1 Routine 2.1 Routine 3.1

Trang 34

Real-time system control

System controller

System controller

user interface

user interface

Actuator processes

Trang 35

Event-driven systems

• Hệ thống bị dẫn dắt bởi các sự kiện tạo ra từ bên ngoài, trong đó thời gian và thời điểm của các sự kiện nằm ngoài tầm kiểm soát của các hệ thống xử lý sự kiện

• Hai mô hình event-driven chính

Trang 36

Broadcast model

• Hiệu quả trong việc tích hợp các hệ thống con nằm tại các máy

khác nhau trong một mạng.

• Các hệ thống con đăng kí quan tâm tới các sự kiện cụ thể Khi một

sự kiện xảy ra, điều khiển được chuyển cho hệ thống con nào có thể xử lý sự kiện đó.

• Chính sách điều khiển không được nhúng trong sự kiện và thành phần xử lý thông điệp (message handler) Các hệ thống con tự

quyết định chúng quan tâm đến những sự kiện nào.

• Tuy nhiên, các hệ thống con không biết một sự kiện cụ thể nào đó

có được xử lý hay không hoặc khi nào sẽ được xử lý.

Trang 37

Selective broadcasting

37 Event and message handler

Sub-system 1 Sub-system 2 Sub-system 3

Trang 38

Interrupt-driven systems

• Dùng trong các hệ thống thời gian thực mà trong

đó việc đáp ứng nhanh chóng một sự kiện có ý nghĩa cốt tử

• Có các loại interrupt được biết trước, mỗi loại có một handler được định nghĩa trước

• Mỗi loại được gắn với một khu vực trong bộ nhớ

và một hardware switch chuyển nó tới handler

• Cho phép phản ứng nhanh nhưng phức tạp khi lập trình và khó thẩm định

Trang 39

Handler 2

Process 2

Process 2

Handler 3

Handler 3

Process 3

Process 3 Interrupt

vector

Ngày đăng: 22/05/2017, 09:19

w