Luận văn thạc sĩ VNU UET chuyển ngôn ngữ trong biểu diễn yêu cầu phần mềm

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ NGUYỄN THỊ HUYỀN TRANG CHUYỂN NGÔN NGỮ TRONG BIỂU DIỄN YÊU CẦU PHẦN MỀM LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN HÀ NỘI - 2013 LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ NGUYỄN THỊ HUYỀN TRANG CHUYỂN NGÔN NGỮ TRONG BIỂU DIỄN YÊU CẦU PHẦN MỀM Ngành: Công nghệ thông tin Chuyên ngành: Công nghệ phần mềm Mã số: 60.48.10 LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS TS Trương Ninh Thuận HÀ NỘI – 2013 LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com MỤC LỤC DANH MỤC CÁC TỪ VIẾT TẮT VÀ THUẬT NGỮ DANH MỤC HÌNH ẢNH DANH MỤC BẢNG BIỂU Chương I: Tổng quan 1.1 Đặt vấn đề 1.2 Tổng quan tình hình nghiên cứu 1.2.1 Mẫu yêu cầu 1.2.2 Mẫu đặc tả 10 1.2.3 Luật mô tả yêu cầu (SPS) 12 1.2.4 PROPEL - Công cụ hỗ trợ xác định yêu cầu 15 Chương II: Phương pháp chuyển ngôn ngữ 18 2.1 Phương pháp chuyển đổi 18 2.1.1 Mô tả yêu cầu thiết kế lập trình hướng đối tượng 18 2.1.2 Phương pháp chuyển đổi 18 2.2 Tinh chỉnh yêu cầu 19 2.3 Xác định kiện 19 2.3.1 Cặp kiện/trạng thái bắt đầu kết thúc 19 2.3.2 Sự kiện đơn 20 2.3.3 Sự kiện sau tinh chỉnh 20 2.4 Xây dựng bảng hỏi 20 2.4.1 Bảng hỏi PROPEL 20 2.4.2 Bảng hỏi dành cho SPSC (SPSCQT) 23 2.4.3 Bảng thống kê tương ứng SPSCQT SPSC 26 Chương III: Áp dụng mở rộng SPSC 34 3.1 Phần mềm hỗ trợ 34 3.1.1 Chức phần mềm 34 3.1.2 Thiết kế khả mở rộng 38 LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com 3.2 Sử dụng SPSC để mô tả yêu cầu 40 3.2.1 Bộ yêu cầu chức 40 3.2.2 Bộ yêu cầu phi chức 47 3.3 Kết áp dụng mở rộng SPSC 50 3.3.1 Kết áp dụng 50 3.3.2 Các luật mở rộng SPSC 50 Chương IV: Kết luận 52 4.1 Kết nghiên cứu 52 4.2 Hướng nghiên cứu tiếp tục 52 TÀI LIỆU THAM KHẢO 54 Phụ lục 1: Mẫu yêu cầu “Living Entity Requirement Pattern” 56 Phụ lục 2: Course Registration Requirements 62 LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com DANH MỤC CÁC TỪ VIẾT TẮT VÀ THUẬT NGỮ TT Từ viết tắt/Thuật ngữ RP Mẫu yêu cầu Requirement Pattern SPS Hệ thống luật mô tả Specification Pattern System SPSKC Hệ thống luật mô tả (SPS) đề xuất Konrad Cheng SPSG Hệ thống luật mô tả (SPS) đề xuất Grunske (giúp mô tả yêu cầu liên quan đến xác xuất) SPSC Hệ thống luật mô tả kết hợp SPSKC, SPSG SPS xác suất nhóm nghiên cứu BOSCH LTL Linear Time Logic CTL Computational Tree Logic GIL Graphical Interval Logic MTL Metric Temporal Logic 10 TCTL Timed Computational Tree Logic 11 RTGIL Real-time Graphical Interval Logic 12 NL 13 14 Giải thích/Định nghĩa Ghi Ngơn ngữ tự nhiên Natural language PROPEL Công cụ hướng dẫn người dùng xác định yêu cầu PROPerty ELuciator SPSCQT Bảng hỏi dành cho SPSC SPSC Question Tree LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com DANH MỤC HÌNH ẢNH Hình 1.1: Phân chia mẫu yêu cầu Dywer [7] 11 Hình 1.2: SPS xây dựng Konrad Cheng [2] 12 Hình 1.3: SPS xây dựng Grunske [6] 14 Hình 1.4: Bốn mô tả xử lý PROPEL [4] 16 Hình 1.5: Ví dụ bảng hỏi PROPEL [4] 16 Hình 1.6: Giao diện FSA PROPEL [4] 17 Hình 2.1: Bảng hỏi hồn chỉnh cho mơ tả xử lý PROPEL [4] 21 Hình 2.2: Bảng hỏi hồn chỉnh cho mơ tả phạm vi PROPEL [4] 22 Hình 2.3: Bảng hỏi SPSCQT - phần 26 Hình 2.4: Bảng hỏi SPSCQT - phần 27 Hình 2.5: Bảng hỏi SPSCQT - phần 28 Hình 2.6: Bảng hỏi SPSCQT - phần 29 Hình 2.7: Mơ tả tương ứng SPSC - Phần 30 Hình 2.8: Mơ tả tương ứng SPSC - Phần 31 Hình 2.9: Mơ tả tương ứng SPSC - Phần 32 Hình 2.10: Mơ tả tương ứng SPSC - Phần 33 Hình 3.1: Trang chủ phần mềm hỗ trợ 34 Hình 3.2: Giao diện thêm/sửa/xóa u cầu 34 Hình 3.3: Giao diện xem chi tiết yêu cầu 35 Hình 3.4: Giao diện chỉnh sửa mơ tả yêu cầu ngôn ngữ tự nhiên 35 Hình 3.5: Giao diện câu hỏi mơ tả phạm vi 36 Hình 3.6: Giao diện trả kết phạm vi 36 Hình 3.7: Giao diện câu hỏi mô tả xử lý 36 Hình 3.8: Giao diện nhập tên kiện 37 Hình 3.9: Giao diện câu hỏi mối quan hệ kiện 37 Hình 3.10: Giao diện kết chuyển đổi sang SPSC 38 Hình 3.11: File văn xuất từ phần mềm 38 LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com DANH MỤC BẢNG BIỂU Bảng 1.1: Phân loại mẫu yêu cầu Withall Bảng 1.2: Cấu trúc chuẩn cho mẫu yêu cầu Bảng 2.1: Bảng hỏi phân biệt u cầu có/khơng có tính xác suất 23 Bảng 2.2: Bảng hỏi dành cho xử lý 01 kiện 23 Bảng 2.3: Bảng hỏi dành cho xử lý 02 kiện 24 Bảng 2.4: Bảng hỏi dành cho xử lý 03 kiện 24 Bảng 2.5: Bảng hỏi dành cho xử lý 04 kiện 25 Bảng 3.1: Cấu trúc file XML bảng hỏi 39 Bảng 3.2: Chi tiết hóa luật "bounded existence" 50 Bảng 3.3: Bổ sung luật "simutaneously response" 51 LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com 1 Chương I: Tổng quan 1.1 Đặt vấn đề Yêu cầu phần mềm thường mô tả ngôn ngữ tự nhiên vốn coi nhập nhằng, thiếu tính rõ ràng Các phương pháp hình thức lại cho phép kiểm chứng yêu cầu chúng mô tả ngơn ngữ hình thức vốn coi khó hiểu nhóm phát triển (bao gồm người thiết kế, lập trình viên, người kiểm thử,…) Để giải vấn đề nêu trên, Konrad Cheng [12] đưa hệ thống luật mô tả (SPSKC) xây dựng số lượng giới hạn từ vựng cấu trúc tiếng anh SPSKC giúp ghi lại yêu cầu chức ngôn ngữ tập ngơn ngữ tự nhiên (tiếng anh) mà lại dịch tự động sang logic hình thức Tuy nhiên, SPSKC lại gặp vấn đề không mô tả yêu cầu phi chức Để bổ sung điểm yếu này, kết hợp thêm với hệ thống luật mô tả đưa Grunske L (SKSG) [6] Năm 2012, nhóm nghiên cứu BOSCH nhóm nghiên đại học Freiburg [2] kết hợp để kiểm chứng lại SPSKC phạm vi đặc biệt (công nghiệp tơ), phần phân tích họ cho hữu ích xem xét việc mở rộng SPSKC cách bổ sung thêm SPSG để thể yêu cầu phi chức Một vấn đề khác nghiên cứu không mô tả cách thức chuyển từ yêu cầu phần mềm ngôn ngữ tự nhiên sang mô tả SPS công bố Việc mô tả rõ phương pháp chuyển đổi việc vơ cần thiết để khẳng định q trình chuyển đổi có thực xác hay khơng, để đánh giá kết chuyển đổi có đáng tin hay khơng Từ nghiên cứu nói trên, luận văn đặt hai mục tiêu cần giải quyết: - Sự kết hợp SPSKC SPSG thành SPS kết hợp (sau gọi SPSC) có đầy đủ để mơ tả yêu cầu phần mềm hay khơng - Cần có quy tắc để chuyển đổi từ ngôn ngữ tự nhiên sang SPSC tránh sai sót giảm cơng sức người thực Bộ mẫu sử dụng để kiểm chứng vấn đề ví dụ mẫu cho phân tích yêu cầu tập tài liệu hướng dẫn “IBM rational software - Section 1: Course Registration Requirements” [8], với giả định yêu cầu đủ rõ ràng bao quát LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com Công cụ hỗ trợ chuyển yêu cầu từ ngôn ngữ tự nhiên sang SPSC xây dựng dựa ý tưởng dùng bảng hỏi phương pháp PROPEL (PROPerty ELucidation approach) trình bày luận án tiến sĩ Rachel L.Cobleigh [4] 1.2 Tổng quan tình hình nghiên cứu Quá trình phát triển phần mềm thường gồm nhiều giai đoạn gồm cơng việc phân tích u cầu, thiết kế hệ thống, lập trình sản phẩm, kiểm thử phát hành tới khách hàng Trước đây, dự án thất bại (số tiền/thời gian thực vượt kế hoạch ban đầu, sản phẩm nhiều lỗi,…), số người thường nghĩ lỗi q trình lập trình sản phẩm, thực tế khơng phải Robert N [3] thống kê 12 lỗi khiến cho dự án phần mềm thất bại IEEE Spectrum inside technology, có nguyên nhân liên quan trực tiếp đến kỹ thuật “khơng xác định xác u cầu phần mềm, sử dụng cơng nghệ chưa hồn chỉnh kỹ lập trình kém” Nghĩa là, xét mặt kỹ thuật việc xác định xác u cầu phần mềm quan trọng không việc lựa chọn công nghệ nâng cao kỹ lập trình Chính lý đó, sau thời gian dài tập trung vào xây dựng lý thuyết, công cụ để hỗ trợ lập trình, phát lỗi sửa lỗi lập trình, chuyên gia phần mềm bắt đầu quan tâm đến việc nâng cao chất lượng phân tích yêu cầu phần mềm Q trình nâng cao chất lượng phân tích yêu cầu bắt đầu việc cố gắng đưa định nghĩa mô tả yêu cầu tốt Trong sách “Software Engineering” xuất năm 2003, Karl E Wiegers [9] cho rằng: “Một mô tả yêu cầu tốt đảm bảo đầy đủ tiêu chí sau: hồn thiện, xác, thực hóa, cần thiết, khơng nhập nhằng, kiểm thử đánh giá mức độ quan trọng” Dựa đó, ơng đề xuất số mẫu (template) tài liệu phân tích yêu cầu đưa hướng dẫn viết mơ tả u cầu như: viết câu hồn chỉnh, sử dụng thể chủ động, sử dụng từ khóa định nghĩa, sử dụng hình ảnh bổ sung để mô tả yêu cầu… 1.2.1 Mẫu yêu cầu Mặc dù Karl E Wiegers [9] đưa hướng dẫn trực quan với ví dụ rõ ràng, chúng khái quát, chưa cụ thể đủ để áp dụng LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com trường hợp thực tế Do đó, chất lượng tài liệu mô tả yêu cầu phụ thuộc hoàn toàn vào khả kinh nghiệm thân người phân tích yêu cầu Để giải vấn đề này, chuyên gia đưa “mẫu yêu cầu” Mỗi mẫu yêu cầu (RP - requirement pattern) hướng dẫn cách mô tả loại yêu cầu định Theo Stephen Withall [11]: “Ý tưởng RP cung cấp hướng dẫn cách xác định yêu cầu cho số nhóm yêu cầu phổ biến, giúp việc viết mô tả yêu cầu trở nên nhanh, dễ dàng, có chất lượng tốt hơn” Ơng đưa 37 RPs mô tả 37 loại yêu cầu mà ông cho phổ biến (được nhóm lại thành nhóm) Bảng 1.1 Mẫu yêu cầu “Living entity RP” thuộc nhóm “Data Entity” Bảng 1.1 mô tả phụ lục Bảng 1.1: Phân loại mẫu yêu cầu Withall STT Tên nhóm Tên mẫu yêu cầu Yêu cầu Công nghệ (technology) (Fundamental) Tiêu chuẩn (comply with standard) Chỉ đến yêu cầu (refer to requirements) Tài liệu (documentation) Giao diện liên kết hệ thống (inter-system interface) Tương tác hệ thống (inter-system interaction) Thông tin Kiểu liệu (data type) (Information) Định danh (ID) Cấu trúc liệu (data structure) Hàm tính tốn (calculation formula) LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com The desktop user-interface shall be Windows 95/98 compliant 3.6 Reliability The system shall be available 24 hours a day days a week, with no more than 10% down time 3.7 Performance The system shall support up to 2000 simultaneous users against the central database at any given time, and up to 500 simultaneous users against the local servers at any one time The system shall provide access to the legacy course catalog database with no more than a 10 second latency Note: Risk-based prototypes have found that the legacy course catalog database cannot meet our performance needs without some creative use of midtier processing power The system must be able to complete 80% of all transactions within minutes 3.8 Supportability None 3.9 Security The system must prevent students from changing any schedules other than their own, and professors from modifying assigned course offerings for other professors Only Professors can enter grades for students Only the Registrar is allowed to change any student information 3.10 Design Constraints The system shall integrate with an existing legacy system, the Course Catalog System, which is an RDBMS database The system shall provide a Windows-based desktop interface Use-Case Model Course Registration System Use-Case Model Main Diagram 65 LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com 4.1 Close Registration 4.1.1 Brief Description This use case allows a Registrar to close the registration process Course offerings that not have enough students are cancelled Course offerings must have a minimum of three students in them The billing system is notified for each student in each course offering that is not cancelled, so the student can be billed for the course offering 4.1.2 Flow of Events  Basic Flow This use case starts when the Registrar requests that the system close registration The system checks to see if registration is in progress If it is, then a message is displayed to the Registrar, and the use case terminates The Close Registration processing cannot be performed if registration is in progress 66 LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com For each course offering, the system checks if a professor has signed up to teach the course offering and at least three students have registered If so, the system commits the course offering for each schedule that contains it For each schedule, the system “levels” the schedule: if the schedule does not have the maximum number of primary courses selected, the system attempts to select alternates from the schedule‟s list of alternates The first available alternate course offerings will be selected If no alternates are available, then no substitution will be made For each course offering, the system closes all course offerings If the course offerings not have at least three students at this point (some may have been added as a result of leveling), then the system cancels the course offering The system cancels the course offering for each schedule that contains it The system calculates the tuition owed by each student for his current semester schedule and sends a transaction to the Billing System The Billing System will send the bill to the students, which will include a copy of their final schedule  Alternative Flows No Professor for the Course Offering If, in the Basic Flow, there is no professor signed up to teach the course offering, the system will cancel the course offering The system cancels the course offering for each schedule that contains it Billing System Unavailable If the system is unable to communicate with the Billing System, the system will attempt to re-send the request after a specified period The system will continue to attempt to re-send until the Billing System becomes available  Special Requirements None  Pre-Conditions The Registrar must be logged onto the system in order for this use case to begin  Post-Conditions If the use case was successful, registration is now closed If not, the system state remains unchanged 67 LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com  Extension Points None 4.2 Login 4.2.1 Brief Description This use case describes how a user logs into the Course Registration System 4.2.2 Flow of Events  Basic Flow This use case starts when the actor wishes to log into the Course Registration System The actor enters his/her name and password The system validates the entered name and password and logs the actor into the system  Alternative Flows Invalid Name/Password If, in the Basic Flow, the actor enters an invalid name and/or password, the system displays an error message The actor can choose to either return to the beginning of the Basic Flow or cancel the login, at which point the use case ends  Special Requirements None  Pre-Conditions The system is in the login state and has the login screen displayed  Post-Conditions If the use case was successful, the actor is now logged into the system If not, the system state is unchanged Extension Points None 4.3 Maintain Professor Information 4.3.1 Brief Description 68 LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com This use case allows the Registrar to maintain professor information in the registration system This includes adding, modifying, and deleting professors from the system 4.3.2 Flow of Events * Basic Flow This use case starts when the Registrar wishes to add, change, and/or delete professor information in the system The system requests that the Registrar specify the function he/she would like to perform (either Add a Professor, Update a Professor, or Delete a Professor) Once the Registrar provides the requested information, one of the sub flows is executed If the Registrar selected “Add a Professor”, the Add a Professor subflow is executed If the Registrar selected “Update a Professor”, the Update a Professor subflow is executed If the Registrar selected “Delete a Professor”, the Delete a Professor subflow is executed - Add a Professor: The system requests that the Registrar enter the professor information This includes: name, date of birth, social security number, status, department Once the Registrar provides the requested information, the system generates and assigns a unique id number to the professor The professor is added to the system The system provides the Registrar with the new professor id - Update a Professor The system requests that the Registrar enter the professor id The Registrar enters the professor id The system retrieves and displays the professor information The Registrar makes the desired changes to the professor information This includes any of the information specified in the Add a Professor sub-flow Once the Registrar updates the necessary information, the system updates the professor record 69 LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com - Delete a Professor The system requests that the Registrar enter the professor id The Registrar enters the professor id The system retrieves and displays the professor information The system prompts the Registrar to confirm the deletion of the professor The Registrar verifies the deletion The system deletes the professor from the system  Alternative Flows Professor Not Found If, in the Update a Professor or Delete a Professor sub-flows, a professor with the specified id number does not exist, the system displays an error message The Registrar can then enter a different id number or cancel the operation, at which point the use case ends Delete Cancelled If, in the Delete A Professor sub-flow, the Registrar decides not to delete the professor, the delete is cancelled, and the Basic Flow is re-started at the beginning  Special Requirements None  Pre-Conditions The Registrar must be logged onto the system before this use case begins  Post-Conditions If the use case was successful, the professor information is added, updated, or deleted from the system Otherwise, the system state is unchanged  Extension Points None 4.4 Maintain Student Information 4.4.1 Brief Description This use case allows the Registrar to maintain student information in the registration system This includes adding, modifying, and deleting Students from the system 70 LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com 4.4.2 Flow of Events  Basic Flow This use case starts when the Registrar wishes to add, change, and/or delete student information in the system The system requests that the Registrar specify the function he/she would like to perform (either Add a Student, Update a Student, or Delete a Student) Once the Registrar provides the requested information, one of the sub flows is executed If the Registrar selected “Add a Student”, the Add a Student subflow is executed If the Registrar selected “Update a Student”, the Update a Student subflow is executed If the Registrar selected “Delete a Student”, the Delete a Student subflow is executed - Add a Student The system requests that the Registrar enter the student information This includes: name, date of birth, social security number, status, graduation date Once the Registrar provides the requested information, the system generates and assigns a unique id number to the student The student is added to the system The system provides the Registrar with the new student id - Update a Student The system requests that the Registrar enter the student id The Registrar enters the student id The system retrieves and displays the student information The Registrar makes the desired changes to the student information This includes any of the information specified in the Add a Student sub-flow Once the Registrar updates the necessary information, the system updates the student information - Delete a Student The system requests that the Registrar enter the student id The Registrar enters the student id The system retrieves and displays the student information 71 LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com The system prompts the Registrar to confirm the deletion of the student The Registrar verifies the deletion The system deletes the student from the system  Alternative Flows - Student Not Found If, in the Update a Student or Delete a Student sub-flows, a student with the specified id number does not exist, the system displays an error message The Registrar can then enter a different id number or cancel the operation, at which point the use case ends - Delete Cancelled If, in the Delete A Student sub-flow, the Registrar decides not to delete the student, the delete is cancelled and the Basic Flow is re-started at the beginning  Special Requirements None  Pre-Conditions The Registrar must be logged onto the system before this use case begins  Post-Conditions If the use case was successful, the student information is added, updated, or deleted from the system Otherwise, the system state is unchanged  Extension Points None 4.5 Register for Courses 4.5.1 Brief Description This use case allows a Student to register for course offerings in the current semester The Student can also update or delete course selections if changes are made within the add/drop period at the beginning of the semester The Course Catalog System provides a list of all the course offerings for the current semester 4.5.2 Flow of Events  Basic Flow 72 LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com This use case starts when a Student wishes to register for course offerings, or to change his/her existing course schedule The Student provides the function to perform (one of the sub flows is executed): If the Student selected “Create a Schedule”, the Create a Schedule subflow is executed If the Student selected “Update a Schedule”, the Update a Schedule subflow is executed If the Student selected “Delete a Schedule”, the Delete a Schedule subflow is executed - Create a Schedule The system retrieves a list of available course offerings from the Course Catalog System and displays the list to the Student The Select Offerings subflow is executed The Submit Schedule subflow is executed - Update a Schedule The system retrieves and displays the Student‟s current schedule (e.g., the schedule for the current semester) The system retrieves a list of available course offerings from the Course Catalog System and displays the list to the Student The Student may update the course selections on the current selection by deleting and adding new course offerings The Student selects the course offerings to add from the list of available course offerings The Student also selects any course offerings to delete from the existing schedule Once the student has made his/her selections, the system updates the schedule for the Student using the selected course offerings The Submit Schedule subflow is executed - Delete a Schedule The system retrieves and displays the Student‟s current schedule (e.g., the schedule for the current semester) The system prompts the Student to confirm the deletion of the schedule The Student verifies the deletion The system deletes the Schedule If the schedule contains “enrolled in” course offerings, the Student must be removed from the course offering 73 LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com - Select Offerings The Student selects primary course offerings and alternate course offerings from the list of available offerings Once the student has made his/her selections, the system creates a schedule for the Student containing the selected course offerings - Submit Schedule For each selected course offering on the schedule not already marked as “enrolled in”, the system verifies that the Student has the necessary prerequisites, that the course offering is open, and that there are no schedule conflicts The system then adds the Student to the selected course offering The course offering is marked as “enrolled in” in the schedule The schedule is saved in the system  Alternative Flows - Save a Schedule At any point, the Student may choose to save a schedule rather than submitting it If this occurs, the Submit Schedule step is replaced with the following: The course offerings not marked as “enrolled in” are marked as “selected” in the schedule The schedule is saved in the system Unfulfilled Prerequisites, Course Full, or Schedule Conflicts If, in the Submit Schedule sub-flow, the system determines that the Student has not satisfied the necessary prerequisites, or that the selected course offering is full, or that there are schedule conflicts, an error message is displayed The Student can either select a different course offering and the use case continues, save the schedule, as is (see Save a Schedule subflow), or cancel the operation, at which point the Basic Flow is re-started at the beginning - No Schedule Found If, in the Update a Schedule or Delete a Schedule sub-flows, the system is unable to retrieve the Student‟s schedule, an error message is displayed The Student acknowledges the error, and the Basic Flow is re- started at the beginning - Course Catalog System Unavailable 74 LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com If the system is unable to communicate with the Course Catalog System, the system will display an error message to the Student The Student acknowledges the error message, and the use case terminates - Course Registration Closed When the use case starts, if it is determined that registration for the current semester has been closed, a message is displayed to the Student, and the use case terminates Students cannot register for course offerings after registration for the current semester has been closed - Delete Cancelled If, in the Delete A Schedule sub-flow, the Student decides not to delete the schedule, the delete is cancelled, and the Basic Flow is re-started at the beginning  Special Requirements None  Pre-Conditions The Student must be logged onto the system before this use case begins  Post-Conditions If the use case was successful, the student schedule is created, updated, or deleted Otherwise, the system state is unchanged  Extension Points None 4.6 Select Courses to Teach 4.6.1 Brief Description This use case allows a Professor to select the course offerings from the course catalog for the courses that he/she is eligible for and wishes to teach in the upcoming semester 4.6.2 Flow of Events  Basic Flow This use case starts when a Professor wishes to sign up to teach some course offerings for the upcoming semester 75 LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com 76 The system retrieves and displays the list of course offerings the professor is eligible to teach for the current semester The system also retrieves and displays the list of courses the professor has previously selected to teach The professor selects and/or de-selects the course offerings that he/she wishes to teach for the upcoming semester The system removes the professor from teaching the de-selected course offerings The system verifies that the selected offerings not conflict (i.e., have the same dates and times) with each other or any course offerings that the professor has previously signed up to teach If there is no conflict, the system updates the course offering information for each offering the professor selects (i.e., records the professor as the instructor for the course offering)  Alternative Flows - No Course Offerings Available If, in the Basic Flow, the professor is not eligible to teach any course offerings in the upcoming semester, the system will display an error message The professor acknowledges the message and the use case ends - Schedule Conflict If the systems find a schedule conflict when trying to establish the course offerings the Professor should take, the system will display an error message indicating that a schedule conflict has occurred The system will also indicate which are the conflicting courses The Professor can either resolve the schedule conflict (i.e., by canceling his selection to teach one of the course offerings), or cancel the operation, in which case, any selections will be lost, and the use case ends - Course Catalog System Unavailable If the system is unable to communicate with the Course Catalog System, the system will display an error message to the Student The Student acknowledges the error message, and the use case terminates - Course Registration Closed 76 LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com 77 When the use case starts, if it is determined that registration for the current semester has been closed, a message is displayed to the Professor, and the use case terminates Professors cannot change the course offerings they teach after registration for the current semester has been closed If a professor change is needed after registration has been closed, it is handled outside the scope of this system - Special Requirements None  Pre-Conditions The Professor must be logged onto the system before this use case begins  Post-Conditions If the use case was successful, the course offerings a Professor is scheduled to teach have been updated Otherwise, the system state is unchanged  Extension Points None 4.7 Submit Grades 4.7.1 Brief Description This use case allows a Professor to submit student grades for one or more classes completed in the previous semester 4.7.2 Flow of Events  Basic Flow This use case starts when a Professor wishes to submit student grades for one or more classes completed in the previous semester The system displays a list of course offerings the Professor taught in the previous semester The Professor selects a course offering 77 LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com 78 The system retrieves a list of all students who were registered for the course offering The system displays each student and any grade that was previously assigned for the offering For each student on the list, the Professor enters a grade: A, B, C, D, F, or I The system records the student‟s grade for the course offering If the Professor wishes to skip a particular student, the grade information can be left blank and filled in at a later time The Professor may also change the grade for a student by entering a new grade  Alternative Flows - No Course Offerings Taught If, in the Basic Flow, the Professor did not teach any course offerings in the previous semester, the system will display an error message The Professor acknowledges the message, and the use case ends  Special Requirements None  Pre-Conditions The Professor must be logged onto the system before this use case begins  Post-Conditions If the use case was successful, student grades for a course offering are updated Otherwise, the system state is unchanged  Extension Points None 4.8 View Report Card 4.8.1 Brief Description This use case allows a Student to view his/her report card for the previously completed semester 4.8.2 Flow of Events  Basic Flow 78 LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com 79 This use case starts when a Student wishes to view his/her report card for the previously completed semester The system retrieves and displays the grade information for each of the course offerings the Student completed during the previous semester When the Student indicates that he/she is done viewing the grades, the use case terminates  Alternative Flows - No Grade Information Available If, in the Basic Flow, the system cannot find any grade information from the previous semester for the Student, a message is displayed Once the Student acknowledges the message, the use case terminates  Special Requirements None  Pre-Conditions The Student must be logged onto the system before this use case begins  Post-Conditions The system state is unchanged by this use case  Extension Points None 79 LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com ... NGHỆ NGUYỄN THỊ HUYỀN TRANG CHUYỂN NGÔN NGỮ TRONG BIỂU DIỄN YÊU CẦU PHẦN MỀM Ngành: Công nghệ thông tin Chuyên ngành: Công nghệ phần mềm Mã số: 60.48.10 LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN NGƯỜI... tiết yêu cầu Khi người dùng click vào tên yêu cầu, phía bên phải hình, hệ thống đưa thơng tin tương ứng với yêu cầu đó, bao gồm: nội dung yêu cầu ngôn ngữ tự nhiên (phần “Description”), yêu cầu. .. pháp chuyển ngôn ngữ 2.1 Phương pháp chuyển đổi 2.1.1 Mô tả yêu cầu thiết kế lập trình hướng đối tượng Trong thiết kế lập trình hướng đối tượng, yêu cầu chức phần mềm mô tả dạng ngôn ngữ tự nhiên