TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP TP.HCM KHOA CÔNG NGHỆ THÔNG TIN
Chương IV
Trần Thị Kim Chi 1
NỘI DUNG
1. Tổng quan về phân tích và thiết kế 2. Mục đích của phân tích 3. Qui trình phân tích yêu cầu 4. Các bước phân tích theo hướng đối tượng 5. Mục đích của thiết kế 6. Qui trình thiết kế 7. Phương pháp phân tích và thiết kế hướng đối tượng 8. Phân tích Use case 9. Đặc tả Use Case 10. Phân tích Use case nghiệp vụ Trần Thị Kim Chi
2
MỤC ĐÍCH CỦA PHÂN TÍCH VÀ THIẾT KẾ
The purposes of Analysis and Design
are to:
Transform the requirements into a
design of the system-to-be.
Evolve a robust architecture for the
system.
Adapt the design to match the implementation environment, designing it for performance.
Trần Thị Kim Chi 3
TỔNG QUAN VỀ PHÂN TÍCH VÀ THIẾT KẾ
Design Model
Use-Case Model
Analysis and Design
Architecture Document
Glossary
Supplementary Specification
Data Model
Trần Thị Kim Chi 4
ANALYSIS VERSUS DESIGN
Analysis
Design
Focus on understanding
Focus on understanding
the problem
the solution
Idealized design Behavior System structure Functional requirements A small model
Operations and attributes Performance Close to real code Object lifecycles Nonfunctional requirements A large model
Trần Thị Kim Chi 5
Analysis and Design Are Not Top-Down or Bottom-Up
Analysis and Design
Top Down
Subsystems
Analysis Classes
Use Cases (Define a middle level)
Bottom Up
Design Classes
Trần Thị Kim Chi 6
Mục đích của phân tích yêu cầu
• Mục đích của hoạt động phân tích yêu cầu là xây dựng mô
hình phân tích với các đặc điểm sau : dùng ngôn ngữ của nhà phát triển để miêu tả mô hình. thể hiện góc nhìn từ bên trong của hệ thống. được cấu trúc từ các class phân tích và các package phân
tích.
được dùng chủ yếu bởi nhà phát triển để hiểu cách thức
tạo hình dạng hệ thống.
loại trừ mọi chi tiết dư thừa, không nhất quán. phát họa các hiện thực cho các chức năng bên trong hệ
thống.
định nghĩa các dẫn xuất use-case, mỗi dẫn xuất use-case
cấp phân tích miêu tả sự phân tích 1 use-case.
Trần Thị Kim Chi 7
CÁC BƯỚC CHÍNH CỦA PHÂN TÍCH
• Phân tích yêu cầu
– Phân tích nghiệp vụ – Phân tích các yêu cầu theo quy trình xử lý – Bổ sung các quy trình cho phù hợp với máy tính – Yêu cầu bổ sung các thông tin
• Xác lập tính năng hệ thống
– Xác lập các chức năng mà hệ thống sẽ bao gồm – Xác lập các điều kiện và môi trường hoạt động
• Xác thực tính năng hệ thống
– Xác thực với người dùng về tính hợp lý và đầy đủ của các tính năng – Xác thực các quy trình nghiệp vụ – Xác thực các ràng buộc
Trần Thị Kim Chi 8
PHÂN TÍCH NGHIỆP VỤ
Mô hình nghiệp vụ mô tả: • các chức năng nghiệp vụ của một tổ chức • mối quan hệ bên trong giữa các chức năng đó cũng như các
mối quan hệ của chúng với môi trường bên ngoài
Mô hình phân rã chức năng • Là mô hình nghiệp vụ của hệ thống • Mô tả sự phân chia các chức năng nghiệp vụ của tổ chức thành
các chức năng nhỏ hơn theo một thứ bậc xác định.
Chức năng nghiệp vụ: • Tập hợp các công việc mà tổ chức cần thực hiện trong hoạt
động của nó.
Trần Thị Kim Chi 9
PHÂN TÍCH NGHIỆP VỤ
• Chức năng được xem xét ở các mức độ từ tổng hợp đến chi
tiết: – Một lĩnh vực hoạt động (area of activites) – Một hoạt động (activity) – Một nhiệm vụ (task) – Một hành động (action)
Trần Thị Kim Chi 10
PHÂN TÍCH NGHIỆP VỤ
Quy tắc phân rã • Mỗi chức năng được phân rã phải là một bộ phận thực sự tham
gia thực hiện chức năng đã phân rã ra nó
• Việc thực hiện tất cả các chức năng ở mức dưới phải đảm bảo
thực hiện chức năng ở mức trên đã phân rã ra chúng
Bố trí mô hình • Ở mỗi mức, các chức năng cùng mức sắp xếp trên cùng một hàng. Riêng mức cuối cùng có thể sắp xếp theo hàng dọc.
• Bố trí cân đối, rõ ràng để dễ kiểm tra, theo dõi
Trần Thị Kim Chi 11
PHÂN TÍCH NGHIỆP VỤ
Đặt tên chức năng • Mỗi chức năng có một tên duy nhất • Công thức
Mô tả chi tiết chức năng ở mức cuối • Tên chức năng • Các sự kiện kích hoạt • Quy trình thực hiện • Dữ liệu vào, ra • Công thức tính toán sử dụng (nếu có) • Quy tắc nghiệp vụ cần tuân thủ
Trần Thị Kim Chi 12
PHÂN TÍCH NGHIỆP VỤ
Ma trận thực thể - chức năng • Nhằm xác định mối liên hệ giữa các chức năng và thực thể
trong hệ thống
• Bao gồm các dòng là các chức năng ở mức tương đối chi tiết,
các cột là thực thể
• Mỗi ô giao giữa dòng và cột có thể là
– C (Create - chức năng tạo ra dữ liệu mới trong thực thể) – R (Read - chức năng đọc dữ liệu trong thực thể) – U (Update - chức năng cập nhật dữ liệu trong thực thể)
• Cho phép xem xét, phát hiện ra những khiếm khuyết trong
khảo sát, loại bỏ những chức năng và thực thể thừa
Trần Thị Kim Chi 13
PHÂN TÍCH NGHIỆP VỤ
Ma trận thực thể - chức năng
Trần Thị Kim Chi 14
PHÂN TÍCH NGHIỆP VỤ
Các bước xây dựng mô hình nghiệp vụ • Mô tả bài toán • Lập bảng phân tích:
– Lập danh sách các danh từ và các nhóm động từ+bổ ngữ – Cột nhận xét:
• Bỏ qua danh từ chỉ khái niệm hay vật thể • Đánh dấu các danh từ là tác nhân và vật mang tin (thực thể
dữ liệu)
Trần Thị Kim Chi 15
PHÂN TÍCH NGHIỆP VỤ
Các bước xây dựng mô hình nghiệp vụ • Lập danh sách các công việc và các hồ sơ dữ liệu sử dụng • Lập biểu đồ phân rã chức năng • Lập ma trận thực thể dữ liệu - chức năng • …
Trần Thị Kim Chi 16
PHÂN TÍCH NGHIỆP VỤ
Ví dụ : Xây dựng mô hình nghiệp vụ cho bài toán • Một bãi gửi xe có 2 cổng: một cổng xe vào, một cổng xe ra. Người ta chia bãi thành 4 khu dành cho 4 loại xe khác nhau: xe máy, xe buýt, xe tải và công-ten-nơ.
• Khi khách đến gửi xe, người coi xe nhận dạng xe theo bảng phân loại, sau đó kiểm tra chỗ trống trong bãi. Nếu chỗ dành cho loại xe đó đã hết thì thông báo cho khách. Ngược lại thì ghi vé đưa cho khách và hướng dẫn xe vào bãi, đồng thời ghi những thông tin trên vé vào sổ xe vào.
Trần Thị Kim Chi 17
PHÂN TÍCH NGHIỆP VỤ
Ví dụ : Xây dựng mô hình nghiệp vụ cho bài toán • Khi khách lấy xe, người coi xe kiểm tra vé xem vé là thật hay giả, đối chiếu vé với xe. Nếu vé giả hay không đúng xe thì không cho nhận xe. Ngược lại thì viết phiếu thanh toán và thu tiền của khách, đồng thời ghi các thông tin cần thiết vào sổ xe ra.
• Khi khách đến báo cáo có sự cố thì kiểm tra xe trong sổ xe vào và sổ xe ra để xác minh xe có gửi hay không và đã lấy ra chưa. Nếu không đúng như vậy thì không giải quyết. Trong trường hợp ngược lại tiến hành kiểm tra xe ở hiện trường. Nếu đúng như sự việc xảy ra thì tiến hành lập biên bản giải quyết và trong trường hợp cần thiết thì viết phiếu chi bồi thường cho khách.
Trần Thị Kim Chi 18
PHÂN TÍCH NGHIỆP VỤ
Ví dụ : Mô tả bài toán
Trần Thị Kim Chi 19
PHÂN TÍCH NGHIỆP VỤ
Ví dụ : Lập bảng phân tích
Trần Thị Kim Chi 20
PHÂN TÍCH NGHIỆP VỤ
Ví dụ : Lập bảng phân tích
Trần Thị Kim Chi 21
PHÂN TÍCH NGHIỆP VỤ
Cách nhóm các chức năng theo phuơng pháp từ dưới lên
Trần Thị Kim Chi 22
PHÂN TÍCH NGHIỆP VỤ
Cách nhóm các chức năng theo phuơng pháp từ dưới lên
Mô hình phân rã chức năng quản lý trông gửi xe
Trần Thị Kim Chi 23
PHÂN TÍCH NGHIỆP VỤ
• Danh sách hồ sơ dữ liệu
Trần Thị Kim Chi 24
PHÂN TÍCH NGHIỆP VỤ
Ma trận thực thể - chức năng
Trần Thị Kim Chi 25
PHÂN TÍCH NGHIỆP VỤ
Ma trận thực thể - chức năng
Trần Thị Kim Chi 26
PHÂN TÍCH NGHIỆP VỤ
Ma trận thực thể - chức năng
Trần Thị Kim Chi 27
PHÂN TÍCH NGHIỆP VỤ
Ma trận thực thể - chức năng
Trần Thị Kim Chi 28
CÁC ARTIFACTS CẦN TẠO RA TRONG PHÂN TÍCH YÊU CẦU
Mô hình phân tích = hệ thống phân tích :
các class phân tích
– boundary class – entity class. – control class
các dẫn xuất use-case cấp phân tích :
– các lược đồ class phân tích – các lược đồ tương tác (cộng tác,...). – 'flow of events' ở cấp phân tích – các yêu cầu đặc biệt của use-case
các package phân tích đặc tả kiến trúc (view of analysis model)
Trần Thị Kim Chi 29
CÁC WORKERS TRONG PHÂN TÍCH YÊU CẦU
Architect
Component Engineer
Use-Case Engineer
chịu trách nhiệm về
chịu trách nhiệm về
chịu trách nhiệm về
Architecture Description
Analysis class
Analysis package
Analysis Model
Use-Case Realization - Analysis
Trần Thị Kim Chi 30
QUI TRÌNH PHÂN TÍCH YÊU CẦU
Architect
Architectural Analysis
Analyze a Use-Case
Use-Case Engineer
Analyze a Package
Analyze a Class
Component Engineer
Trần Thị Kim Chi 31
Phân tích kiến trúc : nhận dạng các package phân tích
Glossary
Reference Architecture
Vision Document
Software Architecture Doc
Supplementary Specification
Architectural Analysis
Design Model
Project-Specific Guidelines
Use-Case Model
Deployment Model
Trần Thị Kim Chi 32
Phân tích kiến trúc : nhận dạng các package phân tích
• Mục đích của phân tích kiến trúc là phát họa mô hình phân tích và kiến trúc hệ thống bằng cách nhận dạng các package phân tích, các class phân tích dễ thấy và các yêu cầu đặc biệt chung cho hệ thống.
• Các package phân tích giúp tổ chức hệ thống thành những đơn vị nhỏ dễ quản lý. Mỗi package chứa 1 số use-case với tính chất sau : các use-case hỗ trợ cho cùng 1 qui trình nghiệp vụ. các use-case hỗ trợ cho cùng 1 actor. các use-case có quan hệ lẫn nhau : tổng quát hóa, include và
extend.
• Theo thời gian, khi việc phân tích tiến triển, sự tinh chế cấu trúc các
package sẽ tiến triển theo.
Trần Thị Kim Chi 33
Phân tích kiến trúc : nhận dạng các class thực thể dễ thấy
• Từ các class lĩnh vực hay các class nghiệp vụ nắm bắt yêu cầu, đề
nghị 1 số class thực thể quan trọng nhất (từ 10-20).
• Các class phân tích còn lại sẽ được nhận dạng trong hoạt động phân
tích use-case.
• Các yêu cầu đặc biệt cũng được nhận dạng để được xử lý trong các
Code
Implementation
Design
Architecture
bước sau, chúng gồm : tính bền vững. sự phân tán & đồng thời. các tính chất an toàn dữ liệu. đề kháng với lỗi. quản lý giao tác.
• Tính chất của mỗi yêu cầu đặc biệt sẽ được cân nhắc sau trong từng
class và từng dẫn xuất use-case.
Trần Thị Kim Chi 34
Phân tích use-case
Logical View Implementation View
Analysts/Designers
Programmers
Structure
Software management
Use-Case View
End-user Functionality
Process View Deployment View
System integrators
Performance, scalability, throughput
System engineering System topology, delivery, installation, communication
Trần Thị Kim Chi 35
Phân tích use-case
Phân tích use-case là để : nhận dạng các class phân tích có đối tượng của chúng tham gia vào việc thực hiện 'flow of events' của use-case.
phân phối hành vi của use- case bằng cách cho các đối tượng phân tích tương tác nhau.
nắm bắt 1 số yêu cầu đặc biệt
cho dẫn xuất use-case.
Trần Thị Kim Chi 36
Phân tích use-case : nhận dạng các class phân tích
• Trong bước này ta nhận dạng các class điều khiển, biên, thực thể
cần thiết để hiện thực use-case và phát họa tên, trách nhiệm, thuộc tính và các mối quan hệ giữa chúng.
• Cách nhận dạng các thành phần :
nhận dạng các class thực thể bằng cách chú ý các thông tin trong
đặc tả use-case và trong mô hình lĩnh vực.
nhận dạng class biên cơ sở cho mỗi class thực thể vừa tìm được. nhận dạng class biên trung tâm cho mỗi actor là con người. nhận dạng class biên trung tâm cho mỗi actor là hệ thống ngoại
hay thiết bị I/O.
nhận dạng class điều khiển có trách nhiệm xử lý trong dẫn xuất
use-case.
• Tập hợp các class phân tích tham gia vào dẫn xuất use-case thành 1
(hay nhiều) lược đồ class. Trần Thị Kim Chi
37
Phân tích use-case : nhận dạng các class phân tích
Trần Thị Kim Chi 38
Phân tích use-case : Hiện thực hóa use case (Use-Case Realization)
Trần Thị Kim Chi 39
Thí dụ về lược đồ class phân tích cho use-case Pay Invoice
Trần Thị Kim Chi 40
Phân tích use-case : miêu tả sự tương tác giữa các đối tượng phân tích
Các bước phân tích Use Case: 1. Bổ sung vào đặc tả use case 2. Hiện thực hóa use case (UC realization)
– Tìm các lớp từ hành vi của use case – Phân phối hành vi của use case vào các lớp
3. Phân tích lớp (analysis class) – Mô tả thuộc tính và sự kết hợp – Mô tả nhiệm vụ – Gán cơ chế phân tích
4. Hợp nhất các lớp phân tích
Trần Thị Kim Chi 41
Phân tích class
• Mục đích của việc phân tích class là :
nhận dạng và duy trì các nghĩa vụ, trách nhiệm của class phân
tích dựa vào vai trò của nó trong dẫn xuất use-case.
nhận dạng và duy trì các thuộc tính và các mối quan hệ của class
phân tích.
nắm bắt các yêu cầu đặc biệt liên quan đến việc hiện thực class
phân tích
Tổ hợp các vai trò mà class đóng trong các dẫn xuất use-case
khác nhau sẽ cho ta 1 số nghĩa vụ của class.
Nghiên cứu các lược đồ class và lược đồ tương tác trong các dẫn
xuất use-case có class tham gia.
Đôi khi cần nghiên cứu 'flow of events cấp phân tích' của dẫn
xuất use-case để tìm thêm các nghĩa vụ các class
Trần Thị Kim Chi 42
Phân tích class
Trần Thị Kim Chi 43
Phân tích class : nhận dạng mối quan hệ giữa các class
• Các đối tượng tương tác nhau thông qua các lược đồ cộng tác.
• Mối quan hệ gộp nên được dùng khi các đối tượng miêu tả :
các khái niệm chứa vật lý khái niệm khác (xe chứa tài xế và
khách)
các khái niệm được xây dựng từ các khái niệm khác (xe
gồm các bánh xe và động cơ).
các khái niệm tạo thành tập hợp ý niệm nhiều đối tượng
(gia đình gồm cha, mẹ và con).
• Để rút trích các hành vi chung của nhiều class phân tích, ta có thể dùng class tổng quát hóa, nhưng chỉ nên ở cấp ý niệm.
Trần Thị Kim Chi 44
Phân tích class : nhận dạng mối quan hệ giữa các class
<
<
System information
System boundary
System information
System boundary
<
<
System boundary
System boundary
Use-case Use-case behavior behavior coordination coordination
<
System information
System information
Trần Thị Kim Chi 45
LỚP GIAO DIỆN -BOUNDARY CLASS
• Thực hiện chức năng giao tiếp với actor • Thường chứa các phần tử giao diện hoặc điều khiển giao diện người dùng( button, listbox, option group, menu…)
• Trong UML được gán stereotype là <
phân tích
• Ví dụ: đối với hệ thống quản lý thư viện, các đối tượng biên như: TheMuonForm, BanDocForm, Form_DangNhap…
Trần Thị Kim Chi 46
LỚP GIAO DIỆN -BOUNDARY CLASS
• Là lớp trung gian giữa giao diện và hệ thống bên
ngoài • Phân loại
– User interface classes – System interface classes – Device interface classes • Cách xác định lớp boundary: • One boundary class per actor/use-case pair
Trần Thị Kim Chi 47
LỚP THỰC THỂ
• Biểu diễn cho các thực thể xuất hiện một cách tự nhiên trong
hệ thống
• Thông tin về các đối tượng thực thể có thể phải được lưu trữ
lâu dài (database,file…)
• Trong UML được gán stereotype là <
trước, nhận diện các đối tượng thực thể như: – Sách, Bạn đọc, Thẻ mượn, Thủ thư.
Trần Thị Kim Chi 48
LỚP THỰC THỂ
Analysis class stereotype
Use Case
Business-Domain Model
Architectural Analysis Abstractions
Glossary
Environment independent. Trần Thị Kim Chi
49
LỚP ĐIỀU KHIỂN
• Có nhiệm vụ điều khiển các lớp khác hoặc những lớp không phải
lớp thực thể và lớp biên
• Trong UML, được gán stereotype là <
khác
• Dùng điều phối hành vi use case • Use case phức tạp sẽ yêu cầu nhiều hơn một lớp điều khiển
Use Case
Analysis class stereotype
Trần Thị Kim Chi 50
Phân tích package
• Một gói (Package) là một cơ chế có mục đích tổ chức các yếu tố
thành các nhóm. Một gói chứa các phần tử mô hình khác.
University Artifacts
• Một gói có thể được sử dụng:
– Để tổ chức các mô hình phát triển.
– Là một đơn vị quản lý cấu hình.
Dependency relationship
Client Package
Supplier Package
Trần Thị Kim Chi 51
Phân tích package
• Mục đích của phân tích package là :
đảm bảo từng package độc lập với các package khác đảm bảo package hoàn thành mục đích của nó là hiện thực 1 số
class lĩnh vực hoặc 1 số use-case.
miêu tả các phụ thuộc sao cho có thể ước lượng ảnh hưởng của
các thay đổi trong tương lai.
• Cách phân tích:
đảm bảo package chứa các class đúng, cố gắng cho tính kết dính
cao bằng cách gộp các class có mối quan hệ chức năng.
hạn chế tối đa sự phụ thuộc giữa các package, phân phối lại các
class quá phụ thuộc vào package khác.
Trần Thị Kim Chi 52
Phân tích package
A
A
B
B
Hierarchy should be acyclic
A
C
B
A'
C
Circular dependencies make it impossible
to reuse one package without the other. Trần Thị Kim Chi
53
MỤC ĐÍCH CỦA THIẾT KẾ
• Giai đoạn thiết kế quan tâm đến HOW:
– Thứ tự các thông điệp trao đổi, thông số của thông điệp – Thuật giải của tác vụ đáp ứng – Cấu trúc dữ liệu cho các thuộc tính – Framework(console, document/view…)
• Thiết kế cũng chịu ảnh hưởng từ:
– Ngôn ngữ lập trình và thư viện lập trình(Vector, List,
Map…)
– Kiến trúc hệ thống (COM,CORBA, EJB…) thiết lập mô hình động và chi tiết hóa mô hình tĩnh
Trần Thị Kim Chi 54
QUI TRÌNH THIẾT KẾ
• THIẾT KẾ HÀNH VI – Khái niệm mô hình động – Tương tác giữa các đối tượng – Sự cộng tác – Miêu tả trình tự – Lược đồ trạng thái – Lược đồ hoạt động
• HOÀN CHỈNH ĐẶC TẢ TĨNH – Nhận diện thêm một số lớp thiết kế – Đặc tả chi tiết các thuộc tính – Nhận diện chính xác các tác vụ – Hoàn chỉnh lược đồ lớpTrần Thị Kim Chi
55
Summary:Analysis and Design Workflow
Analysis
Design
Trần Thị Kim Chi 56
Analysis and Design Activity Overview
Architect
Designer
Trần Thị Kim Chi 57
Software Architect’s Responsibilities
• The Software
Analysis Model
Architect
Architect leads and coordinates technical activities and artifacts.
Design Model
Software Architecture Document
Reference Architecture
Implementation Model
Deployment Model
Trần Thị Kim Chi 58
Designer’s Responsibilities
Designer
Use-Case Realization
• The designer must know use-case modeling techniques, system requirements, and software design techniques.
Class/Subsystems
Package
Trần Thị Kim Chi 59
Analysis and Design in an Iterative Process
Use Case A Scenarios 1 & 2
Use Case B Scenario 1
Use Case A Scenario 3
Use-Case Realization A
Use-Case Realization A
Use-Case Realization B
Start of iteration
Iteration n
Iteration n + 1
End of iteration
Trần Thị Kim Chi 60
Review: Analysis and Design Overview
• What is the purpose of the Analysis and
Design Discipline?
• What are the input and output artifacts? • Name and briefly describe the 4+1 Views of
Architecture.
• What is the difference between Analysis
and Design?
• What is architecture?
Trần Thị Kim Chi 61
PHƯƠNG PHÁP PHÂN TÍCH THIẾT KẾ THEO HƯỚNG ĐỐI TƯỢNG
Trần Thị Kim Chi 62
CÁC BƯỚC PHÂN TÍCH VÀ THIẾT KẾ THEO HƯỚNG ĐỐI TƯỢNG
Problem statement
Create Use case model
Draw Activity Diagram (If reqd.)
Draw the interaction(sequence) diagrams
Draw the class diagram
Draw the state chart,object diagram(If required)
Draw component &Deployment Diagram
Design Document
Trần Thị Kim Chi 63
MÔ HÌNH USE CASE
• Use case diagram chỉ sự tương tác giữa phần mềm với người dùng hay môi trường bên ngoài
• Use case diagram cho biết hệ thống có những chức năng nào, actor nào và chúng liên quan với nhau như thế nào
Trần Thị Kim Chi 64
Use Case và yêu cầu chức năng
• Use case chính là yêu cầu chức năng, chỉ ra những gì mà hệ
thống sẽ làm.
• Nên tập trung vào use case ở mức xử lý nghiệp vụ cơ bản
(elementary business processes -EBP)
• Nhiệm vụ do 1 người thực hiện để đáp ứng 1 sự kiện nghiệp
vụ, tạo ra 1 giá trị nghiệp vụ và dữ liệu xác thực
Trần Thị Kim Chi 65
Use Cases và mục tiêu người dùng
• Use case ở mức EBP được xem là mục tiêu của người dùng • Mục tiêu ở mức thấp hơn được gọi
là mục tiêu con
(subfunction goal) – Mục tiêu con có chức năng hỗ trợ các mục tiêu chính của người dùng
Trần Thị Kim Chi 66
Lợi ích của mô hình Use Cases
• Communication • Identification • Verification
Use Case
Communication
Verification
n o i t a c i f i t n e d I
End User Domain Expert Users
Trần Thị Kim Chi 67
LƯỢC ĐỒ USE CASE
• Lược đồ use case là một tập hợp các use case mô tả nhiệm vụ cơ bản (elemental task) mà hệ thống sẽ phải thực thi và mối quan hệ giữa các nhiệm vụ này với thế giới bên ngoài.
Hệ thống POS
Trần Thị Kim Chi 68
Quy trình xây dựng lược đồ use case
1. Xác định phạm vi hệ thống 2. Xác định các actor chính 3. Xác định các mục tiêu cho mỗi actor 4. Xác định use case đáp ứng mục tiêu của actor.
Trần Thị Kim Chi 69
Xác định phạm vi hệ thống
• Phân biệt đường biên: xác định đối tượng nào bên
ngoài hệ thống – Xác định actor chính và actor hỗ trợ
• Ví dụ:
Trần Thị Kim Chi 70
Nhận diện các tác nhân (actor)
• Khái niệm:
Là một đối tượng bên ngoài hệ thống giao tiếp với hệ thống theo một trong các hình thức sau: – Tương tác, trao đổi thông tin với hệ thống hoặc sử
dụng chức năng của hệ thống
– Cung cấp đầu vào hoặc nhận dữ liệu đầu ra từ hệ
thống
– Không điều khiển hoạt động của hệ thống
Trần Thị Kim Chi 71
Nhận diện các tác nhân (actor)
• Việc tìm các actor phụ thuộc vào điểm xuất phát : nếu xuất phát từ mô hình nghiệp vụ hay mô hình lĩnh vực thì việc tìm actor rất đơn giản. Còn nếu xuất phát từ các ý niệm mơ hồ thì hãy trả lời các câu hỏi sau : Ai là người bắt đầu , kết thúc và sử dụng chức năng của hệ thống? Ai cần sự hỗ trợ từ hệ thống để thực hiện công việc thường nhật của
họ?
Ai phải thực hiện công việc bảo dưỡng, quản trị, quản lý bảo mật và
giữ cho hệ thống hoạt động?
Hệ thống sẽ kiểm soát thiết bị phần cứng nào Hệ thống đang xây dựng cần tương tác với những hệ thống khác
không? Hệ thống nào?
Ai hoặc vật thể nào quan tâm đến hoặc chịu ảnh hưởng bởi kết quả mà
hệ thống phần mềm tạo ra?
• Thường xác định actor trước rồi xác định mục tiêu của actor
sau. Đôi khi từ mục tiêu phát hiện ra actor.
Trần Thị Kim Chi 72
Actor trong uml
• Tên: được mô tả bằng danh từ
– VD: Khách hàng, Sinh viên, Web Client, Hệ thống thanh
toán… • Ký hiệu:
• Có thể sử dụng một số icon riêng cho một số actor
không phải là người như:
Trần Thị Kim Chi 73
Actor trong uml
• Phân loại Actor:
– Chủ yếu/thứ yếu (Primary/Secondary) – Tích cực/ thụ động(Active/Passive)
• Quan hệ giữa các Actor
– Tổng quát hóa (generalization) Một dạng của tính kế thừa – Chuyên biệt hóa(Specialization
Trần Thị Kim Chi 74
Actor trong uml
• Tác nhân chính (primary actor): Ai đang sử dụng hệ thống? Hoặc ai được tác động bởi hệ thống? Hoặc nhóm đối tượng nào cần hệ thống trợ giúp để làm công việc?
Trong hệ thống ATM
Khách hàng
Trong hệ thư viện
Thủ thư
Trần Thị Kim Chi 75
Actor trong uml
• Tác nhân hỗ trợ (secondary actor): những nhóm đối tượng nào hệ thống cần để thực hiện hoạt động của nó (vd: quản trị, dọn dẹp,…)
Trong hệ thống ATM
Trong hệ thư viện
Nhân viên vận hành
Quản trị hệ thống
• Những phần cứng hoặc hệ thống bên ngoài nào sử dụng hệ
thống?
Bán hàng
Hệ thống thanh toán
Trần Thị Kim Chi 76
Actor là thời gian (time)
• Thời gian sẽ trở thành actor của hệ thống nếu sau 1 khoảng thời gian nào đó thì nó kích khởi (trigger) một số sự kiện (event).
Ví du: • Hệ thống POS, cứ vào 5 giờ chiều ngày thứ bảy thì hệ thống sẽ tự động thống kê tình hình bán hàng trong tuần và in phiếu đặt hàng mới.
• Hệ thống đặt vé tự động, cứ 3 giờ chiều mỗi ngày, hệ thống sẽ tự động chọn ngẫu nhiên 1 khách hàng để tặng vé khuyến mãi
Trần Thị Kim Chi 77
Actor trong uml
• Tác nhân trừu tượng (abstract actor)
• Business actor(tác nhân nghiệp vụ): chỉ có trong mô hình
RUP, không phải là chuẩn của UML
• Lưu ý: Business actor (tác nhân nghiệp vụ)
phải liên quan đến business use case
Trần Thị Kim Chi 78
Actor trong uml
• Quan hệ giữa các Actor
– Tổng quát hóa (generalization) Một dạng của tính kế thừa – Chuyên biệt hóa(Specialization
Trần Thị Kim Chi 79
VÍ DỤ - MÔ TẢ BÀI TOÁN
Trần Thị Kim Chi 80
VÍ DỤ - MÔ TẢ BÀI TOÁN
• Hệ thống POS (Point-Of-Sale) là một ứng dụng máy tính tự động hóa được dùng để lưu trữ lại hồ sơ bán hàng và quản lý việc thanh toán. Hệ thống được dùng cho các cửa hàng bán lẻ. • Yêu cầu phần cứng chỉ gồm máy tính và máy quét mã vạch
(bar code scanner).
• Phần mềm có thể liên kết được với các ứng dụng khác như tính thuế, quản lý kho,... Hệ thống cũng cần có khả năng hoạt động ngay cả khi có lỗi kết nối với các dịch vụ khác chẳng hạn như khi hệ thống quản lý kho hay dịch vụ thanh toán từ xa, tạm thời không kết nối được thì hệ thống POS vẫn có thể quản lý việc bán hàng và thanh toán bằng tiền mặt.
Trần Thị Kim Chi 81
VÍ DỤ - MÔ TẢ BÀI TOÁN
Xác định Phạm vi hệ thống: • Ví dụ: Case study POS • Việc thanh toán có được hoàn thành bên trong phạm vi hệ
thống không?
• Không, cần có 1 actor “ payment authorization service actor”
bên ngoài hệ thống
Trần Thị Kim Chi 82
VÍ DỤ - MÔ TẢ BÀI TOÁN
Trần Thị Kim Chi 83
VÍ DỤ - MÔ TẢ BÀI TOÁN
Actor chính và mục tiêu phụ thuộc vào đường biên hệ thống • Tại sao actor chính của use case “Process Sale” là cashier mà
không phải là customer?
• Tại sao customer hầu như không xuất hiện trong danh sách
actor-goal?
depends on the system boundary of the system under design
Trần Thị Kim Chi 84
VÍ DỤ - MÔ TẢ BÀI TOÁN
Bài tập quản lý thư viện, vé tàu, sinh viên Trần Thị Kim Chi
85
USE CASE
• Use case: biểu diễn một chức năng của hệ thống phần mềm • Use case được biểu diễn bằng một chuỗi các thông điệp trao đổi bên trong hệ thống và/hoặc một số thông điệp trao đổi với Actor • Quy ước:
– Use case luôn được bắt đầu từ thông điệp đến từ actor – Use case phải hoàn tất: chuỗi thông điệp phải được kết thúc
bằng kết quả cụ thể
– Lỗi hay gặp: chia nhỏ use case thành các chức năng vụn
vặt.
• Điểm mở rộng là một vị trí trong use case mà tại đó có thể
chèn chuỗi sự kiện của một use case khác
Trần Thị Kim Chi 86
USE CASE
• Use case có thể chứa điều kiện rẽ nhánh, xử lý lỗi, ngoại lệ • Kịch bản (scenario): miêu tả trình tự các sự kiện xảy ra khi use
case được thực hiện
Trần Thị Kim Chi 87
TÌM USE CASE
Việc tìm các use-case phụ thuộc vào điểm xuất phát : nếu xuất phát từ mô hình nghiệp vụ hay mô hình lĩnh vực thì việc tìm use- case rất đơn giản. Còn nếu xuất phát từ các ý niệm mơ hồ thì hãy trả lời các câu hỏi sau :
Actor yêu cầu chức năng gì của hệ thống? Actor cần phải đọc, tạo, xóa, sửa đổi hoặc lưu trữ thông tin
nào của hệ thống?
Actor cần thiết phải được cảnh báo về những sự kiện trong hệ thống, hay actor cần phải báo hiệu cho hệ thống về vấn đề nào đó không?
Hệ thống có thể hỗ trợ một số công việc thường nhật của
actor nào đó không?
• Một số câu hỏi lưu ý:
– Hệ thống cần dữ liệu input/ output nào? Dữ liệu đến từ đâu? – Những khó khăn liên quan đến hiện thực của hệ thống?
Trần Thị Kim Chi 88
TÌM USE CASE
• Đặt tên: dùng động từ + danh từ • Biểu diễn: hình ellipse
Tên use case
Tên use case
• Use case nghiệp vụ
(Business Usecase) (RUP)
– Phải quan hệ với Business Actor
Trần Thị Kim Chi 89
TÌM USE CASE
Ví dụ: Ngân hàngABC đưa ra các yêu cầu sau: • Một khách hàng có thể muốn gửi tiền vào, rút tiền ra hoặc đơn giản kiểm tra lại số tiền trong tài khoản của anh ta qua máy tự động rút tiền (ATM). Khi đưa tiền vào hoặc rút tiền ra, cần phải in ra giấy kết quả những giao dịch đã thực hiện cho khách hàng.
a) Xác định các actor và use case
b) Vẽ lược đồ Use case
Các Use case trong hệ thống ATM
Bài tập quản lý thư viện, vé tàu, sinh viên Trần Thị Kim Chi
90
CÁC MỐI QUAN HỆ - RELATIONSHIP
• Các mối quan hệ:
– Giữa actor với actor – Actor với use case – Use case với use case
• Các ký hiệu quan hệ và tính chất – Tổng quát hóa (Generalization) – Kết hợp (Associtaion) – Mở rộng (Extend) – Bao gộp (Include)
Trần Thị Kim Chi 91
QUAN HỆ TỔNG QUÁT HÓA (Generalization)
• Khi một số các Use Case cùng xử lý các chức năng tương tự hoặc có thể liên quan đến nhau theo một phương thức nào đó.
• Nhiều use case là trường hợp cụ thể của use case trừu tượng • Kí hiệu:
Authenticate WithPassword
Authenticate
Authenticate WithCard
Trần Thị Kim Chi 92
QUAN HỆ KẾT HỢP(Association)
• Chỉ ra mối quan hệ có ý nghĩa giữa 2 bên
– VD:???
• Một số tính chất liên quan:
– Tên của liên kết – Một chiều hay 2 chiều – Bậc: số lượng thực thể tham gia vào liên kết mỗi bên
• Biểu diễn trong UML:
– Đoạn thẳng (2 chiều) hoặc mũi tên (1 chiều)
• Áp dụng các stereotype:
– <
Trần Thị Kim Chi 93
QUAN HỆ LIÊN KẾT - ASSOCIATION
• Liên kết là quan hệ duy nhất giữa Actor và Use case • Có thể một chiều hoặc 2 chiều
– Actor kích hoạt use case và nhận kết quả trả về: 2 chiều – Actor kích hoạt use case và không quan tâm kết quả trả
về: 1 chiều
• VD:
Trần Thị Kim Chi 94
QUAN HỆ GIAO TIẾP - COMMUNICATE
• Là dạng Association mà có stereotype là
<
• Dùng để liên kết giữa use case và actor mà nó kích
hoạt • Ví dụ
Trần Thị Kim Chi 95
QUAN HỆ GỘP - INCLUDE
• Là dạng association có stereotype là <
phải chèn use case đích vào
• Tại điểm mở rộng: diễn tiến của use case nguồn tạm thời ngừng
lại để chuyển sang diễn tiến của use case đích
• Khi kết thúc use case đích, diễn tiến của use nguồn lại tiếp tục. • Ví dụ
Giao dịch
Đăng nhập
<
Khách hàng
Hệ thống ATM
Trần Thị Kim Chi 96
QUAN HỆ MỞ RỘNG - extend
• Là dạng association có stereotype là <
chèn use case đích vào
• Chèn thêm use case hay không phụ thuộc vào điều kiện rẽ nhánh hoặc tương
tác từ actor.
• Tại điểm mở rộng, nếu được mở rộng thì diễn tiến của use case nguồn tạm thời
dừng lại để chuyển sang diễn tiến của use case đích
• Khi kết thúc use case đích, diễn tiến của use case nguồn lại tiếp tục • VD:
Xử lý mượn sách
<
<
Mượn sách từ thư viện thành viên
Xử lý từ chối mượn sách
Hệ thống thư viện
Trần Thị Kim Chi 97
Ví dụ: Use Case Diagram
• The owner of the local video rental store wants
Actor?
to radically change how his video rental business works. Currently, he has the traditional video rental store where customers become members, come into the video rental store to rent a video, and return the video. With his new business plan, he hopes to increase his profit margin by increasing video sales and reducing staff.
Trần Thị Kim Chi 98
Use Case Diagram
•
In his new business plan, he wants to have the customers do everything online but the picking up and returning the videos. He wants a VRS website that allows the customers to become members or search the video inventory (by video name, actor name, director name, type of video (new release, western, mystery(bí ẩn), drama(truyền hình), comedy(phim hài), children, etc.), or video rating). The VRS website also allows members to log on as a member, search the video inventory (as before), select videos to rent (videos must be located at the store location where the member wants to pick up the videos), modify membership information, and check out the videos.
Trần Thị Kim Chi 99
Use Case Diagram
•
Actor?
The member can also pay late fees online since videos cannot be rented by a member with outstanding late fees. The paying of late fees and the rental of videos is to be charged to a credit card number provided by the customer in the membership application process. Provided with each rental is a video rental form which lists, for each video rented, the video ID, video name, and the due date and the rental charges charged to the member’s credit card. Rented videos can be returned to any of the owner’s video stores. Rented videos that are not picked up within 24 hours are returned to the available inventory; however, the rental charged is not removed from the member’s credit card.
Trần Thị Kim Chi 100
Use Case Diagram
•
•
On the day before a rented video is due to be returned, the VRS will email members with due notices which reminds them that the video is due. This due email will be sent to the member every 3 days after the video’s due date. After 60 days of being past its due date, a $30 charge for each overdue video is processed on the member’s credit card, and an email is sent to the member to notify them of this charge. The length of rental is 5 days. The pick-up and return of rented videos is only done through a drive-through facility at the video store. The ability for the customer to come into the video rental store to search for and rent videos is no longer available with this new business plan.
Trần Thị Kim Chi 101
Use Case Diagram
Actor? •
The owner of the video store also wants to automate his
inventory processing. He can now get newly ordered videos
with a video ID (via a bar code) on the video packaging. When
new videos arrive at a store, the owner wants to simply scan
the video ID which then retrieves the video information from
the video distributor via the Internet (the video distributors
provide this feature on their websites). All the video
information (i.e., its name, rating (e.g., G, PG, R), director,
length in minutes, actors) are automatically stored in the
store’s video inventory. The owner then indicates the store 102 Trần Thị Kim Chi location where the video will be placed. When he wants to
Use Case Diagram
•
Note on rental fees: the amount of the rental fee is determined by its type. New releases are at a rental fee of $3.00. All the remaining types except children’s are at a rental fee of $2.00. Children’s videos are at a rental fee of $1.00. Once a video is no longer considered a new release, the owner changes its type from new release to the appropriate type (western, mystery, drama, comedy, etc.).
Trần Thị Kim Chi 103
Use Case Diagram
Build use case diagram for a video rental system
Potential ACTORS
Customers Owner Member
Trần Thị Kim Chi 104
Use Case Diagram
• Build use case diagram for a video rental
system
Register Membership
Potential USE CASES
Search Videos
Rent Video
Pay Late Fee
become members select videos rent a video pay late fees return videos charge to a credit card email member of due notice email member of charge for overdues
Return Video
Trần Thị Kim Chi 105
Use Case Diagram
• Build use case diagram
Email Due Notices
Potential USE CASES
Add New Video
Remove Video
Modify VideoLocal
become members rent a video select videos modify membership information pay late fees charge to a credit card email member of due notice email member of charge for overdues remove videos add videos
Trần Thị Kim Chi 106
Use Case Diagram
Register as Member
Customer Search Videos
Trần Thị Kim Chi 107
Use Case Diagram
Register as Member
Customer Search Videos
Rent Videos
Pay Late Fee
Member Clerk Return Video
Trần Thị Kim Chi 108
Use Case Diagram
Register as Member
Customer Search Videos
Rent Videos
Pay Late Fee
Add New Video
Member Clerk Return Video
Distributor
Remove Video
Owner
109 Modify Trần Thị Kim Chi Video
Use Case Diagram
Register as Member
Customer Search Videos
Rent Videos
Pay Late Fee
Member Clerk Return Video
Email Due Notices
Add New Video
Timer
Distributor
Remove Video
Owner
110 Modify Trần Thị Kim Chi Video
Use Case Diagram
Register as Member
Customer Login Search Videos
Rent Videos
Pay Late Fee
Member Clerk Return Video
Email Due Notices
Add New Video
Timer
Distributor
Remove Video
Owner
111 Modify Trần Thị Kim Chi Video
Use Case Diagram
Print Rental Form Register as Member
Customer Login Search Videos
Rent Videos
Pay Late Fee
Member Clerk Return Video
Email Due Notices
Add New Video
Timer
Distributor
Remove Video
Owner
112 Modify Trần Thị Kim Chi Video
Use Case Diagram
Print Rental Form Register as Member
Customer Login Search Videos
Rent Videos
Pay Late Fee
Member Clerk Return Video
<
Email 60 Day Notice
Email Due Notices
Add New Video
Timer
Distributor
Remove Video
Owner
113 Modify Trần Thị Kim Chi Video
Case Study 1 - safe home access system
Bài tập quản lý thư viện, vé tàu, sinh viên Trần Thị Kim Chi
114
Case Study 1 - safe home access system
Trần Thị Kim Chi 115
Case Study 1 - safe home access system
actor và use case của case study
Trần Thị Kim Chi 116
Case Study 1 - safe home access system
actor và use case của case study
Trần Thị Kim Chi 117
Case Study 1 - safe home access system
actor và use case của case study
Trần Thị Kim Chi 118
Case Study 2- Limited ATM Corp
• A Bank wishes to introduce ATM service to provide limited
facilities to her customers. Customers may get ATM cards on request. Users may only view their balance or withdraw money using these cards. Cards are given for only one account, but an account may be accessed using different cards. A card may be blocked temporarily or permanently by the Bank (e.g. If it is lost). A PIN is associated with each card to verify the authenticity of the user. There is an Over Draft (OD) limit associated with each checking account. Theoretically, any amount may be withdrawn from a checking account at any time (provided it is less than the balance + OD limit and assume always enough money is left in the machine), but there is a withdrawal limit (for a day) for each savings account. There is no OD facility for a savings account.
Trần Thị Kim Chi 119
Case Study 2- Limited ATM Corp
• The personal information of the customers and their account details are already maintained by the Bank’s main system. A subsystem is required to handle the ATM’s functionality. There will be two hardware systems Card reader and Money dispenser communicating with this subsystem. The card reader reads the Card-No and passes it to the system. It is also able to eject the card when an eject signal is received from the system. Similarly the money dispenser is able to dispense the required amount of money.
Trần Thị Kim Chi 120
Case Study - Limited ATM Corp
• The Limited ATM system is required to provide at least the
following operations. – Enter a new card detail – Modify the validity of card – Check the validity of the card – Check the authenticity of the user – View the balance of the account – Withdraw money from the account – Withdrawal information will be stored for later use – (Includes date, time, machineNo, cardNo, and amount) – Change the PIN of a card – Here the first two operations are to be carried out by the Bank and the
rest by the user.
Trần Thị Kim Chi 121
BÀI TẬP - MÔ TẢ BÀI TOÁN
Xây dựng mô hình nghiệp vụ cho bài toán • Một bãi gửi xe có 2 cổng: một cổng xe vào, một cổng xe ra. Người ta chia bãi thành 4 khu dành cho 4 loại xe khác nhau: xe máy, xe buýt, xe tải và công-ten-nơ.
• Khi khách đến gửi xe, người coi xe nhận dạng xe theo bảng phân loại, sau đó kiểm tra chỗ trống trong bãi. Nếu chỗ dành cho loại xe đó đã hết thì thông báo cho khách. Ngược lại thì ghi vé đưa cho khách và hướng dẫn xe vào bãi, đồng thời ghi những thông tin trên vé vào sổ xe vào.
Trần Thị Kim Chi 122
BÀI TẬP - MÔ TẢ BÀI TOÁN
• Khi khách lấy xe, người coi xe kiểm tra vé xem vé là thật hay giả, đối chiếu vé với xe. Nếu vé giả hay không đúng xe thì không cho nhận xe. Ngược lại thì viết phiếu thanh toán và thu tiền của khách, đồng thời ghi các thông tin cần thiết vào sổ xe ra.
• Khi khách đến báo cáo có sự cố thì kiểm tra xe trong sổ xe vào và sổ xe ra để xác minh xe có gửi hay không và đã lấy ra chưa. Nếu không đúng như vậy thì không giải quyết. Trong trường hợp ngược lại tiến hành kiểm tra xe ở hiện trường. Nếu đúng như sự việc xảy ra thì tiến hành lập biên bản giải quyết và trong trường hợp cần thiết thì viết phiếu chi bồi thường cho khách.
Yêu cầu: Vẽ biểu đồ usecase
Trần Thị Kim Chi 123
ĐẶC TẢ USE CASE (Use case specification)
• Use caselà 1tập hợp các scenario thành công cũng như thất bại
có liên quan đến các actor khi sử dụng hệ thống.
Tên use case – Số thứ tự use case (nếu có)
Miêu tả ngắn gọn use case
Dòng chảy sự kiện (dòng logic chung)
Dòng hành động chính (dòng logic chi tiết, các hoạt động bình thường)
Dòng hành động thay thế (chuỗi logic hay thế, các hoạt động bất thường)
Điều kiện thoát (Use case kết thúc như thế nào)
Các yêu cầu đặc biệt
Điều kiện trước (điều xảy ra trước khi use thực hiện)
Điều kiện sau (điều xảy ra sau khi use case thực hiện)
Trần Thị Kim Chi 124
ĐẶC TẢ USE CASE (Use case specification)
Trần Thị Kim Chi 125
ĐẶC TẢ USE CASE (Use case specification)
Trần Thị Kim Chi 126
ĐẶC TẢ USE CASE (Use case specification)
Trần Thị Kim Chi 127
ĐẶC TẢ USE CASE Để viết đặc tả use case hiệu quả
Nên dùng câu chủ động (active) và viết theo quan điểm của người dùng. “The capability is provided for users to log in, using a password- protected authorization scheme” Dạng passive voice “The user enters her username and password, and then clicks the Login button. The system looks up the user profile using the username and checks the password. The system then logs in the user”
Dạng active
Trần Thị Kim Chi 128
ĐẶC TẢ USE CASE Để viết đặc tả use case hiệu quả
• UC mô tả sự tương tác 2 chiều bao gồm: system’s
behavior + user’s behavior.
• Một UC chứa nhiều bước (step) khác nhau, mỗi bước
liên quan đến 1sự kiện (event) và 1đáp ứng (response): the user’s action and the system’s reaction, or vice versa
So a use case really describes a dialogue between a user and the system.
Trần Thị Kim Chi 129
ĐẶC TẢ USE CASE Để viết đặc tả use case hiệu quả
• Nên phác họa kịch bản của UC bằng hình vẽ (storyboard) hay
bằng text
• The user clicks the Edit Shopping Cart button, and the system shows the Edit Shopping Cart page with a list of books in the user’s shopping cart. The user selects one of the books, changes the quantity, and clicks the Update button. The system shows the page with the quantities and price totals updated. Trần Thị Kim Chi
130
Use Case Specification: Natural Language Example
Use Case 1. Withdraw Money
The system displays the account
types available to be withdrawn from and the user indicates the desired type. The system asks for the amount to be withdrawn and the user specifies it. Next, the system debits the user’s account and dispenses the money. The user removes the money, the system prints a receipt, and the user removes the receipt. Then the system displays a closing message and dispenses the user’s ATM card. After the user removes his card, the system displays the welcome message.
Trần Thị Kim Chi 131
ATM System
system name system boundary
primary actor secondary actor
1 Withdraw Money
Customer Accounts Database
2 Deposit Money Bank Customer
role
3 Transfer Money
association
<
alternative actor notation
stereotype 132 Trần Thị Kim Chi
Use Case Specification Template*
Number
Name
Summary
Priority
Preconditions
Postconditions
Primary Actor(s)
Secondary Actor(s)
Trigger
Main Scenario
Step
Action
Extensions
Step
Branching Action
Open Issues
136 Trần Thị Kim Chi *Adapted from A. Cockburn, “Basic Use Case Template”
Use Case Specification Template*
Unique use case number
Number
Brief verb-noun phrase
Name
Brief summary of use case major actions
Summary
1-5 (1 = lowest priority, 5 = highest priority)
Priority
Preconditions
Postconditions
Primary Actor(s)
Secondary Actor(s)
Trigger
Main Scenario
Step
Action
Extensions
Step
Branching Action
Open Issues
137 Trần Thị Kim Chi *Adapted from A. Cockburn, “Basic Use Case Template”
Use Case Specification Template*
Number
Name
Summary
Priority
What needs to be true before the use case “executes”
Preconditions
What will be true after the use case successfully “executes”
Postconditions
Primary Actor(s)
Precondition: None
Secondary Actor(s) Precondition: y != 0 Trigger
Main Scenario
Step
Action
Postcondition: x / y
Postcondition: if y==0 “Illegal”, else x / y
double divide(double x, double y) {
double divide(double x, double y) {
Extensions
Step
Branching Action
return (x / y);
if (y == 0) cout <<
Open Issues
}
“Illegal\n”; 138 Trần Thị Kim Chi *Adapted from A. Cockburn, “Basic Use Case Template”
else return (x / y);
Actor
Use Case Specification Template*
Number
• Anyone or anything with behavior
Name
Summary
• May be a person or system
Priority
Preconditions
Postconditions
Primary actor name(s)
Primary Actor(s)
Secondary actor name(s)
Secondary Actor(s)
Trigger
Main Scenario
Step
Action
• Primary: The stakeholder who or which initiates an interaction with the system to achieve a goal. Is generally a category of individuals (a role).
Extensions
Step
Branching Action
• Secondary: Provides a service to the system. Is almost never a person.
Open Issues
139 Trần Thị Kim Chi *Adapted from A. Cockburn, “Basic Use Case Template”
Use Case Specification Template*
Number
Name
Summary
Priority
Preconditions
Postconditions
Primary Actor(s)
Secondary Actor(s)
The action that caused the use case to be invoked
Trigger
Main Scenario
Step
Action
Step #
This is the “main success scenario” or “happy path”
Step #
Description of steps in successful use case “execution”
This should be in a “system-user-system, etc.” format
Step #
Extensions
Step
Branching Action
Open Issues
140 Trần Thị Kim Chi *Adapted from A. Cockburn, “Basic Use Case Template”
Use Case Specification Template*
Number
Name
Summary
Priority
Preconditions
Postconditions
Primary Actor(s)
Extension
Secondary Actor(s)
Trigger
• Could be an optional path(s)
Main Scenario
Step
Action
• Could be an error path(s)
Extensions
Branching Action
Step
Step #
• Denoted in use case
diagrams (UML) by
<>
Alternative paths that the use case may take
Open Issues
141 Trần Thị Kim Chi *Adapted from A. Cockburn, “Basic Use Case Template”
Use Case Specification Template*
Number
Name
Summary
Priority
Preconditions
Postconditions
Primary Actor(s)
Secondary Actor(s)
Trigger
Main Scenario
Step
Action
Extensions
Step
Branching Action
Issue #
Issues regarding the use case that need resolution
Open Issues
142 Trần Thị Kim Chi *Adapted from A. Cockburn, “Basic Use Case Template”
Use Case Specification Template*
Unique use case number
Number
Brief noun-verb phrase
Name
Brief summary of use case major actions
Summary
1-5 (1 = lowest priority, 5 = highest priority)
Priority
What needs to be true before use case “executes”
Preconditions
What will be true after the use case successfully “executes”
Postconditions
Primary actor name(s)
Primary Actor(s)
Secondary actor name(s)
Secondary Actor(s)
The action that causes this use case to begin
Trigger
Main Scenario
Step
Action
Step #
This is the “main success scenario” or “happy path.”
…
Description of steps in successful use case “execution”
This should be in a “system-user-system, etc.” format.
…
Extensions
Step
Branching Action
Step #
Alternative paths that the use case may take
Issue #
Issues regarding the use case that need resolution
Open Issues
143 Trần Thị Kim Chi *Adapted from A. Cockburn, “Basic Use Case Template”
Use Case Specification Template Example
Number 1
Name Withdraw Money
Summary User withdraws money from one of his/her accounts
Priority
5
Preconditions User has logged into ATM
Postconditions User has withdrawn money and received a receipt
Primary Actor(s) Bank Customer
Continued …
Secondary Actor(s) Customer Accounts Database
144 Trần Thị Kim Chi
Trigger User has chosen to withdraw money
Main Scenario
Step
Action
System displays account types 1
User chooses account type 2
System asks for amount to withdraw 3
User enters amount 4
User removes money
6
System debits user’s account and dispenses money 5
System prints and dispenses receipt 7
User removes receipt 8
System displays closing message and dispenses user’s ATM card 9
User removes card 11
System displays welcome message 10
Extensions
Step
Branching Action
System notifies user that account funds are insufficient 5a
System gives current account balance 5b
System exits option 5c
1 Open Issues Should the system ask if the user wants to see the balance? 145 Trần Thị Kim Chi
BÀI TẬP USE CASE
1. Với hệ thống đặt vé máy bay, người dùng có thể đặt vé, thay đổi hay huỷ vé. Use case của hệ thống là gì??
2. Nếu cần xây dựng hệ thống quản lý máy ATM, thì use case “withdrawing cash” có những scenario nào?
Trần Thị Kim Chi 146
Phân tích package
• Một gói (Package) là một cơ chế có mục đích tổ chức các yếu tố
thành các nhóm. Một gói chứa các phần tử mô hình khác.
University Artifacts
• Một gói có thể được sử dụng:
– Để tổ chức các mô hình phát triển.
– Là một đơn vị quản lý cấu hình.
Dependency relationship
Client Package
Supplier Package
Trần Thị Kim Chi 147
Phân tích package
• Mục đích của phân tích package là :
đảm bảo từng package độc lập với các package khác đảm bảo package hoàn thành mục đích của nó là hiện thực 1 số
class lĩnh vực hoặc 1 số use-case.
miêu tả các phụ thuộc sao cho có thể ước lượng ảnh hưởng của
các thay đổi trong tương lai.
• Cách phân tích:
đảm bảo package chứa các class đúng, cố gắng cho tính kết dính
cao bằng cách gộp các class có mối quan hệ chức năng.
hạn chế tối đa sự phụ thuộc giữa các package, phân phối lại các
class quá phụ thuộc vào package khác.
Trần Thị Kim Chi 148
Phân tích package
A
A
B
B
Hierarchy should be acyclic
A
C
B
A'
C
Circular dependencies make it impossible
to reuse one package without the other. Trần Thị Kim Chi
149
PACKAGE USE CASE
• Khi nào dùng:
– Khi hệ thống lớn,sơ đồ use case phức tạp – Package: gom một số use case liên quan tạo nên một sub
system của hệ thống
• Ký hiệu:
Tên
• Ví dụ: hệ thống ATM gồm các package
Trần Thị Kim Chi 150
PACKAGE USE CASE
Trần Thị Kim Chi 151
MÔ HÌNH HÓA NGHIỆP VỤ-TỔNG QUAN
• Mô hình hóa nghiệp vụ (Business Modeling) – Là kỹ thuật mô hình hóa tiến trình nghiệp vụ – Mô hình hóa các chức năng của tổ chức – Quan tâm đến góc nhìn chức năng. Không phân biệt các tiến trình nghiệp vụ sẽ được tự động hóa hay thực hiện thủ công
• Biểu diễn mô hình nghiệp vụ bằng biểu đồ nghiệp vụ
– Chỉ ra tương tác giữa các tiến trình nghiệp vụ với các vai trò (roles) thực hiện nghiệp vụ như customers hay vendors – Biểu diễn vai trò bên ngoài nghiệp vụ • Hai lĩnh vực của mô hình hóa nghiệp vụ
– Biên của tổ chức và nó cần giao tiếp với ai? – Luồng công việc bên trong tổ chức và tối ưu nó như thế nào?
Trần Thị Kim Chi 152
MÔ HÌNH HÓA NGHIỆP VỤ-TỔNG QUAN
• Không tập trung vào mô hình hóa hệ thống sẽ xây dựng • Tập trung vào nghiệp vụ trên hệ thống
– Mục tiêu là để hiểu rõ môi trường nghiệp vụ trước khi xây dựng hệ
thống
• Mô hình hóa nghiệp vụ – Nghiên cứu về tổ chức – Khảo sát cấu trúc tổ chức, quan sát các vai trò trong tổ chức và quan
hệ của chúng với nhau như thế nào. – Khảo sát luồng công việc trong tổ chức
• Tiến trình chính, họ làm việc thế nào • Tính hiệu quả • Các hạn chế
• Nghiên cứu các tổ chức bên ngoài và quan hệ với chúng? • Làm tài liệu về các thông tin bằng mô hình nghiệp vụ của
UML
Trần Thị Kim Chi 153
MÔ HÌNH HÓA NGHIỆP VỤ-TỔNG QUAN
• Khi nào không cần mô hình hóa nghiệp vụ?
– Khi đã hiểu biết rõ ràng cấu trúc, mục đích tác nghiệp,
stackholders của tổ chức
– Khi xây dựng phần mềm sử dụng cho một phần nhỏ của tổ
chức, không ảnh hưởng đến nghiệp vụ khác
– Luồng công việc khá rõ ràng và có tài liệu đầy đủ – Khi không có đủ thời gian!!!!????
Trần Thị Kim Chi 154
CÁC KHÁI NIỆM CƠ BẢN CỦA MÔ HÌNH HÓA NGHIỆP VỤ (Business Modeling)
• Các khái niệm cơ bản bao gồm
– Business actors – Business workers – Business use case – Biểu đồ Business use case – Quan hệ giao tiếp giữa Business use case và
Business actor
– Thực thể Business – Các biểu đồ hoạt động
Trần Thị Kim Chi 155
TÁC NHÂN NGHIỆP VỤ
• Ai đó, cái gì đó bên ngoài tổ chức nhưng tương tác với nó
– Customers, Investors, Suppliers... – Có thể là nguời hay nhóm nguời
• Tìm kiếm tác nhân nghiệp vụ?
– Quan sát phạm vi dự án để tìm ra những gì nằm ngoài dự án – Những gì (ai, cái gì) nằm ngoài dự án có liên quan đến nghiệp
vụ
• Nghiên cứu tài liệu mô tả dự án, thị trường tổ chức, mục tiêu
nghiệp vụ... để xác định thực thể bên ngoài liên quan – Thí dụ: Hãng hàng không liên quan đến nhà sản xuất máy bay, nhà sản xuất đồ ăn uống cho khách, khách hàng, hiệp hội hàng không...
• Có 2 loại: tác nhân thực hiện các công việc bên trong hệ thống và các tác nhân tương tác trực tiếp với các tác nhân bên ngoài hệ thống. 156 Trần Thị Kim Chi
WORKER NGHIỆP VỤ
• Là vai trò (role) trong tổ chức
– Một người có thể có nhiều vai trò – không phải là chức vụ
• Mô tả worker
– Có trách nhiệm gì? – Kỹ năng cần có để thực hiện trách nhiệm? – Tương tác với worker nào? – Tham gia vào luồng công việc nào? – Trách nhiệm của worker trong luồng công việc
• Tìm kiếm worker nghiệp vụ
– Quan sát phạm vi dự án – bắt đầu từ biểu đồ tổ chức – Khi đã có danh sách worker thì làm tài liệu cho chúng • Thí dụ worker nghiệp vụ trong công ty hàng không
– Phi công, người dẫn đường, thợ máy, tiếp viên, nhân viên an ninh... Trần Thị Kim Chi
157
USE CASE NGHIỆP VỤ
• Business use case là nhóm các luồng công việc liên quan có ý
nghĩa với tác nhân nghiệp vụ – Cho biết tổ chức làm gì – Tập các ca nghiệp vụ mô tả đầy đủ nghiệp vụ của tổ chức
• Ðặt tên: Theo hình thức “<động từ>
VD: “Price Products”
• Làm tài liệu luồng công việc
– Thí dụ với use case nghiệp vụ Price Products
• Nhân viên yêu nguời cầu quản lý cung cấp danh sách các mặt hàng
mới cần định giá
• Nhân viên kiểm tra hóa đơn kho để biết phải trả cho kho bao nhiêu
kho hàng bán
• Nhân viên cộng thêm 10% để có giá bán • Nhân viên trình giá để nguời quản lý phê duyệt • Nhân viên làm các thẻ sản phẩm • Gắn thẻ giá sản phẩm vào từng sản phẩ
Trần Thị Kim Chi 158
TƯƠNG TÁC GIỮA CÁC PHẦN TỬ
• Biểu diễn tương tác
– Quan hệ association:
• giữa tác nhân nghiệp vụ, worker nghiệp
vụ với use case nghiệp vụ
• mũi tên cho biết ai khởi xướng tiến trình
– Quan hệ generalization
• chỉ ra cấu trúc kế thừa giữa các
phần tử mô hình nghiệp vụ
áp dụng cho hai hay nhiều phần
tử tương tự nhau
Trần Thị Kim Chi 159
BIỂU ĐỒ USE CASE NGHIỆP VỤ
• Chỉ ra mô hình đầy đủ
– cái công ty làm – ai ở trong công ty – ai ở ngoài công ty
• Cho biết phạm vi của tổ chức • Nếu có nhiều use case nghiệp vụ có thể tạo nhiều biểu đồ UC nghiệp vụ và mỗi biểu dồ chứa tập các UC nghiệp vụ
• Mũi tên đi từ tác nhân nghiệp
vụ và worker nghiệp vụ đến
• UC nghiệp vụ cho thấy ai khởi động tiến trình nghiệp vụ.
Trần Thị Kim Chi 160
THỰC THỂ NGHIỆP VỤ
• Business entity là đối tuợng mà tổ chức sử dụng để điều hành
tác nghiệp hay sản xuất.
• Thực thể bao gồm tất cả những gì mà worker nghiệp vụ có liên
quan hàng ngày – Thí dụ: Sales Order, Account, Shiping Box, Contract, Ghim giấy...
• Trả lời các câu hỏi sau để tìm thực thể nghiệp vụ:
– Sản phẩm của công ty? – Công ty có các dịch vụ? – Công ty phải mua vật liệu gì để sản xuất? – Khách hàng cung cấp/nhận gì từ công ty? – Các worker nghiệp vụ trao đổi nhau cái gì khi sản xuất?
• Tìm kiếm thực thể nghiệp vụ ở nơi khác – Các danh từ trong use case nghiệp vụ
Trần Thị Kim Chi 161
THỰC THỂ NGHIỆP VỤ
• Ví dụ:
• Bổ sung các thuộc tính cho thực thể nghiệp vụ
– Thí dụ, thực thể nghiệp vụ Account có các thuộc tính account number, account type, balance, date opened, status...
– Chú ý rằng chưa có thiết kế CSDL ở đây – Chỉ bổ sung các thuộc tính để dễ hiểu nghiệp vụ
Trần Thị Kim Chi 162
ÐƠN VỊ TỔ CHỨC
• Ðơn vị tổ chức (Organization Unit) là tập hợp các
worker
nghiệp vụ, thực thể nghiệp vụ và các phần tử mô hình nghiệp vụ khác • Là cơ chế đuợc sử dụng để tổ chức mô hình nghiệp
vụ
• Nhiều công ty tổ chức theo phòng, ban, đơn vị... – Mỗi chúng được mô hình hóa như đơn vị tổ chức – Mỗi đơn vị tổ chức sẽ bao gồm các worker nghiệp vụ bên
trong phòng, ban, đơn vị đó.
• Biểu tượng
Trần Thị Kim Chi 163
BIỂU ĐỒ USE CASE NGHIỆP VỤ
• Thực tế: luồng công việc (Workflow) không đơn giản mà có
nhiều logíc điều kiện – worker nghiệp vụ có thể thực hiện một vài actions khi điều
kiện A xảy ra và thực hiện một vài actions khác khi điều kiện B xảy ra...
– hãy sử dụng biểu đồ hoạt động (Activity Diagram) để mô
hình hóa các luồng công việc
• Nếu trong biểu đồ UC nghiệp vụ có nhiều UC nghiệp vụ, tác nhân nghiệp vụ và worker nghiệp vụ thì có thể nhóm chúng thành các đơn vị tổ chức (Organizational Units)
– tổ chức lại mô hình để dễ dọc và dễ hiểu – sau đó xây dựng biểu đồ UC nghiệp vụ cho từng đơn vị tổ
chức
Trần Thị Kim Chi 164
BIỂU ĐỒ USE CASE NGHIỆP VỤ
Ví dụ: các loại use case nghiệp vụ của một tổ chức nhà hàng
Trần Thị Kim Chi 165
BIỂU ĐỒ USE CASE NGHIỆP VỤ
Ví dụ: mô hình use case mô tả nghiệp vụ của siêu thị Co-op Mart
Trần Thị Kim Chi 166
CÂU HỎI VÀ BÀI TẬP
1. Hỏi: Một tác nhân (Actor) trong một Use Case luôn là
một con người Đáp: Sai, tác nhân là một người hoặc một vật nào đó tương
tác với hệ thống.
2. Hỏi: Hệ thống khác cũng có thể đóng vai trò tác nhân
trong một Use Case? Đáp: Đúng
3. Hỏi: Mỗi hệ thống chỉ có một Use Case?
Đáp: Sai
4. Hỏi: Biểu đồ Use case mô tả chức năng hệ thống?
Đáp: Đúng
Trần Thị Kim Chi 167
CÂU HỎI VÀ BÀI TẬP
Trần Thị Kim Chi 168
CÂU HỎI VÀ BÀI TẬP
• Đặc tả Use case cho các bài toán nghiệp vụ trên
Trần Thị Kim Chi 169
CÂU HỎI VÀ BÀI TẬP
• Là trưởng ban It của trường ĐH KHTN, bạn được yêu cầu phát triển một hệ thống đăng ký học phần mới hệ thống mới cho phép sinh viên đăng ký học phần và xem phiếu điểm từ máy tính cá nhân được kết nối vào mạng nội bộ của trường. Các giảng viên cũng có thể truy cập hệ thống này để đăng ký lớp dạy và nhập điểm cho các môn học.
• Trường sẽ giữ lại CSDL sẵn có về danh mục học phần mà trong đó lưu trữ toàn bộ thông tin về học phần. Đây là CSDL quan hệ và có thể truy cập bằng các câu lệnh SQL thông qua các server của trường. Hệ thống mới sẽ đọc các thông tin học phần trên CSDL cũ nhưng sẽ không cập nhập chúng. Phòng đào tạo sẽ tiếp tục duy trì các thông tin học phần thông qua hệ thống khác.
Trần Thị Kim Chi 170
CÂU HỎI VÀ BÀI TẬP
• Ở đầu mỗi học kỳ, sinh viên có thể yêu cầu danh sách các học phần được mở trong học kỳ đó. Thông tin về mỗi học phần, ví dụ như là tên giáo sư, khoa, và các môn học phần tiên quyết sẽ được cung cấp để giúp sinh viên chọn lựa.
• Hệ thống mới cho phép sinh viên được chọn 4 học phần được mở cho học kỳ tới. Mỗi sinh viên có thể đưa ra hai môn học thay thế trong trường hợp không thể đăng ký theo nguyện vọng chính. Các học phần được mở tối đa là 100 và tối thiểu là 30 sinh viên. Các học phần có ít hơn 30 sinh viên sẽ bị hủy bỏ.
• Đầu mỗi học kỳ, sinh viên có một khoảng thời gian để thay đổi các học phần đã đăng ký. Sinh viên chỉ có thể thêm hay hủy các học phần đăng kí trong khoảng thời gian này.
Trần Thị Kim Chi 171
CÂU HỎI VÀ BÀI TẬP
• Khi quá trình đăng ký đã hoàn tất cho mỗi sinh viên, hệ thống đăng kí sẽ gửi thông tin tới hệ thống thanh toán (billing system) để sinh viên có thể đóng học phí. Nếu một lớp bị hết chỗ trong quá trình đăng ký, sinh viên sẽ được thông báo về sự thay đổi trước khi xác nhận việc đăng ký học
• Ở cuối học kỳ, sinh viên có thể truy cập vào hệ thống để xem phiếu điểm. Vì thông tin về điểm của sinh viên phải được giữ kín, nên hệ thống cần có cơ chế bảo mật để ngăn cản việc truy cập không hợp lệ
• Các giảng viên có thể truy cập vào hệ thống để đăng ký những học phần mà họ sẽ dạy. Họ có thể xem danh sách các sinh viên đã đăng ký vào lớp của họ, cũng như nhập điểm sau mỗi khóa học.
Trần Thị Kim Chi 172
CÂU HỎI VÀ BÀI TẬP
Lập bảng chú giải (Glossary) của ứng dụng Course Registration: • Course (Học phần): Một môn học được dạy trong trường. • Course Offering (Lớp): Một lớp học cụ thể được mở trong mỗi học kỳ cụ thể cùng một học phần cụ thể được mở song song nhiều lớp trong mỗi học kỳ. Thông tin gồm cả ngày học trong tuần và giờ học.
• Course Catalog (Danh mục học phần): Danh mục đầy đủ
của tất cả các học phần được dạy trong trường. • Faculty: Toàn bộ cán bộ giảng dạy của trường. • Finance System (Hệ thống thanh toán): Hệ thống dùng để
xử lý các thông tin thanh toán học phí.
Trần Thị Kim Chi 173
CÂU HỎI VÀ BÀI TẬP
Lập bảng chú giải (Glossary) của ứng dụng Course Registration: • Grade (Điểm số): Điểm của mỗi sinh viên trong một lớp cụ
thể.
• Professor (Giáo sư): Người giảng dạy trong trường. • Report Card (Phiếu điểm): Toàn bộ điểm số cho tất cả học
phần một sinh viên đã học trong một học kỳ xác định.
• Roster (Danh sách sinh viên đăng ký): Tất cả sinh viên đăng
ký vào một lớp học cụ thể.
• Student (Sinh viên): Người đăng ký học các lớp của trường. • Schedule (Lịch học): Các học phần mà sinh viên đã chọn học
trong học kỳ hiện tại.
• Transcript (Bản sao học bạ): Bản sao tất cả điểm cho tất cả các học phần của một sinh viên cụ thể được chuyển cho hệ Trần Thị Kim Chi thống thanh toán để hệ thống này lấp hóa đơn cho mỗi sinh viên.
174
CÂU HỎI VÀ BÀI TẬP
• Vẽ lược đồ Use Case và Đặc tả Use case cho bài toán
nghiệp vụ trên
Trần Thị Kim Chi 175
CÂU HỎI VÀ BÀI TẬP
• Vẽ lược đồ Use Case và Đặc tả Use case cho bài toán
nghiệp vụ trên
Trần Thị Kim Chi 176
CÂU HỎI VÀ BÀI TẬP
• Vẽ lược đồ Use Case và Đặc tả Use case cho bài toán
nghiệp vụ trên
Trần Thị Kim Chi 177
CÂU HỎI VÀ BÀI TẬP
• Vẽ lược đồ Use Case và Đặc tả Use case cho bài toán
nghiệp vụ trên
Lap BC
Trần Thị Kim Chi 178
CÂU HỎI VÀ BÀI TẬP
• Vẽ lược đồ Use Case và Đặc tả Use case cho bài toán
nghiệp vụ trên
Trần Thị Kim Chi 179
CÂU HỎI VÀ BÀI TẬP
• Vẽ lược đồ Use Case và Đặc tả Use case cho bài toán
nghiệp vụ trên
Trần Thị Kim Chi 180
CÂU HỎI VÀ BÀI TẬP
• Vẽ lược đồ Use Case và Đặc tả Use case cho bài toán
nghiệp vụ trên
Trần Thị Kim Chi 181
182
Trần Thị Kim Chi
