Kiến trúc và thiết kế phần mềm là gì?

ìm hiểu phần mềm kiến trúc và thiết kế, hai yếu tố quan trọng định hình cấu trúc, chức năng và hiệu suất của ứng dụng.
Please wait 0 seconds...
Scroll Down and click on Go to Link for destination
Congrats! Link is Generated
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ố góp phần như chiến lược kinh doanh, các 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 và Thiết kế phần mềm 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. Trong kiến trúc, các quyết định phi chức năng được đưa ra và phân tách theo 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 thực hiện. (accomplish - hoàn thành, làm tròn, làm xong)

Software Architecture

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

  • Nó xác định một giải pháp có cấu trúc để đáp ứng tất cả các yêu cầu công nghệ 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 đó có thể có thể tác động (impact - va chạm, đụng vật gì; considerable - đáng kể) đáng kể đến chất lượng, khả năng bảo trì, hiệu suất, và thành công chung của sản phẩm cuối. Những quyết định này bao gồm (comprise - bao gồm, bao hàm, chứa đựng)
    • Sự lựa chọn của các thành phần cấu trúc và các giao diện của chúng mà hệ thống được cấu thành (compose - biên soạn, dàn xếp, hòa giải).
    • Hành vi như được chỉ định trong sự cộng tác giữa các yếu tố.
    • Sự kết hợp 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 kiến trúc phù hợp với mục tiêu kinh doanh. (align - căn chỉnh, kéo thẳng, làm cho ngay ngắn)
    • Loại kiến trúc hướng dẫn tổ chức.

Software Design

Thiết kế phần mềm cung cấp một kế hoạnh thiết kế mô tả các thành phần của một hệ thống, cách chúng phù hợp và làm việc với nhau để đáp ứng yêu cầu của hệ thống (fullfill - thực hiện, làm thỏa mãn, làm cho xong). Mục tiêu của việc có một kế hoạch thiết kế như sau

  • Để đàm phán các yêu cầu hệ thống (negotiate - thương lượng, đàm phán), và để đặt kỳ vọng với khách hàng, nhân viên tiếp thị và người quản lý.
  • Đóng vai trò như một bản vẽ trong quá trình phát triển.
  • Hướng dẫn các nhiệm vụ triển khai, bao gồm thiết kế chi tiết, coding, tích hợp, và thử nghiệm.
Nó xuất hiện trước khi thiết kế chi tiết, coding, 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.

Goals of Architecture

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. Kiến trúc được bố trí tốt (well-laid) giảm thiểu các rủi ro kinh doanh liên quan đến việc xây dựng các giải pháp kỹ thuật và xây dựng một cầu nối giữa các yêu cầu kinh doanh và kỹ thuật.

Một vài mục tiêu khác như sau

  • Hiển thị cấu trúc của hệ thống, nhưng ẩn các 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à các kịch bản.
  • 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. (various - nhiều, khác nhau, nhiều thứ)
  • Xử lý cả các yêu cầu chức năng và chất lượng.
  • Giảm các mục tiêu sở hữu và nâng cao vị thế của tổ chức trên thị trường.
  • Cải thiện chất lượng và chức năng được cung cấp bởi hệ thống.
  • Cải thiện niềm tin bên ngoài vào tổ chức hoặc hệ thống.

Limitations

Kiến trúc phần mềm vẫn đang là một lĩnh vực mới nổi trong kỹ thuật phần mềm (discipline - kỷ luật, môn học, huấn luyện; emerging - mới nổi, nhô lê, hiện ra). Nó có các hạn chế sau

  • Thiếu các công cụ và cách 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 một sự triển khai mà đáp ứng được các yêu cầu hay không.
  • Thiếu nhận thức về sự 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 sự hiểu biết về vai trò của kiến trúc sư phần mềm và giao tiếp kiém giữa các bên liên quan.
  • Thiếu hiểu biết về quá trình thiết kế, kinh nghiệm thiết kế và đánh giá thiết kế.

Role of Software Architect

Một kiến trúc sư phần mềm cung cấp một giải pháp mà nhóm kỹ thuật có thể tạo ra 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 đây

Design Expertise - Chuyên môn thiết kế

  • Chuyên gia trong thiết kế phần mềm, bao gồm các phương pháp và tiếp cận đa dạng như thiết kế hướng đối tượng, thiết kế dựa trên sự kiện, v.v. (diverse - phong phú, không giống nhau)
  • Dẫn dắt nhóm phát triển và phối hợp các nỗ lực phát triển để đảm bảo tính toàn vẹn của thiết kế.
  • Nên có khả năng đánh giá các đề xuất thiết kế và cân nhắc giữa chúng. (tradeoff - sự đánh đổi)

