Phương pháp thiết kế phần mềm sử dụng ngôn ngữ đặc tả kiến trúc AADL

Phương pháp thiết kế phần mềm sử dụng ngôn ngữ đặc tả kiến trúc AADL Trình bày tổng quan về kiến trúc phần mềm. Ngôn ngữ đặc tả kiến trúc. Ngôn ngữ đặc tả kiến trúc ACME. Phương pháp thiết kế phần mềm sử dụng ngôn ngữ đặc tả ACME Trình bày tổng quan về kiến trúc phần mềm. Ngôn ngữ đặc tả kiến trúc. Ngôn ngữ đặc tả kiến trúc ACME. Phương pháp thiết kế phần mềm sử dụng ngôn ngữ đặc tả ACME

Người hướng dẫn khoa học : TS HUỳNH QUYếT THắNG

Hà Nội 2006

LỜI CẢM ƠN

Trước tiên, tôi xin bày tỏ lòng biết ơn chân thành tới thầy giáo, TS Huỳnh Quyết Thắng đã tận tình giúp đỡ, hướng dẫn, đóng góp nhiều ý kiến

quý báu trong quá trình thực hiện và hoàn thành luận văn

Tôi xin gửi tới lãnh đạo Công ty Vietsoftware lời cảm ơn về sự giúp đỡ

nhiệt tình trong suốt quá trình thực hiện đề tài

Tôi xin chân thành cảm ơn các cán bộ Trung tâm Đào tạo Sau Đại học, Ban giám hiệu Trường Đại học Bách khoa Hà Nội đã nhiệt tình giúp

đỡ và tạo mọi điều kiện thuận lợi trong thời gian học tập cũng như khi hoàn thành báo cáo luận văn

Tôi xin cảm ơn các bạn bè, đồng nghiệp và gia đình đã động viên và tạo mọi điều kiện giúp đỡ tôi trong quá trình học tập, nghiên cứu và hoàn thành luận văn

Hà Nội, ngày 30 tháng 9 năm 2007

Nguyễn Thanh Hải

LỜI CAM ĐOAN

Tôi xin cam đoan rằng đây là công trình của riêng tôi, những kết quả nghiên cứu trong luận văn này là hoàn toàn trung thực

Bản luận văn này là do tôi thực hiện dưới sự chỉ bảo của các thầy hướng dẫn và sự giúp đỡ của bạn bè, đồng nghiệp Mọi sự giúp đỡ cho thực hiện luận văn đã được cảm ơn, các thông tin trích dẫn trong luận văn đều đuợc ghi rõ địa chỉ và nguồn gốc

TÁC GIẢ LUẬN VĂN

Nguyễn Thanh Hải

MỤC LỤC

LỜI CẢM ƠN 2

LỜI CAM ĐOAN 3

MỤC LỤC 4

MỤC LỤC HÌNH VẼ 7

MỤC LỤC BẢNG BIỂU 8

DANH MỤC CÁC KÝ HIỆU VIẾT TẮT 8

MỞ ĐẦU 9

Chương 1 CƠ SỞ LÝ THUYẾT 11

1.1 TỔNG QUAN VỀ KIẾN TRÚC PHẦN MỀM 11

1.1.1 Tổng quan 11

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

1.1.1.2 Lịch sử phát triển 11

1.1.1.3 Mô tả kiến trúc 12

1.1.1.4 Các vấn đề liên quan kiến trúc phần mềm 14

1.1.1.5 Những vấn đề không thuộc kiến trúc phần mềm 15

1.1.1.6 Một số kiến trúc tiêu biểu 16

1.1.2 Đặc điểm của kiến trúc phần mềm 16

1.1.2.1 Kiến trúc một phần mềm 17

1.1 2.2 Kiến trúc sư phần mềm 21

1.1 2.3 Kiến trúc phần mềm theo ngữ cảnh 22

1.1.3 Các thành phần của kiến trúc phần mềm 23

1.1.4 Hướng tiếp cận đến kiến trúc phần mềm 24

1.2 NGÔN NGỮ ĐẶC TẢ KIẾN TRÚC 25

1.2.1 Tổng quan 25

1 2.1.1 Giới thiệu chung 25

1 2.1.2 Phạm vi 26

1 2.1.3 Mục đích 27

1.2.2 Đặc điểm 28

1.2.3 Các dạng đặc tả AADL 30

1 2.3.1 Văn bản 30

1 2.3.2 Đặc tả đồ hoạ 32

1.2.4 Mô hình và các thành phần 33

1 2.4.1 Các phần tử của AADL 33

1 2.4.2 Các thành phần của AADL 38

1.2.5 Các công cụ hỗ trợ mô tả kiến trúc 44

1 2.5.1 Các đặc điểm hỗ trợ 44

1 2.5.2 Các công cụ hỗ trợ phát triển 45

1.2.6 Hướng phát triển 46

1.3 KẾT CHƯƠNG 46

Chương 2 NGÔN NGỮ ĐẶC TẢ KIẾN TRÚC ACME 48

2.1 TỔNG QUAN NGÔN NGỮ ACME 48

2.1.1 Giới thiệu 48

2.1.2 Các khái niệm chính 49

2 1.2.1 Thành phần và cổng 49

2 1.2.2 Kết nối và vai trò 51

2 1.2.3 Hệ thống 52

2 1.2.4 Mô tả đại diện 53

2 1.2.5 Thuộc tính 54

2 1.2.6 Trao đổi kiến trúc 55

2.1.3 Bộ công cụ ACME Studio 56

2.2 SO SÁNH VỚI CÁC NGÔN NGỮ ĐẶC TẢ 57

2.2.1 So sánh với ngôn ngữ đặc tả 57

2.2.2 So sánh với UML 58

2.2.3 Sự khác biệt giữa các ngôn ngữ AADL 59

2 2.3.1 Sự hỗ trợ đối với mô hình thành phần 60

2 2.3.2 Hỗ trợ cho mô hình kết nối 61

2 2.3.3 Hỗ trợ mô hình cấu hình 63

2.2.4 Công cụ hỗ trợ AADL 67

2.3 KẾT CHƯƠNG 70

Chương 3 PHƯƠNG PHÁP THIẾT KẾ PHẦN MỀM SỬ DỤNG NGÔN NGỮ ĐẶC TẢ ACME 71

3.1 QUY TRÌNH THIẾT KẾ 71

3.1.1 Yêu cầu kiến trú c 72

3.1.2 Đặc tả kiến trúc 73

3.1.3 Xác định tính hợp lệ của kiến trúc 79

3.1.4 Mô tả một kiểu kiến trúc trong ACME 79

3 1.4.1 Loại phần tử 81

3 1.4.2 Loại thuộc tính 82

3.2 XÂY DỰNG CHỨC NĂNG WEB BASED PAYROLL BẰNG ACME STUDIO 83

3.2.1 Yêu cầu của hệ thống 83

3.2.2 Biểu diễn 86

3 2.2.1 Bước đầu tiên: Định nghĩa từ vựng 87

3 2.2.2 Bước thứ hai: định nghĩa nguyên tắc thiết kế 91

3 2.2.3 Bước thứ ba: Định nghĩa kiểu kiến trúc 97

3.2.3 Kết quả 99

3.3 KẾT CHƯƠNG 99

KẾT LUẬN 101

TÀI LIỆU THAM KHẢO 103

PHỤ LỤC 104

A CÚ PHÁP CỦA ACME ………104

1 Cú pháp thiết kế 104

2 Cú pháp phần tử và thuộc tính 104

2.1 Cú pháp phần tử - Element Syntax 104

2.2 Cú pháp hệ thống: Khai báo hệ thống 105

