Giáo trình Nhập môn công nghệ phần mềm (Phần 2)

125 trang ngocly 90

Download

Bạn đang xem 20 trang mẫu của tài liệu "Giáo trình Nhập môn công nghệ phần mềm (Phần 2)", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên

Tài liệu đính kèm:

giao_trinh_nhap_mon_cong_nghe_phan_mem_phan_2.pdf

Nội dung text: Giáo trình Nhập môn công nghệ phần mềm (Phần 2)

Chương 6. Pha xác định yêu cầu CHƯƠNG 6: PHA XÁC ĐỊNH YÊU CẦU 6.1 XÁC ĐỊNH YÊU CẦU CỦA KHÁCH HÀNG Hiểu sai o Chúng ta phải xác định những gì khách hàng muốn “Tôi biết bạn tin rằng bạn đã hiểu những gì bạn nghĩ là tôi đã nói, nhưng tôi không chắc bạn nhận ra rằng những gì bạn nghe không phải là điều mà tôi muốn nói!” (“I know you believe you understood what you think I said, but I am not sure you realize that what you heard is not what I meant!”) Chúng ta phải xác định những gì khách hàng cần Rất khó để người phân tích một hệ thống để hình dung ra một sản phẩm phần mềm và các chức năng của nó o Vấn đề này khó hỏi khách hàng Một người phân tích hệ thốngPTIT có kinh nghiệm cần làm rõ những thông tin thích hợp cho khách hàng Khách hàng là nguồn duy nhất của thông tin này Giải pháp: o Thu thập những thông tin ban đầu từ khách hàng o Sử dụng những thông tin ban đầu giống như đầu vào của quy trình hợp nhất o Theo sát các bước của quy trình hợp nhất để xác định các nhu cầu thực của khách hàng 6.2 TỔNG QUAN VỀ LUỒNG CÔNG VIỆC XÁC ĐỊNH YÊU CẦU Mục đích của luồng công việc xác định yêu cầu Để trả lời câu hỏi: 60
Chương 6: Pha xác định yêu cầu o Sản phẩm phần mềm phải có khả năng làm được những gì? Nội dung về luồng công việc xác định yêu cầu Đầu tiên, hiểu được lĩnh vực ứng dụng o Môi trường cụ thể mà sản phẩm phần mềm đích hoạt động Thứ hai, xây dựng một mô hình nghiệp vụ o Mô hình các tiến trình nghiệp vụ của khách hàng Thứ ba, sử dụng mô hình nghiệp vụ để xác định các yêu cầu khách hàng Lặp lại các bước trên Các định nghĩa Tìm ra các yêu cầu của khách hàng o Thu thập các yêu cầu o Các phương thức bao gồm phỏng vấn và điều tra Làm mịn và mở rộng những yêu cầu ban đầu o Phân tích yêu cầu 6.2.1 Hiểu lĩnh vực ứng dụng Mỗi thành viên của đội phát triển phải trở nên quen thuộc với lĩnh vực ứng dụng o Thuật ngữ chính xácPTIT là cần thiết Xây dựng thuật ngữ o Một danh sách các từ kỹ thuật được sử dụng trong lĩnh vực ứng dụng và ý nghĩa của nó 6.2.2 Mô hình nghiệp vụ Một mô hình nghiệp vụ là sự miêu tả các tiến trình nghiệp vụ của một tổ chức Mô hình nghiệp vụ đưa ra cách hiểu về toàn bộ nghiệp vụ của khách hàng o Tri thức này là cần thiết để đưa ra lời khuyên cho khách hàng về mặt tính toán Các nhà phân tích hệ thống cần thu thập một cách hiểu chi tiết về các loại tiến trình nghiệp vụ khác nhau. o Các kỹ thuật khác nhau được sử dung, ban đầu là phỏng vấn 61
Chương 6: Pha xác định yêu cầu 6.2.2.1 Phỏng vấn Đội xác định yêu cầu cần gặp gỡ khách hàng và người dùng để thu thập được những thông tin liên quan Có hai loại câu hỏi: o Câu hỏi kết thúc đóng (Close-ended question)syêu cầu một câu trả lời cụ thể o Câu hỏi kết thúc mở (Open-ended questions) khuyến khích người được phỏng vấn nói thẳng ý kiến của mình Có hai kiểu phỏng vấn o Trong cuộc phỏng vấn có cấu trúc, các câu hỏi đã được lập kế hoạch cụ thể từ trước và thường là những câu hỏi kết thúc đóng o Trong cuộc phỏng vấn không cấu trúc, các câu hỏi được đưa ra để phản ứng lại những câu trả lời đã nhận được, thường xuyên là câu hỏi với kết thúc mở Việc phỏng vấn là không dễ dàng o Một cuộc phỏng vấn mà không có cấu trúc sẽ không sinh ra thông tin liên quan o Người phỏng vấn phải quen thuộc với lĩnh vực ứng dụng o Người phỏng vấn phải sẵn sàng tiếp thu cái mới ở mọi lúc (The interviewer must remain open-minded at all times) Sau khi phỏng vấn, người phỏngPTIT vấn phải chuẩn bị một bài tường trình đã được viết ra o Nên đưa một bản sao của bản tường trình cho người được phỏng vấn 6.2.2.2 Các kỹ thuật khác Phỏng vấn là kỹ thuật chính Một bản thăm dò ý kiến rất hữu ích khi lấy ý kiến của hàng trăm người. Kiểm tra các định dạng nghiệp vụ mà chỉ ra cách khách hàng thực hiện những công việc nghiệp vụ (Examination of business forms shows how the client currently does business ) Quan sát trực tiếp những người công nhân thực hiện những nhiệm vụ của họ có thể là một cách rất hữu ích o Máy quay là một phiên bản hiện đại của kỹ thuật này o Nhưng, cần rất nhiều thời gian để phân tích các băng video 62
Chương 6: Pha xác định yêu cầu o Những người công nhân có thể xem máy quay vì sự xâm phạm tùy tiện đời sống riêng tư 6.2.3 Các use case Một use case mô hình tương tác giữa sản phẩm phần mềm với người dùng sản phẩm phần mềm đó (tác nhân - actors) Ví dụ: Hình 6.1: Biểu diễn một use case Một tác nhân là một thành viên của thế giới bên ngoài sản phẩm phần mềm Thường rất dễ dàng nhận dạng ra tác nhân o Một tác nhân thường là một người dùng của hệ thống sản phẩm phần mềm Nhìn chung, một tác nhân đóng vai trò đối với hệ thống sản phẩm phần mềm. Vai trò này gồm: o Là một người dùng; hoặc o Là một khởi đầu; hoặcPTIT o Là một người nào đó đóng vài trò quan trọng trong use case Một người dùng của hệ thống có thể giữ nhiều hơn một vai trò Ví dụ: Một người khách hàng (Customer) của ngân hàng có thể là o Một người vay tiền hoặc o Một người cho mượn Ngược lại, một tác nhân có thể tham gia vào nhiều use case Ví dụ: một người vay tiền (Borrower)có thể là một tác nhân trong o Use case Borrow Money ; o Use case Pay Interest on Loan 63
Chương 6: Pha xác định yêu cầu o Use case Repay Loan Principal Tác nhân người vay tiền (Borrower)có thể đại diện cho hàng nghìn khách hàng của ngân hàng Một tác nhân không cần thiết phải là một con người Ví dụ: hệ thống thông tin thương mại điện tử phải tương tác với hệ thống thông tin công ty thẻ tín dụng o Hệ thống thông tin công tin thẻ tín dụng là một tác nhân từ quan điểm của hệ thống thương mại điện tử o Hệ thống thương mại điện tử là một tác nhân của hệ thống thông tin công ty thẻ tín dụng Vấn đề dễ xảy ra khi xác định các tác nhân o Nạp chồng tác nhân Ví dụ: Hệ thống phần mềm bệnh viện o Một use case có tác nhân Y tá (Nurse) o Một use case khác có tác nhân Nhân viên Y khoa ( Medical Staff) o Tốt hơn: . Các tác nhân::PTIT Bác Sỹ và Y tá (Physician and Nurse) Về mặt giải pháp: o Tác nhân Nhân viên Y khoa (Medical Staff ) với hai sự chuyên môn hóa: Bác sỹ và Y tá (Physician and Nurse) Hình 6.2: Quan hệ giữa các tác nhân 64
Chương 6: Pha xác định yêu cầu 6.2.4 Các yêu cầu ban đầu Những yêu cầu ban đầu dựa trên mô hình nghiệp vụ đầu tiên Sau đó chúng được làm mịn Các yêu cầu là động – có sự thay đổi thường xuyên o Duy trì một danh sách những yêu cầu quan trọng, cùng với các use case của các yêu cầu đã được phê chuẩn bởi khác hàng Có hai loại yêu cầu Yêu cầu chức năng chỉ rõ hành động mà sản phẩm phần mềm phải có khả năng thực hiện o Thường được biểu diễn về mặt các đầu vào và đầu ra Các yêu phi chức năng chỉ rõ những đặc trưng của hệ thống sản phẩm phần mềm, như o Những ràng buộc về môi trường o Thời gian đáp ứng o Tính đáng tin Những yêu cầu chức năng được xử lý như là một phần của luồng công việc xác định yêu cầu và phân tích Một số yêu cầu phi chức năng phải phải chờ đến tận đến luồng công việc thiết kế o Thông tin chi tiết choPTIT những yêuc hầu phi chức năng không có sẵn cho đến tận khi luồng công việc phân tích và xác định yêu cầu hoàn thành 6.3 PHA XÁC ĐỊNH YÊU CẦU CỔ ĐIỂN Không phải thực hiện pha xác định yêu cầu cổ điển trong “xác định yêu cầu hướng đối tượng” o Luồng công việc xác định yêu cầu không phải làm gì khi sản phẩm phần mềm được xây dựng Tuy nhiên, phương pháp này được biểu diễn trong chương này là o Hướng mô hình và do đó o Hướng đối tượng Phương pháp cổ điển để xác định yêu cầu 65
Chương 6: Pha xác định yêu cầu o Làm rõ các yêu cầu o Phân tích yêu cầu o Xây dựng bản mẫu nhanh o Khách hàng và người dùng trong tương lai thử nghiệm với bản mẫu nhanh 6.4 BẢN MẪU NHANH Xây dựng nhanh (“rapid”) o Sự hoàn thiện có thể được bỏ qua Chỉ đưa ra những chức năng chính Nhấn mạnh chỉ những gì mà khách hàng xem o Kiểm tra lỗi, cập nhật tệp có thể được bỏ qua Mục đích: o Để cung cấp tới khách hàng cách hiểu của sản phẩm phần mềm Bản mẫu nhanh được xây dựng để thay đổi o Ngôn ngữ cho bản mẫu nhanh bao gồm 4GLs và ngôn ngữ đã được thông dịch 6.5 NHÂN TỐ CON NGƯỜI Khách hàng và những người dùng có ý định sử dụng hệ thống phải tương tác với giao diện người dùng PTIT Giao diện máy tính – con người (Human-computer interface HCI) o Bảng chọn, không dòng lệnh (Menu, not command line) o “Trỏ và nhấp”(“Point and click” ) o Cửa sổ, biểu tượng, bảng chọn kéo xuống (Windows, icons, pull-down menus) Nhân tố con người phải được xem xét o Tránh bảng đơn dài dòng o Cho phép mức thay đổi mức độ thành thạo của giao diện o Tính đồng đều của hình thức là quan trọng ( Uniformity of appearance is important) 66
Chương 6: Pha xác định yêu cầu o Tâm lý tiến bộ so với cảm giác chung (Advanced psychology vs. common sense?) Bản mẫu nhanh của giao diện người máy của õỗi sản phẩm phần mềm là bắt buộc 6.6 SỬ DỤNG LẠI BẢN MẪU NHANH Việc sử dụng lại bản mẫu nhanh là về bản chất là mô hình xây và sửa Những thay đổi được đưa ra để xây dựng phần mềm o Đắt (Expensive) Bảo trì khó vì không có tài liệu đặc tả và tài liệu thiết kế Những ràng buộc về thời gian thực khó đáp ứng Một cách để đảm bảo rằng bảng mẫu nhanh được bỏ qua o Cài đặt bản mẫu nhanh bằng một ngôn ngữ khác so với ngôn ngữ đã lựa chọn cho sản phẩm đích(Implement it in a different language from that of the target product) Mã được sinh ra có thể được sử dụng lại Chúng ta có thể giữ lại một cách an toàn (các phần của bản mẫu nhanh ) bản mẫu nhanh nếu o Điều này được chuẩn bị trước o Những phần của bản mẫu nhanh đã qua kiểm tra kỹ lưỡng của nhóm SQA o Tuy nhiên, đây khôngPTIT phải là một bản mẫu nhanh cổ điển ( “classical” rapid prototyping) 6.7 CÁC CÔNG CỤ CASE CHO XÁC ĐỊNH YÊU CẦU Chúng ta cần các công cụ đồ họa cho các biểu đồ UML o Dễ dàng để thay đổi các biểu đồ UML o Tài liệu được lưu trong các công cụ và luôn có sẵn Các công cụ như vậy đôi khi rất khó sử dụng The diagrams may need considerable “tweaking” Nhìn chung, điểm mạnh có nhiều ảnh hưởng tốt hơn điểm yếu (Overall, the strengths outweigh the weaknesses) Các môi trường CASE đồ họa được mở rộng để trợ giúp UML 67
Chương 6: Pha xác định yêu cầu o System Architect o Software through Pictures Các môi trường CASE hướng đối tượng bao gồm o IBM Rational Rose o Together o ArgoUML (open source) 6.8 CÁC THƯỚC ĐO CHO XÁC ĐỊNH YÊU CẦU Volatility and speed of convergence are measures of how rapidly the client’s needs are determined Số lượng thay đổi được đưa ra trong suốt chuỗi con các pha Những thay đổi được đề xướng bởi những người phát triển o Quá nhiều thay đổi có thể đồng nghĩa với việc quy trình không hoàn thiện o Nhữung thay đổi được đề xướng bởi khách hàng o Thay đổi san phẩm phần mềm cuối cùng 6.9 NHỮNG THỬ THÁCH CHO PHA XÁC ĐỊNH YÊU CẦU Nhân viên của tổ chức khách hàng thường cảm giác bị đe dọa bởi máy tính Những thành viên đội xác địnhPTIT yêu cầu phải có khả năng thương lượng o Yêu cầu của khách hàng có thể phải thu hẹp phạm vi Nhân viên chính của tổ chức khách hàng không thể có thời gian cho những cuộc thảo luận cốt yếu và sâu sắc Linh hoạt và khách quan là cốt yếu 6.10 CASE STUDY CHO PHA XÁC ĐỊNH YÊU CẦU 6.10.1 Bài toán Khách hàng đến dặt hàng chúng ta xây dựng một phần mềm quản lí khách sạn với yêu cầu như sau (đây có thể coi như là một bản mô tả yêu cầu của khách hàng bằng ngôn ngữ tự nhiên): 68
Chương 6: Pha xác định yêu cầu Phần mềm dạng ứng dụng cho máy tính cá nhân, chỉ có nhân viên lễ tân, nhân viên bán hàng, quản lí khách sạn được sử dụng Nhân viên lễ tân có thể tìm phòng trống theo yêu cầu trực tiếp của khách, checkin cho khách đã đặt phòng hoặc đặt phòng trực tiếp, checkout cho khách và in hóa đơn thanh toán cho khách Nhân viên bán hàng có thể tìm phòng trống và đặt phòng theo yêu cầu của khách. Quản lí có thể : thêm/sửa/xóa thông tin phòng, xem các báo cáo doanh thu theo thời gian/theo phòng/theo loại phòng, xem báo cáo tỉ lệ phòng trống theo thời gian/theo phòng/theo loại phòng, xem báo cáo khách hàng đặt nhiều theo thời gian/theo nguồn gốc khách hàng. Thông tin về khách sạn bao gồm : tên, địa chỉ, số sao, mô tả (bao gồm mô tả bằng text và bằng hình ảnh). Trong khách sạn có nhiều phòng, mỗi phòng được mô tả bằng các thông tin : tên phòng (duy nhất, để phân biệt các phòng), loại phòng, giá niêm yết, các loại dịch vụ đi kèm, mô tả phòng. Mỗi khách hàng, khi đến ở hoặc đặt phòng, sẽ được lưu các thông tin bao gồm số CMND (số passport nếu là người nước ngoài), loại giấy tùy thân (CMND, passport), họ tên đầy đủ, địa chỉ, số điện thoại, ghi chú về phục vụ đặc biệt như cho người khuyết tật, ăn chay Mỗi phòng có thể được đặt/ở bởi nhiều khách hàng khác nhau tại những thời điểm khác nhau. PTIT Mỗi khách hàng có thể đặt/ở nhiều phòng khác nhau tại những thời điểm khác nhau. Tại một thời điểm, chỉ có một khách ở trong một phòng, và xác định một giá phòng cụ thể. Khách hàng chỉ có thể đặt phòng nếu phòng đó còn trống trong suốt thời gian khách hàng muốn đặt. Khách hàng có thể thanh toán nhiều lần cho đến ngày trả phòng. Mỗi lần thanh toán, lễ tân sẽ in hóa đơn cho lần thanh toán đó bao gồm các thông tin : họ tên và địa chỉ khách hàng, số phòng, ngày đến, ngày đi, giá phòng, các dịch vụ đi kèm (mỗi dịch vụ bao gồm tên dịch vụ, đơn vị tính, đơn giá, tổng tiền), số tiền thanh toán. Khách hàng có thể hủy đặt phòng (miên phí) nếu hủy trước ngày đến. Nếu khách hàng hủy sau ngày đặt thì khách hàng bị lưu vào danh sách đen và có thể bị từ chối đặt phòng trong các lần tiếp theo. 69
Chương 6: Pha xác định yêu cầu 6.10.2 Xây dựng sơ đồ use case tổng quan Mục đích của bước này là xây dựng một bản mô tả yêu cầu của khách hàng bằng ngôn ngữ kỹ thuật (UML). Xác định các actor có thể có của hệ thống: Actor là người dùng trực tiếp: người quản lí khách sạn (manager), nhân viên bán hàng (saller), nhân viên lễ tân kiêm luôn thủ quỹ để nhận thanh toán (receptionist) Actor là người dùng gián tiếp: Khách hàng (client), mặc dù không trực tiếp sử dụng và thao tác trên phần mềm, nhưng một số chức năng phải có mặt khách hàng mới thực hiện được như: đặt chỗ, checkin, checkout, thanh toán. Các chức năng liên quan đến các actor: Người quản lí khách sạn (Manager): quản lí thông tin phòng và khách sạn (room manage), tạo và xem các loại báo cáo (create report) Nhân viên bán hàng (Saller): giao dịch với khách hàng (Client) qua điện thoại để đặt chỗ (Book a room) hoặc hủy đặt chỗ (Cancel a booking) Nhân viên tiếp tân (Receptionist): giao dịch trực tiếp với khách hàng (Client) tại quầy để đặt chỗ (Book a room), hủy đặt chỗ (Cancel a booking), nhận Checkin, Checkout và thanh toán cho khách hàng. Khách hàng (Client): có thểPTIT đặt phòng/hủy phòng (Book a room/Cancel a Booking) trực tiếp tại quầy với nhân viên lễ tân hoặc đặt/hủy qua điện thoại với nhân viên bán hàng. Checkin, Checkout và thanh toán tại quầy với nhân viên lễ tân. Như vậy nhóm dự án thu được sơ đồ use case tổng quan như sau: 70
Chương 6: Pha xác định yêu cầu PTIT Hình 6.3: Sơ đồ use case tổng quan của hệ thống 6.10.3 Mô tả các use case Mục đích của bước này là mô tả chi tiết các use case đã xác định được trong sơ đồ tổng quan. a. Use case Room manage Hình 6.4: Use case room manage 71
Chương 6: Pha xác định yêu cầu Mô tả: Use case này cho phép người quản lí (Manager) quản lí các thông tin về phòng khách sạn như thêm, sửa, xóa b. Use case Create report Hình 6.5: Use case tạo báo báo Mô tả: Use case này cho phép người quản lí (Manager) tạo và xem cáo báo cáo thống kê theo một khoảng thời gian nhất định (tuần, tháng) theo các tiêu chí khác nhau (doanh thu, tỉ lệ phòng trống, ) c. Use case Book a room PTIT Hình 6.6: Use case đặt phòng Mô tả: Use case này cho phép Khách hàng có thể đặt phòng. Có hai cách đặt phòng: đặt gián tiếp thông qua điện thoại với Nhân viên bán hàng (Saller, tương ứng với use case Book via phone), hoặc đặt trực tiếp tại quầy thông qua Nhân viên lễ tân (Receptionist, tương ứng với use case Book on site). Để thực hiện được use case này, phải thực hiện use case Tìm phòng trống. d. Use case Cancel a Booking 72
Chương 6: Pha xác định yêu cầu Hình 6.7: Use case hủy đặt phòng Mô tả: Use case này cho phép Khách hàng có thể hủy đặt phòng. Có hai cách hủy đặt phòng: hủy gián tiếp thông qua điện thoại với Nhân viên bán hàng (Saller, tương ứng với use case Cancel via phone), hoặc hủy trực tiếp tại quầy thông qua Nhân viên lễ tân (Receptionist, tương ứng với use case Cancel on site). e. Use case Checkin HìnhPTIT 6.8: Use case nhận phòng Mô tả: Use case này cho phép Nhân viên lễ tân (Receptionist) cập nhật trạng thái một khách hàng (Client) thành đã nhận phòng khi khách hàng đến nhận phòng. f. Use case Checkout 73
Chương 6: Pha xác định yêu cầu Hình 6.9: Use case trả phòng Mô tả: Use case này cho phép Nhân viên lễ tân (Receptionist) cập nhật trạng thái một khách hàng (Client) thành đã trả phòng khi khách hàng trả phòng. Use case này cũng đồng thời thực hiện việc thanh toán và in hóa đơn cho khách hàng. g. Use case Payment PTIT Hình 6.10: Use case thanh toán tiền phòng Mô tả: Use case này cho phép Nhân viên lễ tân (Receptionist) thực hiện thanh toán và in hóa đơn cho khách hàng, khi khách hàng có thanh toán trước hoặc khi khách hàng trả phòng. 74
Chương 7. Các phương pháp phân tích truyền thống CHƯƠNG 7: CÁC PHƯƠNG PHÁP PHÂN TÍCH TRUYỀN THỐNG 7.1 YÊU CẦU TÀI LIỆU ĐẶC TẢ Pha phân tích/đặc tả Kết quả của pha đặc tả thể hiện ở tài liệu. Tài liệu đặc tả là hợp đồng giữa khách hàng và người phát triển. Yêu cầu của tài liệu đặc tả: - Phía khách hàng: rõ ràng và dễ hiểu nên tài liệu phải có mức độ hình thức vừa đủ để khách hàngcó thể hiểu được. - Phía người phát triển: đầy đủ và chi tiết vì nó là nguồn thông tin để sử dụng trng phác thảo thiết kế. Vì vậy, tài liệu đặc tả phải phản ánh đúng yêu cầu khách hàng và là bản hợp đồng giữa khách hàng và nhóm phát triển nên không thẻ thiết sót, mâu thuẫn và nhập nhằng. Tài liệu đặc tả Tài liệu đặc tả là hợp đồng giữa khách hàng và người phát triển. Nó mô tả rõ ràng điều gì sản phẩm cần phải làm và ràng buộc đối với sản phẩm. Các ràng buộc: - Giá thành và thời gian - Chạy song song: chạy được cùng với phần mềm khách trong môi trường hiện thời - Tính khả chuyển: sảnphẩm phải chạy được trên phần cứng khác có cùng hệ điều hành hay chạy được cho nhiều hệ điều hành khác nhau. - Tính tin cậy được: ví dụ, nếu sản phẩm sử dụng để theo dõi nạn nhân thì nó phải chạy trong 24h/ngày. - Đáp ứng nhanh: 95%PTIT câu hỏi phải trả lời trong vòng 0,25 giây. Đối với hệ thời gian thực phải là 100% (thật vô ích nếu 95% trường hợp phần mềm thông báo kịp thời <0,25 giây, cho phi công rằng tên lửa đang đến). Các quy tắc chấp nhận: - Khách hàng và người phát triển cần đưa ra các trường hợp kiểm thử. - Nếu sản phẩm qua được kiểm thử và sản phẩm thực sử thỏa mãn đặc tả và nhóm đã hòan thành công việc. - Ví dụ trường hợp kiểm thử: Dựa trên ràng buộc và khách hàng cung cấp dạng dữ liệu cần xử lý. Khi nhóm phát triển hiểu đầy đủ vấn đề thì sẽ tiến hành xây dựng chiến lược giải quyết. Chiến lược giải quyết là cách tiếp cận chung khi xây dựng sản phẩm Ví dụ: Sử dụng cơ sở dữ liệu online/sử dụng các tệp truyền thông Các bước xây dựng chiến lược: 1. Tìm các chiến lược: Không quan tâm về ràng buộc trong tài liệu đặc tả 75
Chương 7: Các phương pháp phân tích truyền thống 2. Đánh giá và sửa đổi từng chiến lược: so với ràng buocọ của khách hàng (một kỹ thuật là dùng bản mẫu) 3. Xác định một hay vài chiến lược thỏa mãn ràng buộc. Lưu giữ các chiến lược loại bỏ. 4. Chọn chiến lược khả thi: Khách hàgn đưa ra quy tắc lựa chọn và nhóm phát triển đề xuất chiến lược chọn. 7.2 CÁC PHƯƠNG PHÁP ĐẶC TẢ Các phương pháp đặc tả được xếp thành 3 loại: Phi hình thức, nửa hình thức, hình thức. Đặc tả bằng ngôn ngữ tự nhiên là phi hình thức Các phương pháp nửa hình thức: - Kỹ thuật đặc tả của Gane và Sarse - Mô hình quan hệ thực thể - Kỹ thuật của Demarco, Yourdon, Các phương pháp hình thức - Máy hữu hạn trạng thái - Đặc tả Z (dựa trên logic toán, lý thuyết tập hợp) - Mạng Petri 7.2.1 Đặc tả phi hình thức Xét ví dụ trong một tài liệu đặc tả: “If sales for current month are below target sales, then report is to be printed, unless difference between target sales and actual sales is less than half of difference between target sales and actual sales in previous month, or if difference between target sales and actual sales for the current month is under 5%” Ý nghĩa của đặc tả phi hình thức:PTIT 1. Chỉ tiêu doanh thu vào thánh Một là $ 100.000, doanh thu thực sử chỉ là $ 64.000 (kém 36%). Báo cáo được in ra. 2. Chỉ tiêu doanh thu tháng Hai là $120.000, doanh thu thực sự là $100,000 (kém 16,7%). Như vậy, khác biệt % của tháng Hai nhỏ hơn nửa của khác biệt % tháng trước. Không in báo cáo và quản lý tin rằng có cải tiến. 3. Tháng ba chỉ tiêu là $100,000 nhưng doanh thu thực sự là $98,000, chỉ 2% dưới đích (<5%) nên không in báo cáo. Vấn đề là gì? Đặc tả chỉ nói sự khác biệt giữa chỉ tiêu doanh thu và doanh thu thực sự mà không nói sự khác biệt %. Phán đoán cuối cùng nói là tỷ lệ %? Tài liệu trên không rõ ràng, không thể hiện ý muốn của khách hàng. Ngôn ngữ tự nhiên không phải là phương tiện tốt để viết tài liệu đặc tả. Tuy nhiên nhiều tổ chức vẫn sử dụng ngôn ngữ tự nhiên đặc biệt đối với các sản phẩm thương mại. Lý do: 76
Chương 7: Các phương pháp phân tích truyền thống - Các chuyên gia phần mềm chưa được đào tạo cẩn thận. - Quản lý bị áp lực bởi khách hàng - Quản lý không sẵn lòng đầu tư vào đào tạo 7.2.2 Phân tích hướng cấu trúc Sử dụng biểu đồ để đặc tả phần mềm là một kỹ thuật quan trọng trong những năm 1970. Ba kỹ thuật biểu đồ quen thuộc: DeMarco (1978), Gane và Sarsen (1979) , Yourdon và Constantine (1979). Ba kỹ thuật đều tốt và tương đương như nhau. Trước đây nhiều công ty phần mềm ở Mỹ sử dụng chúng trong các sản phẩm thương mại. Các tiếp cận của Gane và Sarse hiện thời được sử dụng rộng rãi để thiết kế hướng đối tượng trong công nghiệp. Ví dụ: Cửa hàng phần mềm Beta mua phần mềm từ các nhà cung cấp khác nhau và bán cho dân chúng. Cửa hàng có phần mềm thông thường nhưng muốn có phần mềm khác thì phải yêu cầu. Cửa hàng bán lẻ ra hàng tháng 300 sản phẩm với giá trung bình $250. Mặc dù thương vụ thành công nhưng nhiều người khuyên Beta nên tin học hóa. Câu hỏi: Nên tin học hóa lĩnh vực nào? Thu/chi hay bán trên mạng? Hiểm họa tiềm tang của nhiều cách tiếp cận thông thường “trước hết đưa ra giải pháp và sau đó xem xét vấn đề nảy sinh”. Phương pháp của Gane và Sarsen được sử dụng để phân tích yêu cầu của khách hàng theo kỹ thuật 9 bước Kỹ thuật 9 bước: 1. Xây dựng DFD và mịn hóa từng bước 2. Quyết định cái gì cần tin học hóa và như thế nào 3. Xác định chi tiết dòngPTIT dữ liệu 4. Xác định logic của tiến trình 5. Xác định các kho dữ liệu //nội dung và định dạng 6. Xác định các nguồn vật lý 7. Xác định các đặc tả Input và Output 8. Xác định kích cỡ 9. Xác định yêu cầu phần cứng Bước 1: Xây dựng Sơ đồ dòng dữ liệu: Sơ đồ dòng dữ liệu DFD chỉ ra logic của dòng dữ liệu tức là điều gì xảy ra. DFD sử dụng 4 ký hiệu cơ bản như hình sau: 77
Chương 7: Các phương pháp phân tích truyền thống DFD biểu diễn bừng hình vẽ mọi khía cạnh logic của dòng dữ liệu. Hình trên là minh hóa lần thứ nhất. Điều chủ yếu là DFD biểu diễn dòng thông tin, gói hàng nào khách hàng cần không phải quan trọng. PTIT 78
Chương 8. Phương pháp phân tích hướng đối tượng CHƯƠNG 8: PHƯƠNG PHÁP PHÂN TÍCH HƯỚNG ĐỐI TƯỢNG 8.1 LUỒNG CÔNG VIỆC PHÂN TÍCH Mục đích: có 2 mục đích chính Để hiểu sâu hơn về các yêu cầu Mô tả các yêu cầu theo một cách thức nhất định để tạo điều kiện thuận lợi cho việc thiết kế và cài đặt sau đó có khả năng bảo trì được. Ba kiểu lớp chính: Các lớp thực thể: mô hình thông tin lưu trữ lâu dài, chẳng hạn như: lớp account và lớp investment. Ký hiệu UML của lớp thực thể: Lớp thực thể Các lớp biên: mô hình những tương tác giữa hệ thống phần mềm với môi trường. Lớp biên nhìn chung gắn liền với đầu vào hoặc đầu ra hoặc giao tiếp với các tác nhân. Ví dụ: lớp Investments Report và lớp Mortgages Report. Ký hiệu UML của lớp biên: Lớp biên Các lớp điều khiển: mô hình những tính toán và những thuật toán phức tạp. Ví dụ: lớp Estimate Funds for Week. Ký hiệu UML của lớp điều khiển:PTIT Lớ p điều khiển 8.2 VIỆC TRÍCH RÚT CÁC LỚP THỰC THỂ Thực hiện theo ba bước sau một cách lặp và tăng dần: Việc mô hình hóa chức năng (hay còn gọi là mô hình hóa Use-Case): Xác định các kết quả khác nhau được đưa ra bởi hệ thống phần mềm. Biều diễn các thông tin đó dưới dạng các kịch bản của tất cả các Use-Case (mỗi kịch bản là một thể hiện của Use Case). Mô hình hóa lớp: Xác định các lớp thực thể và các thuộc tính của các lớp. Sau đó, xác định các mối quan hệ qua lại và các tương tác giữa các lớp. Biểu diễn thông tin này bằng biểu đồ lớp. 79
Chương 8: Phương pháp phân tích hướng đối tượng Mô hình hóa động: Xác định các hành động được thực hiện bởi hoặc đối với mỗi lớp thực thể hoặc các lớp con. Biểu diễn thông tin này dưới dạng các biều đồ trạng thái. Trong thực tế, ba bước trên không được thực hiện một cách tuần tự. Khi nào có một sự thay đổi ở một biểu đồ thì tương ứng sẽ có sự sửa đổi ở hai biểu đồ kia. Do đó, ba bước của phân tích hướng đối tượng được thực hiện song song một cách có hiệu quả. 8.3 PHÂN TÍCH HƯỚNG ĐỐI TƯỢNG CHO BÀI TOÁN THANG MÁY Một hệ thống được cài đặt để điều khiển n thang máy trong một tòa nhà với m tầng. Việc di chuyển thang máy giữa các tầng phải tuân theo những ràng buộc sau: Một là, mỗi thang máy có m nút, mỗi nút tương ứng với một tầng. Các nút này sáng lên khi được bấm và khi đó thang máy sẽ di chuyển tới tầng tương ứng mới số ghi trên nút. Và khi thang máy tới tầng đó thì nút đó sẽ hết sáng và trở lại bình thường. Hai là, ngoại trừ tầng đầu tiên và tầng trên cùng, các tầng khác đều có hai nút, một nút để yêu cầu thang máy đi lên và một nút yêu cầu thang máy đi xuống. Những nút này sẽ sáng lên khi được bấm. Và nút đó trở lại bình thường khi thang máy tới tầng tương ứng, sau đó thang máy sẽ di chuyển theo hướng được yêu cầu sau đó. Ba là, nếu thang máy không nhận được yêu cầu đi lên hoặc đi xuống, thì nó vẫn ở nguyên tầng đó và đóng cửa. 8.4 MÔ HÌNH HÓA CHỨC NĂNG Một Use-Case miêu tả về những chức năng mà hệ thống phần mềm xây dựng. Một Use-Case đưa ra một miêu tả chung về chức năng toàn thể. Còn các kịch bản là những thể hiện cụ thể của các Use-Case. Các kịch bản cần được xem xét cẩn thận để có một cái nhìn toàn diện đối với hệ thống đích được xây dựng. Use-Case miêu tả tương tác giữa hệ thống và các tác nhân (những người dùng bên ngoài). Đối với bài toán thang máy, chỉ có hai Use-Case là : Ấn nút ở thang máy và Ấn nút ở mỗi tầng. Sử dụng UML để biểu diễn Use-Case cho bài toán thang máy như hình 8.1 PTIT Hình 8.1 Các use case của bài toán thang máy Những tương tác có thể giữa người dùng và các lớp đó là: một người dùng nhấn nút tháng máy và ra lệnh cho thang máy di chuyển tới một tầng nào đó hoặc một người dùng nhấn nút để yêu cầu thang máy dừng lại ở một tầng cụ thể. Với mỗi một chức năng nói chung ta có thể đưa ra 80
Chương 8: Phương pháp phân tích hướng đối tượng một số lượng lớn các kịch bản khác nhau, mỗi một kịch bản biểu diễn một tập các tương tác . Hình 8.2 mô tả kịch bản chuẩn, nó bao gồm một tập các tương tác giữa người dùng và các thang máy tương ứng với cách mà thang máy được sử dụng. Hình 8.2 được xây dựng sau khi đã quan sát tỉ mỉ những tương tác giữa người dùng với thang máy (chính xác hơn là với các nút của thang máy và các nút của các tầng). 15 sự kiện đã được đánh số miêu tả chi tiết gồm: hai tương tác giữa người dùng A và các nút của hệ thống thang máy (sự kiện 1 và sự kiện 7) và các thao tác của thang máy (sự kiện 2 đến 6 và 8 đến 15). Hai sự kiện người dùng A bước vào thang máy và người dùng A ra khỏi thang máy không được đánh số sự kiện. Những mục như vậy được xem như là những bình luận thêm, người dùng A không tương tác với các thành phần của hệ thống thang máy khi đã bước vào thang máy hoặc rời khỏi thang máy. 1. Người dùng A nhấn nút đi lên của tầng ba để yêu cầu thang máy và người dùng A muốn đi lên tầng 7. 2. Nút đi lên của tầng ba sáng lên. 3. Thang máy đến tầng 3. Trong thang máy đang có người dùng B, người dùng B đã vào thang máy từ tâng 1 và yêu cầu lên tầng 9. 4. Nút đi lên của tầng 3 trở lại trạng thái bình thường. 5. Cửa thang máy mở ra. 6. Máy bấm giờ bắt đầu. Người dùng A bước vào thang máy. 7. Người dùng A nhấn nút 7 của thang máy . 8. Nút 7 của thang máy sáng lên. 9. Cửa thang máy đóng lại sau một thời gian vượt quá thời gian quy định của máy bấm giờ. 10. Thang máy lên tới tầng 7. 11. Nút 7 của thang máy trở lại trạng thái bình thường. 12. Cửa thang máy mở và cho phép người dùng A ra khỏi thang máy. 13. Máy bấm giờ bắt đầu. Người dùng A bước ra khỏi thang máy. 14. Cửa thang máy đóng lại sau một thời gian quy định. 15. Thang máy đi tiếp tục lên tầng 9 theo yêu cầu trước đó của người B. PTIT Hình 8.2 Kịch b ản chu ẩn cho bài toán thang máy Trái lại, hình 8.3 là một kịch bản ngoại lệ. Nó miêu tả những gì xảy ra khi người dùng nhất nút đi lên ở tầng 3 nhưng thực sự muốn đi xuống tầng 1. Kịch bản này được xây dựng bởi việc quan sát các hành động của nhiều người trong thang máy. 81
Chương 8: Phương pháp phân tích hướng đối tượng 1. Người dùng A nhấn nút đi lên của tầng ba để yêu cầu thang máy và người dùng A muốn đi xuống tầng 1. 2. Nút đi lên của tầng ba sáng lên. 3. Thang máy đến tầng 3. Trong thang máy đang có người dùng B, người dùng B đã vào thang máy từ tâng 1 và yêu cầu lên tầng 9. 4. Nút đi lên của tầng 3 trở lại trạng thái bình thường. 5. Cửa thang máy mở ra. 6. Máy bấm giờ bắt đầu. Người dùng A bước vào thang máy. 7. Người dùng A nhấn nút 1 của thang máy . 8. Nút 1 của thang máy sáng lên. 9. Cửa thang máy đóng lại sau một thời gian vượt quá thời gian quy định của máy bấm giờ. 10. Thang máy lên tới tầng 9. 11. Nút 9 của thang máy trở lại trạng thái bình thường. 12. Cửa thang máy mở và cho phép người dùng B ra khỏi thang máy. 13. Máy bấm giờ bắt đầu. Người dùng B bước ra khỏi thang máy. 14. Cửa thang máy đóng lại sau một thời gian quy định. 15. Thang máy đi tiếp tục xuống tầng 1 theo yêu cầu của người dùng A. Hình 8.3: K ịch bả n ngoại lệ của bài toán thang máy 8.5 MÔ HÌNH HÓA LỚP THỰC THỂ Trong bước này, các lớp và các thuộc tính được trích rút và được biểu diễn bằng biểu đồ UML. Các thuộc tính của mỗi lớp thực thể được xác định ở bước này nhưng các phương thức thì không. Các phươn thức sẽ được gánPTIT cho các lớp ở pha thiết kế hướng đối tượng. Có 3 cách thức để trích rút các lớp và các thuộc tính: Một là, suy luận ra các lớp từ các Use-Case và các kịch bản của các Use-Case. Phương pháp này có nhược điểm là thường có nhiều kịch bản do đó có quá nhiều lớp ứng cử để tìm ra lớp thực thể. Hai là, sử dụng CRC Cards (nếu chúng ta có tri thức về miền nghiệp vụ). Ba là, sử dụng phương pháp trích rút danh từ. 8.5.1 Trích rút danh từ Đối với những người phát triển mà chưa có kiến thức chuyên môn thành thạo về nghiệp vụ của hệ thống xây dựng thì cách tốt nhất để trích rút ra các lớp ứng cử là sử dụng phương pháp trích rút danh từ với 2 giai đoạn như sau: Giai đoạn 1: Định nghĩa vấn đề một cách ngắn gọn: Miêu tả hệ thống phần mềm xây dựng một cách ngắn gọn, súc tích dưới dạng một đoạn văn duy nhất. Trong bài toán thang máy ta có đoạn văn như sau: “ Các nút trong thang máy và ở mỗi tầng điều khiển sự di chuyển của n thang máy trong tòa nhà m tầng. Các nút sáng lên khi có người bấm nút đó để yêu cầu thang máy di chuyển tới một tầng nào đó; nút đó sẽ trở lại trạng thái bình thường khi yêu cầu đã được 82
Chương 8: Phương pháp phân tích hướng đối tượng đáp ứng. Khi thang máy không nhận được yêu cầu nào thì nó vẫn ở tầng hiện tại và cửa vẫn đóng.” Giai đoạn 2: Xác định các danh từ: Xác định các danh từ theo chiến lược không hình thức. Trong bài toán thang máy có: “Các nút trong thang máy và ở mỗi tầng điều khiển sự di chuyển của n thang máy trong tòa nhà m tầng . Các nút sáng lên khi có người bấm nút đó để yêu cầu thang máy di chuyển tới một tầng nào đó; nút đó sẽ trở lại trạng thái bình thường khi yêu cầu đã được đáp ứng. Khi thang máy không nhận được yêu cầu nào thì nó vẫn ở tầng hiện tại và cửa vẫn đóng”. Sử dụng các danh từ trên như là các lớp ứng cử. Ta có các danh từ: Nút, thang máy, tầng , sự di chuyển, tòa nhà, yêu cầu, cửa. Trong đó, các danh từ: tầng, tòa nhà, cửa nằm bên ngoài biên của bài toán nên bị loại trừ. Còn danh từ sự di chuyển là danh từ trừu tượng nên bị loại trừ (chúng có thể trở thành các thuộc tính). Do đó, các lớp ứng cử là: thang máy và lớp nút và các lớp con: lớp nút thang máy và lớp nút tầng. Biểu đồ lớp kết quả được biểu diễn bằng UML như hình 8.4 PTIT Hình 8.4 Bước lặp thứ nhất của biểu đồ lớp Vấn đề xảy ra ở đây là trong thực tế các nút của thang máy không giao tiếp trực tiếp với thang máy. Khi đó thường yêu cầu có một vài loại điều khiển thang máy, và quyết định thang máy nào sẽ đáp ứng yêu cầu cụ thể. Tuy nhiên, trong phát biểu bài toán không đề cập đến lớp điều khiển, vì thế không có lớp điều khiển trong suốt quá trình trích rút danh từ. Mặt khác, kỹ thuật trích danh từ mà chúng ta sử dụng ở đây để tìm ra các lớp ứng cử được xem như điểm khởi đầu nhưng cũng không nên dựa hoàn toàn vào đó. Chúng ta cần thêm lớp điều khiển thang máy vào biểu đồ lớp hình 8.4. Đồng thời cũng thêm mối quan hệ 1-n giữa lớp điều khiển thang máy và lớp thang máy. Yếu tố này sẽ tạo điều kiện cho việc thiết kế và cài đặt dễ dàng hơn 83
Chương 8: Phương pháp phân tích hướng đối tượng Hình 8.5 Bước lặp thứ hai của biểu đồ lớp 8.5.2 CRC Cards Trong nhiều năm về trước, CRC (Class-responsibility-collaboration) Card được sử dụng trong suốt pha phân tích [Wirfs-Brock, Wilkerson và Wiener, 1990]. Đối với mỗi lớp, đội phát triển phầm mềm điền vào thẻ biểuPTIT diễn tên của lớp (name of Class), các chức năng của lớp (Responsibility) và danh sách các lớp khác có liên quan đến lớp đó để cùng nhau thực hiện các chức năng của lớp đó (Collaboration). Hiện nay, CRC card được thực hiện một cách tự động bằng cách sử dụng thành phần công cụ CASE. Điểm mạnh của CRC card là khi CRC card được thực hiện bởi các thành viên trong đội thì tương tác qua lại giữa các thành viên trong đội dễ dàng phát hiện ra những thiếu sót hoặc những mục không đúng trong CRC card. Điểm yếu của CRC card là nếu chúng ta sử dụng CRC card để nhận dạng các lớp thực thể, thì yêu cầu có sự thành thạo về chuyên môn nghiệp vụ. 8.6 MÔ HÌNH HÓA ĐỘNG Mục đích của việc mô hình hóa động là đưa ra biểu đồ tuần tự. Biểu đồ tuần tự mô tả hệ thống phần mềm cuối cùng gần giống với máy hữu hạn trạng thái đối với mỗi lớp. Hình 8.6 biểu diễn biểu đồ trạng thái của lớp Elevator Contronller Khi biểu diễn biểu đồ trạng thái bằng UML gồm các 3 phần chính trạng thái, sự kiện và vị từ được phân bố trên toàn biểu đồ trang thái. Ví dụ trạng thái Chuyển sang trạng thái chờ trong hình 8.6 được bắt đầu nếu trạng thái hiện tại là Vòng lặp sự kiện thang máy và vị từ [Thang máy đã dừng, không có yêu cầu nào chưa quyết định] là đúng. Khi trạng thái Chuyển sang trạng thái chờ đã bắt đầu thì hành động Đóng cửa thang máy sau một khoảng thời gian cố định được thực hiện. 84
Chương 8: Phương pháp phân tích hướng đối tượng PTIT Hình 8.6 Biểu diễn biểu đồ trạng thái của lớp Elevator Controller Để thấy sự tương đương giữa biểu đồ trạng thái trong hình 8.6 và STD của hình 11.14 và 11.16, phải xem xét trong các loại kịch bản khác nhau. Chẳng hạn, xem xét phần đầu tiên của kịch bản của hình 8.2. Đầu tiên, người dùng A nhấn nút đi lên ở tầng 3. Nếu nút ở tầng ba không sáng lên thì sau đó phải xử lý như hình 11.15 và trạng thái Xử lý yêu cầu của hình 8.6 xử lý tình huốn nút được bật sáng lên. Trong trường hợp của biểu đồ trạng thái thì trạng thái tiếp theo sẽ là Vòng lặp sự kiện thang máy. Sau đó, thang máy tiến gần lại tầng 3. Trước tiên ta xem xét cách tiếp cận STD, trong hình 11.16, thang máy bắt đầu với trạng thái S(U, 3) có nghĩa là đi lên và dừng ở tầng 3 (giả định đơn giản hóa ở đây là chỉ có duy nhất một thang máy nên đối số e trong hình 11.16 được bỏ ở đây.) Từ hình 11.15, khi mà thang máy đến tầng 3 thì nút đi lên ở tầng 3 bị 85
Chương 8: Phương pháp phân tích hướng đối tượng tắt. (Theo hình 11.16) hiện thời cửa thang máy đóng và thang máy bắt đầu di chuyển lên tầng 4. Quay trở lại hình 8.6 chúng ta xem xét chuyện gì sẽ xảy ra khi mà thang máy lên tới gần tầng 3. Bởi vì thang máy di chuyển nên trạng thái tiếp theo sẽ là Xác định yêu cầu thang máy dừng lại. Các yêu cầu được kiểm tra và bởi vì, người dùng A đã yêu cầu thang máy dừng ở đó, nên trạng thái tiếp theo là Dừng thang máy tại một tầng. Thang máy dừng ở tầng 3 và cửa thang máy mở. Nút thang máy ở tầng 3 không được nhấn nên trạng thái tiếp theo là Vòng lặp sự kiện thang máy. Người dùng A bước vào và nhấn nút thang máy lên tầng 7. Do đó, trạng thái tiếp theo lại là Xử lý yêu cầu, tiếp đó là trạng thái Vòng lặp sự kiện thang máy. Thang máy dừng lại và hai yêu cầu đang bị treo, vì thế trạng thái tiếp theo là Đóng cửa thang máy cửa đóng lại sau khoảng thời gian cố định. Nút ở tầng 3 được nhấn ở tầng 3 bời người dùng A, vì thế trạng thái tiếp theo là Nút ở tầng trở lại trạng thái bình thường và nút đi lên ở tầng 3 trở về trạng thái bình thường. Trạng thái tiếp theo là Xử lý yêu cầu tiếp theo và thang máy bắt đầu di chuyển lên tầng 4. Rõ ràng những thành phần liên quan của biểu đồ tương ứng là tương đương với kịch bản này. Trong thực tế, biểu đồ trạng thái được xây dựng từ việc mô hình hóa các sự kiện của kịch bản cụ thể. Chẳng hạn, xem xét sự kiện đầu tiên của kịch bản trong hình 8.2, người dùng A nhấn nút đi lên ở tầng ba. Sự kiện này được tổng quan hóa thành là một nút bất kỳ được nhấn. Có hai khả năng có thể xảy ra hoặc là nút sẵn sàng bật sáng (trong trường hợp không có gì xảy ra ) hoặc là nút không được bật sáng (trong trường hợp hành động phải nắm bắt được để xử lý yêu cầu của người dùng). Để mô hình sự kiện này, trạng thái Vòng lặp sự kiện thang máy được đưa ra trong hình 8.6. Trường hợp nút sẵn sàng phát sáng được mô hình bởi vòng lặp không làm gì với vị từ [nút đã ấn, nút sáng] ở góc trái phía trên của hình 8.6. Trong trường hợp khác, nút không phát sáng, được mô hình bởi mũi tên được gán nhán là vị từ [nút đã ấn, nút không sáng] dẫn tới trạng thái Xử lý yêu cầu. Từ sự kiện 2 của kịch bản rõ ràng hành động Bật nút là cần thiết trong mỗi trạng thái Xử lý yêu cầu. Hơn nữa, mục đích của hành động của người dùng là việc nhấn một nút bất kỷ để yêu cầu thang máy, vì thế hành động Cập nhật yêu cầu cũng phải được thực thi ở trạng thái Xử lý yêu cầu. Bây giờ chúng ta sẽ xem xét sự kiện 3 của kịch bản, thang máy tới tầng 3. Sự kiện này được mô hình hóa là thang máy bất kỳ đang di chuyển giữa các tầng. Sự di của thang máy được mô hình bằng vị từ [Thang máy di chuyển theo hướng d, tới tầng f] và trạng thái tiếp theo là Xác định yêu cầu thang máy dừngPTIT lại. Và ở đây lại có hai khả năng xảy ra hoặc là có một yêu cầu dừng tại tầng f hoặc là không có yêu cầu nào như vậy. Trong trường hợp yêu cầu dừng tại từng f tương ứng với vị từ [người dùng đã yêu cầu dừng thang máy ở tầng f] và trạng thái tiếp theo là Dừng thang máy tại một tầng và có các hành động tương ứng với kịch bản ở hình 8.2 là Dừng thang máy (từ sự kiện 3), Mở cửa và bắt đầu đếm giờ ( từ sự kiện 5, 6) và Cập nhật yêu cầu . Cuối cùng, mô hình hóa sự kiện 4 trong kịch bản đó là nút thang may sẽ trở lại trạng thái bình thường nếu nó sáng lên và được mô hình hóa bằng trạng thái Nút thang máy trở lại trạng thái bình thường (là trạng thái cuối cùng bên trái của hình 8.6), cùng với 2 vị từ ở phía trên của hộp trạng thái này. Mô hình hóa sự kiện 9 của kịch bản trong hình 8.2 sinh ra trạng thái Đóng cửa thang máy; mô hình hóa sự kiện 10 tương ứng là trạng thái Xử lý yêu cầu tiếp theo. Tuy nhiên, rất cần thiết có trạng thái Chuyển sang trạng thái chờ và vị từ [Không có yêu cầu chưa quyết định, cửa thang máy đóng] được suy luận ra từ việc mô hình hóa một sự kiện của kịch bản khác, đó là kịch bản người dùng ra khỏi thang máy và không còn nút nào sáng. 8.7 KIỂM THỬ TRONG PHÂN TÍCH HƯỚNG ĐỐI TƯỢNG Sau khi 3 mô hình của tiến trình phân tích hướng đối tượng được xem là hoàn thành thì bước tiếp theo là kiểm tra lại pha phân tích hướng đối tượng. CRC Cards là kỹ thuật kiểm thử tốt. 86
Chương 8: Phương pháp phân tích hướng đối tượng Các CRC cards đối với mỗi lớp Nút, Nút Thang Máy , Nút Tầng, Thang Máy và Điều Khiển Thang Máy được điền đầy đủ các thông tin. Ví dụ hình 8.7 được suy luận từ biểu đồ lớp 8.5 và biểu đồ trạng thái của hình 8.6. Trách nhiệm của lớp Điều Khiển Thang Máy chứa một lọat các hành động trong biểu đồ trạng thái của Điều Khiển Thang Máy (hình 8.6). Các lớp cộng tác của lớp Điều Khiển Thang Máy được xác định bằng cách xem xét biểu đồ lớp hình 8.5 và chú ý rằng các lớp Nút Thang Máy, Nút Tầng và Thang Máy tương tác với lớp Điều Khiển Thang Máy. Lớp Điều Khiển Thang Máy Trách nhiệm 1. Bật nút thang máy 2. Tắt nút thang máy 3. Bật nút ở tầng 4. Tắt nút ở tầng 5. Di chuyển thang máy lên một tầng nào đó 6. Di chuyển thang máy xuống một tầng nào đó 7. Mở cửa thang máy và bắt đầu đếm giờ 8. Đóng cửa thang máy sau một khoảng thời gian nhất định 9. Kiểm tra yêu cầu 10. Cập nhật yêu cầu Cộng tác 1. Lớp Nút Thang Máy 2. Lớp Nút Tầng 3. Lớp Thang Máy Hình 8.7 Vòng lặp thứ nhất cho CRC Card đối với lớp Elevator Controller CRC Card này nổi bật với hai vấn đề chính trong vòng lặp đầu tiên của phân tích hướng đối tượng. Trước tiên hãy xem xét tráchPTIT nhiệm 1.Bật nút thang máy. Yêu cầu này nói chung nằm ngoài phạm vi của mô hình hướng đối tượng. Từ quan điểm của thiết kế hướng trách nhiệm (1.6), chính các đối tượng của lớp Nút Thang Máy chịu trách nhiệm bật và tắt. Từ quan điểm ẩn dấu thông tin (7.6) Điều Khiển Thang Máy cần biết về khả năng của Nút Thang Máy là có thể bật một nút. Khi đó trách nhiệm đó phải được sửa lại là : gửi một thông điệp tới nút Nút Thang Máy để bật một nút. Tương tự ta cần phải thay đối đối với các trách nhiệm 2 đến 6 trong hình 8.7. Sự sửa đổi này được phản ánh trong hình 8.8, vòng lặp thứ 2 của CRC Card đối với lớp Điều Khiển Thang Máy. Vấn đề thứ hai là một lớp đã bị bỏ qua. Xem xét trách nhiệm 7.Mở cửa thang máy và bắt đầu đếm giờ. Khái niệm chính ở đây chính là trạng thái. Các thuộc tính của một lớp đôi khi được gọi là biến trạng thái. Trong hầu hết pha cài đặt hướng đối tượng, trạng thái của hệ thống phần mềm được định nghĩa bởi giá trị của các thuộc tính của các loại đối tượng thành phần khác nhau. Biểu đồ trạng thái có nhiều đặc trưng chung so với máy hữu hạn trạng thái. Vì thế khái niệm trạng thái đóng vai trò quan trọng trong mô hình hướng đối tượng. Khái niệm này được sử dụng để xác định liệu một thành phần có nên được mô hình như một lớp không? Nếu thành phần có trạng thái sẽ bị thay đổi trong suốt quá trình thực thi của sự cài đặt thì nó có thể được mô hình như một lớp. Rõ ràng, cửa của thanh máy có trạng thái (đóng và mở) và do đó nên mô hình Cửa Thang Máy là một lớp. 87
Chương 8: Phương pháp phân tích hướng đối tượng Có một lý do khác lý giải tại sao Cửa Thang Máy nên là một lớp. Mô hình hướng đối tượng cho phép trạng thái được ẩn dấu bên trong đối tượng và do đó trạng thái được bảo vệ khỏi những sự thay đổi không cho phép. Nếu có một đối tượng Cửa Thang Máy, thì có duy nhất một cách để đóng hoặc mở cửa của thanh máy bằng cách gửi một thông điệp tới đối tượng Cửa Thang Máy. Việc đưa thêm lớp Cửa Thang Máy có nghĩa là trách nhiệm 7 và 8 trong hình 8.7 được thay đổi tương tự như trách nhiệm 1 cho đến 6. Có một thông điệp gửi tới lớp Cửa Thang Máy để tự đối tượng đó đóng và mở. Nhưng có thêm sự phức tạp, trách nhiệm 7 là Mở cửa thang máy và bắt đầu đếm giờ phải được phân tách thành 2 trách nhiệm riêng biệt. Một trách nhiệm tương ứng là gửi thông điệp tới Cửa Thang Máy để mở cửa thang máy. Vì máy bấm giờ là một phần của Điều Khiển Thang Máy đo đó việc bắt đầu tính giờ là trách nhiệm của Điều Khiển Thang Máy. Vòng lặp thứ hai của CRC Card đối với lớp Điều Khiển Thang Máy được biểu diễn như hình 8.8. Trong hình 8.8 cũng thêm vào hai trách nhiệm là Kiểm tra yêu cầu và Cập nhật yêu cầu đối với lớp Điều Khiển Thang Máy. Lớp Điều Khiển Thang Máy Trách nhiệm 1. Gửi thông điệp tới Lớp Nút Thang Máy để bật nút 2. Gửi thông điệp tới Lớp Nút Thang Máy để tắt nút 3. Gửi thông điệp tới Lớp Nút Tầng để bật nút 4. Gửi thông điệp tới Lớp Nút Tầng để tắt nút 5. Gửi thông điệp tới Lớp Thang Máy để di chuyển lên một tầng nào đó. 6. Gửi thông điệp tới Lớp Thang Máy để di chuyển xuống một tầng nào đó. 7. Gửi thông điệp tới Lớp Cửa Thang Máy để mở cửa 8. Bắt đầu đếm giờ 9. Gửi thông điệp tới Lớp Cửa Thang Máy để đóng cửa sau một khoảng thời gian nhất định. 10. Kiểm tra yêu cầu PTIT 11. Cập nhật yêu cầu Cộng tác 1. Lớp Nút Thang Máy (lớp con) 2. Lớp Nút Tầng (lớp con) 3. Lớp Cửa Thang Máy 4. Lớp Thang Máy Hình 8.8 Vòng lặp thứ 2 của CRC Card của lớp Elevator Controller Biểu đồ lớp được sửa lại như hình 8.9. Sau khi chỉnh sửa biểu đồ lớp, thì biểu đồ Use-Case và biểu đồ trạng thái cũng phải xem xét lại, nếu cần thiết sẽ làm mịn hơn nữa. Biểu đồ Use case vẫn đầy đủ. Tuy nhiên, các hành động trong biểu đồ trạng thái hình 8.6 phải được chỉnh sửa để phản ánh đầy đủ những trách nhiệm trong 8.8 (vòng lặp thứ hai của CRC Card). Tập các biểu đồ trạng thái phải được mở rộng vì có thêm một lớp mới. Kịch bản cần được cập nhật để thể hiện sử thay đổi; Hình 8.10 biểu diễn vòng lặp thứ hai của kịch bản hình 8.2. Mặc dù sau tất cả những thay đổi đã được đưa ra và kiểm tra nhưng trong suotó pha thiết kế hướng đối tượng vẫn phải quay trở lại phân tích hướng đối tượng và xem xét lại một hoặc nhiều biểu đồ. 88
Chương 8: Phương pháp phân tích hướng đối tượng Hình 8.9 Vòng lặp thứ ba của biểu đồ lớp 1. Người dùng A nhấn nút đi lên của tầng ba để yêu cầu thang máy và người dùng A muốn đi lên tầng 7. 2. Nút ở tầng 3 thông báo cho bộ điều khiển thang máy là nút ở tầng đã được nhấn vào. 3. Điều khiển thang máy gửi một thông điệp tới nút đi lên ở tầng 3 để nút đó tự bật sáng. 4. Điều khiển thang máy gửi một loạt các thông điệp tới thang máy để thang máy tự di chuyển lên tầng 3. Trong thang máy hiện có người dùng B đã vào thang máy từ tầng một và yêu cầu lên tầng 9. 5. Điều khiển thang máy gửi một thông điệp tới cửa thang máy để mở cửa. 6. Thang máy bắt đầu tính thời gian. Người dùng A bước vào thang máy. 7. Người dùng A nhấn nút thangPTIT máy lên tầng 7. 8. Nút thang máy thông báo tới điều khiển thang máy rằng là nút thang máy đã được nhấn vào. 9. Bộ điều khiển thang máy gửi một thông điệp tới nút số 7 của thang máy để nút đó được bật sáng. 10. Bộ điều khiển thang máy gửi một thông điệp tới cửa thang máy để đóng thang máy sau một khoảng thời gian cố định. 11. Bộ điều khiển gửi một thông điệp tới nút đi lên ở tầng 3 để nó trở về trạng thái bình thường. 12. Bộ điều khiển thang máy gửi một loạt thông điệp tới thang máy để nó di chuyển lên tới tầng 7. 13. Bộ điều khiển thang máy gửi một thông điệp tới nút 7 ở thang máy để nó trở về trạng thái bình thường (không sáng). 14. Bộ điều khiển thang máy gửi một thông điệp tới cửa thang máy yêu cầu mở cửa để cho phép người dùng A bước ra khỏi thang máy. 15. Bộ điều khiển thang máy bắt đầu đặt thời gian. Người dùng A bước ra khỏi thang máy. 16. Bộ điều khiển thang máy gửi một thông điệp tới cửa thang máy để đóng cửa sau một thời gian cố định. 17. Bộ điều khiển thang máy gửi một loạt thông điệp tới thang máy để nó di chuyển lên tầng 9. 89
Chương 8: Phương pháp phân tích hướng đối tượng 8.8 CÁC CÔNG CỤ CASE CHO PHÂN TÍCH HƯỚNG ĐỐI TƯỢNG Các biểu đồ đóng vai trò quan trọng trong phân tích hướng đối tượng. Các biểu đồ thường xuyên thay đổi do đó cần có các công cụ vẽbiểu đồ. Các công cụ hỗ trợ cho UML: Các công cụ mang tính thương mại như: IBM Rational Rose và Together. Các công cụ Open-source: AgroUML 8.9 CASE STUDY CHO PHA PHÂN TÍCH HƯỚNG ĐỐI TƯỢNG 8.9.1. Các scenario Mục đích của bước này là viết các kịch bản (scenario) cho các use case đã xác định được trong pha lấy yêu cầu. a. Scenario cho Use case Room manage Mô tả: Use case này cho phép người quản lí (Manager) quản lí các thông tin về phòng khách sạn như thêm, sửa, xóa Thêm phòng mới: 1. Người quản lí A click vào chức năng thêm phòng trong menu quản lí chính. Quản lí A muốn thêm thông tin một phòng mới cho khách sạn. 2. Hệ thống hiển thị giao diện thêm phòng mới, yêu cầu nhập các thông tin: mã (tên) phòng, kiểu phòng, giá hiển thị, và mô tả phòng 3. Quản lí A nhập đầy đủ các thông tin về phòng mới và clik vào nút Thêm phòng 4. Hệ thống lưu thông tin phòng mớiPTIT vào CSDL và thông báo thêm thành công Sửa thông tin một phòng đã tồn tại: 1. Người quản lí A click vào chức năng sửa phòng trong menu quản lí chính. Quản lí A muốn sửa thông tin một phòng 305 của khách sạn. 2. Hệ thống hiển thị giao diện tìm phòng để sửa, yêu cầu nhập các thông tin: mã (tên) phòng 3. Quản lí A nhập tên phòng 305 và clik vào nút Tìm phòng 4. Hệ thống tìm kiếm thông tin phòng 305 từ CSDL và hiển thị lên các ô có thể sửa được các thuộc tính của phòng 305:: mã (tên) phòng, kiểu phòng, giá hiển thị, và mô tả phòng 5. Quản lí A sửa lại các thông tin về phòng 305 và clik vào nút Thêm phòng 6. Hệ thống lưu thông tin phòng mới vào CSDL và thông báo thêm thành công b. Scenario cho Use case Create report Mô tả: Use case này cho phép người quản lí (Manager) tạo và xem cáo báo cáo thống kê theo một khoảng thời gian nhất định (tuần, tháng) theo các tiêu chí khác nhau (doanh thu, tỉ lệ phòng trống, ) 90
Chương 8: Phương pháp phân tích hướng đối tượng Xem báo cáo doanh thu theo thời gian: 1. Người quản lí A click vào chức năng xem báo cáo trong menu quản lí chính. Quản lí A muốn báo cáo doanh thu theo thời gian của khách sạn. 2. Hệ thống hiển thị giao diện yêu cầu nhập khoảng thời gian: ngày bắt đầu, ngày kết thúc thống kê. Nút chọn kiểu báo cáo theo doanh thu hay theo tỉ lệ phòng kín chỗ 3. Quản lí A nhập ngày bắt đầu là 01/01/2013, ngày kết thúc là 31/12/2013, chọn kiểu báo cáo theo doanh thu và clik vào nút Thống kê 4. Hệ thống tìm kiếm từ CSDL và hiển thị lên thông tin thống kê doanh thu cho từng phòng, theo thứ tự giảm dần của tổng doanh thu theo phòng trong khoảng thời gian 01/01/2013- 31/12/2013. Hàng dưới cùng ghi tổng doanh thu của tất cả các phòng 5. Quản lí A xem thông tin thống kê và clik vào nút Quay lại menu chính c. Scenario cho Use case Book a room Mô tả: Use case này cho phép Khách hàng có thể đặt phòng. Có hai cách đặt phòng: đặt gián tiếp thông qua điện thoại với Nhân viên bán hàng (Saller, tương ứng với use case Book via phone), hoặc đặt trực tiếp tại quầy thông qua Nhân viên lễ tân (Receptionist, tương ứng với use case Book on site). Để thực hiện được use case này, phải thực hiện use case Tìm phòng trống. Đặt phòng qua điện thoại: 1. Nhân viên bán hàng A click vào chức năng đặt phòng trong menu quản lí đặt phòng. Nhân viên bán hàng A muốn đặt phòng cho khách hàng B, người đang gọi điện thoại yêu cầu đặt phòng. 2. Hệ thống hiển thị giao diện yêu cầu nhập khoảng thời gian muốn đặt của khách hàng: ngày bắt đầu, ngày kết thúc. 3. Nhân viên A hỏi lại khách hàng BPTIT ngày bắt đầu và kết thúc theo mong muốn 4. Khách hàng B trả lời ngày mong muốn cho nhân viên A qua điện thoại 5. Nhân viên A nhập ngày bắt đầu, ngày kết thúc vào các ô tìm kiếm và click vào nút tìm phòng trống. 6. Hệ thống tìm kiếm từ CSDL và hiển thị lên thông tin các phòng trống trong khoảng thời gian đã nhập. Mỗi hàng một phòng với đầy đủ thông tin: tên (mã) phòng, kiểu phòng, giá hiển thị, mô tả. 7. Nhân viên A thông báo các phòng có thể đặt cho khách hàng B và yêu cầu khách hàng B chọn 1 phòng trong số đó. 8. Khách hàng B chọn 1 phòng và thông báo lại cho nhân viên A, qua điện thoại 9. Nhân viên A click vào phòng tương ứng trên giao diện, và chọn đặt phòng 10. Hệ thống hiện lên giao diện yêu cầu nhập thông tin khách hàng: tên, ngày sinh, số CMT (passport), kiểu giấy tờ tùy thân, địa chỉ. 11. Nhân viên A hỏi lại khách hàng B các thông tin trên và điền lần lượt vào các ô. Sau đó click vào submit. 12. Hệ thống lưu thông tin đặt phòng vào CSDL và thông báo đặt phòng thành công với các thông tin: tên khách hàng, số id của khách hàng, địa chỉ khách hàng, tên phòng, ngày đến, ngày đi, giá phòng theo đêm, tổng giá dự kiến. 13. Nhân viên A xác nhận và thông báo lại cho khách hàng B 91
Chương 8: Phương pháp phân tích hướng đối tượng d. Scenario cho Use case Cancel a Booking Mô tả: Use case này cho phép Khách hàng có thể hủy đặt phòng. Có hai cách hủy đặt phòng: hủy gián tiếp thông qua điện thoại với Nhân viên bán hàng (Saller, tương ứng với use case Cancel via phone), hoặc hủy trực tiếp tại quầy thông qua Nhân viên lễ tân (Receptionist, tương ứng với use case Cancel on site). Hủy đặt phòng qua điện thoại: 1. Nhân viên bán hàng A click vào chức năng hủy đặt phòng trong menu quản lí đặt phòng. Nhân viên bán hàng A muốn hủy đặt phòng cho khách hàng B, người đang gọi điện thoại yêu cầu hủy đặt phòng. 2. Hệ thống hiển thị giao diện yêu cầu tên hoặc số id của khách hàng: 1 ô nhập id, 1 ô nhập tên và một nút tìm kiếm lịch sử đặt phòng của khác hàng 3. Nhân viên A hỏi lại khách hàng B id và tên 4. Khách hàng B trả lời tên và số id của mình cho nhân viên A qua điện thoại 5. Nhân viên A nhập id của khách hàng B ô tìm kiếm và click vào nút tìm kiếm. 6. Hệ thống tìm kiếm từ CSDL và hiển thị lên thông tin các lần đặt phòng của khách hàng B. Mỗi hàng một lần đặt với đầy đủ thông tin: tên (mã) phòng, kiểu phòng, giá đặt, mô tả, ngày bắt đầu, ngày kết thúc. 7. Nhân viên A yêu cầu khách hàng B và xác nhận thông tin phòng đặt và ngày đặt. 8. Khách hàng B thông báo lại cho nhân viên A, qua điện thoại 9. Nhân viên A click vào lần đặt phòng tương ứng trên giao diện, và chọn hủy đặt phòng 10. Hệ thống cập nhật thông tin hủy đặt phòng vào CSDL và thông báo hủy đặt phòng thành công. 11. Nhân viên A xác nhận và thông báo lại cho khách hàng B e. Scenario cho Use case Checkin Mô tả: Use case này cho phép NhânPTIT viên lễ tân (Receptionist) cập nhật trạng thái một khách hàng (Client) thành đã nhận phòng khi khách hàng đến nhận phòng. Khách hàng checkin tại quầy: 1. Nhân viên lễ tân A click vào chức năng nhận phòng trong menu quản lí khách nhận phòng. Nhân viên lễ tân A muốn cập nhật trạng thái nhận phòng cho khách hàng B. 2. Hệ thống hiển thị giao diện yêu cầu tên hoặc số id của khách hàng: 1 ô nhập id, 1 ô nhập tên và một nút tìm kiếm lịch sử đặt phòng của khác hàng 3. Nhân viên A hỏi lại khách hàng B id và tên 4. Khách hàng B trả lời tên và số id của mình cho nhân viên A 5. Nhân viên A nhập id của khách hàng B ô tìm kiếm và click vào nút tìm kiếm. 6. Hệ thống tìm kiếm từ CSDL và hiển thị lên thông tin các lần đặt phòng của khách hàng B. Mỗi hàng một lần đặt với đầy đủ thông tin: tên (mã) phòng, kiểu phòng, giá đặt, mô tả, ngày bắt đầu, ngày kết thúc. 7. Nhân viên A yêu cầu khách hàng B và xác nhận thông tin phòng đặt: ngày đến và đi. 8. Khách hàng B xác nhận ngày đến ngày đi cho nhân viên A 9. Nhân viên A click vào lần đặt phòng tương ứng trên giao diện, và chọn nhận phòng 10. Hệ thống cập nhật thông tin nhận phòng vào CSDL và thông báo nhận phòng thành công. 11. Nhân viên A xác nhận và trao chìa khóa phòng cho khách hàng B 92
Chương 8: Phương pháp phân tích hướng đối tượng f. Scenario cho Use case Checkout Mô tả: Use case này cho phép Nhân viên lễ tân (Receptionist) cập nhật trạng thái một khách hàng (Client) thành đã trả phòng khi khách hàng trả phòng. Use case này cũng đồng thời thực hiện việc thanh toán và in hóa đơn cho khách hàng. Khách hàng trả phòng tại quầy: 1. Nhân viên lễ tân A click vào chức năng trả phòng trong menu quản lí khách nhận phòng. Nhân viên lễ tân A muốn làm thủ tục trả phòng cho khách hàng B. 2. Hệ thống hiển thị giao diện yêu cầu tên hoặc số id của khách hàng hoặc số phòng của khách: 1 ô nhập id, 1 ô nhập tên và một nút tìm kiếm lịch sử đặt phòng của khác hàng 3. Nhân viên A hỏi lại khách hàng B số hiệu phòng muốn trả 4. Khách hàng B trả lời số hiệu phòng cho nhân viên A là 305 5. Nhân viên A nhập số hiệu phòng của khách hàng B ô tìm kiếm và click vào nút tìm kiếm. 6. Hệ thống tìm kiếm từ CSDL và hiển thị lên thông tin các phòng đã nhận của khách hàng B. Mỗi hàng một phòng với đầy đủ thông tin: tên (mã) phòng, kiểu phòng, giá đặt, mô tả, ngày bắt đầu, ngày kết thúc. 7. Nhân viên A click vào phòng 305 trên giao diện, và chọn trả phòng 8. Hệ thống cập nhật thông tin nhận phòng vào CSDL và hiển thị thông tin hóa đơn cần thanh toán bao gồm các thông tin: mã hóa đơn, ngày tạo, tên và địa chỉ khách hàng, số hiệu phòng, kiểu phòng, đơn giá. Dòng tiếp theo ghi tổng số tiền của hóa đơn, một dòng ghi số tổng số tiền đã thanh toán trước đó, dòng cuối ghi tổng số tiền còn lại khách hàng phải thanh toán. Bên dưới có thêm một nút nhấn “bổ sung các dịch vụ” 9. Nhân viên A click vào bổ sung các dịch vụ. 10. Hệ thống hiển thị một cửa sổ con cho phép nhân viên A nhập thông tin các dịch vụ mà khách hàng B đã sử dụng trong khoảng thời gian ở khách sạn. Mỗi dòng có các thông tin: tên dịch vụ, đơn vị tính, đơn giá, thành tiền. 11. Nhân viên A nhập đầy đủ thông tin các dịch vụ mà khách hàng B đã sử dụng và click vào nút xác nhận. PTIT 12. Hệ thống quay lại giao diện hiển thị hóa đơn, có bổ sung thêm phần các dịch vụ đã dùng. Tổng số tiền phải trả cũng được cập nhật theo. 13. Nhân viên A thông báo số tiền phải trả cho khách hàng B 14. Khách hàng B thanh toán cho nhân viên A số tiền yêu cầu. 15. Nhân viên A click vào nút xác nhận thanh toán 16. Hệ thống lưu thông tin thanh toán vào CSDL và thông báo trả phòng thành công. 17. Nhân viên A thông báo lại cho khách hàng B kết thúc thành công giao dịch. g. Scenario cho Use case Payment Mô tả: Use case này cho phép Nhân viên lễ tân (Receptionist) thực hiện thanh toán và in hóa đơn cho khách hàng. Khách hàng thanh toán trước một số tiền đặt phòng: 93
Chương 8: Phương pháp phân tích hướng đối tượng 1. Nhân viên lễ tân A click vào chức năng thanh toán trong menu quản lí khách nhận phòng. Nhân viên lễ tân A muốn làm thủ tục thanh toán đặt cọc cho khách hàng B. 2. Hệ thống hiển thị giao diện yêu cầu tên hoặc số id của khách hàng: 1 ô nhập id, 1 ô nhập tên và một nút tìm kiếm lịch sử đặt phòng của khác hàng 3. Nhân viên A hỏi lại khách hàng B id và tên 4. Khách hàng B trả lời tên và số id của mình cho nhân viên A 5. Nhân viên A nhập id của khách hàng B ô tìm kiếm và click vào nút tìm kiếm. 6. Hệ thống tìm kiếm từ CSDL và hiển thị lên thông tin các lần đặt phòng của khách hàng B. Mỗi hàng một lần đặt với đầy đủ thông tin: tên (mã) phòng, kiểu phòng, giá đặt, mô tả, ngày bắt đầu, ngày kết thúc. 7. Nhân viên A yêu cầu khách hàng B và xác nhận thông tin phòng đặt: ngày đến và đi. 8. Khách hàng B xác nhận ngày đến ngày đi cho nhân viên A 9. Nhân viên A click vào lần đặt phòng tương ứng trên giao diện, và chọn thanh toán 10. Hệ thống hiển thị thông tin hóa đơn cần thanh toán bao gồm các thông tin: mã hóa đơn, ngày tạo, tên và địa chỉ khách hàng, số hiệu phòng, kiểu phòng, đơn giá. Dòng tiếp theo ghi tổng số tiền của hóa đơn, một dòng ghi số tổng số tiền đã thanh toán trước đó. Dòng cuối cùng yêu cầu nhập vào số tiền khách hàng muốn thanh toán. 11. Nhân viên A nhập vào số tiền đã nhận của khách hàng B 12. Hệ thống hiển thị lại thông tin hóa đơn một lần nữa: trong đó cập nhật lại số tiền đã thanh toán và số tiền còn lại cần thanh toán. 13. Nhân viên A thông báo lại cho khách hàng số tiền còn lại cần trả và in hóa đơn cho lần thanh toán này cho khách hàng B. 8.9.2 Trích các lớp thực thể Mô tả hệ thống trong một đoạn văn như sau: Hệ thống quản lí thông tin về phòng của khách sạn, thông tin về khách hàng đặt phòng. Hệ thống cho phép người quản lí có thể quản lí thông tin về phòng và khách sạn, cho phép khách hàng đặt phòng qua điện thoại thông qua nhân viên bán hàng, hoặc đặt phòng trực tiếp tại quầy thông qua nhân viên lễ tân. Hệ thống cũng choPTIT phép nhân viên lễ tân thực hiện các hoạt động như nhận phòng, trả phòng, thanh toán khi có yêu cầu từ khách hàng. Mỗi khi thanh toán, hóa đơn sẽ được in ra cho khách hàng, bao gồm cả phí các dịch vụ mà khách hàng đã sử dụng khi nghỉ tại khách sạn. Như vậy, ta có các danh từ và các phân tích như sau: Hệ thống: danh từ chung chung > loại. Thông tin: danh từ chung chung > loại. Phòng: là đối tượng xử lí của hệ thống > là 1 lớp thực thể: Room Khách sạn: là đối tượng xử lí của hệ thống > là 1 lớp thực thể: Hotel Khách hàng: là đối tượng xử lí của hệ thống > là 1 lớp thực thể: Client 94
Chương 8: Phương pháp phân tích hướng đối tượng Người quản lí: không phải là đối tượng xử lí trực tiếp của hệ thống, nhưng cũng bị quản lí cùng với nhân viên lễ tân và nhân viên bán hàng theo kiểu người dùng trực tiếp của phần mềm > đề xuất là 1 lớp thực thể chung: User Điện thoại: không thuộc phạm vi xử lí của phần mềm > loại Nhân viên bán hàng: không phải là đối tượng xử lí trực tiếp của hệ thống, nhưng cũng bị quản lí cùng với người quản lí và nhân viên lễ tân theo kiểu người dùng trực tiếp của phần mềm > đề xuất là 1 lớp thực thể chung: User Quầy: không thuộc phạm vi xử lí của phần mềm > loại Nhân viên lễ tân: không phải là đối tượng xử lí trực tiếp của hệ thống, nhưng cũng bị quản lí cùng với người quản lí và nhân viên bán hàng theo kiểu người dùng trực tiếp của phần mềm > đề xuất là 1 lớp thực thể chung: User Hóa đơn: là đối tượng xử lí của hệ thống > là 1 lớp thực thể: Bill Dịch vụ: là đối tượng xử lí của hệ thống > là 1 lớp thực thể: Service Vậy chúng ta thu được các lớp thực thể ban đầu là: Room, Hotel, Client, User, Bill, và Service. Quan hệ giữa các lớp thực thể được xác định như sau: Một Hotel có nhiều Room, một Room chỉ thuộc vào một Hotel. Vậy quan hệ giữa Hotel và Room là 1-n. Một Client có thể đặt nhiều PTITRoom, một Room có thể bị đặt trước bởi nhiều Client ở nhiều thời điểm khác nhau: quan hệ giữa Client và Room là n-n. Do đó có thể bổ sung một lớp thực thể liên kết giữa hai đối tượng này là Booking: Một Client và một Room sẽ xác định duy nhất một Booking tại một thời điểm nhất định. Liên kết này xác định thêm các thông tin: ngày đến, ngày đi, giá thực. Một Booking có thể được thanh toán nhiều lần khác nhau. Do đó có nhiều hóa đơn khác nhau. Vậy quan hệ giữa Booking và Bill là 1-n. Một nhân viên lễ tân có thể lập nhiều hóa đơn khác nhau cho các Booking khác nhau. Do đó quan hệ giữa User và Bill cũng là 1-n. Một Service có thể dùng bởi nhiều Client khác nhau, tại nhiều lần Booking khác nhau. Nhưng một Service chỉ được thanh toán 1 lần (có thể với nhiều đơn vị) tại một lần Booking. Một Booking có thể dùng nhiều Service khác nhau: Quan hệ giữa Booking và Service là 1-n. Tuy nhiên một Service sẽ thanh toán với giá khác nhau tại các lần Booking 95
Chương 8: Phương pháp phân tích hướng đối tượng khác nhau. Do đó đề xuất bổ sung lớp UsedService làm cầu nối 1-n giữa lớp Booking và Service. Như vậy, ta thu được sơ đồ các lớp thực thể của hệ thống như Hình 8.10. PTIT Hình 8.10 : Sơ đồ lớp thực thể của hệ thống 8.9.3 Viết lại các scenario 96
Chương 9. Pha thiết kế CHƯƠNG 9: PHA THIẾT KẾ 9.1 TỔNG QUAN VỀ PHA THIẾT KẾ 9.1.1 Dữ liệu và các hành động Hai khía cạnh của một sản phẩm phần mềm o Những hành động thực hiện trên dữ liệu o Dữ liệu mà các hành động thao tác trên dữ liệu đó Hai cách cơ bản của thiết kế hệ thống phần mềm o Thiết kế hướng hành động o Thiết kế hướng dữ liệu Cách thứ ba o Các phương pháp lai o Chẳng hạn, thiết kế hướng đối tượng 9.1.2 Thiết kế và trừu tượng Các hoạt động thiết kế cổ điển o Thiết kế kiến trúc PTIT o Thiết kế chi tiết o Kiểm thử thiết kế Thiết kế kiến trúc o Đầu vào: Những đặc tả o Đầu ra: Sự phân nhỏ thành các mô đun Thiết kế chi tiết o Mỗi mô đun được thiết kế . Các thuật toán đặc trưng, các cấu trúc dữ liệu 97
Chương 9: Pha thiết kế 9.1.3 Thiết kế Tổng kết luồng công việc thiết kế: o Các tài liệu luồng công việc thiết kế được lặp và tích hợp đến khi người lập trình có thể sử dụng được chúng Các quyết định bao gồm: o Ngôn ngữ lập trình o Sử dụng lại o Tính khả chuyển Ý tưởng của việc phân tách luồng công việc lớp thành những luồng công việc nhỏ độc lập (các gói) được thực hiện ở luồng công việc phân tích Mục tiêu là chia nhỏ luồng công việc cài đặt thành những phần có thể quản lý được o Các hệ thống con Tại sao phần mềm được chia nhỏ thành các hệ thống con: o Dễ dàng để cài đặt một số hệ thống con hơn là một hệ thống lớn o Nếu các hệ thống con độc lập với nhau thì chúng có thể được cài đặt bởi các đội lập trình khác nhau cùng một lúc . Khi đó toàn bộPTIT sản phẩm phần mềm được chuyển giao sớm Kiến trúc của sản phẩm phần mềm bao gồm: o Các thành phần khác nhau o Cách chúng ăn khớp với nhau o Phân chia các thành phần vào các hệ thống con Công việc của thiết kế kiến trúc được chuyên môn hóa o Nó được thực hiện bởi các kiến trúc sư phần mềm Kiến trúc sư (architect)cần có sự cân bằng về: o Mỗi sản phẩm phần mềm phải đáp ứng các yêu cầu chức năng của chúng (các use case) 98
Chương 9: Pha thiết kế o Mỗi sản phẩm phần mềm cũng phải đáp ứng các yêu cầu phi chức năng, bao gồm: . Khả chuyển, đáng tin, mạnh mẽ, bảo trì và bảo mật o Mỗi sản phẩm phần mềm phải thực hiện tất cả những yêu cầu này trong ràng buộc chi phí và thời gian Kiến trúc sư phải giúp khác hàng bằng cách sắp xếp những cân bằng này. Thường không thể đáp ứng tất cả các yêu cầu chức năng và phi chức năng trong ràng buộc về chi phí và thời gian o Có một vài sự sắp xếp được thực hiện Khách hàng phải o Giảm bớt một số yêu cầu; o Tăng chi phíe; và /hoặc o Thay đổi thời gian chuyển giao Kiến trúc của sản phẩm phần mềm là quan trong o Luồng công việc xác định yêu cầu có thể được sửa lại (fix) trong suốt luồng phân tích o Luồng công việc phân tích có thể được sửa lại trong suốt luồng công việc thiết kế o Luồng công việc thiếtPTIT kế có thể được sửa lại trong suốt luồng công viẹc cài đặt Nhưng không có cách để phục hồi từ kiến trúc gần tốt nhất o Kiến trúc phải được thiết kế lại ngay lập tức 9.1.4 Kiểm thử trong pha thiết kế Rà soát thiết kế phải được thực hiện o Thiết kế phải phản ánh chính xác đặc tả o Chính thiết kế phải chính xác Kiểm tra kỹ lưỡng hướng giao tác (Transaction-driven inspections) o Cần thiết cho các phần mềm hướng giao tác 99
Chương 9: Pha thiết kế o Tuy nhiên, những kiểm tra hướng giao tác là chưa đủ nên những kiểm tra hướng đặc tả cũng được yêu cầu 9.1.5 Kỹ thuật hình thức cho thiết kế chi tiết Việc cài đặt một phần mềm hoàn thiện và sau đó chứng minh nó là chính xác là rất khó Tuy nhiên, sử dụng kỹ thuật hình thứuc trong suốt thiết kế chi tiết có thể giúp: o Việc chứng minh tính chính xác có thể được áp dụng đối với các phần mô đun o Thiết kế có ít lỗi hơn nếu nó được phát triển song song với sự kiểm chứng tính chính xác o Nếu cùng một người lập trình thực hiện cả thiết kế chi tiết và cài đặt . Người lập trình sẽ có một quan điểm tích cực đối với thiết kế chi tiết . Chính điều này dẫn đến ít lỗi 9.1.6 Kỹ thuật thiết kế hệ thống thời gian thực Những kho khăn của hệ thống thời gian thực o Đầu vào lấy từ thế giới thực . Phần mềm không có điều khiển bộ định thời của các đầu vào ( Software has no control over the timing of the inputs) o Được cài đặt thườngPTIT xuyên trên phần mềm phân tán . Communications implications . Những vấn đề định thời (Timing issues) o Những vấn đề của đồng bộ . Race conditions . Bế tắc (Deadlock - deadly embrace) Những khó khăn chính trong thiết kế hệ thống thời gian thực o Xác định liệu những ràng buộc về thời gian có được đáp ứng bởi thiết kế không? Hầu hết các phương thức thiết kế thời gian thực là những sự mở rộng của các phương thức phi thời gian thực (Most real-time design methods are extensions of non-real-time methods to real-time ) 100
Chương 9: Pha thiết kế Chúng ta đã hạn chế những thử nghiệm trong cách sử dụng bất cứ phương thưc thời gian thực nào. (We have limited experience in the use of any real-time methods) The state-of-the-art is not where we would like it to be 9.1.7 Công cụ CASE cho thiết kế Rất quan trọng để kiểm tra tài liệu thiết kế hợp nhất với mọi khía cạnh của phân tích o Để xử lý tài liệu phân tích và thiết kế chúng ta cần một công cụ upperCASE Công cụ upperCASE o Được xây dựng xung quanh từ điển dữ liệu(Are built around a data dictionary) o They incorporate a consistency checker, and o Màn ảnh và các bản tường trình (Screen and report generators) o Công cụ quản lý đôi khi bao gồm . Ước lượng . Lập kế hoạch Ví dụ của các công cụ cho thiết kế hướng đối tượng o Công cụ thương mại . Software throughPTIT Pictures . IBM Rational Rose . Together o Công cụ mã nguồn mở . ArgoUML 9.1.8 Thước đo cho thiết kế Thước đo chất lượng thiết kế o Kết dính (Cohesion) o Sự kết nối (Coupling) o Thống kê lỗi 101
Chương 9: Pha thiết kế Cyclomatic complexity is problematic o Độ phức tạp dữ liệu được bỏ qua o Nó không được sử dụng nhiều với mô hình hướng đối tượng Các thước đo được đề xuất cho mô hình hướng đối tượng o Chúng đã chứng tỏ được tính hữu ích trong cả lý thuyết và thử nghiệm.(They have been challenged on both theoretical and experimental grounds) 9.1.9 Những thách thức của pha thiết kế Đội thiết kế không nên làm quá nhiều o Thiết kế chi tiết không nên là những người viết mã Đội thiết kế không nên làm quá ít o Đủ để cho đội thiết kế để đưa ra một thiết kế chi tiết hoàn thiện Chúng ta cần “phát triển ” những người thiết kế giỏi Những người thiết kế giỏi tiềm năng phải o Được nhận định, o Đã được đào tạo một cách hình thức, o Đang học nghề để trởPTIT thành một người thiết kế giỏi, và o Được phép giao tiếp với những người thiết kế khác Phải có một hướng đi nghề nghiệp cụ thể cho những người thiết kế này, với một chế độ thưởng thích hợp 9.2 THIẾT KẾ HƯỚNG HÀNH ĐỘNG Phân tích luồng dữ liệu o Sử dụng phân tích luồng dữ liệu với hầu hết các phương pháp đặc tả (ở đây là phân tích hệ thống theo hướng cấu trúc) Điểm chính: Chúng ta đã chi tiết hóa các thông tin hành động từ DFD Hình 9.1: Luồng dữ liệu 102
Chương 9: Pha thiết kế 9.3 PHÂN TÍCH VA THIẾT KẾ DÒNG DỮ LIỆU 9.3.1 Phân tích dòng dữ liệu Mỗi sản phẩm phần mềm biến đổi từ đầu vào thành đầu ra Xác định o “Điểm trừu tượng nhất của đầu vào” o “Điểm trừu tượng nhất của đầu ra” Hình 9.2: Tìm các điểm trừu tượng đầu vào, đầu ra Phân chia phần mềm thành 3 mô đun Lặp lại các bước cho đến khi mỗi mô đun có độ dính kết cao (cohesion) o Những chỉnh sửa phụPTIT có thể cần thiết để giảm bớt độ kết nối (coupling ) 9.3.1.1 Bài toán đếm từ Ví dụ: Thiết kế một hệ thống phần mềm với đầu vào là một tên tệp, và kết quả trả về là số lượng từ trong file đó( giống như UNIX wc ) Hình 9.3: Xác định điểm trừu tượng vào/ra cho bài toán đếm từ 103
Chương 9: Pha thiết kế Quá trình làm mịn thứ nhất Hình 9.4: Quá trình làm mịn thứ nhất Làm mịn hai mô đun ở mức dính kết giao tiếp (communicational cohesion) Bước làm mịn thứ hai PTIT Hình 9.5: Quá trình làm mịn thứ hai Tất cả 8 mô đun đểu ở mức dính kết chức năng (functional cohesion) Thiết kế kiến trúc đã hoàn thiện, vì thế thực hiện thiết kế chi tiết. Hai định dạng để biểu diễn thiết kế chi tiết: 104
Chương 9: Pha thiết kế o Tabular PTIT 105
Chương 9: Pha thiết kế o Mã giả (PDL — program design language – ngôn ngữ thiết kế chương trình) PTIT 106
Chương 9: Pha thiết kế PTIT 9.3.1.2 Mở rộng phân tích luồng dữ liệu Sản phẩm phần mềm trong thực tế, có o Nhiều hơn một luồng đầu vào o Nhiều hơn một luồng đầu ra Tìm điểm trừu tượng nhất của mỗi luồng 107
Chương 9: Pha thiết kế Hình 9.6: mở rộng luồng phân tích dữ liệu Tiếp tục thực hiện cho đến khi mỗi mô đun có độ dính kết cao o Điều chỉnh kết nối (coupling) nếu cần thiết 9.3.2 Thiết kế dòng dữ liệu Nguyên lý cơ bản o Cấu trúc của một phần mềm phải phù hợp với cấu trúc của dữ liệu của nó Có ba phương pháp rất giống nhau o Michael Jackson [1975],PTIT Warnier [1976], Orr [1981] o Thiết kế hướng dữ liệu o Chưa từng phổ biến như thiết kế hướng hành động o Với sự ra đời của OOD, thiết kế hướng dữ liệu đã bị lỗi thời 9.4 THIẾT KẾ HƯỚNG ĐỐI TƯỢNG Mục đích o Thiết kế phần mềm dưới dạng các lớp được trích rút trong suốt phân tích hướng đối tượng (OOA) Nếu chúng ta đang sử dụng một ngôn ngữ mà không có tính kế thừa như C, Ada83 o Sử dụng thiết kế kiểu dữ liệu trừu tượng 108
Chương 9: Pha thiết kế Nếu chúng ta đang sử dung ngôn ngữ không có khai báo kiểu như FOTRAN, COBAL o Sử dụng đóng gói dữ liệu OOD gồm 2 bước: Bước 1. Hoàn thiện biểu đồ lớp Xác định định dạng của các thuộc tính : Định dạng của các thuộc tính có thể được rút ra từ tài liệu phân tích .Ví dụ: Ngày theo định dạng của Mỹ (mm/mm/yyyy) và định dạnh của Châu Âu (dd/mm/yyyy). Trong cả hai trường hợp đều yêu cầu 10 ký tự.Định dạng có thể được thêm vào trong suốt quá trình phân tích. Để cực tiểu hóa việc làm lại, không bao giờ thêm một mục vào biểu đồ UML cho đến lúc cần thiết Gán mỗi phương thức cho 1lớp hoặc một client đã gửi thông điệp tới đối tượng của lớp đó. Với 3 nguyên lý: Nguyên lý A: Ẩn giấu thông tin. Nguyên lý B: Nếu một phương thức được gọi bởi nhiều client của một đối tượng thì sẽ gán phương thức đó cho đối tượng chứ không phải các client. Nguyên lý C: thiết kế hướng trách nhiệm Xem xét vòng lặp thứ hai của thẻ CRC của điều khiển thang máy PTIT Hình 9.7: Xác định trách nhiệm từ thẻ CRC o Trách nhiệm sau được gán trách nhiệm cho lớp điều khiển thang máy . 8. Bắt đầu đặt thời gian . 10. Kiểm tra yêu cầu . 11. Cập nhật yêu cầu o Bởi vì chúng được thực hiện bởi lớp điều khiển thang máy 109
Chương 9: Pha thiết kế o Tám trách nhiệm còn lại có cùng một dạng: . “Gửi một thông điệp tới một lớp khác để yêu cầu nó làm một cái gì đó” o Những trách nhiệm này được gán cho các lớp khác . Thiết kế hướng trách nhiệm . Xem xét độ an toàn o Các phương thức mở cửa, đóng cửa được gán cho lớp Cửa thang máy o Các phương thức mở nút, tắt nút được gán cho lớp Nút Tầng và lớp Thang Máy Biểu đồ lớp chi tiết cho bài toán thang máy: PTIT Hình 9.8: Sơ đồ lớp chi tiết cho bài toán thang máy Bước 2. Thực hiện thiết kế chi tiết Thiết kế chi tiết của vòng lặp sự kiện thang máy được đưa ra từ biểu đồ trạng thái 110
Chương 9: Pha thiết kế PTIT 9.5 CASE STUDY CHO PHA THIẾT KẾ Mục này tiếp tục tiến hành thiết kế hệ thống cho ứng dụng quản lí đặt phòng khách sạn đã được trình bày trong case study của các pha lấy yêu cầu và pha phân tích. Nội dung bao gồm: Thiết kế cơ sở dữ liệu Thiết kế hệ thống: chúng ta sẽ học một số cách thiết kế khác nhau cho cùng một ứng dụng: thiết kế không dựa vào lớp điều khiển, thiết kế có dựa vào lớp điều khiển, và thiết kế theo mô hình MVC cải tiến. Để minh họa cho các hướng thiết kế này, bài giảng sẽ trình bày phần thiết kế cho 3 modul: thêm một phòng khách sạn, sửa thông tin một phòng khách sạn, và khách hàng đặt phòng. 111
Chương 9: Pha thiết kế 9.5.1 Thiết kế cơ sở dữ liệu Dựa vào sơ đồ lớp thực thể đã trích được trong pha phân tích (Hình 8.10), chúng ta có thể đề xuất các bảng dữ liệu như sau: tblHotel: lưu các thông tin về khách sạn, bao gồm: id, tên, địa chỉ, hạng sao, và mô tả về khách sạn. tblRoom: lưu các thông tin về phòng khách sạn, bao gồm: id (cũng là số hiệu phòng), kiểu phòng, giá hiển thị, và mô tả chung về phòng. tblClient: lưu thông tin các khách hàng đặt phòng, bao gồm: id, số thẻ căn cước, kiểu thẻ căn cước, họ tên đầy đủ, ngày sinh, và địa chỉ. tblBooking: lưu thông tin về từng lần đặt chỗ của khách hàng, bao gồm: ngày đến, ngày đi, giá đặt, trạng thái đã checkin hay chưa, và ghi chú bổ sung theo yêu cầu của khách hàng để khách sạn lưu ý. tblUser: lưu thông tin về người dùng của phần mềm: id, tên đăng nhập, mật khẩu, và vị trí công việc. tblService: lưu thông tin các dịch vụ kèm theo phòng và có tính phí cho khách hàng, mỗi dịch vụ được lưu bởi: id, tên dịch vụ, đợn vị tính, đơn giá hiển thị. tblUsedService: lưu thông tin các dịch vụ đã được sử dụng bởi khách đặt phòng, bao gồm: id, số lượng theo đơn vị tính, đơn giá thực trả. tblBill: lưu thông tin hóa đơn mỗi lần thanh toán của khác hàng, bao gồm: id, ngày trả, số tiền thanh toán cho lần trả đóPTIT, hình thức thanh toán. Quan hệ giữa các bảng được mô tả như Hình 9.9: Bảng tblHotel quan hệ 1-n với bảng tblRoom Bảng tblRoom và bảng tblClient đều quan hệ 1-n với bảng tblBooking Bảng tblService và bảng tblBooking đều quan hệ 1-n với bảng tblUsedService Bảng tblUser và bảng tblBooking đều quan hệ 1-n với bảng tblBill. 112
Chương 9. Pha thiết kế PTIT Hình 9.9: Sơ đồ thiết kế CSDL cho hệ thống 113
Chương 9. Pha thiết kế 9.5.2 Thiết kế dùng bean thay cho control Tư tưởng chủ đạo của phương pháp này là đóng gói thông tin và hành động của các lớp thực thể thành một lớp chung, gọi là lớp bean (bản chất không còn là lớp thực thể nữa, mà đã bao gồm các phương thức của lớp điều khiển). Do đó, hệ thống sẽ không còn cần đến lớp điều khiển. Khi có sự kiện trên form, lớp giao diện sẽ gọi hàm actionPerformed(), hàm này sẽ gọi phương thức tương ứng của lớp bean để truy cập CSDL. a. Thiết kế cho chức năng thêm/sửa phòng + Sơ đồ lớp chi tiết cho modul PTIT Hình 9.10: Sơ đồ lớp thiết kế kiểu bean cho modul thêm/sửa phòng Vì thiết kế theo kiểu dùng bean nên lớp RoomBean vừa chứa các thuộc tính của phòng, vừa chứa các phương thức thêm, sửa, tìm kiếm phòng từ CSDL. Trong các lớp giao diện thì các phương thức xử lí sự kiện actionPerformed() sẽ gọi trực tiếp các phương thức của lớp bean để thự hiện. + Viết lại scenario cho chức năng nhập mới thông tin phòng 114
Chương 9: Pha thiết kế 1. Người quản lí nhập thông tin một phòng mới vào AddRoomFrm và click vào nút Submit trên form 2. Lớp AddRoomFrm gọi phương thức addRoom() của lớp RoomBean 3. Lớp Roombean thực hiện phương thức addRoom() rồi trả về cho lớp AddRoomFrm 4. Lớp AddRoomFrm hiện thông báo thêm phòng thành công cho người quản lí. + Sơ đồ tuần tự cho chức năng nhập mới thông tin phòng Hình 9.11: Sơ đồ tuần tự cho chức năng thêm phòng, dùng bean + Viết lại scenario cho chức năng cậpPTIT nhật thông tin phòng 1. Người quản lí nhập tên phòng muốn thay đổi vào EditRoomFrm và click vào nút Search trên form 2. Lớp EditRoomFrm gọi phương thức searchRoom(ID) của lớp RoomBean 3. Lớp Roombean thực hiện phương thức searchRoom(ID) rồi trả về cho lớp EditRoomFrm 4. Lớp EditRoomFrm hiện thông tin phòng lên các ô thuộc tính tương ứng trên form cho người quản lí sửa đổi. 5. Người quản lí sửa đổi các thuộc tính cần thiết trên form và click vào nút Submit 6. Lớp EditRoomFrm gọi phương thức btnSubmit_actionPerformed() để thực hiện. 7. Phương thức btnSubmit_actionPerformed() gọi phương thức editRoom() của lớp RoomBean 115
Chương 9: Pha thiết kế 8. Lớp Roombean thực hiện phương thức editRoom() rồi trả về cho lớp EditRoomFrm 9. Lớp EditRoomFrm hiện thông báo sửa đổi thành công cho người quản lí. + Sơ đồ tuần tự cho chức năng cập nhật thông tin phòng Hình 9.12: Sơ đồ tuần PTITtự cho chức năng sửa thông tin phòng, dùng bean b. Thiết kế cho chức năng đặt phòng + Sơ đồ lớp chi tiết cho modul 116
Chương 9: Pha thiết kế PTIT Hình 9.13: Sơ đồ lớp cho chức năng thêm/sửa phòng, thiết kế dùng bean + Viết lại scenario 1. Khách hàng gọi điện cho nhân viên bán hàng yêu cầu đặt phòng. 2. Nhân viên chọn chức năng tìm kiếm phòng trống trên form AddBookingFrm. 3. Lớp AddBookingFrm gọi form SearchRoomFrm hiển thị. 4. Lớp form SearchRoomFrm hiển thị yêu cầu nhân viên nhập ngày checkin, ngày checkout để tìm kiếm. 5. Nhân viên nhập ngày checkin, checkout theo yêu cầu khách hàng và click vào nút tìm kiếm. 6. Lớp SearchRoomFrm gọi phương thức searchRoom() của lớp RoomBean. 117
Chương 9: Pha thiết kế 7. Lớp RoomBean thực hiện hàm searchRoom() và trả kết quả lại cho lớp SearchRoomFrm. 8. Lớp SearchRoomFrm hiển thị danh sách các phòng trống lên cho nhân viên. 9. Nhân viên thông báo các phòng có thể đặt cho khách hàng. 10. Khách hàng chọn 1 phòng theo yêu cầu và trả lời cho nhân viên. 11. Nhân viên click chọn phòng tương ứng trên giao diện SearchRoomFrm. 12. Lớp SearchRoomFrm gọi hàm setRoom() của lớp AddBookingFrm và tự đóng form lại. 13. Lớp AddBookingFrm cập nhật thông tin phòng đã chọn và yêu cầu nhân viên chọn nhập thông tin khách hàng. 14. Nhân viên click vào nút tìm kiếm khách hàng trên form AddBookingFrm. 15. Lớp AddBookingFrm gọi lớp form AddClientFrm hiển thị. 16. Lớp AddClientFrm hiển thị yêu cầu nhân viên nhập tên khách hàng để tìm kiếm. 17. Nhân viên hỏi lại khách hàng thông tin cá nhân đầy đủ. 18. Khách hàng cung cấp đầy đủ thông tin cá nhân cho nhân viên. 19. Nhân viên gõ tên khách hàng vào và click nút tìm kiếm trên form AddClientFrm. 20. Lớp AddClientFrm gọi hàm searchClient() của lớp ClientBean. 21. Lớp ClientBean thực hiện hàmPTIT searchClient() và trả kết quả lại cho lớp AddClientFrm. 22. Lớp AddClientFrm hiện kết quả các khách hàng có tên đã nhập lên cho nhân viên lựa chọn. 23. Vì khác hàng chưa có trong danh sách đã đặt chỗ nên nhân viên chọn nhập thông tin khách hàng mới và click vào nút Submit trên form AddClientFrm. 24. Lớp AddClientFrm gọi phương thức addClient() của lớp ClientBean. 25. Lớp ClientBean thực hiện hàm addClient() và trả về cho lớp AddClientFrm. 26. Lớp AddClientFrm gọi phương thức setClient() của lớp AddBookingFrm và tự đóng form của mình. 27. Lớp AddBookingFrm cập nhật thông tin khách hàng lên form và yêu cầu nhân viên hoàn thành các thông tin đặt chỗ còn lại. 28. Nhân viên nhập các thông tin đặt chỗ còn lại và click vào Submit. 118
Chương 9: Pha thiết kế 29. Lớp AddBookingFrm gọi phương thức addBooking() của lớp BookingBean. 30. Lớp BookingBean thực hiện hàm addBooking() và trả về cho lớp AddBookingFrm. 31. Lớp AddBookingFrm thông báo đặt chỗ thành công cho nhân viên. 32. Nhân viên xác nhận lại cho khách hàng thông tin đặt chỗ thành công và kết thúc giao dịch. + Sơ đồ tuần tự PTIT 119
Chương 9. Pha thiết kế PTIT 120
Chương 9: Pha thiết kế PTIT Hình 9.14: Sơ đồ tuần tự chức năng đặt phòng, thiết kế theo cách dùng bean 121
Chương 9. Pha thiết kế 9.5.3 Thiết kế dùng control DAO và thực thể thuần Tư tưởng chủ đạo của phương pháp này là tách bạch thông tin và hành động của các lớp thực thể thành 2 lớp riêng biệt: lớp chỉ chứa thông tin được gọi là các lớp thực thể thuần, lớp chỉ chứa hành động (phương thức) được gọi là lớp điều khiển truy cập dữ liệu DAO (Data Access Object). Khi có sự kiện trên form, lớp giao diện sẽ gọi hàm actionPerformed(), hàm này sẽ tạo ra một đối tượng lớp thực thể thuần để truyền vào khi gọi phương thức tương ứng của lớp điều khiển để truy cập CSDL. a. Thiết kế cho chức năng thêm/sửa phòng + Sơ đồ lớp chi tiết cho modul PTIT Hình 9.15: Sơ đồ lớp cho modul thêm/sửa thông tin phòng, thiết kế dùng DAO và thực thể thuần + Sơ đồ tuần tự 122
Chương 9: Pha thiết kế Hình 9.16: Sơ đồ tuần tự cho chức năng thêm thông tin phòng, thiết kế dùng DAO và thực thể thuần PTIT 123
Chương 9: Pha thiết kế Hình 9.17: Sơ đồ tuần tự cho chức năng sửa thông tin phòng, thiết kế dùng DAO và thực thể PTITthuần b. Thiết kế cho chức năng đặt phòng + Sơ đồ lớp chi tiết cho modul 124
Chương 9: Pha thiết kế PTIT Hình 9.18: Sơ đồ lớp chức năng đặt phòng, thiết kế dùng DAO và thực thể thuần + Sơ đồ tuần tự 125
Chương 9. Pha thiết kế PTIT 126
Chương 9: Pha thiết kế PTIT 127
Chương 9: Pha thiết kế Hình 9.19: Sơ đồ tuần tự chức năng đặt phòng, thiết kế dùng DAO và thực thể thuần PTIT 128
Chương 9. Pha thiết kế 9.5.4 Thiết kế theo MVC cải tiến, dùng control DAO và thực thể thuần Tư tưởng của phương pháp này tương tự như phương pháp dùng control DAO và thực thể thuần. Nhưng trong mô hình dùng control DAO và thực thể thuần, lớp view gọi lớp control trong hàm actionPerformed() để xử lí các sự kiện. Trong mmo hình có tuân thủ MVC cải tiến thì lớp view không có quyền gọi contrrol, mà chỉ có control mới có quyền gọi và điều khiển các hàm của view. Do đó, lớp điều khiển sẽ cần đến các lớp nội tại để xử lí sự kiện thay cho lớp view: Khi có sự kiện trên form, lớp giao diện sẽ không gọi hàm actionPerformed() mà truyền sự kiện này cho lớp control xử lí, lớp control sẽ gọi hàm actionPerformed() của lớp nội tại của nó để xử lí, trong hàm này sẽ gọi các phương thức truy nhập CSDL của lớp control. a. Thiết kế cho chức năng thêm/sửa phòng + Sơ đồ lớp chi tiết cho modul PTIT Hình 9.20: Sơ đồ lớp chức năng thêm/sửa thông tin phòng, thiết kế theo mô hình MVC cải tiến 129
Chương 9: Pha thiết kế + Sơ đồ tuần tự Hình 9.21: Sơ đồ tuần tự chức năng thêm thông tin phòng, thiết kế theo mô hình MVC cải tiến PTIT 130
Chương 9: Pha thiết kế PTIT Hình 9.22: Sơ đồ tuần tự chức năng sửa thông tin phòng, thiết kế theo mô hình MVC cải tiến b. Thiết kế cho chức năng đặt phòng + Sơ đồ lớp chi tiết cho modul 131
Chương 9. Pha thiết kế PTIT Hình 9.23: Sơ đồ lớp cho chức năng đặt phòng, thiết kế theo mô hình MVC cải tiến 132
Chương 9. Pha thiết kế PTIT 133
Chương 9: Pha thiết kế PTIT 134
Chương 9: Pha thiết kế Hình 9.24: Sơ đồ tuần tự cho chứcPTIT năng đặt phòng, thiết kế theo mô hình MVC cải tiến 135
Chương 10. Pha cài đặt và tích hợp CHƯƠNG 10: PHA CÀI ĐẶT VÀ TÍCH HỢP 10.1 CÁC PHƯƠNG PHÁP CÀI ĐẶT VÀ TÍCH HỢP 10.1.1 Luồng công việc cài đặt Mục đích của luồng công việc cài đặt là cài đặt phần mềm đích Phần mềm lớn được chia thành các hệ thống con o Được cài đặt song song bởi các đội viết mã Các hệ thống con bao gồm các thành phần và các mô đun mã Một khi người lập trình đã cài đặt một mô đun, người ấy thực hiện kiểm thử đơn vị mô đun đó Sau đó mô đun được chuyển qua nhóm SQA để kiểm thử mức cao hơn o Kiểm thử này là một phần của luồng công việc kiểm thử 10.1.1.1 Chọn ngôn ngữ lập trình Ngôn ngữ thường được chỉ rõ trong hợp đồng Nhưng điều gì sẽ xảy ra khi hợp đồng chỉ ra rằng: o Sản phẩm phần mềm được cài đặt bằng ngôn ngữ lập trình “phù hợp nhất” Ngôn ngữ nào nên được chọn? Ví dụ: o Tổ chức QQQ đã viết bằng ngôn ngữ COBOL suốt 25 năm qua o Trên 200 nhân viên phần mềm, tất cả để là chuyên gia về COBOL o Ngôn ngữ lập trình nào là phù hợp nhất? Hiển nhiên COBOL PTIT Chuyện gì xảy ra khi ngôn ngữ lập trình mới (như C++) được giới thiệu: o Những chuyên gia C++ phải thuê o Những chuyên gia COBOL vốn có phải đào tạo lại o Những sản phẩm trong tương lại được viết bằng C++ o Những sản phẩm phần mềm COBOL sẵn có phải được bảo trì o Có hai kiểu người lập trình khác nhau . Những người bảo trì COBOL (bị coi nhẹ) . Những người lập trình C++ (được trả nhiều tiền hơn) o Yêu cầu phần mềm và phần cứng đắt tiền để chạy ngôn ngữ lập trình o Hàng trăm chuyên gia COBOL bị bỏ phí Kết luận duy nhất là: o COBOL là ngôn ngữ lập trình phù hợp nhất Và ngôn ngữ phù hợp nhất cho dự án mới nhất có thể là C++ o COBOL phù hợp với những ứng dụng chỉ xử lý dữ liệu 136
Chương 10: Pha cài đặt và tích hợp Cách chọn ngôn ngữ lập trình o Phân tích lợi nhuận – chi phí o Tính toán chi phí và lợi nhật của tất cả các ngôn ngữ liên quan Ngôn ngữ hướng đối tượng nào thích hợp nhất? o C++ giống C (C++ is (unfortunately) C-like) o Do đó, mỗi chương trình C cổ điển tự động là chương trình C++ o Java được yêu cầu đối với mô hình hướng đối tượng o Việc đào tạo trong mô hình hướng đối tượng là cần thiết trước khi áp dụng bất cứ ngôn ngữ hướng đối tượng nào Còn việc lựa chọn ngôn ngữ thế hệ thức tư? (Fourth generation language -4GL)? 10.1.1.2 Ngôn ngữ thế hệ thứ tư Ngôn ngữ thế hệ thứ nhất o Ngôn ngữ máy Ngôn ngữ thế hệ thứ hai o Hợp ngữ Ngôn ngữ thế hệ thứ ba o Ngôn ngữ bậc cao (COBOL, FORTRAN, C++, Java) Ngôn ngữ thế hệ thứ tư (4GLs) o Một câu lệnh ngôn ngữ thế hệ thứ ba tương đương với 5 đến 10 câu lệnh hợp ngữ o Mỗi câu lệnh ngôn ngữ thứ tư tương đương với 30 hoặc 50 câu lệnh hợp ngữ Hy vọng rằng ngôn ngữ thứ tư sẽ: o Tăng nhanh tốc độ xây dựng ứng dụng o Kết quả của các ứng dụng là dễ dàng xây dựng và nhanh chóng thay đổi . Giảm chi phíPTIT bảo trì o Đơn giản trong việc gỡ lỗi o Tạo ngôn ngữ thân thiện người dùng Có thể thực hiện được nếu ngôn ngữ thứ tư là ngôn ngữ bậc cao, thân thiện với người dùng Những đóng góp vào thị trường: o Không có một ngôn ngữt thế hệ thứ 4 nào chiếm ưu thế trong thị trường phần mềm o Có hàng trăm 4GL o Hàng tá nhóm người dùng cỡ lớn o Oracle, DB2, và PowerBuilder cực kỳ phổ biến Lý do o Không có một 4GL có đủ những đặc trưng cần thiết Kết luận o Đặc biệt quan tâm đến việc lựa chọn 4GL thích hợp 137
Chương 10: Pha cài đặt và tích hợp Tăng hiệu năng với 4GL Bức tranh không phải toàn màu hồng Playtex used ADF, obtained an 80 to 1 productivity increase over COBOL o However, Playtex then used COBOL for later applications 4GL productivity increases of 10 to 1 over COBOL have been reported o Tuy nhiên, có quá nhiều bản tường trình của những thử nghiệm tồi Những thử nghiệm thực tế với 4GL Nhiều ngôn ngữ thế hệ thứ tư được hỗ trợ bởi môi trường CASE mạnh mẽ o Đây là một vấn đề đối với những tổ chức ở mức CMM 1 hoặc 2 o Một vài thất bại của ngôn ngữ thế thế thứ 4 được ghi lại là do môi trường CASE vật lý Quan điểm của 43 tổ chức đối với 4GLs o Việc sử dụng 4GL đã giảm sự thất vọng của người dùng o Đáp ứng nhanh hơn từ bộ phận DP (Quicker response from DP department ) o 4GLs are slow and inefficient, on average o Nhìn chung, 28 tổ chức sử dụng 4GL trong 3 năm thấy lợi nhuận thu được vượt quá chi phí bỏ ra Những nguy hiểm với ngôn ngữ thứ tư End-user programming o Những người lập trình được đào tạo để nghi ngờ các đầu ra của máy tính ( Programmers are taught to mistrust computer output) o Những dùng cuối được dạy để tin tưởng vào đầu ra của máy tính (End users are taught to believe computer output) o Người dùng cuối đang cập nhật cơ sở dữ liệu có thể đặc biệt nguy hiểm (An end- user updating a databasePTIT can be particularly dangerous) Những nguy hiểm tiềm năng đối với quản lý (Potential pitfalls for management) o Trường hợp giới thiệu sớm môi trường CASE (Premature introduction of a CASE environment) o Đào tạo không đủ đối với độ phát triển (Providing insufficient training for the development team) o Chọn 4GL sai 10.1.1.3 Lập trình tốt trong thực tế (Good Programming Practice) Sử dụng tên biến nhất quán và có ý nghĩa o “Có ý nghĩa” để những người lập trình bảo trì trong tương lai o “Nhất quán” để trợ giúp cho những người bảo trì trong tương lai o Tài liệu mã bao gồm tên các biến như freqAverage, frequencyMaximum, minFr, frqncyTotl o Người lập trình bảo trì phải biết nếu freq, frequency, fr, frqncy đều liên quan đến cùng một thứ 138
Chương 10: Pha cài đặt và tích hợp . Nếu sử dụng từ đồng nhất, tốt nhất là frequency, có thể freq hoặc frqncy, không thể fr . Nếu không sử dụng một từ khác (như: rate) cho một số lượng khác o Chúng ta có thể sử dụng frequencyAverage, frequencyMaximum, frequencyMinimum, frequencyTotal o Chúng ta cũng có thể sử dụng averageFrequency, maximumFrequency, minimumFrequency, totalFrequency o Nhưng bốn tên phải xuất phát cùng một tập Vấn đề của Self-Documenting Code o Self-documenting code cực kỳ hiếm o Vấn đề chính: tài liệu mã có thể được hiểu một cách dễ dàng và không nhập nhằng bởi: . Đội SQA . Những người lập trình bảo trì . Những người khác đọc mã o Ví dụ: . Tài liệu mã bao gồm biến xCoordinateOfPositionOfRobotArm . Biến này được viết tắt là xCoord . Biến này rất tốt, bởi vì toàn bộ mô đun xử lý sự di chuyển của cánh tay rô bốt . Nhưng người lập trình bảo trì có biết điều này không? o Những lời giải thích PTITmở đầu tối thiểu cho một tài liệu viết mã artifact 139
Chương 10: Pha cài đặt và tích hợp o Những đề nghị (Suggestion): Những lời giải thích là cần thiết khi mã được viết theo cách không rõ ràng hoặc cách sử dụng một khía cạnh tinh tế nào đó của ngôn ngữ o Lời giải thích vô nghĩa (Nonsense): Viết lại mã theo cách rõ ràng hơn, chúng ta không bao giờ thúc đẩy/bỏ qua việc lập trình tồi. Tuy nhiên, những lời giải thích có thể trợ giúp những người lập trình bảo trì trong tương lai o Việc sử dụng các tham số o Gần như không có những hằng số thực o Một giải pháp: . Sử dụng câu lệnh const (C++), hoặc . Sử dụng câu lệnh public static final (Java) o Một cách tốt hơn: . Đọc những giá trị “hằng số” từ tệp tham số Việc bố trí mã để tăng khả năng có thể đọc được o Sử dụng thụt đầu dòng o Tốt hơn, sử dụng (Better, use a pretty-printer) o Sử dụng nhiều dòng trống . Để tách những khối lệnh lớn (To break up big blocks of code) Câu lệnh if lồng o Ví dụ: Một bản đồ bao gồm hai hình vuông. Viết mã để xác định liệu một điểm nằm trên bề mặt trái đất nằm trong map_square_1 hoặc map_square_2, hoặc không nằm trong hìnhPTIT vuông nào 140
Chương 10: Pha cài đặt và tích hợp o Giải pháp 1: Được định dạng tồi o Định dạng tốt, được cấu trúc tồi o Cấu trúc lồng được chấp nhận o Sự kết hợp của câu lệnh if-if và if-else-if thường rất khó đọc o Đơn giản: Sự kết hợp if-if if PTITif tương đương với điều kiện đơn if && o Quy luật ngón tay cái (Rule of thumb) : Câu lệnh if được lồng lớn hơn ba lần nên tránh vì đó là cách lập trình tồi 10.1.1.4 Những chuẩn lập trình Standards can be both a blessing and a curse Những mô đun có độ kết dính ngẫu nhiên (coincidental cohesion) sinh ra từ các luật giống như: o “Mỗi mô đun sẽ bao gồm 35 và 50 câu lệnh có thể thực thi được” Tốt hơn o “Những người lập trình nên hỏi ý kiến những người quản lý của họ trước khi xây dựng một mô đun với ít hơn 35 hoặc nhiều hơn 50 câu lệnh có thể thực thi được” Nhận xét: Chưa từng có một chuẩn nào được chấp nhận phổ biến 141
Chương 10: Pha cài đặt và tích hợp Các chuẩn đã áp đặt từ bên trên sẽ được bỏ qua Các chuẩn có thể kiểm tra bằng máy Mục đích của chuẩn là để bảo trì dễ dàng o Nếu các chuẩn làm cho việc phát triển gặp khó khăn, thì chúng phải được chỉnh sửa o Những chuẩn giới hạn quá mức phản tác dụng (Overly restrictive standards are counterproductive) o Chất lượng phần mềm có áp dụng các chuẩn (The quality of software suffers) Ví dụ của chuẩn lập trình tốt “Việc xếp lồng vào nhau các câu lệnh if skhông nên vượt quá 3 lần, ngoại trừ được phê chuẩn trước từ đội trưởng” “Các mô đun gồm từ 35 đến 50 câu lệnh, ngoại trừ có sự phê chuẩn từ trước của đội trưởng” “Sử dụng câu lệnh goto nên tránh. Tuy nhiên, với sự phê chuẩn từ trước của đội trưởng, lệnh goto có thể được sử dụng để xử lý lỗi” 10.1.1.5 Sử dụng lại mã Sử dụng lại mã là một dạng sử dụng lại phổ biến nhất Tuy nhiên, tài liệu của tất cả các luồng công việc có thể được sử dụng lại 10.1.1.6 Công cụ CASE cho cài đặt Công cụ CASE sử dụng cho tích hợp gồm o Công cụ điều khiển phiên bản, công cụ điều khiển cấu hình, và công cụ xây dựng o Ví dụ: . rcs, sccs, PCVS, SourceSafe Công cụ điều khiển cấu hìnhPTIT o Mang tính thươngmại . PCVS, SourceSafe o Mã nguồn mở . CVS Các công cụ CASE cho tiến tình phần mềm hoàn thiện Một tổ chức lớn cần một môi trường Một tổ chức với cỡ trung bình có thể quản lý sử dụng workbench (A medium-sized organization can probably manage with a workbench) Một tổ chức nhỏ có thể quản lý mà chỉ sử dụng các công cụ Môi trường phát triển đã tích hợp Ý nghĩa của từ “tích hợp” o Tích hợp giao diện người dùng o Tương tự “nhìn và cảm nhận” o Thành công nhất trên hệ điều hành Macintosh Cũng có các kiểu tích hợp khác 142
Chương 10: Pha cài đặt và tích hợp Tích hợp công cụ o Tất cả các công cụ giao tiếp sử dụng cùng một định dạng o Ví dụ: . Unix Programmer’s Workbench Tích hợp tiến trình o Môi trường hỗ trợ một tiến trình riêng biệt o Tập con: Môi trường dựa trên kỹ thuật . Trước đây: “môi trường dựa trên phương thức” . Hỗ trợ một kỹ thuật riêng biệt hơn là một tiến trình hoàn thiện . Môi trường của các kỹ thuật là:Phân tích hệ thống trúc (Structured systems analysis) và Petri nets Môi trường dựa trên kỹ thuật o Đồ họa hỗ trợ cho phân tích, thiết kế o Từ điển dữ liệu o Việc vài kiểm tra tính nhất quán o Hỗ trợ quản lý o Hỗ trợ và hình thức hóa tiến trình bằng tay o Ví dụ: . Analyst/Designer . Software through Pictures . IBM Rational Rose . Rhapsody (for Statecharts) o Thuận lợi: . Người dùng épPTIT buộc phải sử dụng một phương pháp cụ thể, chính xác o Bất lợi: . Người dùng bị ép buộc sử dụng một phương thức cụ thể, vì thế phương thức đó phải là một phần của tiến trình phần mềm của tổ chức đó (The user is forced to use one specific method, so that the method must be part of the software process of that organization) Môi trường của các ứng dụng doanh nghiệp Nhấn mạnh tính dễ dàng khi sử dụng bao gồm o Bộ sinh giao diện người dùng thân thiện o Chuẩn màn hình cho đầu vào và đầu ra, và o Bộ sinh mã . Thiết kế chi tiết là mức thấp nhất của trừu tượng . Thiết kế chi tiết là đầu vào của bộ sinh mã Việc sử dụng ngôn ngữ lập trình này làm tăng hiệu năng 143
Chương 10: Pha cài đặt và tích hợp Ví dụ: Oracle Development Suite PCTE — Portable common tool environment o Không phải là một môi trường o Là một cơ sở hạ tầng để trợ giúp công cụ CASE (tương tự với cách hệ điều hành cung cấp các dịch vụ cho các sản phẩm phần mềm người dùng) o Được chấp nhận bởi ECMA (European Computer Manufacturers Association) Ví dụ sự cài đặt: o IBM, Emeraude Những vấn đề xảy ra với môi trường Không có môi trường lý tưởng cho tất cả các tổ chức o Mỗi môi trường có điểm mạnh điểm yếu Cảnh báo 1 o Chọn môi trường sai có thể tồi hơn khi không có môi trường o Ép buộc kỹ thuật sai là phản tác dụng Cảnh báo 2 o Những môi trường Shun CASE dưới mức 3 CMM o Không thể tự động hóa một tiến trình không tồn tại o Tuy nhiên, công cụ CASE hoặc workbench CASE là rất tốt Năm thước đo cơ bản cùng với o Thước đo độ phức tạp Thống kê lỗi là quan trọng o Số lượng trường hợp kiểm thử o Phần trăm trường hợp kiểm thử sinh ra lỗi o Tổng số lượng lỗi PTIT Dữ liệu lỗi được hợp nhất với danh sách kiểm tra (checklist) đối với quá trình kiểm tra kỹ lưỡng mã 10.1.1.7 Thước đo của luồng công việc cài đặt Năm thước đo cơ bản cùng với o Thước đo độ phức tạp Thống kê lỗi là quan trọng o Số lượng trường hợp kiểm thử o Phần trăm trường hợp kiểm thử sinh ra lỗi o Tổng số lượng lỗi Dữ liệu lỗi được hợp nhất với danh sách kiểm tra (checklist) đối với quá trình kiểm tra kỹ lưỡng mã 10.1.1.8 Những thách thức của luồng công việc cài đặt Những vấn đề quản lý có ý nghĩa lớn ở đây o Các công cụ CASE thích hợp 144
Chương 10: Pha cài đặt và tích hợp o Lập kế hoạch kiểm thử o Truyền đạt những thay đổi tới tất cả nhân viên o Quyết định khi nào dừng kiểm thử Sử dụng lại mã cần được đưa vào phần mềm từ lúc băt đầu o Sử dụng lại phải là yêu cầu của khách hàng o Kế hoạch quản lý dự án phần mềm phải hợp nhất với việc sử dụng lại Cài đặt dễ hiểu về mặt kỹ thuật o Những thử thách trong việc quản lý 10.1.2 Tích hợp Cho đến tận bây giờ phương pháp phổ biến là: o Tích hợp theo sau tích hợp Đây là phương pháp tồi Tốt hơn: o Kết hợp giữa cài đặt và tích Sản phẩm phần mềm với 13 mô đun PTIT Cài đặt sau đó tích hợp o Viết mã và kiểm thử tài liệu viết mã là tách biệt o Liên kết 13 tài liệu với nhau, kiểm thử toàn bộ phần mềm Driver và stub o Để kiểm thử tài liệu a, các tài liệu b,c,d phải trở thành những stub . Một tài liệu trống hoặc . In ra một thông báo ("Procedure radarCalc called"), hoặc . Trả lại một phần giá trị từ các trường hợp kiểm thửu đã được lập kế hoạch 145