Thiết kế phần mềm

Khái niệm

Có thể định nghĩa thiết kế là một quá trình áp dụng nhiều kỹ thuật và các nguyên lý để tạo ra mô hình của một thiết bị, một tiến trình hay một hệ thống đủ chi tiết mà theo đó có thể chế tạo ra sản phẩm vật lý tương ứng với nó.

Bản chất thiết kế phần mềm là một quá trình chuyển hóa các yêu cầu phần mềm thành một biểu diễn thiết kế. Từ những mô tả quan niệm về toàn bộ phần mềm, việc làm mịn (chi tiết hóa) liên tục dẫn tới một biểu diễn thiết kế rất gần với cách biểu diễn của chương trình nguồn để có thể ánh xạ vào một ngôn ngữ lập trình cụ thể.

Mục tiêu thiết kế là để tạo ra một mô hình biểu diễn của một thực thể mà sau này sẽ được xây dựng.

Mô hình chung của một thiết kế phần mềm là một đồ thị có hướng, các nút biểu diễn các thực thể có trong thiết kế, các liên kết biểu diễn các mỗi quan hệ giữa các thực thể đó. Hoạt động thiết kế là một loại hoạt động đặc biệt:

• Là một quá trình sáng tạo, đòi hỏi có kinh nghiệm và sự nhanh nhạy và sáng tạo
• Cần phải được thực hành và học bằng kinh nghiệm, bằng khảo sát các hệ đang tồn tại, chỉ học bằng sách vở là không đủ.

Tầm quan trọng

Tầm quan trọng của thiết kế phần mềm có thể được phát biểu bằng một từ “chất lượng”. Thiết kế là nơi chất lượng phần mềm được nuôi dưỡng trong quá trình phát triển: cung cấp cách biểu diễn phần mềm có thể được xác nhận về chất lượng, là cách duy nhất mà chúng ta có thể chuyển hóa một cách chính xác các yêu cầu của khách hàng thành sản phẩm hay hệ thống phần mềm cuối cùng. là công cụ giao tiếp làm cơ sở để có thể mô tả một cách đầy đủ các dịch vụ của hệ thống, để quản lý các rủi ro và lựa chọn giải pháp thích hợp. phục vụ như một nền tảng cho mọi bước kỹ nghệ phần mềm và bảo trì. Không có thiết kế có nguy cơ sản sinh một hệ thống không ổn định - một hệ thống sẽ thất bại. Một hệ thống phần mềm rất khó xác định được chất lượng chừng nào chưa đến bước kiểm thử. Thiết kế tốt là bước quan trọng đầu tiên để đảm bảo chất lượng phần mềm.

Vai trò của thiết kế phần mềm trong quá trình kỹ nghệ.

Quá trình thiết kế

là quá trình chuyển các đặc tả yêu cầu dịch vụ thông tin của hệ thống thành đặc tả hệ thống phần mềm. trải qua một số giai đoạn chính sau:

1. Nghiên cứu để hiểu ra vấn đề. Không hiểu rõ vấn đề thì không thể có được thiết kế hữu hiệu.
2. Chọn một (hay một số) giải pháp thiết kế và xác định các đặc điểm thô của nó. Chọn giải pháp phụ thuộc vào kinh nghiệm của người thiết kế, vào các cấu kiện dùng lại được và vào sự đơn giản của các giải pháp kéo theo. Nếu các nhân tố khác là tương tự thì nên chọn giải pháp đơn giản nhất.
3. Mô tả trừu tượng cho mỗi nội dung trong giải pháp. Trước khi tạo ra các tư liệu chính thức người thiết kế cần phải xây dựng một mô tả ban đầu sơ khai rồi chi tiết hóa nó. Các sai sót và khiếm khuyết trong mỗi mức thiết kế trước đó được phát hiện và phải được chỉnh sửa trước khi lập tư liệu thiết kế.

Kết quả của mỗi hoạt động thiết kế là một đặc tả thiết kế. Đặc tả này có thể là một đặc tả trừu tượng, hình thức và được tạo ra để làm rõ các yêu cầu, nó cũng có thể là một đặc tả về một phần nào đó của hệ thống phải được thực hiện như thế nào. Khi quá trình thiết kế tiến triển thì các chi tiết được bổ sung vào đặc tả đó. Các kết quả cuối cùng là các đặc tả về các thuật toán và các cấu trúc dữ liệu được dùng làm cơ sở cho việc thực hiện hệ thống. Các hoạt động thiết kế chính trong một hệ thống phần mềm lớn:

Các nội dung chính của thiết kế là:

• Thiết kế kiến trúc: Xác định hệ tổng thể phần mềm bao gồm các hệ con và các quan hệ giữa chúng và ghi thành tài liệu
• Đặc tả trừu tượng: các đặc tả trừu tượng cho mỗi hệ con về các dịch vụ mà nó cung cấp cũng như các ràng buộc chúng phải tuân thủ.
• Thiết kế giao diện: giao diện của từng hệ con với các hệ con khác được thiết kế và ghi thành tài liệu; đặc tả giao diện không được mơ hồ và cho phép sử dụng hệ con đó mà không cần biết về thiết kế nội tại của nó.
• Thiết kế các thành phần: các dịch vụ mà một hệ con cung cấp được phân chia cho các thành phần hợp thành của nó.
• Thiết kế cấu trúc dữ liệu: thiết kế chi tiết và đặc tả các cấu trúc dữ liệu (các mô hình về thế giới thực cần xử lý) được dùng trong việc thực hiện hệ thống.
• Thiết kế thuật toán: các thuật toán được dùng cho các dịch vụ được thiết kế chi tiết và được đặc tả.

Quá trình này được lặp lại cho đến khi các thành phần hợp thành của mỗi hệ con được xác định đều có thể ánh xạ trực tiếp vào các thành phần ngôn ngữ lập trình, chẳng hạn như các gói, các thủ tục và các hàm.

Cơ sở của thiết kế

Phần mềm được chia thành các thành phần có tên riêng biệt và xác định được địa chỉ, gọi là các mô đun, được tích hợp để thỏa mãn yêu cầu của vấn đề. Người ta nói rằng: tính môđun là thuộc tính riêng của phần mềm cho phép một chương trình trở nên quản lý được theo cách thông minh. Người đọc không thể nào hiểu thấu phần mềm nguyên khối (như một chương trình lớn chỉ gồm một môđun). Điều này dẫn đến kết luận “chia để trị” sẽ dễ giải quyết một vấn đề phức tạp hơn khi chia nó thành những phần quản lý được. Với cùng một tập hợp các yêu cầu, nhiều môđun hơn có nghĩa là kích cỡ từng môđun nhỏ; độ phức tạp giảm và chi phí cho phát triển môđun giảm. Nhưng khi số các mô đun tăng lên thì nỗ lực liên kết chúng bằng việc làm giao diện cho các môđun cũng tăng lên. Đặc trưng này dẫn đến đường cong tổng chi phí (nỗ lực) như trong hình 2.

Chúng ta nên mô đun hóa nhưng cần phải duy trì chi phí trong vùng lân cận của chi phí tối thiểu. Môđun hóa còn chưa đủ hay quá mức đều nên tránh. Một gợi ý cho kích cỡ của các môđun cơ sở là mỗi môđun đảm nhận một chức năng cơ bản.

Mô tả thiết kế

Một bản thiết kế phần mềm là một mô hình mô tả một đối tượng của thế giới thực có nhiều thành phần và các mối quan hệ giữa chúng với nhau. Việc mô tả thiết kế cần đảm bảo thực hiện được các yêu cầu:

• Làm cơ sở cho việc triển khai chương trình
• Làm phương tiện giao tiếp giữa các nhóm thiết kế các hệ con
• Cung cấp đủ thông tin cho những người bảo trì hệ thống

Thiết kế thường được mô tả ở hai mức: thiết kế mức cao (high level design) và thiết kế chi tiết (low level design). Thiết kế mức cao hay thiết kế kiến trúc chỉ ra:

• Mô hình tổng thể của hệ thống
• Cách thức hệ thống được phân rã thành các môđun
• Mối quan hệ (gọi nhau) giữa các môđun
• Cách thức trao đổi thông tin giữa các môđun (giao diện, các dữ liệu dùng chung, các thông tin trạng thái)

Tuy nhiên thiết kế mức cao không chỉ ra được thứ tự thực hiện, số lần thực hiện của môđun, cũng như các trạng thái và hoạt động bên trong của mỗi môđun.

Nội dung của các môđun được thể hiện ở mức thiết kế chi tiết. Các cấu trúc cơ sở của thiết kế chi tiết hay còn gọi là thiết kế thuật toán là:

• Cấu trúc tuần tự
• Cấu trúc rẽ nhánh
• Cấu trúc lặp

Mọi thuật toán đều có thể mô tả dựa trên 3 cấu trúc trên. Có ba loại hình mô tả thường được sử dụng trong thiết kế:

• Dạng văn bản phi hình thức: Mô tả bằng ngôn ngữ tự nhiên các thông tin không thể hình thức hóa được như các thông tin phi chức năng. Bên cạnh các cách mô tả khác, mô tả văn bản thường được bổ sung để làm cho thiết kế được đầy đủ và dễ hiểu hơn.
• Các biểu đồ: Các biểu đồ được dùng để thể hiện các mối quan hệ giữa các thành phần lập lên hệ thống và là mô hình mô tả thế giới thực. Việc mô tả đồ thị của các thiết kế là rất có lợi vì tính trực quan và cho một bức tranh tổng thể về hệ thống. Trong thời gian gần đây, người ta đã xây dựng được một ngôn ngữ đồ thị dành riêng cho các thiết kế phần mềm với tên gọi: ngôn ngữ mô hình hóa thống nhất (Unified Modeling Model - UML). Tại mức thiết kế chi tiết, có một số các dạng biểu đồ hay được sử dụng là flow chart, JSP, Nassi Shneiderman diagrams.
• Giả mã (pseudo code): Hiện nay, giả mã là công cụ được ưa chuộng để mô tả thiết kế ở mức chi tiết. Các ngôn ngữ này thuận tiện cho việc mô tả chính xác thiết kế, tuy nhiên lại thiếu tính trực quan. Dưới đây là một ví dụ sử dụng giả mã:

