UML và ứng dụng xây dựng mô hình hệ thống quản lý đào tạo

ĐẠI HỌC QUỐC GIA HÀ NỘI
KHOA CÔNG NGHỆ




Vũ Thị Tâm



UML VÀ ỨNG DỤNG XÂY DỰNG
MÔ HÌNH HỆ THỐNG QUẢN LÝ ĐÀO TẠO











LUẬN VĂN THẠC SỸ

Hà Nội, 2004




ĐẠI HỌC QUỐC GIA HÀ NỘI
KHOA CÔNG NGHỆ




Vũ Thị Tâm



UML VÀ ỨNG DỤNG XÂY DỰNG
MÔ HÌNH HỆ THỐNG QUẢN LÝ ĐÀO TẠO




Chuyên ngành: Công nghệ thông tin
Mã số: 1.01.10

LUẬN VĂN THẠC SỸ



NGƯỜI HƯỚNG DẪN KHOA HỌC:
PGS.TS Nguyễn Văn Vỵ








Hà Nội, 2004

MỞ ĐẦU
CHƢƠNG 1. PHƢƠNG PHÁP HƢỚNG ĐỐI TƢỢNG
1.1. Quá trình chung để phát triển phần mềm hƣớng đối tƣợng.
1.2. Các ƣu điểm của tiếp cận hƣớng đối tƣợng
1.3. Những vấn đề đặt ra trong việc khai thác phần mềm hƣớng đối tƣợng
CHƢƠNG 2. CÁC CÔNG CỤ HỖ TRỢ PHÁT TRIỂN HƢỚNG ĐỐI
TƢỢNG
2.1. Khái quát về UML.
2.2. Kiến trúc trong UML
2.2.1. Mô hình khái niệm của UML(conceptional model)
2.2.2. Các khối xây dựng
2.2.3. Các quan hệ:

2.2.4. Các biểu đồ trong UML
2.3. Các quy tắc của UML
2.4.Các cơ chế chung
2.5. Ứng dụng của UML
CHƢƠNG 3. ỨNG DỤNG UML ĐỂ XÂY DỰNG MÔ HÌNH CHO
HỆ THỐNG QUẢN LÝ ĐÀO TẠO.
3.1. Phát biểu bài toán
3.2. Mô tả nghiệp vụ
3.2.1. Các chức năng nghiệp vụ
3.2.2. Từ điển nghiệp vụ
3.3. Phân tích các ca sử dụng (Use case).
3.3.1. Các Actor của hệ thống.
3.3.2. Danh sách các ca sử dụng.
3.3.3. Mô hình các ca sử dụng và mô tả các ca sử dụng, mô hình miền
CHƢƠNG 4. PHÂN TÍCH VÀ CÀI ĐẶT CHƢƠNG TRÌNH
4.1. Mô hình liên kết giữa các lớp
4.2. Mô hình cộng tác của các ca sử dụng trong gói
4.3. Biểu đồ tuần tự thực thi các ca sử dụng
4.4. Mô hình liên kết giữa các lớp
4.5. Mô tả chi tiết các lớp
4.6. Một số giao diện của chƣơng trình
KẾT LUẬN VÀ KIẾN NGHỊ
TÀI LIỆU THAM KHẢO


1
Mở đầu
Trong quá trình phát triển của công nghệ phần mềm, nhiều dự án, nhiều chương
trình phát triển phần mềm đã được thực hiện, nhưng hoặc là không kết thúc, hoặc xây
dựng xong nhưng không thực hiện được hoặc đã xây dựng xong nhưng còn nhiều lỗi

không đáp ứng được yêu cầu của người sử dụng. Vì để xây dựng một phần mềm tốt
cần phải chú ý tới các vấn đề chính sau:
- Dữ liệu, đối tượng và cấu trúc của chúng
- Những hành vi thể hiện các chức năng và quá trình trong hệ thống
- Điều khiển hành vi tổng thể của hệ thống
Trong thực tế, cấu trúc dữ liệu và hành vi của hệ thống phải thường xuyên thay
đổi theo yêu cầu của người sử dụng. Do vậy, việc khảo sát, phân tích, thiết kế hệ thống
là một công việc rất phức tạp và quan trọng trong quá trình xây dựng một hệ thống
phần mềm. Phải phân tích kỹ bài toán, lựa chọn phương pháp phát triển hệ thống thích
hợp để cho hệ thống có tính mở, dễ thích nghi, chất lượng cao, giúp cho công việc bảo
trì hệ thống đỡ tốn kém.
Trong tất cả các giải pháp phát triển phần mềm hiện nay, giải pháp hướng đối
tượng đã được xem như là giải pháp tốt cho những hệ thống phần mềm có qui mô lớn,
độ phức tạp cao, có nhiều ưu điểm so với phương pháp hướng chức năng truyền thống.
Có thể giải pháp hướng đối tượng sẽ còn được tiếp tục được cải tiến cùng với mô hình
phát triển phần mềm. Nhưng hiện nay đây là một giải pháp tốt đang được sự quan tâm
đặc biệt và nhiều công ty đã triển khai.
Cùng với phương pháp luận, phương pháp phát triển phần mềm hướng đối tượng,
công cụ UML (Unifiel Modelling Language) và các phần mêm được xây dựng trên nó
( Rational Rose, ) đã cung cấp một phương tiện mạnh cho phép triển khai phương
pháp trên trong môi trường công nghiệp. UML là một ngôn ngữ mô hình hoá dùng để
đặc tả, mô hình hoá, xây dựng và làm tài liệu cho một hệ thống phần mềm [3] hướng
đối tượng. Ngôn ngữ này thể hiện trực quan được những quyết định và sự hiểu biết của
chúng ta về hệ thống cần xây dựng. Nó là một công cụ mạnh và đầy đủ được dùng để
phân tích, thiết kế, cài đặt, bảo trì và kiểm soát thông tin của hệ thống phần mềm lớn và

2
phức tạp. UML hiện là chuẩn công nghiệp của thế giới về ngôn ngữ đặc tả cho ngành
công nghệ phần mềm và đang được những hãng sản xuất phần mềm nổi tiếng trên thế
giới sử dụng như: Microsoft, Oracle, HP, …

