Giáo trình Nhập môn công nghệ phần mềm: Phần 2 - Nguyễn Thế Dũng

Giáo trình Nhập môn công nghệ phần mềm giúp cho sinh viên nắm được quá trình phát triển một phần mềm một cách hiệu quả, mang tính công nghiệp và hiểu được những khái niệm cơ bản thuộc lĩnh vực này. Trên cơ sở đó sinh viên có định hướng đúng đắn khi học tập nghiên cứu các môn khác cũng như đi sâu vào nghiên cứu và thực hành làm phần mềm. Mời các bạn cùng tham khảo nội dung phần 2 giáo trình.

Chương 4 THIẾT KẾ

Mục đích

Trình bày quá trình thiết kế phần mềm, thiết kế kiến trúc, thiết kế giao diện Bên cạnh đó quá trình thiết kế phần mềm theo phương pháp hướng đối tượng cũng được trình bày

Yêu cầu

+ Biết được các hoạt động của thiết kế và các sản phẩm

+ Hiểu các nguyên lý thiết kế

+ Hiểu được các nguyên tắc thiết kế giao diện

+ Vận dụng vào bộ môn Phân tích thiết kế hệ thống

Cũng như trong phần phân tích và đặc tả yêu cầu, trong phần này chúng tôi cũng không tách riêng phần thiết kế theo phương pháp hướng đối tượng thành một chương của giáo trình mà chỉ đưa vào thành một mục của chương này Tuy mục này khá dài nhưng sẽ không làm cho bố cục của giáo trình quá cồng kềnh

1 Khái niệm về thiết kế phần mềm

1.1.Khái niệm

Có thể định nghĩa thiết kế là một quá trình áp dụng 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ó

Trong khi phân tích nhằm trả lời câu hỏi vấn đề là cái gì (What?), thì thiết

kế nhằm trả lời câu hỏi làm thế nào (How to do?)

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ể

1.2 Tầm quan trọng

1.2.1 Vai trò

Tạo mô hình cài đặt của phần mềm, là phương tiện trao đổi thông tin để đảm bảo chất lượ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 Thiết

kế phần mềm 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 Thiết

kế phần mềm 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

1.2.2 Thiết kế và chất lƣợng

• Thiết kế phải thỏa yêu cầu tường minh cũng như ngầm định

• Thiết kế phải dễ hiểu, dễ đọc và hỗ trợcho việc tạo code, test và hỗ trợ phần mềm

• Thiết kế phải cung cấp hình ảnh đầy đủ của phần mềm, xác định dữ liệu, chức năng và hành vi

Nếu không có thiết kế; hoặc thiết kế tồi dẫn đến: làm tăng công sức mã hóa

và tăng công sức bảo trì

1.3 Quá trình thiết kế

Thiết kế phần mềm 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 Thiết kế 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

1.4 Các hoạt động thiết kế phần mềm

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ế 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

Hình 4.1 Các hoạt động thiết kế phần mềm

Hình 4.2 Hoạt động thiết kế và sản phẩm tương ứng

Các vấn đề liên quan đến thiết kế dữ liệu và thiết kế thuật toán đã được đề cập khá kỹ lưỡng trong các môn học như Nhập môn cơ sở dữ liệu và môn học Phân tích thiết kế thuật toán, nên thường thì trong các giáo trình môn học Công

nghệ phần mềm không đi sâu vào các phần vừa nói trên, mà đi vào các hoạt động thiết kế đó là thiết kế kiến trúc và thiết kế giao diện…

1.5 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 module

- Mối quan hệ (gọi thực hiện lẫn nhau) giữa các module

- Cách thức trao đổi thông tin giữa các module (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 module, cũng như các trạng thái và hoạt động bên trong của mỗi module Nội dung của các module đượ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

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 mã giả (pseudo code)

1.6 Nguyên lý thiết kế

1 Thiết kế không bị bó buộc vào một cách nhìn hạn chế nào, nó cần được lựa chọn từ các giải pháp có thể

2 Cho phép lần ngược lại mô hình phân tích

• Các module và các yêu cầu không nhất thiết phải tương ứng 1-1, nhưng phải kiểm tra được sự thỏa mãn các yêu cầu

3 Không nên tạo lại các thiết kế (giải pháp) đã có, mà cần tái sử dụng tối đa chúng

4 Mô hình thiết kế (giải pháp) nên tiến gần đến mô hình thế giới thực (bài toán)

5 Biểu diễn thiết kế phải nhất quán và có tính tích hợp:

• + Thiết kế do nhiều người tiến hành song song

+ Phải thống nhất cách biểu diễn, thống nhất giao diện

6 Thiết kế cần có cấu trúc để dễ hiểu, dễ thay đổi, tức phải được module hóa, phân cấp

7 Thiết kế không phải là mã hóa, thiết kế luôn có mức trừu tượng hơn mã hóa, để đảm bảo dễ hiểu, dễ thay đổi

8 Thiết kế cần được đánh giá chất lượng ngay trong khi được tạo ra, thể hiện qua tính kết dính, tính ghép nối, hiệu quả thuật toán…

9 Thiết kế cần được thẩm định để tránh các lỗi mang tính hệ thống như thiếu chức năng, chức năng không rõ, mâu thuẫn

1.7 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

Tiêu chí chất lƣợng

Cần thiết lập các tiêu chí kỹ thuật để đánh giá một thiết kế tốt hay không:

+ Thiết kế cần có kiến trúc tốt: cấu thành từ các mẫu (pattern), các thành phần có đặc trưng tốt, dễ tiến hoá

+ Thiết kế được môđul hoá cho mỗi thành phần chức năng

+ Chứa các biểu diễn tách biệt nhau về: dữ liệu, kiến trúc, giao diện, thành phần, môi trường

+ Liên kết qua giao diện làm giảm độ phức tạp liên kết giữa các môđul với nhau và giữa hệ thống và môi trường

Để 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ế

Một số độ đo:

•- Cohesion: mức độ liên kết giữa các thành phần trong một module

•- Coupling: mức độ ghép nối giữa các module

- Understandability: tính hiểu được

•- Adaptability: tính thích nghi được

1) Sự kết dính (Cohesion)

