Hướng dẫn nhanh

Kiến trúc của một hệ thống mô tả các thành phần chính của nó, các mối quan hệ (cấu trúc) của chúng và cách chúng tương tác với nhau. Kiến trúc và thiết kế phần mềm bao gồm một số yếu tố đóng góp như Chiến lược kinh doanh, thuộc tính chất lượng, động lực con người, thiết kế và môi trường CNTT.

Chúng ta có thể tách Kiến trúc phần mềm và Thiết kế thành hai giai đoạn riêng biệt: Kiến trúc phần mềm và Thiết kế phần mềm. TrongArchitecture, các quyết định phi chức năng được đúc kết và tách biệt bởi các yêu cầu chức năng. Trong Thiết kế, các yêu cầu chức năng được hoàn thành.

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

Kiến trúc phục vụ như một blueprint for a system. Nó cung cấp một sự trừu tượng để quản lý độ phức tạp của hệ thống và thiết lập cơ chế giao tiếp và phối hợp giữa các thành phần.

• Nó xác định một structured solution để đáp ứng tất cả các yêu cầu kỹ thuật và vận hành, đồng thời tối ưu hóa các thuộc tính chất lượng chung như hiệu suất và bảo mật.

• Hơn nữa, nó liên quan đến một tập hợp các quyết định quan trọng về tổ chức liên quan đến phát triển phần mềm và mỗi quyết định này có thể có tác động đáng kể đến chất lượng, khả năng bảo trì, hiệu suất và sự thành công chung của sản phẩm cuối cùng. Những quyết định này bao gồm -

  • Lựa chọn các phần tử cấu trúc và các giao diện của chúng mà hệ thống được cấu thành.

  • Hành vi như được chỉ định trong sự hợp tác giữa các yếu tố đó.

  • Thành phần của các yếu tố cấu trúc và hành vi này thành hệ thống con lớn.

  • Các quyết định về kiến ​​trúc phù hợp với các mục tiêu kinh doanh.

  • Phong cách kiến ​​trúc hướng dẫn tổ chức.

Thiết kế phần mềm

Thiết kế phần mềm cung cấp một design planmô tả các phần tử của hệ thống, cách chúng phù hợp và làm việc cùng nhau để đáp ứng yêu cầu của hệ thống. Các mục tiêu của việc có một kế hoạch thiết kế như sau:

• Để thương lượng các yêu cầu hệ thống và đặt kỳ vọng với khách hàng, nhân viên tiếp thị và quản lý.

• Hoạt động như một bản thiết kế trong quá trình phát triển.

• Hướng dẫn các tác vụ triển khai, bao gồm thiết kế chi tiết, mã hóa, tích hợp và thử nghiệm.

Nó xảy ra trước khi thiết kế chi tiết, mã hóa, tích hợp và thử nghiệm và sau khi phân tích miền, phân tích yêu cầu và phân tích rủi ro.

Mục tiêu của Kiến trúc

Mục tiêu chính của kiến ​​trúc là xác định các yêu cầu ảnh hưởng đến cấu trúc của ứng dụng. Một kiến ​​trúc được bố trí tốt sẽ giảm rủi ro kinh doanh liên quan đến việc xây dựng giải pháp kỹ thuật và xây dựng cầu nối giữa yêu cầu kinh doanh và kỹ thuật.

Một số mục tiêu khác như sau:

• Tiết lộ cấu trúc của hệ thống, nhưng ẩn chi tiết triển khai của nó.

• Nhận ra tất cả các trường hợp sử dụng và tình huống.

• Cố gắng giải quyết các yêu cầu của các bên liên quan khác nhau.

• Xử lý cả các yêu cầu về chức năng và chất lượng.

• Giảm mục tiêu sở hữu và nâng cao vị thế thị trường của tổ chức.

• Cải thiện chất lượng và chức năng do hệ thống cung cấp.

• Nâng cao lòng tin từ bên ngoài vào tổ chức hoặc hệ thống.

Hạn chế

Kiến trúc phần mềm vẫn là một ngành học mới nổi trong ngành kỹ thuật phần mềm. Nó có những hạn chế sau:

• Thiếu các công cụ và cách thức tiêu chuẩn hóa để biểu diễn kiến ​​trúc.

• Thiếu các phương pháp phân tích để dự đoán liệu kiến ​​trúc có dẫn đến việc triển khai đáp ứng các yêu cầu hay không.

• Thiếu nhận thức về tầm quan trọng của thiết kế kiến ​​trúc đối với phát triển phần mềm.

• Thiếu hiểu biết về vai trò của kiến ​​trúc sư phần mềm và giao tiếp kém giữa các bên liên quan.

• Thiếu hiểu biết về quy trình thiết kế, kinh nghiệm thiết kế và đánh giá thiết kế.

Vai trò của Kiến trúc sư phần mềm

Kiến trúc sư phần mềm cung cấp giải pháp mà nhóm kỹ thuật có thể tạo và thiết kế cho toàn bộ ứng dụng. Một kiến ​​trúc sư phần mềm nên có chuyên môn trong các lĩnh vực sau:

Chuyên môn thiết kế

• Chuyên gia về thiết kế phần mềm, bao gồm các phương pháp và cách tiếp cận đa dạng như thiết kế hướng đối tượng, thiết kế hướng sự kiện, v.v.

• Lãnh đạo nhóm phát triển và điều phối các nỗ lực phát triển vì tính toàn vẹn của thiết kế.

• Nên có thể xem xét các đề xuất thiết kế và đánh đổi giữa chúng.

Chuyên môn về miền

• Chuyên gia về hệ thống đang được phát triển và lập kế hoạch phát triển phần mềm.

• Hỗ trợ trong quá trình điều tra yêu cầu, đảm bảo tính đầy đủ và nhất quán.

• Phối hợp định nghĩa mô hình miền cho hệ thống đang được phát triển.

Chuyên môn công nghệ

• Chuyên gia về các công nghệ sẵn có giúp triển khai hệ thống.

• Phối hợp lựa chọn ngôn ngữ lập trình, khuôn khổ, nền tảng, cơ sở dữ liệu, v.v.

Chuyên môn phương pháp

• Chuyên gia về các phương pháp luận phát triển phần mềm có thể được áp dụng trong SDLC (Vòng đời phát triển phần mềm).

• Chọn các cách tiếp cận thích hợp để phát triển giúp ích cho toàn bộ nhóm.

Vai trò tiềm ẩn của kiến ​​trúc sư phần mềm

• Tạo điều kiện thuận lợi cho công việc kỹ thuật giữa các thành viên trong nhóm và củng cố mối quan hệ tin cậy trong nhóm.

• Chuyên gia thông tin chia sẻ kiến ​​thức và có nhiều kinh nghiệm.

• Bảo vệ các thành viên trong nhóm khỏi các lực lượng bên ngoài có thể làm họ phân tâm và mang lại ít giá trị hơn cho dự án.

Sản phẩm của Kiến trúc sư

• Một tập hợp các mục tiêu chức năng rõ ràng, đầy đủ, nhất quán và có thể đạt được

• Mô tả chức năng của hệ thống, với ít nhất hai lớp phân hủy

• Một khái niệm cho hệ thống

• Một thiết kế dưới dạng hệ thống, với ít nhất hai lớp phân hủy

• Khái niệm về thời gian, các thuộc tính của nhà điều hành và các kế hoạch thực hiện và hoạt động

• Một tài liệu hoặc quy trình đảm bảo tuân theo sự phân rã chức năng và hình thức giao diện được kiểm soát

Thuộc tính chất lượng

Chất lượng là thước đo sự xuất sắc hoặc trạng thái không có thiếu sót hoặc khuyết tật. Thuộc tính chất lượng là các thuộc tính của hệ thống tách biệt với chức năng của hệ thống.

Việc triển khai các thuộc tính chất lượng giúp dễ dàng phân biệt hệ thống tốt với hệ thống xấu. Thuộc tính là các yếu tố tổng thể ảnh hưởng đến hành vi thời gian chạy, thiết kế hệ thống và trải nghiệm người dùng.

Chúng có thể được phân loại là -

Thuộc tính chất lượng tĩnh

Phản ánh cấu trúc của một hệ thống và tổ chức, liên quan trực tiếp đến kiến ​​trúc, thiết kế và mã nguồn. Chúng vô hình đối với người dùng cuối, nhưng ảnh hưởng đến chi phí phát triển và bảo trì, ví dụ: tính mô-đun, khả năng kiểm tra, khả năng bảo trì, v.v.

Thuộc tính chất lượng động

Phản ánh hành vi của hệ thống trong quá trình thực thi. Chúng liên quan trực tiếp đến kiến ​​trúc, thiết kế, mã nguồn, cấu hình, tham số triển khai, môi trường và nền tảng của hệ thống.

Chúng được hiển thị cho người dùng cuối và tồn tại trong thời gian chạy, ví dụ như thông lượng, độ mạnh mẽ, khả năng mở rộng, v.v.

Kịch bản chất lượng

Các kịch bản chất lượng chỉ rõ cách ngăn lỗi trở thành lỗi. Chúng có thể được chia thành sáu phần dựa trên đặc điểm thuộc tính của chúng -

• Source - Một thực thể bên trong hoặc bên ngoài như con người, phần cứng, phần mềm hoặc cơ sở hạ tầng vật chất tạo ra tác nhân kích thích.

• Stimulus - Một điều kiện cần được xem xét khi nó xuất hiện trên một hệ thống.

• Environment - Kích thích xảy ra trong những điều kiện nhất định.

• Artifact - Toàn bộ hệ thống hoặc một số phần của nó như bộ xử lý, kênh giao tiếp, lưu trữ liên tục, quy trình, v.v.

• Response - Một hoạt động được thực hiện sau khi có kích thích như phát hiện lỗi, khôi phục lỗi, vô hiệu hóa nguồn sự kiện, v.v.

• Response measure - Nên đo lường các phản ứng đã xảy ra để có thể kiểm tra các yêu cầu.

Các thuộc tính chất lượng chung

Bảng sau liệt kê các thuộc tính chất lượng phổ biến mà kiến ​​trúc phần mềm phải có:

thể loại	Thuộc tính chất lượng	Sự miêu tả
Chất lượng thiết kế	Tính toàn vẹn về khái niệm	Xác định tính nhất quán và mạch lạc của thiết kế tổng thể. Điều này bao gồm cách các thành phần hoặc mô-đun được thiết kế.
	Khả năng bảo trì	Khả năng của hệ thống để trải qua những thay đổi với mức độ dễ dàng.
	Khả năng tái sử dụng	Xác định khả năng cho các thành phần và hệ thống con phù hợp để sử dụng trong các ứng dụng khác.
Chất lượng thời gian chạy	Khả năng tương tác	Khả năng của một hệ thống hoặc các hệ thống khác nhau hoạt động thành công bằng cách giao tiếp và trao đổi thông tin với các hệ thống bên ngoài khác do các bên bên ngoài viết và điều hành.
	Khả năng quản lý	Xác định mức độ dễ dàng của quản trị viên hệ thống trong việc quản lý ứng dụng.
	độ tin cậy	Khả năng của một hệ thống để duy trì hoạt động theo thời gian.
	Khả năng mở rộng	Khả năng của một hệ thống để xử lý việc tăng tải mà không ảnh hưởng đến hiệu suất của hệ thống hoặc khả năng dễ dàng được mở rộng.
	Bảo vệ	Khả năng của một hệ thống để ngăn chặn các hành động độc hại hoặc ngẫu nhiên bên ngoài cách sử dụng được thiết kế.
	Hiệu suất	Cho biết khả năng đáp ứng của hệ thống để thực hiện bất kỳ hành động nào trong một khoảng thời gian nhất định.
	khả dụng	Xác định tỷ lệ thời gian mà hệ thống hoạt động và hoạt động. Nó có thể được đo dưới dạng phần trăm tổng thời gian ngừng hoạt động của hệ thống trong một khoảng thời gian xác định trước.
Chất lượng hệ thống	Khả năng hỗ trợ	Khả năng của hệ thống cung cấp thông tin hữu ích cho việc xác định và giải quyết các vấn đề khi hệ thống không hoạt động chính xác.
	Khả năng kiểm tra	Đo lường mức độ dễ dàng tạo ra các tiêu chí kiểm tra cho hệ thống và các thành phần của nó.
Phẩm chất người dùng	Khả năng sử dụng	Xác định mức độ ứng dụng đáp ứng các yêu cầu của người dùng và người tiêu dùng bằng cách trực quan.
Chất lượng kiến ​​trúc	Tính đúng đắn	Trách nhiệm giải trình để đáp ứng tất cả các yêu cầu của hệ thống.
Chất lượng không thời gian chạy	Tính di động	Khả năng của hệ thống chạy trong các môi trường điện toán khác nhau.
	Tính chính trực	Khả năng làm cho các thành phần được phát triển riêng biệt của hệ thống hoạt động chính xác với nhau.
	Khả năng sửa đổi	Dễ dàng mà mỗi hệ thống phần mềm có thể đáp ứng các thay đổi đối với phần mềm của nó.
Thuộc tính chất lượng kinh doanh	Chi phí và lịch trình	Chi phí của hệ thống liên quan đến thời gian đưa ra thị trường, thời gian tồn tại của dự án và việc sử dụng di sản.
	Khả năng tiếp thị	Sử dụng hệ thống liên quan đến cạnh tranh thị trường.

Kiến trúc phần mềm được mô tả như là tổ chức của một hệ thống, trong đó hệ thống đại diện cho một tập hợp các thành phần hoàn thành các chức năng đã xác định.

Phong cách kiến ​​trúc

Các architectural style, còn được gọi là architectural pattern, là một tập hợp các nguyên tắc định hình một ứng dụng. Nó xác định một khuôn khổ trừu tượng cho một họ hệ thống về mô hình tổ chức cấu trúc.

Phong cách kiến ​​trúc có trách nhiệm -

• Cung cấp từ vựng về các thành phần và trình kết nối với các quy tắc về cách chúng có thể được kết hợp.

• Cải thiện việc phân vùng và cho phép sử dụng lại thiết kế bằng cách đưa ra các giải pháp cho các vấn đề thường xuyên xảy ra.

• Mô tả một cách cụ thể để định cấu hình tập hợp các thành phần (một mô-đun có giao diện được xác định rõ, có thể tái sử dụng và có thể thay thế) và các đầu nối (liên kết giao tiếp giữa các mô-đun).

Phần mềm được xây dựng cho các hệ thống dựa trên máy tính thể hiện một trong nhiều phong cách kiến ​​trúc. Mỗi kiểu mô tả một danh mục hệ thống bao gồm:

• Một tập hợp các loại thành phần thực hiện một chức năng yêu cầu của hệ thống.

• Một tập hợp các trình kết nối (lệnh gọi chương trình con, lệnh gọi thủ tục từ xa, luồng dữ liệu và ổ cắm) cho phép giao tiếp, phối hợp và hợp tác giữa các thành phần khác nhau.

• Các ràng buộc ngữ nghĩa xác định cách các thành phần có thể được tích hợp để tạo thành hệ thống.

• Bố cục cấu trúc liên kết của các thành phần chỉ ra mối quan hệ qua lại trong thời gian chạy của chúng.

Thiết kế kiến ​​trúc chung

Bảng sau liệt kê các kiểu kiến ​​trúc có thể được sắp xếp theo khu vực trọng tâm chính của chúng:

thể loại	Thiết kế kiến ​​trúc	Sự miêu tả
Giao tiếp	Xe buýt tin nhắn	Quy định việc sử dụng một hệ thống phần mềm có thể nhận và gửi tin nhắn bằng một hoặc nhiều kênh liên lạc.
	Kiến trúc hướng dịch vụ (SOA)	Xác định các ứng dụng hiển thị và sử dụng chức năng như một dịch vụ bằng cách sử dụng hợp đồng và tin nhắn.
Triển khai	Máy khách / máy chủ	Tách hệ thống thành hai ứng dụng, nơi máy khách thực hiện các yêu cầu đến máy chủ.
	3 bậc hoặc N-tier	Tách chức năng thành các phân đoạn riêng biệt với mỗi phân đoạn là một cấp nằm trên một máy tính vật lý riêng biệt.
Miền	Thiết kế theo hướng miền	Tập trung vào việc lập mô hình miền kinh doanh và xác định đối tượng kinh doanh dựa trên các thực thể trong miền kinh doanh.
Kết cấu	Dựa trên thành phần	Chia nhỏ thiết kế ứng dụng thành các thành phần chức năng hoặc logic có thể tái sử dụng để hiển thị các giao diện truyền thông được xác định rõ ràng.
	Nhiều lớp	Chia các mối quan tâm của ứng dụng thành các nhóm (lớp) xếp chồng lên nhau.
	Hướng đối tượng	Dựa trên việc phân chia trách nhiệm của một ứng dụng hoặc hệ thống thành các đối tượng, mỗi đối tượng chứa dữ liệu và hành vi liên quan đến đối tượng.

Các loại kiến ​​trúc

Có bốn loại kiến ​​trúc theo quan điểm của một doanh nghiệp và gọi chung, những kiến ​​trúc này được gọi là enterprise architecture.

• Business architecture - Xác định chiến lược kinh doanh, quản trị, tổ chức và các quy trình kinh doanh chính trong doanh nghiệp và tập trung vào việc phân tích và thiết kế các quy trình kinh doanh.

