Lecture 6: Mô hình hóa yêu cầu ppsx

Phân tích u cầu phần mềm Lecture 6: Mơ hình hóa u cầu Làm rõ khái niệm Mơ hình hóa ? Các u cầu; Hệ thống; Tư hệ thống (Systems Thinking) Vai trị Mơ hình hóa RE Tầm quan trọng mơ hình hóa Hạn chế mơ hình hóa Tổng quan ngơn ngữ mơ hình hóa Ngun tắc mơ hình hóa Trừu tượng hóa (Abstraction) Phân tách (Decomposition) Quy chiếu (Projection) Mơ-đun hóa (Modularity) Phân tích u cầu phần mềm Khái niệm : Các định nghĩa Application Domain D - domain properties R - requirements Machine Domain C - computers P - programs Một vài điểm khác biệt Domain Properties: điều luôn lĩnh vực ứng dụng Requirements: điều mong lĩnh vực ứng dụng Specification: mô tả hành vi chương trình cần thực để đáp ứng với yêu cầu Hai tiêu chí cho kiểm tra (verification) Chương trình (Program) thực máy tính (Computer) cụ thể đáp ứng với đặc tả (Specification) Đặc tả (Specification) cho thuộc tính lĩnh vực (Domain properties) thỏa mãn yêu cầu (Requirements) Hai tiêu chí cho kiểm chứng (validation) Chúng ta xem xét (và hiểu) tất yêu cầu (Requirements) quan trọng? Chúng ta xem xét (và hiểu) tất thuộc tính lĩnh vực(Domain properties) liên quan? Phân tích yêu cầu phần mềm Khái niệm : Từ hệ thống đến mơ hình Source: Adapted from Loucopoulos & Karakostas, 1995, p73 Maintains information about Needs information about Subject System Uses Information system Usage System builds contracts Development System Phân tích yêu cầu phần mềm Khái niệm : Tư hệ thống Phân tích u cầu phần mềm Mơ hMơ hình hóa Mơ hình hóa hướng dẫn suy luận Nó giúp bạn câu hỏi để hỏi Nó giúp làm rõ yêu cầu ẩn chứa i.e giúp bạn hỏi câu xác? Mơ hình hóa cung cấp đo lường cho quy trình: Việc hồn thiện mơ hình -> hồn thiện suy luận (?) i.e hồn thiện tất thành phần mơ hinh, khơng? Mơ hình hóa giúp phơi bày vấn đề Sự mâu thuẫn mơ hình dẫn đến nhiều thứ đáng quan tâm… e.g yêu cầu xung đột thực e.g nhầm lẫn thuật ngữ, phạm vi, etc e.g bất đồng đối tác Mô hình hóa giúp kiểm tra thấu hiểu bạn Lý giải mơ hình để hiểu kết Nó có đạt đặc tính mà mong muốn? Xây dựng hình ảnh mơ hình giúp quan sát/kiểm chứng u cầu Phân tích yêu cầu phần mềm RE gồm nhiều bước mơ hình hóa Source: Adapted from Jackson, 1995, p120-122 Mơ hình tốt mơ tả Nó có tượng có quan hệ chủ thể tượng Mô hình hữu ích tượng mơ hình phù hợp cách có hệ thống với tượng lĩnh vực mà cần mơ hình hóa Phân tích u cầu phần mềm “Đó mơ hình” Source: Adapted from Jackson, 1995, p124-5 Rất thường thấy rằng: Hiện tượng mơ hình không diện lĩnh vực ứng dụng Hiện tượng lĩnh vực ứng dụng khơng có mơ hình Book (1,n) author Hiện tượng khơng nắm bắt mơ hình …các tác giả “ma”… …bút danh … …nặc danh… ISBN title name DOB (0,n) Person Hiện tượng khơng Hiện tượng chung …mỗi sách có tác giả… …mỗi sách có ISBN … thực tế …khơng có hai người sinh vào ngày có tên… Một mơ hình khơng hồn hảo “Nếu đồ địa hình khơng giống nhau, tin vào địa hình” Tìm kiếm hồn hảo mơ hình khơng việc tốt cho thời gian bạn Phân tích yêu cầu phần mềm Chọn ký pháp cho việc mơ hình hóa Source: Adapted from Loucopoulos & Karakostas, 1995, p72-73 Ngôn ngữ tự nhiên Cực kỳ diễn cảm linh hoạt hữu ích cho suy diễn, lập mơ hình ký hiệu dễ đọc Khó để nắm bắt quan hệ mấu chốt Ký pháp bán hình thức Nắm cấu trúc số ngữ nghĩa UML phù hợp Có thể thực (một số) hoạt động, kiểm tra tính quán, ảnh động, etc E.g lược đồ, bảng, cấu trúc tiếng Anh, etc Gần trực quan – cho phép chuyển thơng tin cách nhanh chóng đến dạng đối tác khác Ký pháp hình thức Ngữ nghĩa xác, suy luận rộng mơ hình dựa sở tốn (e.g lý thuyết tập hợp, FSMs (finite-state machine), etc) Các mơ hình chi tiết (có thể chi tiết cần) RE hình thức khơng chấp nhận việc mơ hình hóa, điều khác với hầu hết dạng khoa học máy tính khác Phân tích yêu cầu phần mềm Mục tiêu ký pháp mơ hình hóa Source: Adapted from Loucopoulos & Karakostas, 1995, p77 Cài đặt độc lập Khơng mơ hình hiển thị kiệu, cách tổ chức bên trong, etc Tính trừu tượng Đưa khía cạnh thiết yếu e.g thứ khơng buộc phải thay đổi thường xun Tính hình thức Cú pháp khơng mơ hồ Ngữ nghĩa biểu cảm Tính kiến trúc Có thể thiết kế phần mơ hình để kiểm sốt độ phức tạp kích thước Thiết kế cần có giao tiếp dễ dàng Dễ phân tích Cho phép phân tích liệu mơ hồ, chưa đầy đủ không quán Dễ lần vết Cho phép phần tử tham chiếu Cho phép liên kết với thiết kế cài đặt, etc Tính khả thi cho mơ hình hoạt động để so sánh với thực tế Tối thiểu hóa Không dư thừa khái niệm lược đồ mô hình hóa i.e khơng chọn lựa hiển thị vấn đề khơng liên quan Phân tích u cầu phần mềm Khảo sát kỹ thuật mơ hình hóa Mơ hình hóa nghiệp vụ Mục đích & Mục tiêu Kiến trúc tổ chức Công việc & phụ thuộc Tác nhân, vai trị, dự định Mơ hình hóa thông tin & Cấu trúc thông tin Quan điểm hành vi Kịch tình Mơ hình máy trạng thái Dịng thơng tin Mơ hình hóa tổ chức: i*, SSM, ISAC Mơ hình hóa mục tiêu: KAOS, CREWS Mơ hình hóa thơng tin: E-R, Class Diagrams Phân tích cấu trúc: hành vi SADT, SSADM, JSD Phân tích hướng đối tượng: OOA, OOSE, OMT, UML Các phương pháp hình thức: SCR, RSML, Z, Larch, VDM Các yêu cầu thời gian/trình tự Mơ hình hóa chất lượng hệ thống Những ‘có thể’: Có thể sử dụng, đáng tin cậy, phát triển, an tồn, bảo mật, khả thi, tương tác,… Thỏa thuận chất lượng: QFD, win-win, AHP, Đạc tả NFRs: Timed Petri nets (mức độ thực thi) Task models (tính dễ sử dụng) Probabilistic MTTF (độ tin cậy) 10 Phân tích yêu cầu phần mềm Unified Modelling Language (UML) Phương pháp hướng đối tượng hệ thứ ba Booch, Rumbaugh & Jacobson tác giả Vẫn cịn tiến hóa Nổ lực chuẩn hóa tiến triển dạng hướng đối tượng khác Hồn tồn ký pháp Khơng có phương pháp mơ hình liên quan tới nó! Được dự định thiết kế ký pháp (một số đặc tính khơng phù hợp với RE) Đã trở thành công nghệ chuẩn Nhưng làm chủ IBM/Rational (đã bán nhiều cơng cụ dịch vụ UML) Có khung mơ hình (meta-model) chuẩn Use case diagrams Class diagrams Message sequence charts Activity diagrams State Diagrams Module Diagrams Platform diagrams 11 Phân tích u cầu phần mềm Meta-Modelling Có thể so sánh lược đồ mơ hình hóa dùng meta-models: Mỗi lược đồ nắm bắt tượng ? Cách thức soạn thảo mơ hình cần dựa theo hướng dẫn nào? Cần thực phân tích mơ hình? Ví dụ meta-model: tinh chế Mục tiêu chủ Tác nhân cài đặt gán cho Công việc tinh chế 12 Phân tích yêu cầu phần mềm Nguyên tắc mơ hình hóa Dễ dàng sửa đổi tái sử dụng Những nhà phân tích có kinh nghiệm thường sử dụng lại kinh nghiệm trước họ họ sử dụng lại thành phần (của mơ hình mà họ xây dựng trước đó) họ sử dụng lại cấu trúc (của mơ hình mà họ xây dựng trước đó) Những nhà phân tích thơng minh hoạch định cho tương lai họ tạo thành phần sử dụng lại mơ hình họ họ cấu trúc mơ hình họ để chúng dễ dàng sửa đổi Các ý niệm hữu ích: Trừu tượng hóa (Abstraction) : Tháo bỏ chi tiết để tập trung vào thứ quan trọng Phân tách (Partitioning) : Phân chia vấn đề thành phần độc lập, để khảo sát riêng biệt Quy chiếu (Projection) : Phân chia khía cạnh (views) khác mơ tả chúng cách riêng biệt Mơ-đun hóa (Modularization) : Chọn lựa cấu trúc ổn định theo thời gian để dễ định vị thay đổi Mẫu (Patterns) : Cấu trúc mơ hình có xuất nhiều ứng dụng khác 13 Phân tích yêu cầu phần mềm Nguyên tắc 1: Phân tách Sự phân tách Nắm rõ tập hợp (aggregation)/phần quan hệ (relationship) Ví dụ: Mục tiêu khai thác tàu vũ trụ Phân tách vấn đề thành vấn đề con: Các dẫn cách điều khiển; Quản lý liệu; Chỉ huy kiểm soát; Kiểm soát môi trường; Theo dõi thiết bị đo đạc; etc Chú ý: thiết kế, phân tích vấn đề Thiết kế thực phải có đủ thành phần, khơng có liên quan với vấn đề Tuy nhiên, cách chọn lựa phân tách vấn đề phản ánh thiết kế 14 Phân tích yêu cầu phần mềm Nguyên tắc 2: Trừu tượng hóa Source: Adapted from Davis, 1990, p48 and Loucopoulos & Karakostas, 1995, p78 Trừu tượng hóa Là cách tìm kiếm tương tự khái niệm việc lờ số chi tiết Tập trung vào mối quan hệ tổng quan/cụ thể tượng Phân loại vào thành nhóm thực thể chúng có vai trị tương tự thành phần nhóm độc lập Quan hệ kế thừa biểu diễn tương tự lớp khác mối quan hệ kết hợp ‘(is_a)’ Ví dụ: Yêu cầu : kiểm soát lỗi tàu vũ trụ Phải nhóm lỗi khác vào thành lớp LỖI Dựa vào vị trí: lỗi thiết bị đo, lỗi truyền thông, lỗi xử lý, etc Dựa vào triệu chứng: khơng có đáp ứng từ thiết bị; đáp ứng khơng xác; tự báo lỗi; etc 15 Phân tích yêu cầu phần mềm Nguyên tắc 3: Quy chiếu Source: Adapted from Davis, 1990, p48-51 Quy chiếu: Phân chia lĩnh vực mơ hình thành nhiều khía cạnh (viewpoints) tương tự phép chiếu dùng kiến trúc sư xây dựng Ví dụ: Cần lập mơ hình u cầu cho tàu vũ trụ Phân chia mơ hình : độ an tồn khả huy khả chịu lỗi thời gian trình tự Etc… Chú ý: Quy chiếu Phân tách tương tự nhau: Phân tách định nghĩa ‘phần’ quan hệ Phép chiếu định nghĩa ‘khía cạnh’ quan hệ Phân tách thừa nhận phần tương đối độc lập 16 Phân tích yêu cầu phần mềm Một ví dụ tổng quan UML Source: Adapted from Davis, 1990, p67-68 Quan hệ thừa kế (hệ thống phân cấp trừu tượng) Quan hệ tập hợp (hệ thống phân cấp phân chia) :patient :patient Name Date of Birth physician history Name Date of Birth physician history 1 1 :in-patient Room Bed Treatments food prefs :out-patient Last visit next visit prescriptions :heart Natural/artif Orig/implant normal bpm :kidney Natural/artif Orig/implant number :eyes Natural/artif Vision colour 17 Phân tích yêu cầu phần mềm Đây mơ hình cho vấn đề ? 18 Phân tích u cầu phần mềm Kết luận Mơ hình hóa đóng vai trị trọng tâm RE Cho phép khảo sát vấn đề cách hệ thống Cho phép kiểm tra hiểu biết Co nhiều lựa chọn ký pháp cho mơ hình Trong course này, dùng dạng ký pháp UML Tất mơ hình thường thiếu xác Sử dụng mơ hình hiệu chỉnh liên tục …nhưng biết ngừng việc hồn chỉnh mơ hình Mỗi mơ hình tạo cho mục đích riêng Mục đích thường khơng biểu diễn mơ hình … Vì nên mơ hình cần có giải thích 19 ... System Phân tích yêu cầu phần mềm Khái niệm : Tư hệ thống Phân tích yêu cầu phần mềm Mơ hMơ hình hóa Mơ hình hóa hướng dẫn suy luận Nó giúp bạn câu hỏi để hỏi Nó giúp làm rõ yêu cầu ẩn chứa i.e... mơ hình khơng hồn hảo “Nếu đồ địa hình khơng giống nhau, tin vào địa hình? ?? Tìm kiếm hồn hảo mơ hình khơng việc tốt cho thời gian bạn Phân tích yêu cầu phần mềm Chọn ký pháp cho việc mô hình hóa. .. muốn? Xây dựng hình ảnh mơ hình giúp quan sát/kiểm chứng yêu cầu Phân tích u cầu phần mềm RE gồm nhiều bước mơ hình hóa Source: Adapted from Jackson, 1995, p120-122 Mơ hình tốt mơ tả Nó có tượng