Please enable JavaScript.
Coggle requires JavaScript to display documents.
Chapter 3 Models for Software Architecture - Coggle Diagram
Chapter 3 Models for Software Architecture
3.1 Overview
kiến trúc phần mềm mô tả tập hợp các thành phần, kết nối, tương tác của nó
xác định cấu hình triển khai của tất cả các thành phần và kết nối
phù hợp với các yêu cầu chức năng và phi chức năng
Box-and-line diagrams thường được sử dụng.
Các dòng biểu thị mối quan hệ giữa các thành phần
ngữ nghĩa của các dòng có thể khác nhau, chúng có thể liên quan đến sự phụ thuộc, luồng điều khiển, luồng dữ liệu, v.v
giúp chúng ta hiểu các khái niệm kinh doanh ->rút ra sơ đồ thiết kế và mô hình hóa phần mềm
UML được sử dụng trong thiết kế và mô hình hóa phần mềm
4+1 view model:cách khác để hiển thị các yêu cầu chức năng và phi chức năng
Có năm khung nhìn trong mô hình
quy trình
:giải quyết các yêu cầu không chức năng như kiểu giao tiếp mô-đun và các vấn đề về hiệu năng
phát triển
: tổ chức các đơn vị phần mềm theo các cách được xác định rõ theo cấu trúc tệp hoặc thư mục thực tế
logic:
xác định các mô-đun phần mềm và ranh giới, giao diện, môi trường bên ngoài
vật lý
: xác định cơ sở hạ tầng triển khai về phần mềm, phần cứng, cấu hình mạng và cài đặt cho mục đích phân phối
giao diện người dùng
3.2 UML for Software Architecture
3.2.1 Structural Diagrams
3.2.1.1 Class Diagram
mô tả mỗi lớp riêng lẻ với kiểu, giao diện, thuộc tính và phương thức của nó
cung cấp các hợp đồng hành vi mà lớp: kế thừa, tổng hợp và liên kết
các quan hệ điển hình bao gồm ánh xạ một-một, một-nhiều và nhiều-nhiều cũng được ký hiệu bằng kiểu bội số
3.2.1.2 Object Diagram
là các thể hiện của các lớp, là một ví dụ cụ thể của sơ đồ lớp khi chạy
Nhiều sơ đồ hành vi khác (sơ đồ trình tự, sơ đồ truyền thông và sơ đồ tương tác) có thể tham chiếu đến sơ đồ đối tượng
3.2.1.3 Composite Structure Diagram
mô tả thành phần của các yếu tố được kết nối với nhau hoặc sự cộng tác của các trường hợp thời gian chạy
Có hai ký hiệu cơ bản: cộng tác (được biểu diễn bằng nhật thực nét đứt) và lớp có cấu trúc (được biểu diễn bằng hộp hình chữ nhật,có thể có một chú thích chỉ ra vai trò của nó trong sự hợp tác)
3.2.1.4 Component Diagram
Một thành phần là một khối xây dựng có thể triển khai, có thể tái sử dụng được sử dụng trong thiết kế và phát triển phần mềm: jar(java),dll(.NET),..
Mỗi thành phần có một giao diện(interface) để hiển thị các dịch vụ của nó và ẩn các triển khai của nó
ký hiệu: một giao diện được thực hiện(hình kẹo mút),giao diện bắt buộc phải được cung cấp bởi một số thành phần khác(cốc)
3.2.1.5 Package Diagram
đại diện bởi một thư mục được gắn thẻ cho biết nơi chứa tất cả các lớp và gói con
tất cả các lớp trong cùng một gói có một tên duy nhất nhưng chúng có thể có cùng tên trong các gói khác nhau (namespace)
Một sơ đồ gói cho thấy mối quan hệ phụ thuộc giữa các gói trong đó thay đổi một gói có thể dẫn đến thay đổi trong các gói khác.
sử dụng các sơ đồ gói để biểu diễn các cấu trúc hệ thống có thể giúp giảm độ phức tạp và đơn giản hóa các mối quan hệ giữa các lớp
3.2.1.6 Deployment Diagram
mô tả cấu hình vật lý của hệ thống phần mềm được triển khai trên các nút máy chủ phần cứng và mạng giữa các nút
được tạo ra trong giai đoạn sau của vòng đời phát triển phần mềm
UML sử dụng ký hiệu khối để biểu diễn nút tài nguyên máy tính (một thiết bị phần cứng hoặc một hệ thống con phần mềm)
3.2.2 Behavioral Diagrams
3.2.2.1 Use Case Diagram
mô tả các yêu cầu của người dùng về mặt chức năng hệ thống như một hợp đồng giữa người dùng (actor) và hệ thống phần mềm
gồm các tác nhân, trường hợp sử dụng và các liên kết giữa chúng
«include» là một đường đứt nét với một mũi tên chỉ vào trường hợp sử dụng được sử dụng lại
«extend» cũng là một đường có hướng đứt nét với một mũi tên chỉ về trường hợp sử dụng mở rộng
3.2.2.2 Activity Diagram
mô tả các quy trình kinh doanh phức tạp, mô tả các bước trong một quy trình
gồm quy trình công việc phức tạp, ra quyết định, thực thi đồng thời, xử lý ngoại lệ, chấm dứt quy trình, v.v ...
Một sơ đồ hoạt động tương ứng với một quy trình kinh doanh
UML sử dụng một hình chữ nhật bo tròn để thể hiện một hoạt động
Mỗi sơ đồ hoạt động có một điểm bắt đầu và một hoặc nhiều điểm kết thúc
xử lý song song: sử dụng một cặp thanh ngang màu đen để biểu thị các hành động rẽ nhánh / nối tương ứng
hỗ trợ giao tiếp giữa hai luồng đồng thời bằng cách gửi tín hiệu từ đường này sang đường khác. (Đây được gọi là một sự kiện và được ghi chú là một cặp đa giác lồi.)
3.2.2.3 State Machine Diagram
là một sơ đồ hướng sự kiện trong đó các yếu tố của hệ thống thay đổi trạng thái của chúng để đáp ứng với các kích thích bên ngoài hoặc bên trong (như sự kiện thời gian hoặc các sự kiện hệ thống khác)
để chỉ định hành vi nội bộ của các đối tượng
trạng thái là một hình chữ nhật tròn với ba phân vùng: tên trạng thái, biến trạng thái và các hoạt động trạng thái
có một điểm bắt đầu trong một vòng tròn màu đen và có một hoặc nhiều điểm cuối,điểm sau được biểu thị bằng vòng tròn mắt
Các liên kết chuyển tiếp giữa các trạng thái là các đường liền nét với đầu mũi tên để chỉ hướng
state chart in UML 1.x
3.2.2.4 Interaction Overview Diagram
mô tả luồng điều khiển của các tương tác thay vì thông báo. Nó là một biến thể của sơ đồ hoạt động
Các nút biểu thị tham chiếu đến sơ đồ hiện có (ref), thành phần tương tác cơ bản [activity diagram(ad)] hoặc sequence diagram(sd)]
Mỗi nút (hoặc khung) có thể là một sơ đồ tương tác như sơ đồ trình tự, sơ đồ truyền thông, sơ đồ hoạt động hoặc sơ đồ tổng quan tương tác lồng nhau
nút tham chiếu được biểu thị bằng "ref" ở góc trên bên trái của khung rỏ đến một sơ đồ hiện có
Một yếu tố cơ bản được biểu thị bằng nhãn: "ad" cho activity diagram, "sd" cho sequence diagram và "cd" cho communication diagram,...
3.2.2.5 Sequence Diagram
quan trọng nhất và được sử dụng rộng rãi để phân tích và thiết kế hệ thống phần mềm
là một sơ đồ tương tác định hướng thời gian hiển thị trình tự thời gian của các thông điệp giữa các đối tượng
một sơ đồ trình tự tương ứng với một trường hợp sử dụng
Mỗi đối tượng có một dòng thời gian dọc cho vòng đời của nó (nét đứt)
Mỗi dòng thời gian dọc có một số hộp hình chữ nhật hẹp đại diện cho trạng thái kích hoạt đối tượng
Mỗi hộp cũng có thể có một liên kết được định hướng tự đệ quy chính nó, chỉ ra rằng đối tượng chuyển các thông điệp đến chính nó
Kích hoạt cũng có thể phân nhánh hoặc rẽ nhánh nhiều vòng đời riêng biệt
truyền tin nhắn giữa các đối tượng được thể hiện bằng một liên kết mũi tên ngang từ nguồn đến đích
3.2.2.6 Communication or Collaboration Diagram
collaboration diagram in UML 1.x
sơ đồ hướng thông báo mô tả tất cả các chuỗi thông điệp, điều khiển luồng, phối hợp đối tượng, v.v
tóm tắt cách các đối tượng trong hệ thống nhận và gửi tin nhắn
Phía trên các liên kết trong sơ đồ truyền thông là các tin nhắn được đánh số, cho biết thứ tự chúng được gửi hoặc nhận
truyền thông có thể được chuyển đổi thành sơ đồ trình tự tương đương và ngược lại.
3.2.2.7 Timing Diagram
là một sơ đồ mới trong UML 2.0
nó kết hợp biểu đồ trạng thái và chuỗi thời gian để hiển thị chế độ xem động của thay đổi trạng thái gây ra bởi các sự kiện bên ngoài theo thời gian
được sử dụng trong các hệ thống quan trọng về thời gian như hệ điều hành thời gian thực, thiết kế hệ thống nhúng, v.v
Unified Modeling Language (UML) là ngôn ngữ đồ họa quan hóa, chỉ định, xây dựng và ghi lại các thành phần của một hệ thống phần mềm
UML cung cấp một cách tiêu chuẩn để vẽ các bản thiết kế của hệ thống gồm: quy trình kinh doanh, chức năng,thiết kế cụ thể(ngôn ngữ, cơ sở dữ liệu, phần có thể sử dụng lại)
UML là một công cụ ký hiệu thiết kế và phân tích hướng đối tượng, được sử dụng rộng rãi
UML có thể được sử dụng để: mô hình hóa vấn đề, mô tả các yêu cầu, xác định các yếu tố kiến trúc( lớp và các đối tượng), mô tả hành vi và tương tác giữa các thành phần, tổ chức cấu trúc phần mềm, chỉ định các ràng buộc,
UML cung cấp sơ đồ mô hình hóa được chia thành hai loại chính : cấu trúc (tĩnh) và hành vi (động)
cấu trúc (tĩnh): mô tả cấu trúc tĩnh của tất cả các thành phần phần mềm trong một hệ thống: phân cấp lớp, cấu trúc thư viện lớp và các mối quan hệ giữa các lớp như kế thừa , tổng hợp, liên kết
hành vi (động): mô tả hành vi của các đối tượng trong hệ thống như cộng tác đối tượng, tương tác, hoạt động và tương tranh
3.3 Architecture View Models
3.3.1 The Scenario View
mô tả chức năng của hệ thống, tức là cách người dùng sử dụng hệ thống và cách hệ thống cung cấp dịch vụ cho người dùng
ung cấp nền tảng cho bốn khung nhìn còn lại và cho phép chúng hoạt động liền mạch và mạch lạc
giúp làm cho kiến trúc phần mềm phù hợp với các yêu cầu chức năng và phi chức năng
Các bên liên quan của quan điểm này là người dùng cuối, kiến trúc sư, nhà phát triển và tất cả người dùng của bốn chế độ xem khác
3.3.2 The Logical or Conceptual View
dựa trên các thực thể miền ứng dụng cần thiết để thực hiện các yêu cầu chức năng
tập trung vào các yêu cầu chức năng, các khối xây dựng chính và trừu tượng hóa chính của hệ thống
là sự trừu tượng hóa các yêu cầu chức năng của hệ thống
hỗ trợ bởi các sơ đồ tĩnh UML bao gồm class/object diagrams và sơ đồ động UML như the interaction overall diagram, sequence diagram, communication diagram, state diagram, and activity diagram
chỉ ra tất cả các nhiệm vụ chính mà hệ thống phải hoàn thành và trình bày các thành phần chính và các mối quan hệ tĩnh của chúng
3.3.3 The Development or Module View
xuất phát từ khung nhìn logic và mô tả tổ chức tĩnh của các mô-đun hệ thống
Các mô-đun như không gian tên, thư viện lớp, hệ thống con hoặc gói đang xây dựng
Các sơ đồ UML như sơ đồ gói và sơ đồ thành phần thường được sử dụng để hỗ trợ cho quan điểm này
3.3.4 The Process View
tập trung vào các khía cạnh động của hệ thống, tức là hành vi thời gian thực hiện
xem xét các quy trình của hệ thống và thông tin liên lạc giữa chúng
Các thuộc tính chất lượng như hiệu suất, khả năng mở rộng, đồng thời, đồng bộ hóa, phân phối và thông lượng hệ thống đều được đề cập
xử lý các vấn đề đồng thời và đồng bộ hóa giữa các hệ thống con
cũng phải giải quyết các yêu cầu không chức năng như đa luồng và truyền thông đồng bộ / không đồng bộ về hiệu suất và tính khả dụng
hỗ trợ bởi activity diagram and interaction overview diagram
3.3.5 The Physical View
mô tả cài đặt, cấu hình và triển khai ứng dụng phần mềm.
cho thấy ánh xạ của phần mềm lên phần cứng
Nó đặc biệt quan tâm trong các hệ thống phân tán hoặc song song
Các thành phần là các thực thể phần cứng (bộ xử lý) và các liên kết là các đường truyền thông
cũng tính đến các yêu cầu không chức năng của hệ thống như tính khả dụng của hệ thống, độ tin cậy (khả năng chịu lỗi), hiệu suất thông lượng, hiệu suất khả năng mở rộng và bảo mật
giải quyết các kết nối mạng và giao thức truyền thông như các nút máy chủ và cấu hình môi trường phân tán nhiều tầng
được hỗ trợ bởi deployment diagrams
3.3.6 The User Interface View
là chế độ xem mở rộng cung cấp chế độ xem giao diện người dùng máy tính rõ ràng và ẩn chi tiết triển khai
có thể được cung cấp dưới dạng một loạt ảnh chụp màn hình hoặc bản thử nghiệm nguyên mẫu tương tác động
Mọi sửa đổi về quan điểm này sẽ có tác động trực tiếp đến the scenarios view
Một mô hình là một mô tả đầy đủ, đơn giản hóa của một hệ thống từ một quan điểm hoặc quan điểm cụ thể
View models cung cấp các biểu diễn một phần của kiến trúc phần mềm cho các bên liên quan cụ thể như người dùng hệ thống, nhà phân tích / nhà thiết kế, nhà phát triển / lập trình viên, nhà tích hợp hệ thống và kỹ sư hệ thống
4+1 view model là mô hình nhiều chế độ xem giải quyết các khía cạnh và mối quan tâm khác nhau của hệ thống bao gồm tất cả các khía cạnh của kiến trúc phần mềm cho tất cả các bên liên quan
3.4 Architecture Description Languages (ADL)
là một đặc tả ký hiệu cung cấp cú pháp và ngữ nghĩa để xác định kiến trúc phần mềm.
cung cấp cho các nhà thiết kế khả năng phân tách các thành phần,kết hợp các thành phần và xác định giao diện của các thành phần
à một ngôn ngữ đặc tả chính thức với cú pháp và ngữ nghĩa được xác định rõ được sử dụng để mô tả các thành phần kiến trúc và các kết nối, giao diện và cấu hình của chúng.
Garlan and Shaw (1996) đưa ra các yêu cầu cho ADL
Thành phần: mô tả một hệ thống là một thành phần của các thành phần và kết nối độc lập
Trừu tượng:Có thể mô tả các thành phần và tương tác của chúng theo cách mô tả vai trò trừu tượng của chúng
Tái sử dụng: Khả năng tái sử dụng nên được tích hợp ở cấp độ thành phần và kết nối
Cấu hình: Mô tả kiến trúc sẽ cho phép tính toán và sửa đổi kiến trúc mà không cần kiểm tra từng thành phần và đầu nối
Tính không đồng nhất: Có thể kết hợp nhiều mô tả kiến trúc không đồng nhất
Phân tích: Việc sử dụng ADL sẽ tạo điều kiện thuận lợi cho việc phân tích thiết kế kiến trúc