Chiến lược thiết kế

Chiến lược từ trên xuống

Chiến lược từ trên xuống sử dụng cách tiếp cận mô-đun để phát triển thiết kế của một hệ thống. Nó được gọi như vậy bởi vì nó bắt đầu từ mô-đun cấp cao nhất hoặc cấp cao nhất và di chuyển đến các mô-đun cấp thấp nhất.

Trong kỹ thuật này, mô-đun cấp cao nhất hoặc mô-đun chính để phát triển phần mềm được xác định. Mô-đun chính được chia thành nhiều mô-đun con hoặc phân đoạn nhỏ hơn và đơn giản hơn dựa trên nhiệm vụ được thực hiện bởi mỗi mô-đun. Sau đó, mỗi mô-đun con lại được chia nhỏ thành nhiều mô-đun con ở cấp độ thấp hơn tiếp theo. Quá trình chia mỗi mô-đun thành nhiều mô-đun con tiếp tục cho đến khi không xác định được các mô-đun cấp thấp nhất, không thể chia nhỏ hơn nữa.

Chiến lược từ dưới lên

Chiến lược Bottom-Up tuân theo cách tiếp cận mô-đun để phát triển thiết kế của hệ thống. Nó được gọi như vậy bởi vì nó bắt đầu từ các mô-đun cấp dưới cùng hoặc cơ bản nhất và tiến dần đến các mô-đun cấp cao nhất.

Trong kỹ thuật này,

Các mô-đun ở mức cơ bản nhất hoặc mức thấp nhất được xác định.
Các mô-đun này sau đó được nhóm lại với nhau dựa trên chức năng được thực hiện bởi từng mô-đun để tạo thành các mô-đun cấp cao hơn tiếp theo.
Sau đó, các mô-đun này được tiếp tục kết hợp để tạo thành các mô-đun cấp cao hơn tiếp theo.
Quá trình nhóm một số mô-đun đơn giản hơn để tạo thành các mô-đun cấp cao hơn tiếp tục cho đến khi đạt được mô-đun chính của quá trình phát triển hệ thống.

Thiết kế có cấu trúc

Thiết kế có cấu trúc là một phương pháp luận dựa trên luồng dữ liệu giúp xác định đầu vào và đầu ra của hệ thống đang phát triển. Mục tiêu chính của thiết kế có cấu trúc là giảm thiểu độ phức tạp và tăng tính mô đun của chương trình. Thiết kế có cấu trúc cũng giúp mô tả các khía cạnh chức năng của hệ thống.

Trong thiết kế có cấu trúc, các đặc tả hệ thống đóng vai trò là cơ sở để biểu diễn bằng đồ thị luồng dữ liệu và trình tự các quy trình liên quan đến phát triển phần mềm với sự trợ giúp của DFD. Sau khi phát triển các DFD cho hệ thống phần mềm, bước tiếp theo là phát triển biểu đồ cấu trúc.

Mô-đun hóa

Thiết kế có cấu trúc phân vùng chương trình thành các mô-đun nhỏ và độc lập. Chúng được sắp xếp theo cách từ trên xuống với các chi tiết được hiển thị ở dưới cùng.

Do đó, thiết kế có cấu trúc sử dụng một cách tiếp cận được gọi là Mô-đun hóa hoặc phân rã để giảm thiểu sự phức tạp và quản lý vấn đề bằng cách chia nó thành các phân đoạn nhỏ hơn.

Advantages

Các giao diện quan trọng được thử nghiệm đầu tiên.
Nó cung cấp tính trừu tượng.
Nó cho phép nhiều lập trình viên làm việc đồng thời.
Nó cho phép sử dụng lại mã.
Nó cung cấp khả năng kiểm soát và cải thiện tinh thần.
Nó làm cho việc xác định cấu trúc dễ dàng hơn.

Biểu đồ có cấu trúc

Biểu đồ có cấu trúc là một công cụ được khuyến nghị để thiết kế hệ thống mô-đun, từ trên xuống xác định các mô-đun phát triển hệ thống khác nhau và mối quan hệ giữa từng mô-đun. Nó cho thấy mô-đun hệ thống và mối quan hệ giữa chúng.

Nó bao gồm sơ đồ bao gồm các hộp hình chữ nhật đại diện cho các mô-đun, các mũi tên kết nối hoặc các đường.

Control Module - Nó là một mô-đun cấp cao hơn chỉ đạo các mô-đun cấp thấp hơn, được gọi là subordinate modules.
Library Module - Đây là một mô-đun có thể tái sử dụng và có thể được gọi từ nhiều hơn một điểm trong biểu đồ.

Chúng tôi có hai cách tiếp cận khác nhau để thiết kế biểu đồ có cấu trúc -