Domain Expertise - Chuyên môn lĩnh vực

  • Chuyên gia về hệ thống đang được phát triển và lập kế hoạch cho sự tiến hóa phần mềm.
  • Hỗ trợ trong quá trình điều tra yêu cầu, đảm bảo tính đầy đủ và tính nhất quán.
  • Phối hợp việc định nghĩa của mô hình lĩnh vực cho hệ thống đang được phát triển.

Technology Expertise - Chuyên môn công nghệ

  • Chuyên gia về các công nghệ có sẵn giúp ttong việc triển khai hệ thống.
  • Phối hợp việc lựa chọn ngôn ngữ lập trình, framework, nền tảng, cơ sở dữ liệu, v.v.

Methodological Expertise - Chuyên môn phương pháp

  • Chuyên gia về các phương pháp phát triển phần mềm có thể được áp dụng trong vòng đời phát triển phần mềm - SDLC (Software Development Life Cycle).
  • Chọn các cách tiếp cận phù hợp (appropriate - phù hợp, đặc biệt, để dành riêng) với sự phát triển, trợ giúp cho toàn bộ nhóm.

Hidden Role of Software Architect - Vai trò ẩn của kiến trúc sư phần mềm

  • Hỗ trợ công việc kỹ thuật (facilitate - tạo điều kiện, làm cho dễ dàng) giữa các thành viên nhóm và củng cố mối quan hệ tin tưởng trong nhóm. (reinforcing - tăng cường, làm cho mạnh thêm)
  • Chuyên gia thông tin, người chia sẻ kiến thức và có nhiều kinh nghiệm. (vast - rộng lớn, bao la)
  • Bảo vệ các thành viên nhóm khỏi các lực lượng bên ngoài làm lạc hướng họ (distract - đánh lạc hướng, làm bối rối, làm không để ý) và mang ít giá trị cho dự án.

Deliverables of the Architect - Sản phẩm của kiến trúc sư

  • Một tập hợp rõ ràng, đầy đủ, nhất quán, và có thể đạt được của các mục tiêu chức năng.
  • Mô tả chức năng của hệ thống, với ít nhất hai lớp phân cấp. (composition - thành phần, sử tổ hợp; decomposition - sự phân hủy, hóa thành đôi)
  • 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 cấp.
  • Một khái niệm về thời gian, các thuộc tính toán tử, và các kế hoạch triển khai và vần hành.
  • Một tài liệu hoặc quy trình đảm bảo việc phân cấp chức năng được tuân theo, và hình thức của các giao diện được kiểm soát.

Quality Attributes

Chất lượng là một thước đo về sự xuất sắc hoặc trạng thái không có thiếu sót hay khuyết điểm (measure - đo lường; deficiency - sự thiết hụt, khuyết điểm, thiếu sót; defect - khuyết điểm, không đủ, phần thiếu). Các thuộc tính chất lượng là các đặc tính của hệ thống được 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 làm cho nó dễ dàng hơn để phân biệt một hệ thống tốt với một hệ thống kém. Các thuộc tính là các yếu tố tổng thể (factor - nhân tố; overall - tất cả) ảnh hưởng đến hành vi thời gian chạy, thiết kế hệ thống, và trả nghiệm người dùng.

Chúng có thể được phân loại như sau (classified - phân loại, phân hạng)

Static Quality Attributes - Các 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 tới kiến trúc, thiết kế và mã nguồn. Chúng có thể không thấy được đối với người dùng cuối, nhưng lại ảnh hưởng đến chi phí phát triển và bảo trì, ví dụ: tính mô-đun hóa, khả năng kiểm thử, khả năng bảo trì, v.v.

Dynamic Quality Attributes - Các 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 của nó. Chúng liên quan trực tiếp đến kiến trúc, thiết kế, mã nguồn, cấu hình, các tham số triển khai, môi trường, và nền tảng của hệ thống.

Chúng có thể thấy được đối với người dùng cuối và tồn tại trong thời gian chạy, ví dụ: thông lượng, tính bền vững, khả năng mở rộng, v.v. (throughput - thông lượng, robust - khỏa mạnh, cường tráng)

Quality Scenarios

Các kịch bản chất lượng chỉ định cách để ngăn chặn một lỗi trở thành thất bại. Chúng có thể được chia thành 6 phần dựa trên các thuộc tính của chúng
  • Source - Một thực thể nội bộ 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 lý tạo ra kích thích. (stimulus - kích thích, chất kích thích, sự khích lệ)
  • Stimulus - Một điều kiện cần được xem xét khi nó xuất hiện trên hệ thống. (arrive - đến, xảy đến, xảy ra)
  • Environment - Kích thích xảy ra trong các điều kiện nhất định. (certain - chắc chắn, đôi chút, nhất định)
  • Artifact (Hiện vật) - Một hệ thống hoàn chỉnh hoặc một phần của nó như các bộ xử lý, các kênh truyền thông, lưu trữ bền vững, các quá trình, v.v.
  • Response - Một hoạt động được thực hiện () sau sự xuất hiện của kích thích, chẳng hạn như phát hiện lỗi, khôi phục từ 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 hồi xảy ra để các yêu cầu có thể được kiểm tra.