• Application (software) architecture - Đóng vai trò là bản thiết kế cho các hệ thống ứng dụng riêng lẻ, các tương tác của chúng và mối quan hệ của chúng với các quy trình kinh doanh của tổ chức.

• Information architecture - Xác định tài sản dữ liệu logic và vật lý và tài nguyên quản lý dữ liệu.

• Information technology (IT) architecture - Xác định các khối xây dựng phần cứng và phần mềm tạo nên hệ thống thông tin tổng thể của tổ chức.

Quy trình thiết kế kiến ​​trúc

Quá trình thiết kế kiến ​​trúc tập trung vào việc phân rã hệ thống thành các thành phần khác nhau và sự tương tác của chúng để thỏa mãn các yêu cầu chức năng và phi chức năng. Các yếu tố đầu vào quan trọng để thiết kế kiến ​​trúc phần mềm là:

• Các yêu cầu do các nhiệm vụ phân tích tạo ra.

• Kiến trúc phần cứng (kiến trúc phần mềm lần lượt cung cấp các yêu cầu cho kiến ​​trúc sư hệ thống, người cấu hình kiến ​​trúc phần cứng).

Kết quả hoặc đầu ra của quá trình thiết kế kiến ​​trúc là một architectural description. Quy trình thiết kế kiến ​​trúc cơ bản bao gồm các bước sau:

Hiểu vấn đề

• Đây là bước quan trọng nhất vì nó ảnh hưởng đến chất lượng của thiết kế sau đó.

• Nếu không hiểu rõ vấn đề thì không thể tạo ra giải pháp hữu hiệu.

• Nhiều dự án và sản phẩm phần mềm bị coi là thất bại vì chúng không thực sự giải quyết được vấn đề kinh doanh hợp lệ hoặc có lợi tức đầu tư (ROI) dễ nhận biết.

Xác định các yếu tố thiết kế và mối quan hệ của chúng

• Trong giai đoạn này, hãy xây dựng đường cơ sở để xác định ranh giới và bối cảnh của hệ thống.

• Phân rã hệ thống thành các thành phần chính của nó dựa trên các yêu cầu chức năng. Sự phân rã có thể được mô hình hóa bằng cách sử dụng ma trận cấu trúc thiết kế (DSM), cho thấy sự phụ thuộc giữa các phần tử thiết kế mà không chỉ rõ mức độ chi tiết của các phần tử.

• Trong bước này, xác nhận đầu tiên của kiến ​​trúc được thực hiện bằng cách mô tả một số trường hợp hệ thống và bước này được gọi là thiết kế kiến ​​trúc dựa trên chức năng.

Đánh giá thiết kế kiến ​​trúc

• Mỗi thuộc tính chất lượng được đưa ra một ước tính để thu thập các thước đo định tính hoặc dữ liệu định lượng, thiết kế được đánh giá.

• Nó liên quan đến việc đánh giá kiến ​​trúc về sự phù hợp với các yêu cầu thuộc tính chất lượng kiến ​​trúc.

• Nếu tất cả các thuộc tính chất lượng ước tính đều theo tiêu chuẩn yêu cầu thì quá trình thiết kế kiến ​​trúc đã kết thúc.

• Nếu không, giai đoạn thứ ba của thiết kế kiến ​​trúc phần mềm được đưa vào: chuyển đổi kiến ​​trúc. Nếu thuộc tính chất lượng quan sát được không đáp ứng yêu cầu của nó, thì một thiết kế mới phải được tạo ra.

Chuyển đổi thiết kế kiến ​​trúc

• Bước này được thực hiện sau khi thẩm định thiết kế kiến ​​trúc. Thiết kế kiến ​​trúc phải được thay đổi cho đến khi hoàn toàn thoả mãn các yêu cầu thuộc tính chất lượng.

• Nó liên quan đến việc lựa chọn các giải pháp thiết kế để cải thiện các thuộc tính chất lượng trong khi vẫn duy trì chức năng miền.

• Một thiết kế được biến đổi bằng cách áp dụng các toán tử, kiểu hoặc mẫu thiết kế. Để chuyển đổi, hãy lấy thiết kế hiện có và áp dụng toán tử thiết kế như phân rã, sao chép, nén, trừu tượng và chia sẻ tài nguyên.

• Thiết kế được đánh giá một lần nữa và quá trình tương tự được lặp lại nhiều lần nếu cần thiết và thậm chí được thực hiện một cách đệ quy.

• Các chuyển đổi (tức là các giải pháp tối ưu hóa thuộc tính chất lượng) thường cải thiện một hoặc một số thuộc tính chất lượng trong khi chúng ảnh hưởng tiêu cực đến những thuộc tính khác

Nguyên tắc kiến ​​trúc chính

Sau đây là các nguyên tắc chính cần được xem xét khi thiết kế kiến ​​trúc:

Xây dựng để thay đổi thay vì xây dựng để cuối cùng

Xem xét cách ứng dụng có thể cần thay đổi theo thời gian để giải quyết các yêu cầu và thách thức mới, đồng thời xây dựng tính linh hoạt để hỗ trợ điều này.

Giảm rủi ro và mô hình để phân tích

Sử dụng các công cụ thiết kế, hình ảnh hóa, hệ thống mô hình hóa như UML để nắm bắt các yêu cầu và quyết định thiết kế. Các tác động cũng có thể được phân tích. Không chính thức hóa mô hình đến mức nó ngăn cản khả năng lặp lại và điều chỉnh thiết kế một cách dễ dàng.

Sử dụng Mô hình và Hình ảnh hóa làm Công cụ Giao tiếp và Cộng tác

Giao tiếp hiệu quả về thiết kế, các quyết định và những thay đổi liên tục đối với thiết kế là rất quan trọng đối với kiến ​​trúc tốt. Sử dụng mô hình, khung nhìn và các hình ảnh trực quan khác về kiến ​​trúc để giao tiếp và chia sẻ thiết kế một cách hiệu quả với tất cả các bên liên quan. Điều này cho phép liên lạc nhanh chóng về các thay đổi đối với thiết kế.

Xác định và hiểu các quyết định kỹ thuật quan trọng và các lĩnh vực thường mắc sai lầm nhất. Đầu tư vào việc đưa ra các quyết định quan trọng ngay lần đầu tiên để làm cho thiết kế trở nên linh hoạt hơn và ít có khả năng bị phá vỡ bởi những thay đổi.

Sử dụng phương pháp tiếp cận tăng dần và lặp lại

Bắt đầu với kiến ​​trúc đường cơ sở và sau đó phát triển các kiến ​​trúc ứng viên bằng cách thử nghiệm lặp đi lặp lại để cải thiện kiến ​​trúc. Lặp lại thêm các chi tiết vào thiết kế qua nhiều lần để có được bức tranh lớn hoặc đúng và sau đó tập trung vào các chi tiết.

Nguyên tắc thiết kế chính

Sau đây là các nguyên tắc thiết kế được xem xét để giảm thiểu chi phí, yêu cầu bảo trì và tối đa hóa khả năng mở rộng, khả năng sử dụng của kiến ​​trúc -

Tách các mối quan tâm

Chia các thành phần của hệ thống thành các tính năng cụ thể để không có sự chồng chéo giữa các chức năng thành phần. Điều này sẽ mang lại sự gắn kết cao và khả năng ghép nối thấp. Cách tiếp cận này tránh được sự phụ thuộc lẫn nhau giữa các thành phần của hệ thống, giúp dễ dàng bảo trì hệ thống.

Nguyên tắc trách nhiệm đơn lẻ

Mỗi và mọi mô-đun của hệ thống phải có một trách nhiệm cụ thể, giúp người dùng hiểu rõ hệ thống. Nó cũng sẽ giúp tích hợp thành phần với các thành phần khác.

Nguyên tắc Kiến thức Ít nhất

Bất kỳ thành phần hoặc đối tượng nào không được có kiến ​​thức về các chi tiết bên trong của các thành phần khác. Cách tiếp cận này tránh phụ thuộc lẫn nhau và giúp khả năng bảo trì.

Giảm thiểu thiết kế lớn trả trước

Giảm thiểu thiết kế lớn trả trước nếu yêu cầu của ứng dụng không rõ ràng. Nếu có khả năng sửa đổi các yêu cầu, thì tránh thiết kế lớn cho toàn bộ hệ thống.

Không lặp lại chức năng

Chức năng không lặp lại quy định rằng chức năng của các thành phần không được lặp lại và do đó một đoạn mã chỉ nên được triển khai trong một thành phần. Việc trùng lặp chức năng trong một ứng dụng có thể gây khó khăn cho việc triển khai các thay đổi, giảm độ rõ ràng và tạo ra các mâu thuẫn tiềm ẩn.

Ưu tiên Sáng tác hơn Kế thừa trong khi Sử dụng lại Chức năng

Kế thừa tạo ra sự phụ thuộc giữa các lớp con và lớp cha và do đó nó chặn việc sử dụng miễn phí các lớp con. Ngược lại, thành phần cung cấp một mức độ tự do lớn và giảm phân cấp kế thừa.

Xác định các thành phần và nhóm chúng trong các lớp logic

Các thành phần nhận dạng và lĩnh vực quan tâm cần thiết trong hệ thống để thỏa mãn các yêu cầu. Sau đó, nhóm các thành phần liên quan này trong một lớp logic, điều này sẽ giúp người dùng hiểu cấu trúc của hệ thống ở mức cao. Tránh trộn các thành phần của các loại mối quan tâm khác nhau trong cùng một lớp.

Xác định giao thức giao tiếp giữa các lớp

Hiểu cách các thành phần sẽ giao tiếp với nhau, điều này đòi hỏi kiến ​​thức đầy đủ về các kịch bản triển khai và môi trường sản xuất.

Xác định định dạng dữ liệu cho một lớp

Các thành phần khác nhau sẽ tương tác với nhau thông qua định dạng dữ liệu. Không trộn lẫn các định dạng dữ liệu để các ứng dụng dễ triển khai, mở rộng và duy trì. Cố gắng giữ nguyên định dạng dữ liệu cho một lớp để các thành phần khác nhau không cần mã / giải mã dữ liệu trong khi giao tiếp với nhau. Nó làm giảm chi phí xử lý.

Các thành phần dịch vụ hệ thống phải là trừu tượng

Mã liên quan đến bảo mật, truyền thông hoặc các dịch vụ hệ thống như ghi nhật ký, lập hồ sơ và cấu hình phải được tóm tắt trong các thành phần riêng biệt. Không trộn mã này với logic nghiệp vụ, vì nó rất dễ mở rộng thiết kế và duy trì nó.

Thiết kế ngoại lệ và cơ chế xử lý ngoại lệ

Xác định trước các ngoại lệ, giúp các thành phần quản lý lỗi hoặc tình huống không mong muốn một cách thanh lịch. Việc quản lý ngoại lệ sẽ giống nhau trong toàn bộ hệ thống.

Quy ước đặt tên

Quy ước đặt tên nên được xác định trước. Họ cung cấp một mô hình nhất quán giúp người dùng hiểu hệ thống một cách dễ dàng. Các thành viên trong nhóm sẽ dễ dàng xác nhận mã do người khác viết hơn và do đó sẽ tăng khả năng bảo trì.

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, việc hiểu các sơ đồ khác nhau để triển khai kiến ​​thức trong các hệ thống thực tế là rất quan trọng. 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 đại diện cho 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 đại diện bởi 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à các 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

Biểu đồ 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 Biểu diễn sự thay đổi trạng thái theo hướng sự kiện của 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 thử nghiệm.

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ó trình bày chi tiết yêu cầu cấp cao của một hệ thống trong khi các chế độ xem khác nêu 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ữ cổ phần	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ỹ thuật 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 rã các thành phần, kết hợp các thành phần và xác định các 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ó những 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 bổ sung 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 tạo nhanh chóng.

Mô hình hướng đối tượng (OO) hình thành từ khái niệm ban đầu về cách tiếp cận lập trình mới, trong khi sự quan tâm đến các phương pháp thiết kế và phân tích đến sau này. Mô hình phân tích và thiết kế OO là kết quả hợp lý của việc áp dụng rộng rãi các ngôn ngữ lập trình OO.

• Ngôn ngữ hướng đối tượng đầu tiên là Simula (Mô phỏng các hệ thống thực) được phát triển vào năm 1960 bởi các nhà nghiên cứu tại Trung tâm Máy tính Na Uy.

• Năm 1970, Alan Kay và nhóm nghiên cứu của ông tại Xerox PARC đã tạo ra một máy tính cá nhân có tên Dynabook và ngôn ngữ lập trình hướng đối tượng thuần túy đầu tiên (OOPL) - Smalltalk, để lập trình Dynabook.

• Trong những năm 1980, Grady Boochđã xuất bản một bài báo có tiêu đề Thiết kế hướng đối tượng chủ yếu trình bày một thiết kế cho ngôn ngữ lập trình, Ada. Trong các ấn bản tiếp theo, ông đã mở rộng ý tưởng của mình thành một phương pháp thiết kế hướng đối tượng hoàn chỉnh.

• Trong những năm 1990, Coad kết hợp ý tưởng hành vi với phương pháp hướng đối tượng.

Những đổi mới quan trọng khác là Kỹ thuật tạo mô hình đối tượng (OMT) của James Rum Baugh và Kỹ thuật phần mềm hướng đối tượng (OOSE) bởi Ivar Jacobson.

Giới thiệu về Mô hình OO

Mô hình OO là một phương pháp luận quan trọng cho sự phát triển của bất kỳ phần mềm nào. Hầu hết các kiểu hoặc mẫu kiến ​​trúc như đường ống và bộ lọc, kho lưu trữ dữ liệu và dựa trên thành phần có thể được triển khai bằng cách sử dụng mô hình này.

Các khái niệm và thuật ngữ cơ bản của hệ thống hướng đối tượng -

Vật

Đối tượng là một phần tử thế giới thực trong môi trường hướng đối tượng có thể tồn tại vật chất hoặc khái niệm. Mỗi đối tượng có -

• Nhận dạng để phân biệt nó với các đối tượng khác trong hệ thống.

• Trạng thái xác định các thuộc tính đặc trưng của một đối tượng cũng như các giá trị của các thuộc tính mà đối tượng đó nắm giữ.

• Hành vi thể hiện các hoạt động có thể nhìn thấy bên ngoài được thực hiện bởi một đối tượng trong điều kiện thay đổi trạng thái của nó.

Các đối tượng có thể được mô hình hóa theo nhu cầu của ứng dụng. Một đối tượng có thể tồn tại vật chất, như khách hàng, ô tô, v.v.; hoặc một tồn tại khái niệm vô hình, như một dự án, một quy trình, v.v.

Lớp học

Một lớp đại diện cho một tập hợp các đối tượng có cùng các thuộc tính đặc trưng thể hiện hành vi chung. Nó cung cấp bản thiết kế hoặc mô tả các đối tượng có thể được tạo ra từ nó. Việc tạo một đối tượng với tư cách là một thành viên của một lớp được gọi là khởi tạo. Do đó, một đối tượng là mộtinstance của một lớp.

Các thành phần của một lớp là -

• Một tập hợp các thuộc tính cho các đối tượng sẽ được khởi tạo từ lớp. Nói chung, các đối tượng khác nhau của một lớp có một số khác biệt về giá trị của các thuộc tính. Các thuộc tính thường được gọi là dữ liệu lớp.

• Một tập hợp các hoạt động mô tả hành vi của các đối tượng của lớp. Các phép toán cũng được gọi là các hàm hoặc phương thức.

Example

Chúng ta hãy xem xét một lớp đơn giản, Circle, đại diện cho hình tròn hình học trong không gian hai chiều. Các thuộc tính của lớp này có thể được xác định như sau:

• x – coord, để biểu thị tọa độ x của tâm
• y – coord, để biểu thị tọa độ y của tâm
• a, để biểu thị bán kính của hình tròn

Một số hoạt động của nó có thể được định nghĩa như sau:

• findArea (), một phương pháp để tính diện tích
• findCircumference (), một phương pháp để tính chu vi
• scale (), một phương pháp để tăng hoặc giảm bán kính

Đóng gói

Đóng gói là quá trình liên kết cả hai thuộc tính và phương thức với nhau trong một lớp. Thông qua tính năng đóng gói, các chi tiết bên trong của một lớp có thể được ẩn từ bên ngoài. Nó cho phép các phần tử của lớp chỉ được truy cập từ bên ngoài thông qua giao diện do lớp cung cấp.

Đa hình

Đa hình nguyên gốc là một từ Hy Lạp có nghĩa là khả năng có nhiều dạng. Trong mô hình hướng đối tượng, tính đa hình ngụ ý sử dụng các hoạt động theo những cách khác nhau, tùy thuộc vào các trường hợp mà chúng đang hoạt động. Tính đa hình cho phép các đối tượng có cấu trúc bên trong khác nhau có một giao diện bên ngoài chung. Tính đa hình đặc biệt hiệu quả trong khi thực hiện kế thừa.

Example

Chúng ta hãy xem xét hai lớp, Circle và Square, mỗi lớp có một phương thức findArea (). Mặc dù tên và mục đích của các phương thức trong các lớp là giống nhau, nhưng việc triển khai bên trong, tức là, thủ tục tính diện tích là khác nhau đối với mỗi lớp. Khi một đối tượng của lớp Circle gọi phương thức findArea () của nó, thao tác này sẽ tìm diện tích của hình tròn mà không có bất kỳ xung đột nào với phương thức findArea () của lớp Square.