Vì vậy việc nghiên cứu phương pháp phân tích, thiết kế hướng đối tượng và sử
dụng UML để phát triển phần mềm đang là một xu hướng trong kỹ nghệ phần mềm.
Những nội dung chính của đề tài:
 Tổng quan phương pháp phát triển phần mềm theo định hướng đối tượng
 Giới thiệu về hệ công cụ UML
 Vận dụng phương pháp và công cụ nêu trên tiến hành phân tích, thiết kế hệ thống
đào ạo ở một trường đại học.
Luận văn này gồm bốn chương. Chương 1 và 2 giới thiệu tổng quan về phương
pháp hướng đối tượng và các công cụ hỗ trợ. Chương 3 và chương 4 xây dựng mô
hình cho hệ thống quản lý đào tạo sử dụng UML. Quản lý đào tạo là một công việc
không thể thiếu được trong tất cả các hệ thống trường học, việc xây dựng một hệ thống
quản lý tự động sẽ giúp hệ thống các trường học quản lý được hiệu quả, chính xác và
đỡ tốn thời gian , sức lực của nhiều người.
Thực hiện đề tài này giúp em hiểu sâu hơn các bước để phân tích, thiết kế một
ứng dụng và phương pháp mô hình hoá hệ thống phần mềm hướng đối tượng bằng
công cụ UML. Vì vấn đề được xét là rộng lớn và phức tạp, kết quả của luận văn mới
dừng lại ở bước phân tích tổng thể bài toán và thiết kế chi tiết cho một phần quan trọng
của bài toán. Tuy vậy, những vấn đề lý thuyết, phương pháp luận và công cụ phát triển
phần mềm hướng đối tượng đã được sử dụng, vận dụng khá toàn diện. Đây là kết quả
bước đầu nghiên cứu khoa học, chắc chắn còn rất nhiều hạn chế, rất mong được ý kiến
đóng góp quý báu của các thầy cô và các bạn. Em cũng xin gửi lời cảm ơn chân thành
đến PGS. TS. Nguyễn Văn Vỵ, người đã giúp đỡ em rất nhiều để em có thể hoàn
thành luận văn này
Hà nội, ngày 5 tháng 2 năm 2004



3
Vũ Thị Tâm
chương 1. Phương pháp hướng đối tượng

Hiện nay thông tin thực sự trở thành nguồn tài nguyên quan trọng, nguồn của
cải to lớn của xã hội. Trong mọi lĩnh vực, các dữ liệu, các mối quan hệ của mọi hệ
thống kinh tế xã hội đều được xử lý một cách nhanh chóng nhất trên máy tính. Hệ
thống càng phát triển, tức là càng nhiều yếu tố hợp thành thì mối quan hệ giữa chúng
càng trở nên phức tạp. Để xử lý lượng thông tin lớn như vậy, cần phải có những
phương pháp và các công cụ hiện đại.
1.1. Quá trình chung để phát triển phần mềm hướng đối tượng.
Tiến trình thực hiện một bước lặp bao gồm xác định yêu cầu của hệ thống, phân
tích, thiết kế, triển khai và kiểm thử, chính là nội dung cơ bản của tiến trình phát triển
phần mềm hướng đối tượng. Trong các hoạt động đó, hoạt động phân tích và thiết kế
đặt ra nhiều vấn đề nan giải hơn cả.[3]
Những vấn đề đặt ra trong phân tích thiết kế hướng đối tượng
Đặc điểm của phân tích và thiết kế hướng đối tượng là nhìn nhận hệ thống như
một tập các đối tượng tương tác với nhau để tạo ra một hành động cho một kết quả ở
mức cao hơn. Để làm được điều đó người ta phải sử dụng hệ thống mô hình các đối
tượng với các đặc trưng cơ bản sau đây:
- Tính trừu tượng hoá cao
- Tính bao gói thông tin
- Tính mô đun hoá
- Tính kế thừa
Ngày nay, UML là công cụ được thiết kế có tất cả những tính chất và điều kiện
giúp ta xây dựng được các mô hình đối tượng có được các đặc trưng nêu ra ở trên.
Lập mô hình nghiệp vụ
Để có thể nắm bắt được yêu cầu hệ thống, trước hết ta phải nắm và hiểu được hệ
thống nghiệp vụ. Việc mô tả các yêu cầu của hệ thống nghiệp vụ đủ tốt là cần thiết để
có thể đạt được sự nhất trí giữa khách hàng và những người phát triển về những gì mà
hệ thống cần làm, không nên làm và những điều kiện ràng buộc đặt ra cho chúng. Mục

4
tiêu của bước này là để hiểu đúng và đầy đủ về hệ thống mà ta cần phải tin học hoá

thuần tuý về mặt nghiệp vụ. Muốn vậy, trước hết cần xác định phạm vi và chức năng
hệ thống cần nghiên cứu bằng cách liệt kê các chức năng mà hệ thống thực hiện, chỉ ra
mối quan hệ của nó với môi trường thông qua việc sử dụng các chức năng của hệ
thống. Tiếp đó cần tìm các ca sử dụng nghiệp vụ từ các chức năng của hệ thống mà qua
đó con người và các hệ thống khác sử dụng chúng.[1]
Xác định yêu cầu hệ thống
Nhiệm vụ chính trong xác định yêu cầu là phát triển một mô hình của hệ thống
cần xây dựng bằng cách dùng các ca sử dụng. Điều này là tự nhiên, bởi vì các yêu cầu
về chức năng được cấu trúc thành các ca sử dụng và do phần lớn các yêu cầu phi chức
năng đều là riêng dối với một ca sử dụng đơn nên chúng cũng được xử lý trong các ca
sử dụng đó. Để mô tả các yêu cầu nghiệp vụ dưới góc độ phát triển phần mềm ta cần
tìm các tác nhân và các ca sử dụng để chuẩn bị một phiên bản đầu tiên của mô hình ca
sử dụng. Sau đó, ta sẽ xác định các ca sử dụng có ý nghĩa về mặt kiến trúc và sắp thứ
tự ưu tiên các ca sử dụng sẽ được triển khai trong bước lặp hiện thời.[4]
Phân tích
Nhiệm vụ của pha phân tích là làm mịn dần các yêu cầu đã nhận được từ pha
trước và tạo cấu trúc cho chúng. Thông qua đó, các yêu cầu được hiểu chính xác hơn,
từ đó đưa ra cấu trúc cho toàn bộ hệ thống.
Nhiệm vụ của pha phân tích là tìm ra cách thức để thực hiện các yêu cầu của hệ
thống đã được xác định trong các ca sử dụng. Cụ thể là, cần phân tích mô hình ca sử
dụng bằng cách tìm ra cách tổ chức các thành phần bên trong của hệ thống để thực hiện
mỗi ca sử dụng. Những thành phần cấu trúc bên trong hệ thống ở đây chính là ba loại
lớp phân tích. Công việc xác định các lớp không phải làm tuỳ tiện mà thực hiện theo
từng ca sử dụng, trước hết cho các ca sử dụng theo thứ tự ưu tiên được sắp. Sau đó, cấu
trúc lại cách tổ chức các thành phần này của hệ thống. Để đạt mục tiêu này cần tiến
hành các hoạt động:
- Phân tích kiến trúc hệ thống
- Phân tích một ca sử dụng

