D) CÁC CÁCH BIỂU DIỄN CỦA MÔ HÌNH PHÂN TÍCH
A) VÍ DỤ PHÂN TÍCH HƯỚNG CẤU TRÚC
5.2.5. Mô hình trạng thái máy
Mô hình trạng thái máy mô tả hệ thống phản ứng lại các sự kiện bên trong và bên ngoài. Mô hình trạng thái máy biểu diễn các trạng thái của hệ thống và các sự kiện gây ra sự biến đổi trạng thái này chứ không chỉ ra luồng dữ liệu trong hệ thống. Kiểu mô hình này thường được sử dụng trong các hệ thống thời gian thực bởi thông thường các hệ thống này được điều khiển bởi việc mô phỏng từ môi trường của hệ thống.
Các mô hình trạng thái máy là một phần của phương pháp thiết kế thời gian thực. Trong UML có lược đồ trạng thái (StateChart) để biểu diễn mô hình này.
Mô hình trạng thái máy của một hệ thống chỉ ra rằng, tại bất kỳ thời điểm nào, hệ thống cũng có một tập hợp các trạng thái có thể. Khi một tín hiệu được nhận, nó có thể biến đổi hệ thống từ trạng thái này sang trạng thái khác. Ví dụ một hệ thống điều khiển van có thể chuyển từ trạng thái van đóng sang trạng thái van mở khi hệ thống nhận được lệnh.
Cách tiếp cận để mô hình hóa hệ thống được minh họa trong hình 5.14. Sơ đồ này chỉ ra một mô hình trạng thái máy của một lò vi sóng đơn giản có gắn các nút chọn nhiệt độ (power) và nút thiết lập thời gian bắt đầu. Lò vi sóng hiện đại thì có nhiều chức năng phức tạp hơn. Tuy nhiên, mô hình này bao gồm những chức năng cơ bản của hệ thống. Để đơn giản hóa, ta giả sử rằng các bước tuần tự để sử dụng lò vi sóng là:
1. Chọn nhiệt độ
2. Đặt thời gian
3. Ấn nút start, máy sẽ hoạt động cho đến khi thời gian kết thúc.
Vì lý do an toàn, lò vi sóng sẽ không hoạt động khi cánh cửa được mở, khi hoàn thành việc sử dụng, có một âm thanh nhắc nhở. Lò vi sóng có thể có nhiều cách hiển thị thông báo và cảnh báo khác nhau.
Một lược đồ UML được sử dụng để mô tả mô hình trạng thái máy được thiết kế theo phương pháp hướng đối tượng. Tuy nhiên, nó cũng có thể sử dụng cho tất cả các mô hình trạng thái máy. Hình chữ nhật góc tròn biểu diễn trạng thái của hệ thống, trong đó có chứa một lời mô
tả ngắn gọn về hoạt động có thể được thực hiện trong trạng thái này. Một mũi tên được gán nhãn chỉ ra tác nhân biến đổi trạng thái.
Hình 5.13. Lược đồ trạng thái của lò vi sóng
Tuy nhiên, trong hình 5.13 chúng ta có thể nhận thấy rằng hệ thống trả lời sự kiện khởi đầu khi lựa chọn nút full-power và half-power. Người sử dụng có thể thay đổi sau khi ấn các nút khác. Thời gian được thiết lập và nếu cửa sổ đóng, nút Start được kích hoạt, hệ thống sẽ hoạt động cho tới khi thời gian thiết lập hết.
Lược đồ UML để chỉ ra các hoạt động được thực hiện trong một trạng thái. Trong một đặc tả hệ thống chi tiết, bạn phải cung cấp thông tin chi tiết hơn về việc kích hoạt và các trạng thái của hệ thống, những thông tin này có thể được lưu trong một từ điển dữ liệu hoặc một bách khoa thư được lưu trữ bởi một công cụ CASE được sử dụng để tạo ra mô hình hệ thống.
Vấn đề nảy sinh với cách tiếp cận này là số lượng các trạng thái của hệ thống có thể tăng lên nhanh chóng. Đối với những mô hình hệ thống lớn, việc cấu trúc hóa các mô hình trạng thái này là cần thiết.
Một cách để thực hiện điều này là sử dụng một khái niệm bao chứa các khái niệm khác (một trạng thái có thể được chi tiết hóa trong một mô hình khác – một trạng thái có nhiều trạng thái thành phần). Ví dụ như trong hình 5.14.
CÂU HỎI ÔN TẬP
1. Hãy nêu vai trò của việc mô hình hóa hệ thống trong tiến trình phát triển phần mềm.
2. UML là gì? Vai trò của các loại biểu đồ UML trong các giai đoạn phát triển phần mềm.
3. Hãy xây dựng mô hình ngữ cảnh và mô hình trường hợp sử dụng (use-case) của hệ thống
máy rút tiền tự động ATM.
4. Xác định các lớp và xây dựng mô hình lớp của hệ thống phần mềm nhúng điều khiển hoạt động của hệ thống máy rút tiền tự động ATM.
5. Xây dựng mô hình tuần tự của chức năng chuyển tiền từ tài khoản này sang tài khoản khác trong máy rút tiền tự động ATM.
Chương 6: THIẾT KẾ PHẦN MỀM
Trong phát triển phần mềm, giai đoạn phân tích và đặc tả yêu cầu sẽ xác định những chức năng cơ bản của phần mềm và các ràng buộc đối với phần mềm cũng như tiến trình phát triển.
Nói cách khác, giai đoạn này phải trả lời câu hỏi “hệ thống cần làm gì?”. Sau khi xác định rõ mục tiêu cần thực hiện sẽ chuyển qua giai đoạn thiết kế, giai đoạn này trả lời câu hỏi “làm như thế nào” thông qua việc đưa ra các giải pháp để thực hiện những yêu cầu đã đề ra trong quá trình đặc tả.
Chương này sẽ giới thiệu về các khái niệm cơ bản trong thiết kế, vai trò và các hoạt động cơ bản trong thiết kế. Phần đầu tiên củachương đề cập đến một số chiến lược và phương pháp thiết kế. Phần tiếp theo trình bày về các vấn đề cơ bản trong thiết kế kiến trúc. Phần cuối cùng giới thiệu về một phương pháp thiết kế được sử dụng rộng rãi bên cạnh phương pháp thiết kế hướng chức năng mà sinh viên đã quen thuộc trong các môn học trước, đó là phương pháp thiết kế hướng đối tượng. Qua đó sinh viên có thể hiểu được những nguyên tắc, công việc phải thực hiện trong quá trình thiết kế phần mềm. Từ đó có khả năng ứng dụng trong các đề án thực tế.
6.1. TỔNG QUAN VỀ THIẾT KẾ PHẦN MỀM
6.1.1. Giới thiệu chung
a. Khái niệm thiết kế
“Thiết kế phần mềm là quá trình chuyển các đặc tả yêu cầu phần mềm thành một biểu diễn thiết kế của hệ thống phần mềm cần xây dựng, sao cho người lập trình có thể dựa trên cơ sở đó để xây dựng thành các chương trình vận hành được”.
Cụ thể hơn, người kỹ sư thiết kế phần mềm cần dựa vào các mô tả về các dịch vụ mà phần mềm sẽ cung cấp cũng như những ràng buộc cần tuân thủ khi hoạt động để đưa ra các giải pháp công nghệ thích hợp, sẽ vận hành trên thực tế, nhằm đáp ứng các yêu cầu đặt ra.
Mục tiêu của giai đoạn này là đưa ra một giải pháp cho vấn đề đã đặt ra trong giai đoạn đặc tả và cấu trúc hoá giải pháp này một cách rõ ràng, đầy đủ, không nhập nhằng, không có sự dư thừa. Cuối cùng sẽ mô tả phương án thiết kế trong một tài liệu thiết kế.
Để đưa ra được các giải pháp phù hợp, người thiết kế phải thực hiện các công việc sau:
- Nghiên cứu tìm hiểu vấn đề.
- Chọn một số giải pháp và xác định các đặc điểm ban đầu của chúng. Các giải pháp này cần khả thi và có hiệu quả cao đối với hệ thống.
b. Vai trò của thiết kế
Trong phát triển phần mềm, nếu bỏ qua giai đoạn thiết kế thì nguy cơ sinh ra một hệ thống không tin cậy, khả năng thất bại cao. Đặc biệt khi phần mềm là một sản phẩm vô hình và rất phức tạp, rất khó xác định chất lượng trước khi kiểm thử và vận hành hệ thống. Thiết kế là một khâu then chốt quyết định chất lượngsản phầm. Về cơ bản, hoạt động thiết kế có vai trò:
- Thiết kế là cách duy nhất để 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 mô hình hệ thống phần mềm, làm cơ sở cho việc triển khai chương trình phần mềm.
- Tài liệu thiết kế là cơ sở để giao tiếp giữa các nhóm cùng tham gia vào việc phát triển sản phẩm. Giúp quản lý rủi ro và lập kế hoạch phát triển phần mềm một cách hiệu quả.
- Một tài liệu thiết kế bao gồm một tập hợp các mô hình cấu trúc hoá, đồng nhất và hoàn thiện, các mô hình này có thể được hiển thị theo nhiều cách khác nhau (bằng các ngôn ngữ hình thức hoặc phi hình thức). Do đó, nó có thể là tài liệu tham khảo quan trọng trong các bước tiếp theo của tiến trình phát triển phần mềm như: giai đoạn phát triển, giai đoạn kiểm thử, giai đoạn bảo trì.
c. Một số khái niệm cơ bản trong thiết kế
Mặc dầu có nhiều phương pháp thiết kế phần mềm nhưng trong quá trình thiết kế chúng ta
đều sử dụng một số khái niệm làm nền tảng. Chúng được gọi là nền tảng thiết kế.
Trừu tượng hóa (abstraction)
Khái niệm trừu tượng hóa là sự cho phép tập trung vào vấn đề ở mức tổng quát nào đó, không xét tới các chi tiết mức thấp hơn không liên quan. Trừu tượng hoá cho phép ta làm việc với khái niệm và thuật ngữ quen thuộc trong môi trường vấn đề mà không phải biến đổi chúng thành một cấu trúc không quen thuộc.
Khi xét vấn đề cho việc tìm ra giải pháp module hóa, chúng ta có thể đặt ra nhiều mức độ trừu tượng. Tại mức trừu tượng cao nhất: phát biểu bằng ngôn ngữ môi trường của vấn đề. Tại mức trừu tượng thấp hơn, thường lấy khuynh hướng thủ tục; tại mức thấp nhất, giải pháp được phát biểu theo cách có thể cài đặt trực tiếp. Trong mỗi bước của tiến trình đều là sự làm mịn cho một mức trừu tượng của giải pháp.
Phân rã (decomposition)
Phân rã là việc phân chia một đối tượng thành những đối tượng nhỏ hơn. Đây là một cách để có thể dễ dàng nghiên cứu các đối tượng con đơn giản hơn của nó.
Làm mịn (Refinement)
Làm mịn là chiến lược thiết kế trên xuống. Kiến trúc của một chương trình được phát triển bằng cách làm mịn liên tiếp các thủ tục. Trong mỗi bước, một hay nhiều lệnh của chương trình đã cho được phân rã thành những lệnh chi tiết hơn. Việc phân rã hay làm mịn liên tiếp các đặc tả này kết thúc khi tất cả các lệnh đã được diễn đạt bằngbất kỳ ngôn ngữ lập trình hay ngôn ngữ máy tính nền tảng nào. Khi các nhiệm vụ đã được làm mịn thì dữ liệu cũng phải được làm mịn, được phân rã hay cấu trúc lại.
Cần chú ý là mọi bước làm mịn đều kéo theo những quyết định thiết kế nào đó. Người lập trình cần nhận biết các tiêu chuẩn nền tảng cho quyết định thiết kế và sự tồn tại của các giải pháp khác.
Tính module
Phần mềm được chia thành các phần có tên riêng biệt và định địa chỉ được, gọi là các module. Các module được tích hợp với nhau để giải quyết yêu cầu của vấn đề đặt ra. Khái niệm này có ý nghĩa rất quan trọng trong quá trình thiết kế: đây là một thuộc tính riêng của phần mềm, nó cho phép tổ chức một chương trình trở nên quản lý được theo một cách thông minh.
Nếu một vấn đề x có thể phân thành hai vấn đề x1, x2 nhỏ hơn để giải quyết thì thực nghiệm đã chứng minh được rằng:
C(x1+ x2) > C(x1) + C(x2) và E(x1 + x2) > E(x1) + E(x2)
Trong đó C(x) là hàm xác định độ phức tạp cảm nhận được của vấn đề x, và E(x) là hàm xác định nỗ lực cần có để giải quyết vấn đề x. Như vậy, khi chia nhỏ một vấn đề thì việc giải quyết nó trở nên dễ hơn và công sức bỏ ra để giải quyết cũng ít hơn.
Thủ tục phần mềm (software procedure)
Thủ tục phần mềm tập trung vào việc mô tả chi tiết các bước xử lý cho từng module riêng
biệt. Thủ tục phải cung cấp một đặc tả chính xác về một quá trình xử lý, có đầu vào, đầu ra, trình
tự các sự kiện, các điểm quyết định rẽ nhánh điều khiển, các thao tác lặp lại, có thể bao gồm cả cấu trúc/tổ chức của dữ liệu đã được sử dụng.
Che dấu thông tin (information hiding)
Che dấu thông tin là khái niệm các module nên được đặc trưng bởi nhữngquyết định thiết kế mà ẩn kín với mọi module khác, thông tin chứa trong module này không thể thâm nhập tới được từ các module khác không cần đến những thông tin đó. Che dấu thông tin kéo theo việc xác định một tập module độc lập mà trao đổi giữa các module chỉ là các thông tin thật sự cần thiết cho việc vận hành phần mềm.
Che dấu thông tin là một tiêu chuẩn thiết kế đối với hệ thống module vì những lợi ích mà nó mang lại. Khi có sai sót xảy ra, sự thay đổi sẽ ít có khả năng lan truyền sang những vị trí khác
bên trong phần mềm.
6.1.2. Thiết kế phần mềm
Tiến trình thiết kế phần mềm có thể xem xét từ những góc độ khác nhau: nội dung công việc, trình tự thực hiện, phương pháp thiết kế và công cụ sử dụng.
Hình 6.1. Mô hình tiến trình thiết kế
Sau mỗi hoạt động thiết kế, nhóm thiết kế cần đưa ra một bản đặc tả thiết kế. Bản đặc tả này có thể là một đặc tả trìu tượng, nửa hình thức, hình thức hay 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. Thực chất quá trình thiết kế là việc bổ sung dần các chi tiết vào đặc tả thiết kế. Kết quả cuối cùng là các đặc tả về các thuật toán, cấu trúc dữ liệu và đặc tả giao diện được dùng làm cơ sở cho việc mã hóa.
Phương pháp tiếp cận hệ thống thường được sử dụng là phương pháp tiếp cận từ trên xuống: vấn đề được phân chia một cách đệ quy thành các vấn đề con cho tới khi các vấn đề nhận được có thể giải quyết một cách dễ dàng. Ngược lại, khi thiết kế người ta lại thường thực hiện từ dưới lên, vì các vấn đề ở mức thấp nhất là đủ nhỏ, đủ thông tin cần thiết để người thiết kế có thể dễ dàng tìm ra giải pháp công nghệ thích hợp và cũng dễ nhận ra thành phần nào có thể dùng lại được trong phần khác hay chương trình khác.
Quá trình này được lặp lại cho đến khi các thành phần hợp thànhcủa mỗi hệ con được xác định để có thể ánh xạ trực tiếp vào các thành phần khác (ví dụ như các gói, các thủ tục và các hàm) biểu diễn bằng một ngôn ngữ lập trình nào đó.
b. Các hoạt động và sản phẩm thiết kế
Đối với việc phát triển các hệ thống phần mềm lớn, hoạt động thiết kế được tiến hành theo các bước sau:
- Thiết kế kiến trúc: Xác định các hệ thống con tạo nên hệ thống và mối liên hệ giữa
chúng.
- Đặc tả trìu tượng: Đối với mỗi hệ thống con, mô tả trìu tượng các dịch vụ mà nó cung cấp và các ràng buộc mà nó phải tuân thủ khi cung cấp dịch vụ.
- Thiết kế các giao diện thành phần: Thiết kế giao diện của từng hệ con khi chúng giao tiếp với hệ con khác, các hệ thống khác trong cùng môi trường hoạt động của hệ thống sao cho các hệ con có thể thực thi các dịch vụ trong các hệ con khác mà không cần biết quá trình thực hiện được diễn ra như thế nào.
- Thiết kế cấu trúc dữ liệu: thiết kế và đặc tả cấu trúc dữ liệu được dùng khi phát triển hệ thống.
- Thiết kế giao diện người dùng: Thiết kế các giao diện người dùng để người sử dụng có thể tương tác với hệ thống.
- Thiết kế thành phần: Phân chia các dịch vụ mà các hệ thống con cung cấp vào các thành phần của nó.
- Thiết kế thủ tục: Đặc tả các thuật toán, quy trình thực hiện các dịch vụ của mỗi thành phần sao cho có thể ánh xạ trực tiếp vào ngôn ngữ lập trình.
Phác thảo thiết kế phi
hình thức
Thiết kế phi
Hình 6.2. Các hoạt động thiết kế và sản phẩm của chúng