Sự kết dính của một module là độ đo về tính khớp lại với nhau của các phần trong module đó Nếu một module 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 module đó đề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 module và việc sửa chữa một module sẽ không (ít) ảnh hưởng tới các module khác

8 mức kết dính theo thứ tự tăng dần sau đây:

a 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 module

b 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 module

c 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 các thành phần hoạt động cùng thời điểm (ví dụ: hàm khởi tạo;đọc dữ liệu, cấp phát bộ nhớ )

d Kết dính thủ tục: các phần tử trong module được ghép lại trong một dãy điều khiển Các thành phần thực hiên theo một thứ tự xác định (ví dụ: tính lương

cơ bản, tính phụ cấp, tính bảo hiểm)

e Kết dính truyền thông: tất cả các phần tử của module 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 Các thành phần truy cập đến cùng tập dữ liệu:, chẳng hạn như các tính toán thống kê (tính max, min, mean, varian )

f Kết dính tuần tự: trong một module, đầu ra của phần tử này là đầu vào của phần tử khác Output của một thành phần là input của thành phần tiếp theo

g Kết dính chức năng: Mỗi phần của module đều là cần thiết để thi hành cùng một chức năng nào đó Các thành phần cùng góp phần thực hiện một chức năng

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à:

h 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ị (module) của hệ thống Hệ thống có nối ghép cao thì các module phụ thuộc lẫn nhau lớn Hệ thống nối ghép lỏng lẻo thì các module 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 module đượ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 module và các module 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:

a Ghép nối nội dung: hai hay nhiều module 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

Ví dụ (ghép nối nội dung):

Ví dụ: (minh họa ghép nối chung)

c Ghép nối điều khiển: một module truyền các thông tin điều khiển để điều khiển hoạt động của một module khác

d Ghép nối dư thừa: module 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 module đó

e Ghép nối dữ liệu: Các module trao đổi thông tin thông qua tham số và giá trị trả lại

f Ghép nối không có trao đổi thông tin: module 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

Ư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:

a 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?

b Đặ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 đó

c 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

d Độ 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ì

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

