Bài giảng Thiết kế hệ thống thông tin: Chương 6 - Trần Thị Kim Chi

Bài giảng Thiết kế hệ thống thông tin - Chương 6: Domain model - Lược đồ lớp & đối tượng của hệ thống giới thiệu các khái niệm về lược đồ lớp, mô hình lớp miền (Domain Model), 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. Mời các bạn cùng tham khảo nội dung chi tiết.

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)

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:

1 Domain Model: iterative ‘traditional’ approach:

dụng và quan hệ ràng buộc giữa chúng

2 Use-case analysis: Use case driven approach

use case

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

+ cancel() + get cost() + delete() + submit() + save() + any conflicts?() + create with offerings() + update with new selections()

+ 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

+ takeSabbatical() + teachClass()

: Professor

Named Object

Anonymous Object

Object

ĐỐI TƯỢNG - OBJECT

Đối tượng (Object):

tượng(object) sinh sống và tương tác với nhau

ĐỐ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 ý:

hệ thống

ĐỐ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

Professor name

ProfessorId : UniqueId

create() save() delete() change()

• Đ i tối tượng cũng được biểu diễn ượng cũng được biểu diễn ng cũng đượng cũng được biểu diễn c bi u di n ểu diễn ễn

b ng các stereotype thông thằng các stereotype thông thường ường ng

g m 2 ph n:ồm 2 phần: ần:

• Tên đ i tối tượng cũng được biểu diễn ượng cũng được biểu diễn ng + tên l p (đớp: ượng cũng được biểu diễn c

g ch chân), giá tr các thu c ạch chân), giá trị các thuộc ị các thuộc ộc tínhtính(tr ng thái c a đ i tạch chân), giá trị các thuộc ủa đối tượng) ối tượng cũng được biểu diễn ượng cũng được biểu diễn ng)

+name() +method1(:double):double +method2():bool

+classMethod()

-x: double -y: double -z: double -n: int

name

PHÂN LOẠI LỚP

Classes

Source Code

Exec

Design Elements

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

• Trong UML được gán stereotype là <<boundary>>

• 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 <<boundary>> <<boundary>> Actor 2

<<control>>

<<entity>> <<entity>>

LỚP GIAO DIỆN -BOUNDARY CLASS

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

LỚP THỰC THỂ - ENTITY CLASS

hệ thống

lâu dài (database,file…)

• Trong UML được gán stereotype là <<entity>>

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

Use Case

Architectural Analysis

Abstractions

LỚP THỰC THỂ - ENTITY CLASS

Cách tìm lớp thực thể

– 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à <<control>>

• 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

ĐỐI TƯỢNG/LỚP ĐIỀU KHIỂN

Cách tìm lớp điều khiển

phát triển thành nhiều hơn 1 lớp

Example: Summary: Analysis Classes

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:

tương tác (Interaction diagrams)

Cách phân phối trách nhiệm cho các lớp

Cách phân phối trách nhiệm cho các lớp

class khác

thêm quan hệ với các class cũ

với các class cần để thực hiện nhiệm vụ

Ví dụ lớp

Example 2

đố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:

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

attributeName : Type = Default

án

thi: integer, float, double, long, char, string, date, time…

hoặc lớp tự định nghĩa

NHẬN DIỆN THUỘC TÍNH

nhóm danh từ liên quan đến đối tượng đang xét

đang xét?

ta có thể tìm được các thuộc tính khác nhau

– 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

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:

trí khác nhau

• 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

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

Trong thời gian đó nó gửi/nhận thông điệp ra sao?

các thuộc tính; các tác vụ thường có visibility là + hoặc #

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á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.

a) General Motors b) Automoible company

c) Student d) Computer Science Student

g) Board Game h) Chess

k) The game of chess between Tom and Jane which started at 2:30pm yesterday

l) The car with serial number DL 2C 7151

BÀI TẬP

Which of the following are variables, and which are objects?

a) Jim Smith, a passenger on flight 101

b) Jim Smith’s address

c) The reference to the object representing

Jim Smith

Link - kết nối giữa các đối tượng

• Là một thể hiện của một association giữa các lớp.

chúng sẽ có mối kết hợp

• Kết nối nhằm tạo dễ dàng cho việc truyền message

• Mối liên hệ ngữ nghĩa giữa hai hay nhiều lớp chỉ ra sự liên kết giữa các thể hiện của chúng

có kết nối với các đối tượng của lớp khác

LIÊN HỆ (ASSOCIATION)

• Mối liên hệ ngữ nghĩa giữa các thể hiện (instances) của các class

LIÊN HỆ (ASSOCIATION)

LIÊN HỆ (ASSOCIATION)

Vai trò trong liên hệ:

• Các vai trò được nối với mỗi lớp bao chứa trong quan hệ Vai trò của một lớp là chức năng mà nó đảm nhận nhìn từ góc nhìn của lớp kia Tên vai trò được viết kèm với một mũi tên chỉ từ hướng lớp chủ nhân ra, thể hiện lớp này đóng vai trò như thế nào đối với lớp mà mũi tên chỉ đến

Vai trò trong liên hệ giữa Customer và Account

LIÊN HỆ (ASSOCIATION)

Vai trò trong liên hệ:

• “Nhân vật” mà một class”đóng vai trong association

LIÊN HỆ (ASSOCIATION)

Multiplicity –Bản số trong liên hệ:

MỘT thể hiện của lớp khác

LIÊN HỆ (ASSOCIATION)

2 4 0 1 1 *

0 * 1

*

2, 4 6

UnspecifiedExactly OneZero or More

Zero or One (optional scalar role)

One or More

Specified RangeMultiple, Disjoint Ranges

Zero or More

LIÊN HỆ (ASSOCIATION)

• Bi-directional:

• Liên hệ một chiều (Uni-Directional Association):

relationship exists

LIÊN HỆ (ASSOCIATION)

2-way navigation

0 4 0 2

LIÊN HỆ (ASSOCIATION)

Một sơ đồ lớp tiêu biểu

• Aggregation là một dạng đặc biệt của association dùng

để mô hình mối quan hệ whole-part

• Là mối quan hệ “Is a part-of”.

• Ký hiệu:

• Có 2 dạng:

QUAN HỆ BAO GỘP (Aggregation)

• Aggregation là một dạng đặc biệt của liên kết mô hình hóa mối quan hệ toàn thể-bộ phận (whole-part) giữa đối tượng toàn thể và các bộ phận của nó

• Kết tập là mối quan hệ “là một phần” (“is a part-of”)

• Bản số quan hệ được biểu diễn giống như các liên

kết khác

QUAN HỆ BAO GỘP (Aggregation)

Whole/aggregate part

0 4 0 2 primaryCourses

QUAN HỆ BAO GỘP (Aggregation)

Khi nghi ngờ, sử dụng association

• Nếu hai đối tượng đang bị ràng buộc chặt chẽ bởi một mối quan hệ toàn phầnThe relationship is an aggregation

• Nếu hai đối tượng thường được coi là độc lập, mặc dù chúng thường được liên kếtThe relationship is an

association

0 2,4 1

0 2,4 1

QUAN HỆ BAO GỘP (Aggregation)

Bốn ngữ nghĩa có thể của Aggregation

• Sở hữu độc quyền (Exclusive Owns): Book has Chapter

– Có sự phụ thuộc tồn tại (không có chapter nếu không có book)

– Không chia sẻ

– Là thuộc tính cố định (một chapter không thể chuyển sang book khác)

• Sở hữu (Owns): Car has Tire

– Không chia sẻ

– Không là thuộc tính cố định (có thể chuyển tire sang một car khác)

• Có (Has): Department has Student

– Không có sự phụ thuộc tồn tại, có thể chia sẻ.

• Thành viên (Member): Meeting has Chairperson

– Không có đặc trưng gì đặc biệt ngoại trừ là tư cách thành viên

• Một dạng của kết tập với quyền sở hữu mạnh và các

vòng đời trùng khớp giữa hai lớp

• Whole sở hữu Part, tạo và hủy Part

• Part bị bỏ đi khi Whole bị bỏ, Part không thể tồn tại

nếu Whole không tồn tại

QUAN HỆ CẤU THÀNH (Composition)

QUAN HỆ BAO GỘP (Aggregation)

• Aggregation cơ bản là bất kỳ quan hệ whole–part

– Tương ứng với ngữ nghĩa "Has" và "Member"

đối tượng bao gồm (whole)

• Composition là Aggregation mạnh hơn

thuộc chỉ một đối tượng bao gồm (whole).

– Có sự phụ thuộc tồn tại từ "part" vào "whole"

– Khi đối tượng "whole" bị hủy thì các "part" cũng bị hủy

QUAN HỆ BAO GỘP (Aggregation)

Quan hệ m*n có 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

(Chancellor) không 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

Association Class

ScheduleOfferingInfo status

// mark as selected() // mark as cancelled() // is selected?()

<<entity>>

CourseOffering

<<entity>> Schedule

<<entity>>

0 *

0 4 primaryCourses

alternateCourses 0 * 0 2

PrimaryScheduleOfferingInfob grade

// is enrolled in?() // mark as enrolled in() // mark as committed()

<<entity>>

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

độ trừu tượng hóa trong đó

lớp con kế thừa từ một hoặc

(“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

Generalizatio

n Relationship