Procedure Write Name

if sex = male

write "Mr."

else

write "Ms."

endif

write name

end Procedure

Nói chung thì cả ba loại biểu diễn trên đây đều được sử dụng trong thiết kế hệ thống. Thiết kế kiến trúc thường được mô tả bằng đồ thị (structure chart)và được bổ sung văn bản phi hình thức, thiết kế dữ liệu lôgic thường được mô tả bằng các bảng, các thiết kế giao diện, thiết kế cấu trúc dữ liệu chi tiết, thiết kế thuật toán thường được mô tả bằng pseudo code.

Chất lượng thiết kế

Không có cách nào hay để xác định được thế nào là thiết kế tốt. Tiêu chuẩn dễ bảo trì là tiêu chuẩn tốt cho người dùng. Một thiết kế dễ bảo trì có thể thích nghi với việc cải biên các chức năng và việc thêm các chức năng mới. Một thiết kế như thế phải dễ hiểu và việc sửa đổi chỉ có hiệu ứng cục bộ. Các thành phần thiết kế phải là kết dính (cohesive) theo nghĩa là tất cả các bộ phận trong thành phần phải có một quan hệ logic chặt chẽ, các thành phần ghép nối (coupling) với nhau là lỏng lẻo. Ghép nối càng lỏng lẻo thì càng dễ thích nghi, nghĩa là càng dễ sửa đổi để phù hợp với hoàn cảnh mới.

Để xem một thiết kế có là tốt hay không, người ta tiến hành thiết lập một số độ đo chất lượng thiết kế:

1. Sự kết dính (Cohesion) :Sự kết dính của một môđun là độ đo về tính khớp lại với nhau của các phần trong môđun đó. Nếu một môđun chỉ thực hiện một chức năng logic hoặc là một thực thể logic, tức là tất cả các bộ phận của môđun đó đều tham gia vào việc thực hiện một công việc thì độ kết dính là cao. Nếu một hoặc nhiều bộ phận không tham gia trực tiếp vào việc chức năng logic đó thì mức độ kết dính của nó là thấp. Thiết kế là tốt khi độ kết dính cao. Khi đó chúng ta sẽ dễ dàng hiểu được từng môđun và việc sửa chữa một môđun sẽ không (ít) ảnh hưởng tới các môđun khác. Constantine và Yourdon định ra 7 mức kết dính theo thứ tự tăng dần sau đây:
   1. Kết dính gom góp: các công việc không liên quan với nhau, song lại bị bó vào một môđun.
   2. Kết dính logic: các thành phần cùng thực hiện các chức năng tương tự về logic chẳng hạn như vào/ra, xử lý lỗi,... được đặt vào cùng một mô đun.
   3. Kết dính thời điểm: tất cả các thành phần cùng hoạt hóa một lúc, chẳng hạn như các thao tác khởi tạo được bó lại với nhau.
   4. Kết dính thủ tục: các phần tử trong môđun được ghép lại trong một dãy điều khiển.
   5. Kết dính truyền thông: tất cả các phần tử của môđun cùng thao tác trên một dữ liệu vào và đưa ra cùng một dữ liệu ra.
   6. Kết dính tuần tự: trong một môđun, đầu ra của phần tử này là đầu vào của phần tử khác.
   7. Kết dính chức năng: Mỗi phần của môđun đều là cần thiết để thi hành cùng một chức năng nào đó. Các lớp kết dính này không được định nghĩa chặt chẽ và cũng không phải luôn luôn xác định được. Một đối tượng kết dính nếu nó thể hiện như một thực thể đơn: tất cả các phép toán trên thực thể đó đều nằm trong thực thể đó. Vậy có thể xác định một lớp kết dính nữa là:
   8. Kết dính đối tượng: mỗi phép toán đều liên quan đến thay đổi, kiểm tra và sử dụng thuộc tính của một đối tượng, là cơ sở cung cấp các dịch vụ của đối tượng.
