Bài giảng Công nghệ phần mềm - Phân tích và đặc tả yêu cầu - Lê Thị Mỹ Hạnh
NỘI DUNG
Đại cương về phân tích và đặc tả
Nền tảng của phân tích
Phân tích và nắm bắt yêu cầu
Đặc tả yêu cầu
Thẩm định yêu cầu
Một số phương pháp và công cụ hỗ trợPhân tích và đặc tả
Xác định và phân tích yêu cầu là khâu kỹ
thuật đầu tiên của quá trình phát triển phần
mềm.
Xác định các chức năng/dịch vụ mà khách hàng
yêu cầu từ hệ thống
Các ràng buộc mà hệ thống được phát triển và
vận hành.
Là sự phối hợp của nhà phát triển và khách
hàng.
Quyết định chất lượng phần mềm đạt được
và chi phí bỏ ra.
Bạn đang xem 20 trang mẫu của tài liệu "Bài giảng Công nghệ phần mềm - Phân tích và đặc tả yêu cầu - Lê Thị Mỹ Hạnh", để tải tài liệu gốc về máy hãy click vào nút Download ở trên
Tóm tắt nội dung tài liệu: Bài giảng Công nghệ phần mềm - Phân tích và đặc tả yêu cầu - Lê Thị Mỹ Hạnh
1Phân tích và đặc tả yêu cầu Lê Thị Mỹ Hạnh Khoa Công nghệ Thông tin Trường Đại học Bách khoa, Đà Nẵng NỘI DUNG Đại cương về phân tích và đặc tả Nền tảng của phân tích Phân tích và nắm bắt yêu cầu Đặc tả yêu cầu Thẩm định yêu cầu Một số phương pháp và công cụ hỗ trợ 2Phân tích và đặc tả Xác định và phân tích yêu cầu là khâu kỹ thuật đầu tiên của quá trình phát triển phần mềm. Xác định các chức năng/dịch vụ mà khách hàng yêu cầu từ hệ thống Các ràng buộc mà hệ thống được phát triển và vận hành. Là sự phối hợp của nhà phát triển và khách hàng. Quyết định chất lượng phần mềm đạt được và chi phí bỏ ra. Phân tích và đặc tả Mục đích: Đặc tả yêu cầu phần mềm Cơ sở cho việc mời thầu (cần có giải thích) cơ sở để ký kết hợp đồng (cần đầy đủ chi tiết) Làm tư liệu phục vụ thiết kế và triển khai (cần đầy đủ , chính xác, không mâu thuẫn) 3Yêu cầu là gì? Các yêu cầu là các mô tả từ mức trừu tượng rất cao đến một đặc ta rất chi tiết về dịch vụ mà hệ thống cần cung cấp cũng như các ràng buộc lên sự phát triển và họat động của nó. Yêu cầu là: Năng lực của phần mềm mà người sử dụng cần để giải quyết vấn đề đặt ra nhằm đạt được mục đích xác định Năng lực của phần mềm cần có nhằm thỏa mãn một hợp đồng, một chuẩn, một đặc tả. Bài toán •Hiểu vấn đề •Chi tiết hóa •Biểu diễn lại Đặc tả Vai trò Có vai trò đặc biệt quan trọng trong tiến trình phát triển phần mềm. 4Phân loại yêu cầu Yêu cầu người dùng Diễn đạt bằng ngôn ngữ tự nhiên và sơ đồ Nêu rõ dịch vụ hệ thống cung cấp và các ràng buộc trong hoạt động của nó. Yêu cầu hệ thống Mô tả đủ chi tiết về các dịch vụ hệ thống Như một hợp đồng giữa khách hàng và nhà thầu Đặc tả phần mềm Mô tả chi tiết về phần mềm làm cơ sở cho thiết kế và cài đặt Dành cho người phát triển Đối tượng đọc yêu cầu Ö Yêu cầu viết ra cần đáp ứng được tất cả các đối tượng này. 5Các loại yêu cầu Các yêu cầu chức năng Mô tả các chức năng hay các dịch vụ mà hệ thống phần mềm cần cung cấp. Các yêu cầu phi chức năng Mô tả các ràng buộc đặt lên dịch vụ và quá trình phát triển hệ thống (về chất lượng, về môi trường, chuẩn sử dụng, qui trình phát triển..) Các yêu cầu miền/lĩnh vực Những yêu cầu đặt ra từ miền ứng dụng, phản ánh đặc trưng của miền đó. Yêu cầu chức năng Mô tả chức năng hay các dịch vụ của hệ thống Chúng phụ thuộc vào: Loại phần mềm sẽ được xây dựng Sự mong muốn của khách hàng Loại hệ thống mà phần mềm trợ giúp Mức độ các yêu cầu Trừu tượng: hệ thống làm gì Chi tiết: dịch vụ cụ thể hệ thống thực hiện 6Yêu cầu chức năng Ví dụ Người sử dụng có thể tìm kiếm tài liệu dựa trên từ khóa có trong tài liệu hoặc tên tài liệu Hệ thống cần cug cấp cho người sử dụng phương tiện hiển thị dễ dàng các tài liệu từ CSDL Hệ thống phải đọc được các dịnh dạng khác nhau của tài liệu: text, doc, pdf, ppt, bảng tính excel,.. Yêu cầu chức năng Sự không chính xác của yêu cầu Yêu cầu không được phát biểu chính xác Yêu cầu nhập nhằng có thể được hiểu khác nhau giữa người sử dụng và người phát triển Ví dụ: yêu cầu “hiển thị dễ dàng” Người sử dụng: có thể hiển thị các loại tài liệ khác nhau Người phát triển: cung cấp giao diện hiển thị tài liệu ở chế độ văn bản Trên nguyên tắc yêu cầu phải thỏa mãn Đầy đủ: yêu càu phải mô tả đầy đủ các chức năng cần thiết Gắn bó: các yêu cầu không mâu thuẫn nhau Thực tế không đơn giản để có các yêu cầu đầy dủ và gắn bó 7Yêu cầu phi chức năng Định nghĩa các tính chất và ràng buộc của hệ thống Yêu cầu tiến trình Phương pháp thiết kế Ngôn ngữ lập trình Công cụ sử dụng Thời gian trả lời Độ tin cậy Yêu cầu về lưu trữ dữ liệu Yêu cầu phi chức năng có thể quan trọng hơn yêu cầu phi chức năng Nếu yêu cầu phi chức năng không được đáp ứng hệ thống trở nên vô dụng Yêu cầu phi chức năng Yêu cầu về sản phẩm Tốc độ, độ tin cậy, bộ nhớ cần, giao diện Yêu cầu về tổ chức, tiến trình phát triển Các chuẩn áp dụng, phương pháp thiết kế, ngôn ngữ lập trình, mô hình tiến trình,.. Yêu cầu từ bên ngoài Về chi phí, về bản quyền, liên kết,.. 8Các loại yêu cầu phi chức năng Yêu cầu Phi chức năng Yêu cầu Sản phẩm Yêu cầu về tổ chức Yêu cầu từ bên ngoài Yêu cầu Khả dụng Yêu cầu Hiệu quả Yêu cầu Tin cậy Yêu cầu Khả chuyển Yêu cầu hoạt động bên trong Yêu cầu Đạo lý Yêu cầu Pháp lý Yêu cầu chuyển giao Yêu cầu Triển khai Yêu cầu về chuẩn Yêu cầu Cá nhân Yêu cầu về an toàn Yêu cầu về hiệu năng Yêu cầu không gian Yêu cầu phi chức năng Ví dụ Yêu cầu về sản phẩm Phần mềm chỉ nên yêu cầu tối đa 256 MB bộ nhớ Yêu cầu vê tổ chức Yêu cầu phải đáp ứng chuẩn DO178 Yêu cầu bên ngoài Hệ thống không được để lộ thông tin cá nhân của khách hàng ra bên ngoài 9Yêu cầu người sử dụng (user requirements) Nên mô tả Yêu cầu chức năng Yêu cầu phi chức năng Dể hiểu đối với người sử dụng Không có kiến thức chi tiết về kỹ thuật/tin học Nên mô tả Bằng ngôn ngữ tự nhiên Biểu đồ, bảng biểu Ngôn ngữ tự nhiên (NNTN) Ưu điểm Dễ hiểu Dễ sử dụng Hạn chế Không rỏ ràng, thiếu chính xác Nhập nhẵng Lẫn lộn giữa yêu cầu chức năng và yêu cầu phi chức năng Quá mềm dẻo Có thể trình bày nhiều cách 10 Giải pháp thay thế cho NNTN Ngôn ngữ có cấu trúc Sử dụng ngôn ngữ gần gũi với ngôn ngữ lập trình Các mô hình Các ký hiệu đồ họa Ký hiệu tóan học Ngôn ngữ hình thức Yêu cầu hệ thống (System Requirements) Là đặc tả chi tiết hơn yêu cầu người sử dụng Phục vụ cơ bản cho bước thiết kế Có thể sử dụng làm một phần của hợp đồng Có thể sử dụng các mô hình để mô tả 11 Tài liệu yêu cầu Chỉ mô tả về chức năng (các hành vi bên ngòai) của hệ thống và các ràng buộc (WHAT) Không mô tả về phương thức cài đặt (HOW) – không phải là tài liệu thiết kế Phải dễ thay đổi Khó xác định được đầy đủ, chính xác ngay Phải qua nhiều bước xét duyệt lại Sử dụng như là tài liệu tham khảo khi bảo trì Đặc tả trả lời các sự kiện không mong đợi Tài liệu yêu cầu Khó khăn Khách hàng chỉ có khái niệm mơ hồ người phát triển phải chi tiết hóa thành các yêu cầu phần mềm có thể xây dựng được Khách hàng rất hay thay đổi yêu cầu người phát triển cần tỉnh táo để xác định đúng các yêu cầu Các yêu cầu thường mang tính đặc thù Khó hiểu, khó định nghĩa Không có chuẩn biểu diễn 12 Tài liệu yêu cầu Khó khăn Hệ thống đa người sử dụng Các yêu cầu đa dạng, mức ưu tiên khác nhau Yêu cầu mâu thuẫn nhau Người đặt hành khác người sử dụng thật sự Không nắm vững yêu cầu Cấu trúc của tài liệu yêu cầu Giới thiệu Thuật ngữ Định nghĩa yêu cầu người sử dụng Kiến trúc hệ thống Đặc tả yêu cầu hệ thống Mô hình hệ thống Phát triển/thay đổi của hệ thống Phụ lục Chỉ mục 13 Định dạng của tài liệu yêu cầu Theo chuẩn IEEE 830-1984 1. Giới thiệu 2. Mô tả chung 3. Yêu cầu chi tiết Định dạng của tài liệu yêu cầu 1. Giới thiệu 1.1. Mục đích 1.2. Phạm vi 1.3. Định nghĩa (định nghĩa, từ viết tắt) 1.4. Tài liệu tham khảo 1.5. Mô tả cấu trúc tài liệu 14 Định dạng của tài liệu yêu cầu 2. Mô tả chung 2.1. Tổng quan về sản phẩm 2.2. Chức năng sản phẩm 2.3. Đối tượng người dùng 2.4. Ràng buộc tổng thể 2.5. Giả thiết và sự lệ thuộc Định dạng của tài liệu yêu cầu 3. Yêu cầu chi tiết 3.1. Yêu cầu về chức năng 3.1.1. Chức năng 1 3.1.1.1. Giới thiệu 3.1.1.2. Dữ liệu vào 3.1.1.3. Xử lý 3.1.1.4. kết quả 3.1.2. Chức năng 2 3.1.n. Chức năng n 3.2. Yêu cầu về giao diện ngoài 3.2.1. Giao diện người dùng 3.2.2. Giao diện phân cứng 3.2.3. Giao diện phần mềm 3.2.4. Giao diện truyền thông 3.3. Yêu cầu hiệu suất 3.4 Ràng buộc thiết kế 3.5. Thuộc tính: - bảo mật - bảo trì 3.6. Yêu cầu khác Phụ lục 15 Các công đoạn phân tích và đặc tả Phân tích bài tóan Thu thập yêu cầu Nghiên cứu khả thi Phân tích yêu cầu Xác định yêu cầu Đặc tả yêu cầu Báo cáo khả thi Tài liệu mô tả hệ thống Tài liệu định nghĩa yêu cầu Tài liệu đặc tả yêu cầuThẩm định Tài liệu yêu cầu Quá trình hình thành yêu cầu Tiến trình phân tích yêu cầu Hiểu miền ứng dụng Thẩm định yêu cầu Phân loại yêu cầu Sắp xếp ưu tiên Đặc tả yêu cầu Thu thập yêu cầu Giải quyết mâu thuẩn Tài liệu mô tả HT 16 Phân tích bài tóan Mô tả nghiệp vụ Mô tả các luồng nghiệp vụ, các xử lý và vai trò của con người trong hệ thống hiện tại Hiểu được nghiệp vụ Chủ yêu tập trung vào các miền cần tự động hoá Hỗ trợ cho việc xác định các thay đổi và cải tiến yêu cầu trong hệ thống mới Phân tích bài tóan Mô tả hệ thống Mô tả hệ thống đề xuất Mô tả luồng thông tin giữa hệ thống đề xuất và môi trường của nó Đáp ứng được các mô tả nghiệp vụ Cải tiến nghiệp vụ hiện tại Dựa trên mô tả nghiệp vụ hiện tại 17 Thu thập yêu cầu Xác định tính khả thi của hệ thống Kinh tế Kỹ thuật Vận hành Xác định những người liên quan đến hệ thống và những người sử dụng cuối Xác định các ràng buộc khi sử dụng hệ thống đề xuất Thu thập yêu cầu Xác định phương pháp thu thập yêu cầu Phỏng vấn Xác định các yêu cầu nhập nhằng Có thể sử dụng kỹ thuật nguyên mẫu Xác định các yêu cầu khác mà khách hàng không yêu cầu rỏ Ví dụ: giao diện dễ sử dụng 18 Thu thập yêu cầu Kết quả của bước thu thập yêu cầu Phát biểu về sự cần thiết và tính khả thi Giới hạn lĩnh vực/chức năng của phần mềm Danh sách những người liên quan/sử dụng phần mềm Mô tả môi trường sẽ vận hành phần mềm Danh sách các yêu cầu phần mềm đề xuất Các ràng buộc phần mềm đề xuất Thu thập yêu cầu Các kỹ thuật thu thập yêu cầu Phỏng vấn Thực hiện các cuộc họp/hội thảo Chuẩn bị bảng câu hỏi điều tra Chức năng mong đợi Thời gian yêu cầu hoàn thành dự án Kết quả một tiến trình nghiệp vụ Quan sát họat động nghiệp vụ hiện tại Đến nơi làm việc của khách hàng để khảo sát, quay phim,.. Tham khảo các chuyên gia trong lĩnh vực Hiểu rỏ các nghiệp vụ chuyên môn phức tạp 19 Thu thập yêu cầu Phỏng vấn Hiểu rỏ nghiệp vụ hiện tại Hiểu rỏ chi tiết yêu cầu Hiểu rỏ mong muốn thực sự của khách hàng Chuẩn bị Lập danh sách đối tượng, hẹn gặp, lập kế hoạch, chuẩn bị câu hỏi, phương tiện,.. Câu hỏi Câu hỏi đóng – mở Câu hỏi ngắn gọn, tập trung vào chủ đề Cách thức tiến hành Theo nhóm, ít nhất hai người Phân công hỏi và ghi chép Nghiên cứu khả thi Mục tiêu của nghiên cứu khả thi là đi đến kết luận: Có nên phát triển hệ thống hay không? Nội dung nghiên cứu khả thi tập trung vào những câu hỏi sau: Hệ thống xây dựng sẽ giúp gì cho tổ chức? Hệ thống xây dựng sử dụng công nghệ nào và kinh phí bao nhiêu? Hệ thống cần tích hợp với hệ thống nào đang sử dụng? 20 Nghiên cứu khả thi Báo cáo khả thi được viết dựa trên thông tin, báo cáo thu thập được, những đánh giá ban đầu về hệ thống hiện tại và phác họa các phương án dự kiến. Câu hỏi đặt ra cho người của tổ chức: Cái gì xảy ra nếu hệ thống không được triển khai? Những vấn đề gì đang đặt ra cần giải quyết? Hệ thống được đề xuất giúp họ như thế nào? Những tích hợp gì cần phải có? Công nghệ mới gì, kỹ năng gì cần có? Những tiện ích gì cần sự trợ giúp từ hệ thống? Phân tích yêu cầu Những khó khăn của phân tích Khách hàng thường mơ hồ về các yêu cầu, không biết mình muốn cụ thể gì, dễ lẫn lộn giữa yêu cầu và mong muốn. Họ thể hiện yêu cầu theo thuật ngữ riêng Khách hàng đa dạng có thể đưa ra các yêu cầu mâu thuẫn. Những yếu tố tổ chức và chính sách có thể ảnh hưởng đến yêu cầu Yêu cầu thường mang tính đặc thù, khó hiểu, khó có chuẩn chung. Các yêu cầu thay đổi trong quá trình phân tích: môi trường nghiệp vụ thay đổi,.. 21 Phân tích yêu cầu Đôi khi còn gọi là phát hiện yêu cầu. Nhà kỹ thuật cùng với khách hàng (người dùng, kỹ sư, nhà quản lý, chuyên gia,..-người liên quan) làm rõ lĩnh vực ứng dụng, các dịch vụ mà hệ thống cần cung cấp và các ràng buộc trong họat động của nó. Xây dựng các mô hình phân tích để làm rõ các yêu cầu miền. Phân tích yêu cầu Phân loại yêu cầu Chức năng Phi chức năng Yêu cầu chức năng xuất phát từ các yêu cầu của khách hàng và nghiệp vụ trong hệ thống hiện tại Yêu cầu phi chức năng thường không lộ rõ Thường do người phát triển đề xuất 22 Phân tích yêu cầu Mục tiêu, mong muốn và yêu cầu Mục tiêu, mong muốn: là cái hướng tới. Ví dụ: “Xây dựng giao diện thân thiện” Yêu cầu: là cái cụ thể kiểm tra được Ví dụ: “Giao diện đồ họa có các lệnh được chọn bằng menu” Nhiệm vụ của người phân tích là các xác định đúng, đầy đủ và chính xác các yêu cầu. Nguyên lý phân tích yêu cầu Nguyên lý 1: Mô hình hóa miền thông tin Phải hiểu và biểu diễn được miền thông tin (problem domain) định danh dữ liệu (đối tượng, thực thể) định nghĩa các thuộc tính thiết lập các mối quan hệ giữa các dữ liệu ÖTừ điển dữ liệu, mô hình thực thể mối quan hệ,mô hình khái niệm 23 Nguyên lý phân tích yêu cầu Nguyên lý 2: Mô hình hóa chức năng Bản chất của phần mềm là biến đổi thông tin định danh các chức năng (biến đổi thông tin) xác định cách thức dữ liệu (thông tin) di chuyển trong hệ thống (luồng dữ liệu) xác định các tác nhân tạo dữ liệu (nguồn) và tác nhân tiêu thụ dữ liệu (đích) ÖMô hình phân rã chức năng, mô hình luồng dữ liệu Nguyên lý phân tích yêu cầu Nguyên lý 3: Mô hình hóa hành vi Phần mềm (hệ thống) có trạng thái (hành vi) xác định các trạng thái của hệ thống ví dụ: giao diện đồ họa, section trong ứng dụng web xác định các dữ kiện làm thay đổi hành vi hệ thống ví dụ: bàn phím, chuột, các cổng thông tin... ÖBiểu đồ trạng thái 24 Nguyên lý phân tích yêu cầu Nguyên lý 4: Phân hoạch các mô hình Làm mịn, phân hoạch và biểu diễn các mô hình ở các mức khác nhau làm mịn các mô hình dữ liệu tạo cây (mô hình) phân rã chức năng biểu diễn hành vi ở các mức chi tiết khác nhau ÖMô hình luồng dữ liệu các mức 1,2,3,.. Nguyên lý phân tích yêu cầu Nguyên lý 5: Tìm hiểu vấn đề bản chất Nhìn nhận bản chất của yêu cầu (làm gì, điều kiện gì,..) Không quan tâm đến cách thức cài đặt (làm như thế nào) 25 Phân hoạch yêu cầu Có thể phân hoạch yêu cầu theo hai cách Phân loại theo đặc trưng: Yêu cầu tương hỗ: chịu ảnh hưởng của môi trường Yêu cầu nảy sinh:nhận ra trong quá trình phát triển Yêu cầu hệ quả:là kết quả của việc áp dụng hệ thống dựa trên máy tính Yêu cầu tương thích:phụ thuộc vào hệ khác hay tiến trình tổ chức Phân loại theo mức độ quan trọng: chính, phụ Thẩm định yêu cầu Thẩm định yêu cầu liên quan tới việc kiểm tra tính đúng đắn, tính đầy đủ, tính hiện thực và kiểm tra được của yêu cầu. 1. Thỏa mãn được nhu cầu của người dùng? 2. Yêu cầu không mâu thuẫn nhau? 3. Yêu cầu phải đầy đủ (chức năng, ràng buộc)? 4. Yêu cầu là hiện thực? 5. Yêu cầu có thể kiểm tra được? 26 Thẩm định yêu cầu Thường xuyên thẩm định yêu cầu Cả khách hàng và người phát triển đều phải thẩm định yêu cầu Việc thẩm định có thể tổ chức hình thức hoặc không hình thức Trao đổi giữa khách hàng, nhà phát triển và người sử dụng cuối có thể giải quyết sớm ... ý hiệu đồ họa Đặc tả nữa hình thức (semi-informal) trộn lẫn cả ngôn ngữ tự nhiên, các kí hiẹu toán học và các kí hiệu đồ họa Đặc tả hình thức (formal) Đặc tả bằng mô hình Đặc tả bằng ngôn ngữ hình thức hoá Đặc tả bằng công thức tóan học 33 Đặc tả hình thức hay không hình thức? Đặc tả hình thức Chính xác (toán học) Hợp thức hóa hình thức (công cụ hóa) công cụ trao đổi: khó đọc, khó hieu khó sử dụng Đặc tả không hình thức Dễ hiểu, dễ sử dụng Mềm dẻo Thiếu sự chính xác Không chặc chẽ, Nhập nhằng Đặc tả phi hình thức Ví dụ: chức năng kiểm tra lỗi chính tả Yêu cầu: thông báo các lỗi chính tả khi duyệt Đặc tả: Các lỗi chính tả được gạch đỏ bên dưới Các lỗi soạn thảo được gạch xanh bên dưới Lỗi chính tả: Từ đơn không có trong từ điển Lỗi soạn thảo Thừa dấu cách Không viết hoa đầu câu 34 Ứng dụng đặc tả hình thức ứng dụng trong các giai đoạn sớm của tiến trình phát triển Hạn chế lỗi trong phát triển phần mềm Ứng dụng chủ yếu trong phát triển các hệ thống “quan trọng” (critical system) Hệ thống điều khiển Hệ thống nhúng Hệ thống thời gian thực Các kỹ thuật đặc tả hình thức Biểu đồ luồng dữ liệu Biểu đồ thực thể kết hợp Làm bản mẫu Máy trạng thái hữu hạn Mạng Petri Điều kiện trước sau Kiểu trừu tượng Ngôn ngữ đặc tả Z 35 Biểu đồ phân rã chức năng Function Decomposition Diagram – FDD Xác định phạm vi của hệ thống Phân hoạch chức năng Tạo nền tảng cho thiết kế kiến trúc hệ thống Chức năng Bán hàng Liên kết Nhận đơn Gửi đơn Gom, gửi hàng Biểu đồ phân rã chức năng Ví dụ: biểu diễn các chức năng của hệ thống cửa hàng nước giai khát Hệ quản lý cửa hàng Bán hàng Kế toán Quản lý tồn kho Quản lý nhập hàng Quản lý xuất Báo cáo tồn Bán lẽ Quản lý đơn hàng Quản công nợ Chức năng Quan hệ bao hàm 36 Biểu đồ dòng dữ liệu Data Flow Diagram – DFD Mô tả cách thức dữ liệu di chuyển và được xử lý, lưu trữ trong hệ thống DFD dễ viết, dễ đọc, dễ hiểu được sử dụng phổ biến DFD được xây dựng từ các hình vẽ và các kí hiệu qui ước. Có nhiều mức chi tiết khác nhau (phân tích có cấu trúc) Có nhiều cách xây dựng DFD, thông dụng là phương pháp DeMarco-Yourdon, Gane Sarson và Merise (pháp) Biểu đồ dòng dữ liệu Một số phương pháp vẽ DFD 37 Biểu đồ dòng dữ liệu DFD – Các thành tố Quá trình (Process) Mô tả hoạt động (activities) hay phép biến đổi (Transform) một hoặc nhiều dòng dữ liệu vào (input) thành một hoặc nhiều dòng dữ liệu ra (output) Quá trình không chỉ ra chi tiết logic hay thủ tục xử lý Trong sơ đồ DFD, quá trình có thể là một người sử dụng hoặc máy tính xử lý Ví dụ: Nhận yêu cầu khách hàng Thủ tục giao hàng Thông báo Xử lý điểm 1 Mô tả quá trình Biểu đồ dòng dữ liệu DFD – Các thành tố Thực thể (Entity) Xác định ranh giới, phạm trù hay phạm vi, ngữ cảnh của hệ thống đang xét Cung cấp cái vào cho hệ thống và lấy cái ra từ hệ thống Các thực thể có thể nằm bên trong hay bên ngoài, tạo thành các nguồn hay các đích cho hệ thống Mỗi thực thể có thể là một người, tổ chức hoặc một hệ thống khác tương tác với hệ thống đang xét Ví dụ: Khách hàng Học viên Giáo viên Tên thực thể 38 Biểu đồ dòng dữ liệu DFD – Các thành tố Kho dữ liệu (data stores): Chỗ chứa các thông tin được lưu theo thời gian, được xử lý thủ công hay tự động Đó là các tập tin, cơ sở dữ liệu hay bất cứ các hình thức lưu trữ dữ liệu nào (bảng biểu báo cáo, từ điển, hộp thư, danh bạ,..) Ví dụ: Hồ sơ học viên Sổ nợ Kết quả tuyển sinh Tên kho dữ liệu Biểu đồ dòng dữ liệu DFD – Các thành tố Dòng dữ liệu (Data flows) Phương tiện luân chuyển thông tin thể hiện cái vào và cái ra, thể hiện sự tương tác trong hệ thống Có thể là báo cáo, biểu mẫu, vân bẳn, thư tín, thông điệp hay dữ liệu nói chung Được tạo thành từ các vật mang thông tin (giấy, màn hình,..) có cùng bản chất Đi từ tơi phát (nguồn) đến nơi nhận (đích) Ví dụ: Yêu cầu cho vay Tra lời vay Báo kết quả thi Dữ liệu chuyển 39 Biểu đồ dòng dữ liệu Ví dụ: DFD hệ thống mua bán hàng Biểu đồ dòng dữ liệu Ví dụ: DFD hệ thống tài chính cá nhân 40 Biểu đồ dòng dữ liệu DFD – Các bước thực hiện Phân rã chức năng hệ thống Liệt kê các tác nhân, các khoản mục dữ liệu Vẽ DFD cho các mức Làm mịn DFD cho các mức từ DFD ngữ cảnh Biểu đồ dòng dữ liệu DFD – Một số nguyên tắc Các tiến trình phải có luồng vào và luồng ra Không có luồng dữ liệu giữa các tác nhân – tác nhân, tác nhân – kho dữ liệu, kho dữ liệu – kho dữ liệu. Luồng dữ liệu không quay lại nơi xuất phát Làm mịn cần đảm bảo đầy đủ các yếu tố của bước trước (tác nhân, luồng dữ liệu, kho dữ liệu). 41 Biểu đồ dòng dữ liệu Các mức DFD Biểu đồ thực thể quan hệ ERD – Entity Relation Diagram Phân tích dữ liệu độc lập với xử lý Nghiên cứu miền thông tin Tạo ra mô hình trừu tượng hướng khách hàng Xác định mối liên hệ giữa các dữ liệu 42 Biểu đồ thực thể quan hệ ER – khái niệm Thực thể: Là các đối tượng thế giới thực mà chúng ta muốn xử lý Có thể là đối tượng thực hoặc trừu tượng Thuộc tính: là các đặc điểm, tính chất của thực thể Quan hệ: Mối liên hệ giữa các thực thể Là thông tin cần lưu trữ, xử lý Kế thừa: quan hệ thừa kế giữa các thực thể Tên thực thể Thuộc tính1 Thuộc tính 2 Biểu đồ thực thể quan hệ ER – ví dụ NGK ĐĐHÀNG_NGK ĐẶT KHÁCH_HÀNG LOẠI_NGKTHUỘC CỦA (0,n) (1,n) (1,1) (0,n) (1,n)(1,1) NGK(MA_NGK, TEN_NGK, HIEU, LOAI, DVTINH, DON_GIA) ĐĐHANG_NGK(SO_DDH, NGAY_DAT, KHACH_HANG, NGAYGIAO, TRANG THAI) CHITIET_DDH(MA_NGK, SO_DDH, SL_DAT, DONGIA_DAT) 43 Biểu đồ thực thể quan hệ ER – Xác định thực thể quan hệ Thực thể: Là các danh từ (trong câu mô tả các yêu cầu) Có các thuộc tính khóa (xác định duy nhất) Quan hệ Hoạt động xảy ra giữa các thực thể Có nghĩa với họat động của hệ thống Là động từ Biểu đồ thực thể quan hệ ER – Các bước Mô tả thực thể và sự liên kết giữa các thực thể Mô tả thực thể và các mối quan hệ Mô tả thực thể, các mối quan hệ và các thuộc tính 44 Từ điển dữ liệu Phương pháp có tính hình thức để mô tả dữ liệu mà hệ thống xử lý Ký pháp để mô tả các dữ liệu điều khiển và miền giá trị của chúng Chứa đựng các thông tin về nơi (modul) và cách thức xử lý dữ liệu Thường được tạo bằng các công cụ trợ giúp Từ điển dữ liệu Các khoản mục từ điển dữ liệu Tên (name): tên dữ liệu Bí danh (alias):tên gọi khác của dữ liệu Vị trí (where): tên các modul xử lý Cách thức (how): vai trò của dữ liệu và cách thức xử lý Ký pháp (Description): ký pháp mô tả dữ liệu Format: Kiểu dữ liệu,giá trị mặc định, 45 Từ điển dữ liệu Từ điển dữ liệu – ví dụ Integrated office phone system Telephone number System output alphanumeric dataFormat: telephone no. = [ local extension | outside no. | 0 ] outside no. = 9 + [ service code | domestic no. ] service code = [ 211 | 411 | 611 | 911 ] domestic no. = ( ( 0 ) + area code ) + local number area code = *three numeral designator* Description: Read_phone_number(input) Display_phone_number(output) Analyze_long_distance_calls (input) Where/ How used: Phone number, numberAliases: Telephone numberName: Bảng từ điển dữ liệu Làm bản mẫu trong phân tích Trong nhiều trường hợp, mô hình chạy thử là phương pháp duy nhất để xác định yêu cầu Phần mềm lớn, phức tạp ⇒ bản mẫu (trực quan) Bản mẫu phần mềm:phát triển yêu cầu Bản mẫu phần cứng: kiểm tra thiết kế 46 Làm bản mẫu trong phân tích Các bước thực hiện Bước 1: Đánh giá yêu cầu và xác định có nên làm bản mẫu không; độ phức tạp, chủng loại, khách hàng Bước 2: Biểu diễn vắn tắt yêu cầu (yêu cầu chức năng, yêu cầu phi chức năng) Bước 3: Thiết kế nhanh kiển trúc, cấu trúc dữ liệu Bước 4: Phát triển, kiểm thử Sử dụng các thành phần sẵn có Dùng các ngôn ngữ bậc cao Các thuật tóan dễ cài đặt Bước 5: Người dùng đánh giá (bước quan trọng???) Bước 6: Lặp lại bước2-5 cho đến khi đủ yêu cầu Làm bản mẫu trong phân tích Ưu điểm Loại bớt hiểu nhầm Phát hiện thiếu hụt chức năng Ví dụ: soạn thảo kéo theo kiểm tra chính tả Phát hiện các điểm yếu Khó sử dụng Thao tác không an toàn Kiểm tra tính khả thi, hữu ích Có thể xây dựng được không Có thực sự cần không Làm cơ sở cho đặc tả: làm giống như thế này nhưng tốt hơn Huấn luyện người sử dụng Hỗ trợ kiểm thử (so sánh kết quả) ÖLàm bản mẫu là kỹ thuật tránh rủi ro 47 Làm bản mẫu trong phân tích Nhược điểm Các yêu cầu phi chức năng thường không được thể hiện đầy đủ Làm tăng chi phí:cần phải ước lượng chi phí chính xác của bản mẫu Các yêu cầu thay đổi quá nhanh làm bản mẫu trở nên vô nghĩa Người dùng không sử dụng bản mẫu theo cách thông thường (kết quả đánh giá không có giá trị) Làm bản mẫu trong phân tích Ngôn ngữ làm bản mẫu Java Visual Basic Prolog, Lisp, Python Các ngôn ngữ script khác Perl, PHP, shell script 48 Làm bản mẫu trong phân tích Bản mẫu giao diện/trực quan Sử dụng các ngôn ngữ, công cụ trực quan VB Delphi, J Buider FrontPage Sử dụng lại một lượng lớn các thư viện sẵn có Tính cấu trúc không cao, khó tích hợp kết quả của nhiều nhóm, khó bảo trì Máy trạng thái hữu hạn Finite State Machine Mô tả các luồng điều khiển Biểu diễn dạng đồ thị Bao gồm: Tập hợp các trạng thái S (các nút của đồ thị) Tập hợp các dữ liệu vào I (các nhãn của các cung) Tập hợp các chuyển tiếp T: S x I -> S (các cung có hướng của đồ thị) Khi có một dữ liệu vào một trạng thái sẽ chuyển sang trạng thái khác 49 Máy trạng thái hữu hạn ON HOOK OFF HOOK DIALING RINGING BUSY CONNECTED Handset lifted Handset replaced Number dialed Number dialed Handset replaced Handset replaced Handset replaced Handset replaced Line in use Last number dialed Caller answers Caller hangs up Ví dụ 1: Máy trạng thái hữu hạn Ví dụ 2: 50 Máy trạng thái hữu hạn Ví dụ 2: Máy trạng thái hữu hạn Ví dụ 2: 51 Máy trạng thái hữu hạn Biểu diễn hệ thống phức tạp Hạn chế khi đặc tả những hệ thống không đồng bộ Các thành phần của hệ thống hoạt động song song hoặc cạnh tranh Điều kiện trước/sau (Pre/Post Condition) Được dùng để đặc tả các hàm hoặc mô đun Đặc tả các tính chất của dữ liệu trước và sau khi thực hiện hàm Pre-condition: đặc tả các ràng buộc trên tham số trước khi hàm được thực hiện Post-condition: đặc tả các ràng buộc trên tham số sau khi hàm được thực hiện Có thể sử dụng ngôn ngữ phi hình thức, hình thức hoặc ngôn ngữ lập trình để đặc tả các điều kiện. 52 Điều kiện trước/sau Ví dụ: đặc tả hàm tìm kiếm Function search(a: danh sách phần tử kiểu K, size: số phần tử của danh sách, e: phần tử kiểu K, result: kiểu Boolean) pre ∀i, 1≤i≤size, a[i] ≤ a[i+1] post result = (∃i, 1≤i≤size, a[i] = e) Điều kiện trước/sau Bài tập: đặc tả các hàm Sắp xếp một danh sách số nguyên Đảo ngược các phần tử của danh sách Đếm số phần tử có giá trị e trong một danh sách số nguyên 53 Kiểu trừu tượng (Abstract type) Mô tả dữ liệu và các thao tác trên dữ liệu đó ở một mức trừu tượng độc lập với cách cài đặt dữ liệu bởi ngôn ngữ lập trình Đặc tả một kiểu trừu tượng gồm: Tên của kiểu trừu tượng Dùng từ khóa sort Khai báo các kiểu trừu tượng đã tồn tại được sử dụng Dùng từ khóa import Các thao tác trên kiểu trừu tượng Dùng từ khóa operations Kiểu trừu tượng Ví dụ 1: đặc tả kiểu trừu tượng Boolean Một thao tác không có tham số là một hằng số một giá trị của kiểu trừu tượng được định nghĩa biểu diễn bởi kí tự “_” 54 Kiểu trừu tượng Ví dụ 2: đặc tả kiểu trừu tượng Vector Kiểu trừu tượng Các thao tác trên kiểu trừu tượng chỉ được định nghĩa mà không chỉ ra ngữ nghĩa của nó Tức là ý nghĩa của thao tác Sử dụng các tiên đề để chỉ ra ngữ nghĩa của các thao tác Sử dụng từ khóa axioms Định nghĩa các ràng buộc mà một thao tác được định nghĩa Sử dụng từ khóa precondition 55 Kiểu trừu tượng Ví dụ 2: đặc tả kiểu trừu tượng Vector Kiểu trừu tượng Bài tập: Đặc tả kiểu trừu tượng Cây nhị phân Đặc tả kiểu trừu tượng Tập hợp 56 Kiểu trừu tượng sort Circle Import Integer, float Operations Init : Integer x Integer x float -> Circle Unit_Circle: ->Circle Bankinh: Circle -> float Get_X: Circle -> Integer Get_Y: Circle -> Integer Zoom: Circle x float -> Circle Tinh_tien:Circle x Integer x Integer -> Circle Kiểu trừu tượng axioms Bankinh(Unit_Circle) = 1 Get_x(Unit_Circle) = Get_Y(Unit_Circle) = 0 Bankinh(Init(x, y, r)) = r Get_X(Init(x, y, r)) = x Get_Y(Init(x, y, r)) = y C = Init(x,y,r) => Bankinh(Tinhtien(C, dx, dy)) = r C = Init(x,y,r) => Get_X(Tinhtien(C, dx, dy)) = x + dx C = Init(x,y,r) => Get_Y(Tinhtien(C, dx, dy)) = y + dy C = Init(x,y,r) =>Bankinh(Zoom(C, dr)) = r + dr C = Init(x,y,r) =>Get_X(Zoom(C, dr)) = x C = Init(x,y,r) =>Get_Y(Zoom(C, dr)) = y With C: Circle ; x, y,dx, dy: integer; r, dr: float 57 Mạng Petri (Petri Nets) Thích hợp để mô tả các hệ thống không đồng bộ với những họat động đồng thời Mô tả luồng điều khiển của hệ thống Đề xuất năm 1962 bởi Carl Adam Có loại Mạng Petri (cổ điển) Mạng Petri mở rộng Mạng Petri Gồm các phần tử Một tập hữu hạn các nút (O) Một tập hữu hạn các chuyển tiếp () Một tập hữu hạn các cung (→) Các cung nối các nút với các chuyển tiếp hoặc ngược lại Mỗi nút có thể chứa một hoặc nhiều thẻ (z) 58 Mạng Petri Ví dụ: Mạng Petri Mạng Petri được định nghĩa bởi sự đánh dấu các nút của nó Việc đánh dấu các nút được tiến hành theo nguyên tắc sau: Mỗi chuyển tiếp có các nút vào và các nút ra Nếu tất cả các nút vào của một chuyển tiếp có ít nhất một thẻ, thì chuyển tiếp này có thể vượt qua được. Nếu chuyển tiếp này được thực hiện thì tất cả các nút vào của chuyển tiếp sẽ bị lấy đi một thẻ, và một thẻ sẽ được thêm vào tất cả các nút ra của chuyển tiếp Nếu chuyển tiếp là có thể vượt qua thì chọn chuyển tiếp nào cũng được 59 Mạng Petri Ví dụ Mạng Petri Ví dụ 60 Mạng Petri Ví dụ Mạng Petri Ví dụ 1: Mô tả hoạt động của đèn giao thông 61 Mạng Petri Ví dụ 1: Mô tả hoạt động của 2 đèn giao thông Mạng Petri Ví dụ 1: Mô tả hoạt động an toàn của 2đèn giao thông 62 Mạng Petri Ví dụ 1: Mô tả hoạt động an toàn của 2đèn giao thông Mạng Petri Ví dụ 2: Chu kì sống của con người 63 Mạng Petri Ví dụ 3: Viết thư và đọc thư Mạng Petri Ví dụ 4: Hệ thống cần mô tả bao gồm một nhà sản xuất, một nhà tiêu thụ và môt kho hàng chỉ chứa được nhiều nhất hai sản phẩm Nhà sản xuất có 2 trạng thái: P1: đang sản xuất P2: không sản xuất Nhà tiêu thụ có 2 trạng thái: C1: có sản phẩm để tiêu thụ C2: không có sản phẩm để tiêu thụ Kho hàng có 3 trạng thái Chứa 0 sản phẩm Chứa 1 sản phẩm Chứa 2 sản phẩm 64 Mạng Petri Ví dụ 4: mô tả tách rời mỗi thành phần Mạng Petri Ví dụ 4: Mô tả kết hợp các thành phần 65 So sánh các kỹ thuật đặc tả
File đính kèm:
- bai_giang_cong_nghe_phan_mem_phan_tich_va_dac_ta_yeu_cau_le.pdf