37 trang 5 lượt tải

Giáo trình môn Phân tích và thiết kế hệ thống | Trường Đại học Bách Khoa Hà Nội

10

Hệ thống được tạo ra để giải quyết vấn đề, gồm một tập các thành phần hoạt động cùng nhau để hiện thực hóa một mục tiêu. Ba thành phần phụ thuộc lẫn nhau của một hệ thống: Input, Process, Output. Tài liệu được sưu tầm gồm 37 trang, giúp các bạn nắm vững kiến thức, rèn luyện kỹ năng và đạt được kết quả tốt trong học tập. Mời các bạn đón xem!

Môn: Phân tích và thiết kế hệ thống hust 10 tài liệu

Trường: Đại học Bách Khoa Hà Nội 3.4 K tài liệu

Tác giả:

Profile

My Lữ

1 tuần trước
Danh sách Quiz
/37
Phân ch thiết kế hệ thống
Kim Cường Nguyễn
June 2025
Mục lục
1 Tổng quan phân ch thiết kế hệ thống 2
1.1 Giới thiệu phân ch và thiết kế hệ thống . . . . . . . . . . . . 2
1.1.1 Định nghĩa hệ thống . . . . . . . . . . . . . . . . . . . 2
1.1.2 Định nghĩa hệ thống thông n . . . . . . . . . . . . . . 3
1.1.3 Phân ch và thiết kế hệ thống . . . . . . . . . . . . . . 3
1.2 Vòng đời phát triển hệ thống . . . . . . . . . . . . . . . . . . 4
1.2.1 Khái niệm . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Các hướng ếp cận phát triển hệ thống . . . . . . . . . 6
1.2.3 Chi ết một số SDLC . . . . . . . . . . . . . . . . . . 8
1.3 Quản trị dự án . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.4 Giới thiệu UML . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2 Phân ch hệ thống 17
2.1 Phân ch yêu cầu . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.1 Mục đích . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.2 Phương pháp ến hành . . . . . . . . . . . . . . . . . . 19
2.1.3 Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3 Thiết kế hệ thống 23
3.1 Sơ lược về thiết kế hệ thống . . . . . . . . . . . . . . . . . . . 23
3.1.1 Mục đích của thiết kế . . . . . . . . . . . . . . . . . . . 23
3.1.2 Vai trò của thiết kế hệ thống . . . . . . . . . . . . . . 23
3.1.3 Đầu vào cho thiết kế . . . . . . . . . . . . . . . . . . . 23
3.1.4 Đầu ra cho thiết kế . . . . . . . . . . . . . . . . . . . . 24
3.1.5 Tư duy thiết kế . . . . . . . . . . . . . . . . . . . . . . 26
3.2 Thiết kế kiến trúc . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.1 Mục đích của thiết kế kiến trúc tổng thể . . . . . . . . 26
3.2.2 Phân rã hệ thống thành các hệ thống con . . . . . . . 27
3.2.3 Mô tả các thành phần vật lý của hệ thống . . . . . . . 29
3.2.4 Bố trí các thành phần khả thi vào các nút phần cứng . 32
3.2.5 Các kiến trúc phổ biến . . . . . . . . . . . . . . . . . . 34
3.2.6 Nợ kỹ thuật . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2.7 Thiết kế để dễ kiểm thử . . . . . . . . . . . . . . . . . 42
3.2.8 Yêu cầu phi chức năng . . . . . . . . . . . . . . . . . . 43
3.2.9 Các nguyên tắc thiết kế . . . . . . . . . . . . . . . . . 44
3.3 Thiết kế giao diện . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.4 Thiết kế lớp và cơ sở dữ liệu . . . . . . . . . . . . . . . . . . . 45
1 Tổng quan phân ch thiết kế hệ thống
1.1 Giới thiệu phân ch và thiết kế hệ thống
1.1.1 Định nghĩa hệ thống
• Hệ thống được tạo ra để giải quyết vấn đề, gồm một tập các thành phần hoạt
động cùng nhau để hiện thực hóa một mục êu.
• Ba thành phần phụ thuộc lẫn nhau của một hệ thống:
– Input
– Process
– Output
• Ví dụ:
– Cơ thể người
– Hệ thống pháp luật
– Hệ thống kinh tế – Hệ thống giáo dục
– ...
– Một hệ thống tốt có thêm một thành phần "điều khiển" cung cấp
phản hồi để đạt được mục êu mong muốn.
1.1.2 Định nghĩa hệ thống thông n
• Một tập các thành phần phụ thuộc lẫn nhau mà thu thập, xử lý, lưu trữ và
cung cấp thông n đầu ra để hoàn thành một quy trình nghiệp vụ.
1.1.3 Phân ch và thiết kế hệ thống
Hình 1: Phát triển một hệ thống thông n
1. Phân ch hệ thống
• Định nghĩa
– Là một tập các hoạt động để hiểu và đặc tả NHỮNG GÌ mà hệ
thống có thể làm và hoàn thành
• Ví dụ
– Một hệ thống quản lý khách hàng cần phải:
∗ Đăng ký sản phẩm
∗ Quản lý bảo hiểm
∗ Tracking Khách hàng
2. Thiết kế hệ thống
• Định nghĩa
– Là một tập các hoạt động diễn tả chi ết hệ thống thông n thực
hiện các hoạt động NHƯ THẾ NÀO.
Hình 2: Phân ch và thiết kế
1.2 Vòng đời phát triển hệ thống
1.2.1 Khái niệm
1. Các pha trong vòng đời
Hình 3: Các pha trong vòng đời phát triển hệ thống
(a) Lập kế hoạch • Khởi tạo dự án
– Chuẩn bị yêu cầu dự án
– Phân ch ền khả thi
• Chuẩn bị dự án
– Kế hoạch dự án, kế hoạch hoạt động, kế hoạch nhân sự, kế
hoạch quản lý sử dụng tài nguyên.
(b) Phân ch
• Phân ch nhu cầu người dùng.
• Tạo tài liệu đặc tả yêu cầu chức năng.
• Nghiên cứu các hệ thống có sẵn và định nghĩa hệ thống mới
(c) Thiết kế
• Chuyển tài liệu đặc tả yêu cầu chức năng thành tài liệu đặc tả
thiết kế chi ết, tập trung vào HOW
• Xác định chiến lược thiết kế: Build/Buy/Outsource
• Thiết kế thành phần: Kiến trúc, Giao diện, Database, Chương
trình
• Hợp nhất các thành phần thành đặc tả hệ thống (d) Cài đặt
• Tích hợp và kiểm thử
• Tập huấn, chuyển giao
• Hỗ trợ, bảo trì
Hình 4: Mở rộng SDLC 10 pha
1.2.2 Các hướng ếp cận phát triển hệ thống
1. Tiếp cận dự đoán • Hướng ếp cận dự đoán giả định rằng dự án được lập
kế hoạch và tổ chức trước. Do đó hệ thống thông n có thể phát triển dựa
vào kế hoạch.
• Mô hình thác nước
2. Tiếp cận thích nghi • Linh hoạt hơn, giả định rằng dự án không thể lập một
kế hoạch cụ thể trước do đó cần được sửa đổi xuyên suốt toàn bộ ến
trình.
• Phát triển lặp
– Hệ thống phát triển một cách có tổ chức, phát triển các thành
phần lõi trước và thêm các thành phần phụ sau, tất cả được lặp
cho đến khi hệ thống hoàn thiện.
– Six Core Processes:
(a) Xác định vấn đề và xin chấp thuận
(b) Lập kế hoạch điều phối dự án
(c) Hiểu chi ết
(d) Thiết kế các thành phần
(e) Tích hợp các thành phần
(f) Triển khai
– Lượng công việc của mỗi vòng lặp cho mỗi ến trình phụ thuộc
vào:
∗ Dự án
∗ Hướng ếp cận ∗ Kết quả
vòng lặp trước
– Trong vòng lặp đầu, các công việc chủ yếu ở ến trình (a),
(b), (c).
– Trong vòng lặp cuối, các công việc chủ yếu ở các ến trình sau.
– Mỗi vòng lặp kéo dài từ 2-4 tuần.
3. Phương pháp luận về phát triển hệ thống • Là một tập các hướng dẫn bao
quát toàn bộ hoạt động trong SDLC bao gồm mô hình cụ thể, công cụ, kỹ
thuật.
• Dựa vào kinh nghiệm hoặc được tư vấn.
4. Các mô hình
• Là biểu diễn của một khía cạnh quan trọng trong thế giới thực.
• Mô hình thành phần hệ thống
– Flowchart
– DFD
– ERD
– Structure chart
– UC Diagram
– Class Diagram
– Sequence Diagram
• Mô hình quản lý quy trình phát triển
– GANTT
– Mô hình phân ch tài chính ROI, NPV
– Biểu đồ tổ chức phân cấp
5. Các công cụ • Là các phần mềm hỗ trợ tạo các mô hình hoặc các thành
phần khác yêu cầu trong dự án
• Công cụ quản trị dự án
• Công cụ trực quan hóa mô hình
• Công cụ phát triển, lập trình
6. Các kỹ thuật • Các hướng dẫn để hoàn thành nhiệm vụ: Thu thập thông n,
tạo các mô hình,...
• Một số kỹ thuật:
– Lập kế hoạch, quản lý, phỏng vấn
– Mô hình hóa dữ liệu, thiết kế CSDL quan hệ
– Phân ch, thiết kế, lập trình, kiểm thử
1.2.3 Chi ết một số SDLC
1. Mô hình thác nước
Hình 5: Mô hình thác nước
• Các giai đoạn không giao nhau, không lặp lại
• Ưu điểm:
– Dễ hiểu, dễ sử dụng
– Tài liệu được tổng hợp sau mỗi giai đoạn
– Yêu cầu phần mềm được cung cấp sớm cho Tester
– Lập kế hoạch, quản lý chặt chẽ
• Nhược điểm:
– Chỉ phù hợp nếu yêu cầu được xác định và cố định từ đầu
– Không phù hợp với dự án kéo dài
– Rủi ro và không chắc chắn
– Khó có sớm các kết quả ban đầu của phần mềm
• Nên áp dụng khi:
– Thời gian thực hiện ngắn
– Yêu cầu được xác định rõ, ổn định, đầy đủ
– Nắm vững công nghệ
– Nguồn lực đủ đáp ứng
2. Mô hình nguyên mẫu • Một số nguyên mẫu (không phải phần mềm hoàn
thiện) được tạo ra để hiểu chính xác yêu cầu phần mềm
• Ưu điểm:
– Có sự tham gia của người dùng, sớm thu được phản hồi
– Phát hiện sớm lỗi, vấn đề, chức năng thiếu, không rõ ràng, khó
thao tác
• Nhược điểm:
– Không nhất quán trong diễn đạt yêu cầu do khiến người dùng
thấy phát triển phần mềm dễ dàng
– Vấn đề kéo dài, không ổn định trong quản trị dự án
– Người phát triển có xu hướng bàn giao một nguyên mẫu cơ bản
chứ không bàn giao sản phẩm hoàn thiện
• Nên dùng khi:
– Yêu cầu không thể xác định từ khi bắt đầu dự án
– Phù hợp để phát triển cảm nhận, giao diện sử dụng của hệ thống
– Khách hàng cần chứng minh nh khả thi
– Khi cần thực nghiệm, demo, kiểm tra
3. Mô hình xoắn ốc • Lai ghép lặp của mô hình nguyên mẫu và tuần tự của
mô hình thác nước, chú trọng vào phân ch nguy cơ.
• Trong các bước lặp đầu, các phiên bản chỉ là các mô hình được phác
thảo trên giấy.
• Trong các bước lặp sau, các phiên bản ngày càng hoàn thiện hơn của
hệ thống sẽ được tạo ra.
• Ưu điểm:
– Chú trọng vào phân ch rủi ro
– Phù hợp với các dự án lớn, quan trọng
– Phiên bản đầu được tạo ra sớm, các nh năng mới được thêm
vào sau
• Nhược điểm
– Chi phí cao
– Đòi hỏi kỹ năng, kinh nghiệm cao
– Thành công phụ thuộc vào phân ch rủi ro
– Không phù hợp với dự án nhỏ
• Nên dùng khi
– Phân ch rủi ro là quan trọng
– Dự án có rủi ro trung bình đến cao
– Người dùng không chắc chắn về nhu cầu, yêu cầu phức tạp, lớn.
– Phát triển dòng sản phẩm mới, thay đổi quan trọng
4. Mô hình hợp nhất
• Kết hợp góc nhìn quản lý dự án và góc nhìn kỹ thuật
Hình 6: Góc nhìn quản trị dự án
Hình 7: Góc nhìn kỹ thuật
Hình 8: Kết hợp hai góc nhìn
5. Quy trình RUP
• Là một quy trình mô hình hóa với UML chứ không phải một chuẩn •
Các nguyên tắc cơ bản
– Lặp và tăng trưởng: Chia thành giai đoạn ngắn và thêm dần các
thành phần
– Tập trung vào kiến trúc: Chia hệ thống thành các mô đun và kiến
trúc được trình bày theo 5 góc nhìn khác nhau
– Dẫn dắt theo ca sử dụng: Thể hiện nhu cầu người dùng ảnh
hưởng xuyên suốt toàn hệ thống, cơ sở xác định vòng lặp tăng
trưởng, căn cứ để phân chia công việc
∗ Nắm bắt nhu cầu: Phát hiện ca sử dụng
∗ Phân ch: Đi sâu vào ca sử dụng
∗ Thiết kế cài đặt: Xây dựng theo ca sử dụng
∗ Kiểm thử: Thực hiện theo ca sử dụng
– Khống chế nguy cơ
• Các giai đoạn
– Giai đoạn khởi đầu:
∗ Cái nhìn tổng quát về hệ thống: chức năng, hiệu năng, công
nghệ
∗ Dự án PTPM sẽ triển khai: Phạm vi, mục êu, nh khả thi
– Giai đoạn chi ết hóa
∗ Phân ch chi ết hơn: Chức năng và cấu trúc nh
∗ Đề xuất một kiến trúc hệ thống (Nguyên mẫu)
– Giai đoạn xây dựng
∗ Tập trung vào thiết kế và cài đặt
∗ Chi ết hóa kiến trúc hệ thống
∗ Kết thúc khi đã cho ra một hệ thống hoàn chỉnh và các tài liệu
kiến trúc đi kèm
∗ Là giai đoạn tốn nhiều công sức nhất
– Giai đoạn chuyển giao ∗ Chuyển giao cho người dùng cuối:
chuyển đổi dữ liệu, kiểm tra, lắp đặt, đào tạo
• Các bước chính
– Nghiên cứu sơ bộ
– Nhận định, đặc tả các ca sử dụng
– MHH lĩnh vực
– Xác định các lớp tham gia ca sử dụng
– MHH tương tác: trình tự, giao ếp
– MHH ứng xử: máy trạng thái
– Làm nguyên mẫu giao diện
– Thiết kế kiến trúc
– Thiết kế chi ết
– Cài đặt
1.3 Quản trị dự án
1.4 Giới thiệu UML
1. UML - Ngôn ngữ MHH• UML dùng để mô hình hóa trực quan, đặc tả, xây
dựng, làm tài liệu
• Có thể sử dụng trong bất kỳ ến trình phát triển hệ thống
2. Các góc nhìn UML• UML cung cấp các biểu đồ (mô hình để diễn tả hệ
thống), mỗi mô hình chỉ diễn tả theo một góc nhìn nhất định. • UML cung
cấp 5 góc nhìn, mỗi góc nhìn được thực hiện bởi một số biểu đồ. Góc nhìn
(1) — (n) Biểu đồ
• Có thể có biểu đồ phụ thuộc vào nhiều góc nhìn khác nhau
• Mỗi vai trò trong quá trình phát triển (phân ch, thiết kế, ch hợp,..)
thường chỉ quan tâm đến một góc nhìn nào đó của hệ thống
• 5 góc nhìn bổ trợ nhau trong đó góc nhìn ca sử dụng có ảnh hưởng
đến 4 góc nhìn còn lại
• Góc nhìn ca sử dụng
– Góc nhìn từ ngoài vào hệ thống của người dùng cuối, người phân
ch
– Chỉ làm rõ các nh năng chính cần đáp ứng cho người dùng
– Sắc thái nh: Biểu đồ UC
– Sắc thái động: Biểu đồ giao ếp, Máy trạng thái, Biểu đồ hoạt
động
• Góc nhìn thiết kế
– Còn được gọi là góc nhìn logic, bên trong cho thấy nghiệp vụ của
hệ thống, của người thiết kế hệ thống.
– Sắc thái nh: Biểu đồ lớp, Biểu đồ đối tượng,Biểu đồ gói
– Sắc thái động: Biểu đồ trình tự, Biểu đồ giao ếp, biểu đồ máy
trạng thái, biểu đồ hoạt động.
• Góc nhìn quá trình
– Còn được gọi là góc nhìn song hành, phản ánh quá trình điều
khiển, quá trình thực hiện, cho thấy sự hoạt động đồng bộ của
hệ thống.
– Biểu diễn bằng các biểu đồ như trong góc nhìn thiết kế, tập trung
vào các lớp chủ động: Các lớp biểu diễn cho các quá trình điều
khiển và các quá trình thực hiện.
• Góc nhìn thực thi
– Còn được gọi là góc nhìn thành phần, cho thấy các thành phân
và tập n tương đối độc lập được lắp ráp lại để hệ thống chạy
được
– Sắc thái nh: Biểu đồ thành phần
– Sắc thái động: Biểu đồ hoạt động, biểu đồ giao ếp, biểu đồ máy
trạng thái
• Góc nhìn triển khai
– Góc nhìn về kiến trúc phần cứng và nền tảng hạ tầng mà trên đó
hệ thống được triển khai, thể hiện sự lắp đặt của các thành phần
hệ thống trên đơn vị nền tảng
– Sắc thái nh: Biểu đồ triển khai
– Sắc thái động: Biểu đồ giao ếp, biểu đồ hoạt động, Biểu đồ máy
trạng thái
3. Các biểu đồ của UML 2.0
• Các biểu đồ về cấu trúc
– Biểu đồ lớp
– Biểu đồ đối tượng
– Biểu đồ triển khai
– Biểu đồ gói
– Biểu đồ thành phần – Biểu đồ cấu trúc đa hợp
• Các biểu đồ về hành vi
– Biểu đồ ca sử dụng
– Biểu đồ hoạt động
– Biểu đồ trình tự
– Biểu đồ giao ếp
– Biểu đồ máy trạng thái
– Biểu đồ thời gian
– Biểu đồ tổng quan tương tác
4. Bổ sung ý nghĩa cho các biểu đồ
• Đặc tả: phát biểu dạng văn bản
• Tô điểm: Các vai trò, cơ số, hạn định, đường viền
• Khuôn dập: chuỗi ký tự đặt trong ngoặc kép «», biểu tượng gắn thêm
vào để tạo phần tử mới.
• Tính chất và giá trị gán nhãn: Đưa thêm thông n
• Ràng buộc: Thêm điều kiện
5. Mô hình hóa với UML
• Theo nhiều góc nhìn
• Theo mức độ trừu tượng hóa khác nhau
2 Phân ch hệ thống
2.1 Phân ch yêu cầu
2.1.1 Mục đích
• Đây là bước nghiên cứu sơ bộ về môi trường, hoàn cảnh nghiệp vụ của hệ
thống sắp xây dựng, gồm:
– Gợi mở yêu cầu – Làm rõ yêu cầu
– Nắm bắt yêu cầu
• Nhận định các yêu cầu chức năng, phi chức năng, nguy cơ, ràng buộc
• Xác lập và hoạch định dự án
• Trả lời câu hỏi khả thi
1. Xác định yêu cầu
• Yêu cầu người dùng
– Viết cho khách hàng.
– Đầu vào chính để tạo nên yêu cầu hệ thống.
– Ngôn ngữ tự nhiên + sơ đồ: dịch vụ hệ thống cung cấp + ràng
buộc.
• Yêu cầu hệ thống:
– Tài liệu có cấu trúc + chi ết: chức năng + dịch vụ + ràng buộc
– Định nghĩa cái gì cần được cài đặt, có thể là một phần của bản
hợp đồng
2. Phân loại yêu cầu
Hình 9: Phân loại yêu cầu
(a) Yêu cầu chức năng
i. Khái niệm • Là danh sách các công việc được thực hiện trên hệ
thống cùng thông n mô tả tương ứng. ii. Yêu cầu chức năng nghiệp
vụ
• Các chức năng của phần mềm tương ứng với các công việc
có thật trong thế giới thực.
• Có 4 loại chức năng chính tương ứng với 4 loại nghiệp vụ –
Chức năng lưu trữ:
∗ Tương tự công việc ghi chép sổ sách ∗ VD: Ghi nhận điểm
thi kết thúc học phần của sinh viên
– Chức năng tra cứu:
∗ Tương tự công việc m kiếm và xem thông n tương ứng
∗ VD: m sách, xem nh trạng sách
– Chức năng nh toán∗ Tương tự với các công việc nh
toán theo công thức, quy định cho trước.
∗ VD: Tính ền phạt trả sách trễ hạn
– Chức năng kết xuất
∗ Tương ứng với chức năng tạo báo cáo (theo biểu mẫu
cho trước)
∗ Lập báo cáo thống kê về số lượng mượn sách theo từng
thể loại trong năm.
iii. Yêu cầu chức năng hệ thống
• Là chức năng phải phát sinh thêm khi ến hành các công việc
trên máy nh thay vì trên thực tế.
• Là chức năng không tương ứng với bất kỳ công việc nào trong
thế giới thực (có nhu cầu nhưng không thể thực hiện thủ
công)
• Một số yêu cầu chức năng hệ thống thông dụng
– Phân quyền hệ thống
– Sao lưu, backup, phục hồi thông n
– Định cấu hình thiết bị, ngày giờ làm việc
– Báo động, nhắc nhở người dùng
– Mô phỏng hoạt động thế giới thực
(b) Yêu cầu phi chức năng i. Khái niệm
• Các yêu cầu liên quan tới chất lượng phần mềm.
• Là sự ràng buộc trên cách thực hiện các yêu cầu chức năng.
ii. Phân loại
• Yêu cầu về sản phẩm
– Yêu cầu khả dụng, khả chuyển, n cậy
– Yêu cầu về hiệu quả, hiệu năng, không gian, tốc độ xử lý
• Yêu cầu về tổ chức
– Yêu cầu về chuyển giao
– Yêu cầu về triển khai
– Yêu cầu về chuẩn
• Yêu cầu mở rộng
– Yêu cầu về hoạt động bên trong
– Yêu cầu về đạo đức, pháp lý
– Yêu cầu về cá nhân, an toàn
2.1.2 Phương pháp ến hành
2.1.3 Use Case
1. Các khái niệm liên quan
• Là cốt lõi để định nghĩa các yêu cầu chức năng của hệ thống, đại diện
cho một hoạt động hệ thống thực hiện để đáp ứng yêu cầu từ người
dùng hoặc tác nhân
• Có hai kỹ thuật chính để phát triển các ca sử dụng: User Goal
Technique và Event Decomposion Technique
(a) User Goal Technique
Xác định CSD dựa trên vai trò và mục êu của người dùng • Xác định,
phân loại người dùng theo vai trò chức năng, cấp độ tổ chức
• Phỏng vấn người dùng
• Đặt tên ca sử dụng: Động từ - Danh từ mệnh lệnh. VD: Cập nhật
đơn hàng
• Tạo danh sách ca sử dụng theo phân loại người dùng
• Tìm kiếm trùng lặp. VD: Các người dùng khác nhau có cùng ca sử
dụng
• Xem xét danh sách đã cập nhật với người dùng và các bên liên
quan
(b) Event Decomposion Technique
Xác định CSD dựa trên các sự kiện nghiệp vụ mà hệ thống cần xử lý •
Khó khăn trong xác định mức độ chi ết phù hợp:
– Được thực hiện bởi một người
– Đem lại giá trị có thể đo lường được
– Để lại hệ thống và dữ liệu trong một trạng thái ổn định
• Được gọi là Quy trình nghiệp vụ cơ bản (EBP)
2. Các loại sự kiện
(a) Sự kiện bên ngoài
• Có thể được kích hoạt bởi các tác nhân bên ngoài, thậm chí là
nhân viên hoặc các phòng ban:
– Tác nhân bên ngoài muốn một điều gì đó dẫn tới một giao
dịch
– Tác nhân bên ngoài/quản lý muốn một số thông n
– Dữ liệu thay đổi và cần được cập nhật
• VD: "Khách hàng thanh toán hóa đơn", "Khách hàng thực hiện
một khoản nợ", "Khách hàng thay đổi địa chỉ"
(b) Sự kiện thời gian• Một sự kiện xảy ra khi đạt đến một thời gian nhất
định:
– Deadline xảy đến những khi nào
– Đầu ra nào ứng với deadline
• VD: Báo cáo, lời nhắc,...
(c) Sự kiện trạng thái
• Còn được gọi là sự kiện nội bộ
• Sự kiện xảy ra khi có điều gì đó bên trong hệ thống mà kích hoạt
một nhu cầu xử lý.
3. Xác định sự kiện
(a) Tên sự kiện
• Gom các hành động nhỏ thành một chuỗi hành động có ý nghĩa
nghiệp vụ
• Bỏ qua các sự kiện liên quan đến kiểm soát hệ thống: Đảm bảo
nh bảo mật, xác thực, toàn vẹn; hay các sự kiện liên quan đến
kỹ thuật: API, giao diện,..
=> Duy trì sự trừu tượng, đơn giản hóa, tập trung vào phân ch
• Tên sự kiện = Tên tác nhân + Hành động
(b) Các bước tóm tắt để phân rã
• Xác định sự kiện bên ngoài, đặt tên CSD
• Xác định sự kiện thời gian, xác định thời điểm kích hoạt, đặt tên
CSD
• Xác định sự kiện trạng thái, đặt tên CSD, xác định sự thay đổi
trạng thái
• Kiểm tra lại các Use Case, bỏ qua các kiểm soát hệ thống, bỏ qua
sự kiện kỹ thuật
• Bảng sự kiện: Danh mục thông n về các Use Case tạo nên yêu
cầu chức năng của hệ thống
4. Đặc tả UseCase
5. Các đối tượng • Mô hình hóa các đối tượng mà hệ thống cần lưu trữ thông
n, những thứ cần là một phần của hệ thống. VD: sản phẩm, đơn hàng,
hóa đơn, khách hàng.
• Các đối tượng tương tự các tác nhân ngoài nhưng khác ở chỗ cần lưu
trữ thông n
(a) Xác định các đối tượng
(b) Mối quan hệ và thuộc nh các đối tượng
• Mối quan hệ và lực lượng của quan hệ
• Thuộc nh
• Định danh
• Thuộc nh hỗn hợp: Tập các thuộc nh
• Sơ đồ thực thể liên kết
3 Thiết kế hệ thống
3.1 Sơ lược về thiết kế hệ thống
3.1.1 Mục đích của thiết kế
• Phân ch: trả lời cho câu hỏi WHAT, tập trung vào các yêu cầu (chức năng và
phi chức năng), gồm 6 bước đầu ên trong 10 bước của quy trình RUP
• Thiết kế: trả lời cho câu hỏi HOW, đáp ứng yêu cầu phi chức năng, đưa ra
những thiết kế phù hợp với công nghệ được chọn
Hình 10: Phân ch vs Thiết kế
3.1.2 Vai trò của thiết kế hệ thống
• Cầu nối từ "yêu cầu" tới "mã nguồn"
• Quyết định nh linh hoạt, khả năng bảo trì, mở rộng của hệ thống
• Tiết kiệm chi phí phát triển và thời gian trong dài hạn
• Giảm thiểu nợ kỹ thuật
• Tạo nền tảng vững chắc cho quá trình phát triển
3.1.3 Đầu vào cho thiết kế
• Ca sử dụng (Tương tác và luồng xử lý)
• Mô hình lớp lĩnh vực (Thực thể và mối quan hệ)
• Ràng buộc hệ thống (Thời gian, Ngân sách, Công nghệ)
• Yêu cầu hiệu suất (Thời gian phản hồi, thông lượng)
• Yêu cầu bảo mật (Xác thực, ủy quyền, mã hóa)
• Yêu cầu khả năng mở rộng (Số lượng người dùng, dữ liệu)
3.1.4 Đầu ra cho thiết kế
• Thiết kế kiến trúc (Cấu trúc tổng thể của hệ thống)
• Sơ đồ thành phần/lớp (Chi ết các mô đun và lớp)
• Đặc tả giao diện (UI/API)
• Mô hình dữ liệu (Cấu trúc CSDL)
• Mô hình bảo mật (Cơ chế xác thực và phân quyền)
• Kế hoạch triển khai (Hạ tầng, cấu hình)