2. Sự ghép nối (Coupling):Ghép nối là độ đo sự nối ghép với nhau giữa các đơn vị (môđun) của hệ thống. Hệ thống có nối ghép cao thì các môđun phụ thuộc lẫn nhau lớn. Hệ thống nối ghép lỏng lẻo thì các môđun là độc lập hoặc là tương đối độc lập với nhau và chúng ta sẽ dễ bảo trì nó. Các mô đun được ghép nối chặt chẽ nếu chúng dùng các biến chung và nếu chúng trao đổi các thông tin điều khiển (ghép nối chung nhau và ghép nối điều khiển). Ghép nối lỏng lẻo đạt được khi bảo đảm rằng các thông tin cục bộ được che dấu trong các môđun và các môđun trao đổi thông tin thông qua danh sách tham số (giao diện) xác định. Có thể chia ghép nối thành các mức từ chặt chẽ đến lỏng lẻo như sau:
   1. Ghép nối nội dung: hai hay nhiều môđun dùng lẫn dữ liệu của nhau, đây là mức xấu nhất, thường xẩy ra đối với các ngôn ngữ mức thấp dùng các dữ liệu toàn cục hay lạm dụng lệnh GOTO.
   2. Ghép nối chung: một số môđun dùng các biến chung, nếu xẩy ra lỗi thao tác dữ liệu, sẽ khó xác định được lỗi đó do môđun nào gây ra.
   3. Ghép nối điều khiển: một môđun truyền các thông tin điều khiển để điều khiển hoạt động của một môđun khác.
   4. Ghép nối dư thừa: môđun nhận thông tin thừa không liên quan trực tiếp đến chức năng của nó, điều này sẽ làm giảm khả năng thích nghi của môđun đó.
   5. Ghép nối dữ liệu: Các môđun trao đổi thông tin thông qua tham số và giá trị trả lại.
   6. Ghép nối không có trao đổi thông tin: môđun thực hiện một chức năng độc lập và hoàn toàn không nhận tham số và không có giá trị trả lại.
   7. Ưu việt của thiết kế hướng đối tượng là do bản chất che dấu thông tin của đối tượng dẫn tới việc tạo ra các hệ ghép nối lỏng lẻo. Việc thừa kế trong hệ thống hướng đối tượng lại dẫn tới một dạng khác của ghép nối, ghép nối giữa đối tượng mức cao và đối tượng kế thừa nó.
3. Sự hiểu được (Understandability): Sự hiểu được của thiết kế liên quan tới một số đặc trưng sau đây:
   1. Tính kết dính: có thể hiểu được thành phần đó mà không cần tham khảo tới một thành phần nào khác hay không?
   2. Đặt tên: phải chăng là mọi tên được dùng trong thành phần đó đều có nghĩa? Tên có nghĩa là những tên phản ánh tên của thực thể trong thế giới thực được mô hình bởi thành phần đó.
   3. Soạn tư liệu: Thành phần có được soạn thảo tư liệu sao cho ánh xạ giữa các thực thể trong thế giới thực và thành phần đó là rõ ràng.
   4. Độ phức tạp: độ phức tạp của các thuật toán được dùng để thực hiện thành phần đó như thế nào? Độ phức tạp cao ám chỉ nhiều quan hệ giữa các thành phần khác nhau của thành phần thiết kế đó và một cấu trúc logic phức tạp mà nó dính líu đến độ sâu lồng nhau của cấu trúc ifưthenưelsse. Các thành phần phức tạp là khó hiểu, vì thế người thiết kế nên làm cho thiết kế thành phần càng đơn giản càng tốt. Đa số công việc về đo chất lượng thiết kế được tập trung vào cố gắng đo độ phức tạp của thành phần và từ đó thu được một vài độ đo về sự dễ hiểu của thành phần. Độ phức tạp phản ánh độ dễ hiểu, nhưng cũng có một số nhân tố khác ảnh hưởng đến độ dễ hiểu, chẳng hạn như tổ chức dữ liệu và kiểu cách mô tả thiết kế. Các số đo độ phức tạp có thể chỉ cung cấp một chỉ số cho độ dễ hiểu của một thành phần.
4. Sự thích nghi được (Adaptability): Một thiết kế dễ bảo trì thì nó phải sẵn sàng thích nghi được, nghĩa là các thành phần của chúng nên được ghép nối lỏng lẻo. Một thành phần có thể là ghép nối lỏng lẻo theo nghĩa là chỉ hợp tác với các thành phần khác thông qua việc truyền các thông báo. Sự thích nghi được còn có nghĩa là thiết kế phải được soạn thảo tư liệu tốt, dễ hiểu và nhất quán. Để có độ thích nghi thì hệ thống còn cần phải phải tự chứa. Muốn là tự chứa một cách hoàn toàn thì một hệ thống không nên dùng các thành phần khác được xác định ngoại lai. Tuy nhiên, điều đó lại mâu thuẫn với kinh nghiệm nói rằng các thành phần hiện có nên là dùng lại được. Vậy là cần có một cân bằng giữa tính ưu việt của sự dùng lại các thành phần và sự mất mát tính thích nghi được của hệ thống. Một trong những ưu việt chính của kế thừa trong thiết kế hướng đối tượng là các thành phần này có thể sẵn sàng thích nghi được. Cơ cấu thích nghi được này không dựa trên việc cải biên thành phần đã có mà dựa trên việc tạo ra một thành phần mới thừa kế các thuộc tính và các chức năng của thành phần đó. Chúng ta chỉ cần thêm các thuộc tính và chức năng cần thiết cho thành phần mới. Các thành phần khác dựa trên thành phần cơ bản đó sẽ không bị ảnh hưởng gì.