2.3 Cú pháp thành phần : Khai báo thành phần 106

2.4 Cú pháp kết nối – Khai báo kết nối 107

2.5 Cú pháp vai trò – Khai báo vai trò 107

3 Thuộc tính và cú pháp giá trị thuộc tính 107

3.1 Cú pháp mô tả 108

3.2 Dịch từ một mô tả ACME 108

B SO SÁNH CÁC NGÔN NGỮ ĐẶC TẢ AADL 110

C MỘT SỐ MÀN HÌNH MÔ PHỎNG 124

MỤC LỤC HÌNH VẼ

Hình 1.1 Các câu hỏi lớn của kiến trúc phần mềm 18

Hình 1 2 Quá trình mô hình kiến trúc 19

Hình 1.3 Xác định tính hợp lệ của kiến trúc 20

Hình 1.4 Các tiếp cận tuần tự của kiến trúc 22

Hình 1.5 Các hoạt động trong một quá trình phát triển 24

Hình 1.6 Khung nhìn thành phần và kết nối 25

Hình 1.7 Các biểu diễn của AADL (David và cs, 1995) 31

Hình 1.8 Các chú thích đồ hoạ AADL (Peter và cs, 2006 34

Hình 1.9 Tổng quan các phần tử AADL (Peter và cs, 2006 33

Hình 1.10 Mệnh đề con của một khai báo loại thành phần 36

Hình 1.11 Mệnh đề con của khai báo thực hiện 37

Hình 2.1 Mô hình thành phần và cổng 50

Hình 2.2 Mô hình Port 51

Hình 2.3 Giao diện của chương trình ACME Studio 56

Hình 2.4 Quan hệ giữa AADL và UML [9] 59

Hình 2.5 Ánh xạ tinh chỉnh được khai báo trong SADL 65

Hình 2.6 Thêm phần tử vào bên trong (a), theo đường biên (b) 66

Hình 2.7 Khai báo họ kiến trúc 66

Hình 3.1 Quy trình thiết kế trong ACME 71

Hình 3.2 Xác định yêu cầu 72

Hình 3.3 Siêu kiến trúc 74

Hình 3.4 Ý tưởng kiến trúc 74

Hình 3.5 Kiến trúc Logic 75

Hình 3.6 Các bước xây dựng kiến trúc mô hình 75

Hình 3.7 Mô hình luồng dữ liệu hệ thống Payroll 85

Hình 3.8 Biểu đồ use case của hệ thống Payroll 86

Hình 3.9 Các loại thành phần được mô hình hoá trong ACME Family 88

Hình 3.10 Kết nối được mô hình trong ACME Family 89

Hình 3.11 Port và Role được mô hình trong ACME 90

Hình 3.12 Mô hình hoá trong ACME 99

MỤC LỤC BẢNG BIỂU

Bảng 1 1 Nguyên tắc khai báo AADL 31 Bảng 3.1 Bảng ánh xạ từ yêu cầu kiến trúc văn bản sang ACME 77

DANH MỤC CÁC KÝ HIỆU VIẾT TẮT

ADL Architecture Description Language Ngôn ngữ đặc tả kiến

trúc AADL Architecture Analysis and Design

Language

Ngôn ngữ đặc tả kiến trúc

CMU Carnergie Mellon University Trường đại học

Carnergie Mellon DFD Data Flow Diagram Lược đồ luồng dữ liệu UML Unified Modeling Language Ngôn ngữ mô hình

XML Extensible Markup Language Ngôn ngữ siêu văn bản

đánh dấu

MỞ ĐẦU

1 Tính cấp thiết của đề tài

Kết quả trong các hệ thống tích hợp cho thấy một số nhược điểm như: tích hợp rủi ro cao, chi phí nâng cấp cao, vòng đời bảo trì sản phẩm ngắn Bên cạnh đó việc đảm bảo tính tin cậy cùng các thuộc tính chất lượng hệ thống như hiệu năng, độ an toàn, các vấn đề then chốt về thời gian, khả năng lên lịch, bảo mật, tính chịu lỗi của hệ thống lại không chắc chắn kiểm soát được

Càng ngày vai trò của kiến trúc phần mềm ngày càng trở nên quan trọng nhất là trong bối cảnh hiện nay phần mềm thực sự là hỗn hợp của nhiều triển vọng Các triển vọng khác nhau có thể kết hợp cùng nhau trong các quan điểm kiến trúc phần mềm Có thể nói kiến trúc phần mềm đưa ra những định hướng để đạt được các nhiệm vụ liên quan đến mỗi vùng nghiệp vụ cụ thể với các tác nhân là các thành viên trong hệ thống phần mềm, người phát triển hệ thống, nhóm hỗ trợ thao tác, các chuyên gia bảo trì, người triển khai, nhân viên kiểm tra thử và người sử dụng cuối cùng

Hướng nghiên cứu kiến trúc phần mềm dựa trên mô hình và đưa ra cách thức tập trung phân tích hệ thống với những khả năng hứa hẹn để phát hiện các vấn đề về tính sẵn sàng, an toàn bảo mật, sự tin cậy, hiệu năng … có

ý nghĩa quan trọng

Trong những năm gần đây, ngôn ngữ đặc tả kiến trúc (Architecture Analysis and Design Language - AADL hay còn gọi là Architecture Description Language - ADL) tập hợp các công cụ đi kèm trở thành đề tài nghiên cứu nóng bỏng trong kiến trúc phần mềm bởi nó cung cấp:

thống thời gian thực và các hệ thống nhúng, các chú thích mô hình theo chuẩn công nghiệp cho các ứng dụng và nền tảng thực hiện

 Cách thức trao đổi dựa trên cú pháp XML của mô hình AADL có thể tích hợp và phân nhánh

đặc tả trong phạm vi khung chương trình UML

Trên cơ sở những phân tích trên chúng tôi tiến hành thực hiện đề tài:

Phương pháp thiết kế phần mềm sử dụng ngôn ngữ đặc tả kiến trúc AADL

2 Mục tiêu nghiên cứu

thuộc tính, các vấn đề liên quan đến kiến trúc và ngôn ngữ đặc tả kiến trúc

đặc tả AADL, đề xuất quy trình thiết kế cho ngôn ngữ đặc tả kiến trúc ACME

trong thực tế

Kiến trúc phần mềm của một chương trình hay một hệ thống tính toán

là cấu trúc của các cấu trúc trong hệ thống, bao gồm các phần tử phần mềm, các thuộc tính xác định phần tử và mối quan hệ giữa chúng Thuật ngữ “kiến trúc phần mềm” cũng đề cập đến các tài liệu kiến trúc phần mềm của một hệ thống, thuận tiện cho việc giao tiếp giữa các thành viên dự án, dễ dàng đưa ra quyết định ở mức cao của thiết kế, cho phép tái sử dụng các thành phần và mẫu thiết kế các dự án

Kiến trúc phần mềm của hệ thống là sự kết hợp giữa khoa học và thực

tế Khía cạnh thực tế của kiến trúc phần mềm được thừa hưởng từ các phần mềm thương mại, hỗ trợ các khía cạnh của nghiệp vụ, thông qua kịch bản và yêu cầu phi chức năng, các thuộc tính chất lượng Nó giúp tạo ra một hệ thống

có khả năng chịu lỗi, tương thích với các phiên bản cũ, có khả năng mở rộng,

có tính tin cậy cao, có khả năng duy trì, tính sẵn sàng, tính an toàn, khả năng

sử dụng như các tiện ích được biến đổi đối với mỗi phiên bản khi triển khai

1.1.1.2 Lịch sử phát triển

Nguồn gốc của kiến trúc phần mềm như một ý tưởng được giới thiệu đầu tiên trong nghiên cứu của Edsger Dijkstra năm 1968 và David Parnas đầu những năm 1970 Các nghiên cứu về lĩnh vực này ngày càng nhiều và trở nên phổ biến từ đầu những năm 1990 cùng với các nghiên cứu tập trung vào các mẫu kiến trúc, ngôn ngữ đặc tả kiến trúc, tài liệu kiến trúc và các phương pháp chính thức

Lĩnh vực khoa học máy tính trải qua sự kết hợp các vấn đề cùng với sự phức tạp của cấu trúc Thuật ngữ kiến trúc phần mềm liên quan đến sự mới

mẻ của ngành công nghiệp này, nhưng nguyên tắc cơ bản của nó đã được áp dụng bởi các công nghệ tiên phong từ giữa những năm 80 Trong những năm

1990, đã có một số nỗ lực tập trung để xác định và hệ thống hoá các khía cạnh

cơ bản của môn học Mary Shaw và David Garlan của Viện nghiên cứu

Carnegie Mellon đã viết cuốn sách “Software Architecture: Perspectives on

an Emerging Discipline” vào năm 1996, mang đến các khái niệm tiến bộ trong kiến trúc phần mềm như thành phần (component), kết nối (connector), kiểu (style) và nhiều thứ nữa Các tập khởi đầu của các mẫu thiết kế, kiểu, các bài tập thực hành, các ngôn ngữ mô tả và lôgic hình thức cũng được phát triển

trong thời gian này

Một trong những chuẩn đầu tiên trong kiến trúc phần mềm là chuẩn ANSI/IEEE 1471-2000 được ISO chấp nhận như ISO/IEC DIS 25961 (Mary

Ngôn ngữ đặc tả kiến trúc AADL được sử dụng để mô tả một kiến trúc phần mềm Các quy tắc kiến trúc phần mềm được tập trung vào các ý tưởng giảm thiểu sự phức tạp qua các khái niệm và phân chia các mối quan tâm Cho đến nay vẫn chưa có sự thoả thuận thống nhất trong việc định nghĩa chính xác thuật ngữ kiến trúc phần mềm

như Wrigh (Carnegie Mellon), ACME (Carnegie Mellon), xADL (UCI), Darwin (Imperial College London), DAOP-ADL (Trường Đại học Málaga) www.aadl.info [10]

Các thành phần cơ bản của một ngôn ngữ AADL là thành phần, kết nối

và cấu hình hệ thống

 Các khung nhìn

Kiến trúc phần mềm thường được tổ chức trong các khung nhìn

(views), tương tự với các loại bản thiết kế khác nhau để xây dựng nên một hệ thống Trong phạm vi ngữ nghĩa được thiết lập bởi chuẩn ANSI/IEEE 1471-

2000, khung nhìn là các thực thể thể hiện các quan điểm, các cách nhìn khác nhau về hệ thống, nơi mà các điểm nhìn tồn tại để mô tả hệ thống theo các khía cạnh cùng với mối quan tâm của các thành viên tham gia hệ thống

Một số khung nhìn phổ biến là: (Peter và cs, 2004), [6]

Khung nhìn theo các chức năng/ logic

Khung nhìn theo mã nguồn

Khung nhìn theo tư tưởng phát triển/cấu trúc

Khung nhìn về xử lý đồng thời / tiến trình / thread

Khung nhìn vật lý / triển khai

Khung nhìn theo hành động người sử dụng

 Sự khác biệt với thiết kế chi tiết

Kiến trúc phần mềm còn được biết đến như một chiến lược thiết kế Nó

là một hoạt động liên quan đến thiết kế tổng thể một giải pháp Như những

mô hình lập trình, kiểu kiến trúc, các chuẩn của công nghệ phần mềm dựa trên các thành phần, các nguyên tắc thiết kế, cách biểu diễn ngôn ngữ và sự tinh chỉnh

Sự khác biệt giữa chiến lược và thực hiện thiết kế được định nghĩa bởi Locality Criterion, theo những thoả thuận về thiết kế phần mềm là không cục

bộ nếu và chỉ nếu một chương trình thoả mãn các yêu cầu mở rộng vào trong một chương trình đáng lẽ là không thể

1.1.1.4 Các vấn đề liên quan kiến trúc phần mềm

Kiến trúc phần mềm là một tập các quyết định do kiến trúc sư phần mềm tạo ra Kiến trúc phần mềm được định nghĩa thông thường theo các thành phần và kết nối Các thành phần được xác định với nhiệm vụ cụ thể để các thành phần client tương tác qua các giao diện Các kết nối giữa các thành phần xác định cơ chế trao đổi, điều khiển và hỗ trợ tất cả các tương tác cần thiết để thực hiện các hành vi của hệ thống

Khi tạo ra kiến trúc, chúng ta phải chỉ ra: (http://cs.cmu.edu/acme) [11]

 Phân chia hệ thống thành các thành phần, hệ thống con, các đơn vị con hoặc các phân mảnh (Mary và cs, 1996) [4]

tất cả các mảnh? 2) Các mảnh có phù hợp với nhau? Đó chính là các vấn đề của giao diện và quan hệ giữa các mảnh

lượng hoặc các thuộc tính của hệ thống, vì ảnh hưởng của chúng là phổ biến và mang tính hệ thống

Kiến trúc không phải là một khung nhìn bằng phẳng về cấu trúc thành phần, dù một lược đồ kiến trúc trình diễn các thành phần và quan hệ giữa chúng là những vấn đề trung tâm và là công cụ giao tiếp cho các kiến trúc sư, đội phát triển và khách hàng Kiến trúc cần phải bao gồm:

 Siêu kiến trúc: khung nhìn kiến trúc, kiểu, nguyên tắc, cách giao tiếp chính,

cơ chế điều khiển và các khái niệm để hướng dẫn nhóm kiến trúc sư trong việc tạo ra các kiến trúc

nhìn hoặc mô hình bổ sung trong các kiến trúc phần mềm

Khi tạo ra các khung nhìn, chúng ta cần chú ý đến:

các vấn đề liên quan, các quyết định, đơn giản hoá và kỹ thuật quan hệ như giao diện ẩn và đóng gói

để đạt năng lực hệ thống xác định

1.1.1.5 Những vấn đề không thuộc kiến trúc phần mềm

Kiến trúc phần mềm phải được phân biệt từ thiết kế cấp thấp như thiết

kế thành phần bên trong và các thuật toán, cách thực hiện và các loại khác của kiến trúc quan hệ Nó cũng không phải là mô hình thông tin hay dữ liệu, qua cách sử dụng mô hình để lấy loại thông tin cho các phương thức trên giải quyết

Những vấn đề không thuộc về kiến trúc còn bao gồm các bộ xử lý,

mạng (network) mà phần mềm sẽ chạy trên đó Tuy nhiên, nó sử dụng thông

tin này để đánh giá tác động trong các lựa chọn kiến trúc trên chất lượng hệ

thống như hiệu năng và độ tin cậy Mỗi một kiến trúc đều có những đặc điểm riêng biệt

1.1.1.6 Một số kiến trúc tiêu biểu

Có nhiều cách phương pháp để thiết kế các module phần mềm máy tính

và truyền thông giữa chúng, đó là: (http://cs.cmu.edu/acme) [11]

 Mô hình khách - chủ (Client-server)

 Mô hình 3 lớp (Three-tier model)

1.1.2 Đặc điểm của kiến trúc phần mềm

Kiến trúc phần mềm ngày càng được chú ý Để đạt được thành công, đòi hỏi không chỉ các yếu tố kỹ thuật mà còn phụ thuộc vào sự hiểu biết các nghiệp vụ, cơ cấu tổ chức và các kiến thức để đảm bảo hướng đi đúng đắn trong phát triển Có rất nhiều tài nguyên để giúp các kiến trúc sư của doanh nghiệp và kiến trúc sư phần mềm hiểu rộng và sâu hơn về kiến trúc và vai trò của kiến trúc trong việc phát triển và bảo trì hệ thống

Hình 1.1 cho thấy có 5 câu hỏi lớn của kiến trúc phần mềm: Kiến trúc phần mềm là gì? Tại sao phải chú ý đến kiến trúc? Cách thức tạo ra một kiến trúc phần mềm? Ai chịu trách nhiệm tạo ra kiến trúc? Cách thức kiến trúc phù hợp với quá trình phát triển

What is software architecture?

Why should we pay attention to architecture?

Where does architecture fit in development?

Who is right for the architect role?

 Kỹ thuật tốt và trình bày sáng sủa

 Thành công – được sử dụng trong thực tế ở các hệ thống đang phát triển và

có những ưu thế chiến lược

1.1.2.1.2 Các quy trình kỹ thuật

Trọng tâm của quy trình kiến trúc là các tập hợp tài liệu kiến trúc, mô

tả cấu trúc của hệ thống trên nhiều khung nhìn Các yêu cầu của kiến trúc tập trung vào các hoạt động mang tính cấu trúc Các hướng tiếp cận kiến trúc khác nhau tạo ra các bản thiết kế khác nhau Các mô hình và đánh giá các lựa chọn, phân tích sự cân bằng giữa các yếu tố, là một phần quan trọng của pha

đánh giá (evaluating phase) Cuối cùng, pha xác nhận tính hợp lệ cung cấp các chỉ dẫn, có cơ hội để giải quyết các vấn đề của kiến trúc hệ thống

Khởi tạo

Yêu cầu kiến trúc kiến trúcĐặc tả

Xác nhận tính hợp lệ

Triến khai kiến trúc

Hình 1.2 Quá trình mô hình kiến trúc

 Yêu cầu kiến trúc

Yêu cầu kiến trúc là một tập các yêu cầu hệ thống, xác định các vấn đề liên quan đến kiến trúc Các đối tượng nghiệp vụ trong hệ thống và kiến trúc trong những phần cụ thể đóng vai trò quan trọng để đảm bảo kiến trúc thoả

những công việc trong phạm vi hệ thống và những tác động của chúng đến hệ thống

 Đặc tả kiến trúc

Kiến trúc được tạo và ghi thành tài liệu trong pha kiến trúc hệ thống

Mô hình kiến trúc giúp tạo ra các quyết định ban đầu, xác định các yếu tố ảnh hưởng kiến trúc (artifact) Các tài liệu yếu tố này được quyết định dưới dạng các mô hình, các khung nhìn, các mô tả, giải thích, phân tích nguồn gốc, cân nhắc sự lựa chọn, các báo cáo

 Xác định tính hợp lệ của kiến trúc

Pha xác nhận tính hợp lệ liên quan đến một số người bên ngoài nhóm thiết kế, giúp đưa ra các ý kiến khách quan về kiến trúc để nâng cao sự tin cậy của kiến trúc, đáp ứng được yêu cầu, tạo nên sự hoàn thiện của thiết kế Giá trị của kiến trúc liên quan đến các kinh nghiệm thực nghiệm, mô hình và kịch bản sử dụng, tìm ra các lỗ hổng và điểm yếu trong kiến trúc

Hình 1.3 Xác định tính hợp lệ của kiến trúc [11]

Ví dụ như hình 1.3, khi chuyển đổi kiến trúc từ lược đồ tuần tự (sequence diagram) sang lược đồ kiến trúc (architecture diagram), hệ thống sẽ báo lỗi thiếu giao diện kết nối giữa thành phần C2 và C4

 Ti ến trình tổ chức

Dự án kiến trúc dễ bị ảnh hưởng bởi 3 lỗi chính – dự án thiếu tài nguyên hoặc bị huỷ bỏ vội vã bởi sự quản lý thiếu trách nhiệm; bị treo bởi các cuộc tranh cãi nội bộ; sự thiếu sót trong khâu quản lý của lãnh đạo; hoặc kiến trúc bị bỏ qua, bị cản trở bởi đội ngũ phát triển sản phẩm Tiến trình tổ chức giúp giải quyết các vấn đề này Tiến trình gồm 2 pha: bắt đầu (init/commit) và

triển khai (deployment) hỗ trợ các tiến trình kỹ thuật

Pha khởi đầu: Pha khởi đầu tập trung vào các vấn đề khởi đầu dự án để

đạt được sự ủng hộ Việc tạo ra khung nhìn kiến trúc tập trung vào tổ chức nhóm kiến trúc và đạt được sự chấp thuận của lãnh đạo Từ trên xuống dưới, phải tạo ra các quy trình để thiết lập các mối quan hệ trong nhóm Kế hoạch

trao đổi cần được thực hiện để thoả mãn các yêu cầu hệ thống Các công việc cần thực hiện trong pha này là:

Bảo vệ được kiến trúc đề ra

Lãnh đạo và tổ chức nhóm

Trao đổi và tư vấn với các đội thành viên trong dự án

Áp dụng các quy trình cho dự án

P ha triển khai – Deployment: Pha triển khai theo các tiến trình kỹ thuật,

xác định các nhu cầu của người phát triển, những người được hiểu là sử dụng kiến trúc để thiết kế và xây dựng sản phẩm Khoảng cách từ hiểu kiến trúc và các nhân tố cơ bản đến đáp ứng nhu cầu thay đổi đối với kiến trúc là rất lớn Các tư vấn kế thừa là các bài hướng dẫn, trình diễn cũng như xem xét lại các vấn đề liên quan đến kiến trúc

1.1.2.1.3 Động lực của kiến trúc phần mềm

Các khuôn mẫu thành công tạo ra nền tảng cho các chiến lược kiến trúc Những thiếu sót trong quá khứ của kiến trúc sẽ được sửa chữa làm cho tính tổ chức trở nên chắc chắn Các hệ thống nguyên khối, các hệ thống ẩn có thời gian phát triển kéo dài, không đoán trước, là nguyên nhân gây nên tình trạng lộn xộn của kiến trúc, cản trở đối với các tổ chức lớn Để phá vỡ cơ cấu của các hệ thống kế thừa liên hiệp, xây dựng hệ thống phù hợp với môi trường và thích nghi khi môi trường thay đổi, chúng ta cần phải có kiến trúc

Khi có sự thay đổi trong tổ chức, kiến trúc chỉ ra tính phức tạp, các khoảng trống phát sinh khi đổi mới Nó cho phép hệ thống phát triển có tính tin cậy trên thoả mãn khách hàng với các nghiệp vụ khác nhau

Kiến trúc phục vụ cả hai tiến trình kỹ thuật và tổ chức Trên khía cạnh

tổ chức, kiến trúc giúp:

Giao tiếp thiết kế ở cấp độ cao

Cung cấp các ngữ cảnh hệ thống

Phân chia phần công việc

Trên khía cạnh kỹ thuật, kiến trúc cho phép thiết kế hệ thống tốt hơn:

Thoả mãn các yêu cầu và mục tiêu

Cho phép phân chia linh hoạt của hệ thống

Giảm giá thành của công việc duy trì và mở rộng

Tăng cường sử dụng lại, tích hợp với các hệ thống kế thừa và các phần mềm trung gian

1.1.2.2 Kiến trúc sư phần mềm

nhiệm hoàn thiện những công việc liên quan đến kiến trúc Trách nhiệm cũng

sẽ bao gồm cả việc ghép nối khung nhìn kiến trúc, các khái niệm hoá và thử nghiệm với hướng tiếp cận kiến trúc thay thế, tạo ra các mô hình, thành phần, tài liệu đặc tả giao diện, xác định tính hợp lệ đối với yêu cầu và giả định

Kiến trúc sư không chỉ liên quan đến các hoạt động kỹ thuật mà còn cả khía cạnh chiến lược và quản lý Đôi khi kiến trúc sư còn đóng vai trò tư vấn Các chiến lược về nghiệp vụ và kỹ thuật đòi hỏi phải hình dung một hướng tiếp cận kiến trúc đúng đắn đối với các vấn đề của khách hàng, đưa ra các mục tiêu nghiệp vụ của một tổ chức kiến trúc, khẳng định sự đúng đắn trong định hướng kỹ thuật, chỉ ra sự tuần tự cho chiến lược kỹ thuật về mặt kiến trúc

Hình 1.4 Các tiếp cận tuần tự của kiến trúc [11]

Kiến trúc sư cần hợp tác tích cực với các nhóm thành viên dự án, bao gồm cả các cấp lãnh đạo, các nhóm phân tích nghiệp vụ, nhóm marketing và người phát triển, chủ động đưa kiến trúc tới các thành viên khác nhau của dự

án, trao đổi rộng rãi và làm việc theo mạng lưới để bảo đảm sự thành công trong các quá trình tiếp theo

Trong vòng đời xây dựng, kiến trúc sư phải luôn sẵn sàng để tư vấn, trả lời trên những ứng dụng của kiến trúc, giải thích các yếu tố cơ bản đằng sau

sự lựa chọn, sửa đổi, bổ sung vào kiến trúc nếu thấy hợp lý

Cuối cùng, kiến trúc sư phải dẫn dắt đội thiết kế, cộng đồng người phát triển trong định hướng kỹ thuật và tổ chức

Thông thường, kiến trúc sư là cơ hội thăng tiến cao nhất của người phát triển trong những nỗ lực để đạt tới Một kiến trúc sư tốt nhất là một người không chỉ có kỹ thuật tốt và tinh thông các khía cạnh về mặt kỹ thuật, khả năng truyền đạt tốt mà còn có chiến lược tốt, có quan điểm tổ chức tốt, nhà tư vấn và khả năng lãnh đạo

1.1.2.3 Kiến trúc phần mềm theo ngữ cảnh

Ngày càng nhiều sản phẩm được phát triển với nhiều phiên bản đưa ra

và qua nhiều vòng đời phát triển Các sản phẩm còn được biết đến như sự phát triển mang tính tiến hoá

Trong những trường hợp này, pha kiến trúc rất quan trọng đối với các vòng đời tiến hoá, cho phép chia hệ thống thành những hệ thống nhỏ có thể xây dựng Bước sửa đổi kiến trúc là một phần đối với mỗi vòng phát triển ngắn, thực hiện yêu cầu và làm cho kiến trúc phù hợp và hợp thành trong kiến trúc

Hình 1.5 cho thấy quá trình phát triển của một hệ thống phải trải qua

nhiều bước từ các đầu tư ban đầu (initiate investigation), xem xét nhu cầu thực tế và xu hướng của thị trường (Market Trends/Needs Evaluating), các đánh giá về kỹ thuật cũng như nghiên cứu các đặc điểm (Technical Evaluating/Feasibility Studies) để quyết định có tiến hành lam hày không

(Go/Not Go) Trên cơ sở quyết định làm mới tiến hành các bước xử lý yêu cầu

(Understand/Doc Customer Requirements), thiết kế và phát triển các thành phần (design and develop component), song song với nó là quá trình cập nhật

tài liệu (Arbitrate and document) Tiếp theo là bước thiết kế và kiểm thử (Design And Run Test ) để rồi quyết định thực hiện sản phẩm (Go To Product) Hình 5 cũng chỉ ra các đôin tham gia phát triển hệ thống gồm đội

quản lý sản phẩm (Product Management), đội thu thập và xử lý yêu cầu (Requirement ), đội kiến trúc (Architecture), đội phát triển (Development) và đội kiểm thử (Test)

Hình 1.5 Các hoạt động trong một quá trình phát triển [11]

1.1.3 Các thành phần của kiến trúc phần mềm

Có rất nhiều kiến trúc khác nhau, nhưng có một cách chung để xem xét các thành phần kiến trúc Nó coi hệ thống như một hệ thống cụ thể, là tập hợp

các thành phần tính toán (nói tắt là thành phần) cùng nhau cùng với một đặc

tả các tương tác giữa các thành phần Đó chính là các kết nối

Hình 1.6 Khung nhìn thành phần và kết nối

Một kiểu kiến trúc định nghĩa một họ các hệ thống dưới dạng các mẫu

tổ chức cấu trúc Cụ thể, kiểu kiến trúc xác định các từ vựng của thành phần

và kết nối có thể sử dụng cùng nhau trong một thực thể của mẫu đó, với một tập ràng buộc trên cách thức kết hợp Nó bao gồm cả các mô hình ràng buộc trên mô tả kiến trúc

Chúng ta mô hình một khung nhìn của kiến trúc phần mềm như một đồ thị thành phần và kết nối Cụ thể, các phần tử và quan hệ cơ bản của đồ thị là:

sở dữ liệu, client, server, giao diện đồ hoạ GUI Mỗi thành phần có một tập các cổng để mô hình giao diện của thành phần đó, qua nó tương tác với thành phần khác (qua kết nối)

một tập các vai trò, mô hình các đặc tả của hành vi yêu cầu của thành phần

sử dụng kết nối đó

phần thích hợp với vai trò của tập kết nối để xác định các mô hình liên thông

1.1.4 Hướng tiếp cận đến kiến trúc phần mềm

Hiện tại đang có một số xu hướng tiếp cận đến các ngôn ngữ đặc tả kiến trúc phần mềm:

Tập trung vào phân tích sự mở rộng của mô hình kiến trúc

Các mô hình riêng biệt

Các chú thích mô hình

Các kỹ thuật phân tích

Các giải pháp đối với các yêu cầu cụ thể

Tập trung vào dải rộng của các vấn đề phát triển

Họ các mô hình

Các thực nghiệm thông qua kiểm tra nghiêm ngặt

Kiến trúc như một bức tranh lớn của phát triển

Các giải pháp chung

1.2 NGÔN NGỮ ĐẶC TẢ KIẾN TRÚC

1.2.1 Tổng quan

1.2.1.1 Giới thiệu chung

Kiến trúc phần mềm là một cấp độ thiết kế liên quan đến việc mô tả các phần tử mà từ đó hệ thống sẽ được xây dựng, mô tả các tương tác giữa các phần tử này, các khuôn mẫu chỉ dẫn thành phần cấu tạo và các ràng buộc trên những khuôn mẫu này (Mary và cs, 1996) [4]

Đáp ứng nhu cầu này, ngôn ngữ đặc tả kiến trúc (ADL hay còn gọi là

nghĩa như sau: một AADL cho các ứng dụng phần mềm tập trung vào các cấu

trúc cao của toàn thể ứng dụng hơn là cách thực hiện chi tiết của bất kỳ module ngồn đặc tả nào AADL đang trở thành đối tượng nghiên cứu trong

vài năm gần đây của cộng đồng kiến trúc phần mềm

Ngôn ngữ đặc tả kiến trúc là một ngôn ngữ đặc tả bằng văn bản và đồ hoạ, được sử dụng để phân tích, thiết kế kiến trúc hệ thống gồm cả phần mềm, phần cứng của hệ thống thời gian thực và các tính năng quyết định hiệu năng Ngôn ngữ AADL mô tả cấu trúc của hệ thống như một tập hợp các thành phần phần mềm ánh xạ tới một cơ sở phần cứng thực hiện Nó mô tả các giao diện chức năng của các thành phần (dữ liệu đầu vào, dữ liệu đầu ra) và các khía cạnh hiệu năng của thành phần

vào ra được kết nối và cách thức các thành phần phần mềm được phân chia tới các thành phần phần cứng Ngôn ngữ này cũng mô tả các hành vi động của kiến trúc hỗ trợ bởi các ý tưởng mô hình của kiểu thao tác và thay đổi trạng thái

tích mở rộng, cung cấp khả năng phân tích các điểm giao nhau bị ảnh hưởng bởi thay đổi trong kiến trúc trên một đặc tả

AADL cũng có các chú thích đồ hoạ để minh hoạ trực quan của hệ thống phân cấp và cấu trúc truyền thông Biểu tượng đồ hoạ được sử dụng trong các tài liệu tổng quan Một số biểu tượng được trang trí với các icon thêm vào như các vòng trong để thay thế các thuộc tính thành phần

Hiện nay có một số ngôn ngữ đặc tả kiến trúc như ACME (CMU), AADL (UCI), Darwin (Imperial College London) và Wright (CMU) (www aadl info) [10]

1.2.1.2 Phạm vi

Mô hình kiến trúc AADL đặc tả kiến trúc phần mềm và nền tảng phần cứng của các hệ thống hiệu năng, nhúng, thời gian thực Nó mô tả các thuộc tính, giao diện các thành phần phần mềm và thành phần phần cứng (các bộ xử

lý, bus và bộ nhớ) cũng như mô tả cách thức tương tác và kết hợp giữa các thành phần để tạo nên một hệ thống hoàn chỉnh AADL mô tả cả hai giao diện chức năng và khía cạnh hiệu năng của các thành phần độc lập và các thành phần kết hợp Ngôn ngữ được áp dụng cho hệ thống thời gian thực với ràng buộc tài nguyên, an toàn và gồm cả các thiết bị phần cứng chuyên dụng

AADL không chỉ ra cách thức thiết kế hoặc chi tiết thực hiện bên trong của thành phần phần mềm và phần cứng được đặc tả Các chi tiết có thể được xác định bởi các ngôn ngữ mô tả phần cứng và phần mềm lập trình khác nhau

AADL cũng không mô tả bất kỳ một kỹ thuật tích hợp hệ thống cụ thể như hệ điều hành, giao diện chương trình ứng dụng trung gian, kỹ thuật bus hoặc mô hình Tuy nhiên, trong các kiến trúc hệ thống cụ thể, nó có thể mô hình qua các thành phần phần cứng AADL được sử dụng để mô tả các kiến trúc phần cứng khác nhau, các cơ sở hạ tầng phần mềm khác nhau và công nghệ tích hợp có thể được sử dụng để thực hiện một hệ thống xác định

AADL không thiết kế xung quanh một tập công cụ cụ thể Nó đề cập đến các hệ thống và công cụ phần mềm hỗ trợ sử dụng AADL

AADL được phát triển để mô hình hệ thống với các thách thức về tài nguyên, các ràng buộc và các yêu cầu thời gian thực AADL đặc biệt hiệu quả đối với phân tích dựa trên mô hình và đặc tả của hệ thống nhúng thời gian thực phức tạp

1.2.1.3 Mục đích

Ngôn ngữ AADL cung cấp định nghĩa ngữ nghĩa và cú pháp để mô tả các kiến trúc thời gian thực dưới dạng tương tác giữa các thành phần đặc tả

hoá Chuẩn SAE AADL đưa ra một kết nối mô hình cho mô tả và phân tích kiến trúc hệ thống ứng dụng dưới dạng các thành phần và tương tác của chúng AADL bao gồm phần mềm, phần cứng và các thành phần hệ thống để:

và đặc tả hệ thống khả năng hiệu năng

Mục đích của AADL là cung cấp một chuẩn, đưa ra cách thức hiệu quả

và chính xác để mô hình kiến trúc của một hệ thống nhúng, thời gian thực hoặc các hệ thống hiệu năng Nó là một cách thức có thể xử lý bằng máy mô

tả các ý tưởng và cung cấp một khung chương trình để phân tích, mô hình hệ thống, các tiện ích tự động của các hoạt động phát triển, giảm đáng kể các nhược điểm của thiết kế và thực hiện Trong các hệ thống phức tạp AADL cho phép phân tích ban đầu và kiểm tra tính khả thi của các quyết định thiết

kế kiến trúc

ADL không phù hợp cho các thiết kế bên trong cũng như cách thực hiện của thành phần Nó có xu hướng được sử dụng cùng với các ngôn ngữ chuẩn đang tồn tại trong miền này AADL mô tả giao diện và các thuộc tính của thành phần phần cứng bao gồm bộ xử lý, bus, bộ nhớ, kênh truyền thông

và các giao diện thiết bị với môi trường bên ngoài

với thiết kế hệ thống sơ bộ Nó sử dụng công cụ để mô hình, phân tích, thực hiện, tích hợp, xác nhận hợp lệ và chứng thực tự động ở các cấp độ khác nhau

1.2.2 Đặc điểm

Ngôn ngữ AADL gồm các ký hiệu mô hình cho cả các trình bày ký tự hoặc đồ hoạ Nó đưa ra các khái niệm mô hình để mô tả kiến trúc thời gian

thực của hệ thống ứng dụng dưới dạng các công việc cùng xảy ra và tương tác của chúng như là các ánh xạ tới nền tảng thực hiện

Về mặt nguyên tắc, AADL khác với:

trong đó các yêu cầu được mô tả như những vấn đề không gian

 Hỗ trợ công việc khởi tạo, tinh chỉnh và xác nhận tính hợp lệ của kiến trúc

thêm các thông tin để đặc tả hệ thống cuối cùng bắt nguồn từ AADL

Thông thường AADL có:

pháp định nghĩa chính thức cùng với các ngữ nghĩa

 Hỗ trợ cho việc nắm bắt các thông tin thiết kế qua cơ chế chú thích

cấu trúc con bằng các mẫu khởi tạo

hướng đối tượng điều khiển hoặc các kiến trúc động

 Hỗ trợ phân tích

1.2.3 Các dạng đặc tả AADL

Mô hình AADL mô tả kiến trúc và môi trường runtime của một hệ thống ứng dụng dưới dạng các thành phần phần mềm, nền tảng phần cứng cùng với sự tương tác giữa chúng Mô hình AADL nắm bắt các đặc tả bao gồm các khai báo theo cú pháp và ngữ nghĩa bao gồm tất cả các khai báo cần thiết để khởi tạo thực thể runtime của hệ thống ứng dụng mà các đặc tả trình bày

Theo khía cạnh người sử dụng, đặc tả AADL và khai báo thành phần cấu tạo được diễn tả theo các văn bản hoặc đồ hoạ, trong một sự kết hợp của các trình bày đó hoặc dưới dạng ngôn ngữ XML Văn bản và các chú thích đồ hoạ AADL được định nghĩa bởi chuẩn SAE AADL và các mở rộng của nó Hình 1.7 tổng quát các diễn tả thay thế của một đặc tả AADL dưới dạng các văn bản, đồ hoạ hoặc XML

Hình 1.7 Các biểu diễn của AADL (David và cs, 1995) [2]

1.2.3.1 Văn bản

Các đặc tả AADL dưới dạng văn bản là một tập hợp các khai báo văn bản mà người sử dụng có thể đọc được theo chuẩn của AADL Các chú thích

đồ hoạ kết hợp với các đặc tả văn bản bao hàm trong tài liệu để làm nổi bật quan hệ giữa các đặc tả và giúp người đọc có một cái nhìn trực quan về kiến trúc Các chú thích chi tiết của các đại diện đồ hoạ trong xây dựng và khai báo AADL được đưa ra theo các chuẩn đồ hoạ Nguyên tắc khai báo AADL được tổng quát theo bảng 1.1

Bảng 1.1 Nguyên tắc khai báo AADL (Peter và cs, 2006 ) [7]

thread, thread group data,

device, memory và bus

Khai báo loại thành phần thiết lập một định danh (loại thành phần và tên) và định nghĩa tính năng, luồng, các thuộc tính của một loại thành phần Một kha i báo loại

loại khác (extend)

Thực hiện thành phần

(Component Implementation):

system, process, thread,

device, memory và bus

Khai báo thực hiện loại thành phần thiết lập một định

danh (phân loại thành phần, loại và tên) và định nghĩa các tinh chế (sửa đổi mệnh đề con của loại), các thành phần con, lời gọi, kết nối, luồng, kiểu, và các thuộc tính của thực hiện thành phần Các định danh phải bao gồm khai báo loại thành phần nhất quán với phân loại thành phần Khai báo thực hiện thành phần được khai báo phần thực hiện như một sự mở rộng của

Type)

Khai báo loại nhóm cổng thiết lập một định danh (tên)

và định nghĩa các tính năng và thuộc tính của một nhóm cổng Trong phạm vi khai báo, nhóm cổng được định nghĩa như nghịch đảo của một nhóm khác Khai báo loại nhóm cổng cũng được định nghĩa nhóm cổng như một sự mở rộng của loại nhóm cổng khác

(extend)

Package K hai báo gói thiết lập một định danh (tên) của một tập

một đoạn dùng chung hoặc riêng biệt, khai báo các thuộc tính kết hợp với package Package cũng được

loại thành phần AADL , thực hiện, nhóm cổng trong một package có thể được tham chiếu bởi một nhóm

khác

thuộc tính, loại thuộc tính, hằng số thuộc tính mà không thuộc về các lời khai báo trước đó Mỗi một tập thuộc tính có một tên dùng chung duy nhất và cung

cấp một vùng không gian (namespace) duy nhất cho các đối tượng khai báo trong nó Nói cách khác, thuộc

tính l à loại thuộc tính khai báo trong tập thuộc tính được tham chiếu bởi tên tập thuộc tính và tên đối tượng.

(tên) và định nghĩa nội dung một tập các khai báo có thể sử dụng lại mà không phải là một phần của ngôn

mở rộng lõ i mô hình AADL và khả năng phân tích

1.2.3.2 Đặc tả đồ hoạ

cấu trúc hệ thống và mô hình truyền thông, đưa ra cơ sở cho các phối cảnh kiến trúc Các biểu tượng ( ) được sử dụng để chỉ ra sự khác biệt ngữ nghĩa với các biểu tượng đồ hoạ tương tự trong UML

Hình 1.8 Các chú thích đồ hoạ AADL (Peter và cs, 2006 [7]

1.2.4 Mô hình và các thành phần

1.2.4.1 Các phần tử của AADL

Hình 1.9 Tổng quan các phần tử AADL (Peter và cs, 2006) [7]

Hình 1.9 cho thấy các phần tử của AADL gồm có: Loại thành phần (component type), thành phần (component), thực hiện thành phần (component implementation), tập thuộc tính (property set), các gói (package) và thư viện (annex library) Trong phạm vi AADL, một thành phần được đặc trưng hoá bởi định nghĩa của nó (với tên duy nhất), các giao diện với các thành phần khác, các thuộc tính phân biệt, các thành phần con và tương tác của nó

Trong AADL, thành phần được định nghĩa thông qua loại và khai báo thực hiện Một khai báo loại thành phần định nghĩa một thành phần giao diện

và các thuộc tính có thể quan sát được ở bên ngoài Một khai báo thực hiện thành phần định nghĩa một cấu trúc bên trong dưới dạng thành phần con, kết nối các thành phần con, chương trình con gọi tuần tự, các kiểu, thực hiện luồng và các thuộc tính Các thành phần có thể được nhóm bên trong các phần mềm ứng dụng, nền tảng phần cứng thực hiện và các phần loại phức hợp Gói cho phép tổ chức các phần tử AADL vào các nhóm tên Tập thuộc tính và thư viện thêm vào cho phép người thiết kế mở rộng và chỉnh sửa các đặc tả ngôn ngữ để thoả mãn yêu cầu của dự án

1.2.4.1.1 Phần tử thành phần

Thành phần tạo là thành phần trung tâm của AADL Các thành phần được gán một định danh duy nhất (tên), được khai báo với loại và thực hiện trong một phân loại thành phần cụ thể Một phân loại thành phần được định nghĩa như bản chất runtime của thành phần Có 3 loại nhóm thành phần là:

 Phần mềm ứng dụng

Thread: một thành phần hoạt động có thể thực hiện đồng thời và tổ chức thành nhóm thread Một thread là một khối tuần tự các bước thực hiện có thể lập lịch, chạy đồng thời qua các mã nguồn

Nhóm thread: Nhóm thread là một thành phần trừu tượng cho các tổ chức logic như thread, dữ liệu và nhóm thread trong một bô xử lý

Tiến trình: Tiến trình mô tả một vùng không gian địa chỉ bảo vệ, vùng

không gian phân chia, nơi sự bảo vệ được cung cấp từ các thành phần khác truy nhập vào bên trong tiến trình

Dữ liệu: loại dữ liệu và dữ liệu tĩnh trong các văn bản nguồn Đặc biệt,

Loại dữ liệu ứng dụng

Cấu trúc của loại dữ liệu qua thành phần con dữ liệu trong khai báo

hệ điều hành) để thực hiện việc lập lịch và các khả năng khác để hỗ trợ thực hiện thread

Bộ nhớ: lưu trữ mã nguồn và dữ liệu như chương trình con, dữ liệu và bộ

xử lý giới hạn thành phần bộ nhớ Thành phần bộ nhớ bao gồm RAM, ROM hoặc các thiết bị lưu trữ khác như ổ cứng…

Thiết bị: như các thiết bị cảm ứng, đầu từ hoặc các thành phần khác có

giao diện với môi trường bên ngoài

xác định sử dụng khai báo truy nhập và kết hợp đến một bus Bus có thể kết nối trực tiếp đến các bus khác để mô tả liên kết liên mạng phức tạp

 Các thành phần phức hợp

Hệ thống: thiết kế các phần tử để cho phép tích hợp các thành phần khác vào các khối khác nhau trong kiến trúc Các thành phần hệ thống phức hợp có

Chuẩn AADL bao gồm cả ngữ nghĩa runtime cho một cơ chế trao đổi

và điều khiển dữ liệu bao gồm:

Truyền thông điệp - message passing

Truyền sự kiện - event passing

Đồng bộ hoá truy cập và chia sẻ các thành phần

Hình 1.10 Mệnh đề con của một khai báo loại thành phần

Mệnh đề con extends cho phép một khai báo loại thành phần để xây

dựng nên một thành phần khác Một khai báo thành phần như một phần mở rộng kế thừa các đặc điểm đã có của thành phần gốc Trong phạm vi, một thành phần được khai báo như một sự mở rộng của một loại khác, giao diện, luồng và các thuộc tính khác được thêm vào, các phần tử khai báo cụ thể của loại thành phần trước đó được mô tả chi tiết và các thuộc tính được sửa đổi

Nó cho phép mô hình hoá các giao diện khác nhau của một họ hay các thành phần quan hệ

1.2.4.1.3 Thực hiện thành phần

Thực hiện thành phần xác định một cấu trúc bên trong dưới dạng các thành phần con, các tương tác (lời gọi hay các kết nối) giữa các tính năng của các thành phần con này, luồng theo thứ tự, các thành phần con, kiểu minh hoạ của trạng thái thao tác và thuộc tính

Các thành phần con của một khai báo thực hiện được mô tả ở phần trên Các khai báo thành phần con, kết nối, lời gọi xác định một phức hợp của một thành phần như tập hợp của các thành phần (thành phần con) và các tương tác của chúng Flow đại diện cho cách thực hiện của đặc tả luồng trong loại thành phần hoặc từng bước được phân tích Mode đại diện cho các kiểu thao tác thay thế có thể biểu lộ chính nó như một cấu hình thay thế của thành phần con, lời gọi tuần tự, kết nối, tuần tự luồng và các thuộc tính Các thuộc tính định nghĩa bản chất bên trong của một thành phần Có một số thuộc tính được định nghĩa trước cho mỗi thực hiện thành phần

Hình 1.11 Mệnh đề con của khai báo thực hiện

Thực hiện mở rộng (khai báo với mệnh đề con mở rộng) kế thừa các đặc điểm của thực hiện thành phần gốc và tất cả các công việc đã thực hiện trước đó Sự tinh chế cho phép xác định cụ thể các thực hiện thành phần (các mẫu template) được hoàn thiện, trong khi sự mở rộng cho phép một thực hiện thành phần được diễn tả như các biến của mô tả thành phần chung thông qua

bổ sung Hơn nữa, một khai báo thực hiện bổ sung có thể thêm các giá trị thuộc tính đến các tính năng và các loại phù hợp, thực hiện thông qua mệnh

đề refine type

Loại thành phần phức hợp được định nghĩa qua các khai báo thành phần con trong phạm vi khai báo thực hiện thành phần Một thành phần con

đại diện cho các phần tử phân chia và một thực hiện phân loại (classifier) đại

diện cho sự lựa chọn trong một họ Thực thể thành phần được tạo bởi sự khởi tạo một thực hiện thành phần và các thành phần con của nó một cách đệ quy

1.2.4.1.4 Gói, tập thuộc tính và thư viện

Gói AADL cho phép tập hợp các khai báo thành phần vào các khối riêng biệt cùng với tên của nó (namespace) Các phần tử với cùng đặc tính cũng có thể nhóm với nhau vào trong một package và tham chiếu đến tên package sử dụng Package có thể hỗ trợ sự phát triển độc lập của mô hình AADL cho các hệ thống con khác nhau trong một hệ thống cỡ lớn, bằng cách cung cấp các tên vùng khác nhau cho mỗi nhóm phần tử hệ thống con

Mỗi tập thuộc tính là tên nhóm của khai báo thuộc tính định nghĩa một thuộc tính mới và loại thuộc tính có thể bao gồm trong đặc tả Các thuộc tính này có thể được tham chiếu khi sử dụng tên tập thuộc tính và có thể kết hợp với các thành phần và phần tử mô hình khác trong phạm vi đặc tả hệ thống Các khai báo này và cách sử dụng trở thành một phần của đặc tả

Annex cho phép người sử dụng mở rộng ngôn ngữ AADL, hợp nhất

phép phân tích các khía cạnh quan trọng của hệ thống

1.2.4.2 Các thành phần của AADL

Các khối thành phần chính của ngôn ngữ đặc tả kiến trúc phần mềm là các thành phần (components), các thành phần kết nối (connectors) và các cấu hình kiến trúc Để suy luận ra bất kỳ loại thông tin về một kiến trúc, ít nhất các thành phần cấu tạo phải được mô hình hoá

1.2.4.2.1 Mô hình thành phần

Thành phần trong kiến trúc là các đơn vị tính toán hoặc đơn vị lưu trữ

dữ liệu Do đó, thành phần là nơi tính toán hoặc lưu các trạng thái Thành phần có thể nhỏ như một thủ tục đơn hoặc cũng có thể lớn như toàn bộ một ứng dụng

Mỗi thành phần có thể yêu cầu không gian dữ liệu và không gian tính toán của nó hoặc yêu cầu chia sẻ với các thành phần khác Như đã đề cập, các giao diện thành phần rõ ràng là một yêu cầu bắt buộc của ngôn ngữ đặc tả kiến trúc phần mềm Các đặc điểm bổ sung cho thành phần mô hình là loại

(types ), ngữ nghĩa (semantics), ràng buộc (constraints), mở rộng (evolution)

và các thuộc tính phi chức năng (non-function properties)

thế giới xung quanh Giao diện xác định các dịch vụ (thông điệp, thao tác

và các biến) mà thành phần cung cấp

có khả năng sử dụng lại Loại thành phần có thể thuyết minh bằng ví dụ cụ thể nhiều lần trong một kiến trúc đơn lẻ hoặc qua nhiều kiến trúc

phần Nó tựa như mô hình cần thiết để thực hiện phân tích, tuân theo các ràng buộc kiến trúc, bảo đảm các ánh xạ nhất quán của kiến trúc từ một cấp

độ trừu tượng đến cấp khác

của nó, sự vi phạm các ràng buộc sẽ đưa ra một hệ thống không như mong đợi của người tham gia hệ thống

thể định nghĩa không chính thức như một sự sửa đổi của (một tập hợp con) các thuộc tính thành phần, ví dụ như giao diện, hành vi hoặc sự thực hiện

 Các thuộc tính phi chức năng: Các thuộc tính phi chức năng (như an toàn, bảo mật, hiệu năng, đóng gói) có thể không trực tiếp xây dựng từ sự đặc tả các hành vi của nó nhưng cần thiết để đảm bảo sự mô phỏng của hành vi khi chạy, thực hiện phân tích, đảm bảo các ràng buộc, ánh xạ thành phần thực hiện tới các khu xử lý

1.2.4.2.2 Mô hình kết nối

Kết nối là khối xây dựng kiến trúc sử dụng để mô hình sự tương tác giữa các thành phần và các nguyên tắc quản lý các tương tác đó Không giống các thành phần, các kết nối có thể không phù hợp với các khối biên dịch trong một hệ thống thực hiện Nó có thể thực hiện như các thông điệp (message) có thể biên dịch một cách độc lập trong các thiết bị, nhưng cũng có thể chứng tỏ bản thân nó là các biến chia sẻ, các bảng số liệu vào, các vùng đệm, các câu lệnh như một sự kết nối, cấu trúc dữ liệu động, thứ tự tuần tự của các lời gọi thủ tục gắn liền bên trong các mã nguồn, khởi tạo các tham số, các giao thức client – server, các đường ống (pipe), các kết nối SQL giữa cơ sở dữ liệu và một ứng dụng… Các đặc điểm mô tả hoá các kết nối là các giao diện, loại, ngữ nghĩa, ràng buộc, mở rộng và các thuộc tính phi chức năng của nó Chúng được mô tả như sau:

gắn liền với nó Giao diện kết nối cho phép các kết nối thích hợp của các thành phần và tương tác của nó bên trong kiến trúc và do đó, lý giải được các cấu hình kiến trúc

 Loại: Loại kết nối là sự tách ra có thể đóng gói các thành phần truyền thông, sự phối hợp và các quyết định đã được dàn xếp Tương tác ở cấp kiến trúc có thể được mô tả hoá bằng các giao thức phức hợp Việc tạo các giao thức có thể sử dụng cả bên trong kiến trúc và các điểm giao nhau giữa các kiến trúc đòi hỏi các kết nối mô hình AADL như các loại kết nối