5

- Phân tích một lớp
- Phân tích một gói
Trong quá trình phân tích, ta sẽ liên tục tìm các gói, các lớp phân tích mới và
các yêu cầu chung khi tiếp tục làm mịn mô hình bằng cách phân tích các gói phân tích
và duy trì các gói đó.
Thiết kế
Trong thiết kế, chúng ta định hình hệ thống và tìm hình thức thể hiện về mặt vật
lý của nó (kể cả kiến trúc) để thực hiện mọi yêu cầu được đặt ra cho hệ thống. Một đầu
vào cho thiết kế là mô hình phân tích. Khi thiết kế ta sẽ cố gắng bảo tồn được càng
nhiều càng tốt cấu trúc của hệ thống được định hình từ mô hình phân tích. Kết quả của
thiết kế là mô hình thiết kế và mô hình triển khai được thể hiện ra dưới dạng một loạt
các mô hình cụ thể. Mô hình thiết kế là sự thực thi mô hình phân tích khi tính đến các
điều kiện của môi trường để thực thi hệ thống.
Để nhận được mô hình thiết kế ta cần thực hiện các công việc sau:
- Thiết kế kiến trúc
- Thiết kế một ca sử dụng
- Thiết kế một lớp
- Thiết kế một hệ thống con
Mô hình thiết kế là một mô hình đối tượng mô tả sự thực thi các ca sử dụng về
mặt vật lý bằng cách tập trung vào việc xác định các yêu cầu chức năng và phi chức
năng, cũng như các ràng buộc khác liên quan đến môi trường triển khai và ảnh hưởng
của chúng lên hệ thống.
Đặc điểm của cách tiếp cân hướng đối tượng
Sử dụng kết hợp cả hai cách thiết kế: trên - xuống (top-down) và dưới-lên
(bottom-up). Kỹ thuật phân rã chức năng trên-xuống được áp dụng để thiết kế các lớp,
còn cấu trúc cả hệ thống được xây dựng dựa trên kiến trúc đơn thể được đặc tả trong
miền ứng dụng và hỗ trợ một phần trong việc sử dụng lại - cách tiếp cận dưới - lên và
nguyên lý che dấu thông tin cho phép sử dụng lại một cách tối đa.
1.2. Các ưu điểm của tiếp cận hướng đối tượng

6
 Những đối tượng được thiết kế tốt trong hệ thống hướng đối tượng là cơ sở để kết
hợp các đơn thể (module) được sử dụng lại thành hệ thống có chất lượng cao hơn.
 Cơ chế tương tác bằng cách truyền thông điệp giữa các đối tượng đảm bảo cho việc
mô tả các giao diện giữa các modul bên trong hệ thống và hệ thống bên ngoài trở
nên dễ dàng hơn.
 Việc phân tích và thiết kế theo cách phân bài toán thành các đối tượng là hướng tới
lời giải của thế giới thực, là tự nhiên hơn so với cách phân rã theo chức năng từ trên
xuống (Top-down).
 Nguyên lý che dấu thông tin hỗ trợ cho việc xây dựng các hệ thống thông tin an
toàn.
 Nguyên lý thiết kế dựa vào sự bao gói cả dữ liệu và xử lý trong một đối tượng rất
phù hợp với ngữ nghĩa của mô hình trong cài đặt.
 Lập trình hướng đối tượng và kỹ thuật kế thừa cho phép xác định các modul và sử
dụng ngay sau khi chúng chưa thực hiện đầy đủ các chức năng và sau đó mở rộng
các đơn thể đó mà không ảnh hưởng tới các đơn thể đã có.
 Tiếp cận hướng đối tượng cung cấp cho ta công cụ hỗ trợ giải quyết độ phức tạp
của bài toán bằng việc phân rã thành các thành phần độc lập tương đối với nhau.
 Hệ thống hướng đối tượng dễ dàng mở rộng thành các hệ thống có quy mô lớn hơn
nhờ tương tác giữa các đối tượng thông qua việc gửi và nhận thông báo.
 Về vấn đề phát triển và bảo trì hệ thống đơn giản hơn do có sự phân hoạch rõ ràng,
là kết quả của việc bao gói thông tin và sự kết nối giữa các đối tượng thông qua
giao diện, là việc sử dụng lại các thành phần tin cậy.
 Xoá bỏ được hố ngăn cách giữa các bước phát triển, thiết kế và cài đặt trong quá
trình phát triển phần mềm.[2]
1.3. Những vấn đề đặt ra trong việc khai thác phần mềm hướng đối tượng
- Xác định các lớp và đối tượng
- Gán trách nhiệm
- Giao tiếp với cơ sở dữ liệu
- Cần có công cụ thích hợp: UML

7



