Chương 4 Phân tích yêu cầu
4.5 Nguyên lí phân tích
Trên hai thập kỉ qua, người ta đã đề xuất một số phương pháp phân tích và đặc tả phần mềm. Các chuyên gia công nghệ phần mềm đã xác định được các vấn đề chính yếu và nguyên nhân dẫn đến các vấn đề đó cũng như đã đề xuất được các qui tắc và thủ tục để khắc phục. Mỗi phương pháp đều có kí pháp và quan điểm duy nhất. Tuy nhiên, tất cả các phương pháp này đều dựa trên các nguyên lí cơ bản sau đây:
Miền thông tin của vấn đề phải được biểu diễn lại và hiểu rõ.
Các mô hình mô tả thông tin, chức năng và hành vi hệ thống cần phải được xây dựng.
Các mô hình (và vấn đề) phải được phân hoạch theo cách để lộ ra các chi tiết theo kiểu phân tầng (hay cấp bậc).
Tiến trình phân tích phải đi từ thông tin bản chất hướng tới chi tiết cài đặt.
Bằng cách vận dụng các nguyên lí nêu trên, phân tích viên có thể tiếp cận tới vấn đề một cách hệ thống. Miền thông tin cần được xem xét sao cho người ta có thể hiểu rõ chức năng một cách đầy đủ. Các mô hình cần được vận dụng sao cho việc trao đổi thông tin được dễ dàng theo một cách ngắn gọn. Việc phân hoạch vấn đề cần hướng tới mục tiêu làm giảm độ phức tạp. Những cách nhìn nhận cả từ góc độ bản chất và góc độ cài đặt phần mềm đều cần thiết như nhau sao cho chúng bao hàm được các ràng buộc logic do yêu cầu xử lí đặt ra cũng như các ràng buộc vật lí do các phần tử của hệ thống áp đặt.
4.5.1 Miền thông tin
Mọi ứng dụng phần mềm đều có thể được gọi chung là xử lí dữ liệu. Điều đáng quan tâm là thuật ngữ này chứa một điều mấu chốt cho cách hiểu của chúng ta về yêu cầu phần mềm. Phần mềm được xây dựng ra để xử lí dữ liệu: để biến
đổi dữ liệu từ dạng này sang dạng khác, tức là, để nhận cái vào, thao tác nó theo cách nào đó để tạo ra cái ra. Phát biểu nền tảng này về mục tiêu là đúng, cho dù ta xây dựng phần mềm cho hệ thống trả lương hay phần mềm nhúng chạy theo thời gian thực để kiểm soát luồng nhiên liệu cho động cơ ô tô.
Tuy nhiên điều quan trọng cần phải lưu ý là phần mềm cũng xử lí cả biến cố nữa. Một biến cố biểu thị cho một khía cạnh nào đó của hệ thống và thực sự không gì khác hơn là dữ liệu kiểu logic - tức là đạt ngưỡng hoặc chưa đạt ngưỡng, hoặc là bật hoặc tắt, hoặc đúng hoặc sai, có đấy hay không có đấy.
Chẳng hạn, một cảm biến áp suất phát hiện ra rằng áp suất đã vượt quá một giá trị an toàn nào đó và gửi một tín hiệu báo động tới cho phần mềm điều phối. Tín hiệu báo động này là một sự kiện điều khiển hành vi của hệ thống. Do đó, dữ liệu (số, kí tự, hình ảnh, âm thanh v.v) và điều khiển (sự kiện) - cả hai đều nằm trong miền thông tin của vấn đề.
Miền thông tin chứa ba khung nhìn khác nhau về dữ liệu và điều khiển khi chúng được xử lí trên máy tính:
Luồng thông tin,
Nội dung thông tin, và
Cấu trúc thông tin.
Để hiểu đầy đủ miền thông tin ta phải xem xét từng khung nhìn này.
Luồng thông tin biểu thị cho phương thức dữ liệu và điều khiển thay đổi khi chúng chuyển qua hệ thống. Cái vào được biến đổi thành thông tin trung gian để rồi được biến đổi thêm nữa thành cái ra. Trên con đường biến đổi này (hay đường đi), các thông tin phụ có thể được bổ sung thêm từ một kho dữ liệu hiện có (như các file lưu trên đĩa, trong cơ sở dữ liệu, hay bộ đệm). Phép biến đổi được áp dụng cho dữ liệu chính là chức năng hay chức năng con mà chương trình phải thực hiện. Dữ liệu và điều khiển di chuyển giữa hai phép biến đổi (chức năng) sẽ xác định giao diện cho từng chức năng.
Nội dung thông tin biểu thị cho từng khoản mục dữ liệu và điều khiển có chứa một khoản mục thông tin lớn nào đó. Chẳng hạn, khoản mục dữ liệu trả lương được hợp thành từ một số mẩu thông tin quan trọng: tên người nhận lương, số tiền được trả, tổng số phải trả, khấu trừ, vân vân. Do đó nội dung của trả lương được xác định bởi các khoản mục cần để tạo ra nó. Tương tự như vậy, nội dung của khoản mục điều khiển được gọi là trạng thái hệ thống, có thể được định nghĩa bằng một xâu các bit. Từng bit biểu thị cho một khoản mục thông tin tách biệt chỉ ra rằng liệu một thiết bị đặc biệt nào đó hiện đang được kết nối trực tuyến hay gián tuyến.
dữ liệu và điều khiển khác nhau. Các khoản mục dữ liệu hay điều khiển được tổ chức theo một bảng N chiều hay cấu trúc cây cấp bậc? Bên trong nội dung của cấu trúc, thông tin nào có quan hệ với thông tin khác? Liệu tất cả các thông tin đều được chứa chỉ ở trong một cấu trúc riêng lẻ hay dùng nhiều cấu trúc phân biệt? Làm sao thông tin trong một cấu trúc này lại có liên quan với thông tin trong một cấu trúc khác? Những câu hỏi này và nhiều câu hỏi khác sẽ được giải đáp thông qua việc định giá về cấu trúc thông tin. Cũng cần phải chú ý rằng cấu trúc dữ liệu, một khái niệm có liên quan hữu cơ với công đoạn lập trình sẽ được thảo luận trong phần nói về thiết kế và cài đặt cấu trúc thông tin bằng phần mềm.
4.4.3 Mô hình hoá
Chúng ta tạo ra các mô hình để nhận biết rõ hơn về thực thể cần xây dựng.
Khi thực thể là một đối tượng vật lí (như toà nhà, máy bay, thiết bị) thì ta có thể xây dựng một mô hình giống nó về hình dạng, nhưng nhỏ hơn về qui mô. Tuy nhiên, khi thực thể cần xây dựng là phần mềm, thì mô hình của chúng ta phải mang dạng khác. Nó phải có khả năng mô hình hoá thông tin mà phần mềm biến đổi, các chức năng (và chức năng con) làm cho phép biến đổi đó thực hiện được, và thể hiện tường minh được hành vi của hệ thống khi phép biến đổi xảy ra.
Trong khi phân tích các yêu cầu phần mềm, chúng ta tạo ra các mô hình về hệ thống cần xây dựng. Các mô hình tập trung vào các chức năng hệ thống phải thực hiện mà không chú ý đến cách thức nó thực hiện. Trong nhiều trường hợp, các mô hình chúng ta tạo ra có thể dùng kí pháp đồ hoạ trực quan mô tả thông tin và các luồng thông tin vận hành trong hệ thống, thông tin được xử lí cũng như phản ánh được hành vi của hệ thống và các đặc trưng khác thông qua các biểu tượng phân biệt và dễ nhận diện. Những phần khác của mô hình có thể thuần tuý là văn bản. Thông tin mô tả có thể được cung cấp bằng cách dùng ngôn ngữ tự nhiên hay ngôn ngữ chuyên dụng cho mô tả yêu cầu.
Các mô hình được tạo ra trong quá trình phân tích yêu cầu còn đóng một số vai trò quan trọng:
Mô hình trợ giúp cho phân tích viên hiểu rõ về thông tin, chức năng và hành vi của hệ thống, do đó làm cho nhiệm vụ phân tích yêu cầu được dễ dàng và có hệ thống hơn;
Mô hình trở thành tiêu điểm cho việc khảo sát và do đó, đóng vai trò nền tảng cho việc xác định tính đầy đủ, nhất quán và chính xác của đặc tả;
Mô hình trở thành nền tảng cho thiết kế, cung cấp cho người thiết kế một cách biểu diễn chủ yếu về phần mềm có thể được “ánh xạ” vào hoàn cảnh cài đặt.
Các phương pháp phân tích được thảo luận trong các mục sau thực tế chính là các phương pháp mô hình hoá. Mặc dầu phương pháp mô hình hoá được dùng thường là sự ưa thích cá nhân (hay tổ chức), hoạt động mô hình hoá chính là nền tảng cho công việc phân tích đạt hiệu quả cao.