Bài giảng Phân tích và thiết kế hệ thống - Chương 6: Domain model lược đồ lớp và đối tượng của hệ thống

TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP TP.HCM 
KHOA CÔNG NGHỆ THÔNG TIN 
DOMAIN MODEL 
LƯỢC ĐỒ LỚP & 
ĐỐI TƯỢNG CỦA HỆ THỐNG 
Chương V 
NỘI DUNG 
Các khái niệm về lược đồ lớp 
Mô hình lớp miền (Domain Model) 
Nhận diện lớp 
Nhận diện quan hệ Association, aggregation, generalization 
Xây dựng lược đồ lớp bằng cách hiện thực use case 
Thiết lập các package 
Tổng quan về phân tích Use Case 
Supplementary 
Specifications 
Glossary 
Use-Case 
Analysis 
Project Specific 
 Guidelines 
Use-Case Realization 
Analysis Model 
Use-Case Model 
Analysis Classes 
Software 
Architecture 
Document 
Khái niệm mô hình tĩnh 
Mô hình đối tượng định nghĩa hệ thống theo khái niệm các thành phần tĩnh. Mô hình đối tượng miêu tả ứng xử mang tính cấu trúc và chức năng của các lớp. 
Tiếp cận xây dựng lược đồ lớp phân tích 
Hai tiếp cận chính để xây dựng lược đồ lớp: 
Domain Model: iterative ‘traditional’ approach: 
Xây dựng lược đồ lớp từ tri thức về miền ứng dụng 
Mô hình các khái niệm, sự vật quan trọng trong miền ứng dụng và quan hệ ràng buộc giữa chúng 
Use-case analysis: Use case driven approach 
Identify boundary, control, entity classes needed for each use case 
Consolidate into analysis model for application as a whole 
Domain Model (Mô hình miền) 
Phân hoạch và mô tả các sự vật và các khái niệm quan trọng trong miền ứng dụng. 
Hoạt động phân tích hướng đối tượng cổ điển. 
Mô hình lớp phân tích độc lập với các use case cụ thể 
Không biểu diễn các đối tượng phần mềm mà là tự điển trực quan về các khái niệm quan trọng của miền. 
UML Class Diagram 
7 
Là mô hình chính để phân tích yêu cầu 
CloseRegistrationForm 
+ open() 
+ close registration() 
Student 
+ get tuition() 
+ add schedule() 
+ get schedule() 
+ delete schedule() 
+ has pre-requisites() 
Schedule 
- semester 
+ commit() 
+ select alternate() 
+ remove offering() 
+ level() 
+ cancel() 
+ get cost() 
+ delete() 
+ submit() 
+ save() 
+ any conflicts?() 
+ create with offerings() 
+ update with new selections() 
Professor 
- name 
- employeeID : UniqueId 
- hireDate 
- status 
- discipline 
- maxLoad 
+ submitFinalGrade() 
+ acceptCourseOffering() 
+ setMaxLoad() 
+ takeSabbatical() 
+ teachClass() 
CloseRegistrationController 
+ is registration open?() 
+ close registration() 
Class Diagram Usage 
When modeling the static view of a system, class diagrams are typically used in one of three ways, to model: 
The vocabulary of a system 
Collaborations 
A logical database schema 
Representing Classes and Objects in the UML 
Professor 
- name 
- employeeID : UniqueId 
- hireDate 
- status 
- discipline 
- maxLoad 
+ submitFinalGrade() 
+ acceptCourseOffering() 
+ setMaxLoad() 
+ takeSabbatical() 
+ teachClass() 
class name 
attributes 
operations 
Class 
J Clark : 
Professor 
 : Professor 