Chương 2. Các công cụ hỗ trợ phát triển hướng đối tượng
Phương pháp phân tích thiết kế hướng đối tượng với việc sử dụng ngôn ngữ
UML cung cấp cho chúng ta phương tiện đủ mạnh để xác định các đối tượng và xây
dựng các đơn thể của hệ thống cần phát triển
2.1. Khái quát về UML.
UML là một ngôn ngữ chuyên dụng
UML được đưa vào sử dụng từ năm 1997, và đã nhanh chóng được công nghiệp
phần mềm chấp nhận làm ngôn ngữ đồ hoạ chuẩn để đặc tả, xây dựng và làm tài liệu
cho các hệ thống phần mềm chuyên sâu.
UML là ngôn ngữ mô hình hoá, ngôn ngữ chuẩn thống nhất để viết ra bản kế
hoạch chi tiết phần mềm. Nó mô tả ký pháp thống nhất, ngữ nghĩa và các định nghĩa
chính mô hình hoá. Các khung nhìn của ngôn ngữ cho phép nhìn nhận hệ thống được
phát triển khác nhau, nó không khó hiểu và dễ sử dụng. Như mọi ngôn ngữ mô hình
hoá khác, UML có ký pháp (các biểu tượng sử dụng trong mô hình)và tập các quy tắc
sử dụng nó để mô hình hoá các hệ thống của thế giới thực.
 UML là một ngôn ngữ
Là một ngôn ngữ UML có từ vựng và quy tắc tổ hợp các từ vựng đó nhằm mục
đích giao tiếp. Ngôn ngữ mô hình là ngôn ngữ có từ vựng và quy tắc tập trung vào biểu
diễn về mặt vật lý và khái niệm của hệ thống. Vì vậy, UML là ngôn ngữ chuẩn công
nghiệp để viết ra kế hoạch chi tiết phần mềm.
 UML là ngôn ngữ để biểu diễn đồ hoạ
Đối với nhiều lập trình viên, không có khoảng cách giữa ý tưởng cài đặt và
chuyển nó thành mã, họ suy nghĩ vấn đề và viết ngay mã trình cho nó. Tuy nhiên, việc
giao tiếp giữa mô hình khái niệm với những cái khác trong vòng đời phát triển phần
mềm sẽ gặp khó khăn khi mọi người không sử dụng chung một ngôn ngữ cho dự án.

Đặc biệt có những dự án và tổ chức phát triển phần mềm theo ngôn ngữ riêng của họ

8
và khó có thể hiểu được đối với những người mới tham gia dự án. Hơn nữa một số vấn
đề của hệ thống phần mềm sẽ được hiểu rõ ràng hơn thông qua mô hình thay cho ngôn
ngữ lập trình văn bản. Cuối cùng, nếu người viết mã không bao giờ viết thành các mô
hình thì thông tin có thể mất hoặc không thể viết lại một cách đầy đủ nếu chỉ xem mã
lệnh trong trường hợp người viết mã chuyển đi nơi khác làm việc.
Để khắc phục những nhược điểm trên, ta sẽ sử dụng ngôn ngữ UML để xây
dựng các mô hình khác nhau:
- Mỗi ký pháp trong UML mang một ngữ nghĩa rõ ràng, nên nếu một người
trong đội phát triển viết mô hình UML thì những người khác có thể hiểu
được, thậm chí các công cụ khác cũng có thể dịch được những mô hình đó
một cách rõ ràng
- Các cấu trúc mô tả dưới dạng các mô hình đồ hoạ nên dễ dàng nắm bắt
- Mô hình rõ ràng sẽ làm cho việc trao đổi, giao tiếp trở nên dễ dàng.
 UML là ngôn ngữ đặc tả
Đặc tả là mô tả rõ ràng nhất những điểm mấu chốt của vấn đề. UML cho phép
mô tả chính xác, không nhập nhằng và hoàn thiện. UML tập trung đặc tả toàn bộ các
quyết định phân tích, thiết kế và cài đặt quan trọng trong quá trình phát triển và triển
khai hệ thống phần mềm.
 UML là ngôn ngữ để tạo mã
UML không phải là ngôn ngữ lập trình trực quan, những mô hình của nó có thể
kết nối trực tiếp tới các ngôn ngữ lập trình khác nhau. Điều đó có nghĩa là có thể ánh
xạ từ mô hình trong UML sang một ngôn ngữ lập trình như Java, C
++
hoặc Visual
Basic, thậm chí có thể sang các bảng trong cơ sở dữ liệu quan hệ hoặc cơ sở dữ liệu
hướng đối tượng. Đồng thời có thể thực hiện ngược lại từ cài đặt về mô hình UML.
Điều đó có nghĩa là nó cho phép chúng ta có thể làm việc với văn bản, chương trình,

hay đồ hoạ một cách nhất quán.
 UML là ngôn ngữ làm tài liệu

9
UML hướng tới làm tài liệu kiến trúc hệ thống và các chi tiết của nó. UML cho
khả năng biểu diễn yêu cầu, thử nghiệm, mô hình hoá các hoạt động lập kế hoạch và
quản lý sản phẩm.
- UML cho biết giới hạn của hệ thống và các chức năng của nó thông qua các trường
hợp sử dụng (Use case) và tác nhân (Actor).
- Trong UML các trường hợp sử dụng được mô tả bằng biểu đồ lôgic.
- Biểu diễn cấu trúc tĩnh của hệ thống nhờ biểu đồ lớp.
- Mô hình hoá các hành vi đối tượng bằng biểu đồ chuyển trạng thái.
- Phản ánh kiến trúc cài đặt vật lý bằng biểu đồ thành phần và biểu đồ triển khai
- Mở rộng khả năng mô tả các chức năng và hành vi hệ thống bằng khuôn mẫu
(stereotypes) [4]
2.2. Kiến trúc trong UML
Kiến trúc phần mềm cho ta một cái nhìn khái quát nhất về hệ thống phần mềm
ở các góc độ khác nhau. Mỗi khung nhìn phản ánh về một khía cạnh của tổ chức và cấu
trúc của hệ thống mà tập trung vào từng mặt cụ thể giúp cho ta hiểu và sử dụng hệ
thống tốt nhất.
Khung nhìn ca sử dụng cho ta cách sử dụng chức năng để mô tả hành vi của hệ
thống khi nhìn nhận hệ thống dưới góc độ của người dùng cuối cùng, của các nhà phát
triển.
Khung nhìn thiết kế bao gồm các lớp, các giao diện, các cộng tác tạo nên từ
vựng để đặc tả các vấn đề và các giải pháp cho nó. Khung nhìn này hỗ trợ việc xác
định các yêu cầu chức năng của hệ thống, nghĩa là các dịch vụ mà hệ thống sẽ cung cấp
cho người dùng.

Hình 2.1: Mô hình hoá kiến trúc hệ thống
Khung nhìn bố trí
Khung nhìn triển khai
Khung nhìn tiến trình
Khung nhìn thiết kế
Khung nhìn ca sử
dụng

10
Khung nhìn tiến trình của hệ thống chứa đựng các luồng và tiến trình công việc
tạo nên cơ chế hoạt động tương tranh
Khung nhìn triển khai của hệ thống bao gồm các thành phần và các file được
kết hợp lại cho ra các hệ thống vật lý. Khung nhìn này hướng đến việc quản lý cấu
hình của hệ thống.
Khung nhìn bố trí bao gồm các nút tạo nên kết cấu phần cứng mà trên đó hệ
thống vận hành. Khung nhìn này chủ yếu hướng đến sự phân tán và cài đặt cụ thể của
hệ thống. [4]
2.2.1. Mô hình khái niệm của UML(conceptional model)

Hình 2.2: Các cấu trúc thành phần của UML
Ba khối chính tạo nên UML là các khối xây dựng, các quy tắc ngữ nghĩa và một
số cơ chế chung được áp dụng cho việc mô hình hoá.
2.2.2. Các khối xây dựng
Các sự vật là các trừu tượng hoá và là những phần tử lớp đầu tiên để xây dựng
nên các mô hình trong UML. Các quan hệ gắn kết các sự vật lại với nhau, các biểu đồ
nhóm các sự vật được quan tâm lại tạo nên ngữ nghĩa của nó (cho một mô hình)
a. Các sự vật cấu trúc (structural things): Bao gồm
Các khối xây dựng
Sự vật
Quan hệ
Biểu đồ
Sự vật
cấu trúc
Sự vật
hành vi
Sự vật
nhóm gộp
Sự vật
chú thích
Phụ thuộc
Liên kết
Tổng quát
hoá
Ca sử dụng
Lớp
Đối tượng
Tuần tự
Cộng tác

Trạng thái
Hoạt động
Thành phần
Bố trí
Ca sử dụng
Lớp
Lớp hoạt
động
Giao diện
Thành phần
Sự cộng tác
Nút
Tương tác
Máy trạng
thái
Gói
Mô hình
Hệ thống con
Khung làm
việc
Ghi chú

11
Lớp (class): Một lớp mô tả một tập hợp các đối tượng có chung các thuộc tính,
các tác vụ, các mối quan hệ và ngữ nghĩa. Một lớp có trách nhiệm thực hiện một hay
nhiều giao diện. Một lớp được biểu diễn bằng một hình chữ nhật bên trong có tên,
các thuộc tính và các tác vụ (phương thức)

Hình 2.3. Lớp
Một lớp có ba thành phần như sau: tên lớp, các thuộc tính, các phương thức
(ứng xử) của lớp .
Tên lớp thường là danh từ, ví dụ: sinh viên.
Các thuộc tính được coi là đúng nếu nó bao gồm các thông tin để mô tả và nhận
dạng một thực thể cụ thể của một lớp. Tuy nhiên chỉ nên đưa vào các thuộc tính mà hệ
thống quan tâm. Mỗi một thuộc tính đều thuộc một kiểu dữ liệu nào đó. Kiểu dữ liệu
nguyên thuỷ bao gồm các kiểu như: Integer, Boolean, Real. Ngoài ra các thuộc tính
còn có khả năng nhìn thấy được (Visibility) bao gồm public, private và protected. Nếu
một thuộc tính là public nghĩa là một lớp khác có thể tham chiếu đến và sử dụng thuộc
tính đó. Nếu là private thì các lớp khác không thể tham chiếu đến thuộc tính này.
Các phương thức trong một lớp mô tả cái mà lớp đó có thể làm. Các phương
thức thường được gọi là các hàm (funtion) nhưng chúng chỉ thuộc vào lớp đó và áp
dụng đối với các đối tượng của lớp đó. Cũng giống như các thuộc tính, các phương
thức cũng có phạm vi và khả năng nhìn thấy được.
Đối tượng là khái niệm dùng để mô hình hoá một vật hoặc một khái niệm trong
thế giới thực, có thể là một phần của bất kỳ loại hệ thống nào như máy móc hay một tổ
chức. Có một số đối tượng (ví dụ như các đối tượng thực thi trong hệ thống phần mềm)
Window
Size
Origin

Open()
Close()
Move()
Tên lớp

Thuộc tính
Tác vụ

12
không tồn tại một cách trực tiếp trong thế giới thực nhưng nó phát sinh bắt nguồn từ
việc nghiên cứu cấu trúc và hành vi của các đối tượng trong thế giới thực. Vì thế các
đối tượng liên quan đến hiểu biết của chúng ta về thế giới thực bởi đối tượng là thể
hiện của một lớp nào đó.
Ký pháp: trong UML đối tượng được thể hiện bởi một hình chữ nhật với tên ở
bên trong. Tên đối tượng được gạch chân


Hình 2.4: Đối tượng
Giao diện (interface): Một giao diện là một tập hợp các tác vụ đặc tả một dịch
vụ của một lớp hoặc một thành phần. Một giao diện biểu diễn bằng một hình tròn với
tên của nó:
Ispenlling
Hình 2.5: Giao diện
Sự cộng tác (collaboration): Sự cộng tác xác định các hoạt động bên trong hệ
thống và là một bộ các nguyên tắc và các phần tử khác nhau cùng làm việc để cung cấp
một hành vi hợp tác lớn hơn tổng hành vi của tất cả các phần tử đó. Một sự cộng tác
được biểu diễn bằng một hình elip với đường nét đứt và thường chỉ gồm có tên


Hình 2.6: Sự cộng tác
Ca sử dụng (Use case): Một ca sử dụng mô tả một tập hợp các dãy hành động
mà hệ thống thực hiện để cho một kết quả quan sát được các giá trị đối với một tác
nhân. Một ca sử dụng được biểu diễn bằng một hình elip nét liền, thường chỉ bao gồm
có tên:

Hình 2.7: Ca sử dụng
Dãy các trách
nhiệm
Sửa hồ sơ
sinh viên
Hình tròn

13
Những chức năng mà hệ thống cung cấp sẽ được mô tả trong mỗi ca sử dụng.
Trong đó mô tả những chức năng, những thành phần ở bên ngoài - tác nhân (Actor)
tương tác với hệ thống và mối quan hệ giữa ca sử dụng và tác nhân (biểu đồ ca sử
dụng). Nói một cách chính xác hơn, ca sử dụng mô tả trình tự các hành động của một
tác nhân nào đó, sử dụng một phần chức năng của hệ thống để hoàn thành một tiến
trình. Vì thế, đối với người sử dụng, ca sử dụng mô tả một cách để họ sử dụng hệ
thống: nó mô tả các tương tác giữa một số tác nhân và hệ thống thông qua dịch vụ mà
hệ thống cung cấp cho các tác nhân. Mỗi ca sử dụng là một bộ phận các yêu cầu chức
năng cho một số người sử dụng. Kết hợp tất cả các ca sử dụng lại với nhau ta có được
mô tả về toàn bộ các yêu cầu chức năng của hệ thống. Tất cả các ca sử dụng cho phép
những người phát triển phần mềm và khách hàng thoả thuận được về các yêu cầu, các
điều kiện cũng như các khả năng mà hệ thống phải tuân theo.
Tác nhân: Một tác nhân thể hiện một tập hợp các vai trò mà các thực thể ngoài
(đối với hệ thống) có thể thực hiện khi sử dụng hệ thống. Một tác nhân thể hiện một
nhóm người, một bộ phận, một tổ chức hoặc các hệ thống nào khác có tương tác với hệ
thống đó. Tương tác của tác nhân với hệ thống có thể:
 Cung cấp thông tin cho hệ thống.
 Lấy thông tin từ hệ thống.
 Nhận thông tin từ hệ thống và cung cấp thông tin cho hệ thống.
Một số đặc điểm của tác nhân:
 Một tác nhân có tên và tên đó nên phản ánh vai trò của tác nhân. Tên không nên

phản ánh một thực thể đặc trưng của tác nhân và cũng không phản ánh chức năng của
tác nhân.
 Các tác nhân tương tác với hệ thống bằng cách gửi và nhận thông báo với hệ
thống như nó thực hiện các ca sử dụng.
 Nếu có nhiều hơn một tác nhân trong một ca sử dụng thì tác nhân kích thích
được gọi là “tác nhân khởi tạo” hay “tác nhân chủ động” và các tác nhân còn lại được
gọi là “tác nhân tham dự” hay “tác nhân bị động”.

14
 Các tác nhân tương tác trực tiếp với hệ thống được gọi là các tác nhân chính hay
các tác nhân trực tiếp, các tác nhân còn lại được gọi là các tác nhân thứ yếu.
Cách xác định các tác nhân: dựa vào việc nhận dạng các tác nhân, là các thực
thể quan tâm đến việc sử dụng và tương tác với hệ thống, tức là phải xác định xem nó
đòi hỏi gì ở hệ thống và cần đến những ca sử dụng nào để sử dụng hệ thống?
Khi mô tả một tác nhân cần chỉ rõ vai trò của tác nhân khi tương tác với hệ
thống. Ví dụ, với hệ thống bán hàng có một tác nhân là nhân viên bán hàng, ta có thể
mô tả một cách ngắn gọn như sau:
Nhân viên bán hàng: là những người bán hàng cho khách khi có khách đến mua
hàng.
Tác nhân được biểu diễn bằng hình tượng sau:


Xác định ca sử dụng:
Có hai cách xác định ca sử dụng trong hệ thống
 Xác định thông qua các tác nhân:
Xác định các tác nhân nào có liên quan tới hệ thống hoặc tổ chức: tìm và
mô tả tất cả các tác nhân bằng cách xem người dùng nào sẽ sử dụng hệ thống và hệ
thống nào khác phải tương tác với nó.
Với mỗi tác nhân, xác định các quá trình mà nó khởi tạo hoặc tham gia
vào bằng cách xem tác nhân trao đổi/ tương tác hoặc sử dụng với hệ thống để làm việc

như thế nào
 Xác định thông qua các sự kiện
Những sự kiện nào hệ thống phải có đáp ứng lại hoặc có hành vi ứng xử
tương ứng.
Mối quan hệ giữa các sự kiện với tác nhân, sự kiện với hệ thống
Khi xác định các ca sử dụng cần thảo luận, trao đổi với người dùng hệ thống và
nên xem xét lại các dữ liệu đặc tả yêu cầu đã có để có thể trả lời một số câu hỏi sau:
Nhiệm vụ chính của tác nhân là gì?

15
Có phải tác nhân sẽ phải đọc, viết hay thay đổi thông tin hệ thống?
Có phải tác nhân sẽ phải cung cấp tin tức cho hệ thống về những thay đổi
bên ngoài hệ thống?
Có phải tác nhân mong muốn được cung cấp tin tức về sự thay đổi
không?
Thành phần (Component): Thành phần là một bộ phận vật lý có thể thay thế
được của một hệ thống được làm phù hợp với những điều kiện cụ thể và cung cấp
phương tiện (tác vụ) thực hiện một tập các giao diện. Một thành phần biểu diễn một gói
vật lý các phần tử lôgic khác nhau như các lớp, các giao diện và sự cộng tác. Một thành
phần được biểu diễn bằng một hình chữ nhật với các bảng và thường bao gồm chỉ có
tên của nó:



Hình 2.8: Các thành phần
Lớp chủ động (active class): Một lớp chủ động là một lớp mà các đối tượng của
nó sở hữu một hay một số tiến trình hoặc các dãy thao tác. Bởi vậy nó có thể khởi
động hoạt động điều khiển. Một lớp chủ động được biểu diễn như một lớp nhưng có
đường viền đậm:

Hình 2.9. Lớp hoạt động
Nút (node): Một nút là một phần tử vật lý tồn tại trong thời gian thực và biểu
diễn một tài nguyên tính toán, thường có ít nhất bộ nhớ và khả năng xử lý. Một nút
biểu diễn bằng một hình hộp thường bao gồm tên của nó:

Orderform.java
Window

Size
Origin

Open()
Close()
Move()

16



Hình 2.10: Một nút
b. Các sự vật hành vi (behavioral things): các sự vật hành vi là những bộ phận động
của các mô hình UML, mô tả hành vi của hệ thống theo thời gian và không gian. Có
hai loại hành vi sơ cấp của sự vật:
Sự tương tác (interaction): sự tương tác là một hành vi bao gồm một tập các
thông báo được trao đổi giữa một tập các đối tượng trong một khung cảnh cụ thể nhằm

thực hiện một mục tiêu xác định. Một thông báo được biểu diễn bằng một đường thẳng
có hướng, gồm tên

Hiển thị
Thông báo
Máy trạng thái (state machine): một máy trạng thái gồm một số các phần tử
biểu diễn các trạng thái, các chuyển dịch (từ một trạng thái sang một trạng thái khác),
các sự kiện (các sự vật kích hoạt một chuyển dịch). Một trạng thái được biểu diễn bằng
một hình chữ nhật góc tròn trong đó có tên trạng thái và các trạng thái con của nó (nếu
có)


Hình 2.11. Trạng thái
Các sự vật nhóm gộp ( grouping thinks): Có một loại sự vật nhóm gộp duy
nhất là gói (package). Nó là công cụ để tổ chức các thành phần của một mô hình thành
các nhóm: một mô hình có thể được phân chia vào trong các gói. Một gói đơn thuần là
một khái niệm.
Gói cung cấp một cơ chế nhóm gộp để:
 Chỉ ra bức tranh lớn không quá đi sâu vào chi tiết
 Chỉ ra sự phụ thuộc giữa các lớp
Máy dịch vụ
Trả lại bản sao

17
 Chỉ ra chi tiết các tập hợp con cô lập
Thông thường một gói là tập hợp của các lớp nhưng nó cũng có thể chứa các gói
khác. Một lớp chỉ thuộc vào duy nhất một gói. Một gói có thể tham chiếu đến các gói
khác hoặc phụ thuộc vào các gói, các lớp khác. Tham chiếu của một gói chỉ ra rằng có
một số lớp thuộc gói đó phụ thuộc vào một số lớp thuộc vào gói mà nó tham chiếu đến.
Một gói được biểu diễn như một bảng thường chỉ gồm có tên, và đôi khi có nội

dung của nó.


Hình 2.12: Gói
Sự vật giải thích (Annontional things): sự vật gải thích là phần giải thích của
mô hình UML. Nó có thể sử dụng để mô tả, giải thích và đánh dấu một phần tử bất kì
trong một mô hình. [4]
Dù cho một ngôn ngữ có mức độ bao quát đến đâu thì vẫn còn những thứ chưa
được định nghĩa trong ngôn ngữ đó. Để có thể thể hiện được hết mọi điều trong mô
hình, UML cung cấp khả năng lập chú thích. Một chú thích có thể được đặt bất cứ chỗ
nào trong biểu đồ và có thể chứa bất kỳ loại thông tin nào. Loại thông tin mà nó chứa
không được UML thông dịch. Chú thích được gắn vào một vài phần tử trong biểu đồ
với đường đứt nét chỉ ra phần tử nào được giải thích thêm hay chi tiết hoá với thông tin
trên chú thích. Một chú thích thường chứa các thông tin dẫn giải hay các câu hỏi từ
người làm mô hình như lời nhắc nhở để giải quyết các tình trạng khó xử sau này. Một
chú thích có thể có các khuôn mẫu (stereotype) mô tả kiểu chú thích. Một chú thích
biểu diễn một lời chú giải không có ảnh hưởng về ngữ nghĩa, nghĩa là nội dung của nó
không làm thay đổi nghĩa của mô hình mà nó gắn vào. Điều này giải thích tại sao các
chú thích thường được sử dụng để đặc tả các thứ như các yêu cầu, các nhận xét, các sự
giải thích và các ràng buộc.
Một chú thích có thể chứa bất kỳ sự phối hợp văn bản hay đồ thị nào. Ta có thể
đưa vào một URL, thậm chí liên kết hay nhúng vào một tài liệu khác.
Các quy tắc nghiệp vụ

18
Một chú thích là một biểu tượng đồ hoạ để diễn tả các ràng buộc hoặc các lời
chú giải gắn vào một hay một tập hợp các phần tử. Một chú thích được biểu diễn như
một hình chữ nhật với một nếp quăn ở góc, cùng với chú giải bằng văn bản hoặc đồ
hoạ ở bên trong.
Trả lại bản sao

Hình 2.13: Chú thích
2.2.3. Các quan hệ:
a. Quan hệ giữa ca sử dụng và tác nhân:
Quan hệ giữa ca sử dụng và tác nhân thường gọi là quan hệ tương tác vì nó thể
hiện sự tương tác giữa một tác nhân và một ca sử dụng. Thông thường đây là quan hệ 1
- 1 không có hướng để chỉ ra rằng tác nhân có thể liên lạc với ca sử dụng theo cả hai
hướng. Quan hệ này thể hiện bằng một đường thẳng nối giữa tác nhân và ca sử
dụng.[7]
b. Quan hệ giữa ca sử dụng với ca sử dụng
Các ca sử dụng quan hệ với nhau theo ba kiểu quan hệ là: mở rộng, bao gồm và
tổng quát hoá.
Quan hệ mở rộng: là một quan hệ tổng quát hoá trong đó một ca sử dụng mở
rộng một ca sử dụng khác bằng cách đưa thêm các hành động vào ca sử dụng tổng
quát. Ca sử dụng mở rộng có thể bao gồm các hành vi từ ca sử dụng được mở rộng
thêm, phụ thuộc vào các điều kiện mở rộng. Nó không phải bao gồm toàn bộ hành vi,
nó có thể chọn một phần hành vi của ca sử dụng tổng quát mà nó muốn dùng lại. Ca sử
dụng được mở rộng phải là ca sử dụng hoàn thiện. Thông thường các ca sử dụng được
mô tả dưới dạng văn bản nên cần xác định phần nào trong ca sử dụng mở rộng là được
sử dụng lại từ ca sử dụng tổng quát, phần nào là được định nghĩa lại, phần nào là được
thêm vào. Một ca sử dụng mở rộng là một cách để có thể kiểm soát các ngoại lệ, là
trường hợp đặc biệt của ca sử dụng tổng quát. Quan hệ mở rộng giữa hai ca sử dụng
được biểu diễn bằng mũi tên đứt nét nối giữa hai ca sử dụng hướng vào ca sử dụng
được mở rộng và ký pháp khuôn mẫu “extends” ở bên cạnh.[2]

19



Hình 2.14: Quan hệ mở rộng

Quan hệ tổng quát hoá: Khi một số các ca sử dụng kiểm soát các chức năng
tương tự nhau có liên hệ với nhau theo một cách nào đó, chúng có thể được gói lại
thành một gói trong UML. Các nhóm gói liên hệ với các phần tử mô hình, có thể được
mở rộng hoặc thu bớt lại thành một biểu tượng, cho phép người phát triển nhìn một gói
tại một thời điểm. Gói không mang ý nghĩa nào khác, nó chỉ một tập hợp các ca sử
dụng có các chức năng tương tự hoặc có các liên hệ với nhau.
Quan hệ sử dụng (uers): là một quan hệ tổng quát hoá mà trong đó một số ca sử
dụng có cùng những ứng xử chung, thì phần chung này được tách thành một ca độc lập
và các ca sử dụng ban đầu chứa nó bây giờ sẽ “sử dụng” nó. Người ta dùng mũi tên với
hình tam giác rỗng để nối từ mỗi ca sử dụng đến ca sử dụng chung được sử dụng và
trên mỗi mũi tên này ghi thêm chữ “users”. Khi một ca sử dụng “sử dụng” ca sử dụng
này nó cần phải sử dụng “đầy đủ”, tức là mọi chức năng của nó. Tuy nhiên không đòi
hỏi các chức năng đó được “sử dụng” theo một trật tự xác định nào[7]
c. Các quan hệ giữa các lớp:
Các lớp và các đối tượng cùng với biểu đồ lớp, biểu đồ đối tượng cho ta cái nhìn
tĩnh về hệ thống. Khía cạnh động hay ứng xử của hệ thống thể hiện qua sự hợp tác của
một tập hợp các đối tượng. Trong hệ thống, một đối tượng luôn luôn có các mối quan
hệ với các đối tượng khác. Vì vậy, khi mô hình hoá hệ thống ta không chỉ mô hình các
đối tượng mà còn phải mô hình hoá quan hệ các đối tượng đó với các đối tượng khác.
UML cung cấp một số loại quan hệ chính như sau
d. Quan hệ liên kết (Assocition):
Trong UML, liên kết là một quan hệ giữa hai lớp để xác định xem các đối tượng
của các lớp này được liên kết và thực hiện công việc cùng nhau như thế nào. Giữa các
đối tượng thuộc các lớp khác nhau phải có sự liên kết để chúng có thể tương tác và
công tác với nhau nhằm thực hiện các tiến trình.
extends
A
B

20

Quan hệ liên kết mô hình hoá mỗi liên kết ngữ nghĩa giữa các lớp.

Biểu diễn:
Tên liên kết
Ví dụ:
Tham gia
Bản số: Đối với một liên kết giữa hai lớp A và B, một thông tin quan trọng liên
quan đến việc có bao nhiêu đối tượng của lớp A có thể được liên kết với một đối
tượng của lớp B tại một thời điểm. Ta sử dụng lực lượng của A để mô tả thông tin
này.[8]


1

*

1 *
1 10

1,3, 5

Ví dụ: 1 * 1 *

Hình 2.12: Bản số của quan hệ
Quy tắc để xác định các liên kết: Đối với bước phân tích, ta sử dụng quy tắc sau:
- Một quan hệ liên kết hữu ích thường mang một hiểu biết về mối quan hệ mà nó cần.
- Một liên kết quan trọng giữa hai đối tượng phải thoả mãn vai trò cung cấp một
phương tiện cho phép đối tượng này công tác hay tương tác với đối tượng kia
Sinh viên
Thi

A
Không xác định
A
Chỉ một
A
Không hoặc nhiều
A
Một hoặc nhiều
A
Khoảng từ 1 đến 10
A
Hoặc 1, hoặc 3, hoặc 5
Sinh viên
Kỳ thi

21
Các quan hệ liên kết thường được ứng với một động từ hoặc một danh động từ.
Mỗi liên kết thường có một số ngữ nghĩa trong các quan hệ sau:
- Trật tự vật lý: tiếp theo (next to), là một phần của (part of), chứa trong
(contained in),…
- Hành động định hướng: lái (drive),…
- Tương tác: nói tới (talk to),…
- Sử hữu: có (have), là một phần của (part of),…
- Hoặc thoả mãn điều kiện: làm việc cho (work for), quản lý (manage),…
Quan hệ giữa liên kết và cài đặt: Trong bước phân tích, một quan hệ liên kết
không phải là một phát biểu về dòng dữ liệu và các biến đối tượng hay các liên kết đối
tượng trong giải pháp phần mềm. Quan hệ liên kết có thể được cài đặt bằng nhiếu cách,
nhưng các quyết định đó không thực hiện trong bước phân tích để đảm bảo tính tự do
của thiết kế sau này.
Khi tạo ra một mô hình khái niệm, ta có thể định nghĩa nhiều quan hệ liên kết

không cần thiết cho quá trình xây dựng. Ngược lại, có thể phát hiện các quan hệ liên
kết cần thiết cho cài đặt nhưng không có trong pha phân tích. Trong các trường hợp đó,
mô hình khái niệm phải được cập nhật lại.


e. Quan hệ kết tập (Shared Aggregation)[6]
Quan hệ kết tập là một dạng đặc biệt của quan hệ liên kết, biểu diễn mối quan hệ
toàn thể – bộ phận. Nếu như quan hệ liên kết giữa hai lớp chỉ ra một mối quan hệ
mang tính cấu trúc giữa hai thành phần ngang hàng, có nghĩa là cả hai lớp ở cùng một
cấp độ, không lớp nào quan trọng hơn lớp nào. Đôi khi chúng ta muốn mô hình hoá
một đối tượng toàn thể và các thành phần của nó, chẳng hạn ta muốn thể hiện Sinh
viên là thành viên của lớp học, hay các khoa là các bộ phận của một trường. Kiểu quan
hệ này gọi là kết tập, thể hiện mối quan hệ “có”, “chứa trong”, “bao gồm”, “là một
phần của”.