Chiến lược thiết kế phần mềm

Thiết kế phần mềm là một quá trình để khái niệm hóa các yêu cầu phần mềm thành việc triển khai phần mềm. Thiết kế phần mềm lấy các yêu cầu của người dùng làm thách thức và cố gắng tìm ra giải pháp tối ưu. Trong khi phần mềm đang được lên ý tưởng, một kế hoạch được đưa ra nhằm tìm ra thiết kế tốt nhất có thể để thực hiện giải pháp dự định.

Có nhiều biến thể của thiết kế phần mềm. Hãy để chúng tôi nghiên cứu chúng một cách ngắn gọn:

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

Thiết kế có cấu trúc là một khái niệm hóa vấn đề thành một số yếu tố được tổ chức tốt của giải pháp. Về cơ bản nó liên quan đến thiết kế giải pháp. Lợi ích của thiết kế có cấu trúc là, nó giúp hiểu rõ hơn về cách vấn đề đang được giải quyết. Thiết kế có cấu trúc cũng giúp người thiết kế dễ dàng tập trung vào vấn đề một cách chính xác hơn.

Thiết kế có cấu trúc chủ yếu dựa trên chiến lược 'chia để trị' trong đó một vấn đề được chia thành nhiều vấn đề nhỏ và từng vấn đề nhỏ được giải quyết riêng lẻ cho đến khi toàn bộ vấn đề được giải quyết.

Các phần nhỏ của vấn đề được giải quyết bằng các mô-đun giải pháp. Thiết kế có cấu trúc nhấn mạnh rằng các mô-đun này được tổ chức tốt để đạt được giải pháp chính xác.

Các mô-đun này được sắp xếp theo thứ bậc. Họ giao tiếp với nhau. Một thiết kế có cấu trúc tốt luôn tuân theo một số quy tắc để giao tiếp giữa nhiều mô-đun, cụ thể là -

Cohesion - nhóm tất cả các yếu tố liên quan đến chức năng.

Coupling - giao tiếp giữa các mô-đun khác nhau.

Một thiết kế có cấu trúc tốt có sự gắn kết cao và sắp xếp khớp nối thấp.

Thiết kế hướng chức năng

Trong thiết kế hướng chức năng, hệ thống bao gồm nhiều hệ thống con nhỏ hơn được gọi là chức năng. Các chức năng này có khả năng thực hiện nhiệm vụ quan trọng trong hệ thống. Hệ thống được coi là cái nhìn từ trên xuống của tất cả các chức năng.

Thiết kế hướng chức năng kế thừa một số thuộc tính của thiết kế có cấu trúc trong đó phương pháp phân chia và chinh phục được sử dụng.

Cơ chế thiết kế này chia toàn bộ hệ thống thành các chức năng nhỏ hơn, cung cấp các phương tiện trừu tượng bằng cách che giấu thông tin và hoạt động của chúng .. Các mô-đun chức năng này có thể chia sẻ thông tin giữa chúng với nhau bằng cách truyền thông tin và sử dụng thông tin có sẵn trên toàn cầu.

Một đặc điểm khác của các hàm là khi một chương trình gọi một hàm, hàm đó sẽ thay đổi trạng thái của chương trình, điều này đôi khi không được các mô-đun khác chấp nhận. Thiết kế hướng chức năng hoạt động tốt khi trạng thái hệ thống không quan trọng và chương trình / chức năng hoạt động trên đầu vào chứ không phải trên một trạng thái.

Quá trình thiết kế

Toàn bộ hệ thống được xem như cách dữ liệu lưu chuyển trong hệ thống bằng sơ đồ luồng dữ liệu.
DFD mô tả cách các chức năng thay đổi dữ liệu và trạng thái của toàn bộ hệ thống.
Toàn bộ hệ thống được chia nhỏ một cách hợp lý thành các đơn vị nhỏ hơn được gọi là các chức năng trên cơ sở hoạt động của chúng trong hệ thống.
Mỗi chức năng sau đó được mô tả lớn.

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

Thiết kế hướng đối tượng hoạt động xung quanh các thực thể và đặc điểm của chúng thay vì các chức năng liên quan đến hệ thống phần mềm. Chiến lược thiết kế này tập trung vào các thực thể và đặc điểm của nó. Toàn bộ khái niệm về giải pháp phần mềm xoay quanh các thực thể tham gia.

Hãy để chúng tôi xem các khái niệm quan trọng của Thiết kế hướng đối tượng:

Objects - Tất cả các thực thể tham gia vào thiết kế giải pháp được gọi là các đối tượng. Ví dụ, con người, ngân hàng, công ty và khách hàng được coi là đối tượng. Mỗi thực thể đều có một số thuộc tính được liên kết với nó và có một số phương pháp để thực hiện trên các thuộc tính.
Classes - Một lớp là một mô tả tổng quát của một đối tượng. Một đối tượng là một thể hiện của một lớp. Lớp định nghĩa tất cả các thuộc tính, mà một đối tượng có thể có và các phương thức, xác định chức năng của đối tượng.