Named Object 
Anonymous Object 
Object 
ĐỐI TƯỢNG - OBJECT 
Đối tượng (Object ) : 
Mô hình đối tượng quan niệm thế giới bao gồm các đối tượng(object) sinh sống và tương tác với nhau. 
Đối tượng bao gồm: 
Dữ liệu: mang một giá trị nhất định 
Tác vụ: thực hiện một công việc nào đó 
VD: 
ĐỐI TƯỢNG - OBJECT 
Margaret: 
date of birth: 1980/03/03 
position: Teller 
Transaction 487: 
amount: 200.00 
time: 2001/09/01 14:30 
Greg: 
date of birth: 1970/01/01 
address: 75 Object Dr. 
Mortgage Account 29865: 
balance: 198760.00 
opened: 2000/08/12 
property: 75 Object Dr. 
Instant Teller 876: 
location: Java Valley Cafe 
Savings Account 12876: 
balance: 1976.32 
opened: 1997/03/03 
Jane: 
date of birth: 1955/02/02 
position: Manager 
address: 99 UML St. 
address: 150 C++ Rd. 
ĐỐI TƯỢNG - OBJECT 
Dựa vào đặc tả của từng use case để tìm kiếm các đối tượng 
Các đối tượng thường xuất hiện trong các danh từ hay nhóm danh từ 
Một số lưu ý: 
Đối tượng/lớp phải thật sự cần thiết cho sự hoạt động của hệ thống 
Đối tượng/lớp tương ứng với bảng cơ sở dữ liệu 
Đối tượng/lớp tương ứng với actor. 
ĐỐI TƯỢNG - OBJECT 
Phân loại đối tượng/lớp: 
Đối tượng thực thể(entity): biểu diễn các thông tin cần thiết của hệ thống, có thể được lưu trong cơ sở dữ liệu 
Đối tượng biên (boundary): thực hiện chức năng giao tiếp với actor 
Đối tượng điều khiển (control): điều khiển các đối tượng khác. 
LỚP - CLASS 
Lớp là sự mô tả những thuộc tính và những hành vi của một hay nhiều đối tượng trong hệ thống của bạn. Một đối tượng là một thể hiện của một lớp . 
Person 
name 
age 
weight 
(Person) 
(Person) 
Joe Smith 
age=39 
weight=158 
Mary Wilson 
age=27 
weight=121 
LỚP - CLASS 
Describes a group of objects with common: 
Properties (attributes) 
Behavior (operations) 
Relationships 
Semantics 
Class Name 
Attributes 
Operations 
Professor 
name 
ProfessorId : UniqueId 
create() 
save() 
delete() 
change() 
CẤU TRÚC LỚP - CLASS 
Biểu diễn lớp trong UML: 
Tên> 
 Thuộc tính 
Tác vụ 
Stereotype cho lớp: 
> 
> 
> 
Đối tượng cũng được biểu diễn bằng các stereotype thông thường gồm 2 phần: 
Tên đối tượng + tên lớp (được gạch chân), giá trị các thuộc tính(trạng thái của đối tượng) 
VÍ DỤ LỚP - CLASS 
Biểu diễn lớp trong UML: 
Class name 
Data members 
(attributes) 
Instance methods 
Arguments 
Return types 
Class method (static) 
PHÂN LOẠI LỚP 
Lớp biên (bourndary class) 
Lớp thực thể (entity class) 
Lớp điều khiển (control class) 
PHÂN LOẠI LỚP 
Use Cases 
AnalysisClasses 
Source 
Code 
Exec 
DesignElements 
Use-Case Analysis 
PHÂN TÍCH LỚP – ANALYSIS CLASS 
Tìm kiếm các lớp từ Use case behavior: toàn bộ hành vi của Use case phải được phân bổ về cho các analysis class 
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) 
Khó nhận biết các thuộc tính và tác vụ trong mô hình 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 
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 
Trong UML được gán stereotype là > 
Một boundary class cho 1 cặp actor/use case 
LỚP GIAO DIỆN -BOUNDARY CLASS 
Lưu trữ và quản trị các thông tin trong system 
Actor 1 
Actor 2 
> 
> 
> 
> 
> 
LỚP GIAO DIỆN -BOUNDARY CLASS 
Example: Finding Boundary Classes 
LỚP GIAO DIỆN -BOUNDARY CLASS 
Các User Interface Class 
Tập trung vào những thông tin gì được thể hiện cho người dùng 
Không tập trung vào các chi tiết UI 
Các System và Device Interface Class 
Tập trung vào những protocol nào phải định nghĩa 
Không tập trung vào cách mà các protocol sẽ được cài đặt 
Tập trung vào các nhiệm vụ, chứ không phải chi tiết! 
LỚP THỰC THỂ - ENTITY CLASS 
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à > 
Dễ nhận diện các thuộc tính của chúng 
Ví dụ: đối với hệ thống quản lý thư viện đã mô tả ở phần 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ư. 
Là sự trừu tượng hóa chính của hệ thống 
Glossary 
Business-Domain 
Model 
Environment independent. 
Analysis class stereotype 
Use Case 
Architectural Analysis Abstractions 
LỚP THỰC THỂ - ENTITY CLASS 
Vai trò lớp thực thể 
Store and manage information in the system. 
Actor 1 
> 
> 
> 
> 
> 
Actor 2 
LỚP THỰC THỂ - ENTITY CLASS 
Cách tìm lớp thực thể 
Dựa vào các dòng sự kiện của use case 
Phương pháp lọc danh từ 
Gạch dưới các mệnh đề danh từ 
Loại bỏ các danh từ dư thừa 
Loại bỏ các danh từ mơ hồ 
Loại bỏ actor (ngoài phạm vi) 
Loại bỏ các kiến trúc cài đặt 
Loại bỏ thuộc tính 
Loại bỏ phương thức operation 
LỚP THỰC THỂ - ENTITY CLASS 
Register for Courses (Create Schedule) 
Student 
Schedule 
CourseOffering 
LỚP THỰC THỂ - ENTITY CLASS 
Register for Courses (Create Schedule) 
LỚP THỰC THỂ - ENTITY CLASS 
LỚP ĐIỀU KHIỂN – CONTROL CLASS 
Có nhiệm vụ điều khiển các lớp khác 
Trong UML, được gán stereotype là > 
Lớp biên thường có quan hệ liên kết hoặc phụ thuộc với các lớp 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 
VAI TRÒ LỚP ĐIỀU KHIỂN 
Coordinate the use-case behavior. 
Actor 1 
> 
> 
> 
> 
> 
Actor 2 
ĐỐI TƯỢNG/LỚP ĐIỀU KHIỂN 
Cách tìm lớp điều khiển 
Nguyên tắc chung: cần 1 lớp điều khiển cho mỗi use case. 
Khi tiêp tục phân tích, lớp điều khiển của use case phức có thể phát triển thành nhiều hơn 1 lớp 
Example: Summary: Analysis Classes 
Student 
Course Catalog 
System 
Register for Courses 
Use-Case Model 
Design Model 
RegisterForCoursesForm 
CourseCatalogSystem 
Student 
Schedule 
CourseOffering 
RegistrationController 
Example: Summary: Analysis Classes 
Phân phối hành vi use case vào các lớp 
Đối với dòng sự kiện của mỗi use case: 
Xác định các lớp phân tích 
Phân phối hành vi của use case vào các lớp phân tích 
Mô hình hóa sự tương tác của các lớp phân tích trong lược đồ tương tác (Interaction diagrams) 
Cách phân phối trách nhiệm cho các lớp 
Với lớp Boundary 
Các hành vi liên quan đến giao tiếp với actor 
Với lớp Entity 
Các hành vi liên quan đến dữ liệu 
Với lớp Control 
Các hành vi xác định use case hay một phần dòng sự kiện quan trọng 
Cách phân phối trách nhiệm cho các lớp 
Ai có dữ liệu cần cho việc thực hiện nhiệm vụ? 
Một class có dữ liệu, hãy để nhiệm vụ cùng với dữ liệu 
Nhiều class có dữ liệu : 
Hãy để nhiệm vụ trong 1 class và thêm quan hệ với các class khác. 
Tạo một class mới, để nhiệm vụ trong class mới này, và thêm quan hệ với các class cũ 
Hãy để nhiệm vụ trong control class, và thêm quan hệ với các class cần để thực hiện nhiệm vụ 
Ví dụ lớp 
Example 1 
Ví dụ về các lớp trong doanh nghiệp và các hệ thống thông tin: 
 Khách hàng 
 Bản hợp đồng 
 Hóa đơn 
 Món nợ 
 Tài sản 
 Bản công bố giá cổ phiếu 