Cách tiếp cận hướng chức năng

Thiết kế hướng chức năng là một cách tiếp cận thiết kế phần mềm trong đó bản thiết kế được phân giải thành một bộ các đơn thể tác động lẫn nhau, mà mỗi đơn thể có một chức năng được xác định rõ ràng. Các chức năng có các trạng thái cục bộ nhưng chúng chia sẻ với nhau trạng thái hệ thống, trạng thái này là tập trung và mọi chức năng đều có thể truy cập được. Nhiều tổ chức đã phát triển các chuẩn và các phương pháp dựa trên sự phân giải chức năng. Nhiều phương pháp thiết kế kết hợp với công cụ CASE đều là hướng chức năng. Vô khối các hệ thống đã được phát triển bằng cách sử dụng phương pháp tiếp cận hướng chức năng. Các hệ thống đó sẽ được bảo trì cho một tương lai xa xôi. Bởi vậy thiết kế hướng chức năng vẫn sẽ còn được tiếp tục sử dụng rộng rãi.

Trong thiết kế hướng chức năng, người ta dùng các biểu đồ luồng dữ liệu (mô tả việc xử lý dữ liệu), các lược đồ cấu trúc (nó chỉ ra cấu trúc của phần mềm), và các mô tả thiết kế chi tiết. Thiết kế hướng chức năng gắn với các chi tiết của một thuật toán của chức năng đó nhưng các thông tin trạng thái hệ thống là không bị che dấu. Việc thay đổi một chức năng và cách nó sử dụng trạng thái của hệ thống có thể gây ra những tương tác bất ngờ đối với các chức năng khác. Cách tiếp cận chức năng để thiết kế là tốt nhất khi mà khối lượng thông tin trạng thái hệ thống được làm nhỏ nhất và thông tin dùng chung nhau là rõ ràng.

Biểu đồ luồng dữ liệu

Biểu đồ luồng dữ liệu chỉ ra cách thức biến đổi dữ liệu vào thành dữ liệu ra thông qua một dãy các phép biến đổi. Bước thứ nhất của thiết kế hướng chức năng là phát triển một biểu đồ luồng dữ liệu hệ thống. Biểu đồ này không nhất thiết bao gồm các thông tin điều khiển nhưng nên lập tư liệu các phép biến đổi dữ liệu. Biểu đồ luồng dữ liệu là một phần hợp nhất của một số các phương pháp thiết kế và các công cụ CASE thường trợ giúp cho việc tạo ra biểu đồ luồng dữ liệu.

Lược đồ cấu trúc

Lược đồ cấu trúc chỉ ra cấu trúc các thành phần theo thứ bậc của hệ thống. Nó chỉ ra rằng các phần tử của một biểu đồ luồng dữ liệu có thể được thực hiện như thế nào với tư cách là một thứ bậc của các đơn vị chương trình. Lược đồ cấu trúc có thể được dùng như là một mô tả chương trình nhìn thấy được với các thông tin xác định các sự lựa chọn và các vòng lặp. Lược đồ cấu trúc được dùng để trình bày một tổ chức tĩnh của thiết kế.

Các từ điển dữ liệu

Từ điển dữ liệu vừa có ích cho việc bảo trì hệ thống vừa có ích trong quá trình thiết kế. Với mỗi khái niệm thiết kế, cần có một từ khóa mô tả ứng với từ khóa (entry) của từ điển dữ liệu cung cấp thông tin về khái niệm đó (kiểu, chức năng của dữ liệu...). Đôi khi người ta gọi cái này là một mô tả ngắn của chức năng thành phần.

Các từ điển dữ liệu dùng để nối các mô tả thiết kế kiểu biểu đồ và các mô tả thiết kế kiểu văn bản. Một vài bộ công cụ CASE cung cấp một phép nối tự động biểu đồ luồng dữ liệu và từ điển dữ liệu.

Cách tiếp cận hướng đối tượng

Thiết kế hướng đối tượng dựa trên chiến lược che dấu thông tin cấu trúc vào bên trong các thành phần. Cái đó ngầm hiểu rằng việc kết hợp điều khiển logic và cấu trúc dữ liệu được thực hiện trong thiết kế càng chậm càng tốt. Liên lạc thông qua các thông tin trạng thái dùng chung (các biến tổng thể) là ít nhất, nhờ vậy khả năng hiểu được nâng lên. Thiết kế là tương đối dễ thay đổi vì sự thay đổi cấu trúc một thành phần có thể không cần quan tâm tới các hiệu ứng phụ trên các thành phần khác.

Việc che dấu thông tin trong thiết kế hướng đối tượng là dựa trên sự nhìn hệ phần mềm như là một bộ các đối tượng tương tác với nhau chứ không phải là bộ các chức năng như cách tiếp cận chức năng. Các đối tượng có một trạng thái riêng được che dấu và các phép toán trên trạng thái đó. Thiết kế biểu thị các dịch vụ được yêu cầu cùng với những hỗ trợ mà các đối tượng có tương tác với nó cung cấp.