Relationships

Để mô tả một hệ thống, cả đặc tả động (hành vi) và tĩnh (logic) của một hệ thống phải được cung cấp. Đặc tả động mô tả các mối quan hệ giữa các đối tượng, ví dụ truyền thông điệp. Và đặc tả tĩnh mô tả các mối quan hệ giữa các lớp, ví dụ như tập hợp, liên kết và kế thừa.

Thông qua

Bất kỳ ứng dụng nào cũng yêu cầu một số đối tượng tương tác một cách hài hòa. Các đối tượng trong một hệ thống có thể giao tiếp với nhau bằng cách sử dụng truyền thông điệp. Giả sử một hệ thống có hai đối tượng - obj1 và obj2. Đối tượng obj1 gửi thông báo đến đối tượng obj2, nếu obj1 muốn obj2 thực thi một trong các phương thức của nó.

Thành phần hoặc Tổng hợp

Tổng hợp hoặc thành phần là mối quan hệ giữa các lớp mà một lớp có thể được tạo thành từ bất kỳ sự kết hợp nào của các đối tượng của các lớp khác. Nó cho phép các đối tượng được đặt trực tiếp trong phần thân của các lớp khác. Tổng hợp được gọi là mối quan hệ “part – of” hoặc “has – a”, với khả năng điều hướng từ tổng thể sang các bộ phận của nó. Đối tượng tổng hợp là đối tượng được cấu tạo bởi một hoặc nhiều đối tượng khác.

Hiệp hội

Liên kết là một nhóm liên kết có cấu trúc chung và hành vi chung. Mối quan hệ mô tả mối quan hệ giữa các đối tượng của một hoặc nhiều lớp. Một liên kết có thể được định nghĩa là một thể hiện của một liên kết. Mức độ của một liên kết biểu thị số lượng các lớp tham gia vào một kết nối. Mức độ có thể là một bậc, nhị phân hoặc bậc ba.

• Mối quan hệ một ngôi kết nối các đối tượng của cùng một lớp.
• Một mối quan hệ nhị phân kết nối các đối tượng của hai lớp.
• Mối quan hệ bậc ba kết nối các đối tượng của ba lớp trở lên.

Di sản

Nó là một cơ chế cho phép các lớp mới được tạo ra từ các lớp hiện có bằng cách mở rộng và tinh chỉnh các khả năng của nó. Các lớp hiện có được gọi là lớp cơ sở / lớp cha / lớp siêu và các lớp mới được gọi là lớp dẫn xuất / lớp con / lớp con.

Lớp con có thể kế thừa hoặc dẫn xuất các thuộc tính và phương thức của (các) lớp siêu với điều kiện lớp siêu cho phép như vậy. Bên cạnh đó, lớp con có thể thêm các thuộc tính và phương thức của riêng nó và có thể sửa đổi bất kỳ phương thức siêu lớp nào. Kế thừa xác định mối quan hệ "là - một".

Example

Từ một lớp Động vật có vú, một số lớp có thể được bắt nguồn như Người, Mèo, Chó, Bò, ... Con người, mèo, chó và bò đều có những đặc điểm riêng biệt của động vật có vú. Ngoài ra, mỗi loại đều có những đặc điểm riêng biệt. Có thể nói bò “là - một loài động vật có vú”.

Phân tích OO

Trong giai đoạn phân tích hướng đối tượng của phát triển phần mềm, các yêu cầu hệ thống được xác định, các lớp được xác định và mối quan hệ giữa các lớp được thừa nhận. Mục đích của phân tích OO là để hiểu miền ứng dụng và các yêu cầu cụ thể của hệ thống. Kết quả của giai đoạn này là đặc tả yêu cầu và phân tích ban đầu về cấu trúc logic và tính khả thi của hệ thống.

Ba kỹ thuật phân tích được sử dụng kết hợp với nhau để phân tích hướng đối tượng là mô hình hóa đối tượng, mô hình động và mô hình chức năng.

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

Mô hình hóa đối tượng phát triển cấu trúc tĩnh của hệ thống phần mềm về các đối tượng. Nó xác định các đối tượng, các lớp mà các đối tượng có thể được nhóm vào và mối quan hệ giữa các đối tượng. Nó cũng xác định các thuộc tính và hoạt động chính đặc trưng cho mỗi lớp.

Quá trình mô hình hóa đối tượng có thể được hình dung theo các bước sau:

• Xác định các đối tượng và nhóm thành các lớp
• Xác định mối quan hệ giữa các lớp
• Tạo sơ đồ mô hình đối tượng người dùng
• Xác định thuộc tính đối tượng người dùng
• Xác định các hoạt động sẽ được thực hiện trên các lớp

Mô hình động

Sau khi hành vi tĩnh của hệ thống được phân tích, hành vi của nó đối với thời gian và những thay đổi bên ngoài cần được kiểm tra. Đây là mục đích của mô hình động.

Mô hình động có thể được định nghĩa là “một cách mô tả cách một đối tượng riêng lẻ phản ứng với các sự kiện, các sự kiện bên trong do các đối tượng khác kích hoạt hoặc các sự kiện bên ngoài do thế giới bên ngoài kích hoạt”.

Quá trình mô hình hóa động có thể được hình dung theo các bước sau:

• Xác định trạng thái của từng đối tượng
• Xác định các sự kiện và phân tích khả năng áp dụng của các hành động
• Xây dựng một sơ đồ mô hình động, bao gồm các sơ đồ chuyển đổi trạng thái
• Thể hiện từng trạng thái dưới dạng thuộc tính đối tượng
• Xác thực các sơ đồ chuyển đổi trạng thái đã vẽ

Mô hình hóa chức năng

Mô hình hóa chức năng là thành phần cuối cùng của phân tích hướng đối tượng. Mô hình chức năng hiển thị các quy trình được thực hiện trong một đối tượng và dữ liệu thay đổi như thế nào khi nó di chuyển giữa các phương thức. Nó chỉ rõ ý nghĩa của các hoạt động của một mô hình đối tượng và các hành động của một mô hình động. Mô hình chức năng tương ứng với sơ đồ luồng dữ liệu của phân tích có cấu trúc truyền thống.

Quá trình mô hình hóa chức năng có thể được hình dung theo các bước sau:

• Xác định tất cả các đầu vào và đầu ra
• Xây dựng sơ đồ luồng dữ liệu hiển thị các phụ thuộc chức năng
• Nêu mục đích của từng chức năng
• Xác định các ràng buộc
• Chỉ định tiêu chí tối ưu hóa

Thiết kế hướng đối tượng

Sau giai đoạn phân tích, mô hình khái niệm được phát triển thêm thành mô hình hướng đối tượng sử dụng thiết kế hướng đối tượng (OOD). Trong OOD, các khái niệm độc lập về công nghệ trong mô hình phân tích được ánh xạ vào các lớp triển khai, các ràng buộc được xác định và các giao diện được thiết kế, dẫn đến một mô hình cho miền giải pháp. Mục đích chính của thiết kế OO là phát triển kiến ​​trúc cấu trúc của một hệ thống.

Các giai đoạn cho thiết kế hướng đối tượng có thể được xác định là:

• Xác định bối cảnh của hệ thống
• Thiết kế kiến ​​trúc hệ thống
• Nhận dạng các đối tượng trong hệ thống
• Xây dựng mô hình thiết kế
• Đặc điểm kỹ thuật của giao diện đối tượng

OO Design có thể được chia thành hai giai đoạn - Thiết kế ý tưởng và Thiết kế chi tiết.

Conceptual design

Trong giai đoạn này, tất cả các lớp được xác định cần thiết để xây dựng hệ thống. Hơn nữa, trách nhiệm cụ thể được giao cho từng lớp. Biểu đồ lớp được sử dụng để làm rõ mối quan hệ giữa các lớp và biểu đồ tương tác được sử dụng để hiển thị luồng sự kiện. Nó còn được gọi làhigh-level design.

Detailed design

Trong giai đoạn này, các thuộc tính và hoạt động được gán cho mỗi lớp dựa trên sơ đồ tương tác của chúng. Sơ đồ máy trạng thái được phát triển để mô tả các chi tiết hơn nữa của thiết kế. Nó còn được gọi làlow-level design.

Nguyên tắc thiết kế

Sau đây là các nguyên tắc thiết kế chính:

Principle of Decoupling

Rất khó để duy trì một hệ thống với một tập hợp các lớp phụ thuộc lẫn nhau cao, vì việc sửa đổi trong một lớp có thể dẫn đến cập nhật theo tầng của các lớp khác. Trong thiết kế OO, sự kết hợp chặt chẽ có thể được loại bỏ bằng cách giới thiệu các lớp hoặc kế thừa mới.

Ensuring Cohesion

Một lớp gắn kết thực hiện một tập hợp các chức năng có liên quan chặt chẽ với nhau. Sự thiếu gắn kết có nghĩa là - một lớp thực hiện các chức năng không liên quan, mặc dù nó không ảnh hưởng đến hoạt động của toàn hệ thống. Nó làm cho toàn bộ cấu trúc của phần mềm khó quản lý, mở rộng, bảo trì và thay đổi.

Open-closed Principle

Theo nguyên tắc này, một hệ thống phải có thể mở rộng để đáp ứng các yêu cầu mới. Việc triển khai hiện có và mã của hệ thống không được sửa đổi do mở rộng hệ thống. Ngoài ra, các nguyên tắc sau đây phải được tuân thủ theo nguyên tắc đóng mở -

• Đối với mỗi lớp cụ thể, giao diện và triển khai riêng biệt phải được duy trì.

• Trong môi trường đa luồng, hãy giữ các thuộc tính ở chế độ riêng tư.

• Giảm thiểu việc sử dụng các biến toàn cục và biến lớp.

Trong kiến ​​trúc luồng dữ liệu, toàn bộ hệ thống phần mềm được xem như một chuỗi các phép biến đổi trên các phần hoặc tập dữ liệu đầu vào liên tiếp, nơi dữ liệu và hoạt động độc lập với nhau. Trong cách tiếp cận này, dữ liệu đi vào hệ thống và sau đó chảy qua các mô-đun tại một thời điểm cho đến khi chúng được gán cho một số đích cuối cùng (đầu ra hoặc kho dữ liệu).

Các kết nối giữa các thành phần hoặc mô-đun có thể được thực hiện dưới dạng luồng I / O, bộ đệm I / O, đường ống hoặc các loại kết nối khác. Dữ liệu có thể được di chuyển trong cấu trúc liên kết đồ thị có chu trình, trong cấu trúc tuyến tính không có chu trình hoặc trong cấu trúc kiểu cây.

Mục tiêu chính của phương pháp này là đạt được chất lượng tái sử dụng và khả năng sửa đổi. Nó phù hợp cho các ứng dụng liên quan đến một loạt các phép tính hoặc biến đổi dữ liệu độc lập được xác định rõ trên đầu vào và đầu ra được xác định có trật tự như trình biên dịch và các ứng dụng xử lý dữ liệu kinh doanh. Có ba loại trình tự thực thi giữa các mô-đun−

• Hàng loạt tuần tự
• Chế độ đường ống và bộ lọc hoặc chế độ đường ống không tuần tự
• Kiểm soát quy trình

Tuần tự hàng loạt

Tuần tự hàng loạt là một mô hình xử lý dữ liệu cổ điển, trong đó một hệ thống con chuyển đổi dữ liệu chỉ có thể bắt đầu quá trình của nó sau khi hệ thống con trước đó của nó hoàn toàn thông qua -

• Luồng dữ liệu mang một loạt dữ liệu tổng thể từ hệ thống con này sang hệ thống con khác.

• Sự liên lạc giữa các mô-đun được thực hiện thông qua các tệp trung gian tạm thời có thể được gỡ bỏ bởi các hệ thống con kế tiếp.

• Nó có thể áp dụng cho những ứng dụng mà dữ liệu được chia theo lô và mỗi hệ thống con đọc các tệp đầu vào liên quan và ghi các tệp đầu ra.

• Ứng dụng điển hình của kiến ​​trúc này bao gồm xử lý dữ liệu kinh doanh như thanh toán ngân hàng và tiện ích.

Ưu điểm

• Cung cấp các phân chia đơn giản hơn trên các hệ thống con.

• Mỗi hệ thống con có thể là một chương trình độc lập làm việc trên dữ liệu đầu vào và tạo ra dữ liệu đầu ra.

Nhược điểm

• Cung cấp độ trễ cao và thông lượng thấp.

• Không cung cấp giao diện tương tác và đồng thời.

• Kiểm soát bên ngoài là cần thiết để thực hiện.

Kiến trúc ống và bộ lọc

Cách tiếp cận này nhấn mạnh vào sự chuyển đổi gia tăng dữ liệu theo thành phần kế tiếp. Trong cách tiếp cận này, luồng dữ liệu được điều khiển bởi dữ liệu và toàn bộ hệ thống được phân tách thành các thành phần của nguồn dữ liệu, bộ lọc, đường ống và bồn chứa dữ liệu.

Các kết nối giữa các mô-đun là dòng dữ liệu là bộ đệm vào / ra trước có thể là dòng byte, ký tự hoặc bất kỳ loại nào khác như vậy. Tính năng chính của kiến ​​trúc này là thực thi đồng thời và tăng dần.

Bộ lọc

Bộ lọc là một bộ biến dòng dữ liệu độc lập hoặc các bộ chuyển đổi dòng. Nó biến đổi dữ liệu của luồng dữ liệu đầu vào, xử lý và ghi luồng dữ liệu đã biến đổi qua một đường ống để bộ lọc tiếp theo xử lý. Nó hoạt động ở chế độ gia tăng, trong đó nó bắt đầu hoạt động ngay khi dữ liệu đến qua đường ống được kết nối. Có hai loại bộ lọc -active filter và passive filter.

Active filter

Bộ lọc hoạt động cho phép các đường ống được kết nối để kéo dữ liệu vào và đẩy ra dữ liệu đã chuyển đổi. Nó hoạt động với ống thụ động, cung cấp cơ chế đọc / ghi để kéo và đẩy. Chế độ này được sử dụng trong cơ chế ống và bộ lọc UNIX.

Passive filter

Bộ lọc thụ động cho phép các đường ống được kết nối để đẩy dữ liệu vào và kéo dữ liệu ra. Nó hoạt động với đường ống hoạt động, kéo dữ liệu từ một bộ lọc và đẩy dữ liệu vào bộ lọc tiếp theo. Nó phải cung cấp cơ chế đọc / ghi.

Ưu điểm

• Cung cấp đồng thời và thông lượng cao để xử lý dữ liệu quá mức.

• Cung cấp khả năng tái sử dụng và đơn giản hóa việc bảo trì hệ thống.

• Cung cấp khả năng sửa đổi và khớp nối thấp giữa các bộ lọc.

• Cung cấp sự đơn giản bằng cách cung cấp sự phân chia rõ ràng giữa hai bộ lọc bất kỳ được kết nối bằng đường ống.

• Cung cấp tính linh hoạt bằng cách hỗ trợ cả thực thi tuần tự và song song.

Nhược điểm

• Không thích hợp cho các tương tác động.

• Cần có một mẫu số chung thấp để truyền dữ liệu ở các định dạng ASCII.

• Chi phí chuyển đổi dữ liệu giữa các bộ lọc.

• Không cung cấp cách để các bộ lọc tương tác hợp tác để giải quyết vấn đề.

• Khó cấu hình động kiến ​​trúc này.

Ống

Các đường ống là không trạng thái và chúng mang dòng nhị phân hoặc ký tự tồn tại giữa hai bộ lọc. Nó có thể di chuyển luồng dữ liệu từ bộ lọc này sang bộ lọc khác. Pipes sử dụng một ít thông tin theo ngữ cảnh và không giữ lại thông tin trạng thái giữa các lần khởi tạo.

Kiến trúc kiểm soát quy trình

Đây là một kiểu kiến ​​trúc luồng dữ liệu trong đó dữ liệu không phải là luồng tuần tự theo lô hay luồng liên kết. Luồng dữ liệu đến từ một tập hợp các biến, điều khiển quá trình thực thi. Nó phân hủy toàn bộ hệ thống thành các hệ thống con hoặc mô-đun và kết nối chúng.

Các loại hệ thống con

Một kiến ​​trúc kiểm soát quy trình sẽ có processing unit để thay đổi các biến kiểm soát quá trình và controller unit để tính toán lượng thay đổi.

Bộ điều khiển phải có các yếu tố sau:

• Controlled Variable- Biến được điều khiển cung cấp các giá trị cho hệ thống bên dưới và cần được đo bằng cảm biến. Ví dụ, tốc độ trong hệ thống kiểm soát hành trình.

• Input Variable- Đo lường một đầu vào cho quá trình. Ví dụ, nhiệt độ của khí hồi trong hệ thống điều khiển nhiệt độ

• Manipulated Variable - Giá trị biến được thao tác được điều chỉnh hoặc thay đổi bởi bộ điều khiển.

• Process Definition - Nó bao gồm các cơ chế để thao tác một số biến quy trình.

• Sensor - Nhận các giá trị của các biến quá trình thích hợp để kiểm soát và có thể được sử dụng như một tham chiếu phản hồi để tính toán lại các biến đã thao tác.

• Set Point - Đây là giá trị mong muốn cho một biến được kiểm soát.

• Control Algorithm - Nó được sử dụng để quyết định cách thao tác với các biến quy trình.