Transform-Centered Structured Charts - Chúng được sử dụng khi tất cả các giao dịch theo cùng một đường dẫn.
Transaction–Centered Structured Charts - Chúng được sử dụng khi tất cả các giao dịch không theo cùng một đường dẫn.

Mục tiêu của việc sử dụng sơ đồ cấu trúc

Để khuyến khích thiết kế từ trên xuống.
Để hỗ trợ khái niệm về mô-đun và xác định các mô-đun thích hợp.
Để hiển thị quy mô và độ phức tạp của hệ thống.
Để xác định số lượng các chức năng và mô-đun có thể nhận dạng dễ dàng trong mỗi chức năng.
Để mô tả liệu mỗi chức năng có thể nhận dạng là một thực thể có thể quản lý được hay nên được chia thành các thành phần nhỏ hơn.

Các yếu tố ảnh hưởng đến độ phức tạp của hệ thống

Để phát triển chất lượng tốt của phần mềm hệ thống, cần phải phát triển một thiết kế tốt. Vì vậy, trọng tâm chính trong khi phát triển thiết kế của hệ thống là chất lượng của thiết kế phần mềm. Một thiết kế phần mềm có chất lượng tốt là một thiết kế giảm thiểu sự phức tạp và chi phí phát triển phần mềm.

Hai khái niệm quan trọng liên quan đến phát triển hệ thống giúp xác định mức độ phức tạp của hệ thống là coupling và cohesion.

Khớp nối

Khớp nối là thước đo tính độc lập của các thành phần. Nó xác định mức độ phụ thuộc của từng mô-đun phát triển hệ thống vào mô-đun khác. Trong thực tế, điều này có nghĩa là sự kết hợp giữa các mô-đun trong hệ thống càng mạnh thì việc triển khai và duy trì hệ thống càng khó khăn hơn.

Mỗi mô-đun phải có giao diện đơn giản, rõ ràng với các mô-đun khác và số phần tử dữ liệu tối thiểu phải được chia sẻ giữa các mô-đun.

Khớp nối cao

Các loại hệ thống này có sự kết nối với nhau với các đơn vị chương trình phụ thuộc vào nhau. Những thay đổi đối với một hệ thống con dẫn đến tác động lớn đến hệ thống con khác.

Khớp nối thấp

Loại hệ thống này được tạo thành từ các thành phần độc lập hoặc gần như độc lập. Một thay đổi trong một hệ thống con không ảnh hưởng đến bất kỳ hệ thống con nào khác.

Các biện pháp khớp nối

Content Coupling - Khi một thành phần thực sự sửa đổi thành phần khác, thì thành phần được sửa đổi hoàn toàn phụ thuộc vào việc sửa đổi một thành phần.
Common Coupling - Khi lượng khớp nối được giảm bớt phần nào bằng cách tổ chức thiết kế hệ thống để dữ liệu có thể truy cập được từ một kho dữ liệu chung.
Control Coupling - Khi một thành phần truyền tham số để điều khiển hoạt động của thành phần khác.
Stamp Coupling - Khi cấu trúc dữ liệu được sử dụng để truyền thông tin từ thành phần này sang thành phần khác.
Data Coupling - Khi chỉ có dữ liệu được truyền qua thì các thành phần được kết nối bằng khớp nối này.

Sự gắn kết

Sự gắn kết là thước đo mức độ chặt chẽ của mối quan hệ giữa các thành phần của nó. Nó xác định mức độ phụ thuộc của các thành phần của một mô-đun vào nhau. Trong thực tế, điều này có nghĩa là nhà thiết kế hệ thống phải đảm bảo rằng -

Họ không chia các quy trình thiết yếu thành các mô-đun phân mảnh.
Chúng không tập hợp các quy trình không liên quan với nhau được biểu diễn như các quy trình trên DFD thành các mô-đun vô nghĩa.

Các mô-đun tốt nhất là những mô-đun gắn kết về mặt chức năng. Các mô-đun tồi tệ nhất là những mô-đun được gắn kết một cách ngẫu nhiên.

Mức độ gắn kết tồi tệ nhất

Sự gắn kết ngẫu nhiên được tìm thấy trong một thành phần mà các phần của nó không liên quan đến phần khác.

Logical Cohesion - Đó là nơi một số chức năng hoặc phần tử dữ liệu liên quan về mặt logic được đặt trong cùng một thành phần.
Temporal Cohesion - Là khi một thành phần được sử dụng để khởi tạo hệ thống hoặc tập hợp các biến thực hiện một số chức năng theo trình tự, nhưng các chức năng có liên quan với nhau theo thời gian liên quan.
Procedurally Cohesion - Là khi các chức năng được nhóm lại với nhau trong một thành phần chỉ để đảm bảo thứ tự này.
Sequential Cohesion - Là khi đầu ra từ một phần của một thành phần là đầu vào cho phần tiếp theo của nó.