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

Chia sẻ: Hương Hoa Cỏ Mới | Ngày: | Loại File: PDF | Số trang:110

Thêm vào BST

Báo xấu

51
lượt xem 12
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

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ủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

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

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ể. 102
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: 103
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ả. 104
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 105
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 106
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 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ể 107
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: 108
+ 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. 109
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 110
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): 10. k =1 20. gosub 100 30. if y > 120 goto 60 40. k = k+1 50. goto 20 60. print k, y 70. stop 100. Y =3*k*k+7*k-3 110. return b. Ghép nối chung: một số module 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 module nào gây ra. 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. Ví dụ: Procedure PrintRec is begin Display Name (name, 111
sex); ..... end PrintRec; Procedure DisplayName (in : name, sex) is begin if sex = m then print Mr. else print Ms print name end DisplayName; 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? 112
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 113
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. 114
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). Ví dụ: hàng, chồng, cánh cửa... 2.2.2. Tinh chế Tinh chế là quá trình làm rõ vấn đề Tinh chế và trừu tượng hoá là hai khái niệm bù trừ nhau: càng tinh chế thì càng hạ thấp mức trừu tượng hóa. 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ị”. 115
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 116
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 117
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 118
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 (sub- 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. 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 119
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. 120
Hình 4.5. Kiến trúc khách dịch vụ (Client-Server Architecture) Ưu điểm: • Sử dụng hiệu quả mạng, giảm chi phí thiết bị. • Dễ dàng mở rộng, thêm dịch vụ. Nhược điểm: • Khó tích hợp dữ liệu. • 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. 121