Lĩnh vực ứng dụng

Kiến trúc điều khiển quy trình phù hợp trong các lĩnh vực sau:

• Thiết kế phần mềm hệ thống nhúng, trong đó hệ thống được điều khiển bởi dữ liệu biến điều khiển quá trình.

• Các ứng dụng, mục đích là duy trì các thuộc tính cụ thể của các đầu ra của quá trình ở các giá trị tham chiếu nhất định.

• Áp dụng cho hệ thống kiểm soát hành trình và kiểm soát nhiệt độ tòa nhà.

• Phần mềm hệ thống thời gian thực để điều khiển phanh chống bó cứng ô tô, nhà máy điện hạt nhân, v.v.

Trong kiến ​​trúc lấy dữ liệu làm trung tâm, dữ liệu được tập trung và được truy cập thường xuyên bởi các thành phần khác, điều này sẽ sửa đổi dữ liệu. Mục đích chính của phong cách này là đạt được tính toàn vẹn của dữ liệu. Kiến trúc lấy dữ liệu làm trung tâm bao gồm các thành phần khác nhau giao tiếp thông qua các kho dữ liệu được chia sẻ. Các thành phần truy cập một cấu trúc dữ liệu được chia sẻ và tương đối độc lập, trong đó, chúng chỉ tương tác thông qua kho dữ liệu.

Các ví dụ nổi tiếng nhất về kiến ​​trúc lấy dữ liệu làm trung tâm là kiến ​​trúc cơ sở dữ liệu, trong đó lược đồ cơ sở dữ liệu chung được tạo bằng giao thức định nghĩa dữ liệu - ví dụ: một tập hợp các bảng liên quan với các trường và kiểu dữ liệu trong RDBMS.

Một ví dụ khác về kiến ​​trúc lấy dữ liệu làm trung tâm là kiến ​​trúc web có một lược đồ dữ liệu chung (tức là siêu cấu trúc của Web) và tuân theo mô hình dữ liệu siêu phương tiện và các quy trình giao tiếp thông qua việc sử dụng các dịch vụ dữ liệu dựa trên web được chia sẻ.

Các loại thành phần

Có hai loại thành phần -

• A central datacấu trúc hoặc kho dữ liệu hoặc kho dữ liệu, nơi chịu trách nhiệm cung cấp khả năng lưu trữ dữ liệu vĩnh viễn. Nó đại diện cho trạng thái hiện tại.

• A data accessor hoặc một tập hợp các thành phần độc lập hoạt động trên kho dữ liệu trung tâm, thực hiện các phép tính và có thể đưa lại kết quả.

Sự tương tác hoặc giao tiếp giữa những người truy cập dữ liệu chỉ thông qua kho dữ liệu. Dữ liệu là phương tiện giao tiếp duy nhất giữa các khách hàng. Luồng kiểm soát phân biệt kiến ​​trúc thành hai loại:

• Phong cách kiến ​​trúc kho lưu trữ
• Phong cách kiến ​​trúc bảng đen

Phong cách kiến ​​trúc kho lưu trữ

Trong Kiểu kiến ​​trúc Kho lưu trữ, kho lưu trữ dữ liệu là thụ động và các máy khách (thành phần phần mềm hoặc tác nhân) của kho dữ liệu đang hoạt động, điều khiển luồng logic. Các thành phần tham gia kiểm tra kho dữ liệu để biết các thay đổi.

• Máy khách gửi yêu cầu đến hệ thống để thực hiện các hành động (ví dụ: chèn dữ liệu).

• Các quy trình tính toán là độc lập và được kích hoạt bởi các yêu cầu đến.

• Nếu các loại giao dịch trong luồng giao dịch đầu vào kích hoạt lựa chọn các quy trình để thực hiện, thì đó là cơ sở dữ liệu truyền thống hoặc kiến ​​trúc kho lưu trữ hoặc kho lưu trữ thụ động.

• Cách tiếp cận này được sử dụng rộng rãi trong DBMS, hệ thống thông tin thư viện, kho giao diện trong CORBA, trình biên dịch và môi trường CASE (kỹ thuật phần mềm hỗ trợ máy tính).

Ưu điểm

• Cung cấp tính năng toàn vẹn dữ liệu, sao lưu và khôi phục.

• Cung cấp khả năng mở rộng và khả năng tái sử dụng của các đại lý vì chúng không có giao tiếp trực tiếp với nhau.

• Giảm chi phí dữ liệu tạm thời giữa các thành phần phần mềm.

Nhược điểm

• Nó dễ bị hỏng hơn và có thể xảy ra sao chép hoặc sao chép dữ liệu.

• Sự phụ thuộc cao giữa cấu trúc dữ liệu của kho dữ liệu và các tác nhân của nó.

• Những thay đổi trong cấu trúc dữ liệu ảnh hưởng lớn đến các máy khách.

• Quá trình phát triển dữ liệu rất khó khăn và tốn kém.

• Chi phí di chuyển dữ liệu trên mạng đối với dữ liệu phân tán.

Phong cách kiến ​​trúc bảng đen

Trong Phong cách Kiến trúc Bảng đen, kho dữ liệu đang hoạt động và các máy khách của nó là bị động. Do đó luồng logic được xác định bởi trạng thái dữ liệu hiện tại trong kho dữ liệu. Nó có một thành phần bảng đen, hoạt động như một kho lưu trữ dữ liệu trung tâm và một biểu diễn bên trong được xây dựng và hoạt động bởi các phần tử tính toán khác nhau.

• Một số thành phần hoạt động độc lập trên cấu trúc dữ liệu chung được lưu trữ trong bảng đen.

• Trong phong cách này, các thành phần chỉ tương tác thông qua bảng đen. Kho lưu trữ dữ liệu cảnh báo cho khách hàng bất cứ khi nào có thay đổi về kho dữ liệu.

• Trạng thái hiện tại của giải pháp được lưu trữ trong bảng đen và quá trình xử lý được kích hoạt bởi trạng thái của bảng đen.

• Hệ thống gửi thông báo được gọi là trigger và dữ liệu cho khách hàng khi dữ liệu xảy ra thay đổi.

• Cách tiếp cận này được tìm thấy trong các ứng dụng AI nhất định và các ứng dụng phức tạp, chẳng hạn như nhận dạng giọng nói, nhận dạng hình ảnh, hệ thống bảo mật và hệ thống quản lý tài nguyên kinh doanh, v.v.

• Nếu trạng thái hiện tại của cấu trúc dữ liệu trung tâm là kích hoạt chính của việc lựa chọn các quy trình để thực thi, thì kho lưu trữ có thể là một bảng đen và nguồn dữ liệu được chia sẻ này là một tác nhân hoạt động.

• Một sự khác biệt chính với các hệ thống cơ sở dữ liệu truyền thống là việc gọi các phần tử tính toán trong kiến ​​trúc bảng đen được kích hoạt bởi trạng thái hiện tại của bảng đen, chứ không phải bởi các đầu vào bên ngoài.

Các bộ phận của mô hình bảng đen

Mô hình bảng đen thường được trình bày với ba phần chính:

Knowledge Sources (KS)

Nguồn tri thức, còn được gọi là Listeners hoặc là Subscriberslà các đơn vị riêng biệt và độc lập. Chúng giải quyết các phần của một vấn đề và tổng hợp các kết quả từng phần. Sự tương tác giữa các nguồn tri thức diễn ra duy nhất thông qua bảng đen.

Blackboard Data Structure

Dữ liệu trạng thái giải quyết vấn đề được tổ chức thành một hệ thống phân cấp phụ thuộc vào ứng dụng. Các nguồn tri thức thực hiện các thay đổi đối với bảng đen để dần dần dẫn đến giải pháp cho vấn đề.

Control

Control quản lý các nhiệm vụ và kiểm tra trạng thái công việc.

Ưu điểm

• Cung cấp khả năng mở rộng giúp dễ dàng bổ sung hoặc cập nhật nguồn kiến ​​thức.

• Cung cấp tính đồng thời cho phép tất cả các nguồn tri thức hoạt động song song vì chúng độc lập với nhau.

• Hỗ trợ thử nghiệm cho các giả thuyết.

• Hỗ trợ khả năng tái sử dụng của các tác nhân nguồn tri thức.

Nhược điểm

• Sự thay đổi cấu trúc của bảng đen có thể có tác động đáng kể đến tất cả các tác nhân của nó vì tồn tại sự phụ thuộc chặt chẽ giữa bảng đen và nguồn tri thức.

• Có thể khó quyết định khi nào chấm dứt suy luận vì chỉ có giải pháp gần đúng được mong đợi.

• Sự cố đồng bộ hóa của nhiều tác nhân.

• Những thách thức lớn trong việc thiết kế và thử nghiệm hệ thống.

Kiến trúc phân cấp xem toàn bộ hệ thống như một cấu trúc phân cấp, trong đó hệ thống phần mềm được phân tách thành các mô-đun lôgic hoặc hệ thống con ở các cấp độ khác nhau trong hệ thống phân cấp. Cách tiếp cận này thường được sử dụng trong thiết kế phần mềm hệ thống như giao thức mạng và hệ điều hành.

Trong thiết kế phân cấp phần mềm hệ thống, hệ thống con cấp thấp cung cấp các dịch vụ cho các hệ thống con cấp trên liền kề của nó, hệ thống này gọi các phương thức ở cấp thấp hơn. Lớp dưới cung cấp nhiều chức năng cụ thể hơn như dịch vụ I / O, giao dịch, lập lịch, dịch vụ bảo mật, v.v. Lớp giữa cung cấp nhiều chức năng phụ thuộc miền hơn như logic nghiệp vụ và dịch vụ xử lý cốt lõi. Và, lớp trên cung cấp nhiều chức năng trừu tượng hơn dưới dạng giao diện người dùng như GUI, cơ sở lập trình shell, v.v.

Nó cũng được sử dụng trong việc tổ chức các thư viện lớp như thư viện lớp .NET trong hệ thống phân cấp không gian tên. Tất cả các kiểu thiết kế đều có thể thực hiện kiến ​​trúc phân cấp này và thường kết hợp với các kiểu kiến ​​trúc khác.

Các phong cách kiến ​​trúc phân cấp được chia thành:

• Main-subroutine
• Master-slave
• Máy ảo

Chương trình con chính

Mục đích của phong cách này là sử dụng lại các mô-đun và tự do phát triển các mô-đun hoặc chương trình con riêng lẻ. Theo phong cách này, một hệ thống phần mềm được chia thành các chương trình con bằng cách sử dụng sàng lọc từ trên xuống theo chức năng mong muốn của hệ thống.

Những cải tiến này dẫn đầu theo chiều dọc cho đến khi các mô-đun phân hủy đủ đơn giản để có trách nhiệm độc lập riêng của nó. Chức năng có thể được sử dụng lại và chia sẻ bởi nhiều người gọi ở các lớp trên.

Có hai cách mà dữ liệu được truyền dưới dạng tham số cho các chương trình con, đó là:

• Pass by Value - Chương trình con chỉ sử dụng dữ liệu quá khứ, nhưng không thể sửa đổi nó.

• Pass by Reference - Các chương trình con sử dụng cũng như thay đổi giá trị của dữ liệu được tham chiếu bởi tham số.

Ưu điểm

• Dễ dàng phân rã hệ thống dựa trên sự tinh chỉnh phân cấp.

• Có thể được sử dụng trong một hệ thống con của thiết kế hướng đối tượng.

Nhược điểm

• Dễ bị tổn thương vì nó chứa dữ liệu được chia sẻ toàn cầu.

• Khớp nối chặt chẽ có thể gây ra nhiều gợn sóng hơn khi thay đổi.

Chủ-nô lệ

Cách tiếp cận này áp dụng nguyên tắc 'chia để trị' và hỗ trợ tính toán lỗi và tính chính xác. Nó là một sửa đổi của kiến ​​trúc chương trình con chính để cung cấp độ tin cậy của hệ thống và khả năng chịu lỗi.

Trong kiến ​​trúc này, các nô lệ cung cấp các dịch vụ trùng lặp cho chủ và chủ chọn một kết quả cụ thể giữa các nô lệ bằng một chiến lược lựa chọn nhất định. Các nô lệ có thể thực hiện cùng một nhiệm vụ chức năng bằng các thuật toán và phương pháp khác nhau hoặc chức năng hoàn toàn khác. Nó bao gồm tính toán song song trong đó tất cả các nô lệ có thể được thực thi song song.

Việc triển khai mẫu Master-Slave tuân theo năm bước:

• Chỉ định cách tính toán nhiệm vụ có thể được chia thành một tập hợp các nhiệm vụ con bằng nhau và xác định các dịch vụ con cần thiết để xử lý một nhiệm vụ con.

• Chỉ định cách tính kết quả cuối cùng của toàn bộ dịch vụ với sự trợ giúp của các kết quả thu được từ việc xử lý các nhiệm vụ con riêng lẻ.

• Xác định giao diện cho dịch vụ con được xác định trong bước 1. Nó sẽ được thực thi bởi máy chủ và được máy chủ sử dụng để ủy quyền xử lý các nhiệm vụ con riêng lẻ.

• Thực hiện các thành phần phụ theo các thông số kỹ thuật đã phát triển ở bước trước.

• Triển khai tổng thể theo các thông số kỹ thuật đã phát triển ở bước 1 đến 3.

Các ứng dụng

• Thích hợp cho các ứng dụng mà độ tin cậy của phần mềm là vấn đề quan trọng.

• Ứng dụng rộng rãi trong các lĩnh vực tính toán song song và phân tán.

Ưu điểm

• Tính toán nhanh hơn và khả năng mở rộng dễ dàng.

• Cung cấp sự mạnh mẽ vì nô lệ có thể được nhân bản.

• Slave có thể được thực hiện khác nhau để giảm thiểu lỗi ngữ nghĩa.

Nhược điểm

• Chi phí giao tiếp.

• Không phải tất cả các vấn đề đều có thể được phân chia.

• Vấn đề khó thực hiện và tính di động.

Kiến trúc máy ảo

Kiến trúc Máy ảo giả vờ một số chức năng, không có nguồn gốc từ phần cứng và / hoặc phần mềm mà nó được triển khai. Một máy ảo được xây dựng dựa trên một hệ thống hiện có và cung cấp một trừu tượng ảo, một tập hợp các thuộc tính và hoạt động.

Trong kiến ​​trúc máy ảo, máy chủ sử dụng 'cùng một' dịch vụ con 'từ máy phụ và thực hiện các chức năng như phân chia công việc, gọi nô lệ và kết hợp các kết quả. Nó cho phép các nhà phát triển mô phỏng và thử nghiệm các nền tảng chưa được xây dựng và mô phỏng các chế độ "thảm họa" sẽ quá phức tạp, tốn kém hoặc nguy hiểm để thử nghiệm với hệ thống thực.

Trong hầu hết các trường hợp, máy ảo tách ngôn ngữ lập trình hoặc môi trường ứng dụng khỏi nền tảng thực thi. Mục tiêu chính là cung cấpportability. Việc diễn giải một mô-đun cụ thể thông qua Máy ảo có thể được coi là -

• Công cụ thông dịch chọn một lệnh từ mô-đun đang được thông dịch.

• Dựa trên hướng dẫn, công cụ cập nhật trạng thái bên trong của máy ảo và quá trình trên được lặp lại.

Hình dưới đây cho thấy kiến ​​trúc của cơ sở hạ tầng VM tiêu chuẩn trên một máy vật lý duy nhất.

Các hypervisor, cũng được gọi là virtual machine monitor, chạy trên hệ điều hành chủ và phân bổ tài nguyên phù hợp cho mỗi hệ điều hành khách. Khi khách thực hiện cuộc gọi hệ thống, hypervisor sẽ chặn và chuyển nó thành lệnh gọi hệ thống tương ứng được hỗ trợ bởi hệ điều hành chủ. Hypervisor kiểm soát từng quyền truy cập của máy ảo vào CPU, bộ nhớ, lưu trữ liên tục, các thiết bị I / O và mạng.

Các ứng dụng

Kiến trúc máy ảo phù hợp trong các lĩnh vực sau:

• Thích hợp để giải quyết một vấn đề bằng mô phỏng hoặc dịch thuật nếu không có giải pháp trực tiếp.

• Các ứng dụng mẫu bao gồm trình thông dịch của vi lập trình, xử lý XML, thực thi ngôn ngữ lệnh tập lệnh, thực thi hệ thống dựa trên quy tắc, ngôn ngữ lập trình kiểu thông dịch viên Smalltalk và Java.

• Các ví dụ phổ biến về máy ảo là trình thông dịch, hệ thống dựa trên quy tắc, trình bao cú pháp và bộ xử lý ngôn ngữ lệnh.

Ưu điểm

• Tính di động và tính độc lập của nền tảng máy.

• Tính đơn giản của phát triển phần mềm.

• Cung cấp tính linh hoạt thông qua khả năng ngắt và truy vấn chương trình.

• Mô phỏng cho mô hình làm việc với thảm họa.

• Giới thiệu các sửa đổi trong thời gian chạy.

Nhược điểm

• Trình thông dịch thực hiện chậm do tính chất của trình thông dịch.

• Có một chi phí hiệu suất do tính toán bổ sung liên quan đến việc thực thi.

Kiểu phân lớp

Theo cách tiếp cận này, hệ thống được phân tách thành một số lớp cao hơn và thấp hơn trong một hệ thống phân cấp, và mỗi lớp có trách nhiệm duy nhất trong hệ thống.