Ví dụ lớp 
Example 2 
Các lớp trong một hệ thống kỹ thuật thường bao gồm các đối tượng kỹ thuật, ví dụ như máy móc được sử dụng trong hệ thống: 
 Sensor 
 Màn hình 
 I/O card 
 Động cơ 
 Nút bấm 
 Lớp điều khiển 
Ví dụ lớp 
Example 3 
Các hệ thống phần mềm thường có các lớp đại diện cho các thực thể phần mềm trong một hệ điều hành: 
 File 
 Chương trình chạy được 
 Trang thiết bị 
 Icon 
 Cửa sổ 
 Thanh kéo 
THUỘC TÍNH CỦA LỚP 
Thuộc tính: mô tả cấu trúc của 1 lớp, là một vùng có thể chứa dữ liệu (đơn hoặc tổ hợp) của lớp 
Dữ liệu mà thuộc tính thể hiện nằm trong một khoảng giá trị nào đó được xác định bởi kiểu dữ liệu. 
Thuộc tính có thể bị che dấu hoặc truy xuất được từ bên ngoài: public, protected, private 
THUỘC TÍNH CỦA LỚP 
Biểu diễn thuộc tính 
Chỉ ra tên, kiểu và giá trị mặc định nếu có 
	 	 attributeName : Type = Default 