2.1 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 Rất nhiều các hệ thống đã đượcphá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 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 (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

2.2 Các cơ sở của thiết kế phần mềm hướng chức năng

2.2.1 Trừu tượng hóa

Trừu tượng hóa là một khái niệm cơ sở trong tư duy của con người, đây là

quá trình ánh xạ một sự vật/hiện tượng của thế giới thực thành một khái niệm

logic

Có nhiều mức trừu tượng khác nhau nhằm cho phép con người tập trung (tư duy) vào giải quyết vấn đề mà không cần bận tâm đến chi tiết hoặc biểu diễn vấn

đề bằng một cấu trúc tự nhiên

Trong thiết kế phần mềm có các trừu tượng hóa như trừu tượng hóa dữ liệu, trừu tượng hóa chức năng, trừu tượng hóa điều khiển…

Quá trình thiết kế trải qua nhiều mức trừu tượng hoá khác nhau:

Mức cao nhất: vấn đề cần thiết kế được mô tả một cách tổng quát sử dụng thuật ngữ hướng vấn đề

Các mức thấp hơn: hướng đến thủ tục xử lý chi tiết; kết hợp các thuật ngữ hướng đến hiện thực

Mức thấp nhất: vấn đề được mô tả theo cách có thể hiện thực trực tiếp Phân loại trừu tượng hoá: trừ tượng hóa dữ liệu và trừu tượng hoá thủ tục Trừu tượng hóa thủ tục là xác định chuỗi các lệnh liên tiếp thực hiện chức năng nào đó

Ví dụ: mở cửa (bao gồm đi đến cửa, cầm lấy tay nắm, xoay tay nắm, kéo cánh cửa, đi vào…); thêm một phần tử vào danh sách có thứ tự (xác định vị trí, chèn phần tử mới)

Trừu tượng hoá dữ liệu: là tổ hợp dữ liệu mô tả một đối tượng dữ liệu (liên

hệ tới đối tượng thực thể trong UML)

2.2.3 Phân chia module

Khái niệm module đã xuất hiện khoảng 4 thập niên trở lại đây Phần mềm được xây dựng bằng cách phân chia thành nhiều module, sau đó sẽ được tích hợp lại Quá trình này dựa trên chiến lược “chia để trị”

Phân chia module làm cho việc quản lý phần mềm khoa học hơn, nhằm giảm độ phức tạp cục bộ, dễ sửa đổi, có khả năng phát triển song song, dễ sửa đổi, dễ hiểu nên dễ tái sử dụng

Giả sử C(x): độ phức tạp của x, E(x): công sức để thực hiện x Rõ ràng: nếu C(p1) > C(p2) thì E(p1) > E(p2)

Nếu phân chia p = p1 + p2 ta thấy:

C(p1 + p2) > C(p1) + C(p2) => E(p1 + p2) > E(p1) + E(p2)

Số lượng module phụ thuộc vào độ phức tạp của hệ thống phần mềm cần xây dựng quá ít hoặc quá nhiều module đều không tốt

Hình 4.3 Số lƣợng module và chi phí tích hợp module

Kích cỡ module được quyết định dựa trên khái niệm độc lập chức năng: mỗi module nên thực hiện một công việc nhằm dễ hiểu, dễ sửa đổi, dễ tái sử dụng

Một số heuristics cho việc phân chia module

Nhiều khi cần sửa lại thiết kế ban đầu để tăng độ kết dính và giảm sự liên kết, với lưu ý: Gữ cho tầm ảnh hưởng của một module nằm bên trong tầm điều khiển của nó và loại bỏ dư thừa trong giao tiếp của các module Bên cạnh đó cần

ưu tiên các module tất định, hạn chế các module nhiều ràng buộc, đóng gói các module để đạt được tính khả chuyển (portability)

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

Kiến trúc phần mềm mô tả các thành phần (component) kiến tạo nên hệ thống phần mềm và sự giao tiếp giữa các thành phần đó

ƒThành phần có thể là: Các module mã nguồn; Các file thực thi (*.dll,

*.exe, *.class ); Các thành phần của kiến trúc hệ thống: ActiveX control, bean ; Các trang HTML, *.asp, *.jsp

2.2.5 Cấu trúc dữ liệu

Cấu trúc dữ liệu mô tả sự tổ chức, phương thức truy xuất, mức độ liên kết và các xử lý khác của thông tin Dữ liệu đơn là dạng cấu trúc dữ liệu đơn giản nhất chỉ bao gồm một phần tử thông tin mà có thể được truy xuất bằng một danh định Một số dạng phức tạp hơn: vector, ma trận, mảng nhiều chiều, danh sách liên kết, hàng, chồng, cây nhị phân… Được biểu diễn ở các mức trừu tượng hoá khác nhau

2.2.6 Thủ tục

Thủ tục tập trung vào chi tiết xử lý của mỗi module Cung cấp đặc tả chi tiết của: Chuỗi sự kiện; Vòng lặp; Quyết định rẽ nhánh; Có thể cả cấu trúc dữ liệu

2.2.7 Nguyên lý che dấu thông tin

Che dấu thông tin là một trong những nguyên lý quan trọng của việc phân chia module Các module giao tiếp với nhau bằng những thông tin thật sự cần thiết Những thông tin về thủ tục và dữ liệu cục bộ của mỗi module phải được che dấu khỏi các module khác

Lợi ích: Kiểm soát được thay đổi và sửa lỗi dễ dàng

Tại sao phải che dấu thống tin:

• Giảm hiệu ứng lề

• Giới hạn những tác động toàn cục lên những quyết định thiết kế cục bộ

• Nhấn mạnh tới việc thông tin qua những giao diện có điều khiển

• Ngăn cản việc dùng dữ liệu cục bộ

• Đưa tới việc đóng gói là một thuộc tính của thiết kế chất lượng cao

• Làm cho phần mềm chất lượng cao hơn

2.2.8 Thiết kế dữ liệu

Nhằm tìm kiếm biểu diễn luận lý cho các phần tử dữ liệu đã được nhận diện trong giai đoạn phân tích yêu cầu Giai đoạn này bao gồm cả thiết kế các cấu trúc

dữ liệu của chương trình và cơ sở dữ liệu Gai đoạn này chúng ta cần thực hiện tinh chế từng bước

Một số nguyên tắc:

+ Nhận diện cả cấu trúc dữ liệu và tác vụ truy xuất

+ Chú ý sử dụng từ điển dữ liệu

+ Trì hoãn thiết kế dữ liệu mức thấp cho đến cuối giai đoạn này

+ Che dấu biểu diễn bên trong của cấu trúc dữ liệu

+ Phát triển một thư viện các cấu trúc dữ liệu và các tác vụ thường gặp Các vấn đề của thiết kế cơ sở dữ liệu đã được đề cập nhiều trong môn học Nhập môn Hệ cơ sở dữ liệu, nên chúng tôi không đưa chi tiết vào đây Mời bạn đọc xem lại trong các tài liệu tham khảo liên quan

3 Thiết kế kiến trúc

3.1 Khái niệm kiến trúc

Kiến trúc phần mềm chỉ cấu trúc tổng thể của một phần mềm và cách thức

tổ chức qua đó cho ta một sự tích hợp về mặt khái niệm của một hệ thống [SHA95a]

Ở mức thông thường, kiến trúc phần mềm được thể hiện bằng một biểu đồ phân cấp của các thành phần vàquan hệ giữa chúng Ở mức đầy đủ cần thể hiện cầu trúc hệ thống theo nhiều góc nhìn khác nhau: góc nhìn tĩnh, động, dữ liệu, triển khai

Mô hình kiến trúc không phải là mô hình hoạt động mà là mô hình phân hoạch theo những cách nhìn khác nhau (chức năng, dữ liệu, tiến trình, tĩnh hay động…) nhằm giúp kỹ sư hệ thống: Phân tích tính hiệu quả của thiết kế đáp ứng được yêu cầu của phần mềm và tìm các giải pháp thay thế kiến trúc ở giai đoạn sớm cũng như giảm các rủi ro liên quan tới kiến trúc

3.2 Khái niệm thiết kế kiến trúc

Giai đoạn thiết kế kiến trúc là giai đoạn đầu của quá trình thiết kế nhằm biểu diễn sự kết nối giữa đặc tả yêu cầuvà các tiến trình thiết kế Giai đoạn này thường

tiến hành song song với các hoạt động đặc tả phần mềm Bao gồm việc xác định các thành phần hệ thống và giao tiếp giữa chúng

Các bước thiết kế kiến trúc

1 Cấu trúc hóa hệ thống: phân chia hệ thống thành các hệ con system) độc lập và xác định trao đổi thông tin giữa các hệ con xác d?nh các giao diện của chúng