• Mỗi lớp bao gồm một nhóm các lớp liên quan được đóng gói trong một gói, trong một thành phần được triển khai hoặc dưới dạng một nhóm chương trình con ở định dạng thư viện phương thức hoặc tệp tiêu đề.

• Mỗi lớp cung cấp dịch vụ cho lớp bên trên nó và phục vụ như một máy khách cho lớp bên dưới, tức là yêu cầu lớp i +1 gọi các dịch vụ được cung cấp bởi lớp i thông qua giao diện của lớp i. Phản hồi có thể quay trở lại lớp i +1 nếu nhiệm vụ được hoàn thành; nếu không lớp tôi liên tục gọi các dịch vụ từ lớp i -1 bên dưới.

Các ứng dụng

Kiểu phân lớp phù hợp trong các lĩnh vực sau:

• Các ứng dụng liên quan đến các lớp dịch vụ riêng biệt có thể được tổ chức theo thứ bậc.

• Bất kỳ ứng dụng nào có thể được phân tách thành các phần dành riêng cho ứng dụng và nền tảng cụ thể.

• Các ứng dụng có sự phân chia rõ ràng giữa các dịch vụ cốt lõi, các dịch vụ quan trọng và các dịch vụ giao diện người dùng, v.v.

Ưu điểm

• Thiết kế dựa trên mức độ trừu tượng tăng dần.

• Cung cấp tính độc lập nâng cao khi các thay đổi đối với chức năng của một lớp ảnh hưởng đến nhiều nhất hai lớp khác.

• Tách giao diện tiêu chuẩn và việc triển khai nó.

• Được triển khai bằng cách sử dụng công nghệ dựa trên thành phần giúp hệ thống cho phép plug-and-play các thành phần mới dễ dàng hơn nhiều.

• Mỗi lớp có thể là một máy trừu tượng được triển khai độc lập hỗ trợ tính di động.

• Dễ dàng phân rã hệ thống dựa trên định nghĩa của các nhiệm vụ theo cách tinh chỉnh từ trên xuống

• Các triển khai khác nhau (với các giao diện giống hệt nhau) của cùng một lớp có thể được sử dụng thay thế cho nhau

Nhược điểm

• Nhiều ứng dụng hoặc hệ thống không dễ dàng được cấu trúc theo kiểu nhiều lớp.

• Hiệu suất thời gian chạy thấp hơn vì yêu cầu của khách hàng hoặc phản hồi đối với khách hàng phải trải qua một số lớp tiềm năng.

• Ngoài ra còn có các mối quan tâm về hiệu suất về chi phí trên việc sắp xếp và đệm dữ liệu theo từng lớp.

• Việc mở giao tiếp giữa các lớp có thể gây ra bế tắc và "bắc cầu" có thể gây ra khớp nối chặt chẽ.

• Các ngoại lệ và xử lý lỗi là một vấn đề trong kiến ​​trúc phân lớp, vì các lỗi trong một lớp phải lan rộng lên tất cả các lớp đang gọi

Mục tiêu chính của kiến ​​trúc hướng tương tác là tách sự tương tác của người dùng khỏi sự trừu tượng hóa dữ liệu và xử lý dữ liệu nghiệp vụ. Kiến trúc phần mềm hướng tương tác phân tách hệ thống thành ba phân vùng chính -

• Data module - Mô-đun dữ liệu cung cấp tính trừu tượng hóa dữ liệu và tất cả logic nghiệp vụ.

• Control module - Mô-đun điều khiển xác định luồng điều khiển và các hành động cấu hình hệ thống.

• View presentation module - Mô-đun trình bày View chịu trách nhiệm trình bày bằng hình ảnh hoặc âm thanh của đầu ra dữ liệu và nó cũng cung cấp một giao diện để người dùng nhập liệu.

Kiến trúc hướng tương tác có hai phong cách chính: Model-View-Controller (MVC) và Presentation-Abstraction-Control(PAC). Cả MVC và PAC đều đề xuất phân tách ba thành phần và được sử dụng cho các ứng dụng tương tác như ứng dụng web với nhiều cuộc nói chuyện và tương tác với người dùng. Họ khác nhau về quy trình kiểm soát và tổ chức. PAC là một kiến ​​trúc phân cấp dựa trên tác nhân nhưng MVC không có cấu trúc phân cấp rõ ràng.

Model-View-Controller (MVC)

MVC phân tách một ứng dụng phần mềm nhất định thành ba phần được kết nối với nhau để giúp tách các phần trình bày nội bộ của thông tin khỏi thông tin được trình bày hoặc chấp nhận từ người dùng.

Mô-đun	Chức năng
Mô hình	Đóng gói dữ liệu cơ bản và logic nghiệp vụ
Bộ điều khiển	Phản hồi hành động của người dùng và hướng luồng ứng dụng
Lượt xem	Định dạng và trình bày dữ liệu từ mô hình cho người dùng.

Mô hình

Model là thành phần trung tâm của MVC quản lý trực tiếp dữ liệu, logic và các ràng buộc của một ứng dụng. Nó bao gồm các thành phần dữ liệu, duy trì dữ liệu ứng dụng thô và logic ứng dụng cho giao diện.

• Nó là một giao diện người dùng độc lập và nắm bắt hành vi của miền sự cố ứng dụng.

• Nó là phần mềm mô phỏng miền cụ thể hoặc thực hiện cấu trúc trung tâm của ứng dụng.

• Khi có sự thay đổi trong trạng thái của nó, nó sẽ đưa ra thông báo cho khung nhìn liên quan của nó để tạo ra đầu ra cập nhật và bộ điều khiển để thay đổi bộ lệnh có sẵn.

Lượt xem

Dạng xem có thể được sử dụng để biểu diễn bất kỳ đầu ra thông tin nào ở dạng đồ họa như sơ đồ hoặc biểu đồ. Nó bao gồm các thành phần trình bày cung cấp các biểu diễn trực quan của dữ liệu

• Chế độ xem yêu cầu thông tin từ mô hình của họ và tạo ra một biểu diễn đầu ra cho người dùng.

• Có thể có nhiều chế độ xem của cùng một thông tin, chẳng hạn như biểu đồ thanh để quản lý và chế độ xem dạng bảng cho kế toán.

Bộ điều khiển

Bộ điều khiển chấp nhận một đầu vào và chuyển đổi nó thành các lệnh cho mô hình hoặc chế độ xem. Nó bao gồm các thành phần xử lý đầu vào xử lý đầu vào từ người dùng bằng cách sửa đổi mô hình.

• Nó hoạt động như một giao diện giữa các mô hình và chế độ xem liên quan và các thiết bị đầu vào.

• Nó có thể gửi các lệnh tới mô hình để cập nhật trạng thái của mô hình và đến khung nhìn liên quan của nó để thay đổi cách trình bày mô hình của khung nhìn.

MVC - Tôi

Đây là một phiên bản đơn giản của kiến ​​trúc MVC trong đó hệ thống được chia thành hai hệ thống con -

• The Controller-View - Chế độ xem bộ điều khiển hoạt động như giao diện đầu vào / đầu ra và quá trình xử lý được thực hiện.

• The Model - Mô hình cung cấp tất cả các dịch vụ dữ liệu và miền.

MVC-I Architecture

Mô-đun mô hình thông báo cho mô-đun chế độ xem bộ điều khiển về mọi thay đổi dữ liệu để mọi hiển thị dữ liệu đồ họa sẽ được thay đổi tương ứng. Bộ điều khiển cũng thực hiện hành động thích hợp khi thay đổi.

Kết nối giữa chế độ xem bộ điều khiển và mô hình có thể được thiết kế theo mô hình (như thể hiện trong hình trên) của đăng ký-thông báo theo đó chế độ xem bộ điều khiển đăng ký với mô hình và mô hình thông báo cho chế độ xem bộ điều khiển về bất kỳ thay đổi nào.

MVC - II

MVC – II là sự cải tiến của kiến ​​trúc MVC-I trong đó mô-đun khung nhìn và mô-đun bộ điều khiển tách biệt. Mô-đun mô hình đóng một vai trò tích cực như trong MVC-I bằng cách cung cấp tất cả các chức năng cốt lõi và dữ liệu được cơ sở dữ liệu hỗ trợ.

Mô-đun khung nhìn trình bày dữ liệu trong khi mô-đun bộ điều khiển chấp nhận yêu cầu đầu vào, xác thực dữ liệu đầu vào, khởi tạo mô hình, khung nhìn, kết nối của chúng và cũng gửi tác vụ.

MVC-II Architecture

Ứng dụng MVC

Các ứng dụng MVC có hiệu quả đối với các ứng dụng tương tác cần nhiều chế độ xem cho một mô hình dữ liệu duy nhất và dễ dàng bổ sung chế độ xem giao diện mới hoặc thay đổi.

Ứng dụng MVC thích hợp cho các ứng dụng có sự phân chia rõ ràng giữa các mô-đun để các chuyên gia khác nhau có thể được chỉ định làm việc đồng thời trên các khía cạnh khác nhau của các ứng dụng đó.

Advantages

• Có rất nhiều bộ công cụ khung của nhà cung cấp MVC có sẵn.

• Nhiều chế độ xem được đồng bộ hóa với cùng một mô hình dữ liệu.

• Dễ dàng cắm các giao diện mới hoặc thay thế.

• Được sử dụng để phát triển ứng dụng nơi các chuyên gia đồ họa, chuyên gia lập trình và chuyên gia phát triển cơ sở dữ liệu đang làm việc trong nhóm dự án được thiết kế.

Disadvantages

• Không phù hợp với các ứng dụng hướng đến tác nhân như ứng dụng di động và rô bốt tương tác.

• Nhiều cặp bộ điều khiển và khung nhìn dựa trên cùng một mô hình dữ liệu làm cho bất kỳ thay đổi mô hình dữ liệu nào trở nên đắt đỏ.

• Sự phân chia giữa Chế độ xem và Bộ điều khiển không rõ ràng trong một số trường hợp.

Trình bày-Tóm tắt-Kiểm soát (PAC)

Trong PAC, hệ thống được sắp xếp thành một hệ thống phân cấp gồm nhiều tác nhân hợp tác (bộ ba). Nó được phát triển từ MVC để hỗ trợ yêu cầu ứng dụng của nhiều tác nhân ngoài các yêu cầu tương tác.

Mỗi tác nhân có ba thành phần -

• The presentation component - Định dạng hình ảnh và âm thanh trình bày dữ liệu.

• The abstraction component - Truy xuất và xử lý dữ liệu.

• The control component - Xử lý nhiệm vụ như luồng điều khiển và giao tiếp giữa hai thành phần còn lại.

Kiến trúc PAC tương tự như MVC, theo nghĩa mô-đun trình bày giống như mô-đun xem của MVC. Mô-đun trừu tượng trông giống như mô-đun mô hình của MVC và mô-đun điều khiển giống như mô-đun điều khiển của MVC, nhưng chúng khác nhau về luồng điều khiển và tổ chức.

Không có kết nối trực tiếp giữa thành phần trừu tượng và thành phần trình bày trong mỗi tác nhân. Thành phần kiểm soát trong mỗi tác nhân phụ trách liên lạc với các tác nhân khác.

Hình dưới đây cho thấy một sơ đồ khối cho một tác nhân duy nhất trong thiết kế PAC.

PAC với nhiều đại lý

Trong PAC bao gồm nhiều đại lý, đại lý cấp cao nhất cung cấp dữ liệu cốt lõi và lôgic kinh doanh. Các tác nhân cấp dưới xác định dữ liệu và bản trình bày cụ thể chi tiết. Cấp trung gian hoặc đại lý cấp trung đóng vai trò là người điều phối các đại lý cấp thấp.

• Mỗi đại lý có công việc được giao cụ thể riêng.

• Đối với một số đại lý cấp trung, các bản trình bày tương tác là không bắt buộc, do đó chúng không có thành phần trình bày.

• Thành phần điều khiển là bắt buộc đối với tất cả các tác nhân mà qua đó tất cả các tác nhân giao tiếp với nhau.

Hình sau đây cho thấy Nhiều Đại lý tham gia PAC.

Applications

• Hiệu quả cho một hệ thống tương tác trong đó hệ thống có thể được phân tách thành nhiều tác nhân hợp tác theo cách phân cấp.

• Hiệu quả khi mối liên kết giữa các tác nhân dự kiến ​​sẽ lỏng lẻo để những thay đổi trên một tác nhân không ảnh hưởng đến những người khác.

• Hiệu quả cho hệ thống phân tán nơi tất cả các tác nhân được phân phối xa và mỗi tác nhân trong số chúng có các chức năng riêng với dữ liệu và giao diện tương tác.

• Thích hợp cho các ứng dụng có các thành phần GUI phong phú trong đó mỗi thành phần trong số chúng giữ dữ liệu hiện tại và giao diện tương tác của riêng mình và cần giao tiếp với các thành phần khác.

Ưu điểm

• Hỗ trợ đa tác vụ và đa chế độ xem

• Hỗ trợ khả năng tái sử dụng và khả năng mở rộng của tác nhân

• Dễ dàng cắm thêm tác nhân mới hoặc thay đổi tác nhân hiện có

• Hỗ trợ đồng thời trong đó nhiều tác nhân đang chạy song song trong các luồng khác nhau hoặc các thiết bị hoặc máy tính khác nhau

Nhược điểm

• Chi phí do cầu nối kiểm soát giữa trình bày và tóm tắt và giao tiếp các kiểm soát giữa các tác nhân.

• Khó xác định đúng số lượng đại lý vì sự liên kết lỏng lẻo và tính độc lập cao giữa các đại lý.

• Việc tách biệt hoàn toàn việc trình bày và trừu tượng hóa bằng kiểm soát trong mỗi tác nhân tạo ra sự phức tạp trong phát triển vì thông tin liên lạc giữa các tác nhân chỉ diễn ra giữa các kiểm soát của tác nhân

Trong kiến ​​trúc phân tán, các thành phần được trình bày trên các nền tảng khác nhau và một số thành phần có thể hợp tác với nhau qua mạng truyền thông để đạt được mục tiêu hoặc mục tiêu cụ thể.

• Trong kiến ​​trúc này, việc xử lý thông tin không chỉ giới hạn trong một máy duy nhất mà nó được phân phối trên nhiều máy tính độc lập.

• Một hệ thống phân tán có thể được thể hiện bằng kiến ​​trúc máy khách-máy chủ tạo thành cơ sở cho các kiến ​​trúc nhiều tầng; các lựa chọn thay thế là kiến ​​trúc môi giới như CORBA và Kiến trúc hướng dịch vụ (SOA).

• Có một số khuôn khổ công nghệ để hỗ trợ kiến ​​trúc phân tán, bao gồm các dịch vụ .NET, J2EE, CORBA, .NET Web, dịch vụ Web AXIS Java và dịch vụ Globus Grid.

• Phần mềm trung gian là cơ sở hạ tầng hỗ trợ thích hợp cho việc phát triển và thực thi các ứng dụng phân tán. Nó cung cấp một bộ đệm giữa các ứng dụng và mạng.

• Nó nằm ở giữa hệ thống và quản lý hoặc hỗ trợ các thành phần khác nhau của hệ thống phân tán. Ví dụ như bộ giám sát xử lý giao dịch, bộ chuyển đổi dữ liệu và bộ điều khiển giao tiếp, v.v.

Phần mềm trung gian làm cơ sở hạ tầng cho hệ thống phân tán

Cơ sở của kiến ​​trúc phân tán là tính minh bạch, độ tin cậy và tính khả dụng của nó.

Bảng sau liệt kê các dạng minh bạch khác nhau trong hệ thống phân tán:

Sr.No.	Tính minh bạch & mô tả
1	Access Ẩn cách thức truy cập tài nguyên và sự khác biệt trong nền tảng dữ liệu.
2	Location Ẩn nơi tài nguyên được đặt.
3	Technology Ẩn các công nghệ khác nhau như ngôn ngữ lập trình và hệ điều hành khỏi người dùng.
4	Migration / Relocation Ẩn các tài nguyên có thể được chuyển đến một vị trí khác đang được sử dụng.
5	Replication Ẩn các tài nguyên có thể được sao chép tại một số vị trí.
6	Concurrency Ẩn các tài nguyên có thể được chia sẻ với những người dùng khác.
7	Failure Ẩn lỗi và khôi phục tài nguyên từ người dùng.
số 8	Persistence Ẩn tài nguyên (phần mềm) trong bộ nhớ hay đĩa.

Ưu điểm

• Resource sharing - Chia sẻ tài nguyên phần cứng và phần mềm.

• Openness - Linh hoạt trong việc sử dụng phần cứng và phần mềm của các nhà cung cấp khác nhau.

• Concurrency - Xử lý đồng thời để nâng cao hiệu suất.

• Scalability - Tăng thông lượng bằng cách thêm tài nguyên mới.

• Fault tolerance - Khả năng tiếp tục hoạt động sau khi xảy ra sự cố.

Nhược điểm

• Complexity - Chúng phức tạp hơn các hệ thống tập trung.

• Security - Dễ bị tấn công từ bên ngoài.

• Manageability - Cần nhiều nỗ lực hơn để quản lý hệ thống.

• Unpredictability - Các phản ứng không thể đoán trước tùy thuộc vào tổ chức hệ thống và tải mạng.