Tuân theo quy ước đặt tên của ngôn ngữ cài đặt và của dự án. 
Kiểu (type) nên là kiểu dữ liệu cơ bản trong ngôn ngữ thực thi : integer, float, double, long, char, string, date, time 
Kiểu dữ liệu có sẵn, kiểu dữ liệu người dùng định nghĩa, hoặc lớp tự định nghĩa. 
UML cho phép định nghĩa tất cả kiểu dữ liệu trên. 
NHẬN DIỆN THUỘC TÍNH 
Dựa vào đặc tả của từng use case, tìm kiếm các danh từ hoặc nhóm danh từ liên quan đến đối tượng đang xét 
Trả lời câu hỏi: những thành phần nào cấu thành đối tượng đang xét? 
Lưu ý: cùng một đối tượng trong các ngữ cảnh khác nhau chúng ta có thể tìm được các thuộc tính khác nhau. 
Nên xác định (không bắt buộc) trong mô hình phân tích: 
Kiểu của thuộc tính: một số kiểu cơ bản 
Bậc của thuộc tính: số ít hoặc số nhiều 
Visibility của thuộc tính: mức độ cho phép truy xuất thuộc tính từ bên ngoài 
Trường hợp thuộc tính được miêu tả thông qua quan hệ với các lớp khác: UML cho phép thể hiện bậc trên quan hệ (ví dụ: 1,0,*,2..9,0..n) 
MỨC ĐỘ TRUY XUẤT THUỘC TÍNH 
Có 3 mức độ truy xuất thuộc tính: 
Public (+): có thể truy xuất thuộc tính từ tất cả các vị trí khác nhau 
Protected (#): bản thân lớp đang xét 
Private(-) : chỉ có lớp đang xét có thể truy xuất 
Thông thưong nên đặt mức độ truy xuất thuộc tính là private hoặc protected(cho các lớp cơ sở), không nên là public. Thuộc tính nên được truy xuất thông qua tác vụ get,set. 
MỨC ĐỘ TRUY XUẤT THUỘC TÍNH 
Các thuộc tính 
tiêu biểu 
Các thuộc tính 
 chung (+) và riêng (-) 
Các thuộc tính 
chung và riêng 
Các thuộc tính với gía trị mặc nhiên và thuộc tính phạm vi lớp 
Một thuộc tính với liệt kê gía trị (status) 
NHẬN DIỆN TÁC VỤ (OPERATION) 
Ứng xử chung chia sẻ cho tất cả các đối tượng của lớp 
Dịch vụ mà các đối tượng có thể cung cấp cho đối tượng khác 
Hành động mà một đối tượng có thể thực hiện: 
Đọc hay ghi các giá trị thuộc tính 
Thực hiện các tính toán 
Gởi messages tới đối tượng khác 
Tạo hoặc hủy các liên kết với đối tượng khác 
Student 
+ get tuition() 
+ add schedule() 
+ get schedule() 
+ delete schedule() 
+ has prerequisites() 
NHẬN DIỆN TÁC VỤ (OPERATION) 
Tác vụ (operation ) Là một dịch vụ có thể yêu cầu từ phía đối tượng để thực hiện hành vi 
Dấu hiệu nhận dạng của tác vụ (signature) xác định các thông số truyền cũng như kết quả trả về. 
Phương thức (method) là phần hiện thực của tác vụ 
Tác vụ có thể bị che dấu hoặc truy xuất từ bên ngoài 
Tác vụ có thể được override trong các lớp con thừa kế 
Trừu tượng(abstract): không có hiện thực 
Một số ngôn ngữ lập trình cho phép định nghĩa: 
Tác vụ khởi tạo(constructor) 
Tác vụ hủy (destructor) 
NHẬN DIỆN TÁC VỤ (OPERATION) 
Operations 
compartment 
Các giá trị mặc nhiên của tham số 
Dựa vào đặc tả của từng use case, tìm kiếm các động từ hoặc nhóm động từ liên quan đến đối tượng đang xét 
Chú ý xem đối tượng được tạo ra và hủy bỏ như thế nào? Trong thời gian đó nó gửi/nhận thông điệp ra sao? 
Các đối tượng biên có các tác vụ nhận lệnh từ actor 
Xem xét mức độ truy xuất của các tác vụ tương tự như đối với các thuộc tính; các tác vụ thường có visibility là + hoặc # 
Một số tác vụ không xuất hiện một cách tự nhiên trong mô hình phân tích mô hình thiết kế sẽ nghiên cứu trách nhiệm và hành vi của từng đối tượng 
NHẬN DIỆN TÁC VỤ (OPERATION) 
Khi thiết kế operation signatures phải bảo đảm hàm chứa: 
Các tham số truyền theo giá trị hay tham số? 
Các tham số có bị thay đổi bởi operation? 
Các tham số là optional? 
Các tham số có giá trị mặc định? 
Miền tham số hợp lệ? 
Càng ít tham số càng tốt 
Truyền các object thay vì “data bits ” 
Những gì cần xem xét: 
Các thuật toán đặc biệt 
Các object và các operation khác cần sử dụng 
Cách cài đặt và cách sử dụng các attribute và các tham số 
Cách cài đặt và sử dụng các mỗi quan hệ 
Thiết kế Operation Signatures 
BÀI TẬP 
Which of the following items do you think should be a class, and which should be an instance? For any item which should be an instance, name a suitable class for it. 
General Motors	b) Automoible company 
Student	d) Computer Science Student 
Mary Smith	f) Game 
Board Game	h) Chess 
Car	j) Mazda car 
The game of chess between Tom and Jane which started at 2:30pm yesterday 
The car with serial number DL 2C 7151 
BÀI TẬP 
Identify the attributes tha ... ó thể chấp nhận 
Quan hệ m*n không được phép 
Các Student có thể trong nhiều CourseOffering. 
Nếu CourseOffering bị hủy, các Student không bị hủy! 
Nếu Book bị xóa, các chương (Chapter) trong Book cũng bị xóa! 
Aggregation – University and Chancellor 
Nếu không có trường Đại học ( University) , hiệu trưởng ( Chancellor) không thể tồn tại. 
Nếu không có Chancellor , University vẫn có thể tồn tại 
Composition – University and Faculty 
University không thể tồn tại nếu không có các giảng viên ( Faculty) và ngược lại (share time-life) 
Thời gian sống của University gắn chặt với thời gian sống của Faculty 
Nếu Faculties được giải phóng thì University không thể tồn tại và ngược lại 
Ví dụ – Aggregration vs. Composition 
Một class “được gắn” vào một association 
Chứa các thuộc tính của relationship 
Một thể hiện / 1 link 
Association Class 
ScheduleOfferingInfo 
status 
// mark as selected() 
// mark as cancelled() 
// is selected?() 
> 
CourseOffering 
> 
Schedule 
> 
0..* 
0..4 
primaryCourses 
alternateCourses 
0..* 
0..2 
PrimaryScheduleOfferingInfob 
grade 
// is enrolled in?() 
// mark as enrolled in() 
// mark as committed() 
> 
Mối quan hệ giữa các lớp ( relationship) 
Liên kết (Association) 
 Sử dụng (use-a) 