Ba đặc trưng của thiết kế hướng đối tượng

Thiết kế hướng đối tượng bao gồm các đặc trưng chính sau:

1. Không có vùng dữ liệu dùng chung. Các đối tượng liên lạc với nhau bằng cách trao đổi thông báo.
2. Các đối tượng là các thực thể độc lập, dễ thay đổi vì rằng tất cả các trạng thái và các thông tin biểu diễn chỉ ảnh hưởng trong phạm vi chính đối tượng đó thôi. Các thay đổi về biểu diễn thông tin có thể được thực hiện không cần sự tham khảo tới các đối tượng khác.
3. Các đối tượng có thể phân tán và có thể hoạt động tuần tự hoặc song song. Đây là một trong những lý do khiến cho thiết kế hướng đối tượng được sử dụng rộng rãi trong các hệ thống nhúng.

Cơ sở của thiết kế hướng đối tượng

Cơ sở của thiết kế hướng đối tượng là các lớp. Lớp là một trừu tượng mô tả cho một nhóm sự vật. Đối tượng của một lớp là một thực thể (cụ thể hóa) của lớp đó. Thiết kế của một lớp bao gồm:

• Cấu trúc dữ liệu (thuộc tính)
• Hàm, thủ tục (chức năng)
• Giao diện (cung cấp khả năng trao đổi dữ liệu đối với các lớp khác, về bản chất là các chức năng của đối tượng)

Việc cài đặt các giao diện là một yếu tố quan trọng để đảm bao che dấu cấu trúc dữ liệu. Tức là thiết kế nội tại của đối tượng độc lập với giao diện do đó chúng ta có thể sửa đổi thiết kế mà không sợ ảnh hưởng tới các đối tượng khác.

Các đối tượng trao đổi với nhau bằng cách truyền các thông báo. Tức là một đối tượng yêu cầu một đối tượng khác thực hiện một chức năng nào đó. Thông báo bao gồm: tên đối tượng, tên phương thức, và các tham số.

Vòng đời của một đối tượng khi hệ thống hoạt động như sau:

• Khởi tạo: hệ thống tạo ra đối tượng bằng cách xác lập vùng dữ liệu đồng thời tự động thực hiện các chức năng liên quan đến khởi tạo đối tượng.
• Hoạt động: đối tượng nhận các thông báo và thực hiện các chức năng được yêu cầu.
• Phá hủy: hệ thống giải phóng vùng nhớ đã được cấp phát sau khi thực hiện tự động các thao tác cần thiết để hủy đối tượng.

Nhờ có chức năng khởi tạo và phá hủy được gọi tự động chúng ta có thể tự động hóa được một số công việc và tránh được nhiều sai sót trong lập trình như quên khởi tạo dữ liệu, quên cấp phát hay quên giải phóng vùng nhớ động.

Sự kế thừa. Kế thừa là một khái niệm quan trọng trong thiết kế hướng đối tượng. Một lớp có thể được định nghĩa dựa trên sự kế thừa một hoặc nhiều lớp đã được định nghĩa. Kế thừa ở đây bao gồm

• . Kế thừa cấu trúc dữ liệu
• . Kế thừa chức năng

Khả năng kế thừa giúp cho rút gọn được chương trình và nâng cao tính tái sử dụng. Một chiến lược chung là trước tiên tạo ra các lớp trừu tượng (để có thể dùng chung) và đối với các bài toán cụ thể tạo ra các lớp kế thừa bằng cách thêm các thông tin đặc thù.

Các bước thiết kế

Thiết kế hướng đối tượng bao gồm các bước chính sau:

1. Xác định lớp đối tượng.
2. Xác định thuộc tính cho lớp: các biến của lớp
3. Xác định hành vi (chức năng): các hàm
4. Xác định tương tác giữa các lớp đối tượng: giao diện (thông báo).
5. Áp dụng tính kế thừa: xây dựng các lớp trừu tượng có các thuộc tính chung, đây là một khâu đặc trưng của thiết kế hướng đối tượng.

Ví dụ, giả sử cần xây dựng các lớp hình tròn, elíp và đa giác. Có thể thấy elip và hình tròn có một số các thuộc tính chung như tọa độ tâm, chúng ta có thể xây dựng lớp hình nón chứa các thuộc tính chung này. Giữa hình nón và đa giác lại có thể tìm ra các thuộc tính chung như mầu nền, mầu biên..., và có thể xây dựng lớp trừu tượng hình hình học chứa các thuộc tính này.

Phương pháp xác định đối tượng Xác định đối tượng là một trong nhưng công đoạn thiết kế quan trọng, phụ thuộc nhiều vào kinh nghiệm và bài toán cụ thể. Có một số phương pháp được đề xuất, một trong các phương pháp này là phân tích từ vựng của “câu yêu cầu”. Cụ thể là danh từ trong câu yêu cầu sẽ được coi là đối tượng và động từ sẽ được coi là chức năng.

Ví dụ: Với yêu cầu Phần mềm Email cung cấp cho user khả năng gửi thư, đọc thư và soạn thảo thư điện tử., chúng ta có thể sơ bộ tạo ra các đối tượng phần mềm, user, email và các chức năng gửi, nhận, soạn thảo.

Ưu nhược điểm của thiết kế hướng đối tượng

Thiết kế hướng đối tượng có các ưu điểm chính sau:

• Dễ bảo trì vì các đối tượng là độc lập. Các đối tượng có thể hiểu và cải biên như là một thực thể độc lập. Thay đổi trong thực hiện một đối tượng hoặc thêm các dịch vụ sẽ không làm ảnh hưởng tới các đối tượng hệ thống khác.
• Các đối tượng là các thành phần dùng lại được thích hợp do tính độc lập của chúng và khả năng kế thừa cao.
• Có một vài lớp hệ thống thể hiện phản ánh quan hệ rõ ràng giữa các thực thể có thực (chẳng hạn như các thành phần phần cứng) với các đối tượng điều khiển nó trong hệ thống. Điều này đạt được tính dễ hiểu của thiết kế.

Nhược điểm chính của thiết kế hướng đối tượng là sự khó nhận ra các đối tượng của một hệ thống. Cách nhìn tự nhiên đối với nhiều hệ thống là cách nhìn chức năng.

Quan hệ giữa thiết kế và lập trình hướng đối tượng

Thiết kế hướng đối tượng là một chiến lược thiết kế, không phụ thuộc vào ngôn ngữ thực hiện cụ thể nào. Các ngôn ngữ lập trình hướng đối tượng có các khả năng bao gói đối tượng, và kế thừa làm cho việc thực hiện thiết kế hướng đối tượng an toàn hơn và đơn giản hơn.

Một thiết kế hướng đối tượng cũng có thể được thực hiện trong một ngôn ngữ thủ tục kiểu như PASCAL hoặc C (không có các đặc điểm bao gói như vậy). Ada không phải là ngôn ngữ lập trình hướng đối tượng vì nó không trợ giúp sự thừa kế của các lớp, nhưng lại có thể thực hiện các đối tượng trong Ada bằng cách sử dụng các gói hoặc các nhiệm vụ (tasks), do đó Ada cũng được dùng để mô tả các thiết kế hướng đối tượng.

Tuy nhiên, cũng phải nhấn mạnh rằng chúng ta có thể mô tả thiết kế hướng đối tượng trên các ngôn ngữ truyền thống nhưng chúng ta không thể kiểm tra được sự tuân thủ tư tưởng hướng đối tượng trên các ngôn ngữ này, nghĩa là người phát triển vẫn có thể truy cập đến cấu trúc dữ liệu vật lý của đối tượng và việc đó làm vô nghĩa khái niệm che dấu thông tin.

Việc chấp nhận thiết kế hướng đối tượng như là một chiến lược hữu hiệu dẫn đến sự phát triển rộng rãi các phương pháp thiết kế hướng đối tượng và các ngôn ngữ lập trình hướng đối tượng.

Quan hệ giữa thiết kế hướng đối tượng và hướng chức năng

Có nhiều quan niệm khác nhau về quan hệ giữa thiết kế hướng đối tượng và thiết kế hướng chức năng. Có người cho rằng, hai chiến lược thiết kế này hỗ trợ lẫn nhau, cụ thể là

• DFD dưa ra mô hình về các thuộc tính và chức năng
• Luồng giao tác đưa ra hướng dẫn về tương tác giữa các đối tượng (thông báo)
• Mô hình E - R đưa ra hướng dẫn xây dựng đối tượng

Thêm nữa, thiết kế nội tại của lớp đối tượng có nhiều điểm tương đồng với thiết kế hướng chức năng.

Một quan điểm khác cho rằng thiết kế hướng đối tượng và thiết kế hướng chức năng là hai cách tiếp cận hoàn toàn khác nhau, các khái niệm như che dấu thông tin, kế thừa là đặc trưng quan trọng và bản chất của thiết kế hướng đối tượng và nếu không dứt bỏ cách nhìn thiết kế hướng chức năng thì không thể khai thác hiệu quả các đặc trưng này.

Một số vấn đề thiết kế

Trong thiết kế giao diện, cần chú ý tới một số vấn đề sau:

1. Thời gian phản hồi. Chúng ta cần quan tâm tới hai loại thời gian là
   • Thời gian đáp ứng trung bình: là thời gian trung bình mà hệ thống phản hồi đối với một yêu cầu của người dùng. Thời gian để sinh ra “kết quả thực sự” của yêu cầu sẽ phụ thuộc vào bản chất yêu cầu, thuật toán, tốc độ của máy tính, tuy nhiên chúng ta cần quan tâm khía cạnh tâm lý là nếu người dùng đợi quá lâu mà không nhận được thông tin gì thì họ sẽ nghĩ là có vấn đề và có thể sẽ tiến hành các thao tác ngoài mong đợi như lặp lại thao tác hay dừng hệ thống.
   • Độ biến thiên của thời gian: độ biến thiên của thời gian cũng là đại lượng cần quan tâm. Nếu độ biến thiên lớn, ví dụ một thao tác thường được đáp ứng trong 1 giây mà có trường hợp phải mất 5 giây mới hoàn thành thì cũng có thể làm cho người dùng đưa ra các thao tác sai.