Hệ thống tập trung so với Hệ thống phân tán

Tiêu chí	Hệ thống tập trung	Hệ thống phân phối
Kinh tế học	Thấp	Cao
khả dụng	Thấp	Cao
Phức tạp	Thấp	Cao
Tính nhất quán	Đơn giản	Cao
Khả năng mở rộng	Nghèo	Tốt
Công nghệ	Đồng nhất	không đồng nhất
Bảo vệ	Cao	Thấp

Kiến trúc Máy khách-Máy chủ

Kiến trúc máy khách-máy chủ là kiến ​​trúc hệ thống phân tán phổ biến nhất, phân tách hệ thống thành hai hệ thống con chính hoặc các quy trình logic -

• Client - Đây là tiến trình đầu tiên đưa ra yêu cầu đến tiến trình thứ hai tức là máy chủ.

• Server - Đây là quá trình thứ hai nhận yêu cầu, thực hiện và gửi trả lời cho khách hàng.

Trong kiến ​​trúc này, ứng dụng được mô hình hóa như một tập hợp các dịch vụ được cung cấp bởi các máy chủ và một tập hợp các khách hàng sử dụng các dịch vụ này. Máy chủ không cần biết về máy khách, nhưng máy khách phải biết danh tính của máy chủ và ánh xạ của bộ xử lý tới các quy trình không nhất thiết phải là 1: 1

Kiến trúc máy khách-máy chủ có thể được phân loại thành hai mô hình dựa trên chức năng của máy khách -

Mô hình khách hàng mỏng

Trong mô hình thin-client, tất cả quá trình xử lý ứng dụng và quản lý dữ liệu được thực hiện bởi máy chủ. Máy khách chỉ chịu trách nhiệm chạy phần mềm trình chiếu.

• Được sử dụng khi hệ thống kế thừa được di chuyển sang kiến ​​trúc máy chủ khách trong đó hệ thống kế thừa hoạt động như một máy chủ theo đúng nghĩa của nó với giao diện đồ họa được triển khai trên máy khách

• Một bất lợi lớn là nó đặt một tải xử lý nặng lên cả máy chủ và mạng.

Mô hình khách hàng dày / béo

Trong mô hình máy khách dày, máy chủ chỉ phụ trách quản lý dữ liệu. Phần mềm trên máy khách thực hiện logic ứng dụng và các tương tác với người dùng hệ thống.

• Thích hợp nhất cho các hệ thống C / S mới mà khả năng của hệ thống khách hàng đã được biết trước

• Phức tạp hơn một mô hình khách hàng mỏng đặc biệt là đối với quản lý. Các phiên bản mới của ứng dụng phải được cài đặt trên tất cả các máy khách.

Ưu điểm

• Phân tách các trách nhiệm như trình bày giao diện người dùng và xử lý logic nghiệp vụ.

• Khả năng tái sử dụng của các thành phần máy chủ và tiềm năng đồng thời

• Đơn giản hóa thiết kế và phát triển các ứng dụng phân tán

• Nó giúp dễ dàng di chuyển hoặc tích hợp các ứng dụng hiện có vào môi trường phân tán.

• Nó cũng sử dụng hiệu quả tài nguyên khi một số lượng lớn máy khách đang truy cập vào một máy chủ hiệu suất cao.

Nhược điểm

• Thiếu cơ sở hạ tầng không đồng nhất để đối phó với những thay đổi yêu cầu.

• Sự phức tạp về bảo mật.

• Tính khả dụng và độ tin cậy của máy chủ hạn chế.

• Khả năng kiểm tra và khả năng mở rộng hạn chế.

• Khách hàng béo với trình bày và logic kinh doanh cùng nhau.

Kiến trúc nhiều tầng (Kiến trúc n-tầng)

Kiến trúc đa tầng là kiến ​​trúc máy khách-máy chủ trong đó các chức năng như trình bày, xử lý ứng dụng và quản lý dữ liệu được tách biệt về mặt vật lý. Bằng cách tách một ứng dụng thành các lớp, các nhà phát triển có được tùy chọn thay đổi hoặc thêm một lớp cụ thể, thay vì làm lại toàn bộ ứng dụng. Nó cung cấp một mô hình mà các nhà phát triển có thể tạo ra các ứng dụng linh hoạt và có thể tái sử dụng.

Cách sử dụng chung nhất của kiến ​​trúc nhiều tầng là kiến ​​trúc ba tầng. Kiến trúc ba tầng thường bao gồm tầng trình bày, tầng ứng dụng và tầng lưu trữ dữ liệu và có thể thực thi trên một bộ xử lý riêng biệt.

Bậc trình bày

Lớp trình bày là cấp cao nhất của ứng dụng mà người dùng có thể truy cập trực tiếp như trang web hoặc GUI của hệ điều hành (Giao diện người dùng đồ họa). Chức năng chính của lớp này là dịch các nhiệm vụ và kết quả sang thứ mà người dùng có thể hiểu được. Nó giao tiếp với các tầng khác để đưa kết quả đến tầng trình duyệt / máy khách và tất cả các tầng khác trong mạng.

Bậc ứng dụng (Bậc logic nghiệp vụ, Bậc logic hoặc Bậc trung bình)

Tầng ứng dụng điều phối ứng dụng, xử lý các lệnh, đưa ra các quyết định logic, đánh giá và thực hiện các phép tính. Nó kiểm soát chức năng của ứng dụng bằng cách thực hiện xử lý chi tiết. Nó cũng di chuyển và xử lý dữ liệu giữa hai lớp xung quanh.

Bậc dữ liệu

Trong lớp này, thông tin được lưu trữ và truy xuất từ ​​cơ sở dữ liệu hoặc hệ thống tệp. Thông tin sau đó được chuyển trở lại để xử lý và sau đó trở lại người dùng. Nó bao gồm các cơ chế lưu trữ dữ liệu (máy chủ cơ sở dữ liệu, chia sẻ tệp, v.v.) và cung cấp API (Giao diện lập trình ứng dụng) cho tầng ứng dụng cung cấp các phương pháp quản lý dữ liệu được lưu trữ.

Advantages

• Hiệu suất tốt hơn phương pháp tiếp cận khách hàng mỏng và dễ quản lý hơn phương pháp tiếp cận khách hàng dày.

• Nâng cao khả năng tái sử dụng và khả năng mở rộng - khi nhu cầu tăng lên, các máy chủ bổ sung có thể được thêm vào.

• Cung cấp hỗ trợ đa luồng và cũng giảm lưu lượng mạng.

• Cung cấp khả năng bảo trì và tính linh hoạt

Disadvantages

• Khả năng kiểm tra không đạt yêu cầu do thiếu công cụ kiểm tra.

• Độ tin cậy và tính khả dụng của máy chủ quan trọng hơn.

Phong cách kiến ​​trúc môi giới

Broker Architectural Style là một kiến ​​trúc phần mềm trung gian được sử dụng trong máy tính phân tán để điều phối và cho phép giao tiếp giữa các máy chủ và máy khách đã đăng ký. Tại đây, giao tiếp đối tượng diễn ra thông qua một hệ thống phần mềm trung gian gọi là môi giới yêu cầu đối tượng (bus phần mềm).

• Máy khách và máy chủ không tương tác trực tiếp với nhau. Máy khách và máy chủ có một kết nối trực tiếp đến proxy của nó để giao tiếp với người trung gian-môi giới.

• Máy chủ cung cấp dịch vụ bằng cách đăng ký và xuất bản giao diện của họ với nhà môi giới và khách hàng có thể yêu cầu dịch vụ từ nhà môi giới tĩnh hoặc động bằng cách tra cứu.

• CORBA (Kiến trúc nhà môi giới yêu cầu đối tượng chung) là một ví dụ triển khai tốt của kiến ​​trúc nhà môi giới.

Các thành phần của phong cách kiến ​​trúc môi giới

Các thành phần của phong cách kiến ​​trúc môi giới được thảo luận thông qua các phần sau:

Broker

Nhà môi giới chịu trách nhiệm điều phối thông tin liên lạc, chẳng hạn như chuyển tiếp và gửi kết quả và các trường hợp ngoại lệ. Nó có thể là một dịch vụ hướng gọi, một tài liệu hoặc môi giới hướng tin nhắn mà khách hàng gửi tin nhắn.

• Nó chịu trách nhiệm môi giới các yêu cầu dịch vụ, định vị một máy chủ thích hợp, truyền yêu cầu và gửi phản hồi lại cho khách hàng.

• Nó giữ lại thông tin đăng ký của máy chủ bao gồm chức năng và dịch vụ cũng như thông tin vị trí.

• Nó cung cấp các API để máy khách yêu cầu, máy chủ phản hồi, đăng ký hoặc hủy đăng ký các thành phần máy chủ, chuyển thông báo và định vị máy chủ.

Stub

Stubs được tạo tại thời điểm biên dịch tĩnh và sau đó được triển khai cho phía máy khách được sử dụng làm proxy cho máy khách. Proxy phía máy khách hoạt động như một người trung gian giữa khách hàng và nhà môi giới và cung cấp thêm sự minh bạch giữa họ và khách hàng; một đối tượng từ xa xuất hiện giống như một đối tượng cục bộ.

Proxy ẩn IPC (giao tiếp giữa các quá trình) ở cấp giao thức và thực hiện việc sắp xếp các giá trị tham số và bỏ sắp xếp các kết quả từ máy chủ.

Skeleton

Skeleton được tạo ra bởi quá trình biên dịch giao diện dịch vụ và sau đó được triển khai tới phía máy chủ, được sử dụng làm proxy cho máy chủ. Proxy phía máy chủ đóng gói các chức năng mạng cấp thấp dành riêng cho hệ thống và cung cấp các API cấp cao để làm trung gian giữa máy chủ và nhà môi giới.

Nó nhận các yêu cầu, giải nén các yêu cầu, giải nén các đối số của phương thức, gọi dịch vụ phù hợp và cũng sắp xếp kết quả trước khi gửi nó trở lại máy khách.

Bridge

Một cầu nối có thể kết nối hai mạng khác nhau dựa trên các giao thức truyền thông khác nhau. Nó làm trung gian cho các nhà môi giới khác nhau bao gồm các nhà môi giới DCOM, .NET từ xa và Java CORBA.

Cầu nối là thành phần tùy chọn, ẩn các chi tiết triển khai khi hai nhà môi giới tương tác với nhau và nhận các yêu cầu và tham số ở một định dạng và dịch chúng sang định dạng khác.

Broker implementation in CORBA

CORBA là tiêu chuẩn quốc tế cho Nhà môi giới yêu cầu đối tượng - một phần mềm trung gian để quản lý thông tin liên lạc giữa các đối tượng phân tán được xác định bởi OMG (nhóm quản lý đối tượng).

Kiến trúc hướng dịch vụ (SOA)

Dịch vụ là một thành phần của chức năng nghiệp vụ được xác định rõ ràng, khép kín, độc lập, được xuất bản và có sẵn để sử dụng thông qua giao diện lập trình tiêu chuẩn. Kết nối giữa các dịch vụ được thực hiện bởi các giao thức hướng thông điệp chung và phổ biến như giao thức dịch vụ Web SOAP, có thể đưa ra các yêu cầu và phản hồi giữa các dịch vụ một cách lỏng lẻo.

Kiến trúc hướng dịch vụ là thiết kế máy khách / máy chủ hỗ trợ cách tiếp cận CNTT theo hướng kinh doanh, trong đó ứng dụng bao gồm các dịch vụ phần mềm và người tiêu dùng dịch vụ phần mềm (còn được gọi là khách hàng hoặc người yêu cầu dịch vụ).

Đặc điểm của SOA

Kiến trúc hướng dịch vụ cung cấp các tính năng sau:

• Distributed Deployment - Thể hiện dữ liệu doanh nghiệp và logic nghiệp vụ dưới dạng các đơn vị chức năng không trạng thái, được kết hợp, có thể khám phá, có cấu trúc, dựa trên tiêu chuẩn, được gọi là dịch vụ.

• Composability - Tập hợp các quy trình mới từ các dịch vụ hiện có được hiển thị ở mức độ chi tiết mong muốn thông qua các giao diện khiếu nại được xác định rõ ràng, xuất bản và tiêu chuẩn.

• Interoperability - Chia sẻ khả năng và sử dụng lại các dịch vụ được chia sẻ trên một mạng không phân biệt các giao thức cơ bản hoặc công nghệ triển khai.

• Reusability - Chọn một nhà cung cấp dịch vụ và truy cập vào các tài nguyên hiện có được hiển thị dưới dạng dịch vụ.

Hoạt động SOA

Hình sau minh họa cách SOA hoạt động:

Advantages

• Sự kết hợp lỏng lẻo giữa định hướng dịch vụ mang lại sự linh hoạt tuyệt vời cho các doanh nghiệp trong việc sử dụng tất cả các khoản hoàn vốn dịch vụ có sẵn bất kể các hạn chế về nền tảng và công nghệ.

• Mỗi thành phần dịch vụ độc lập với các dịch vụ khác do tính năng dịch vụ không trạng thái.

• Việc triển khai một dịch vụ sẽ không ảnh hưởng đến ứng dụng của dịch vụ miễn là giao diện tiếp xúc không bị thay đổi.

• Khách hàng hoặc bất kỳ dịch vụ nào có thể truy cập các dịch vụ khác bất kể nền tảng, công nghệ, nhà cung cấp hoặc triển khai ngôn ngữ của họ.

• Khả năng tái sử dụng của tài sản và dịch vụ vì khách hàng của một dịch vụ chỉ cần biết các giao diện công khai, thành phần dịch vụ của nó.

• Phát triển ứng dụng kinh doanh dựa trên SOA hiệu quả hơn nhiều về thời gian và chi phí.

• Nâng cao khả năng mở rộng và cung cấp kết nối tiêu chuẩn giữa các hệ thống.

• Sử dụng hiệu quả và hiệu quả 'Dịch vụ Kinh doanh'.

• Việc tích hợp trở nên dễ dàng hơn nhiều và cải thiện khả năng tương tác nội tại.

• Sự phức tạp trừu tượng cho các nhà phát triển và tiếp thêm năng lượng cho các quy trình kinh doanh gần gũi hơn với người dùng cuối.

Kiến trúc dựa trên thành phần tập trung vào việc phân rã thiết kế thành các thành phần chức năng hoặc logic riêng lẻ đại diện cho các giao diện truyền thông được xác định rõ có chứa các phương thức, sự kiện và thuộc tính. Nó cung cấp mức độ trừu tượng cao hơn và chia vấn đề thành các vấn đề con, mỗi vấn đề được liên kết với các phân vùng thành phần.

Mục tiêu chính của kiến ​​trúc dựa trên thành phần là đảm bảo component reusability. Một thành phần đóng gói chức năng và hành vi của một phần tử phần mềm thành một đơn vị nhị phân có thể tái sử dụng và tự triển khai. Có nhiều khuôn khổ thành phần tiêu chuẩn như COM / DCOM, JavaBean, EJB, CORBA, .NET, dịch vụ web và dịch vụ lưới. Những công nghệ này được sử dụng rộng rãi trong thiết kế ứng dụng GUI cục bộ trên máy tính để bàn như các thành phần JavaBean đồ họa, các thành phần MS ActiveX và các thành phần COM có thể được sử dụng lại bằng thao tác kéo và thả đơn giản.

Thiết kế phần mềm hướng thành phần có nhiều ưu điểm so với các phương pháp tiếp cận hướng đối tượng truyền thống như:

• Giảm thời gian trên thị trường và chi phí phát triển bằng cách sử dụng lại các thành phần hiện có.

• Tăng độ tin cậy với việc tái sử dụng các thành phần hiện có.

Thành phần là gì?

Thành phần là một tập hợp chức năng được xác định rõ theo mô-đun, di động, có thể thay thế và tái sử dụng, đóng gói việc triển khai nó và xuất nó dưới dạng giao diện cấp cao hơn.

Thành phần là một đối tượng phần mềm, nhằm tương tác với các thành phần khác, đóng gói chức năng nhất định hoặc một tập hợp các chức năng. Nó có một giao diện được xác định rõ ràng và tuân theo một hành vi được khuyến nghị chung cho tất cả các thành phần trong một kiến ​​trúc.

Một thành phần phần mềm có thể được định nghĩa là một đơn vị cấu thành có giao diện được chỉ định theo hợp đồng và chỉ phụ thuộc ngữ cảnh rõ ràng. Nghĩa là, một thành phần phần mềm có thể được triển khai độc lập và chịu sự chi phối của các bên thứ ba.

Chế độ xem của một thành phần

Một thành phần có thể có ba dạng xem khác nhau - dạng xem hướng đối tượng, dạng xem thông thường và dạng xem liên quan đến quá trình.

Object-oriented view

Một thành phần được xem như một tập hợp một hoặc nhiều lớp hợp tác. Mỗi lớp miền vấn đề (phân tích) và lớp cơ sở hạ tầng (thiết kế) được giải thích để xác định tất cả các thuộc tính và hoạt động áp dụng cho việc triển khai của nó. Nó cũng liên quan đến việc xác định các giao diện cho phép các lớp giao tiếp và hợp tác.

Conventional view

Nó được xem như một phần tử chức năng hoặc một mô-đun của chương trình tích hợp logic xử lý, các cấu trúc dữ liệu bên trong được yêu cầu để thực hiện logic xử lý và một giao diện cho phép thành phần được gọi và dữ liệu được truyền đến nó.

Process-related view

Theo quan điểm này, thay vì tạo từng thành phần từ đầu, hệ thống đang xây dựng từ các thành phần hiện có được duy trì trong thư viện. Khi cấu trúc phần mềm được xây dựng, các thành phần được chọn từ thư viện và được sử dụng để đưa vào kiến ​​trúc.

• Thành phần giao diện người dùng (UI) bao gồm các lưới, các nút được gọi là điều khiển và các thành phần tiện ích hiển thị một tập hợp con cụ thể của các chức năng được sử dụng trong các thành phần khác.

• Các loại thành phần phổ biến khác là những thành phần sử dụng nhiều tài nguyên, không được truy cập thường xuyên và phải được kích hoạt bằng cách sử dụng phương pháp tiếp cận đúng lúc (JIT).

• Nhiều thành phần là vô hình được phân phối trong các ứng dụng kinh doanh doanh nghiệp và ứng dụng web internet như Enterprise JavaBean (EJB), các thành phần .NET và các thành phần CORBA.

Đặc điểm của các thành phần

• Reusability- Các thành phần thường được thiết kế để sử dụng lại trong các tình huống khác nhau trong các ứng dụng khác nhau. Tuy nhiên, một số thành phần có thể được thiết kế cho một nhiệm vụ cụ thể.

• Replaceable - Các thành phần có thể được thay thế tự do bằng các thành phần tương tự khác.

• Not context specific - Các thành phần được thiết kế để hoạt động trong các môi trường và bối cảnh khác nhau.

• Extensible - Một thành phần có thể được mở rộng từ các thành phần hiện có để cung cấp hành vi mới.

• Encapsulated - Thành phần AA mô tả các giao diện cho phép người gọi sử dụng chức năng của nó và không tiết lộ chi tiết về các quy trình nội bộ hoặc bất kỳ biến hoặc trạng thái nội bộ nào.

• Independent - Các thành phần được thiết kế để có sự phụ thuộc tối thiểu vào các thành phần khác.

Nguyên tắc thiết kế dựa trên thành phần

Một thiết kế cấp thành phần có thể được biểu diễn bằng cách sử dụng một số biểu diễn trung gian (ví dụ: đồ họa, bảng hoặc dựa trên văn bản) có thể được dịch sang mã nguồn. Việc thiết kế cấu trúc dữ liệu, giao diện và thuật toán phải tuân theo các nguyên tắc đã được thiết lập tốt để giúp chúng tôi tránh đưa vào lỗi.

• Hệ thống phần mềm được phân rã thành các đơn vị thành phần có thể tái sử dụng, gắn kết và đóng gói.

• Mỗi thành phần có giao diện riêng chỉ định các cổng yêu cầu và các cổng được cung cấp; mỗi thành phần ẩn việc triển khai chi tiết của nó.

• Một thành phần nên được mở rộng mà không cần thực hiện mã nội bộ hoặc sửa đổi thiết kế cho các phần hiện có của thành phần.

• Sự phụ thuộc vào thành phần trừu tượng không phụ thuộc vào các thành phần bê tông khác, điều này làm tăng khó khăn trong khả năng sử dụng.

• Kết nối các thành phần kết nối, xác định và điều khiển sự tương tác giữa các thành phần. Kiểu tương tác được xác định bởi các giao diện của các thành phần.

• Tương tác các thành phần có thể ở dạng lệnh gọi phương thức, lệnh gọi không đồng bộ, phát sóng, tương tác theo hướng tin nhắn, truyền thông luồng dữ liệu và các tương tác cụ thể của giao thức khác.

• Đối với một lớp máy chủ, các giao diện chuyên biệt nên được tạo ra để phục vụ các loại máy khách chính. Chỉ những hoạt động có liên quan đến một danh mục khách hàng cụ thể mới nên được chỉ định trong giao diện.

• Một thành phần có thể mở rộng đến các thành phần khác và vẫn cung cấp các điểm mở rộng của riêng nó. Đó là khái niệm về kiến ​​trúc dựa trên trình cắm thêm. Điều này cho phép một plugin cung cấp một API plugin khác.

Nguyên tắc thiết kế cấp thành phần

Tạo quy ước đặt tên cho các thành phần được chỉ định như một phần của mô hình kiến ​​trúc và sau đó tinh chỉnh hoặc xây dựng như một phần của mô hình mức thành phần.

• Đính kèm các tên thành phần kiến ​​trúc từ miền vấn đề và đảm bảo rằng chúng có ý nghĩa đối với tất cả các bên liên quan xem mô hình kiến ​​trúc.

• Trích xuất các thực thể của quá trình kinh doanh có thể tồn tại độc lập mà không có bất kỳ sự phụ thuộc liên quan nào vào các thực thể khác.

• Nhận biết và khám phá các thực thể độc lập này như các thành phần mới.

• Sử dụng tên thành phần cơ sở hạ tầng phản ánh ý nghĩa cụ thể về việc triển khai của chúng.

• Mô hình hóa bất kỳ phụ thuộc nào từ trái sang phải và kế thừa từ trên cùng (lớp cơ sở) xuống dưới (lớp dẫn xuất).

• Mô hình hóa bất kỳ phụ thuộc thành phần nào dưới dạng giao diện thay vì biểu diễn chúng dưới dạng phụ thuộc thành phần trực tiếp.

Tiến hành thiết kế cấp thành phần

Nhận biết tất cả các lớp thiết kế tương ứng với miền vấn đề như được định nghĩa trong mô hình phân tích và mô hình kiến ​​trúc.

• Nhận biết tất cả các lớp thiết kế tương ứng với miền cơ sở hạ tầng.

• Mô tả tất cả các lớp thiết kế không được lấy làm thành phần có thể sử dụng lại và chỉ định chi tiết thông báo.

• Xác định các giao diện thích hợp cho từng thành phần và xây dựng các thuộc tính và xác định các kiểu dữ liệu và cấu trúc dữ liệu cần thiết để triển khai chúng.

• Mô tả chi tiết luồng xử lý trong từng thao tác bằng mã giả hoặc sơ đồ hoạt động UML.

• Mô tả các nguồn dữ liệu liên tục (cơ sở dữ liệu và tệp) và xác định các lớp cần thiết để quản lý chúng.

• Phát triển và xây dựng các biểu diễn hành vi cho một lớp hoặc thành phần. Điều này có thể được thực hiện bằng cách xây dựng biểu đồ trạng thái UML được tạo cho mô hình phân tích và bằng cách kiểm tra tất cả các trường hợp sử dụng có liên quan đến lớp thiết kế.

• Lập sơ đồ triển khai để cung cấp thêm chi tiết triển khai.

• Thể hiện vị trí của các gói hoặc lớp chính của các thành phần trong hệ thống bằng cách sử dụng các thể hiện của lớp và chỉ định môi trường phần cứng và hệ điều hành cụ thể.

• Quyết định cuối cùng có thể được thực hiện bằng cách sử dụng các nguyên tắc và hướng dẫn thiết kế đã được thiết lập. Các nhà thiết kế có kinh nghiệm xem xét tất cả (hoặc hầu hết) các giải pháp thiết kế thay thế trước khi quyết định mô hình thiết kế cuối cùng.

Ưu điểm

• Ease of deployment - Khi có phiên bản tương thích mới, việc thay thế các phiên bản hiện có sẽ dễ dàng hơn mà không ảnh hưởng đến các thành phần khác hoặc toàn bộ hệ thống.

• Reduced cost - Việc sử dụng các thành phần của bên thứ ba cho phép bạn phân bổ chi phí phát triển và bảo trì.

• Ease of development - Các thành phần triển khai các giao diện nổi tiếng để cung cấp chức năng xác định, cho phép phát triển mà không ảnh hưởng đến các phần khác của hệ thống.

• Reusable - Việc sử dụng các thành phần có thể tái sử dụng có nghĩa là chúng có thể được sử dụng để phân bổ chi phí phát triển và bảo trì trên một số ứng dụng hoặc hệ thống.

• Modification of technical complexity - Một thành phần sửa đổi độ phức tạp thông qua việc sử dụng một vùng chứa thành phần và các dịch vụ của nó.

• Reliability - Độ tin cậy tổng thể của hệ thống tăng lên do độ tin cậy của từng thành phần riêng lẻ nâng cao độ tin cậy của toàn hệ thống thông qua việc tái sử dụng.

• System maintenance and evolution - Dễ dàng thay đổi và cập nhật việc thực hiện mà không ảnh hưởng đến phần còn lại của hệ thống.

• Independent- Tính độc lập và khả năng kết nối linh hoạt của các thành phần. Phát triển độc lập các thành phần theo nhóm khác nhau song song. Năng suất cho việc phát triển phần mềm và phát triển phần mềm trong tương lai.

Giao diện người dùng là ấn tượng đầu tiên về một hệ thống phần mềm theo quan điểm của người dùng. Do đó bất kỳ hệ thống phần mềm nào cũng phải đáp ứng yêu cầu của người sử dụng. UI chủ yếu thực hiện hai chức năng -

• Chấp nhận đầu vào của người dùng

• Hiển thị đầu ra

Giao diện người dùng đóng một vai trò quan trọng trong bất kỳ hệ thống phần mềm nào. Nó có thể là khía cạnh duy nhất có thể nhìn thấy của một hệ thống phần mềm như -

• Ban đầu người dùng sẽ nhìn thấy kiến ​​trúc của giao diện người dùng bên ngoài của hệ thống phần mềm mà không cần xem xét kiến ​​trúc bên trong của nó.

• Một giao diện người dùng tốt phải thu hút người dùng sử dụng hệ thống phần mềm mà không mắc lỗi. Nó sẽ giúp người dùng hiểu hệ thống phần mềm một cách dễ dàng mà không làm sai lệch thông tin. Một giao diện người dùng không tốt có thể gây ra thất bại trên thị trường trước sự cạnh tranh của hệ thống phần mềm.

• Giao diện người dùng có cú pháp và ngữ nghĩa của nó. Cú pháp bao gồm các loại thành phần như văn bản, biểu tượng, nút, v.v. và khả năng sử dụng tóm tắt ngữ nghĩa của giao diện người dùng. Chất lượng của giao diện người dùng được đặc trưng bởi giao diện (cú pháp) và khả năng sử dụng (ngữ nghĩa) của nó.

• Về cơ bản có hai loại giao diện người dùng chính - a) Dạng văn bản b) Đồ họa.

• Phần mềm trong các miền khác nhau có thể yêu cầu kiểu giao diện người dùng khác nhau, ví dụ như máy tính chỉ cần một khu vực nhỏ để hiển thị số, nhưng một khu vực lớn cho các lệnh, một trang web cần biểu mẫu, liên kết, tab, v.v.

Giao diện đồ họa người dùng

Giao diện người dùng đồ họa là loại giao diện người dùng phổ biến nhất hiện nay. Nó rất thân thiện với người dùng vì nó sử dụng hình ảnh, đồ họa và biểu tượng - do đó tại sao nó được gọi là 'đồ họa'.

Nó còn được gọi là WIMP interface bởi vì nó sử dụng -

• Windows - Một vùng hình chữ nhật trên màn hình nơi chạy các ứng dụng thường dùng.

• Icons - Hình ảnh hoặc biểu tượng được sử dụng để đại diện cho một ứng dụng phần mềm hoặc thiết bị phần cứng.

• Menus - Danh sách các tùy chọn mà từ đó người dùng có thể chọn những gì họ yêu cầu.

• Pointers- Một biểu tượng như mũi tên di chuyển xung quanh màn hình khi người dùng di chuyển chuột. Nó giúp người dùng chọn đối tượng.

Thiết kế giao diện người dùng

Nó bắt đầu với phân tích nhiệm vụ hiểu các nhiệm vụ chính của người dùng và miền vấn đề. Nó nên được thiết kế theo thuật ngữ của Người dùng và khởi đầu công việc của người dùng hơn là của lập trình viên.

• Để thực hiện phân tích giao diện người dùng, người hành nghề cần nghiên cứu và hiểu rõ bốn yếu tố:

  • Các users ai sẽ tương tác với hệ thống thông qua giao diện

  • Các tasks mà người dùng cuối phải thực hiện để làm công việc của họ

  • Các content được trình bày như một phần của giao diện

  • Các work environment trong đó những nhiệm vụ này sẽ được tiến hành

• Thiết kế giao diện người dùng phù hợp hay tốt hoạt động dựa trên khả năng của người dùng và giới hạn chứ không phải do máy móc. Trong khi thiết kế giao diện người dùng, kiến ​​thức về bản chất công việc và môi trường của người dùng cũng rất quan trọng.

• Sau đó, nhiệm vụ được thực hiện có thể được phân chia được giao cho người dùng hoặc máy móc, dựa trên kiến ​​thức về khả năng và giới hạn của từng loại. Thiết kế giao diện người dùng thường được chia thành bốn cấp độ khác nhau -

  • The conceptual level - Nó mô tả các thực thể cơ bản xem xét cách nhìn của người dùng về hệ thống và các hành động có thể xảy ra đối với chúng.

  • The semantic level - Nó mô tả các chức năng được thực hiện bởi hệ thống tức là mô tả các yêu cầu chức năng của hệ thống, nhưng không giải quyết cách người dùng sẽ gọi các chức năng.

  • The syntactic level - Nó mô tả trình tự đầu vào và đầu ra cần thiết để gọi các chức năng được mô tả.

  • The lexical level - Nó xác định cách các đầu vào và đầu ra thực sự được hình thành từ các hoạt động phần cứng nguyên thủy.

• Thiết kế giao diện người dùng là một quá trình lặp lại, trong đó tất cả các lần lặp lại giải thích và tinh chỉnh thông tin được phát triển trong các bước trước đó. Các bước chung để thiết kế giao diện người dùng

• Xác định các đối tượng giao diện người dùng và các hành động (hoạt động).

• Xác định các sự kiện (hành động của người dùng) sẽ khiến trạng thái của giao diện người dùng thay đổi.

• Cho biết cách người dùng diễn giải trạng thái của hệ thống từ thông tin được cung cấp qua giao diện.

• Mô tả từng trạng thái giao diện vì nó sẽ thực sự nhìn vào người dùng cuối.

Quy trình phát triển giao diện người dùng

Nó tuân theo một quá trình xoắn ốc như thể hiện trong sơ đồ sau:



Interface analysis

Nó tập trung hoặc tập trung vào người dùng, nhiệm vụ, nội dung và môi trường làm việc, những người sẽ tương tác với hệ thống. Xác định các nhiệm vụ hướng đến con người và máy tính được yêu cầu để đạt được chức năng của hệ thống.

Interface design

Nó xác định một tập hợp các đối tượng giao diện, các hành động và các biểu diễn trên màn hình của chúng cho phép người dùng thực hiện tất cả các tác vụ đã xác định theo cách đáp ứng mọi mục tiêu về khả năng sử dụng được xác định cho hệ thống.

Interface construction

Nó bắt đầu với một nguyên mẫu cho phép đánh giá các kịch bản sử dụng và tiếp tục với các công cụ phát triển để hoàn thành việc xây dựng.

Interface validation

Nó tập trung vào khả năng của giao diện để thực hiện mọi tác vụ của người dùng một cách chính xác, phù hợp với tất cả các biến thể nhiệm vụ, để đạt được tất cả các yêu cầu chung của người dùng và mức độ mà giao diện dễ sử dụng và dễ học.

User Interface Models

Khi giao diện người dùng được phân tích và thiết kế theo bốn mô hình được sử dụng:

User profile model

• Được tạo bởi người dùng hoặc kỹ sư phần mềm, thiết lập hồ sơ của người dùng cuối của hệ thống dựa trên độ tuổi, giới tính, khả năng thể chất, học vấn, động lực, mục tiêu và tính cách.

• Xem xét kiến ​​thức về cú pháp và ngữ nghĩa của người dùng và phân loại người dùng là người mới sử dụng, người dùng không liên tục và có kiến ​​thức.

Design model

• Được tạo bởi một kỹ sư phần mềm, kết hợp các biểu diễn dữ liệu, kiến ​​trúc, giao diện và thủ tục của phần mềm.

• Bắt nguồn từ mô hình phân tích các yêu cầu và được kiểm soát bởi thông tin trong đặc tả yêu cầu giúp xác định người dùng của hệ thống.

Implementation model

• Được tạo bởi những người triển khai phần mềm làm việc dựa trên giao diện kết hợp với tất cả thông tin hỗ trợ (sách, video, tệp trợ giúp) mô tả cú pháp và ngữ nghĩa của hệ thống.

• Đóng vai trò là bản dịch mô hình thiết kế và cố gắng thống nhất với mô hình tinh thần của người dùng để người dùng sau đó cảm thấy thoải mái với phần mềm và sử dụng nó một cách hiệu quả.

User's mental model

• Do người dùng tạo ra khi tương tác với ứng dụng. Nó chứa hình ảnh của hệ thống mà người dùng mang trong đầu.

• Thường được gọi là nhận thức hệ thống của người dùng và tính đúng đắn của mô tả phụ thuộc vào hồ sơ của người dùng và sự quen thuộc tổng thể với phần mềm trong miền ứng dụng.

Cân nhắc thiết kế của giao diện người dùng

Lấy người dùng làm trung tâm