Kết tập (Aggregation) 
Strong association 
has-a/is-a-part 
Hợp thành (Composition) 
Strong aggregation 
Share life-time 
Mối quan hệ giữa các lớp ( relationship) 
Mối quan hệ giữa các lớp ( relationship) 
Mối quan hệ giữa các lớp trong đó một lớp chia sẻ cấu trúc và/hoặc hành vi với một hoặc nhiều lớp khác 
Xác định sự phân cấp về mức độ trừu tượng hóa trong đó lớp con kế thừa từ một hoặc nhiều lớp cha 
Đơn kế thừa (Single inheritance) 
Đa kế thừa (Multiple inheritance) 
Là mối liên hệ “là một loại” (“is a kind of”) 
TỔNG QUÁT HÓA (GENERALIZATION) 
Subtype – Sub class 
Account 
balance 
name 
number 
Withdraw() 
CreateStatement() 
Checking 
Withdraw() 
Savings 
GetInterest() 
Withdraw() 
Superclass (parent) 
Subclasses 
Generalization Relationship 
TỔNG QUÁT HÓA (GENERALIZATION) 
Savings 
Checking 
Stock 
Bond 
RealEstate 
Asset 
RealEstate 
Savings 
BankAccount 
Checking 
Stock 
Security 
Bond 
Tổng quát hơn 
Dặn lớp cô Hương đi thi giữa kỳ lúc 12 g30 cả lớp luôn 
TỔNG QUÁT HÓA (GENERALIZATION) 
Asset 
Asset 
RealEstate 
Savings 
BankAccount 
Checking 
Stock 
Security 
Bond 
Chuyên biệt hơn 
TỔNG QUÁT HÓA (GENERALIZATION) 
Student 
name 
address 
FulltimeStudent 
studentID 
gradDate 
ParttimeStudent 
maxNumCourses 
Part-timeStudent 
name 
address 
numberCourses 
Full-timeStudent 
name 
address 
studentID 
gradDate 
Không có sự tổng quát hóa 
Có sự tổng quát hóa 
studentID 
TỔNG QUÁT HÓA (GENERALIZATION) 
Subtype – Sub class 
Mục đích 
Xác định các khả năng dùng lại 
Tinh chỉnh cây kế thừa để có thể dễ dàng cài đặt 
Những gì cần xem xét: 
So sánh Abstract classes (không có thể hiện) với concrete classes (bất kỳ thể hiện nào) 
Bài toán đa kế thừa 
So sánh Generalization và Aggregation 
Tổng quát hóa để hỗ trợ tái sử dụng trong cài đặt 
Tổng quát hóa để hỗ trợ đa xạ (polymorphism) 
Tổng quát hóa để hỗ trợ đa hình (metamorphosis) 
Mô phỏng tổng quát hóa 
TỔNG QUÁT HÓA (GENERALIZATION) 
TỔNG QUÁT HÓA (GENERALIZATION) 
Lớp trừu tượng và lớp cụ thể  ( Abstract and Concrete Class ) 
Lớp trừu tượng không thể có đối tượng 
▫ Chứa phương thức trừu tượng 
▫ Chữ nghiêng 
• Lớp cụ thể có thể có đối tượng 
Polymorphism là gì? 
Khả năng che giấu các thực thi khác nhau dưới một giao diện duy nhất. 
Polymorphism là gì? 
Là một sự liên quan ngữ nghĩa giữa hai phần tử mô hình, một mang tính độc lập và một mang tính phụ thuộc. Mọi sự thay đổi trong phần tử độc lập sẽ ảnh hưởng đến phần tử phụ thuộc. Phần tử mô hình ở đây có thể là một lớp, một gói (package), một trường hợp sử dụng, .v.v... 
Quan hệ Dependency – Phụ thuộc 
Supplier 
Client 
Mối quan hệ giữa các lớp ( relationship) 
Mối quan hệ giữa các lớp ( relationship) 
Domain Modeling 
Phát hiện lớp miền 
Biểu đồ lớp chỉ ra sự tồn tại của các lớp và mối quan hệ giữa chúng trong bản thiết kế logic của một hệ thống 
Chỉ ra cấu trúc tĩnh của mô hình như lớp, cấu trúc bên trong của chúng và mối quan hệ với các lớp khác. 
Chỉ ra tất cả hoặc một phần cấu trúc lớp của một hệ thống. 
Không đưa ra các thông tin tạm thời. 
Khung nhìn tĩnh của một hệ thống chủ yếu hỗ trợ các yêu cầu chức năng của hệ thống. 
BIỂU ĐỒ LỚP 
BIỂU ĐỒ LỚP 
BIỂU ĐỒ LỚP 
Biểu diễn cấu trúc của một số lớp và quan hệ giữa 
	chúng Mô tả khía cạnh tĩnh của hệ thống. 
