Bài giảng Phân tích và thiết kế hệ thống thông tin: Phần 3 - Nguyễn Anh Hào
lượt xem 3
download
Bài giảng "Phân tích và thiết kế hệ thống thông tin - Phần 3: Phân tích hệ thống" cung cấp cho người học các kiến thức: Hành động phân tích hệ thống, yêu cầu đ/v hệ thống từ môi trường, đặc tả hệ thống. Mời các bạn cùng tham khảo nội dung chi tiết.
Bình luận(0) Đăng nhập để gửi bình luận!
Nội dung Text: Bài giảng Phân tích và thiết kế hệ thống thông tin: Phần 3 - Nguyễn Anh Hào
- Phân tích & thiết kế H.T.T.T Phần 3: Phân tích hệ thống Nguyễn Anh Hào Khoa CNTT2 – HV CNBCVT Cơ sở Tp.HCM 0913609730 – nahao@ptithcm.edu.vn
- Nội dung bài giảng 2 1. Hành động phân tích hệ thống 2. Yêu cầu đ/v hệ thống từ môi trường 3. Đặc tả hệ thống • Coi hệ thống là một đối tượng lớn: ranh giới của nó tách hệ thống thành 2 phần: bên trong và bên ngoài • Nhìn từ ngoài: đặc tả những gì hệ thống sẽ làm cho môi trường (usecase) • Nhìn vào bên trong: đặc tả kết cấu các thành phần (đối tượng) cần thiết của hệ thống (classes) và các quan hệ giữa các đối tượng này.
- SE: phân tích hệ thống 3 • Trong SE, phân tích hệ thống: – Là quá trình chuyễn đổi yêu cầu đ/v hệ thống thành đặc tả về hệ thống. Các đặc tả này sẽ phải hiện thực trong hệ thống sau khi nó được “cải tạo”. – Đặc tả hệ thống = cấu trúc logic của hệ thống, nhìn từ phía người phát triễn hệ thống, trong đó: • Có các thành phần hợp thành hệ thống (các đối tượng) • Có các quan hệ nội tại giữa các thành phần, mà người phát triễn phải tìm ra và sử dụng chúng. • Yêu cầu đối với hệ thống: – Từ đâu ra ? Có phải là từ người sử dụng ? … Tất cả các câu hỏi này phải được giải đáp từ cách lý giải về sự tồn tại của hệ thống bằng lý thuyết hệ thống
- Sự tương tác của hệ thống 4 Đề thực hiện được vai trò, hệ thống phải có các tương tác với môi trường để tạo ra / lấy những thứ cần thiết cho / từ môi trường. Sự tương tác này hình thành các yêu cầu chức năng của hệ thống. Hệ thống là cổ máy biến inputs thành outputs cho môi trường
- Quan hệ giữa hệ thống - môi trường 5 • Hệ thống lớn (môi trường) phải giải quyết nhiều vấn đề để giúp nó tồn tại, được gọi là miền vấn đề (problem domain). – Vd: Công ty phải làm gì để tồn tại được ?... • Miền vấn đề chứa các vấn đề có tính quy luật (khách quan, và kết dính với nhau theo cách nào đó) – Vd: chuổi nghiệp vụ của tổ chức được xem là “bất biến” (khách quan) vì người ta có lý do để làm như vậy. – Domain Model: mô hình cho miền vấn đề • Hệ thống đang xem xét là một bộ phận của hệ thống lớn, do đó nó có vai trò hổ trợ giải quyết tốt các vấn đề của hệ thống lớn, thông qua các tương tác của nó.
- Yêu cầu từ môi trường 6 • Sự tương tác giữa hệ thống với môi trường bên ngoài hình thành yêu cầu đối với hệ thống (cái gì nó phải làm ra, và phải chuyễn giao như thế nào,…) • Yêu cầu (từ tương tác) được xác định đúng (giải quyết đúng bản chất của vấn đề trong miền vấn đề) thì hệ thống sẽ hoạt động ổn định (ít bị thay đổi). • Như vậy, khía cạnh đầu tiên của việc phân tích yêu cầu là hiểu đúng bản chất của các tương tác trong môi trường mà hệ thống sẽ vận hành. – Phân tích các quan hệ cộng tác với nhau ở bên ngoài (trong hệ thống lớn hơn) và có liên quan đến hệ thống.
- Cách đặc tả hệ thống (1) 7 A. Nhìn hệ thống từ bên ngoài (outside view – ‘what’): 1. Xác định phạm vi trách nhiệm (vai trò) của hệ thống. 2. Mô hình hóa các quy luật cộng tác trong môi trường có hệ thống tham gia. – Tìm ra các quy luật cộng tác mang tính bản chất – Vẽ Workflow,Dataflow,Collaboration,Activity, … 3. Xác định các tương tác cơ bản nhất, quyết định vai trò của hệ thống trong môi trường (Usecases) 4. Đặc tả ứng xử của hệ thống đ/v từng usecase – “Phương thức” của hệ thống, scenario
- Vai trò của use-case 8 Nhìn từ bên ngoài: Hệ thống sẽ làm được gì cho hệ thống lớn hơn (qua sự cộng tác với các actors) Use case Nhìn vào bên trong: Những đối tượng trong hệ thống hợp tác thực hiện use-case như thế nào ? Ranh giới của phần mềm
- Lược đồ use case: nhìn từ ngoài 9 1. Với các đối tượng có trong hệ thống lớn (môi trường): – Đối tượng nào cần hệ thống phần mềm này, hoặc phần mềm này cần đối tượng nào ? 2. Định nghĩa use-case – Sự hợp tác trên có ý nghĩa gì đối với hệ thống lớn ? 3. Định nghĩa actor – Vai trò của các đối tượng trong hệ thống lớn (hoặc đối với usecase) là gì ? 4. Vẽ lược đồ use case – nhìn từ bên ngoài cho hệ thống phần mềm
- ví dụ 1: coffee drink 10 Người ta cần gì ở tách cà phê ?
- Coffee cup: interfaces 11
- Coffee cup: use cases - external 12 Filling Drinking Pouring Holding Sitting Holding
- Ví dụ 2: Quản lý kho trong nhà hàng13 Tiền trả Nguyên liệu Nhà cung câp Kho Văn phòng (cung ứng) (lưu trữ) (điều khiển) Chính phủ Quy định Nguyên liệu (ra luật) Nhà bếp Thông tin, (chế biến) mệnh lệnh Đối thủ (cạnh tranh) Hàng hóa, Thức ăn Dịch vụ Khách hàng Quầy phục vụ (tiêu thụ) (bán) Tiền trả Tiền thu
- Các tương tác liên quan đến kho 14 “Trả tiền mua ….” Nhà cung câp Kho Văn phòng (cung ứng) (lưu trữ) (điều khiển) “Tôi đặt mua …” “Đề nghị trả tiền …” Người bán Thủ kho Giám đốc “Tôi giao …” “Tôi cần …” “Xuất … cho …” UML dùng thông điệp để diễn tả cho tương tác Nhà bếp (chế biến) Đầu bếp
- Thông điệp (message) 15 • Thông điệp là một thông báo mang yêu cầu hoặc phản hồi, gửi từ một đối tượng đến một đối tượng. • Trong UML, thông điệp được diễn tả là: [điều kiện] (thông sô) – [điều kiện]: điều kiện để thông điệp xuất hiện (biểu thức logic) – : tên của thông điệp – (thông số): các thuộc tính của nhóm thông điệp • Ví dụ, sau khi login, khách có thể đặt hàng trên website: [acc=valid] Đặt hàng (mã kh,mã hàng,số lượng, ngày)
- Kho của nhà hàng: Lược đồ cộng tác16 Trả tiền (tiền, hđ#) Đặt mua(hàng,slg) y/c trả tiền (tiền, hđ#) Người bán Thủ kho Giám đốc Giao(hàng,slg,hđ#) y/c xuất(hàng,slg, pyc#) Xuất (hàng,slg, pyc#) Đầu bếp Trong UML v2: lược đồ này gọi là communication diagram
- Quản lý kho: use-cases (a) 17 PM quản lý kho Đặt hàng Người bán Nhập kho y/c trả Giám đốc Thủ kho tiền Xuất Đầu bếp kho Phạm vi sử dụng của phần mềm (a): chỉ giới hạn ở các tương tác với thủ kho
- Quản lý kho:use-cases (b) 18 PM quản lý kho Đặt hàng Người bán Nhập kho y/c trả Thủ kho tiền Giám đốc Xuất kho Đầu bếp Phạm vi sử dụng của phần mềm (b): có các tương tác với thủ kho, người bán, giám đốc, và đầu bếp
- Ví dụ 3: hệ thống khóa cửa 19 • Hệ thống khóa cửa yêu cầu chìa khóa là số pin để mở cửa. Có 2 tình huống: số pin đúng và số pin sai Book_SE_2012.pdf Page 82
- Lược đồ tuần tự: chìa khóa đúng 20
CÓ THỂ BẠN MUỐN DOWNLOAD
-
Bài giảng Phân tích và thiết kế hệ thống thông tin: Chương 3 - PGS.TS. Nguyễn Mậu Hân
134 p | 54 | 7
-
Bài giảng Phân tích và thiết kế thuật toán: Bài 4 – Hà Đại Dương
23 p | 38 | 7
-
Bài giảng Phân tích và thiết kế hệ thống: Chương 4.1
30 p | 85 | 5
-
Bài giảng Phân tích và thiết kế hệ thống thông tin: Chương 1 - PGS.TS. Nguyễn Mậu Hân
82 p | 62 | 4
-
Bài giảng Phân tích và thiết kế hệ thống thông tin: Phân 1 - ĐH Phạm Văn Đồng
62 p | 64 | 4
-
Bài giảng Phân tích và thiết kế thuật toán: Bài 2 – Hà Đại Dương
25 p | 48 | 4
-
Bài giảng Phân tích và thiết kế thuật toán: Bài 3 – Hà Đại Dương
26 p | 40 | 4
-
Bài giảng Phân tích và thiết kế hệ thống: Chương 1 - Nguyễn Nhật Quang
12 p | 22 | 3
-
Bài giảng Phân tích và thiết kế hệ thống: Chương 5 - Nguyễn Nhật Quang
35 p | 17 | 3
-
Bài giảng Phân tích và thiết kế hệ thống: Chương 9 - Nguyễn Nhật Quang
44 p | 13 | 3
-
Bài giảng Phân tích và thiết kế hệ thống: Chương 3.1
11 p | 79 | 3
-
Bài giảng Phân tích và thiết kế mạng: Chương 3 – Vũ Chí Cường
25 p | 37 | 3
-
Bài giảng Phân tích và thiết kế mạng: Chương 2 – Vũ Chí Cường
17 p | 55 | 3
-
Bài giảng Phân tích và thiết kế hệ thống: Chương 10 - Nguyễn Nhật Quang
58 p | 15 | 3
-
Bài giảng Phân tích và thiết kế thuật toán: Bài 1 – Hà Đại Dương
18 p | 38 | 3
-
Bài giảng Phân tích và thiết kế hệ thống: Chương 3.2
19 p | 80 | 3
-
Bài giảng Phân tích và thiết kế thuật toán
26 p | 127 | 2
-
Bài giảng Phân tích và thiết kế mạng: Chương 1 – Vũ Chí Cường
14 p | 39 | 2
Chịu trách nhiệm nội dung:
Nguyễn Công Hà - Giám đốc Công ty TNHH TÀI LIỆU TRỰC TUYẾN VI NA
LIÊN HỆ
Địa chỉ: P402, 54A Nơ Trang Long, Phường 14, Q.Bình Thạnh, TP.HCM
Hotline: 093 303 0098
Email: support@tailieu.vn