Common Quality Attributes

Dưới đây là bảng liệt kê các thuọc tính chất lượng thông thường mà một kiến trúc phần mềm phải có

Design Qualities - Chất lượng thiết kế

  • Tính toàn vẹn khái niệm: Định nghĩa tính nhất quán và đồng bộ của toàn bộ thiết kế. Nó 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 để chịu được các thay đổi một cách dễ dàng. (undergo - trải qua, chịu sự đau khổ)
  • Khả năng tái sử dụng: Định nghĩa khả năng cho các thành phần và các hệ thống con phù hợp để sử dụng trong các ứng dụng khác. (capability - khả năng, tài trí)

Run-time Qualities - Chất lượng thời gian chạy

    • Interoperability: Ability of a system or different systems to operate successfully by communicating and exchanging information with other external systems written and run by external parties.
    • Manageability: Defines how easy it is for system administrators to manage the application.
    • Reliability: Ability of a system to remain operational over time.
    • Scalability: Ability of a system to either handle the load increase without impacting the performance of the system or the ability to be readily enlarged.
    • Security: Capability of a system to prevent malicious or accidental actions outside of the designed usages.
    • Performance: Indication of the responsiveness of a system to execute any action within a given time interval.
    • Availability: Defines the proportion of time that the system is functional and working. It can be measured as a percentage of the total system downtime over a predefined period.
  • Khả Năng Tương Tác (Interoperability): 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 được viết và vận hành bởi các bên khác.
  • Khả Năng Quản Lý (Manageability): Định nghĩa mức độ dễ dàng của các quản trị viên hệ thống trong việc quản lý ứng dụng.
  • Độ Tin Cậy (Reliability): 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 (Scalability): Khả năng của một hệ thống xử lý 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 mở rộng. (readily - nhanh chóng, ngay lập tức, sẵn sàng)
  • Bảo Mật (Security): Khả năng của hệ thống để ngăn chặn các hành động ác ý hoặc ngẫu nhiên ngoài các sử dụng được thiết kế. (malicious - độc hại, hay thù oán)
  • Hiệu Suất (Performance): Chỉ số của sự phản hồi 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. (indicate - biểu thị, biểu lộ)
  • Tính Khả Dụng (Availability): Định nghĩa tỷ lệ thời gian mà hệ thống hoạt động và làm việc. Nó có thể được đo lường dưới dạng tỷ lệ phần trăm của tổng thời gian ngừng hoạt động của hệ thống trong một khoảng thời gian định trước. (proportion - tỷ lệ)

System Qualities - 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 để xác định và giải quyết các vấn đề khi nó không hoạt động đúng.
  • Khả năng kiểm thử: Đo lường mức độ dễ dàng trong việc tạo ra các tiêu chí kiểm thử cho hệ thống và các thành phần của nó. (criteria - tiêu chuẩn)

User Qualities - Chất lượng người dùng

  • Khả năng sử dụng: Định nghĩa mức độ ứng dụng đáp ứng được các yêu cầu của người dùng và khách hàng bằng cách dễ sử dụng. (intuitive - trực giác)

Architecture Quality - Chất lượng kiến trúc

    • Correctness: Accountability for satisfying all the requirements of the system.
  • Tính đúng đắn: Trách nhiệm đối với việc đáp ứng tất cả các yêu cầu của hệ thống. (accountability - trách nhiệm giải trình, nhiệm vụ)

Non-runtime Quality

  • Khả năng di động: Khả năng của hệ thống chạy dưới các môi trường máy tính khác nhau.
  • Tính toàn vẹn: Khả năng làm cho các thành phần phát triển riêng biệt của hệ thống hoạt động đúng cùng nhau.
  • Khả năng sửa đổi: Mức độ dễ dàng mà mỗi hệ thống phần mềm có thể thích ứng với các thay đổi trong phần mềm của nó. (accommodate - chứa, cung cấp, đựng)

Business Quality Attributes - Các 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, tuổi thọ dự kiến của dự án, và việc sử dụng các di sản. (utilization - sự tận dụng)
  • Tính thị trường: Mức độ sử dụng hệ thống liên quan đến cạnh tranh thị trường.


Source: https://www.tutorialspoint.com/software_architecture_design/introduction.htm

Đăng nhận xét

Tham gia cuộc trò chuyện