Hệ thống phức tạp có nhiều lớp cần xây dựng nhiều lược đồ lớp, mỗi lược đồ mô tả một phần của hệ thống 
Lược đồ lớp được bổ sung và hoàn thiện trong mô hình thiết kế (thêm một số lớp, chi tiết thuộc tính tác vụ, làm rõ các quan hệ) 
XÂY DỰNG BIỂU ĐỒ LỚP 
Từ các danh từ trong phát biểu bài toán 
T ài liệu yêu cầu phải đầy đủ và đúng. 
Là một phát biểu có mục đích 
Miêu tả cho một tập các đối tượng (nhiều hơn 1) 
Không xét các lớp chỉ có một thể hiện (Singleton) 
Sở hữu một tập các thuộc tính 
Thuộc tính định danh: chỉ xem xét nếu có ý nghĩa thực tế. 
Sở hữu một tập các phép toán 
Phép toán có thể nhận diện sau 
Phát hiện lớp miền (Key Abstraction) 
Nó có nằm ngoài phạm vi của hệ thống không? 
Nó có ám chỉ tới toàn bộ hệ thống không? 
Nó có lập lại một lớp khác không? 
Nó có quá mơ hồ không? 
Nó có buộc quá chặt với inputs và outputs vật lý không? 
Nó có là một thuộc tính hay không? 
Nó có là một mối kết hợp hay không? 
Nếu câu trả lời là "Yes", 
Mô hình lớp theo một cách khác hoặc loại bỏ lớp đó 
Kiểm tra tính hợp lý của các lớp ứng viên 
Nhận diện quan hệ 
Từ các động từ biểu diễn các quy định nghiệp vụ (business rules) trong phát biểu bài toán 
Tránh các chu trình trong quan hệ 
có thể có ý nghĩa giống nhau 
Schedule 
Student 
0..* 
1 
CourseOffering 
0..4 
0..* 
primaryCourses 
0..* 
0..* 
register 
Ví dụ: Hệ thống đăng ký học phần 
Course 
- credits 
- name 
- curriculum 
- description 
- number 
0..n 
0..n 
preRequisites 
0..n 
0..n 
Professor 
- professorId 
- name 
CourseOffering 
- number 
- startTime 
- endTime 
- days 
/- numStudents 
Schedule 
- semester 
0..n 
0..2 
0..n 
alternateCourses 
0..2 
Student 
- name 
- address 
- studentID 
0..n 
0..4 
0..n 
primaryCourses 
0..4 
PrimaryScheduleOfferingInfob 
- grade 
0..n 
1 
0..n 
1 
offer 
0..1 
0..n 
instructor 
0..1 
0..n 
teach 
0..n 
1 
0..n 
1 
has 
Bài tập Class Diagram 
“FastData, Inc. employees may order office supplies via the Internal Web and receive a receipt confirming the order . The order must include the user name , user password , account number , and the list of supplies . A receipt must be generated containing an order number , ship date , and total cost . If the order is valid, it must be entered into an order database . If the order is invalid, an error message must be generated.” 
Bài tập Class Diagram 
Out-of-Domain 
Internal Web 
Abstract 
user name 
user password 
account number 
order number 
ship date 
total cost 
list of supplies 
office supplies -> item 
Good Candidates 
employee 
item (was office supplies) 
receipt 
order 
order database 
error message 
Notes 
We have decided not to worry about the Web in this design. Instead we focus on the inputs and outputs and defer the Web details until later. 
Bài tập Class Diagram 
order DB 
employee 
name 
password 
order 
number 
account 
total cost 
receipt 
order number 
ship date 
total cost 
item 
name 
quantity 
price 
error message 
explanation 
Bài tập Class Diagram 
response 
receipt 
order number 
ship date 
total cost 
error message 
explanation 
Since both receipts and error messages will be generated as output 
it might make sense to have them as subclasses of a more general 
class. We do not know enough yet to assign it attributes however. 
Bài tập Class Diagram 
order DB 
employee 
name 
password 
order 
number 
account 
total cost 
receipt 
order number 
ship date 
total cost 
item 
name 
quantity 
price 
1+ 
error message 
explanation 
Bài tập Class Diagram 
Draw a class diagram for an information modeling system for a university. 
University has one or more Departments. 
Department offers one or more Classes. 
A particular class will be offered by only one department. 
Department has instructors and instructors can work for one or more departments. 
Student can enroll in up to 5 classes in a University. 
Instructors can teach up to 3 classes. 
The same class can be taught by different instructors. 
Students can be enrolled in more than one university. 
Bài tập Class Diagram 
University has one or more Departments. 
Department offers one or more Classes. 
A particular class will be offered by only one department. 
University 
Department 
Department 
Class 
 has 