Tài liệu khác của Đại học Bách Khoa Hà Nội

Preview text:

Phân tích thiết kế hệ thống Kim Cường Nguyễn June 2025 Mục lục
1 Tổng quan phân tích thiết kế hệ thống 2
1.1 Giới thiệu phân tích và thiết kế hệ thống . . . . . . . . . . . . 2
1.1.1 Định nghĩa hệ thống . . . . . . . . . . . . . . . . . . . 2
1.1.2 Định nghĩa hệ thống thông tin . . . . . . . . . . . . . . 3
1.1.3 Phân tích và thiết kế hệ thống . . . . . . . . . . . . . . 3
1.2 Vòng đời phát triển hệ thống . . . . . . . . . . . . . . . . . . 4
1.2.1 Khái niệm . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Các hướng tiếp cận phát triển hệ thống . . . . . . . . . 6
1.2.3 Chi tiết một số SDLC . . . . . . . . . . . . . . . . . . 8
1.3 Quản trị dự án . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.4 Giới thiệu UML . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2 Phân tích hệ thống 17
2.1 Phân tích yêu cầu . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.1.1 Mục đích
. . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.2 Phương pháp tiến hành . . . . . . . . . . . . . . . . . . 19
2.1.3 Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3 Thiết kế hệ thống 23
3.1 Sơ lược về thiết kế hệ thống . . . . . . . . . . . . . . . . . . . 23
3.1.1 Mục đích của thiết kế . . . . . . . . . . . . . . . . . . . 23
3.1.2 Vai trò của thiết kế hệ thống . . . . . . . . . . . . . . 23
3.1.3 Đầu vào cho thiết kế . . . . . . . . . . . . . . . . . . . 23
3.1.4 Đầu ra cho thiết kế . . . . . . . . . . . . . . . . . . . . 24
3.1.5 Tư duy thiết kế . . . . . . . . . . . . . . . . . . . . . . 26
3.2 Thiết kế kiến trúc . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.1 Mục đích của thiết kế kiến trúc tổng thể . . . . . . . . 26
3.2.2 Phân rã hệ thống thành các hệ thống con . . . . . . . 27
3.2.3 Mô tả các thành phần vật lý của hệ thống . . . . . . . 29
3.2.4 Bố trí các thành phần khả thi vào các nút phần cứng . 32
3.2.5 Các kiến trúc phổ biến . . . . . . . . . . . . . . . . . . 34
3.2.6 Nợ kỹ thuật . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2.7 Thiết kế để dễ kiểm thử . . . . . . . . . . . . . . . . . 42
3.2.8 Yêu cầu phi chức năng . . . . . . . . . . . . . . . . . . 43
3.2.9 Các nguyên tắc thiết kế
. . . . . . . . . . . . . . . . . 44
3.3 Thiết kế giao diện . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.4 Thiết kế lớp và cơ sở dữ liệu . . . . . . . . . . . . . . . . . . . 45 1
Tổng quan phân tích thiết kế hệ thống 1.1
Giới thiệu phân tích và thiết kế hệ thống
1.1.1 Định nghĩa hệ thống
• Hệ thống được tạo ra để giải quyết vấn đề, gồm một tập các thành phần hoạt
động cùng nhau để hiện thực hóa một mục tiêu.
• Ba thành phần phụ thuộc lẫn nhau của một hệ thống: – Input – Process – Output • Ví dụ: – Cơ thể người – Hệ thống pháp luật
– Hệ thống kinh tế – Hệ thống giáo dục – ...
– Một hệ thống tốt có thêm một thành phần "điều khiển" cung cấp
phản hồi để đạt được mục tiêu mong muốn.
1.1.2 Định nghĩa hệ thống thông tin
• Một tập các thành phần phụ thuộc lẫn nhau mà thu thập, xử lý, lưu trữ và
cung cấp thông tin đầu ra để hoàn thành một quy trình nghiệp vụ. 1.1.3
Phân tích và thiết kế hệ thống
Hình 1: Phát triển một hệ thống thông tin 1. Phân tích hệ thống • Định nghĩa
– Là một tập các hoạt động để hiểu và đặc tả NHỮNG GÌ mà hệ
thống có thể làm và hoàn thành • Ví dụ
– Một hệ thống quản lý khách hàng cần phải: ∗ Đăng ký sản phẩm ∗ Quản lý bảo hiểm ∗ Tracking Khách hàng 2. Thiết kế hệ thống • Định nghĩa
– Là một tập các hoạt động diễn tả chi tiết hệ thống thông tin thực
hiện các hoạt động NHƯ THẾ NÀO.
Hình 2: Phân tích và thiết kế 1.2
Vòng đời phát triển hệ thống 1.2.1 Khái niệm
1. Các pha trong vòng đời
Hình 3: Các pha trong vòng đời phát triển hệ thống
(a) Lập kế hoạch • Khởi tạo dự án
– Chuẩn bị yêu cầu dự án
– Phân tích tiền khả thi • Chuẩn bị dự án
– Kế hoạch dự án, kế hoạch hoạt động, kế hoạch nhân sự, kế
hoạch quản lý sử dụng tài nguyên. (b) Phân tích
• Phân tích nhu cầu người dùng.
• Tạo tài liệu đặc tả yêu cầu chức năng.
• Nghiên cứu các hệ thống có sẵn và định nghĩa hệ thống mới (c) Thiết kế
• Chuyển tài liệu đặc tả yêu cầu chức năng thành tài liệu đặc tả
thiết kế chi tiết, tập trung vào HOW
• Xác định chiến lược thiết kế: Build/Buy/Outsource
• Thiết kế thành phần: Kiến trúc, Giao diện, Database, Chương trình
• Hợp nhất các thành phần thành đặc tả hệ thống (d) Cài đặt
• Tích hợp và kiểm thử
• Tập huấn, chuyển giao • Hỗ trợ, bảo trì
Hình 4: Mở rộng SDLC 10 pha 1.2.2
Các hướng tiếp cận phát triển hệ thống
1. Tiếp cận dự đoán • Hướng tiếp cận dự đoán giả định rằng dự án được lập
kế hoạch và tổ chức trước. Do đó hệ thống thông tin có thể phát triển dựa vào kế hoạch. • Mô hình thác nước
2. Tiếp cận thích nghi • Linh hoạt hơn, giả định rằng dự án không thể lập một
kế hoạch cụ thể trước do đó cần được sửa đổi xuyên suốt toàn bộ tiến trình. • Phát triển lặp
– Hệ thống phát triển một cách có tổ chức, phát triển các thành
phần lõi trước và thêm các thành phần phụ sau, tất cả được lặp
cho đến khi hệ thống hoàn thiện. – Six Core Processes:
(a) Xác định vấn đề và xin chấp thuận
(b) Lập kế hoạch điều phối dự án (c) Hiểu chi tiết
(d) Thiết kế các thành phần
(e) Tích hợp các thành phần (f) Triển khai
– Lượng công việc của mỗi vòng lặp cho mỗi tiến trình phụ thuộc vào: ∗ Dự án
∗ Hướng tiếp cận ∗ Kết quả vòng lặp trước
– Trong vòng lặp đầu, các công việc chủ yếu ở tiến trình (a), (b), (c).
– Trong vòng lặp cuối, các công việc chủ yếu ở các tiến trình sau.
– Mỗi vòng lặp kéo dài từ 2-4 tuần.
3. Phương pháp luận về phát triển hệ thống • Là một tập các hướng dẫn bao
quát toàn bộ hoạt động trong SDLC bao gồm mô hình cụ thể, công cụ, kỹ thuật.
• Dựa vào kinh nghiệm hoặc được tư vấn. 4. Các mô hình
• Là biểu diễn của một khía cạnh quan trọng trong thế giới thực.
• Mô hình thành phần hệ thống – Flowchart – DFD – ERD – Structure chart – UC Diagram – Class Diagram – Sequence Diagram
• Mô hình quản lý quy trình phát triển – GANTT
– Mô hình phân tích tài chính ROI, NPV
– Biểu đồ tổ chức phân cấp
5. Các công cụ • Là các phần mềm hỗ trợ tạo các mô hình hoặc các thành
phần khác yêu cầu trong dự án
• Công cụ quản trị dự án
• Công cụ trực quan hóa mô hình
• Công cụ phát triển, lập trình
6. Các kỹ thuật • Các hướng dẫn để hoàn thành nhiệm vụ: Thu thập thông tin, tạo các mô hình,... • Một số kỹ thuật:
– Lập kế hoạch, quản lý, phỏng vấn
– Mô hình hóa dữ liệu, thiết kế CSDL quan hệ
– Phân tích, thiết kế, lập trình, kiểm thử 1.2.3 Chi tiết một số SDLC 1. Mô hình thác nước
Hình 5: Mô hình thác nước
• Các giai đoạn không giao nhau, không lặp lại • Ưu điểm:
– Dễ hiểu, dễ sử dụng
– Tài liệu được tổng hợp sau mỗi giai đoạn
– Yêu cầu phần mềm được cung cấp sớm cho Tester
– Lập kế hoạch, quản lý chặt chẽ • Nhược điểm:
– Chỉ phù hợp nếu yêu cầu được xác định và cố định từ đầu
– Không phù hợp với dự án kéo dài
– Rủi ro và không chắc chắn
– Khó có sớm các kết quả ban đầu của phần mềm • Nên áp dụng khi:
– Thời gian thực hiện ngắn
– Yêu cầu được xác định rõ, ổn định, đầy đủ – Nắm vững công nghệ
– Nguồn lực đủ đáp ứng
2. Mô hình nguyên mẫu • Một số nguyên mẫu (không phải phần mềm hoàn
thiện) được tạo ra để hiểu chính xác yêu cầu phần mềm • Ưu điểm:
– Có sự tham gia của người dùng, sớm thu được phản hồi
– Phát hiện sớm lỗi, vấn đề, chức năng thiếu, không rõ ràng, khó thao tác • Nhược điểm:
– Không nhất quán trong diễn đạt yêu cầu do khiến người dùng
thấy phát triển phần mềm dễ dàng
– Vấn đề kéo dài, không ổn định trong quản trị dự án
– Người phát triển có xu hướng bàn giao một nguyên mẫu cơ bản
chứ không bàn giao sản phẩm hoàn thiện • Nên dùng khi:
– Yêu cầu không thể xác định từ khi bắt đầu dự án
– Phù hợp để phát triển cảm nhận, giao diện sử dụng của hệ thống
– Khách hàng cần chứng minh tính khả thi
– Khi cần thực nghiệm, demo, kiểm tra
3. Mô hình xoắn ốc • Lai ghép lặp của mô hình nguyên mẫu và tuần tự của
mô hình thác nước, chú trọng vào phân tích nguy cơ.
• Trong các bước lặp đầu, các phiên bản chỉ là các mô hình được phác thảo trên giấy.
• Trong các bước lặp sau, các phiên bản ngày càng hoàn thiện hơn của
hệ thống sẽ được tạo ra. • Ưu điểm:
– Chú trọng vào phân tích rủi ro
– Phù hợp với các dự án lớn, quan trọng
– Phiên bản đầu được tạo ra sớm, các tính năng mới được thêm vào sau • Nhược điểm – Chi phí cao
– Đòi hỏi kỹ năng, kinh nghiệm cao
– Thành công phụ thuộc vào phân tích rủi ro
– Không phù hợp với dự án nhỏ • Nên dùng khi
– Phân tích rủi ro là quan trọng
– Dự án có rủi ro trung bình đến cao
– Người dùng không chắc chắn về nhu cầu, yêu cầu phức tạp, lớn.
– Phát triển dòng sản phẩm mới, thay đổi quan trọng 4. Mô hình hợp nhất
• Kết hợp góc nhìn quản lý dự án và góc nhìn kỹ thuật
Hình 6: Góc nhìn quản trị dự án
Hình 7: Góc nhìn kỹ thuật
Hình 8: Kết hợp hai góc nhìn 5. Quy trình RUP
• Là một quy trình mô hình hóa với UML chứ không phải một chuẩn • Các nguyên tắc cơ bản
– Lặp và tăng trưởng: Chia thành giai đoạn ngắn và thêm dần các thành phần
– Tập trung vào kiến trúc: Chia hệ thống thành các mô đun và kiến
trúc được trình bày theo 5 góc nhìn khác nhau
– Dẫn dắt theo ca sử dụng: Thể hiện nhu cầu người dùng ảnh
hưởng xuyên suốt toàn hệ thống, cơ sở xác định vòng lặp tăng
trưởng, căn cứ để phân chia công việc
∗ Nắm bắt nhu cầu: Phát hiện ca sử dụng
∗ Phân tích: Đi sâu vào ca sử dụng
∗ Thiết kế cài đặt: Xây dựng theo ca sử dụng
∗ Kiểm thử: Thực hiện theo ca sử dụng – Khống chế nguy cơ • Các giai đoạn
– Giai đoạn khởi đầu:
∗ Cái nhìn tổng quát về hệ thống: chức năng, hiệu năng, công nghệ
∗ Dự án PTPM sẽ triển khai: Phạm vi, mục tiêu, tính khả thi
– Giai đoạn chi tiết hóa
∗ Phân tích chi tiết hơn: Chức năng và cấu trúc tĩnh
∗ Đề xuất một kiến trúc hệ thống (Nguyên mẫu) – Giai đoạn xây dựng
∗ Tập trung vào thiết kế và cài đặt
∗ Chi tiết hóa kiến trúc hệ thống
∗ Kết thúc khi đã cho ra một hệ thống hoàn chỉnh và các tài liệu kiến trúc đi kèm
∗ Là giai đoạn tốn nhiều công sức nhất
– Giai đoạn chuyển giao ∗ Chuyển giao cho người dùng cuối:
chuyển đổi dữ liệu, kiểm tra, lắp đặt, đào tạo • Các bước chính – Nghiên cứu sơ bộ
– Nhận định, đặc tả các ca sử dụng – MHH lĩnh vực
– Xác định các lớp tham gia ca sử dụng
– MHH tương tác: trình tự, giao tiếp
– MHH ứng xử: máy trạng thái
– Làm nguyên mẫu giao diện – Thiết kế kiến trúc – Thiết kế chi tiết – Cài đặt 1.3 Quản trị dự án 1.4 Giới thiệu UML
1. UML - Ngôn ngữ MHH• UML dùng để mô hình hóa trực quan, đặc tả, xây dựng, làm tài liệu
• Có thể sử dụng trong bất kỳ tiến trình phát triển hệ thống
2. Các góc nhìn UML• UML cung cấp các biểu đồ (mô hình để diễn tả hệ
thống), mỗi mô hình chỉ diễn tả theo một góc nhìn nhất định. • UML cung
cấp 5 góc nhìn, mỗi góc nhìn được thực hiện bởi một số biểu đồ. Góc nhìn (1) — (n) Biểu đồ
• Có thể có biểu đồ phụ thuộc vào nhiều góc nhìn khác nhau
• Mỗi vai trò trong quá trình phát triển (phân tích, thiết kế, tích hợp,..)
thường chỉ quan tâm đến một góc nhìn nào đó của hệ thống
• 5 góc nhìn bổ trợ nhau trong đó góc nhìn ca sử dụng có ảnh hưởng
đến 4 góc nhìn còn lại • Góc nhìn ca sử dụng
– Góc nhìn từ ngoài vào hệ thống của người dùng cuối, người phân tích
– Chỉ làm rõ các tính năng chính cần đáp ứng cho người dùng
– Sắc thái tĩnh: Biểu đồ UC
– Sắc thái động: Biểu đồ giao tiếp, Máy trạng thái, Biểu đồ hoạt động • Góc nhìn thiết kế
– Còn được gọi là góc nhìn logic, bên trong cho thấy nghiệp vụ của
hệ thống, của người thiết kế hệ thống.
– Sắc thái tĩnh: Biểu đồ lớp, Biểu đồ đối tượng,Biểu đồ gói
– Sắc thái động: Biểu đồ trình tự, Biểu đồ giao tiếp, biểu đồ máy
trạng thái, biểu đồ hoạt động. • Góc nhìn quá trình
– Còn được gọi là góc nhìn song hành, phản ánh quá trình điều
khiển, quá trình thực hiện, cho thấy sự hoạt động đồng bộ của hệ thống.
– Biểu diễn bằng các biểu đồ như trong góc nhìn thiết kế, tập trung
vào các lớp chủ động: Các lớp biểu diễn cho các quá trình điều
khiển và các quá trình thực hiện. • Góc nhìn thực thi
– Còn được gọi là góc nhìn thành phần, cho thấy các thành phân
và tập tin tương đối độc lập được lắp ráp lại để hệ thống chạy được
– Sắc thái tĩnh: Biểu đồ thành phần
– Sắc thái động: Biểu đồ hoạt động, biểu đồ giao tiếp, biểu đồ máy trạng thái • Góc nhìn triển khai
– Góc nhìn về kiến trúc phần cứng và nền tảng hạ tầng mà trên đó
hệ thống được triển khai, thể hiện sự lắp đặt của các thành phần
hệ thống trên đơn vị nền tảng
– Sắc thái tĩnh: Biểu đồ triển khai
– Sắc thái động: Biểu đồ giao tiếp, biểu đồ hoạt động, Biểu đồ máy trạng thái
3. Các biểu đồ của UML 2.0
• Các biểu đồ về cấu trúc – Biểu đồ lớp
– Biểu đồ đối tượng – Biểu đồ triển khai – Biểu đồ gói
– Biểu đồ thành phần – Biểu đồ cấu trúc đa hợp
• Các biểu đồ về hành vi
– Biểu đồ ca sử dụng
– Biểu đồ hoạt động – Biểu đồ trình tự – Biểu đồ giao tiếp
– Biểu đồ máy trạng thái – Biểu đồ thời gian
– Biểu đồ tổng quan tương tác
4. Bổ sung ý nghĩa cho các biểu đồ
• Đặc tả: phát biểu dạng văn bản
• Tô điểm: Các vai trò, cơ số, hạn định, đường viền
• Khuôn dập: chuỗi ký tự đặt trong ngoặc kép «», biểu tượng gắn thêm
vào để tạo phần tử mới.
• Tính chất và giá trị gán nhãn: Đưa thêm thông tin
• Ràng buộc: Thêm điều kiện 5. Mô hình hóa với UML • Theo nhiều góc nhìn
• Theo mức độ trừu tượng hóa khác nhau 2 Phân tích hệ thống 2.1 Phân tích yêu cầu 2.1.1 Mục đích
• Đây là bước nghiên cứu sơ bộ về môi trường, hoàn cảnh nghiệp vụ của hệ
thống sắp xây dựng, gồm:
– Gợi mở yêu cầu – Làm rõ yêu cầu – Nắm bắt yêu cầu
• Nhận định các yêu cầu chức năng, phi chức năng, nguy cơ, ràng buộc
• Xác lập và hoạch định dự án
• Trả lời câu hỏi khả thi 1. Xác định yêu cầu • Yêu cầu người dùng – Viết cho khách hàng.
– Đầu vào chính để tạo nên yêu cầu hệ thống.
– Ngôn ngữ tự nhiên + sơ đồ: dịch vụ hệ thống cung cấp + ràng buộc. • Yêu cầu hệ thống:
– Tài liệu có cấu trúc + chi tiết: chức năng + dịch vụ + ràng buộc
– Định nghĩa cái gì cần được cài đặt, có thể là một phần của bản hợp đồng 2. Phân loại yêu cầu
Hình 9: Phân loại yêu cầu (a) Yêu cầu chức năng
i. Khái niệm • Là danh sách các công việc được thực hiện trên hệ
thống cùng thông tin mô tả tương ứng. ii. Yêu cầu chức năng nghiệp vụ
• Các chức năng của phần mềm tương ứng với các công việc
có thật trong thế giới thực.
• Có 4 loại chức năng chính tương ứng với 4 loại nghiệp vụ – Chức năng lưu trữ:
∗ Tương tự công việc ghi chép sổ sách ∗ VD: Ghi nhận điểm
thi kết thúc học phần của sinh viên – Chức năng tra cứu:
∗ Tương tự công việc tìm kiếm và xem thông tin tương ứng
∗ VD: tìm sách, xem tình trạng sách
– Chức năng tính toán∗ Tương tự với các công việc tính
toán theo công thức, quy định cho trước.
∗ VD: Tính tiền phạt trả sách trễ hạn – Chức năng kết xuất
∗ Tương ứng với chức năng tạo báo cáo (theo biểu mẫu cho trước)
∗ Lập báo cáo thống kê về số lượng mượn sách theo từng thể loại trong năm.
iii. Yêu cầu chức năng hệ thống
• Là chức năng phải phát sinh thêm khi tiến hành các công việc
trên máy tính thay vì trên thực tế.
• Là chức năng không tương ứng với bất kỳ công việc nào trong
thế giới thực (có nhu cầu nhưng không thể thực hiện thủ công)
• Một số yêu cầu chức năng hệ thống thông dụng
– Phân quyền hệ thống
– Sao lưu, backup, phục hồi thông tin
– Định cấu hình thiết bị, ngày giờ làm việc
– Báo động, nhắc nhở người dùng
– Mô phỏng hoạt động thế giới thực
(b) Yêu cầu phi chức năng i. Khái niệm
• Các yêu cầu liên quan tới chất lượng phần mềm.
• Là sự ràng buộc trên cách thực hiện các yêu cầu chức năng. ii. Phân loại
• Yêu cầu về sản phẩm
– Yêu cầu khả dụng, khả chuyển, tin cậy
– Yêu cầu về hiệu quả, hiệu năng, không gian, tốc độ xử lý
• Yêu cầu về tổ chức
– Yêu cầu về chuyển giao
– Yêu cầu về triển khai – Yêu cầu về chuẩn • Yêu cầu mở rộng
– Yêu cầu về hoạt động bên trong
– Yêu cầu về đạo đức, pháp lý
– Yêu cầu về cá nhân, an toàn 2.1.2 Phương pháp tiến hành 2.1.3 Use Case
1. Các khái niệm liên quan
• Là cốt lõi để định nghĩa các yêu cầu chức năng của hệ thống, đại diện
cho một hoạt động hệ thống thực hiện để đáp ứng yêu cầu từ người dùng hoặc tác nhân
• Có hai kỹ thuật chính để phát triển các ca sử dụng: User Goal
Technique và Event Decomposition Technique (a) User Goal Technique
Xác định CSD dựa trên vai trò và mục tiêu của người dùng • Xác định,
phân loại người dùng theo vai trò chức năng, cấp độ tổ chức
• Phỏng vấn người dùng
• Đặt tên ca sử dụng: Động từ - Danh từ mệnh lệnh. VD: Cập nhật đơn hàng
• Tạo danh sách ca sử dụng theo phân loại người dùng
• Tìm kiếm trùng lặp. VD: Các người dùng khác nhau có cùng ca sử dụng
• Xem xét danh sách đã cập nhật với người dùng và các bên liên quan
(b) Event Decomposition Technique
Xác định CSD dựa trên các sự kiện nghiệp vụ mà hệ thống cần xử lý •
Khó khăn trong xác định mức độ chi tiết phù hợp:
– Được thực hiện bởi một người
– Đem lại giá trị có thể đo lường được
– Để lại hệ thống và dữ liệu trong một trạng thái ổn định
• Được gọi là Quy trình nghiệp vụ cơ bản (EBP) 2. Các loại sự kiện (a) Sự kiện bên ngoài
• Có thể được kích hoạt bởi các tác nhân bên ngoài, thậm chí là
nhân viên hoặc các phòng ban:
– Tác nhân bên ngoài muốn một điều gì đó dẫn tới một giao dịch
– Tác nhân bên ngoài/quản lý muốn một số thông tin
– Dữ liệu thay đổi và cần được cập nhật
• VD: "Khách hàng thanh toán hóa đơn", "Khách hàng thực hiện
một khoản nợ", "Khách hàng thay đổi địa chỉ"
(b) Sự kiện thời gian• Một sự kiện xảy ra khi đạt đến một thời gian nhất định:
– Deadline xảy đến những khi nào
– Đầu ra nào ứng với deadline
• VD: Báo cáo, lời nhắc,... (c) Sự kiện trạng thái
• Còn được gọi là sự kiện nội bộ
• Sự kiện xảy ra khi có điều gì đó bên trong hệ thống mà kích hoạt một nhu cầu xử lý. 3. Xác định sự kiện (a) Tên sự kiện
• Gom các hành động nhỏ thành một chuỗi hành động có ý nghĩa nghiệp vụ
• Bỏ qua các sự kiện liên quan đến kiểm soát hệ thống: Đảm bảo
tính bảo mật, xác thực, toàn vẹn; hay các sự kiện liên quan đến
kỹ thuật: API, giao diện,..
=> Duy trì sự trừu tượng, đơn giản hóa, tập trung vào phân tích
• Tên sự kiện = Tên tác nhân + Hành động
(b) Các bước tóm tắt để phân rã
• Xác định sự kiện bên ngoài, đặt tên CSD
• Xác định sự kiện thời gian, xác định thời điểm kích hoạt, đặt tên CSD
• Xác định sự kiện trạng thái, đặt tên CSD, xác định sự thay đổi trạng thái
• Kiểm tra lại các Use Case, bỏ qua các kiểm soát hệ thống, bỏ qua sự kiện kỹ thuật
• Bảng sự kiện: Danh mục thông tin về các Use Case tạo nên yêu
cầu chức năng của hệ thống 4. Đặc tả UseCase
5. Các đối tượng • Mô hình hóa các đối tượng mà hệ thống cần lưu trữ thông
tin, những thứ cần là một phần của hệ thống. VD: sản phẩm, đơn hàng, hóa đơn, khách hàng.
• Các đối tượng tương tự các tác nhân ngoài nhưng khác ở chỗ cần lưu trữ thông tin
(a) Xác định các đối tượng
(b) Mối quan hệ và thuộc tính các đối tượng
• Mối quan hệ và lực lượng của quan hệ • Thuộc tính • Định danh
• Thuộc tính hỗn hợp: Tập các thuộc tính
• Sơ đồ thực thể liên kết 3 Thiết kế hệ thống 3.1
Sơ lược về thiết kế hệ thống
3.1.1 Mục đích của thiết kế
• Phân tích: trả lời cho câu hỏi WHAT, tập trung vào các yêu cầu (chức năng và
phi chức năng), gồm 6 bước đầu tiên trong 10 bước của quy trình RUP
• Thiết kế: trả lời cho câu hỏi HOW, đáp ứng yêu cầu phi chức năng, đưa ra
những thiết kế phù hợp với công nghệ được chọn
Hình 10: Phân tích vs Thiết kế 3.1.2
Vai trò của thiết kế hệ thống
• Cầu nối từ "yêu cầu" tới "mã nguồn"
• Quyết định tính linh hoạt, khả năng bảo trì, mở rộng của hệ thống
• Tiết kiệm chi phí phát triển và thời gian trong dài hạn
• Giảm thiểu nợ kỹ thuật
• Tạo nền tảng vững chắc cho quá trình phát triển 3.1.3 Đầu vào cho thiết kế
• Ca sử dụng (Tương tác và luồng xử lý)
• Mô hình lớp lĩnh vực (Thực thể và mối quan hệ)
• Ràng buộc hệ thống (Thời gian, Ngân sách, Công nghệ)
• Yêu cầu hiệu suất (Thời gian phản hồi, thông lượng)
• Yêu cầu bảo mật (Xác thực, ủy quyền, mã hóa)
• Yêu cầu khả năng mở rộng (Số lượng người dùng, dữ liệu) 3.1.4 Đầu ra cho thiết kế
• Thiết kế kiến trúc (Cấu trúc tổng thể của hệ thống)
• Sơ đồ thành phần/lớp (Chi tiết các mô đun và lớp)
• Đặc tả giao diện (UI/API)
• Mô hình dữ liệu (Cấu trúc CSDL)
• Mô hình bảo mật (Cơ chế xác thực và phân quyền)
• Kế hoạch triển khai (Hạ tầng, cấu hình)

Tài liệu liên quan: