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

ƯỜ

Ạ Ọ

Ệ

NG Đ I H C CÔNG NGHI P TP.HCM Ệ KHOA CÔNG NGH THÔNG TIN

ươ

ng V

DOMAIN MODEL ƯỢ Ồ Ớ C Đ L P & L

Ố ƯỢ

Ệ Ố

Ủ

Đ I T

NG C A H TH NG

Ộ

N I DUNG

ệ

c đ l p

ề ượ ồ ớ • Các khái ni m v l ề • Mô hình l p mi n (Domain Model)

ớ – Nh n di n l p ệ ớ – Nh n di n quan h Association, aggregation, ệ

ậ ậ ệ

ự

ệ

ằ

c đ l p b ng cách hi n th c use case

• Xây d ng l • Thi

ượ ồ ớ ự ế ậ t l p các package

generalization

ổ

ề

T ng quan v phân tích Use Case

Use-Case Realization

Glossary

Project Specific Guidelines

Software Architecture Document

Use-Case Analysis

Supplementary Specifications

Analysis Model

Use-Case Model

Analysis Classes

ệ

Khái ni m mô hình tĩnh

ị

ệ ố

ệ

ng đ nh nghĩa h th ng theo khái ni m các thành ph n tĩnh. Mô hình ứ ả ứ

ử

ủ

ấ

ớ

Mô hình đ i t ố ượ đ 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.

ế ậ

ự

ượ ồ ớ

c đ l p phân

Ti p c n xây d ng l tích

ể

ự

ế ậ

ượ ồ ớ

c đ l p:

Hai ti p c n chính đ xây d ng l 1. Domain Model: iterative ‘traditional’ approach: ụ

– Xây d ng l 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

–

ượ ồ ớ ừ c đ l p t ệ ệ 2. Usecase analysis: Use case driven approach

– Consolidate into analysis model for application as a

Identify boundary, control, entity classes needed for each 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 c

ự ậ ề ứ ng đ i t

đi n.ể

ộ ậ

ớ

• Mô hình l p phân tích đ c l p v i các use

ễ

ầ

ề ng ph n m m mà là

ệ

ề

ọ

ề

ớ case c thụ ể – Không bi u di n các đ i t ể ố ượ ự ự ể t đi n tr c quan v các khái ni m quan tr ng ủ c a mi n.

UML Class Diagram

ể

ầ • Là mô hình chính đ phân tích yêu c u

CloseRegistrationForm

CloseRegistrationController

Schedule

- semester

+ open() + close registration()

+ is registration open?() + close registration()

Professor

Student

- name - employeeID : UniqueId - hireDate - status - discipline - maxLoad

+ commit() + select alternate() + remove offering() + level() + cancel() + get cost() + delete() + submit() + save() + any conflicts?() + create with offerings() + update with new selections()

+ get tuition() + add schedule() + get schedule() + delete schedule() + has pre-requisites()

+ submitFinalGrade() + acceptCourseOffering() + setMaxLoad() + takeSabbatical() + teachClass()

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

class name

J Clark : Professor

attributes

Named Object

- name - employeeID : UniqueId - hireDate - status - discipline - maxLoad

: Professor

operations

Anonymous Object

+ submitFinalGrade() + acceptCourseOffering() + setMaxLoad() + takeSabbatical() + teachClass()

Class Object

Ố ƯỢ

Đ I T

NG OBJECT

ố ượ

ồ ố ng (Object): ố ượ i bao g m các đ i Đ i t • Mô hình đ i t

ố ế ớ ệ ng quan ni m th gi ớ ươ ng tác v i nhau. ng(object) sinh s ng và t

ồ t • Đ i t

ị

• VD:

ữ ệ ụ ấ ị ệ ự ộ ượ ố ượ 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 đó ệ

Ố ƯỢ

Đ I T

NG OBJECT

Jane:

date of birth: 1955/02/02 address: 99 UML St. position: Manager

Savings Account 12876:

Greg:

balance: 1976.32 opened: 1997/03/03

date of birth: 1970/01/01 address: 75 Object Dr.

Margaret:

Mortgage Account 29865:

date of birth: 1980/03/03 address: 150 C++ Rd. position: Teller

balance: 198760.00 opened: 2000/08/12 property: 75 Object Dr.

Transaction 487:

amount: 200.00 time: 2001/09/01 14:30

Instant Teller 876:

location: Java Valley Cafe

Ố ƯỢ

Đ I T

NG OBJECT

ặ ả ủ ừ

ế

ể

• D a vào đ c t

c a t ng use case đ tìm ki m các

ườ

ệ

ấ

ừ

ng xu t hi n trong các danh t

ự ố ượ đ i t ng ố ượ • Các đ i t ng th hay nhóm danh từ

– Đ i t

ộ ố ư • M t s l u ý: ố ượ ớ ủ ệ ố c a h th ng ố ượ ố ượ

ậ ự ầ ả ế ự ạ ộ ng/l p ph i th t s c n thi t cho s ho t đ ng

– Đ i t – Đ i t

ớ ươ ứ ớ ươ ứ ng/l p t ng/l p t ơ ở ữ ệ ớ ả ng ng v i b ng c s d li u ớ ng ng v i actor.

Ố ƯỢ

Đ I T

NG OBJECT

ạ ố ượ

ễ

ớ ng/l p: ể ng th c th (entity):

ệ ầ ể bi u di n các thông tin c n ơ ở ữ ệ ể ượ ư c l u trong c s d li u ứ ự th c hi n ch c năng giao ng biên (boundary):

ớ ti p v i actor

ề ề ố ể đi u khi n các đ i ể ng đi u khi n (control):

• Phân lo i đ i t – Đ i t ố ượ ự ế ủ ệ ố t c a h th ng, có th đ thi – Đ i t ố ượ ế – Đ i t ố ượ ượ t

ng khác.

Ớ

L P CLASS

ả

ự

ữ

ủ

ộ ớ

ộ ữ ớ nh ng thu c tính và nh ng hành vi • L p là s mô t ệ ố ố ượ ề ộ ủ ng trong h th ng c a c a m t hay nhi u đ i t ể ệ ủ ộ ộ ố ượ ạ ng là m t th hi n c a m t l p. b n. M t đ i t

(Person)

Person

Joe Smith age=39 weight=158

name age weight

(Person)

Mary Wilson age=27 weight=121

Ớ

L P CLASS

• Describes a group of objects with common:

– Properties (attributes) – Behavior (operations) – Relationships – Semantics

Class Name

Professor

Attributes

name ProfessorId : UniqueId

Operations

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 ượ ể

ườ ễ c bi u di n ng

ầ ố ượ ớ Stereotype cho l p:ớ - <> - <> - <> ố ượ • Đ i t ng cũng đ ằ b ng các stereotype thông th ồ g m 2 ph n: • Tên đ i t

Tác vụ 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

name

Data members (attributes)

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

Instance methods

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

Class method (static)

Return types

Arguments

Ạ Ớ

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

Exec

Use Cases Analysis Classes

Design Elements

Source Code

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 ổ ề c phân b v cho các

hành vi c a Use case ph i đ 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 i dùng( button, listbox, option

ụ

ộ

• Khó nh n bi

t các thu c tính và tác v trong mô

ệ khi n giao di n ng group, menu…) ế ậ hình phân tích

ư ệ

ả

ố ớ ệ ố ư

• Ví d : ụ đ i v i h th ng qu n lý th vi n, các đ i ố ng biên nh : TheMuonForm, BanDocForm,

ượ t 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

ượ

c gán stereotype là <>

ặ

ộ

• Trong UML đ • M t boundary class cho 1 c p actor/use case

Ớ

Ệ

L P GIAO DI N BOUNDARY CLASS

Actor 1

Actor 2

Lưu trữ và quản trị các thông tin trong system

Ớ

Ệ

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

• Thông tin v các đ i t

ễ ệ ố trong h th ng ề ố ượ ả ượ ư ự ể ể ng th c th có th ph i đ c l u

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

ượ

ậ ễ c gán stereotype là <> ủ ộ

ả ở ầ ph n

ẻ ượ

ả ố ượ

• Trong UML đ ệ • 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 ướ ể ư ự ệ ng th c th nh : tr c, nh n di n các đ i t – Sách, B n đ c, Th m n, Th th . ủ ư ọ

ậ ạ

Ớ

Ự

Ể

L P TH C TH ENTITY CLASS

ự ừ ượ

ủ ệ ố

• Là s tr u t

ng hóa chính c a h th ng

Analysis class stereotype

Use Case

Business-Domain Model

Architectural Analysis Abstractions

Glossary

Environment independent.

Ớ

Ự

Ể

L P TH C TH ENTITY CLASS

ự

ể

ớ • Vai trò l p th c th

Actor 1

Actor 2

Store and manage information in the system.

Ớ

Ự

Ể

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

ừ

i các m nh đ danh t

ể ự ệ ủ ừ ề ừ ư ừ d th a ừ ơ ồ m h ạ

ế

ng th c operation

ự ọ ươ ng pháp l c danh t – G ch d ệ ướ ạ – Lo i b các danh t ạ ỏ – Lo i b các danh t ạ ỏ – 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 ứ ạ ỏ ươ

Ớ

Ự

Ể

L P TH C TH ENTITY CLASS

• Register for Courses (Create Schedule)

CourseOffering

Schedule

Student

Ớ

Ự

Ể

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, đ ườ • L p biên th

thu c v i các l p khác

ộ ớ ề

ứ ạ ẽ

ộ ớ

ề

ầ

ụ ề ượ c gán stereotype là <> ụ ng có quan h liên k t ho c ph ớ ố • 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

Actor 1

Actor 2

Coordinate the usecase behavior.

Ố ƯỢ

Ớ

Ể

Đ 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

UseCase Model

Design Model

CourseCatalogSystem

Student

Schedule

RegisterForCoursesForm

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

• V i l p Entity

• V i l p Control

ế ế ớ

ớ ớ – Các hành vi liên quan đ n giao ti p v i actor ớ ớ – Các hành vi liên quan đ n d li u ế ữ ệ ớ ớ – 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 ?

ộ ữ ệ ệ ệ ệ ụ

ề

• Hãy đ nhi m v trong 1 class và thêm quan h v i

ữ ệ ụ ệ ớ ệ

ự – 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 : ể 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 s

ộ ệ ố ỹ ụ ỹ ng k thu t, ví d nh máy móc đ ệ ố

–

ộ

–

ớ

Sensor Màn hình I/O card ơ Đ ng c Nút b m ấ ể ề L p đi u khi n

các đ i t ụ d ng trong h th ng: –

ụ ớ

Ví d l p

ề

ườ

ệ ố

ể

ầ ự

–

ạ ượ

–

ng trình ch y đ ế ị t b

–

ạ ớ 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 Trang thi Icon ử ổ C a s Thanh kéo

Example 3 • Các h th ng ph n m m th ầ

Ủ Ớ

Ộ

THU C TÍNH C A L P

ộ ộ mô t

ặ ổ ợ ữ ệ ể Thu c tính: ứ th ch a d li u (đ n ho c t ớ ả ấ ủ c u trúc c a 1 l p, là m t vùng có ủ ớ ơ 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. ể ị ộ ấ ấ ượ ừ c t

ặ Thu c tính có th b che d u ho c truy xu t đ bên ngoài: public, protected, private

Ủ Ớ

Ộ

THU C TÍNH C A L P

ễ ể ộ

́ ị ặ ị ̉ ̉ Bi u di n thu c tính • Chi ra tên, kiêu và giá tr m c đ nh nê u có

• Tuân theo quy

attributeName : Type = Default ặ ́ươ ữ ặ ̉ ̉ c đ t tên cua ngôn ng cài đ t và cua

ự d án.

̉ ữ ̣ ơ ̉ ̉

ữ • Kiêu (type) nên là kiêu d liêu c ban trong ngôn ng ự th c thi: integer, float, double, long, char, string, date, time…

̉ ữ ̣ ườ ị i dùng đ nh nghĩa,

ự ị ẵ • Kiêu d liêu có s n, kiêu d liêu ng đ nh nghĩa. ̉ ữ ̣ ́ ặ ơ ho c l p t

• 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

ự ặ ả ủ ừ ừ c a t ng use case, tìm ki m các danh t ặ ho c

• D a vào đ c t ừ nhóm danh t

ế ế ng đang xét

• Tr l

liên quan đ n đ i t ỏ ố ượ ầ ữ ố ượ ấ i câu h i: nh ng thành ph n nào c u thành đ i t ng

ả ờ đang xét?

ư ữ ả ng trong các ng c nh khác nhau

ể ộ 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:

ề

ố

ộ ộ ủ

ấ

ộ

ừ

ộ

bên

ộ ố ượ • L u ý: cùng m t đ i t ượ chúng ta có th tìm đ ắ ị ộ ố ể ơ ả ể ủ – 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

• Tr

ngoài ườ ng h p thu c tính đ ớ

ợ ộ ượ

thông qua quan h v i ụ ệ ớ ệ ậ

ả c miêu t ể ệ 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 c các v t

trí khác nhau

ớ

ứ ộ

ặ

ộ

ặ

ỉ ớ ấ

ụ

ấ

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 đ xu t thông qua tác v get,set.

ả – 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 ớ ơ ở ượ c truy

Ứ Ộ

Ộ

Ấ

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

ộ

ị ặ

ớ ệ

ộ

M t thu c tính v i li

ị t kê gía tr (status)

ộ

ạ

ớ 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

Ụ

Ậ

Ệ

NH N DI N TÁC V (OPERATION)

ấ

ố ượ

ẻ ủ ớ

ng c a l p

Student

ố ượ ể ng có th

ng khác

ử Ứ ng x chung chia s cho t ả c các đ i t ụ ị D ch v mà các đ i t ố ượ ấ cung c p cho đ i t ộ Hành đ ng mà m t đ i t ệ th th c hi n:

ộ

ị

+ get tuition() + add schedule() + get schedule() + delete schedule() + has prerequisites()

ệ

ng khác

ủ

ế ớ ố ượ

ộ ố ượ ng có

ể ự ọ Đ c hay ghi các giá tr thu c tính ự Th c hi n các tính toán ớ ố ượ ở i đ i t G i messages t ặ ạ T o ho c h y các liên k t v i đ i t khác

Ụ

Ậ

Ệ

NH N DI N TÁC V (OPERATION)

ụ ể ầ ộ ị ừ Là m t d ch v có th yêu c u t

ụ ố ượ ệ Tác v (operation) ể ự 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 ặ ụ ấ ừ ể ị ấ

ể ượ ừ ế

bên ngoài c override trong các l p con th a k ệ ụ ừ ượ Tác v có th b che d u ho c truy xu t t ớ Tác v có th đ ự 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:

ở ạ

Tr u t ộ ố ụ ụ ủ Tác v kh i t o(constructor) Tác v h y (destructor)

Ụ

Ậ

Ệ

NH N DI N TÁC V (OPERATION)

ị ặ

ủ

ố Các giá tr m c nhiên c a tham s

Operations compartment

Ụ

Ậ

Ệ

NH N DI N TÁC V (OPERATION)

ộ ế ừ

ế ự ặ ho c nhóm đ ng t ng đang xét

• Chú ý xem đ i t

ặ ả ủ ừ • D a vào đ c t ộ ừ ố ượ ư ế ỏ c t o ra và h y b nh th nào?

liên quan đ n đ i t ượ ạ ng đ ậ ử Trong th i gian đó nó g i/nh n thông đi p ra sao?

c a t ng use case, tìm ki m các đ ng t ố ượ ủ ệ ụ ậ ệ ờ ố ượ

• Các đ i t • Xem xét m c đ truy xu t c a các tác v t

ừ ụ ươ

ng biên có các tác v nh n l nh t ấ ủ ứ ộ ộ ụ ườ actor ư ố ự nh đ i ng t ặ ng có visibility là + ho c

ớ v i các thu c tính; các tác v th #

• M t s tác v không xu t hi n m t cách t

ộ ố ụ ệ ấ ự

ế ẽ ộ nhiên trong mô ứ t k s nghiên c u trách

ế ố ượ ủ ừ ệ hình phân tích  mô hình thi nhi m và hành vi c a t ng đ i t ng

ế ế

Thi

t k Operation Signatures

• 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 ? ố t

ề

ặ

ầ ử ụ

ử ụ

ố

ặ ặ

ệ

ỗ

• Càng ít tham s càng t • Truy n các object thay vì “data bits” ầ • Nh ng gì c n xem xét: ệ ậ t – Các thu t toán đ c bi – 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

ữ

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.

b) Automoible company

d) Computer Science Student

f) Game

h) Chess j) Mazda car

a) General Motors d) Student g) Mary Smith j) Board Game i) Car 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Ậ

Identify the attributes that might be present in the following classes. Try to be reasonably exhaustive. a) Passenger b) Room c) Phone Call

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

Ệ

QUAN H RELATIONSHIP

ớ ồ

ệ ữ

ố

ạ

Quan h gi a các l p g m có b n lo i:

Association Aggregation Composition Generalization Dependency Realization

ế ố ữ

ố ượ

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. ớ ươ ứ ng ng c a

ộ ế – N u 2 đ i t

ể ệ ủ ố ượ ẽ 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

net2_05:CourseOffering

net1_05:CourseOffering

Network Basic:Course

Database:Course

dat_05:CourseOffering

ế ng có liên k t thì các l p t ố ế ợ ạ

Ệ

LIÊN H (ASSOCIATION)

̀ ̃ ́ ́ ơ ̉ ự ữ • Mô i liên hê ng nghi a gi a hai hay nhiê u l p chi ra s

́ ́ ữ ̉ ̣ ̉ liên kê t gi a ca c thê hiên cua chu ng

́ ̣ ̉ ̉

́ ́ ́ ́ ́ ̀ ́ ́ ̣ ữ ́ ̀ ́ ặ ấ • Mô i quan hê vê m t c u tru c chi ra ca c đô i t ́ ơ ́ ̉ ơ ơ l p na y co kê t nô i v i ca c đô i t ́ ượ ng cua ́ ượ ng cua l p kha c.

Ệ

LIÊN H (ASSOCIATION)

has-capital

Country

City

Class diagram

name

(Country)

has-capital

(City)

Canada

Ottawa

(Country)

has-capital

(City)

Object diagram

France

Paris

(Country)

has-capital

(City)

Austria

Vienna

Ệ

LIÊN H (ASSOCIATION)

̃ ể ệ ̣ ữ ủ ữ • Mô i liên hê ng nghi a gi a các th hi n (instances) c a

́ các class

Ệ

LIÊN H (ASSOCIATION)

PerformResponsibility

:Client

:Supplier

Link

Client

Supplier

Communication Diagram

Client

Supplier

Class Diagram

0..*

PerformResponsibility()

Association

Relationship for every link!

Ệ

LIÊN H (ASSOCIATION)

ỗ ớ

ố ớ

Vai trò trong liên h :ệ • Các vai trò đ

ủ

ứ

ượ

ộ

ủ ớ ỉ ừ ướ h ư ế

ứ ượ ệ 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 ớ ế c vi góc nhìn c a l p kia. Tên vai trò đ t kèm v i m t mũi ể ệ ớ ủ ớ ng l p ch nhân ra, th hi n l p này đóng vai tên ch t ỉ ế ố ớ ớ 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)

́ ́ ̣ ơ ̣ ̉ ̣ ̉ ng thê hiên cua môt l p liên quan

́ ượ ́ ̣ ̉ ̣ t

• V i m i liên kê t, co hai b n sô quan hê cho hai đâ u cua liên

̀ ́ Multiplicity –B n sả ố trong liên h :ệ ́ • B n sô quan hê la sô l ̉ ơ ́ ỗ ả ̣ ̉

• Đ nh nghĩa có bao nhiêu đ i t

ặ ị M c đ nh

ề

ố ượ ệ ng tham gia vào quan h

ệ Đi u ki n n < m

̀ ả ́ ơ i MÔT thê hiên cua l p kha c. ́ ́ ơ kê t. ́ ị – 1 – – 0 .. 1 – * – – n .. m –

ố ượ ệ ữ S l ng trong liên h gi a Customer và Account

Ệ

LIÊN H (ASSOCIATION)

Unspecified

Exactly One

Zero or More

0..*

Zero or More

One or More

1..*

Zero or One (optional scalar role)

0..1

Specified Range

2..4

Multiple, Disjoint Ranges

2, 4..6

Ệ

LIÊN H (ASSOCIATION)

Ệ

LIÊN H (ASSOCIATION)

• Bidirectional:

– both classes are aware of each other and their relationship

• Liên h m t chi u (UniDirectional Association):

–

ệ ộ ề

Class1

Class2

Một chiều

two classes are related, but only one class knows that the relationship exists

Ệ

LIÊN H (ASSOCIATION)

<> RegisterForCoursesForm

<> RegistrationController

1-way navigation

0..*

0..4 primaryCourses

<> Schedule

0..2

<> CourseOffering

0..*

alternateCourses

2-way navigation

Ệ

LIÊN H (ASSOCIATION)

ộ ơ ồ ớ

ể

M t s đ l p tiêu bi u

Ệ

LIÊN H (ASSOCIATION)

<> RegisterForCoursesForm

<> RegistrationController

0..1

currentSchedule

0..1

primaryCourses

Student

Schedule

CourseOffering

0..4

0..*

Ộ

Ệ

QUAN H BAO G P (Aggregation)

ặ

• Aggregation la môt d ng đ c biêt cua association

̣ ̉

̣ ạ ́ dùng đ mô hình mô i quan hê wholepart

ể ́ ̀ • La mô i quan hê “Is a partof”. • Ký hi u:ệ

• Có 2 d ng:ạ

ẻ

ộ ở ữ ầ ủ ẻ ữ – Chia s : chia s gi a các bao g p khác nhau – Hoàn toàn (composite): s h u đ y đ

Ộ

Ệ

QUAN H BAO G P (Aggregation)

̣ ạ

ặ ̀

̣ ̉

ượ

̣ ̉ ̣ ̣

̉ ̣ ̣ ̉

• Kê t tâp la mô i quan hê “la môt phâ n” (“is a part

̀ • Aggregation la môt d ng đ c biêt cua liên kê t mô ́ ́ hi nh ho a mô i quan hê toa n thêbô phân (whole ̀ ữ part) gi a đô i t ng toa n thê va ca c bô phân cua no . ́ ́ of”). ả

̣ ượ

ễ

̣ ̣ ̣

c biêu di n giô ng nh ca c

́ • B n sô quan hê đ ́ liên kê t kha c

Ộ

Ệ

QUAN H BAO G P (Aggregation)

Ộ

Ệ

QUAN H BAO G P (Aggregation)

Whole/aggregate

part

0..4

0..*

<> Student

<> Schedule

0..*

primaryCourses 0..2

<> CourseOffering

alternateCourses

Ộ

Ệ

QUAN H BAO G P (Aggregation)

ặ

ộ

• N u hai đ i t

ế ộ

ố

ẽ ở ị ầ The relationship is an

ố ượ ng đang b ràng bu c ch t ch b i ệ m t m i quan h toàn ph n aggregation.

Car

Door

0..2,4

ế

ng th ượ

ặ ộ ậ ượ ườ c coi là đ c l p, m c ng đ ế The relationship is an c liên k t

ng đ

ố ượ • N u hai đ i t ườ dù chúng th association.

Car

Door

0..2,4

Khi nghi ngờ, sử dụng association

Ộ

Ệ

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

ộ ồ ạ

ế

i (không có chapter n u không có book)

ố ị

ể

ộ

• S h u (Owns): Car has Tire

ố ị

ể

ộ

Chapter ụ ự – Có s ph thu c t n t – Không chia sẻ ộ – Là thu c tính c đ nh (m t chapter không th chuy n sang book khác) ở ữ – 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 cách thành viên

ặ – Không có đ c tr ng gì đ c bi

ạ ừ t ngo i tr là t

̀

́

Ệ

(Composition)

QUAN H CÂ U THA NH

̣ ạ

ạ

̉ ế các vòng đ i trùng kh p gi

ờ ở ữ

́ ơ • Môt d ng cua k t tâp v i quyê n s h u m nh và ́ ơ ạ

ở ữ ́ ̃ ơ a hai l p • Whole s h u Part, t o và huy Part. • Part b b đi khi Whole b b , Part không thê tô n ̀ ̀

ị ỏ ́

ị ỏ ạ

ạ

i nê u Whole không tô n t

Ộ

Ệ

QUAN H BAO G P (Aggregation)

ệ

ơ ả

• Aggregation c b n là b t k quan h whole–part

ữ

ấ ỳ ơ ồ ng ng v i ng nghĩa "Has" và "Member". ầ

ể ấ ữ

– Ng nghĩa có th r t m h ươ ứ – T ộ ố ượ – M t đ i t ộ ố ượ m t đ i t

ể ề ộ ơ

– T i m t th i đi m, m i đ i t

ể ỉ ầ (part) ch có

ạ ể

ớ ng thành ph n (part) có th thu c nhi u h n ồ ng bao g m (whole) ạ ơ • Composition là Aggregation m nh h n ỗ ố ượ ng thành ph n ồ (whole). ng bao g m "part" vào "whole"

ỉ ộ ố ượ ộ ồ ạ ừ i t ị ủ ị ủ ng "whole" b h y thì các "part" cũng b h y

ộ ờ ộ th thu c ch m t đ i t ự ụ – Có s ph thu c t n t ố ượ – Khi đ i t ươ ứ ng ng – T

Ộ

Ệ

QUAN H BAO G P (Aggregation)

Quan hệ m*n có thể chấp nhận

CourseOffering

Student

1..* 1..*

0..* 0..*

Các Student có thể trong nhiều CourseOffering. Nếu CourseOffering bị hủy, các Student không bị hủy!

Quan hệ m*n không được phép

Book

Chapter

Nếu Book bị xóa, các chương (Chapter) trong Book cũng bị xóa!

1 1

1..* 1..*

́

Vi du – Aggregration vs. Composition

́ ưở ̣ Aggregation – University and Chancellor ́ ườ • Nê u không co tr ng

ạ ̉ (Chancellor) không thê tô n t ̣ University), hiêu tr ạ ng Đ i hoc ( ̀ i.

• Nê u không co

̃ ́ ̀ ́ ạ ̉ ́ Chancellor, University vâ n co thê tô n t i

́ ạ ̉ ̉ Composition – University and Faculty • University không thê tô n t ́ i nê u không co ca c giang viên

ờ

̀ ượ ạ

ờ Faculty

ượ

ạ

̉ ̀ ́ (Faculty) va ng c l i (share timelife) ́ ́ ặ ơ ̉ University gă n ch t v i th i gian sô ng cua – Th i gian sô ng cua

̀ c giai pho ng thi

University không thê tô n t

̀ i va

– Nê u ́ Faculties đ ượ ạ c l

̉ ̉

Association Class

ộ c g n” vào m t association

<> ScheduleOfferingInfo

ượ ắ ộ ủ

• M t class “đ • Ch a các thu c tính c a relationship ể ệ • M t th hi n / 1 link

status

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

alternateCourses

0..*

0..2

<> Schedule

<> CourseOffering

primaryCourses

0..*

0..4

<> PrimaryScheduleOfferingInfob

grade

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

ộ ứ ộ

́

̣ ữ

ơ

́ Mô i quan hê gi a ca c l p (relationship)

• Liên kê t (Association)

ử ụ

(cid:150) S d ng (usea)

• Kê t tâp (Aggregation)

(cid:150) Strong association

(cid:150) hasa/isapart

ợ

• H p tha nh (Composition)

(cid:150) Strong aggregation

(cid:150) Share lifetime

́

̣ ữ

ơ

́ Mô i quan hê gi a ca c l p (relationship)

́

̣ ữ

ơ

́ Mô i quan hê gi a ca c l p (relationship)

TÔNG QUA T HO A (GENERALIZATION)

́ ́ ́ ơ

Account

́ ́ ̉

́ ̀

balance name number

Superclass (parent)

́ ̀ ơ ̣

Withdraw() CreateStatement()

ấ ị

Generalizatio n Relationship

̣ ữ • Mô i quan hê gi a ca c l p ̣ ơ trong đo môt l p chia se ̀ ặ ấ c u tru c va /ho c ha nh vi ́ ặ ơ v i môt ho c nhiê u l p kha c ́ ́ ́ ư ượ

̀ ̣

Savings

̀ ̀ ư th a

Checking

Subclasses

̀ ự • Xa c đ nh s phân c p vê ́ ̀ ̣ ư ng ho a m c đô tr u t ̀ ́ ́ ́ ư ơ trong đo l p con kê th a ́ ặ ơ ư môt ho c nhiê u l p cha t ́ (Single kê – Đ n inheritance)

Withdraw()

– Đa

́ kê

̀ư th a

(Multiple

GetInterest() Withdraw()

• La mô i liên hê “la môt

Subtype – Sub class

inheritance) ̀ ́ ạ

̀ ̣ ̣

lo i” (“is a kind of”)

TÔNG QUA T HO A (GENERALIZATION)

Stock

Savings

Checking

Tổng quát hơn

Bond

Asset

RealEstate

BankAccount

Security

RealEstate

Savings

Checking

Stock

Bond

ữ ỳ

ặ ớ

ả ớ

ươ

D n l p cô H ng đi thi gi a k lúc 12 g30 c l p luôn

TÔNG QUA T HO A (GENERALIZATION)

Asset

BankAccount

Security

RealEstate

Savings

Checking

Stock

Bond

Chuyên biệt hơn

TÔNG QUA T HO A (GENERALIZATION)

Không có s ự ổ t ng quát hóa

Part-timeStudent name address studentID numberCourses

Full-timeStudent name address studentID gradDate

Student

ự ổ

name address studentID

Có s t ng quát hóa

ParttimeStudent

FulltimeStudent

maxNumCourses

gradDate

TÔNG QUA T HO A (GENERALIZATION)

ạ i

ả ế ừ ể

ể ễ

ỉ

ụ • M c đích ị – Xác đ nh các kh năng dùng l ặ – 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

Subtype – Sub class

TÔNG QUA T HO A (GENERALIZATION)

́ ơ ng va l p cu thê

́ ư

ươ

ượ ng

ượ L p tr u t (Abstract and Concrete Class) ́ ượ ể ng không th co đô i t L p tr u t ́ ́ ▫ Ch a ph ượ ư ư ng th c tr u t ▫ Ch nghiêng ̃ư ́ ể ̣ ể

ượ

• L p cu th co th co đô i t

̣ ̉

̀

Polymorphism la gi ?

ự

ươ

ộ

́ Kha năng che giâ u ca c th c thi kha c nhau d

́ i m t giao diên duy nhâ t.

̉ ̣

̀

Polymorphism la gi ?

ụ

ệ

ộ Quan h Dependency – Ph thu c

ầ ử

• Là m t s liên quan ng nghĩa gi a hai ph n t

ộ ự ộ

ữ ộ ậ ổ ọ ự ầ ử ế ng đ n ph n t

ữ ộ ầ ử ộ ậ ầ ử ộ ph thu c. Ph n t ộ

ể ợ ử ụ

mô ụ hình, m t mang tính đ c l p và m t mang tính ph ẽ ộ đ c l p s thu c. M i s thay đ i trong ph n t ụ ưở ả mô nh h ộ ớ ở 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...

Client

Supplier

́

̣ ữ

ơ

́ Mô i quan hê gi a ca c l p (relationship)

́

̣ ữ

ơ

́ Mô i quan hê gi a ca c l p (relationship)

Domain Modeling

ề ệ ớ Phát hi n l p mi n

Ồ Ớ

Ể

BI U Đ L P

ự

́ • Bi u đô l p chi ra s tô n t

̀ i cua ca c l p va

ể ́

̉ ̉

́ ơ ế ế t k logic

̉ ̣

̀ ́ ́ ́ ́ ̉ ̉

́ ̀ ạ ̃ ̣ ư mô i quan hê gi a chu ng trong ban thi ́ ộ cua m t hê thô ng ̃ ́ – Chi ra câ u tru c ti nh cua mô hi nh nh l p, câ u tru c ́ bên trong cua chu ng va mô i quan hê v i ca c l p ́ kha c.

́ ̀ ́ ́ ư ơ ́ ̣ ơ ơ ̉

́ ́ ́ ́ ơ ộ ộ ̉ ̉ ̣ ̉ ̣ ̀ – Chi ra tâ t ca hoăc m t phâ n câ u tru c l p cua m t hê

́ thô ng.

– Không đ a ra ca c thông tin t m th i.

̀ ́ ạ

̉ ế

ợ ộ • Khung nhi n ti nh cua m t hê thô ng chu y u hô tr

ơ ́ ̉ ̣

ca c yêu câ u ch c năng cua hê thô ng.

ư ̀ ̀ ̉ ̣

Ồ Ớ

Ể

BI U Đ L P

Ồ Ớ

Ể

BI U Đ L P

Ồ Ớ

Ự

Ể

XÂY D NG 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.

ỗ ượ

ự ầ

ủ ệ ố ả ề ớ  c n xây d ng ầ ứ ạ • H th ng ph c t p có nhi u l p ả ộ ồ ồ ớ c đ mô t m t ph n

c đ l p, m i l

ượ

ổ

• L

ộ ố ớ

ệ c b sung và hoàn thi n trong mô ộ ế t thu c tính

t k (thêm m t s l p, chi ti

ụ

ệ ố ề ượ nhi u l ủ ệ ố c a h th ng ồ ớ ượ c đ l p đ ế ế hình thi ệ tác v , làm rõ các quan h )

ệ ớ

ề

Phát hi n l p mi n (Key Abstraction)

ể

• T các danh t

ừ – Tài li u yêu c u ph i đ y đ và đúng.

ệ

ả

ộ • Là m t phát bi u có m c đích cho m t t p các đ i t • Miêu t

ề ng (nhi u h n 1)

ừ trong phát bi u bài toán ầ ể ộ ậ ớ

ố ượ ộ

ả ầ ủ ụ

ể ệ ỉ

ế ự ế .

ơ – 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

ể ệ ậ

ớ ứ

ủ

ể

ợ

Ki m tra tính h p lý c a các l p ng viên

ằ

ạ

ủ ệ ố

ộ ệ ố

i toàn b h th ng không? ộ ớ

ậ ạ

ỉ ớ i m t l p khác không? ơ ồ

ậ

ộ

• Nó có n m ngoài ph m vi c a h th ng không? • Nó có ám ch t • Nó có l p l • 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? i là "Yes", N u câu tr l

ộ ộ ả ờ ớ

– Mô hình l p theo m t cách khác ho c lo i b l p đó

ạ ỏ ớ ặ ộ

ậ

ệ

ệ 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

0..*

CourseOffering

primaryCourses

Student

Schedule

0..*

0..4

ể ố

ụ ệ ố

ọ

ầ Ví d : H th ng đăng ký h c ph n

Course

CourseOffering

teach

offer

preRequisites

instructor

Professor - professorId - name

0..n 0..n

0..1 0..1

1 1

0..n 0..n

- credits - name - curriculum - description - number

- number - startTime - endTime - days /- numStudents

0..n 0..n

0..4 0..4 primaryCourses

0..2 0..2 alternateCourses

PrimaryScheduleOfferingInfob

- grade

0..n 0..n

Student

has

Schedule - semester

0..n 0..n

- name - address - studentID

1 1

ậ

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

• OutofDomain

–

Internal Web

–

• Abstract

–

• Good Candidates employee item (was office supplies) receipt

–

– order – order database error message

–

– user name – user password – account number – order number – ship date – total cost list of supplies

– office supplies > item

• 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

order

employee

name password

number account total cost

error message

receipt

item

explanation

order number ship date total cost

name quantity price

ậ

Bài t p Class Diagram

response

error message

receipt

explanation

order number ship date total cost

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

employee

order DB

order

name password

number account total cost

receipt

item

error message

explanation

order number ship date total cost

name quantity price

ậ

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.

University

Department

– Department offers one or more Classes. – A particular class will be offered by only one department.

Department

Class

1..* has 1

offers offers 1..* 1

ậ

Bài t p Class Diagram

– Department has Instructors and instructors can work for

Instructor

Department

one or more departments.

– Student can enroll in up to 5 Classes.

Student

Class

1..* assigned to 1..*

takes 0..5 *

ậ

Bài t p Class Diagram

–

– The same class can be taught by different instructors.

Instructor

Class

Instructors can teach up to 3 classes.

1..* 1..3 teaches

ậ

Bài t p Class Diagram

– Students can be enrolled in more than one

school.

Student

University

1..* member *

ậ

Bài t p Class Diagram

has

1..*

Department University

offers

assignedTo

member

1..*

attends

teaches

1…*

1..5

1..3 1..*

Instructor Class Student

ậ

Bài t p Class Diagram

Owner

Vehicle

myVehicles

myOwner

0..*

+ firstName : string + lastName : string + phoneNumber : string

+ weight : int + topSpeed : int + VIN : string

+ getOwner ( )

+ contactOwner ( [in] message : string ) : bool + getName ( ) : string

Car

Mot orcycle

+ modelType : string + maxPassengers : int

wheels

Wheel

+ modelType : string

+ addRepairNote ( [in] note : string ) : bool

+ maxMileage : int

wheels 4

ả ơ ế

Mô t

c ch phân tích

ậ t c c ch phân tích trong danh sách

ơ ế ấ ủ ơ ế ợ ấ ả ơ ế • T p h p t ớ ạ ớ • Á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

• Lo i b các l p trùng l p t

khác nhau ạ ỏ ặ ừ ớ ượ ồ ớ các l c đ l p khác nhau

ả

Đánh giá k t quế

RegisterFor CoursesForm

Registration Controller

Course Catalog System

Registration Controller

Student

Course Offering

Schedule

Course Offering

Schedule

CloseRegistration Form

Course Catalog System

Close Registration

CloseRegistration Controller

Billing System

Student

CloseRegistration Controller

Billing System

CloseRegistration Form

Course Offering

Schedule

ả

Đá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 welldefined 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 đ • T t c các yêu c u c th đã đ

ầ ụ ể ượ ượ ể ệ c y/c? 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? ng c n thi ấ ả ả ấ ấ ả t c các đ i t ộ ề ố t c các hành vi v các đ i

• Đã tìm th y t ố • Đã phân ph i m t cách rõ ràng t ng ch a?

ượ ư t

ượ ố ượ ố ề c phân ph i v đúng đ i t ng không?

ằ ở ố đâu, m i quan hê gwiax chúng

• Các hành vi có đ • Các interaction diagrams n m có rõ ràng và phù h p không?

ợ

Câu h iỏ

ủ

• M c tiêu c a UseCase Analysis là gì? • M t analysis class là gì? Cho bi

ụ ộ ế ả ề t tên và mô t v 3 analysis

stereotype.

• Usecase 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 UseCase Analysis?

Câu h iỏ

• Hãy cho bi

ế ệ

t các khái ni m sau: ặ ặ ả ổ ệ t là đ c t b sung

ơ ế ể

– Các Requirements artifact, đ c bi – 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:

ụ ệ

– Ánh x Analysis class v i các c ch phân tích

ứ – VOPC class diagram, ch a các analysis class, stereotype ủ c a chúng, nhi m v , các attribute, và relationship. ớ ơ ế ạ

Ậ

Ế

THI T L P CÁC PACKAGE

ộ ơ ế ể ổ ứ ầ ử ch c các ph n t vào nhóm có

ệ ữ ớ

ầ ử ừ ộ t m t package khác

• Package là m t c ch đ t quan h ng nghĩa v i nhau ể • Package có th import các ph n t • Có th ch ra quan h gi a các package

ệ ữ

• 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

ể ỉ ụ ộ – Ph thu c ổ – T ng quát hóa ứ ộ ấ ủ

Ậ

Ế

THI T L P CÁC PACKAGE

Ậ

Ế

THI T L P CÁC PACKAGE

Ậ

Ế

THI T L P CÁC PACKAGE

Ệ

Ậ

Ộ Ố Ớ

Ế

ộ ố ớ

ứ

ấ

ộ ớ

ệ ứ

ệ

NH N DI N THÊM M T S L P THI T KẾ ệ • 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

ờ ậ

ượ

ớ

ồ c đ l p đ ng th i c p

ồ ớ ộ

ổ ậ

ụ

ộ

ớ • B sung các l p m i vào l ệ ớ ố nh t các m i quan h m i(bao g p, ph thu c)

Ộ

Ặ

Ả

Ế

Đ C T CHI TI T CÁC THU C TÍNH

ầ

ặ ấ

ể

ứ ộ

• 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 ớ ủ l p c a th vi n và quan h bao g p vào l

ộ ư ệ ậ ữ ệ  b sung ổ ượ ồ ớ ộ c đ l p.

Ệ

Ụ

NHÂN DI N CHÍNH XÁC CÁC TÁC V

ả

ầ ự ạ

• 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:

Ỉ

ƯỢ Ồ Ớ

HOÀN CH NH L

C Đ L P

ớ ậ ụ ớ ố

ậ ị ữ ộ

ộ ệ ụ ổ ở ộ ớ ệ ớ • 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 ổ ở m t l p, package kéo theo thay đ i

ướ ặ ho c package: thay đ i ớ l p kia • Ký hi u: ệ ộ ố • M t s stereotype quy ướ c

c tr <>, <>, <>, <>,

<>, <>, <>

Ỉ

ƯỢ Ồ Ớ

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

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.

2. H i: ỏ Các l p ch th hi n c u trúc thông tin?

ỉ ể ệ ấ

ph i ch th hi n c u trúc thông tin mà còn

ả ả

Đáp: sai, các l p không c hành vi. mô t

ệ

ố

ườ

ẽ ở

ớ

ng s tr thành các l p trong mô

Đáp: Đúng ớ ớ ỉ ể ệ ấ ả

ừ

ể

ẽ

i phát bi u bài toán s là

3. H i: ỏ Các khái ni m then ch t th hình phân tích?

ờ ố ượ

trong các l ng các danh t ớ ể ng c viên đ chuy n thành l p và đ i t

ng?

Đáp: Đúng ườ ể

4. H i: ỏ Th ử ứ Đáp: Đúng

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

Chủ đề:

Phân tích thiết kế HTTT

Bài giảng Phân tích thiết kế HTTT

ƯỜ

Ạ Ọ

Ệ

NG Đ I H C CÔNG NGHI P TP.HCM Ệ KHOA CÔNG NGH THÔNG TIN

ươ

DOMAIN MODEL ƯỢ Ồ Ớ C Đ L P & L

Ố ƯỢ

Ệ Ố

Ủ

Ộ

ổ

ề

Use-Case Analysis

ệ

ế ậ

ự

ượ ồ ớ

c đ l p phân

Ti p c n xây d ng l tích

Domain Model (Mô hình mi n)ề

UML Class Diagram

Class Diagram Usage

class name

attributes

operations

Ố ƯỢ

Đ I T

NG ­ OBJECT

Ố ƯỢ

Đ I T

NG ­ OBJECT

Jane:

Savings Account 12876:

Greg:

Margaret:

Mortgage Account 29865:

Transaction 487:

Instant Teller 876:

Ố ƯỢ

Đ I T

NG ­ OBJECT

Ố ƯỢ

Đ I T

NG ­ OBJECT

ớ ng/l p: ể ng th c th (entity):

• Phân lo i đ i t – Đ i t ố ượ ự ế ủ ệ ố t c a h th ng, có th đ thi – Đ i t ố ượ ế – Đ i t ố ượ ượ t

Ớ

L P ­ CLASS

(Person)

Person

(Person)

Ớ

L P ­ CLASS

Ớ

Ấ

C U TRÚC L P ­ CLASS

Ụ Ớ

VÍ D L P ­ CLASS

name

Ạ Ớ

ự ề

ớ ớ ớ

• L p biên (bourndary class) ể • L p th c th (entity class) ể • L p đi u khi n (control class)

Ạ Ớ

Exec

Use Cases Analysis Classes

Design Elements

Source Code

Ớ

Ớ

Ệ

Ớ

Ệ

Ớ

Ệ

Lưu trữ và quản trị các thông tin trong system

NG OBJECT

NG OBJECT

NG OBJECT

NG OBJECT

L P CLASS

L P CLASS

C U TRÚC L P CLASS

VÍ D L P CLASS

L P TH C TH ENTITY CLASS

L P TH C TH ENTITY CLASS

L P TH C TH ENTITY CLASS

L P TH C TH ENTITY CLASS

L P TH C TH ENTITY CLASS

L P TH C TH ENTITY CLASS