Giao diện người dùng phải là sản phẩm lấy người dùng làm trung tâm, liên quan đến người dùng trong suốt vòng đời phát triển của sản phẩm. Nguyên mẫu của giao diện người dùng nên có sẵn cho người dùng và phản hồi từ người dùng, nên được kết hợp vào sản phẩm cuối cùng.

Đơn giản và Trực quan

Giao diện người dùng cung cấp sự đơn giản và trực quan để có thể sử dụng nhanh chóng và hiệu quả mà không cần hướng dẫn. GUI tốt hơn giao diện người dùng văn bản, vì GUI bao gồm các menu, cửa sổ và các nút và được vận hành đơn giản bằng chuột.

Đặt người dùng vào quyền kiểm soát

Không bắt buộc người dùng phải hoàn thành các trình tự được xác định trước. Cung cấp cho họ các tùy chọn — để hủy hoặc lưu và quay lại nơi họ đã dừng lại. Sử dụng các điều khoản trên toàn giao diện mà người dùng có thể hiểu được, thay vì các điều khoản của hệ thống hoặc nhà phát triển.

Cung cấp cho người dùng một số dấu hiệu cho thấy một hành động đã được thực hiện, bằng cách hiển thị cho họ kết quả của hành động hoặc thừa nhận rằng hành động đã diễn ra thành công.

Minh bạch

Giao diện người dùng phải trong suốt giúp người dùng cảm thấy như họ đang tiếp cận ngay trên máy tính và thao tác trực tiếp với các đối tượng mà họ đang làm việc. Giao diện có thể được làm trong suốt bằng cách cung cấp cho người dùng các đối tượng công việc hơn là đối tượng hệ thống. Ví dụ, người dùng nên hiểu rằng mật khẩu hệ thống của họ phải có ít nhất 6 ký tự, không phải mật khẩu phải có bao nhiêu byte dung lượng.

Sử dụng tiết lộ tiến bộ

Luôn cung cấp khả năng truy cập dễ dàng vào các tính năng phổ biến và các hành động thường dùng. Ẩn các tính năng và hành động ít phổ biến hơn và cho phép người dùng điều hướng chúng. Đừng cố gắng đưa mọi thông tin vào một cửa sổ chính. Sử dụng cửa sổ phụ cho thông tin không phải là thông tin chính.

Tính nhất quán

Giao diện người dùng duy trì tính nhất quán trong và trên toàn bộ sản phẩm, giữ cho kết quả tương tác giống nhau, các lệnh và menu giao diện người dùng phải có cùng định dạng, dấu câu lệnh phải giống nhau và các tham số phải được truyền cho tất cả các lệnh theo cùng một cách. Giao diện người dùng không nên có các hành vi có thể gây ngạc nhiên cho người dùng và nên bao gồm các cơ chế cho phép người dùng khôi phục sau những sai lầm của họ.

Hội nhập

Hệ thống phần mềm phải tích hợp trơn tru với các ứng dụng khác như MS notepad và MS-Office. Nó có thể sử dụng các lệnh Clipboard trực tiếp để thực hiện trao đổi dữ liệu.

Định hướng thành phần

Thiết kế giao diện người dùng phải theo mô-đun và kết hợp kiến ​​trúc hướng thành phần để thiết kế giao diện người dùng sẽ có các yêu cầu tương tự như thiết kế phần thân chính của hệ thống phần mềm. Các mô-đun có thể dễ dàng được sửa đổi và thay thế mà không ảnh hưởng đến các bộ phận khác của hệ thống.

Có thể tùy chỉnh

Kiến trúc của toàn bộ hệ thống phần mềm kết hợp các mô-đun plug-in, cho phép nhiều người khác nhau mở rộng phần mềm một cách độc lập. Nó cho phép người dùng cá nhân chọn từ các hình thức có sẵn khác nhau để phù hợp với sở thích và nhu cầu cá nhân.

Giảm tải bộ nhớ của người dùng

Không bắt người dùng phải nhớ và lặp lại những gì máy tính phải làm cho họ. Ví dụ: khi điền vào các biểu mẫu trực tuyến, tên, địa chỉ và số điện thoại của khách hàng phải được hệ thống ghi nhớ sau khi người dùng nhập chúng hoặc khi hồ sơ khách hàng đã được mở.

Giao diện người dùng hỗ trợ truy xuất bộ nhớ dài hạn bằng cách cung cấp cho người dùng các mục để họ nhận ra thay vì phải nhớ lại thông tin.

Tách biệt

UI phải được tách biệt khỏi logic của hệ thống thông qua việc triển khai nó để tăng khả năng tái sử dụng và khả năng bảo trì.

Phương pháp tiếp cận lặp đi lặp lại và gia tăng

Đây là một cách tiếp cận lặp đi lặp lại và gia tăng bao gồm năm bước chính giúp tạo ra các giải pháp ứng viên. Giải pháp ứng cử viên này có thể được hoàn thiện hơn nữa bằng cách lặp lại các bước này và cuối cùng tạo ra một thiết kế kiến ​​trúc phù hợp nhất với ứng dụng của chúng tôi. Vào cuối quá trình, chúng tôi có thể xem xét và truyền đạt kiến ​​trúc của mình cho tất cả các bên quan tâm.

Nó chỉ là một cách tiếp cận khả thi. Có nhiều cách tiếp cận khác chính thức hơn để xác định, xem xét và truyền đạt kiến ​​trúc của bạn.

Xác định mục tiêu kiến ​​trúc

Xác định mục tiêu kiến ​​trúc hình thành quy trình kiến ​​trúc và thiết kế. Các mục tiêu hoàn hảo và được xác định nhấn mạnh vào kiến ​​trúc, giải quyết đúng các vấn đề trong thiết kế và giúp xác định khi nào giai đoạn hiện tại đã hoàn thành và sẵn sàng chuyển sang giai đoạn tiếp theo.

Bước này bao gồm các hoạt động sau:

• Xác định mục tiêu kiến ​​trúc của bạn ngay từ đầu.
• Xác định khách hàng của kiến ​​trúc của chúng tôi.
• Xác định các ràng buộc.

Ví dụ về các hoạt động kiến ​​trúc bao gồm xây dựng mẫu thử nghiệm để nhận phản hồi về giao diện người dùng xử lý đơn đặt hàng cho ứng dụng Web, xây dựng ứng dụng theo dõi đơn đặt hàng của khách hàng và thiết kế kiến ​​trúc xác thực và ủy quyền cho ứng dụng để thực hiện đánh giá bảo mật.

Các tình huống chính

Bước này nhấn mạnh vào thiết kế quan trọng nhất. Một kịch bản là một mô tả bao quát và bao quát về sự tương tác của người dùng với hệ thống.

Các kịch bản chính là những kịch bản được coi là những kịch bản quan trọng nhất cho sự thành công của ứng dụng của bạn. Nó giúp đưa ra quyết định về kiến ​​trúc. Mục tiêu là đạt được sự cân bằng giữa các mục tiêu người dùng, doanh nghiệp và hệ thống. Ví dụ: xác thực người dùng là một kịch bản quan trọng vì chúng là giao điểm của thuộc tính chất lượng (bảo mật) với chức năng quan trọng (cách người dùng đăng nhập vào hệ thống của bạn).

Tổng quan về ứng dụng

Xây dựng tổng quan về ứng dụng, giúp kiến ​​trúc dễ chạm hơn, kết nối nó với các ràng buộc và quyết định trong thế giới thực. Nó bao gồm các hoạt động sau:

Xác định loại ứng dụng

Xác định loại ứng dụng cho dù đó là ứng dụng dành cho thiết bị di động, ứng dụng khách đa dạng, ứng dụng internet phong phú, dịch vụ, ứng dụng web hoặc một số kết hợp của các loại này.

Xác định các ràng buộc khi triển khai

Chọn một cấu trúc liên kết triển khai thích hợp và giải quyết xung đột giữa ứng dụng và cơ sở hạ tầng mục tiêu.

Xác định các kiểu thiết kế kiến ​​trúc quan trọng

Xác định các phong cách thiết kế kiến ​​trúc quan trọng như máy khách / máy chủ, phân lớp, bus thông báo, thiết kế hướng miền, v.v. để cải thiện việc phân vùng và thúc đẩy tái sử dụng thiết kế bằng cách cung cấp giải pháp cho các vấn đề thường xuyên lặp lại. Các ứng dụng thường sẽ sử dụng kết hợp nhiều kiểu.

Xác định các công nghệ có liên quan

Xác định các công nghệ có liên quan bằng cách xem xét loại ứng dụng chúng tôi đang phát triển, các tùy chọn ưu tiên của chúng tôi cho cấu trúc liên kết triển khai ứng dụng và kiểu kiến ​​trúc. Việc lựa chọn công nghệ cũng sẽ được định hướng bởi các chính sách của tổ chức, các giới hạn về cơ sở hạ tầng, kỹ năng nguồn lực, v.v.

Các vấn đề chính hoặc điểm nóng chính

Trong khi thiết kế một ứng dụng, các điểm nóng là khu vực thường mắc lỗi nhất. Xác định các vấn đề chính dựa trên các thuộc tính chất lượng và các mối quan tâm đan xen. Các vấn đề tiềm ẩn bao gồm sự xuất hiện của công nghệ mới và các yêu cầu kinh doanh quan trọng.

Thuộc tính chất lượng là các tính năng tổng thể của kiến ​​trúc ảnh hưởng đến hành vi trong thời gian chạy, thiết kế hệ thống và trải nghiệm người dùng. Mối quan tâm về việc cắt ngang là các đặc điểm trong thiết kế của chúng tôi có thể áp dụng trên tất cả các lớp, thành phần và tầng.

Đây cũng là những lĩnh vực mà các lỗi thiết kế có tác động cao thường mắc phải nhất. Ví dụ về các mối quan tâm liên quan đến xác thực và ủy quyền, giao tiếp, quản lý cấu hình, quản lý ngoại lệ và xác thực, v.v.

Giải pháp ứng viên

Sau khi xác định các điểm nóng chính, hãy xây dựng kiến ​​trúc đường cơ sở ban đầu hoặc thiết kế cấp cao đầu tiên và sau đó bắt đầu điền vào các chi tiết để tạo ra kiến ​​trúc ứng viên.

Kiến trúc ứng viên bao gồm loại ứng dụng, kiến ​​trúc triển khai, phong cách kiến ​​trúc, lựa chọn công nghệ, thuộc tính chất lượng và các mối quan tâm đan xen. Nếu kiến ​​trúc ứng viên là một cải tiến, thì nó có thể trở thành đường cơ sở mà từ đó kiến ​​trúc ứng viên mới có thể được tạo và thử nghiệm.

Xác thực thiết kế giải pháp ứng viên dựa trên các tình huống và yêu cầu chính đã được xác định trước khi lặp lại theo chu trình và cải tiến thiết kế.

Chúng tôi có thể sử dụng các gai kiến ​​trúc để khám phá các khu vực cụ thể của thiết kế hoặc để xác nhận các khái niệm mới. Các gai kiến ​​trúc là một nguyên mẫu thiết kế, xác định tính khả thi của một con đường thiết kế cụ thể, giảm rủi ro và nhanh chóng xác định khả năng tồn tại của các phương pháp tiếp cận khác nhau. Kiểm tra đột biến kiến ​​trúc đối với các kịch bản và điểm nóng chính.

Đánh giá kiến ​​trúc

Rà soát kiến ​​trúc là nhiệm vụ quan trọng nhất để giảm chi phí sai sót và tìm ra và sửa chữa các vấn đề kiến ​​trúc càng sớm càng tốt. Đó là một cách hiệu quả, được thiết lập tốt để giảm chi phí dự án và khả năng thất bại của dự án.

• Thường xuyên xem lại kiến ​​trúc tại các mốc quan trọng của dự án và để ứng phó với những thay đổi kiến ​​trúc quan trọng khác.

• Mục tiêu chính của đánh giá kiến ​​trúc là xác định tính khả thi của các kiến ​​trúc cơ sở và ứng viên, xác minh kiến ​​trúc đó một cách chính xác.

• Liên kết các yêu cầu chức năng và các thuộc tính chất lượng với giải pháp kỹ thuật được đề xuất. Nó cũng giúp xác định các vấn đề và nhận ra các lĩnh vực cần cải thiện

Đánh giá dựa trên tình huống là một phương pháp chủ đạo để xem xét thiết kế kiến ​​trúc, tập trung vào các tình huống quan trọng nhất từ ​​góc độ kinh doanh và có tác động lớn nhất đến kiến ​​trúc. Sau đây là các phương pháp đánh giá phổ biến -

Phương pháp phân tích kiến ​​trúc phần mềm (SAAM)

Ban đầu nó được thiết kế để đánh giá khả năng sửa đổi, nhưng sau đó đã được mở rộng để xem xét kiến ​​trúc liên quan đến các thuộc tính chất lượng.

Phương pháp phân tích đánh đổi kiến ​​trúc (ATAM)

Đây là một phiên bản được đánh bóng và cải tiến của SAAM, xem xét các quyết định về kiến ​​trúc đối với các yêu cầu về thuộc tính chất lượng và mức độ đáp ứng các mục tiêu chất lượng cụ thể của chúng.

Đánh giá Thiết kế Hoạt động (ADR)

Nó phù hợp nhất cho các kiến ​​trúc chưa hoàn thiện hoặc đang trong quá trình thực hiện, tập trung nhiều hơn vào một tập hợp các vấn đề hoặc các phần riêng lẻ của kiến ​​trúc tại một thời điểm, thay vì thực hiện đánh giá chung.

Đánh giá tích cực về các thiết kế trung gian (ARID)

Nó kết hợp khía cạnh ADR của việc xem xét kiến ​​trúc đang tiến hành với việc tập trung vào một số vấn đề và cách tiếp cận ATAM và SAAM của việc xem xét dựa trên kịch bản tập trung vào các thuộc tính chất lượng.

Phương pháp phân tích lợi ích chi phí (CBAM)

Nó tập trung vào việc phân tích chi phí, lợi ích và ý nghĩa lịch trình của các quyết định kiến ​​trúc.

Phân tích khả năng sửa đổi mức kiến ​​trúc (ALMA)

Nó ước tính khả năng sửa đổi của kiến ​​trúc cho hệ thống thông tin kinh doanh (BIS).

Phương pháp đánh giá kiến ​​trúc gia đình (FAAM)

Nó ước tính kiến ​​trúc họ hệ thống thông tin cho khả năng tương tác và khả năng mở rộng.

Truyền đạt thiết kế kiến ​​trúc

Sau khi hoàn thành thiết kế kiến ​​trúc, chúng tôi phải truyền đạt thiết kế cho các bên liên quan khác, bao gồm nhóm phát triển, quản trị viên hệ thống, người vận hành, chủ sở hữu doanh nghiệp và các bên quan tâm khác.

Có một số phương pháp nổi tiếng sau đây để mô tả kiến ​​trúc cho những người khác: -

Mô hình 4 + 1

Cách tiếp cận này sử dụng năm góc nhìn của kiến ​​trúc hoàn chỉnh. Trong số đó, bốn lượt xem (logical view, các process view, các physical view, và development view) mô tả kiến ​​trúc từ các cách tiếp cận khác nhau. Chế độ xem thứ năm hiển thị các tình huống và trường hợp sử dụng cho phần mềm. Nó cho phép các bên liên quan xem các đặc điểm của kiến ​​trúc mà họ quan tâm cụ thể.

Ngôn ngữ mô tả kiến ​​trúc (ADL)

Cách tiếp cận này được sử dụng để mô tả kiến ​​trúc phần mềm trước khi triển khai hệ thống. Nó giải quyết các mối quan tâm sau - hành vi, giao thức và trình kết nối.

Ưu điểm chính của ADL là chúng ta có thể phân tích kiến ​​trúc về tính hoàn chỉnh, nhất quán, không rõ ràng và hiệu suất trước khi chính thức bắt đầu sử dụng thiết kế.

Mô hình Agile

Cách tiếp cận này tuân theo khái niệm “nội dung quan trọng hơn sự trình bày”. Nó đảm bảo rằng các mô hình được tạo đơn giản và dễ hiểu, đủ chính xác, chi tiết và nhất quán.

Các tài liệu về mô hình Agile nhắm mục tiêu (các) khách hàng cụ thể và hoàn thành các nỗ lực làm việc của khách hàng đó. Tính đơn giản của tài liệu đảm bảo rằng có sự tham gia tích cực của các bên liên quan trong việc mô hình hóa hiện vật.

IEEE 1471

IEEE 1471 là tên viết tắt của tiêu chuẩn chính thức được gọi là ANSI / IEEE 1471-2000, “Thực hành được khuyến nghị cho mô tả kiến ​​trúc của các hệ thống chuyên sâu về phần mềm”. IEEE 1471 nâng cao nội dung của mô tả kiến ​​trúc, đặc biệt, mang lại ý nghĩa cụ thể cho ngữ cảnh, quan điểm và quan điểm.

Ngôn ngữ mô hình thống nhất (UML)

Cách tiếp cận này thể hiện ba quan điểm của một mô hình hệ thống. Cácfunctional requirements view (các yêu cầu chức năng của hệ thống theo quan điểm của người dùng, bao gồm cả các ca sử dụng); the static structural view(các đối tượng, thuộc tính, mối quan hệ và hoạt động bao gồm cả sơ đồ lớp); vàdynamic behavior view (sự cộng tác giữa các đối tượng và thay đổi trạng thái bên trong của các đối tượng, bao gồm biểu đồ trình tự, hoạt động và trạng thái).