Mô hình kiến trúc
Kiến trúc phần mềm liên quan đến cấu trúc cấp cao của sự trừu tượng hóa hệ thống phần mềm, bằng cách sử dụng phân rã và thành phần, với phong cách kiến trúc và các thuộc tính chất lượng. Thiết kế kiến trúc phần mềm phải phù hợp với các yêu cầu về chức năng và hiệu suất chính của hệ thống, cũng như đáp ứng các yêu cầu phi chức năng như độ tin cậy, khả năng mở rộng, tính di động và tính khả dụng.
Một kiến trúc phần mềm phải mô tả nhóm các thành phần của nó, các kết nối của chúng, tương tác giữa chúng và cấu hình triển khai của tất cả các thành phần.
Một kiến trúc phần mềm có thể được định nghĩa theo nhiều cách -
UML (Unified Modeling Language) - UML là một trong những giải pháp hướng đối tượng được sử dụng trong mô hình hóa và thiết kế phần mềm.
Architecture View Model (4+1 view model) - Mô hình khung nhìn kiến trúc thể hiện các yêu cầu chức năng và phi chức năng của ứng dụng phần mềm.
ADL (Architecture Description Language) - ADL xác định kiến trúc phần mềm một cách chính thức và ngữ nghĩa.
UML
UML là viết tắt của Unified Modeling Language. Nó là một ngôn ngữ hình ảnh được sử dụng để tạo bản thiết kế phần mềm. UML được tạo ra bởi Nhóm Quản lý Đối tượng (OMG). Dự thảo đặc tả UML 1.0 đã được đề xuất cho OMG vào tháng 1 năm 1997. Nó được dùng như một tiêu chuẩn cho các tài liệu thiết kế và phân tích yêu cầu phần mềm, là cơ sở để phát triển một phần mềm.
UML có thể được mô tả như một ngôn ngữ mô hình trực quan có mục đích chung để hình dung, chỉ định, xây dựng và lập tài liệu cho một hệ thống phần mềm. Mặc dù UML thường được sử dụng để mô hình hóa hệ thống phần mềm, nhưng nó không bị giới hạn trong ranh giới này. Nó cũng được sử dụng để mô hình hóa các hệ thống không phải phần mềm như các luồng quy trình trong một đơn vị sản xuất.
Các phần tử giống như các thành phần có thể được liên kết theo những cách khác nhau để tạo nên một bức tranh UML hoàn chỉnh, được gọi là diagram. Vì vậy, điều rất quan trọng là phải hiểu các sơ đồ khác nhau để triển khai kiến thức trong các hệ thống thực tế. Chúng tôi có hai danh mục sơ đồ lớn và chúng được chia thành các danh mục phụ, tức làStructural Diagrams và Behavioral Diagrams.
Sơ đồ cấu trúc
Sơ đồ cấu trúc thể hiện các khía cạnh tĩnh của một hệ thống. Các khía cạnh tĩnh này đại diện cho các phần của một sơ đồ tạo thành cấu trúc chính và do đó ổn định.
Các phần tĩnh này được biểu diễn bằng các lớp, giao diện, đối tượng, thành phần và nút. Sơ đồ cấu trúc có thể được chia nhỏ như sau:
- Sơ đồ lớp
- Sơ đồ đối tượng
- Sơ đồ thành phần
- Sơ đồ triển khai
- Sơ đồ gói
- Cấu trúc tổng hợp
Bảng sau đây cung cấp mô tả ngắn gọn về các sơ đồ này:
| Sr.No. | Sơ đồ & Mô tả |
|---|---|
| 1 | Class Biểu diễn hướng đối tượng của một hệ thống. Hiển thị cách các lớp có liên quan tĩnh. |
| 2 | Object Đại diện cho một tập hợp các đối tượng và mối quan hệ của chúng trong thời gian chạy và cũng đại diện cho chế độ xem tĩnh của hệ thống. |
| 3 | Component Mô tả tất cả các thành phần, mối quan hệ qua lại của chúng, tương tác và giao diện của hệ thống. |
| 4 | Composite structure Mô tả cấu trúc bên trong của thành phần bao gồm tất cả các lớp, giao diện của thành phần, v.v. |
| 5 | Package Mô tả cấu trúc và tổ chức gói. Bao gồm các lớp trong gói và các gói trong gói khác. |
| 6 | Deployment Sơ đồ triển khai là một tập hợp các nút và mối quan hệ của chúng. Các nút này là các thực thể vật lý nơi các thành phần được triển khai. |
Sơ đồ hành vi
Sơ đồ hành vi về cơ bản nắm bắt khía cạnh động của một hệ thống. Các khía cạnh động về cơ bản là các phần thay đổi / chuyển động của một hệ thống. UML có các loại biểu đồ hành vi sau:
- Sử dụng sơ đồ trường hợp
- Biểu đồ trình tự
- Sơ đồ giao tiếp
- Biểu đồ trạng thái
- Sơ đồ hoạt động
- Tổng quan về tương tác
- Biểu đồ trình tự thời gian
Bảng sau đây cung cấp mô tả ngắn gọn về sơ đồ này:
| Sr.No. | Sơ đồ & Mô tả |
|---|---|
| 1 | Use case Mô tả mối quan hệ giữa các chức năng và bộ điều khiển bên trong / bên ngoài của chúng. Các bộ điều khiển này được gọi là các tác nhân. |
| 2 | Activity Mô tả luồng điều khiển trong hệ thống. Nó bao gồm các hoạt động và liên kết. Luồng có thể tuần tự, đồng thời hoặc phân nhánh. |
| 3 | State Machine/state chart Đại diện cho sự thay đổi trạng thái theo hướng sự kiện của một hệ thống. Về cơ bản, nó mô tả sự thay đổi trạng thái của một lớp, giao diện, v.v. Được sử dụng để hình dung phản ứng của một hệ thống bởi các yếu tố bên trong / bên ngoài. |
| 4 | Sequence Hình dung chuỗi lệnh gọi trong hệ thống để thực hiện một chức năng cụ thể. |
| 5 | Interaction Overview Kết hợp các biểu đồ trình tự và hoạt động để cung cấp tổng quan về luồng kiểm soát của hệ thống và quy trình kinh doanh. |
| 6 | Communication Tương tự như sơ đồ tuần tự, ngoại trừ việc nó tập trung vào vai trò của đối tượng. Mỗi giao tiếp được liên kết với một thứ tự tuần tự, số cộng với các tin nhắn trong quá khứ. |
| 7 | Time Sequenced Mô tả những thay đổi của thông báo trong trạng thái, điều kiện và sự kiện. |
Mô hình xem kiến trúc
Mô hình là một mô tả đầy đủ, cơ bản và đơn giản về kiến trúc phần mềm, bao gồm nhiều khung nhìn từ một góc nhìn hoặc góc nhìn cụ thể.
Một khung nhìn là một đại diện của toàn bộ hệ thống từ quan điểm của một nhóm các mối quan tâm có liên quan. Nó được sử dụng để mô tả hệ thống từ quan điểm của các bên liên quan khác nhau như người dùng cuối, nhà phát triển, người quản lý dự án và người kiểm tra.
Mô hình xem 4 + 1
Mô hình 4 + 1 View được Philippe Kruchten thiết kế để mô tả kiến trúc của một hệ thống chuyên sâu về phần mềm dựa trên việc sử dụng nhiều view và đồng thời. Nó là mộtmultiple viewmô hình giải quyết các tính năng và mối quan tâm khác nhau của hệ thống. Nó chuẩn hóa các tài liệu thiết kế phần mềm và làm cho thiết kế dễ hiểu đối với tất cả các bên liên quan.
Nó là một phương pháp xác minh kiến trúc để nghiên cứu và lập hồ sơ thiết kế kiến trúc phần mềm và 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. Nó cung cấp bốn quan điểm thiết yếu -
The logical view or conceptual view - Nó mô tả mô hình đối tượng của thiết kế.
The process view - Nó mô tả các hoạt động của hệ thống, nắm bắt các khía cạnh đồng thời và đồng bộ của thiết kế.
The physical view - Nó mô tả ánh xạ của phần mềm vào phần cứng và phản ánh khía cạnh phân tán của nó.
The development view - Nó mô tả tổ chức hoặc cấu trúc tĩnh của phần mềm trong môi trường phát triển của nó.
Mô hình chế độ xem này có thể được mở rộng bằng cách thêm một chế độ xem nữa được gọi là scenario view hoặc là use case viewcho người dùng cuối hoặc khách hàng của hệ thống phần mềm. Nó nhất quán với bốn chế độ xem khác và được sử dụng để minh họa kiến trúc đóng vai trò là chế độ xem “cộng một”, mô hình chế độ xem (4 + 1). Hình dưới đây mô tả kiến trúc phần mềm sử dụng mô hình năm khung nhìn đồng thời (4 + 1).
Tại sao nó được gọi là 4 + 1 thay vì 5?
Các use case viewcó một ý nghĩa đặc biệt vì nó nêu chi tiết yêu cầu cấp cao của một hệ thống trong khi các quan điểm khác trình bày chi tiết - cách các yêu cầu đó được thực hiện. Khi tất cả bốn chế độ xem khác được hoàn thành, nó thực sự dư thừa. Tuy nhiên, tất cả các quan điểm khác sẽ không thể thực hiện được nếu không có nó. Hình ảnh và bảng sau thể hiện chi tiết chế độ xem 4 + 1 -
| Hợp lý | Quá trình | Phát triển | Vật lý | Tình huống | |
|---|---|---|---|---|---|
| Sự miêu tả | Cho biết thành phần (Đối tượng) của hệ thống cũng như sự tương tác của chúng | Hiển thị các quy trình / Quy tắc quy trình làm việc của hệ thống và cách các quy trình đó giao tiếp, tập trung vào chế độ xem động của hệ thống | Cung cấp các khung nhìn khối xây dựng của hệ thống và mô tả tổ chức tĩnh của các mô-đun hệ thống | Hiển thị cài đặt, cấu hình và triển khai ứng dụng phần mềm | Cho thấy thiết kế đã hoàn chỉnh bằng cách thực hiện xác nhận và minh họa |
| Người xem / Người giữ tiền đặt cọc | Người dùng cuối, Nhà phân tích và Nhà thiết kế | Người tích hợp và nhà phát triển | Lập trình viên và quản lý dự án phần mềm | Kỹ sư hệ thống, người vận hành, quản trị viên hệ thống và người cài đặt hệ thống | Tất cả các quan điểm của quan điểm và người đánh giá của họ |
| Xem xét | Yêu cầu chức năng | Những yêu cầu phi lý | Tổ chức mô-đun phần mềm (Tái sử dụng quản lý phần mềm, ràng buộc của các công cụ) | Yêu cầu phi chức năng liên quan đến phần cứng cơ bản | Tính nhất quán và hiệu lực của hệ thống |
| UML - Sơ đồ | Lớp, Trạng thái, Đối tượng, trình tự, Sơ đồ truyền thông | Sơ đồ hoạt động | Sơ đồ thành phần, gói | Sơ đồ triển khai | Sử dụng sơ đồ trường hợp |
Ngôn ngữ mô tả kiến trúc (ADL)
ADL là một ngôn ngữ cung cấp cú pháp và ngữ nghĩa để xác định kiến trúc phần mềm. Nó là một đặc tả ký hiệu cung cấp các tính năng để mô hình hóa kiến trúc khái niệm của hệ thống phần mềm, phân biệt với việc triển khai hệ thống.
ADL phải hỗ trợ các thành phần kiến trúc, các kết nối, giao diện và cấu hình của chúng là khối xây dựng của mô tả kiến trúc. Nó là một dạng biểu thức để sử dụng trong mô tả kiến trúc và cung cấp khả năng phân hủy 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.
Ngôn ngữ mô tả kiến trúc là một ngôn ngữ đặc tả chính thức, nó mô tả các tính năng phần mềm như quy trình, luồng, dữ liệu và chương trình con cũng như thành phần phần cứng như bộ xử lý, thiết bị, bus và bộ nhớ.
Thật khó để phân loại hoặc phân biệt ADL và ngôn ngữ lập trình hoặc ngôn ngữ mô hình hóa. Tuy nhiên, có các yêu cầu sau để một ngôn ngữ được phân loại là ADL -
Nó phải phù hợp để truyền đạt kiến trúc cho tất cả các bên liên quan.
Nó phải phù hợp cho các nhiệm vụ tạo, tinh chỉnh và xác nhận kiến trúc.
Nó phải cung cấp cơ sở để thực hiện thêm, vì vậy nó phải có khả năng thêm thông tin vào đặc tả ADL để cho phép đặc tả hệ thống cuối cùng được lấy từ ADL.
Nó phải có khả năng đại diện cho hầu hết các phong cách kiến trúc thông thường.
Nó phải hỗ trợ khả năng phân tích hoặc cung cấp các triển khai nguyên mẫu nhanh chóng.