1 
1..* 
 offers 
 offers 
1 
1..* 
Bài tập Class Diagram 
Department has Instructors and instructors can work for one or more departments. 
Student can enroll in up to 5 Classes. 
Instructor 
Department 
assigned to 
1..* 
1..* 
Student 
Class 
 takes 
* 
0..5 
Bài tập Class Diagram 
Instructors can teach up to 3 classes. 
The same class can be taught by different instructors. 
Instructor 
Class 
 teaches 
1..* 
1..3 
Bài tập Class Diagram 
Students can be enrolled in more than one school. 
Student 
University 
 member 
* 
1..* 
Bài tập Class Diagram 
University 
Department 
Student 
Class 
Instructor 
1* 
* 
member 
* 
1..5 
 attends 
1..3 
1..* 
teaches 
1..* 
1 
1 
1..* 
has 
1..* 
1..* 
assignedTo 
offers 
Bài tập Class Diagram 
Mô tả cơ chế phân tích 
Tập hợp tất cả cơ chế phân tích trong danh sách 
Ánh xạ lớp với các cơ chế phân tích 
Xác định các tính chất của cơ chế phân tích 
Ví dụ: Mô tả cơ chế phân tích 
Ví dụ: Mô tả cơ chế phân tích 
Cơ chế Persistency đối với lớp Schedule class: 
Granularity : 1 to 10 Kbytes per product 
Volume : up to 2,000 schedules 
Access frequency 
Create : 500 per day 
Read : 2,000 access per hour 
Update : 1,000 per day 
Delete : 50 per day 
Other characteristics 
Hợp nhất các lớp phân tích 
Mỗi use case khi hiện thực hóa sẽ cho ra 1 lược đồ lớp khác nhau 
Loại bỏ các lớp trùng lặp từ các lược đồ lớp khác nhau 
Đánh giá kết quả 
Register for Courses 
Close Registration 
Student 
Course 
Offering 
Course 
Offering 
Student 
CloseRegistration 
Controller 
Registration 
Controller 
CloseRegistration 
Form 
Course 
Catalog 
System 
Schedule 
Course 
Catalog 
System 
Course 
Offering 
Schedule 
Registration 
Controller 
Student 
 CloseRegistration 
