Bài giảng Nhập môn công nghệ phần mềm - Phần II: Tiến trình phần mềm

1Ths.Phan Phương Lan 1 NHẬP MÔN CÔNG NGHỆ PHẦN MỀM PHẦN II – TIẾN TRÌNH PHẦN MỀM Bộ môn Công nghệ phần mềm, Khoa CNTT&TT, Đại học Cần Thơ Ths.Phan Phương Lan 2 Nội dung  Phân tích và Đặc tả  Thiết kế  Lập trình  Kiểm thử  Triển khai hệ thống và Bảo trì  Tiến trình RUP Ths.Phan Phương Lan 3 TIẾN TRÌNH PHẦN MỀM PHẦN II.1 – PHÂN TÍCH & ĐẶC TẢ YÊU CẦU Ths.Phan Phương Lan 4 Nội dung  Quy trình xác định các yêu cầu  Thu thập các yêu cầu  Phân loại các yêu cầu  Các đặc trưng của yêu cầu  Các ký hiệu mô hình hóa  Các ngôn ngữ đặc tả và yêu cầu  Lập bản mẫu cho các yêu cầu  Tài liệu yêu cầu  Thẩm tra và công nhận hợp lệ 2Ths.Phan Phương Lan 5 Quy trình xác định các yêu cầu  Một yêu cầu là sự diễn đạt cách hoạt động (behaviour) mong muốn.  Một yêu cầu đề cập đến:  Các đối tượng hay thực thể  Trạng thái của đối tượng hay thực thể  Các chức năng được thực hiện để thay đổi trạng thái hay các đặc trưng của đối tượng  Các yêu cầu tập trung vào nhu cầu của khách hàng chứ không phải tập trung vào giải pháp hay sự thực hiện. Ths.Phan Phương Lan 6 Quy trình xác định các yêu cầu  Các yêu cầu là quan trọng  Các yếu tố hàng đầu làm cho dự án thất bại:  Các yêu cầu không hoàn chỉnh  Thiếu sự tham gia của người sử dụng  Các mong muốn không thực tế  Thiếu sự hỗ trợ về quản lý  Thay đổi các yêu cầu và các đặc tả  Thiếu việc lập kế hoạch  Hệ thống không được cần nữa  Một phần nào đó trong quy trình xác định các yêu cầu liên quan đến hầu hết các nguyên nhân này.  Lỗi về yêu cầu có thể gây tốn kém nếu không được phát hiện sớm. Ths.Phan Phương Lan 7 Quy trình xác định các yêu cầu  Được thực hiện bởi nhà phân tích yêu cầu hay nhà phân tích hệ thống.  Kết quả cuối cùng là tài liệu đặc tả các yêu cầu phần mềm. Ths.Phan Phương Lan 8 Thu thập các yêu cầu  Có khoảng cách thông tin giữa khách hàng và nhà phân tích.   Sự thảo luận với các thành viên tham gia vào hoạt động thu thập yêu cầu là quan trọng.  Sự thảo luận đưa đến sự đồng ý giữa các bên về các yêu cầu. 3Ths.Phan Phương Lan 9 Thu thập các yêu cầu  Các thành viên tham gia trong hoạt động thu thập yêu cầu  Clients: trả tiền cho phần mềm được phát triển.  Customers: mua phần mềm sau khi nó được phát triển.  Người dùng: sử dụng hệ thống.  Chuyên gia về lĩnh vực: biết rõ vấn đề mà phần mềm phải tin học hóa.  Nhà nghiên cứu thị trường: thực hiện các cuộc khảo sát để xác định các xu hướng tương lai và những khách hàng tiềm năng.  Luật sư và kiểm toán viên: biết rõ các yêu cầu của luật pháp, chính phủ hay sự an toàn.  Kỹ sư phần mềm và các chuyên gia công nghệ khác: đảm bảo phần mềm là khả thi về kinh tế và công nghệ. Ths.Phan Phương Lan 10 Thu thập các yêu cầu  Các cách thu thập yêu cầu  Phỏng vấn những người tham gia trong hệ thống.  Phỏng vấn những người tham gia vào hệ thống theo nhóm.  Xem lại các tài liệu có sẵn.  Quan sát hệ thống hiện hành (nếu hệ thống tồn tại).  Theo người dùng để học về nghiệp vụ của họ một cách chi tiết hơn.  Sử dụng các chiến lược xác định vấn đề như thiết kế ứng dụng chung (Joint Application Design).  Vận dụng trí tuệ tập thể (brainstorming) của người dùng hiện tại và tiềm năng để có được các yêu cầu. Ths.Phan Phương Lan 11 Thu thập các yêu cầu  Các nguồn của các yêu cầu có thể có Ths.Phan Phương Lan 12 Phân loại các yêu cầu  Phân loại các yêu cầu  Giải quyết các xung đột  Các loại tài liệu yêu cầu 4Ths.Phan Phương Lan 13 Phân loại các yêu cầu  Các yêu cầu chức năng (functional requirements) mô tả các chức năng và dịch vụ mà hệ thống phải cung cấp.  Các yêu cầu phi chức năng (non-functional requirements) mô tả một đặc trưng nào đó về chất lượng nào mà phần mềm phải có.  Các ràng buộc thiết kế như chọn nền hay các thành phần của giao diện.  Các ràng buộc quy trình như sự hạn chế về các kỹ thuật và các tài nguyên được sử dụng để xây dựng hệ thống. Ths.Phan Phương Lan 14 Phân loại các yêu cầu  Các loại yêu cầu phi chức năng Ths.Phan Phương Lan 15 Phân loại các yêu cầu  Giải quyết sự xung đột  Các thành viên khác nhau có các yêu cầu khác nhau => các yêu cầu xung đột tiềm ẩn.  Giải quyết sự xung đột bằng cách sắp thứ tự ưu tiên cho các yêu cầu.  Ba hạng mục ưu tiên:  Cần thiết: phải được đáp ứng một cách hoàn toàn.  Mong muốn: mong được đáp ứng cao nhưng không nhất thiết.  Tùy chọn: có thể được đáp ứng nhưng có thể bị loại trừ. Ths.Phan Phương Lan 16 Các đặc trưng của yêu cầu  Chính xác (Correct)  Nhất quán (Consistent)  Không mơ hồ (Unambigious)  Hoàn chỉnh (Complete)  Khả thi (Feasible)  Có liên quan (Relevant)  Có thể kiểm thử (Testable)  Có thể theo vết (Traceable) 5Ths.Phan Phương Lan 17 Các ký hiệu mô hình hóa  Việc có các ký hiệu chuẩn để mô hình hóa, lập tài liệu, giao tiếp với các quyết định là quan trọng.  Việc mô hình hóa giúp ta hiểu thấu đáo các yêu cầu (hoạt động còn mơ hồ hay chưa biết, sự xung đột giữa các kết xuất hay sự không nhất quan trong các yêu cầu).  Một số mô thức (paradigm) ký hiệu cơ bản:  Lưu đồ thực thể quan hệ (Entity Relationship Diagram - ERD)  Dò theo sự kiện (Event Traces)  Máy trạng thái (State Machines)  Lưu đồ dòng dữ liệu (Data Flow Diagram)  Hàm và quan hệ  Logic  Đặc tả đại số Ths.Phan Phương Lan 18 Mô thức ký hiệu - Lưu đồ thực thể quan hệ  Một lưu đồ ký hiệu dạng đồ thị được ưa dùng để biểu diễn các mô hình mức quan niệm  Các thành phần cốt lõi trong lưu đồ  Thực thể: được vẽ như một hình chữ nhật, biểu diễn cho tập các đối tượng trong thế giới thực mà chúng có chung các đặc điểm và cách hoạt động  Quan hệ: được vẽ như một cạnh nối hai thực thể, với hình thoi ở chính giữa cạnh xác định loại quan hệ  Thuộc tính: một diễn giải trong thực thể. Nó mô tả dữ liệu hay các đặc tính được kết hợp với thực thể Ths.Phan Phương Lan 19 Mô thức ký hiệu - Lưu đồ thực thể quan hệ  Ví dụ: sơ đồ thực thể - quan hệ của bài toán cửa quay  Lưu đồ thực thể quan hệ là phổ biến vì  Nó cung cấp một cái nhìn tổng quan về vấn đề phải được xác định.  Tính tổng quan là tương đối ổn định khi có thay đổi trong các yêu cầu.  Lưu đồ thực thể quan hệ có vẻ phù hợp để mô hình hóa vấn đề sớm trong quy trình xác định các yêu cầu. Ths.Phan Phương Lan 20 Mô thức ký hiệu - Lưu đồ thực thể quan hệ  Ví dụ: sơ đồ lớp của UML (UML Class Diagram) là một lưu đồ thực thể quan hệ phức tạp 6Ths.Phan Phương Lan 21 Mô thức ký hiệu - Lưu đồ thực thể quan hệ  Ví dụ: sơ đồ lớp của UML là lưu đồ thực thể quan hệ phức tạp  Các thuộc tính và các phương thức được kết hợp với lớp hơn là với các thể hiện của lớp.  Thuộc tính phạm vi lớp, được biểu diễn như một thuộc tính được gạch chân, là một giá trị dữ liệu mà nó được chia sẻ bởi tất cả các thể hiện của lớp.  Phương thức phạm vi lớp, được biểu diễn như một phương thức được gạch chân, là một phương thức được thực hiện bởi lớp trừu tượng hơn là bởi các thể hiện của lớp.  Liên kết (association), được biểu diễn bởi một đường nối giữa hai lớp, chỉ ra mối quan hệ giữa các thực thể của các lớp. Ths.Phan Phương Lan 22 Mô thức ký hiệu - Lưu đồ thực thể quan hệ  Ví dụ: sơ đồ lớp của UML là lưu đồ thực thể quan hệ phức tạp  Liên kết kết tập (aggregation association)  Liên kết cấu thành (composition association)  Liên kết tổng quát hóa  Ths.Phan Phương Lan 23 Mô thức ký hiệu - Dò theo sự kiện  Mô hình thực thể quan hệ không nói gì về cách mà các thực thể hành xử.  Dò theo sự kiện là sự mô tả ở dạng đồ thị của một chuỗi các sự kiện mà chúng được trao đổi giữa các thực thể của thế giới thực.  Trục tung: đường thời gian của một thực thể riêng biệt; tên của nó xuất hiện trên đỉnh của trục.  Trục hoành: một sự kiện hay sự tương tác giữa hai thực thể.  Thời gian tiến triển theo hướng từ trên xuống.  Mỗi đồ thị mô tả một đơn dò theo sự kiện, biểu diễn cho một trong một vài cách hoạt động có thể có Ths.Phan Phương Lan 24 Mô thức ký hiệu - Dò theo sự kiện  Ví dụ: sự biểu diễn đồ thị của 2 theo vết của bài toán cửa quay 7Ths.Phan Phương Lan 25 Mô thức ký hiệu - Dò theo sự kiện  Ví dụ: sơ đồ tuần tự thông điệp là ký hiệu dò theo sự kiện được cải tiến, với các phương tiện cho phép tạo ra hay hủy bỏ các thực thể, xác định các hoạt động và định thời, và tạo ra các dò theo  Đường dọc biểu diễn cho một thực thể tham gia  Thông điệp được vẽ bằng một mũi tên hướng từ thực thể gửi sang thực thể nhận.  Hoạt động được vẽ bằng hình chữ nhật được gán nhãn và được đặt trên đường thực thi của thực thể  Điều kiện là các trạng thái quan trọng trong sự tiến hóa của thực thể, được biểu diễn bằng hình sáu cạnh có gán nhãn Ths.Phan Phương Lan 26 Mô thức ký hiệu - Dò theo sự kiện  Ví dụ biểu đồ tuần tự thông điệp là dò theo sự kiện được cải tiến: biểu đồ tuần tự thông điệp cho giao dịch mượn tài liệu của thư viện Ths.Phan Phương Lan 27 Mô thức ký hiệu - Máy trạng thái  Sự mô tả ở dạng đồ thị của tất cả các cuộc đối thoại giữa hệ thống và môi trường của nó.  Nút (trạng thái) biểu diễn một tập ổn định các điều kiện mà nó tồn tại giữa các lần xuất hiện của sự kiện.  Cạnh (dịch chuyển) biểu diễn cho sự thay đổi về hành vi hay điều kiện do sự xuất hiện của một sự kiện.  Hữu ích cả cho việc xác định hành vi động và cho việc mô tả cách mà hành vi nên thay đổi để đáp ứng được lịch sử của các sự kiện mà chúng đã xuất hiện. Ths.Phan Phương Lan 28 Mô thức ký hiệu - Máy trạng thái  Đường đi: bắt đầu từ trạng thái bắt đầu của máy và đi theo các dịch chuyển từ trạng thái này sang trạng thái khác.  Máy trạng thái hữu hạn: với mỗi trạng thái hay sự kiện, có một đáp ứng duy nhất.  Ví dụ: sơ đồ trạng thái máy cho bài toán cửa quay 8Ths.Phan Phương Lan 29 Mô thức ký hiệu - Máy trạng thái  Ví dụ: sơ đồ trạng thái của UML  Mô tả hành vi động của các đối tượng trong một lớp UML.  Có một cú pháp phong phú, bao gồm sự phân cấp trạng thái, sự đồng thời và giao tiếp giữa các máy. Ths.Phan Phương Lan 30 Mô thức ký hiệu - Máy trạng thái  Ví dụ: sơ đồ trạng thái của UML cho lớp Publication Ths.Phan Phương Lan 31 Mô thức ký hiệu - Máy trạng thái  Ví dụ: mạng Petri  Ký pháp dịch chuyển trạng thái được sử dụng để mô hình hóa các hoạt động đồng thời và sự tương tác của chúng. Vòng tròn biểu diễn cho các hoạt động hay các điều kiện. Thanh ngang/ dọc biểu diễn cho các dịch chuyển. Cung nối kết một dịch chuyển với các hoạt động và điều kiện vào và ra của nó. Ths.Phan Phương Lan 32 Mô thức ký hiệu - Máy trạng thái  Ví dụ: mạng Petri cho mượn sách 9Ths.Phan Phương Lan 33 Mô thức ký hiệu - Lưu đồ dòng dữ liệu  Lược đồ thực thể quan hệ phân rã vấn đề theo các thực thể.  Dò theo sự kiện phân rã vấn đề theo kịch bản.  Máy trạng thái phân rã vấn đề theo trạng thái điều khiển.  Cả ba chỉ mô tả các hành vi mức thấp => rất khó nhìn thấy chức năng mức cao của mô hình. Ths.Phan Phương Lan 34 Mô thức ký hiệu - Lưu đồ dòng dữ liệu  Lưu đồ dòng dữ liệu mô hình hóa chức năng và dòng dữ liệu từ chức năng này sang chức năng khác.  Hình elip biểu diễn cho quy trình hay chức năng: biến đổi dữ liệu  Mũi tên biểu diễn cho dòng dữ liệu (vào hay ra của chức năng).  Hai đường song song biểu diễn cho kho dữ liệu: lưu giữ các dữ liệu.  Hình chữ nhật biểu diễn cho các tác nhân: các thực thể cung cấp dữ liệu vào và nhận kết quả kết xuất. Ths.Phan Phương Lan 35 Mô thức ký hiệu - Lưu đồ dòng dữ liệu  Lưu đồ dòng dữ liệu mức cao biểu diễn cho bài toán thư viện Ths.Phan Phương Lan 36 Mô thức ký hiệu - Lưu đồ dòng dữ liệu  Thuận lợi:  Cung cấp một mô hình trực quan về chức năng mức cao của hệ thống được đề nghị và của các phụ thuộc dữ liệu giữa các quy trình khác nhau.  Khó khăn :  Có thể làm tăng tính mơ hồ đối với nhà phát triển phần mềm, người chưa quen với vấn đề đang được mô hình hóa. 10 Ths.Phan Phương Lan 37 Mô thức ký hiệu - Lưu đồ dòng dữ liệu  Ví dụ: sơ đồ use case của UML  Các thành phần  Đường biên của hệ thống (được ký hiệu bởi hình chữ nhật)  Tác nhân (được ký hiệu bởi hình người hay >)  Trường hợp sử dụng – use case - (được ký hiệu bằng hình oval). Một use case biểu diễn một chức năng được yêu cầu nào đó và biến thể của nó  Quan hệ giữa tác nhân và use case hay giữa các use case (được biểu diễn bằng các đường hay đường nét đứt) Ths.Phan Phương Lan 38 Mô thức ký hiệu - Lưu đồ dòng dữ liệu  Ví dụ sơ đồ use case của UML: một số use case của thư viện Ths.Phan Phương Lan 39 Mô thức ký hiệu – Hàm và quan hệ  Phương thức hay cách tiếp cận hình thức: các kỹ thuật thiết kế và đặc tả dựa vào toán học.  Phương thức hình thức mô hình hóa các yêu cầu hay hoạt động phần mềm như một tập các hàm hay quan hệ toán học, chúng ánh xạ từ đầu vào của hệ thống tới đầu ra của hệ thống.  Hàm: xác định trạng thái của sự thực thi của hệ thống, và các kết xuất.  Quan hệ: được sử dụng khi 1 giá trị nhập ánh xạ tới nhiều hơn 1 giá trị xuất.  Ví dụ: bảng quyết định Ths.Phan Phương Lan 40 Mô thức ký hiệu – Logic, Đặc tả đại số  Logic  Một logic bao gồm một ngôn ngữ diễn tả các thuộc tính và một tập các quy tắc suy luận ra các thuộc tính kết quả, mới từ những thuộc tính đã có.  Ví dụ: ngôn ngữ đặc tả yêu cầu hình thức Z  Đặc tả đại số  Xác định hành vi của các phép toán bằng cách xác d9inh6 sự tương tác giữa các cặp phép toán thay vì mô hình hóa các phép toán riêng lẻ.  Khó có thể định nghĩa được tập các tiên đề mà nó là hoàn chỉnh, nhất quán và phản ánh hành vi mong muốn.  Ví dụ: SDL Data 11 Ths.Phan Phương Lan 41 Các ngôn ngữ đặc tả và yêu cầu  Ngôn ngữ mô hình hóa hợp nhất (Unified Modeling Language - UML)  Ngôn ngữ mô tả và đặc tả (Specification and Description Language – SDL) Ths.Phan Phương Lan 42 Các ngôn ngữ đặc tả và yêu cầu  UML (Unified Modeling Language)  Kết hợp nhiều sơ đồ ký hiệu.  Các sơ đồ UML được sử dụng trong suốt sự định nghĩa và đặc tả các yêu cầu.  Sơ đồ use case (Lưu đồ dòng dữ liệu mức cao)  Sơ đồ lớp (Lưu đồ thực thể quan hệ)  Sơ đồ tuần tự (Dò theo sự kiện)  Sơ đồ cộng tác (Dò theo sự kiện)  Sơ đồ trạng thái (Mô hình trạng thái máy) Ths.Phan Phương Lan 43 Các ngôn ngữ đặc tả và yêu cầu  Ngôn ngữ mô tả và đặc tả (SDL)  Xác định hành vi của các quy trình phân tán, đồng thời và thời gian thực mà chúng giao tiếp với nhau thông qua các hàng đợi thông điệp không giới hạn.  Bao gồm:  Sơ đồ hệ thống SDL (Lưu đồ dòng dữ liệu)  Sơ đồ khối SDL (Lưu đồ dòng dữ liệu)  Sơ đồ quy trình SDL (Mô hình máy trạng thái)  Kiểu dữ liệu SDL (Đặc tả đại số)  Thường được đi kèm bởi một tập sơ đồ tuần tự của thông điệp. Ths.Phan Phương Lan 44 Lập bản mẫu cho các yêu cầu  Xây dựng bản mẫu  Để thu thập các chi tiết của hệ thống được đề nghị  Để cố gắng lấy được thông tin phản hồi từ người dùng tiềm năng về:  Những khía cạnh mà họ muốn cải tiến.  Những đặc tính là không quá hữu ích.  Chức năng đang thiếu.  Giúp xác định xem vấn đề của khách hàng có giải pháp khả thi hay không.  Hỗ trợ trong việc thăm dò các chọn lựa để tối ưu hóa các yêu cầu về chất lượng. 12 Ths.Phan Phương Lan 45 Lập bản mẫu cho các yêu cầu  Các cách tiếp cận để làm bản mẫu  Cách tiếp cận được làm ra để sử dụng một lần duy nhất (throwaway prototype)  Được phát triển để nghiên cứu thêm về vấn đề hay giải pháp được đề nghị , và không bao giờ được xem là một phần của phần mềm được phân phối.  Cách tiếp cận tiến hóa (evolutionary prototype)  Được phát triển không chỉ giúp chúng ta trả lời các câu hỏi mà còn được kết hợp vào sản phẩm cuối cùng.  Bản mẫu cuối cùng phải biểu thị các yêu cầu về chất lượng của sản phẩm cuối.  Cả hai kỹ thuật này đôi khi được gọi là làm bản mẫu nhanh. Ths.Phan Phương Lan 46 Lập bản mẫu cho các yêu cầu  Sự khác nhau giữa lập bản mẫu và mô hình hóa  Lập bản mẫu Tốt khi trả lời những câu hỏi về giao diện người dùng.  Mô hình hóa Trả lời nhanh các câu hỏi về các ràng buộc theo thứ tự mà theo đó các sự kiện nên xuất hiện, về sự đồng bộ của các hoạt động. Ths.Phan Phương Lan 47 Tài liệu yêu cầu  Các loại tài liệu yêu cầu  Định nghĩa các yêu cầu: một danh sách hoàn chỉnh về những thứ mà khách hàng muốn đạt được  Mô tả các thực thể trong môi trường nơi hệ thống sẽ được cài đặt (các thực thể trong thế giới thực của khách hàng).  Mô tả các phép biến đổi hay các ràng buộc lên các thực thể đó.  Đặc tả các yêu cầu: diễn tả lại các yêu cầu như một đặc tả về cách mà hệ thống được đề nghị sẽ hoạt động  Chỉ tham khảo tới các thực thể mà hệ thống có thể truy xuất chúng qua giao diện của hệ thống (chỉ các thực thể trong thế giới thực mà chúng có trong hệ thống được đề nghị). Ths.Phan Phương Lan 48 Tài liệu yêu cầu  Định nghĩa các yêu cầu - Các bước của quy trình  Phác thảo mục đích chung và phạm vi của hệ thống, bao gồm các lợi ích liên quan, các mục tiêu và mục đích.  Mô tả nền tảng và nhân tố cơ bản ẩn sau sự đề xuất cho hệ thống mới.  Mô tả các đặc trưng cần thiết của một giải pháp có thể chấp nhận được.  Mô tả môi trường trong đó hệ thống sẽ vận hành.  Phác thảo sự mô tả về đề xuất, nếu khách hàng có một đề xuất cho giải quyết vấn đề.  Liệt kê bất cứ giả định nào về cách mà môi trường hoạt động. 13 Ths.Phan Phương Lan 49 Tài liệu yêu cầu  Đặc tả các yêu cầu - Các bước của quy trình  Mô tả chi tiết tất cả các đầu vào, đầu ra, bao gồm:  Các nguồn của đầu vào  Các đích của đầu ra  Các miền giá trị  Định dạng dữ liệu cho dữ liệu vào/ra  Các giao thức của dữ liệu  Tổ chức và định dạng của cửa sổ  Ràng buộc thời gian  Diễn đạt lại chức năng được yêu cầu dưới dạng các đầu vào/ra của giao diện.  Đưa ra tiêu chuẩn phù hợp cho từng yêu cầu về chất lượng của khách hàng. Ths.Phan Phương Lan 50 Tài liệu yêu cầu 1.Introduction to the Document 1.1 Purpose of the Product 1.2 Scope of the Product 1.3 Acronyms, Abbreviations, Definitions 1.4 References 1.5 Outline of the rest of the SRS 2.General Description of Product 2.1 Context of Product 2.2 Product Functions 2.3 User Characteristics 2.4 Constraints 2.5 Assumptions and Dependencies  Chuẩn IEEE cho đặc tả các yêu cầu phần mềm Ths.Phan Phương Lan 51 Tài liệu yêu cầu 3. Specific Requirements 3.1 External Interface Requirements 3.1.1 User Interfaces 3.1.2 Hardware Interfaces 3.1.3 Software Interfaces 3.1.4 Communications Interfaces 3.2 Functional Requirements 3.2.1 Class 1 3.2.2 Class 2 3.3 Performance Requirements 3.4 Design Constraints 3.5 Quality Requirements 3.6 Other Requirements 4. Appendices Ths.Phan Phương Lan 52 Thẩm tra và công nhận hợp lệ  Công nhận hợp lệ (xác nhận, validation) của các yêu cầu: ta kiểm tra xem định nghĩa các yêu cầu có phản ánh chính xác nhu cầu của khách hàng.  Thẩm tra (verification) các yêu cầu: ta kiểm tra xem một tài liệu được tạo ra có tuân theo tài liệu khác. Tại mức yêu cầu, ta kiểm tra xem đặc tả yêu cầu có phù hợp với định nghĩa yêu cầu. 14 Ths.Phan Phương Lan 53 Thẩm tra và công nhận hợp lệ  Các kỹ thuật công nhận hợp lệ Ths.Phan Phương Lan 54 Thẩm tra và công nhận hợp lệ  Thẩm tra  Kiểm tra xem tài liệu đặc tả các yêu cầu có tương đương với định nghĩa các yêu cầu.  Đảm bảo rằng nếu ta thực hiện một hệ thống mà nó đáp ứng sự đặc tả thì hệ thống sẽ đáp ứng các yêu cầu của khách hàng.  Đảm bảo rằng mỗi yêu cầu trong tài liệu định nghĩa là có thể theo vết trong đặc tả. Ths.Phan Phương Lan 55 Thẩm tra và công nhận hợp lệ  Các kỹ thuật thẩm tra Ths.Phan Phương Lan 56 TIẾN TRÌNH PHẦN MỀM PHẦN II.2 – THIẾT KẾ 15 Ths.Phan Phương Lan 57 Nội dung  Định nghĩa về thiết kế  Các nội dung thiết kế  Một số vấn đề trong thiết kế  Đặc trưng của thiết kế hoàn thiện  Tài liệu thiết kế Ths.Phan Phương Lan 58 Định nghĩa về thiết kế  Thiết kế là quá trình sáng tạo thực hiện việc chuyển đổi vấn đề thành giải pháp.  Sự mô tả của một giải pháp còn được biết như là thiết kế.  Đặc tả các yêu cầu định nghĩa vấn đề.  Tài liệu thiết kế xác định một giải pháp cụ thể cho vấn đề. Ths.Phan Phương Lan 59 Định nghĩa về thiết kế  Thiết kế là một quá trình tương tác gồm hai phần:  Thiết kế mức quan niệm (thiết kế hệ thống)  Thiết kế kỹ thuật Ths.Phan Phương Lan 60 Định nghĩa về thiết kế  Thiết kế mức quan niệm nói với khách hàng những cái mà hệ thống phải làm:  Dữ liệu đến từ đâu?  Điều gì sẽ xảy ra với dữ liệu trong hệ thống?  (Đối với người sử dụng) Hệ thống trông giống cái gì?  Những lựa chọn nào sẽ được cung cấp cho người dùng?  Các báo cáo và màn hình giống cái gì?  Định thời gian cho các sự kiện? 16 Ths.Phan Phương Lan 61 Định nghĩa về thiết kế  Thiết kế mức quan niệm Các đặc trưng của một thiết kế mức quan niệm hoàn thiện:  Theo ngôn ngữ mà khách hàng có thể hiểu  Không có các từ kỹ thuật  Mô tả các chức năng của hệ thống  Độc lập với sự cài đặt  Được liên kết với các yêu cầu Ths.Phan Phương Lan 62 Định nghĩa về thiết kế  Thiết kế kỹ thuật nói với lập trình viên những cái mà hệ thống phải làm như:  Các thành phần phần cứng chính và chức năng của chúng.  Sự phân cấp và các chức năng của các thành phần phần mềm.  Các cấu trúc dữ liệu và dòng dữ liệu. Ths.Phan Phương Lan 63 Định nghĩa về thiết kế  Sự khác nhau trong tài liệu thiết kế Ths.Phan Phương Lan 64 Định nghĩa về thiết kế  Thiết kế một hệ thống là xác định một tập các thành phần và các giao diện giữa các thành phần để đáp ứng tập các yêu cầu được đặc tả.  Những phương pháp tạo ra thiết kế  Phân rã theo mô đun  Phân rã hướng dữ liệu  Phân rã hướng sự kiện  Thiết kế trong ngoài  Thiết kế hướng đối tượng 17 Ths.Phan Phương Lan 65 Định nghĩa về thiết kế Các mức phân rã Sự phân rã  Mô tả dữ liệu hệ thống  Mô tả chức năng mức cao  Tạo ra sự phân cấp thông tin với các chi tiết tăng dần Ths.Phan Phương Lan 66 Định nghĩa về thiết kế Tính mô đun hóa  Mô đun hay thành phần (component): các bộ phận hợp lại của thiết kế.  Một hệ thống là có tính mô đun khi  Mỗi hoạt động của hệ thống được thực hiện bởi chỉ một thành.  Đầu vào và đầu ra của mỗi thành phần là rành mạch  Tất cả các đầu vào là cần thiết cho chức năng của nó.  Tất cả các kết xuất được tạo ra bởi một trong các hoạt động của nó. Ths.Phan Phương Lan 67 Các nội dung thiết kế  Nhà thiết kế thực hiện các công việc:  Thiết kế kiến trúc  Thiết kế dữ liệu  Thiết kế giao diện  Thiết kế thủ tục (thuật toán) Ths.Phan Phương Lan 68 Thiết kế kiến trúc  Thiết kế kiến trúc  Liên kết các thành phần của hệ thống với các khả năng đã được xác định trong đặc tả yêu cầu.  Một loại kiến trúc phần mềm liên quan tới các thành phần, các liên kết và các ràng buộc trên các thành phần kết hợp. 18 Ths.Phan Phương Lan 69 Thiết kế kiến trúc  Thiết kế kiến trúc  Các loại kiến trúc phần mềm Ths.Phan Phương Lan 70 Thiết kế kiến trúc - Ví dụ Đường dẫn và bộ lọc Phân lớp Ths.Phan Phương Lan 71 Thiết kế dữ liệu  Thiết kế dữ liệu  Các thành phần dữ liệu và bảng để tạo CSDL.  Các cấu trúc dữ liệu.  Các mức thiết kế dữ liệu  Thiết kế cấu trúc logic: các quan hệ chuẩn, các khóa, các tham chiếu, các cấu trúc thao tác dữ liệu.  Thiết kế cấu trúc vật lý: các file, các kiểu, kích thước. Ths.Phan Phương Lan 72 Thiết kế dữ liệu – Ví dụ 19 Ths.Phan Phương Lan 73 Thiết kế dữ liệu – Ví dụ Ths.Phan Phương Lan 74 Thiết kế giao diện  Thiết kế giao diện  Các form nhập liệu.  Các reports và những kết xuất mà hệ thống phải sinh ra. Ths.Phan Phương Lan 75 Thiết kế giao diện Ths.Phan Phương Lan 76 Thiết kế thủ tục  Thiết kế thủ tục (thuật toán)  Giải thích quá trình xử lý từ input đến output.  Phương pháp biểu diễn  Lưu đồ giải thuật.  Ngôn ngữ giả. 20 Ths.Phan Phương Lan 77 Thiết kế thủ tục Lưu đồ xử lý khi nhấn nút “Đăng nhập” Ths.Phan Phương Lan 78 Một số vấn đề trong thiết kế  Thiết kế cộng tác  Hầu hết các dự án làm việc cộng tác.  Các vấn đề trong thiết kế cộng tác  Ai là người phù hợp nhất để thiết kế từng bộ phận của hệ thống.  Viết tài liệu thiết kế như thế nào.  Làm thế nào để kết hợp các thành phần thiết kế thành một thiết kế hợp nhất.  Các vấn đề trong việc thực hiện thiết kế cộng tác  Sự khác nhau về kinh nghiệm cá nhân, sự hiểu biết, sở thích. Ths.Phan Phương Lan 79 Một số vấn đề trong thiết kế  Thiết kế giao diện  Các vấn đề then chốt được xem xét khi thiết kế giao diện:  Các vấn đề về văn hóa (quốc tịch, dân tộc, giới tính, nghề nghiệp, tuổi tác, vùng miền).  Sở thích của người dùng.  Một số lưu ý khi thiết kế giao diện:  Nên có sự đồng nhất giữa các giao diện (menu, lệnh, hiển thị...).  Đặt tên nhãn ngắn gọn, dễ nhớ.  Tối ưu trong trình bày hộp thoại và di chuyển chuột. Ths.Phan Phương Lan 80 Một số vấn đề trong thiết kế  Một số lưu ý khi thiết kế giao diện  Hạn chế nhập dữ liệu trực tiếp, nếu có thể, nên cho người dùng chọn lựa từ một số dữ liệu có sẵn.  Yêu cầu xác nhận những tác vụ mang tính phá hủy (xoá dữ liệu).  Chấp nhận lỗi từ phía người sử dụng.  Nên cung cấp feedback cho người dùng.  Tạo ra thông báo lỗi có ý nghĩa.  Cung cấp trợ giúp. 21 Ths.Phan Phương Lan 81 Một số vấn đề trong thiết kế  Sự đồng thời  Các vấn đề  Tính nhất quán của dữ liệu được chia sẻ giữa các thành phần mà chúng thực thi tại cùng thời điểm.  Đảm bảo rằng một hoạt động không can thiệp vào các hoạt động khác.  Các giải pháp  Sự đồng bộ: phương pháp cho phép hai hoạt động thực hiện đồng thời mà không can thiệp vào nhau.  Loại trừ lẫn nhau: một quy trình truy xuất một phần tử dữ liệu, không có quy trình nào khác ảnh hưởng tới phần tử.  Giám sát: một đối tượng trừu tượng kiểm soát sự loại trừ lẫn nhau của một quy trình cụ thể. Ths.Phan Phương Lan 82 Các đặc trưng của một thiết kế hoàn thiện  Sự độc lập của thành phần  Sự nối kết (coupling): mức độ tương tác giữa các mô đun.  Sự gắn kết (cohesion): mức độ tương tác bên trong một mô đun.  Nhận dạng và xử lý các ngoại lệ.  Ngăn chặn và chấp nhận các lỗi trong giới hạn cho phép  Chủ động  Bị động Ths.Phan Phương Lan 83 Sự nối kết  Các thành phần được nối kết cao khi có một lượng lớn các phụ thuộc.  Các thành phần được nối kết lỏng lẻo khi có một sự phụ thuộc nào đó nhưng sự kết nối lẫn nhau giữa các thành phần yếu.  Các thành phần không được nối kết khi không có các quan hệ nào cả. Ths.Phan Phương Lan 84 Sự nối kết  Ta có thể đo sự nối kết theo mức độ phụ thuộc 22 Ths.Phan Phương Lan 85 Sự nối kết  Các loại nối kết  Nối kết nội dung: một thành phần sửa dữ liệu nội bộ của một thành phần khác hay một thành phần rẽ nhánh sang một thành phần khác.  Nối kết chung: các thành phần truy xuất và làm thay đổi dữ liệu chung.  Nối kết điều khiển: một thành phần truyền các tham số để điều khiển hoạt động của một thành phần khác.  Nối kết cấu trúc dữ liệu: cấu trúc dữ liệu được sử dụng để truyền thông tin từ một thành phần này sang một thành phần khác và bản thân cấu trúc dữ liệu được truyền đi.  Nối kết dữ liệu: chỉ có dữ liệu được truyền từ một thành phần này sang một thành phần khác. Ths.Phan Phương Lan 86 Sự nối kết  Ví dụ Nối kết nội dung Nối kết chung Ths.Phan Phương Lan 87 Sự gắn kết  Một thành phần là gắn kết nếu tất cả các thành viên của thành phần được điều khiển với mục đích và cần thiết để thực hiện cùng một công việc  Một số dạng gắn kết Ths.Phan Phương Lan 88 FUNCTION D FUNCTION E Procedural Related by order of functions Logical Similar functions FUNCTION A FUNCTION A’ FUNCTION A” logic Temporal Related by time TIME T0 TIME T0 + X TIME T0 + 2X FUNCTION A FUNCTION B FUNCTION C FUNCTION A FUNCTION B FUNCTION C Communicational Access same data Sequential Output of one part is input to next DATA FUNCTION A FUNCTION B FUNCTION C Functional Sequential with complete, related functions FUNCTION A - part 1 FUNCTION A - part 2 FUNCTION A - part 3 Coincidental Parts unrelated FUNCTION A FUNCTION B FUNCTION C 23 Ths.Phan Phương Lan 89 Nhận dạng và xử lý ngoại lệ  Các ngoại lệ: những tình huống mà nó ngược lại với cái mà ta thực sự muốn hệ thống làm. Các ngoại lệ điển hình gồm:  Không thực hiện được việc cung cấp một dịch vụ.  Cung cấp dữ liệu hay dịch vụ sai.  Làm hư dữ liệu.  Các ngoại lệ có thể được xử lý theo một trong ba cách sau  Thử lại: phục hồi hệ thống về trạng thái trước đó và cố gắng thực hiện dịch vụ bằng một chiến lược khác.  Hiệu chỉnh: phục hồi hệ thống về trạng thái trước đó, hiệu chỉnh một mặt nào đó của hệ thống và cố gắng thực hiện lại bằng cùng một chiến lược.  Báo cáo: phục hồi hệ thống về trạng thái trước đó, báo cáo vấn đề với thành phần xử lý lỗi và không cung cấp dịch vụ. Ths.Phan Phương Lan 90 Ngăn chặn và chấp nhận các lỗi  Phát hiện lỗi chủ động: định kỳ kiểm tra các dấu hiệu về lỗi hoặc cố gắng giải quyết trước khi lỗi xuất hiện.  Phát hiện lỗi bị động: chờ cho đến khi lỗi xuất hiện trong suốt sự thực thi.  Hiệu chỉnh lỗi: sự đền bù của hệ thống cho sự hiện diện của lỗi.  Chấp nhận lỗi: cô lập những thiệt hại bị gây ra bởi lỗi. Ths.Phan Phương Lan 91 Viết tài liệu thiết kế  Tài liệu thiết kế gồm các mục:  Nêu lý do cơ bản của thiết kế.  Phác thảo những vấn đề then chốt và các thỏa hiệp  Mô tả về các thành phần của hệ thống.  Xác định cách mà người dùng tương tác với hệ thống.  Tập các biểu đồ và ký pháp hình thức mô tả toàn bộ tổ chức và cấu trúc của hệ thống. Ths.Phan Phương Lan 92 Viết tài liệu thiết kế  Xác định cách mà người sử dụng tương tác với hệ thống  Các menu và các định dạng màn hình hiển thị.  Giao diện người dùng: các phím chức năng, v.v.  Kết nhập: dữ liệu đến từ đâu, cách mà chúng được định dạng, chúng được lưu giữ trên phương tiện nào.  Kết xuất: dữ liệu đến từ đâu, cách mà chúng được định dạng, chúng được lưu giữ trên phương tiện nào.  Các đặc trưng chức năng chung.  Các ràng buộc về sự thực thi.  Các thủ tục lưu giữ.  Cách phương pháp xử lý lỗi.