2. Các tiện ích. Một giao diện tốt cần có các tiện ích để trợ giúp người sử dụng. Có các loại tiện ích sau
   • Tích hợp: là tiện ích được tích hợp vào giao diện như nút Help cung cấp các thuyết minh về thao tác.
   • Phụ thêm: là các tiện ích phụ thêm như các tài liệu trực tuyến.
   • Macro: một số chương trình còn cho phép người dùng tự động hóa một số thao tác bằng các lệnh kiểu macro.
3. Thông báo. Các thông báo do hệ thống đưa ra cần
   • Có nghĩa: mọi thông báo cần có nghĩa đối với người dùng.
   • Ngắn gọn: các thông báo cần ngắn gọn đi vào bản chất vấn đề, đặc biệt là đối với kiểu giao diện dòng lệnh.
   • Có tính xây dựng: thông báo nên có tính xây dựng như đưa ra các nguyên nhân và các hướng khắc phục.

Một số hướng dẫn thiết kế

Dưới đây là một số yếu tố mà giao diện tốt nên có:

• Hướng người dùng: đối tượng người dùng phải rõ ràng, giao diện nên được thiết kế có tính đến năng lực, thói quen... của loại đối tượng đó.
• Có khả năng tùy biến cao: giao diện nên có khả năng tùy biến cao để phục vụ cho các cá nhân có cách sử dụng khác nhau, các môi trường hoạt động khác nhau.

Các phần mềm trên hệ UNIX với giao diện theo chuẩn X protocol thường được thiết kế có độ tùy biến rất cao.

• Nhất quán: các biểu tượng, thông báo, cách thức nhập dữ liệu phải nhất quán và nên tuân theo các chuẩn thông thường.
• An toàn: nên có chế độ xác nhận lại đối với các thao tác nguy hiểm (như xóa dữ liệu) và nên có khả năng phục hồi trạng thái cũ (undo).
• Dễ học, dễ sử dụng: giao diện luôn cần được thiết kế hướng tới tính dễ học, dễ sử dụng, tức là không đòi hỏi người dùng phải có các năng lực đặc biệt. Ví dụ như không cần nhớ nhiều thao tác, không đòi hỏi phải thao tác nhanh, các thông tin trên màn hình dễ đọc... Một cách tốt nhất để xây dựng giao diện dễ học dễ sử dụng là tuân theo các chuẩn giao diện thông dụng.

Tổng kết: Thiết kế là cái lõi của kỹ nghệ phần mềm. Trong khi thiết kế người ta sẽ phát triển, xét duyệt và làm tư liệu cho việc làm mịn dần các chi tiết thủ tục, cấu trúc chương trình, cấu trúc dữ liệu. Thông qua thiết kế và xét duyệt, chúng ta có thể thẩm định được chất lượng phần mềm. Tính môđun (trong cả chương trình và dữ liệu) và khái niệm trừu tượng làm cho người thiết kế có khả năng đơn giản hóa và dùng lại các thành phần phần mềm. Việc làm mịn đưa ra một cơ chế để biểu diễn các tầng kế tiếp của chi tiết chức năng. Cấu trúc chương trình và dữ liệu đóng góp cho một quan điểm tổng thể về kiến trúc phần mềm, trong khi thủ tục lại đưa ra những chi tiết cần thiết cho việc cài đặt thuật toán. Che dấu thông tin và độc lập chức năng đưa ra những trực cảm để đạt tới tính môđun có hiệu quả. có thể được xem xét hoặc theo cách nhìn kỹ thuật hoặc theo cách nhìn quản lý dự án. Theo quan điểm kỹ thuật, thiết kế bao gồm 4 hoạt động: thiết kế dữ liệu, thiết kế kiến trúc, thiết kế thủ tục và thiết kế giao diện. Theo quan điểm quản lý, thiết kế tiến hóa từ thiết kế sơ bộ sang thiết kế chi tiết. Ký pháp thiết kế, đi kèm với các khái niệm lập trình có cấu trúc làm cho người thiết kế biểu diễn được chi tiết thủ tục theo cách thức làm thuận tiện cho việc dịch sang mã chương trình. Chúng ta có thể sử dụng các ký pháp đồ họa, bảng và ngôn ngữ mô tả.

Còn nhiều phương pháp thiết kế phần mềm quan trọng như thiết kế hướng chức năng, hướng đối tượng. Những phương pháp này, được kết hợp với những nền tảng đã trình bày ở trên tạo nên cơ sở cho một cách nhìn đầy đủ về thiết kế phần mềm.