(sub-2 Mô hinh hóa điều khiển: xác lập mô hinh điều khiển giữa các phần khác nhau của hệ thống đã được xác định

3 Phân rã thành các module: phân rã các hệ con thành các module

Ở đây hệ con: phần hệ thống hoạt động độc lập với các dịch vụ mà các hệ con khác cung cấp

Module: phần hệ thống cung cấp dịch vụ và tương tác cùng phần khác để tạo ra dịch vụ hay sản phẩm

3.3 Mô hình kiến trúc

Các mô hình kiến trúc khác nhau được tạo ra trong quá trình thiết kế Mỗi

mô hình biểu diễn một cách nhìn của kiến trúc Mô hình kiến trúc tĩnh chỉ ra các thành phần chính của hệ thống (biểu đồ phân rã) Mô hình động chỉ ra cấu trúc tiến trình của hệ thống (biểu đồ luồng dữ liệu) Mô hình giao diện xác định hệ thống giao diện của hệ thống (hệ thống giao diện tương tác) Mô hình mối quan hệ như mô hình khái niệm thực thể xác định miền dữ liệu của hệ thống

Mô hình kiến trúc bao gồm: Mô hình cấu trúc; Mô hình điều khiển; Mô hình phân rã module

3.3.1 Mô hình cấu trúc

Mô hình cấu trúc bao gồm:

+ Kiến trúc dữ liệu tập trung

+ Kiến trúc khách-dịch vụ

+ Kiến trúc phân tầng

+ Kiến trúc dữ liệu tập trung

Hình 4.4 Mô hình kiến trúc dữ liệu tập trung

Ưu điểm:

• Tiện lợi cho chia sẻ dữ liệu lớn

• Các phân hệ không cần quan tâm tổ chứcdữ liệu

Nhược điểm:

• Các phân hệ phải thống nhất mô hình dữ liệu

• Khó thay đổi cấu trúc dữ liệu

• Các phân hệ không thể đưa ra chính sách riêng

• Khó khăn trong quản lý giao dịch

+ Kiến trúc khách dịch vụ (Client-Server Architecture)

Hệ thống được phân tán về dữ liệu và xử lý thông qua quan hệ các thành phần Các máy dịch vụ (server) độc lập cung cấp các dịch vụ đặc biệt như: in ấn, quản lý dữ liệu Các máy khách (client) sử dụng dịch vụ server Hệ thống mạng để client truy cập dịch vụ server

Hình 4.5 Kiến trúc khách dịch vụ (Client-Server Architecture)

• Cần cơ chế bảo toàn dữ liệu cho từng server

Đây là mô hình phát triển ứng dụng phổ biến hiện nay

+ Kiến trúc phân tầng (Layered Architecture/Abstract machine model)

Kiểu kiến trúc nhằm mô hình hóa tương tác các hệ con Mô hình này phân

rã hệ thống thành các tầng, mỗi tầng cung cấp một tập các dịch vụ Mô hình này

hỗ trợ sự phát triển tăng trưởng của các tầng, khi giao diện mỗi tầng thay đổi thi chỉ ảnh hưởng tới các tầng liền kề Tuy vậy không phải hệ thống nào cũng xây dựng cấu trúc hệ thống được theo kiến trúc này

Một ví dụ minh họa cho mô hình này là kiến trúc mô hình tham chiếu OSI trong mạng máy tính

Hình 4.6 Mô hình kiến trúc phân tầng 3.3.2 Mô hình điều khiển

Mô hình điều khiển bao gồm:

+ Kiến trúc gọi và trả lại

+ Kiến trúc xử lý hướng sự kiện

+ Kiến trúc gọi và trả lại (Call and Return Architecture )

Mô hình này sử dụng một hệ con để điều khiển, khởi động và dừng các hệ thống con khác, truyền điều khiển hoạt động của hệ thhống trên xuống Mô hình thường dùng cho các hệ thống tuần tự

Hình 4.7 Kiến trúc gọi và trả lại + Kiến trúc xử lý sự kiện (Event-driven Architecture)

Kiến trúc xử lý hướng sự kiện là cơ chế gửi yêu cầu xử lý đến các hệ con Bao gồm hai mô hình chính: Điều khiển quảng bá (Broadcast) và Điều khiển hướng ngắt (Interupt)

Mô hình điều khiển quảng bá (Broadcast): Một sự kiện được truyền đến

tất cả các hệ con Hệ con được truyền điều khiển khi đã có đăng ký

Mô hình này hiệu quả trong tích hợp các hệ con Tuy vậy thường thì các hệ con không biết sự kiện đã được xử lý chưa

Hình 4.8 Mô hình điều khiển quảng bá

Mô hình điều khiển hướng ngắt (Interupt): Mô hình này thường được

dùng trong các hệ thời gian thực Bộ điều khiển ngắt nhận sự kiện và truyền đến các thành phầnxử lý Mô hình này đáp ứng phản hồi nhanh nhưng sẽ khó lập trình

và đánh giá

Hình 4.9 Mô hình điều khiển hướng ngắt 3.3.3 Mô hình phân rã module

Đây là cấp độ kiến trúc mà các hệ thống con được phân rã thành các module Mô hình phân rã module bao gồm:

+ Mô hình đối tượng: hệ thống được phân rã dựa trên sự tương tác giữa các đối tượng

+ Mô hình luồng dữ liệu: hệ thống được phân tách thành các module chức năng chuyển các đầu vào thành các đầu ra (mô hình đường ống - pipeline)

+ Mô hình hướng đối tượng

Mô hình là tập hợp đối tượng ghép nối lỏng lẻo qua giao diện Trong mô hình này chúng ta cần xác định: lớp, đốitượng, thuộc tính, phương thức và xác định mô hình điều khiển để phối hợp thao tác giữa các đối tượng

+ Mô hình luồng dữ liệu

Trong mô hình này, mỗi chức năng là một tiến trình chuyển hóa các đầu vào thành các đầu ra Các biến thể của nó là: pipe/filter model, batch model… Mô hình này không phù hợp với hệ thống tương tác

3.3.3.1 Phương pháp tạo kiến trúc

Có các cách phân hoạch kiến trúc sau:

• Phân hoạch ngang

• Phân hoạch dọc

Phương pháp tạo kiến trúc từ DFD

Hình 4.10 Tạo kiến trúc từ lƣợc đồ DFFD

Phân hoạch kiến trúc

Tại sao cần phân hoạch kiến trúc: nhằm tạo ra phần mềm dễ kiểm thử, dễ bảo trì, hạn chế hiệu ứng phụ khi sửa đổi, dễ mở rộng

Phân hoạch dọc:

Xác định các nhánh rẽ riêng biệt cho các chức năng chủchốt Sử dụng các module điều khiển để điều phối thông tin giữa các chức năng

Hình 4.11 Phân hoạc dọc kiến trúc

Phân hoạch ngang:

Phân tầng các module ra các mức: module điều khiển (ra quyết định) và module thao tác (workers) Module ra quyết định được xếp ở tầng cao

Hình 4.12 Phân hoạch ngang kiến trúc 3.3.3.2 Tạo kiến trúc phần mềm

Mục tiêu: Tạo ra kiến trúc được phân hoạch Tạo kiến trúc phần mềm từ các biểu đồ DFD Trong DFD có hai loại luồng dữ liệu tiêu biểu:

Luồng chuyển đổi: xử lý tập trung

Luồng giao dịch (Transaction Flow): định tuyến phân phối

Phương pháp chuyển đổi luồng chuyển đổi

Phân tích luồng chuyển đổi:

Ở giai đoạn này cần cô lập, xác định biên của các module vào/ra; xác định các module xử lý tập trung Chuyển chúng thành các module kiến trúc tương ứng Thêm các module điều khiển nếu cần thiết Vi chỉnh (refining) kiến trúc để nâng cao tính module

Luồng chuyển đổi tập trung là luồng mà có các dữ liệu đầu vào được tập trung xử lý ở một số tiến trình rồi cho kết quả đầu ra là các tiến trình thực hiện lưu trữ, truyền đi hay biểu diễn thông tin

Hình 4.13 Chuyển đổi luồng chuyển đổi Phương pháp chuyển đổi luồng giao dịch

Phân tích luồng giao dịch:

Xác định các luồng vào; Xác định các luồng thực hiện; Xác định trung tâm giao dịch (module phân phối) Biến đổi riêng rẽ từng luồng hành động Luồng giao dịch là luồng mà mỗi đầu vào được nhận dạng và chuyển cho các tiến trình

xử lý tương ứng với nó Tiến trình làm nhiệm vụ nhận dạng và chuyển dữ liệu đến nơi cần gọi là trung tâm giao dịch

Hình 4.14 Chuyển đổi luồng giao dịch

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

Phần mềm cần có giao diện thân thiện với người sử dụng Thiết kế giao diện

là một khâu trong thiết kế phần mềm Với đầu vào là tài liệu đặc tả yêu cầu Đặc trưng của thiết kế giao diện: Hướng người dùng, cần làm bản mẫu, cần được người dùng đánh giá

Vai trò, tầm quan trọng: Một khâu không thể thiếu trong thiết kế phần mềm, người dùng đánh giá phần mềm qua giao diện

Thiết kế giao diện: Cần hướng đến người dùng; Che dấu chi tiết kỹ thuật bên trong; Kết hợp 3 mặt: người dùng, chức năng, công nghệ

Giao diện là phương tiện để người dùng sử dụng hệ thống Giao diện thiết

kế nghèo nàn người dùng dễ mắc lỗi Giao diện thiết kế tồi là lý do nhiều phần mềm không được sử dụng Giao diện trợ giúp người dùng làm việc với khả năng của họ Giao diện trợ giúp tốt người dùng thành công Giao diện trợ giúp tồi, người dùng khó khăn, thất bại

Hình 4.15 Các bước thực hiện thiết kế giao diện 4.1 Nguyên tắc thiết kế giao diện:

 Cần phản ảnh vào thiết kế:

+ Kinh nghiệm, năng lực, nhu cầu của người dùng khả năng dùng bàn phím, mouse, tốc độ phản ứng, khả năng nhớ thao tác, sở thích, văn hóa, lứa tuổi:mầu sắc, ngôn ngữ, …

+ Những hạn chế về mặt vất chất và tinh thần của người dùng (trí nhớ, vụng

về, có thể mắc lỗi)

 Luôn bao gồm việc làm bản mẫu để người dùng đánh giá

 Giao diện cần có các tính chất sau đây:

+ Tính thân thiện: thuật ngữ, khái niệm, thói quen, trình tự nghiệp vụ của người dùng

+ Tính nhất quán: ví trí hiển thị, câu lệnh, thực đơn, biểu tượng, màu sắc, cùng dạng

-+ Ít gây ngạc nhiên

+ Có cơ chế phục hồi tình trạng trước lỗi

+ Cung cấp kịp thời phản hồi và trợ giúp mọi lúc, mọi nơi

+ Tiện ích tương tác đa dạng

Một số thiết bị giao diện phổ biến: Màn hình, bàn phím, mouse, bút từ, màn hình cảm biến, mic/speaker, smart cards,…một số thiết bị đang phát triển (nhận dạng tiếng nói, chữ viết)

Có các kiểu tương tác sau thông dụng: Thao tác trực tiếp, chọn thực đơn, chọn biểu tượng, điền vào mẫu biều, ngôn ngữ lệnh, ngôn ngữ tự nhiên…

Các loại giao diện gồm:

+ Giao diện dòng lệnh, đây là phương thức tương tác có sớm nhất, được

ƒthực hiện thông qua hàm chuẩn của ngôn ngữ do đó ít tốn tài nguyên hệ thống,

do đó có khả năng tổ hợp lệnh để tạo các lệnh phức tạp Với loại giao diện này chúng ta cần nhập lệnh/dữ liệu từ bàn phím Với ưu điểm là dễ cài đặt so với giao diện đồ họa (GUI) Nhưng hạn chế là thao tác thực hiện tuần tự dẫn đến khó sửa thao tác trước và không phù hợp người dùng ít kinh nghiệm

+ Giao diện đồ họa, đây là giao diện thông dụng trên máy tính PC, Apple, Unix… Với ưu điểm là dễ học, dễ sử dụng, hợp với người ít kinh nghiệm Một lúc có thể thao tác trực tiếp trên nhiều cửa sổ hay nhiều vị trí trên cửa sổ, dó đó có thể thao tác song song Người dùng có thể tương tác trực tiếp với thông tin: soạn thảo; nhập dữ liệu vào các form, nhận được tức thời kết quả thao tác Tuy vậy phải cài đặt phức tạp, tốn tài nguyên phần cứng…

4.2 Các kiểu tương tác

+ Ngôn ngữ lệnh (Command Language)

+ Thực đơn (Menu)

+ Biểu mẫu (Form-fill)

+ Biểu tượng (Icon)

+ Ngôn ngữ tự nhiên (Natural Language)

+Thao tác trực tiếp (Direct Manipulation)

Tương tác bằng ngôn ngữ lệnh có ưu điểm là đơn giản, linh hoạt, thao tác nhanh Nhưng đòi hỏi người dùng có kinh nghiệm Loại tương tác này dễ gây nhầm lẫn, cần phải nhớ cú pháp, ngữ nghĩa lệnh…

Kiểu tương tác thực đơn (menu) đó là thao tác trực tiếp trên danh sách tùy chọn Kiểu tương này có tính dễ hiểu, dễ dùng, có cấu trúc logic, hạn chế dùng bàn phím, tránh các lỗi kiểu gõ lệnh, dễ dàng tạo trợ giúp theo ngữ cảnh…

Kiểu tương tác biểu mẫu, với kiểu này người dùng cần điền thông tin vào các mục của biểu mẫu Kiểu tương tác này khá hiệu quả với việc cập nhật và biểu

diễn thông tin Một biểu mẫu tốt cần có tiêu đề rõ ràng, nhóm hợp lý các trường,

có các giá trị ngầm định, có màn hình tĩnh tại, ít thay đổi…

Kiểu tương tác biểu tượng sử dụng ký họa mang ý nghĩa trực quan Người dùng tương tác qua con trỏ, do đó chiếm ít không gian trên màn hình, tiện lợi, dễ

sử dụng, nhanh chóng hiểu được nội dung Tuy vậy cũng khó tạo các biểu tượng, nhiều khi dễ gây lúng túng, hiểu nhầm…

Kiểu tương tác ngôn ngữ nói sử dụng ngôn ngữ tự nhiên để tương tác với hệ thống, do đó có tính tiện lợi cao Nhưng rất khó thiết kế, đây là một hướng nghiên cứu thú vị của ngành trí tuệ nhân tạo

Các vẫn đề cần quan tâm khi thiết kế giao diện là: Phương pháp hiển thị thông tin; Thời gian phản hồi; Hiển thị thông báo; Tiện ích …

4.3 Phương pháp hiển thị thông tin

Hiển thị bằng văn bản thường chính xác, dễ cài đặt

Hiển thị bằng đồ họa thì có tính trực quan, dễ dàng nhận ra mối quan hệ Với thời gian phản hồi cần quan tâm đến thời gian trung bình phản hồi với các thao tác, vì người dùng không thể đợi quá lâu, vì vậy cần làm sao để chứng tỏ

hệ thống đang hoạt động Độ biến thiên thời gian phản hồi không đồng đều cũng

sẽ gây cảm giác hệ thống gặp lỗi

Khi xây dựng thông báo, đó là các phản hồi hệ thống đối với thao tác vì vậy các thông báo cần có nghĩa, dễ hiểu, hữu ích, tránh đưa ra các số hiệu, định dạng thông báo phải nhất quán

Thông báo lỗi cần chính xác, có tính hướng dẫn, xây dựng Số lượng thông báo: khi đưa ra càng nhiều càng tốt, càng thân thiện Nhưng cũng nên đưa ra một lượng tối thiểu là phù hợp Thời điểm và thứ tự đưa ra thông báo, cũng như các yêu cầu phản hồi đối với thông báo cũng nên quan tâm

Cần có nhiều tiện ích trợ giúp người sử dụng Các loại tiện ích là: trợ giúp trực tuyến và theo ngữ cảnh hay chú giải các thao tác, giao diện…Các tài liệu trực tuyến như tra cứu chức năng hệ thống Các macro nhằm tự động hóa thao tác Tính kỹ nghệ của giao diện: Giao diện là phần tử dễ thay đổi như thay đổi qui trình, phương thức thao tác, thay đổi môi trường (phần cứng, hệ điều hành),

nâng cấp (đẹp hơn, dễ sử dụng hơn) Giao diện phải dễ sửa đổi Giao diện phải có tính khả chuyển Giao diện nên độc lập với xử lý thông tin…

4.4 Một số tiêu chuẩn giao diện

 Thời gian đáp ứng của hệ thống: giá trị trung bình và độ lệch phù hợp

 Phương tiện trợ giúp người sử dụng: tích hợp và add-on

 Kiểm soát thông tin lỗi: hiển thị cả nguyên nhân lỗi và cách khắc phục

 Đặt tên nhãn: ngắn gọn và gợi nhớ

 Công cụ thiết kế giao diện nên có những tính năng sau:

 Quản lý thiết bị nhập (bàn phím, chuột)

 Hiệu chỉnh thông tin input

 Kiểm soát lỗi và hiển thị thông báo lỗi

 Cung cấp trợ giúp và hiển thị thông báo nhắc nhở

 Cung cấp feedback (ví dụ như tự động hiển thị ký tự gõ vào)

 Kiểm soát cửa sổ và vùng, khả năng cuộn

 Thiết lập giao tiếp giữa chương trình với giao diện (ví dụ: các hàm đáp ứng)

 Cách ly chương trình với các hàm quản lý giao diện

 Cho phép tuỳ biến giao diện

 Một số hướng dẫn chung:

 Nên đồng nhất (menu, lệnh, hiển thị )

 Nên cung cấp feedbackcho người dùng

 Yêu cầu xác nhận những tác vụ mang tính phá hoại (xoá file, account)

 Nên hỗ trợ UNDO, REDO

 Hạn chế lượng thông tin phải ghi nhớ giữa 2 tác vụ liên tiếp

 Tối ưu trong trình bày hộp thoại và di chuyển mouse

 Chấp nhận lỗi từ phía người sử dụng

 Cung cấp trợ giúp trực tuyến

 Dùng động từ đơn giản và ngắn gọn để đặt tên các lệnh

 Đối với thông tin hiển thị

 Chỉ hiển thị những thông tin phù hợp với ngữ cảnh hiện tại

 Dùng tên, từ viết tắt và màu gợi nhớ

 Cho phép tương tác trực quan

 Tạo thông báo lỗi có ý nghĩa

 Hiển thị dữ liệu ở nhiều dạng khác nhau trong cửa sổ

 Thiết lập biểu diễn tượng tự

 Sử dụng không gian màn hình một cách tối ưu

 Đối với thông tin input

 Hạn chế input trực tiếp (có thể chọn lựa từ một số dữ liệu có sẵn)

 Nên đồng nhất giữa thông tin input và hiển thị

 Nên cho phép tuỳ biến input

 Cấm các chức năng không thích hợp trong ngữ cảnh hiện tại

 Cho phép input ở nhiều dạng khác nhau

 Để cho người sử dụng kiểm soát dòng sự kiện tương tác

 Tự động tính các giá trị inputcho người sử dụng nếu có thể

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

Trong phần này trình bày một số vấn đề cốt lõi của thiết kế phần mềm theo

mô hình RUP Để hiểu rõ hơn, các bạn có thể đọc thêm trong các tài liệu môn Phân tích thiết kế hệ thống với UML

6.1 Giới thiệu

Trong giai đoạn này, như trên đã nói chúng ta cần trả lời câu hỏi: How? Ở giai đoạn này cần thiết lập mô hình động (dynamic modeling) và chi tiết hoá mô hình tĩnh

Giai đoạn thiết kế quan tâm đến “HOW”, đó là:

 Thứ tự các thông điệp trao đổi, thông số của thông điệp

 Thuật giải của các tác vụ đáp ứng

 Cấu trúc dữ liệu cho các thuộc tính

 Framework (console, document/view, 3-tier )

Thiết kế cũng chịu ảnh hưởng từ:

 Ngôn ngữ lập trình và thư viện lập trình (Hỗ trợ Vector, List, Map hay không? Hỗ trợ template hay không? )

 Kiến trúc hệ thống (COM, CORBA hay EJB)

Do đó cần thiết lập mô hình động (dynamic modeling) và chi tiết hoá mô hình tĩnh

Một số vấn đề của thiết kế hướng thủ tục gặp phải:

Với thiết kế hướng thủ tục thì dữ liệu là chung cho cả hệ thống, do đó mọi thủ tục thao tác trên cơ sở dữ liệu chung sẽ đặc trưng cho trạng thái toàn hệ thống Thao tác sai của một thủ tục lên dữ liệu sẽ gây sai lan truyền sang phần khác sử dụng dữ liệu này Sửa đổi một thủ tục sẽ có nguy cơ ảnh hưởng tới phần khác liên quan Thay đổi cấu trúc dữ liệu dẫn đến thay đổi tổng thể hệ thống, vì vậy dữ liệu cần tổ chức tốt Với các hệ thống lớn, phức tạp việc bảo trì sẽ rất khó khăn

Thiết kế hướng đối tượng (OOD) là một phương pháp hiện đang trở nên phổ biến Phương pháp này là một cách tiếp cận khác, nhìn nhận hệ thống theo các quan điểm:

Hệ thống là một tập các đối tượng có tương tác với nhau, mỗi đối tượng bao gói cả dữ liệu và các xử lý trên chúng Tương tác giữa các đối tượng bằng truyền thông báo Các đối tượng có thể kế thừa nhau

Phương pháp OOD có các ưu điểm sau:

Dễ bảo trì: các đối tượng được hiểu như các thực thể hoạt động độc lập

o Bao gói thông tin

o Liên kết lỏng lẻo (trao đổi bằng truyền thông báo)

Nội dung của OOD bao gồm:

o Xác định các tập đối tượng (gọi là lớp) và các đặc trưng của chúng

o Phân định vai trò và trách nhiệm của chúng trong hệ thống

o Thiết lập được sự tương tác của chúng để thực hiện chức năng của

+ Xác định liên kết giữa các lớp

2 Phân gói lại các lớp phân tích (nhằm tăng cường kiến trúc)

+ Tách các lớp dịch vụ và ứng dụng

+ Phân gói các lớp phân tích theo tầng

3 Xác định và mô tả các giao diện

+ Xác định giao diện giữa các gói

+ Xác định liên kết giữa các gói

Thiết kế hướng đối tượng bao gồm:

1 Thiết kế biểu đồ tương tác mỗi gói

+ Xác định lại các lớp

+ Xây dựng biểu đồ tương tác

2 Phát triển biểu đồ lớp thiết kế

+ Chuyển biểu đồ cộng tác sang biểu đồ lớp

+ Hoàn thiện các quan hệ công tác

3 Thiết kế các lớp

+ Thiết kế các thuộc tính

+ Thiết kế các phương thức

+ Thiết kế cơ sở dữ liệu

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

Các mô hình thiết kế sẽ bao gồm: Mô hình cấu trúc gói; Mô hình cộng tác; Mô hình lớp; Đặc tả lớp, giao diện

6.2 Khái niệm mô hình động

Lược đồ lớp chỉ mô tả khía cạnh tĩnh của hệ thống Hành vi của hệ thống được mô tả bằng mô hình động bao gồm:

Tương tác giữa các đối tượng: cộng tác hay trình tự;

Trạng thái của đối tượng/lớp;

Quá trình hoạt động của lớp/đối tượng

Tương tác giữa các đối tượng

Đối tượng tương tác với nhau (interaction) bằng cách gửi/nhận các thông điệp kích hoạt Các actor cũng có thể gửi thông điệp kích hoạt đến đối tượng Kích hoạt khiến một tác vụ thực thi, một đối tượng được tạo ra hay huỷ đi, hoặc gây ra một tín hiệu Ở đây cụ thể các thông điệp (message) là đặc tả của kích hoạt Các loại thông điệp: Đơn giản; Đồng bộ; Bất đồng bộ; Thông điệp trả về của lời gọi hàm

Thông điệp bao gồm: Tên dịch vụ được yêu cầu và thông tin dùng để thực hiện dịch vụ

Thường thì, thông điệp được cài đặt bằng lời gọi hàm, có dạng:

Các lược đồ cộng tác (collaboration diagram) sẽ được thiết lập để cụ thể hoá một use-case hoặc một tác vụ Lược đồ cộng tác là một đồ thị liên kết các vai trò Các quan hệ liên kết được dùng để kết nối các vai trò với nhau Chúng ta có thể chỉ ra tên vai trò cho các liên kết Các tương tác được thể hiện bằng gửi/nhận thông điệp Mỗi thông điệp được thể hiện bằng mũi tên (tùy theo loại thông điệp

mà nét vẽ của các mũi tên trong UML có khác đi) cộng với phần đặc tả của thông điệp Các thông điệp được đánh số theo kiểu phân cấp:

+ 3.4.2 xảy ra sau 3.4.1 và cả hai được lồng trong 3.4

+ 3.4.3a và 3.4.3b xảy ra đồng thời và được lồng trong 3.4

Cú pháp tổng quát của thông điệp:

precedessor guard-condition sequence-expression returnvalue := message-name argument-list

Ví dụ: 2/ 1.3.1: p := find(specs)

1.1, 4.2/ 3.2 *[i:=1 6]: invert(x, color)

Lược đồ cộng tác có thể được thiết lập ở một trong 2 dạng:

+ Dạng cụ thể: mỗi vai trò được biểu diễn bằng một ký hiệu của đối tượng

cụ thể, các thông điệp được trao đổi trên các đường liên kết

+ Dạng đặc tả: mô tả các lớp; các đường liên kết được ánh xạ vào các thông điệp

Việc thiết lập lược đồ cộng tác giúp cụ thể hoá (realize) các use-case và nhận diện thêm một số tác vụ của các đối tượng/lớp phân tích

Ví dụ: lược đồ cộng tác mức cụ thể cho use-case Login của hệ thống đăng

ký môn học tín chỉ qua WEB

Ví dụ: Lược đồ cộng tác mức cụ thể cho use-case Registers course của hệ thống đăng ký môn học tín chỉ qua WEB

6.3 Mô tả trình tự

Lược đồ cộng tác mô tả sự tương tác giữa các đối tượng và actor trong case theo khía cạnh không gian Để nhấn mạnh tính trình tự của các tương tác, chúng ta dùng lược đồ tuần tự (sequence diagram) Lược đồ tuần tự miêu tả các đối tượng tương tác với nhau theo thời gian sống của nó Các thông điệp được trao đổi theo trình tự thời gian Các mối liên kết không được thể hiện trong lược đồ Lược đồ tuần tự có 2 dạng:

use-+ Dạng tổng quát: thể hiện cả vòng lặp và rẽ nhánh

+ Dạng cụ thể: miêu tả một kịch bản cụ thể

Thời gian sống của mỗi đối tượng được mô tả theo một đường thẳng đứng Thông thường thời gian trôi theo chiều từ trên xuống dưới Thường thì chúng ta ít khi quan tâm đến khoảng thời gian, thường chỉ quan tâm đến trình tự mà thôi Thanh hình chữ nhật mô tả sự thực thi của một tác vụ để đáp ứng lại thông điệp gửi đến Độ dài của thanh chữ nhật phản ánh thời gian thực thi của tác vụ và tính chất lồng nhau giữa chúng Các dòng text phụ trợ (mô tả tác vụ, ràng buộc thời gian ) được viết ở lề trái

Ví dụ: Lược đồ tuần tự dạng cụ thể cho use-case Login của hệ thống đăng

ký môn học tín chỉ qua WEB

Ví dụ: Lược đồ tuần tự dạng cụ thể cho use-case Register Courses

6.4 Lƣợc đồ trạng thái

Chuẩn UML đưa ra lược đồ trạng thái để biểu diễn hành vi của một phần tử bất kỳ bằng cách chỉ ra đáp ứng của nó đối với các sự kiện bên ngoài Thông thường lược đồ trạng thái được áp dụng cho đối tượng/lớp nhằm biểu diễn hành vi của lớp

Trạng thái của mỗi đối tượng ít nhiều sẽ bị thay đổi trong suốt chu kỳ sống của đối tượng Trạng thái đơn giản là một tình trạng trong đời sống đối tượng hoặc một tương tác của đối tượng mà theo đó đối tượng thoả một điều kiện, thực hiện một công việc hoặc đợi một sự kiện nào đó Thông thường mỗi đối tượng nằm ở một trạng thái trong một khoảng thời gian nhất định nó sẽ dịch chuyển từ