Controller 
Schedule 
Course 
Catalog 
System 
Billing 
System 
RegisterFor 
CoursesForm 
RegisterFor 
CoursesForm 
Billing 
System 
CloseRegistration 
Form 
Đánh giá kết quả 
Câu hỏi 
Các class có hợp lý không? 
Tên của các class có phản ánh đúng vai trò của chúng? 
Class có biểu diễn 1 single well-defined abstraction? 
Tất cả các attribute và responsibility có gắn kết với nhau về mặt chức năng không? 
Class có cung cấp các hành vi được y/c? 
Tất cả các yêu cầu cụ thể đã được thể hiện trên class chưa? 
Câu hỏi 
Tất cả các luồng chính và luồng con đã được điều khiển chưa, bao gồm cả các trường hợp ngoài lệ? 
Đã tìm thấy tất cả các đối tượng cần thiết? 
Đã phân phối một cách rõ ràng tất cả các hành vi về các đối tượng chưa? 
Các hành vi có được phân phối về đúng đối tượng không? 
Các interaction diagrams nằm ở đâu, mối quan hê gwiax chúng có rõ ràng và phù hợp không? 
Câu hỏi 
Mục tiêu của Use-Case Analysis là gì? 
Một analysis class là gì? Cho biết tên và mô tả về 3 analysis stereotype. 
Use-case realization là gì? 
Mô tả một vài hoạt động khảo sát when đặt các trách nhiệm cho các analysis class. 
Bao nhiêu interaction diagram phải được xây dựng trong giai đoạn Use-Case Analysis? 
Câu hỏi 
Hãy cho biết các khái niệm sau: 
Các Requirements artifact, đặc biệt là đặc tả bổ sung 
Các cơ chế phân tích có thể 
Các flow of events interaction diagram cho một use case cụ thể 
Với mỗi use case hãy xác định các dữ kiện sau: 
Các thuộc tính và các mối quan hệ của Analysis class 
Các cơ chế phân tích Analysis class 
Xây dựng các lược đồ sau: 
VOPC class diagram, chứa các analysis class, stereotype của chúng, nhiệm vụ, các attribute, và relationship. 
Ánh xạ Analysis class với các cơ chế phân tích 
Package là một cơ chế để tổ chức các phần tử vào nhóm có quan hệ ngữ nghĩa với nhau 
Package có thể import các phần tử từ một package khác 
Có thể chỉ ra quan hệ giữa các package 
Phụ thuộc 
Tổng quát hóa 
Mức độ truy xuất của package 
Private: chỉ nó và các package import nó có thể truy xuất nội dung 
Protected: giống như các private nhưng cho phép thêm các package dẫn xuất 
Public: các package khác có thể truy xuất nội dung 
Implementation: không cho phép import, có thể áp dụng các phẩn tử bên trong package 
THIẾT LẬP CÁC PACKAGE 
THIẾT LẬP CÁC PACKAGE 
THIẾT LẬP CÁC PACKAGE 
THIẾT LẬP CÁC PACKAGE 
Một số lớp khác xuất hiện làm chức năng duyệt (iterate) một lớp khác hay thực hiện các tính toán phức tạp 
Sử dụng trực tiếp các lớp do thư viện hay ngôn ngữ cung cấp, hoặc tạo ra lớp mới bằng cách thừa kế hay tích hợp lớp có sẵn, ví dụ: 
CArray 
Bổ sung các lớp mới vào lược đồ lớp đồng thời cập nhật các mối quan hệ mới(bao gộp, phụ thuộc) 
NHẬN DIỆN THÊM MỘT SỐ LỚP THIẾT KẾ 
Trong mô hình phân tích cần chỉ rõ kiểu (hoặc cấu trúc dữ liệu) và mức độ truy xuất các thuộc tính 
Có thể chọn một lớp cung cấp bởi thư viện lập trình để cụ thể hóa kiểu hay cấu trúc dữ liệu bổ sung lớp của thư viện và quan hệ bao gộp vào lược đồ lớp. 
ĐẶC TẢ CHI TIẾT CÁC THUỘC TÍNH 
Các lược đồ mô tả hành vi(cộng tác, tuần tự, trạng thái, hành động) giúp nhận diện chính xác các tác vụ của các lớp 
Dựa vào thông điệp hay hành động để xác định signature của các tác vụ 
VD: 
NHÂN DIỆN CHÍNH XÁC CÁC TÁC VỤ 
Cập nhật các lớp mới, thuộc tính, tác vụ và mối quan hệ mới 
UML định nghĩa quan hệ phụ thuộc (dependency) giữa 2 lớp hoặc package: thay đổi ở một lớp, package kéo theo thay đổi ở lớp kia 
Ký hiệu: 
Một số stereotype quy ước trước 
	>, >, >, >, 	>, >, > 
HOÀN CHỈNH LƯỢC ĐỒ LỚP 
VD thêm lược đồ lớp cho hệ thống đăng ký môn học 
HOÀN CHỈNH LƯỢC ĐỒ LỚP 
VD thêm lược đồ lớp cho hệ thống đăng ký môn học 
HOÀN CHỈNH LƯỢC ĐỒ LỚP 
 139 
Review 
1. Hỏi: Khi tạo dựng mô hình, cần sử dụng các khái niệm của chính phạm vi vấn đề để mô hình dễ hiểu và dễ giao tiếp. 
Đáp: Đúng 
2. Hỏi: Các lớp chỉ thể hiện cấu trúc thông tin? 
Đáp: sai, các lớp không phải chỉ thể hiện cấu trúc thông tin mà còn mô tả cả hành vi. 
3. Hỏi: Các khái niệm then chốt thường sẽ trở thành các lớp trong mô hình phân tích? 
Đáp: Đúng 
4. Hỏi: Thường các danh từ trong các lời phát biểu bài toán sẽ là ứng cử viên để chuyển thành lớp và đối tượng? 
Đáp: Đúng 
THANKS YOU