Trong thiết kế giải pháp, các thuộc tính được lưu trữ dưới dạng các biến và các chức năng được xác định bằng các phương pháp hoặc thủ tục.
Encapsulation - Trong OOD, các thuộc tính (biến dữ liệu) và phương thức (hoạt động trên dữ liệu) được gói lại với nhau được gọi là đóng gói. Đóng gói không chỉ gói thông tin quan trọng của một đối tượng lại với nhau, mà còn hạn chế quyền truy cập dữ liệu và phương thức từ thế giới bên ngoài. Đây được gọi là ẩn thông tin.
Inheritance - OOD cho phép các lớp tương tự xếp chồng lên nhau theo cách phân cấp trong đó các lớp thấp hơn hoặc lớp con có thể nhập, triển khai và sử dụng lại các biến và phương thức được phép từ các siêu lớp trực tiếp của chúng. Thuộc tính này của OOD được gọi là tài sản thừa kế. Điều này giúp dễ dàng xác định lớp cụ thể và tạo lớp tổng quát từ những lớp cụ thể.
Polymorphism - Các ngôn ngữ OOD cung cấp một cơ chế trong đó các phương thức thực hiện các tác vụ tương tự nhưng khác nhau về đối số, có thể được gán cùng tên. Đây được gọi là tính đa hình, cho phép một giao diện duy nhất thực hiện các tác vụ cho các kiểu khác nhau. Tùy thuộc vào cách hàm được gọi, phần tương ứng của mã sẽ được thực thi.

Quá trình thiết kế

Quá trình thiết kế phần mềm có thể được coi là một loạt các bước được xác định rõ ràng. Mặc dù nó thay đổi theo cách tiếp cận thiết kế (hướng chức năng hoặc hướng đối tượng, nhưng nó có thể có các bước sau:

Một thiết kế giải pháp được tạo ra từ yêu cầu hoặc sơ đồ trình tự hệ thống và / hoặc hệ thống đã sử dụng trước đó.
Các đối tượng được xác định và nhóm thành các lớp nhân danh sự giống nhau về đặc điểm thuộc tính.
Hệ thống phân cấp lớp và mối quan hệ giữa chúng được xác định.
Khung ứng dụng được xác định.

Phương pháp tiếp cận thiết kế phần mềm

Dưới đây là hai cách tiếp cận chung cho thiết kế phần mềm:

Thiết kế từ trên xuống

Chúng ta biết rằng một hệ thống bao gồm nhiều hơn một hệ thống con và nó chứa một số thành phần. Hơn nữa, các hệ thống con và thành phần này có thể có trên tập hợp các hệ thống con và thành phần và tạo ra cấu trúc phân cấp trong hệ thống.

Thiết kế từ trên xuống lấy toàn bộ hệ thống phần mềm như một thực thể và sau đó phân tách nó để đạt được nhiều hơn một hệ thống con hoặc thành phần dựa trên một số đặc điểm. Mỗi hệ thống con hoặc thành phần sau đó được coi như một hệ thống và được phân rã thêm. Quá trình này tiếp tục chạy cho đến khi đạt được mức thấp nhất của hệ thống trong phân cấp từ trên xuống.

Thiết kế từ trên xuống bắt đầu với một mô hình tổng quát của hệ thống và tiếp tục xác định phần cụ thể hơn của nó. Khi tất cả các thành phần được cấu thành, toàn bộ hệ thống sẽ tồn tại.

Thiết kế từ trên xuống phù hợp hơn khi giải pháp phần mềm cần được thiết kế từ đầu và các chi tiết cụ thể chưa được biết đến.

Thiết kế từ dưới lên

Mô hình thiết kế từ dưới lên bắt đầu với hầu hết các thành phần cụ thể và cơ bản. Nó tiến hành soạn các thành phần cấp cao hơn bằng cách sử dụng các thành phần cơ bản hoặc cấp thấp hơn. Nó tiếp tục tạo các thành phần cấp cao hơn cho đến khi hệ thống mong muốn không được phát triển thành một thành phần duy nhất. Với mỗi cấp độ cao hơn, số lượng trừu tượng được tăng lên.

Chiến lược từ dưới lên phù hợp hơn khi một hệ thống cần được tạo ra từ một số hệ thống hiện có, nơi các nguyên thủy cơ bản có thể được sử dụng trong hệ thống mới hơn.

Cả hai cách tiếp cận từ trên xuống và từ dưới lên đều không thực tế riêng lẻ. Thay vào đó, sự kết hợp tốt của cả hai được sử dụng.