Ngôn ngữ UML và ngôn ngữ SDL

Đ Ạ I H Ọ C Q U Ố C G IA H À N Ộ I
KHOA CÔNG NGHỆ
TRỊNH THỊ THUÝ GIANG
NGÔN NGỮUML VÀ NGÔN NGỮ SDL
Chuyên ngành: Công nghệ thông tin
M ã số:
LUÂN VÃN THAC SỸ KHOA HOC
Người hướng dản khoa học:
PGS Nguyễn Quốc Toản
Ị V õ
Ỉ-Õ J
;
H à N ội, năm 2001
MỤC LỤC
\1 ỊX IẠiC： 2
PHÂN 1 4
Cơ SO THỰC TĨỀN CÜA ĐỂ T À I
4
PHẤN II 6
(ÎK)
丨
THIỆU VỂ N(ỈÔN NGỮUML 6
I. Lịch sử ra đời 6
II. Khái quát về U M L 6
2.1. Báng từ vựng trong UML: Gồm 3 khối chính 8
2.2. Các luật và các cơ chế trong Ư M L : 16
2.3. Các khung nhìn (V iew) trong U M L :
.

19
2.4. M ò hình hoá với U M L

20
PHẨN 丨I I

27
NGÔN N(；ỮĐẶC TẢ SDL CHUẨN c ủ a ISO 27
I. Lịch sử phát triển và các phạm vi ứng dụng của SDL
27
II. Tổng quát về S D L 28
2 .1 • Các thành phần của S D L 28
2.2. Mô hình chung của SDL (General Model of SDL) 32
2.3. Các luật thông thường (General Rules) 34
2.4. Structure (cấu trúc) 36
2.5. Hành vi (Behaviour) 39
PHẨN IV 44
SO SÁNH VẢ CHUYỂN Đổi (ĨĨỮA UML VÀ SI)L 44
I. So sánh giữa U M L và SDL 44
1.1. Tổng quát 44
1.2. Phát tricn phần mềm dựa trên U M L và SDL 46
II. Chuyên đổi từ U M L sang SD L 48
2.1. Ánh xạ các biểu đồ lớp từ U M L sang S D L 48
2.2. Ánh xạ các biêu đổ trạng thái (Statcchart Diagram)
53
2.3. Ánh xạ biếu đồ tuần tự (Sequence Diagram) 54
III. Dịch từ SDL sang U M L 54
3.1. Cách tiếp cận 54
3.2. The Rational Rose RealTime U M L Profile 56
3.3. Mô hình hoá cấu trúc (Structure Modeling)

61
3.4. Mô hình hoá hành vi (Behavior Modeling)

67
PHẤN V 75
MỘ ! SỐ VÍ DỤ MINH HOẠ 75
i. Ví dụ dịch chuyển từ UML sang S D L 75
1.1. Chuyển dịch các cấu trúc tĩnh (Static structure) - Biểu đồ lớp

75
1.2. Biểu đồ trạng thái (State Diagram )

77
II. Dịch chuyển từ SDL sang U M L 77
PHẨN V I 80
KẾT LU Ậ N 80
TÀ
丨丨
JỆU THAM KHẢO 82
PHẦN I
C ơ SỞ THỤC TIỄN CỦA ĐỂ TÀI
Hiện nay trcn thế giới, cồng nghiệp phần mềm đang bùng nổ và phát
triển mạnh mẽ, các nhà phát triển phần mềm gọi đây là những "cơn sốt phần
mểm". Những cơn sốt phần mềm này là do trên thực tế có nhiều dự án phần
mém đã bị đổ vỡ hoặc là nó vượt quá thời gian, ngân sách cho phép. Chính vì
vậy mà lập trình hướng đối tượng, lập trình ảo đã ra đời giúp cho việc phát
tricn Cổng nghiệp phần mểm. Phấn ỉ ớn các dự án phần mcm khi được thực
hiện
người la thường bát tay vào việc viết mã chương trình (code). Đối với các
hệ thống lớn và phức tạp thì điều này gây ra rất nhiều khó khăn trong quá
trình phát triển phần mềm. Các dự án phần mềm sẽ trở nên khó thực hiện khi
các nhà lập trinh gặp khó khăn trong việc viết mã chương trình.
Các nhà lập trình cảm thấy chắc chắn hơn khi họ viết một chương trình

mà hệ thống cần tạo lập đã được mô tá trước bời một mồ hình irừu tượng. Mô
hình thông Ihường được xây dựng bằng một ngôn ngữ ảo, có nghĩa rằng hầu
hết các thông tin trong mô hình được đưa ra bởi các biểu tượng và mối quan
hệ giữa chúng. Người ta thường nói: “ Một bức tranh bằng trăm nghìn lời nói” ,
điểu này giống như việc mô hình hoá.
Lập trình hướng đối tượng ra đời vào giữa những nãm bảy mươi đến cuối
những năm tám mươi những ngôn ngữ lập trình hướng đối tượng mới ra đời và
được mớ rộng trên các ứng dụng phức tạp, ban đầu chỉ mới là các tiếp cận cho
giai đoạn phân tích và thiết kế. Có quá nhiều các phương pháp hướng đối
tượng được đưa ra vào những nãm từ 1989 đến 1994. Khi lập trình hướng đối
tượng trơ nèn phổ biến, nó đòi hỏi phiìi có những phương pháp trợ giúp cho
phát triến phần mềm. Trước những vấn đề nêu ra ở trên, một số nhà phát triển
phần mcm đã kết hợp cùng với nhau để đưa ra một ngôn ngữ mô hình hoá
thống nhấl í rợ giúp cho lập trình hưởng đối tượng, với mục đích là tạo ra được
một ngôn ngữ có thể mô hình cho tất cá mọi thứ kể cả những cái không phải là
phần mém, Trong khuôn khổ cua luận án này tôi xin được trình bày về
ngôn ngữ mô hình hoá thống nhất UM L (Unified Modeling Language) và so
sánh nó với một ngôn ngừ đặc tả trước đó.
PHẦN II
GIỚI THIỆU VỂ NGÔN NGỮUML
(UNIFIED MODELLING LANGUAGE)
I. LỊCH SỬ RA ĐỜI
Năm 1994 hai nhà phái triển phầm mềm hướng đối tượng Grady Booch
và James Rumbaugh đã kết hợp cùng nhau xây dựng UM L tại công ty phần
mềm Rational. Version 0.8 của Unified Method ra đời vào 10/1995, nó là
phương pháp mởi dựa trẽn phương pháp của Booch và OTM (Object Modeling
Technique) của Rumbaugh. Cùng thời gian này Ivar Jacobson gia nhập
Rational và dự án U M L đã dược mở rộng nó kết hợp thêm phươnc pháp OOSE
(Object-Orient Software Engineering), U M L version 0.9 ra đời vào tháng
06/1996 [3]. Phương pháp của Booch chủ yếu thực hiện trong giai đoạn thiết

kẽ và xây dựng các dự án. OOSE cung cấp sự trợ giúp cho các use case để
nắm bắt các yêu cầu, phân tích, thiết kế ở mức cao và OTM được dùng trong
quá trình phân tích và tập trung vào các hệ thông tin dữ liệu.
Version 1.0 của UM L được đưa ra năm 1997. về cơ bản ƯM L dựa trên
Booch. OMT, OOSE nhưng họ cũng kết hợp một vài ý tướng của các phương
pháp khác như StatcCharts của David Harel và chuyển nó thành biểu đồ trạng
thái (Stale Diagram) trong UM L. Sử dụng thao tác đánh dấu trong chú thích
cua Fusion trong biểu đồ cộng tác (collaboration diagram) [4].
II. KHÁI QUÁT VÊ UML
UM L là một ngôn ngữ mô hình hoá, nó là một ngôn ngữ đã được nhiều
công ty coi là chuẩn đê xây dựng các bản thiết kế cho phần mềm.
- Các khái niệm của UM L cho phép xây dựng được các hệ thống mô
hình (kể ca không phải phẩn mềm) sử dụng khái niệm hướng đối tượng.
- UM L thiết lập dược mối quan hệ rõ ràng giữa các khái niệm bới các
thực hiện giả.
- UML tạo ra một ngôn ngữ mò hình hoá mà có khả năng được sử dụng
hứi Cii con người và máy móc.
Khi thiết lập UML, những nhà phát triển của Rational thực sự muốn tạo
ra một ngòn ngữ mà có giá trị cho tất cả các nhà phát triển phần mềm. Ngôn
ngữ này không độc quyển sử dụng mà nó có lính chất mở cho tất cả các công
ty. Các cồng ty có thể tự do sử dụng nó cùng với các phương pháp, công cụ
riens của họ đê tạo lập ra những bộ công cụ CASE cho nó.
UM L Là ngôn ngữ mô hình đê thực hiện mọi chức năng của hoạt động
làm phần mềm: Làm trực quan lioá (visualizing), đặc tả (specifying), xâỵ
dựng (constructing), làm tải liệu (documenting) cho thiết kế phần mềm. Như
vậy, UM L về cơ bán định nghĩa một siêu mô hình và không mô tả "kỹ thuật
phát triển".
UM L trợ giúp cho cả 5 giai đoạn trong phát triển hệ thống:
■ Phán tích yêu cầu: ƯM L có các khái niệm tính huống sử dụng (use
case) dùng để nắm bắt các yêu cầu của khách hàng. Thông qua mô hình use-

case, các tác nhân bên ngoài tham gia vào hệ thống được mô hình cùng với
các chức năng mà nó đòi hỏi từ hệ thống. Mỏi use-case mô tá cho một tập các
chuỗi tuần tự các hành động mà một hệ thống thực hiện và cho một kết quả có
thể quan sát được là giá trị cho một tác nhân.
■ Phân í ích: Giai đoạn phân tích liên quan tới các lớp, các đối tượng và
các cơ chế được mô tả trong phạm vi của một vấn đề. Trong UM L có các biểu
dồ lớp (Class Diagram) để mô tả các lóp và mối quan hệ giữa chúng.
■ Thiết kế: Trong giai đoạn thiết kế, kết quả của phân tích được mở rộng
thành một giải pháp kỹ thuật.
_ Lập Ịrìnlĩ
：
Trong giai đoạn lập trình hoặc xây dựng, các lớp trong pha
(phase) thi ci kế được chuyến thành mã chương trình (codc) trong một ngôn
ngữ lập trình hướng đối urợng. UML có các khái niệm cho phép xây dựng các
ngôn ngữ trợ giúp cho kỹ thuật dịch một mô hình thành mã chương trình và
ngược lại.
■ Kiểm tlìír. U M L sử dụng các biểu đồ cho các loại kiểm thử (lest): biểu
dồ lớp và đặc tả lớp dùng cho unit tests; biểu đồ thành phần (component
diagram) và biêu đổ cộng tác (collaboration Diagram) dùng cho integration
lests; biếu đồ tình huống sử dụng (use-case diagram) dùng cho system tests,
Trong ƯML có 3 phần tử chính: Các Building blocks, các luật để có thể
gắn kết các Building blocks và một số cơ chế mớ rộng. Nó bao gồm bảng từ
vựng (ate biểu Irưng đổ thị), các cú pháp (nguyên tắc để xây dựng mô hình)
2.1. Bảng từ vựng trong Ư M L: (ỉồm 3 khối chính
- Các sự vật (things): Gồm 4 nhóm chính:
1. Sự vật có cấu trúc (structural things): Biểu diễn các phần tử vật lý
hay các cấu trúc tĩnh: Lớp, giao diện, sự cộng tác (collaboration),
usc-case, lớp hoạt động (class active), thành phần, nút (node).
[9J
Student

{persistent}
oname : Name
ostudentlD : Number
Chain of
Responssibilily
ISpelling
Classes
Interfaces
Collaborations
EventManager
♦suspend()
^flushO
orderform
java
Placeorder
Use cases
Active Classes
Com none n! s
Server
Nodes
Các sự vật được mỏ tả trong Rational Rose [10]
2. Sự vật hành vi (behavioral things): Biểu diễn hành vi trong không
gian, thời gian, là phần động của hệ thống: Sự tương tác (bao gồm
các phẩn tử, các message, dãy các hoạt động và các kết nối giữa
các đối tượng), máy trạng thái.
Displav

-
^
Messages

3. Sự vật nhóm gộp (Grouping things): Là phần tổ chức của UML:
Có 1 kiểu thành phần nhóm gộp duy nhất trong UM L là hao gói
(packets). Có các biến thể của bao gói: Các Frame work, model,
Subsystem.
: .j i

Business
Rules
Packages
4. Sự vật chú dẫn (annotational things): Là phần giải thích trong
ƯML. Đó là những bình luận, chú thích để giải thích, minh hoạ
hay nhấn mạnh về một phần tử bấl kỳ nào đó trong mô hình gọi
là: ghi chú (note).
return copy of
self
States
Notes
-10-
Củc quaìì hệ (Relationships): Gồtn 4 loại:
1. Phụ thuộc (dependence): Là mối quan hệ ngữ nghĩa giữa 2 sự
vật, trong đó sự thay đổi của một vật có thể tác động lên sự thay
đổi ngữ nghĩa của vật kia.
ClassA : ClassB
2. Kết hợp (assosiation): Là một mối quan hệ cấu trúc mô tả một
tập các mối liên kết đang kết nối các đối tượng với nhau.
n .
Member of
0 .
Politician Party
3. Khái quát hoà(generalization): Là 1 mối quan hệ tổng quát hoá

hay chuyên biệt hoá, trong đó các đối tượng của phần tử chuycn
biệt hoá (con) được thay thế cho các đối tượng của phân tử được
tổng quát hoá (cha).
Person
Man Woman
二
4. Sự hiện thực hoá (realization): Là một mối quan hệ ngữ nghĩa,
Irong đó mội phân loại xác định một hợp đồng mà một phân loại
khác phái đám báo thực hiện nó. Có loại:
■ Giao diện - các lớp, các thành phẩn
■ Sử dụng tình huống - sự cộng lác
- Cík bien dồ (Diagrams): Biểu diễn các phần tử cúa một hệ thống.
Trong UML có các dạng biểu đổ khác nhau, bản thân các hiểu đồ thì lại bao
góm các phần tử đồ hoạ khác nhau. Biêu đổ trong UM L có thể mô (ả cả hai
khía cạnh động và tĩnh cúa hệ thống.
• Các biểu đồ tĩnh (Static Diagrams): Có 3 loại biểu đồ tĩnh
1. Biểu đồ lớp (Class diagram ): Biểu đồ lớp là quan trọng nhất và là
một biểu đồ chung nhất của UML. Có thể sử dụng nó ớ hầu hết
mọi nơi. Biếu đồ lớp nhìn hệ thống theo hướng phân tích, thiết kế
và thực hiện. Biểu đồ lớp chi 1 tập các lớp, các giao diện và các
sự công tác và các mối quan hệ của nó.
Company 1
1
Department
■ ^>name : Name
0 1
Location
Office
^a d d ress : string
^v o ic e : Number

member
Person
I ^ n a m e : Name
^em ployeelD : Integer
务title : String
^getPhotoO
^getSoundBiteO
^getContactlnformation()
^getPersonalRecordsO
generalization
Headquarters
Contact 丨 nformation
I ^a ddre ss : string
dependency
f —
-


- ； .丨
Personnel Records
^taxlD
»ậ>empỉoy mentHistory
冬
salary
ISecurelnfor
(nation
2. Biểu đổ thực hiện (implementation Diagram): Nhìn hệ thống theo
hướng phân tích và thiêì kế. Biểu đồ thực hiện mô tá cấu trúc phần
cứng và phần mềm của hộ thống. Trong U M L có hai loại biểu đồ
thực hiện:

^ Biếu đồ thành phần (Component diagram): Chí ra các tổ chức
và các phụ thuộc trong tập các thành phần, liên hệ với các sơ
đồ lớp trong đó một thành phần ánh xạ vào 1 hay 1 số các lớp,
các giao diện hoặc các cộng tác. Biểu đổ thành phần kết nối
giữa các modul phần mềm khác nhau.
Ị ~ '— Ị "page"
I home.htm I
"document"
animiogo.doc
.•file"
animator, java
□ Z D
"document"
animator.doc
y Biểu đồ triển khai (Deployment diagram): Chỉ ra cấu hình
của các nút xử lí thời gian thực và các thành phần hoạt động
trên nó. Chỉ ra cấu trúc vật lý của hệ thống.
Biểu đổ triển khai cho hệ thống báo động nhà.
2. Biểu đồ đối tượng (Object diagram): Chỉ một tập các đối tượng
và các mối quan hệ của chúng - nhìn hệ thống theo quan điểm
tiến trình ->làm mầu.
c:company
d1:department
: d2:Department :
(name = ,rsalen
i —

I
1 砍name = "R&D"1
I

: :
::::
1
d3:Department
^name = "US Sales"
p: person
<name = "exin"
Các biểu đồ động (Behavioral Diagrams)
1. Biểu đồ tình huống sử dụng (Use case diagram): Nhìn hệ thống
theo hướng phân lích, thiết kế và kiểm thử. Chỉ ra sự tương tác
giữa các tác nhân và hệ thông. Ví dụ về biểu đồ use-case xây
dựng cho hệ Ihống quán lý thư viện.
-14-
Borrowers
AddTitle
MakeReservation
Update&RemoveTitle
Ad dltem
RemoveReservatỉon
L
Remo veltem
Lendltem
AddBorrower
Retu rnltem
RemoveBorrower
ỉbrarians
2. Biểu đổ tương tác (Interaction Diagram): Nhìn hộ thống theo
hướng phân tích, thiết kế và thực hiện. Biểu đồ tương tác chí ra
các luống thông điệp giữa các đối tượng và hành vi thời gian của
hệ thống. Trong UM L có hai dạng biểu đổ tương tác:

^ Biểu đồ tuần tự (Sequence diagram): Cấu trúc hướng thời gian
với một số ít các lớp. (Biểu đồ tuần tự change message)
CliangctCustomerData) .Custom erW indow -Customer
_ _ i

—

^
UpdateCustom er((Custom erData))
>
<
^ Biểu đồ cộng tác (Collaboration Diagram): Cáu trúc hướng
thời gian với một số ít các thông điệp. Một ví dụ về hiểu đồ
cộng tác thực hiện chức năng trả lời của thủ thư khi có người
yêu cầu mượn không đặt trước.
.Librarian Lending ;Title :Borrowerlnfo .Loan :ltem
W indow
1 findT丨tie 2 find (string)
4 find on Title
>
<
3: findltemO
>
5 IdentifyBorrowerO
>
6: find(string)
>
7 Create(Borrlnfo, Item)
>
3. Biểu đồ trạng thái (State diagram): Nhìn hệ thống theo hướng

phân tích, thiết kế và thực hiện. Chỉ ra 1 máy trạng thái mô tả
các hành vi động, bao gồm các trạng thái, các chuyển đổi, các sự
kiện và các hoạt động:
^ Là cách nhìn HT theo quan điểm động.
^ Đặc biệt quan trọng khi mô hình hoá hành vi của 1 giao diện,
1 lớp hoặc một cộng tác
y Nhấn mạnh hành vi được sắp theo sự kiện.
#

> On 1st GoUp (floor) Moving up
floor do/moving to floor
Arrived
GoUp(floor)
arrived Moving down arrived Idle
do/moving to floor
GoDown(floor)
Moving
1st floor
4. Biểu đồ hoạt động (Activity Diagram): Nhìn hệ thống theo
hướng phân tích, thiết kế. Biểu đồ hoạt động là một dạng đặc biệt
của biểu đồ trạng thái. Sử đụng đầy đủ hoặc chỉ ra các tiến trình
song song.
Sampler.Run (channel, frequency) Initiate
Updating Measuring
Display
2.2. Các luật và các cơ chẽ trong UML:
/. Cúc luật ngữ nỊịhĩa chiiìỉg:
° Tèn gọi (Name)
0 Pliạm vi (Scope)
Tính nhìn Ihấv (Visibility)

0 Tính toàn vẹn (Intergrily)
0 Tính hành xử (execution)
2. Các nguyên tắc xây dựng mô hình:
° Lược bỏ: Một số phần tử có thổ dấu đi để làm đơn gián khung
nhìn
0 Tính không đầy đủ: Một số phần tử có thể bỏ qua
° Sự không chắc chắn: Tính chắc chắn của mỏ hình không đảm bảo
3. Các cơ cliếchn/ỉiị
：
■
C ác c ơ chê c h u n g ( G e n e ra l M e ch a n ism s ):
° Các đặc tả (Specifications): Sau mỗi ký hiệu đổ thị là một đặc tả
cung cấp 1 phát biểu bằng lời về cú pháp và ngữ nghĩa cúa khối xây
dựng. Cách đặc tả này làm đầy đủ ngữ nghĩa cho mọi phân tử hệ thống
nếu cần. Trong các công cụ được xây dựng theo cơ chế của UM L để xem
đặc tả của mỗi phần tử kích đôi vào biểu lượng phần tử sẽ hiện lên một
cửa sổ đặc tả của nó.
° Các bài trí (Adornments): Hầu hết các phần tử trong U M L có
biểu trưng (Symbol) đổ thị duy nhất cung cấp một trình diễn trực quan
theo một khía cạnh quan trọng của sự vật. Ví dụ, một lớp hình chữ nhật
với tên bồi đậm miêu tả cho một lớp và tên gạch dưới miêu tả cho một
dối tượng.
c lass Printer
° Phàn chia chung (Common division): Trong mô hình, m ọi thứ dcu
được phân chia ít nhất thành một cặp các cách thể hiện có ngữ nghĩa
bố sung tương phán nhau: lớp - đối tượng, Giao diện - sự cộng tác,
Giao diện - sự thực hiện.
■
C ác c ơ ch ê có k h ả m à rộ n g ( e x te n s ib ility m e c h a n is m s ):
ƯML là ngôn ngữ mờ: cung cấp một cách thức mở rộng có kicm

soát: Bao gồm:
° Khuôn mẫu (Stereotype) mở rộng bảng từ vựng của UML: Cho
phép tạo loại lừ vựng mới từ những cái đã có. Một khuôn mẫu giống như
một từ vựng đã có, cộng thêm mộl số ngữ nghĩa phụ hoạ mà không có
trong từ vựng ban đầu. Khuôn mầu có thế áp dụng cho tất cả các dạng:
Lớp, nút, thành phần, và ghi chú. Ví dụ một lớp Customer với nguyên
mẫu « A c to r » để mở rộng các user của hệ thống .
« A c t> >
C ustom er
Customer Customer
° Giá trị thẻ (tagged value) mở rộng thuộc tính của ƯM L cho phép tạo
thông tin mới trong đó có đặc tả phần tử.
Ịnsirunìent
{Abstract}
{author=“ Mai” |
[Statusfsinglcj
value: Int
-19-
c Các ràng buộc (Constrains) mớ rộng ngữ nghĩa của khối được xây
dựng, cho phép thêm các luật mới hay cải biên luật hiện có.
Senior Citizen Group
{ person.age>60 Ị
o n
Person
Các đặc trưng của ƯML cho phép mọi thành phần liên quan đều có the
mang vào trong kiến trúc dự án cách nhìn khác nhau làm cho dự án có được
một sự hoàn thiện tổng thể.
2.3. Các khung nhìn (View) trong UML:
View chí ra các khía cạnh khác nhau của hệ thống được mô hình. Một
view không phái là một mô tá đồ họa mà nó bao gồm một số lớn các biểu đồ

trừu tượng. Tổng hợp tất cá các View cho chúng ta một cái nhìn tổng quan về
hệ thống. Trong U M L có 5 loại View: use case view, design view, process
view, implementation view, deployment view.
chức năng quản lý cấu hình
Use case
Process view
Design view
hành vi
hiệu năng, quy mô vận hành
hình trạnẹ hệ thốrm, phân
bố,lắp đạt
- Uses case view bao gồm các use case mô tả hành vi của hệ thống
được xem bởi các user của nó, phán tích và kiểm thử. View này
không chỉ rõ tổ chức của một hệ thống phần mềm. Trong UM L khía
cạnh tĩnh của View này thể hiện trong các biểu đổ use case còn khía
cạnh động thể hiện trong các biểu đồ tương tác, biểu đồ statechart và
các biểu đồ hoạt động.
- Design view bao gồm các lớp, các giao diện và các cộng tác. View
này chủ yếu trợ giúp cho các yêu cầu chức năng của hệ thống, có
nghĩa ià các dịch vụ mà hệ thống sẽ cung cấp cho các user của nó.
Với UM L mặt tĩnh của View này thể hiện trọng các biểu đồ lớp và
biểu đổ đối tượng; mặt động thể hiện trong các biểu đồ tương tác,
biểu đồ trạng thái và biểu đổ hoạt động.
- Process view bao gồm các dòng (thread) và các tiến trình (process),
trong đó có các cơ chế lương tranh và động bộ của hệ thống. View
này chủ yếu nhằm vào sự thực hiện, khả năng và các tiến trình của hệ
thống.
- Ỉmplcmentaỉion view bao gồm các thành phần và các file mà được sử
dụng để tập hợp và đưa ra hệ thống vật lý. View này chủ yếu tập trung
vào việc quán lý cấu hình của hệ thống đưa ra.

- Deployment view bao gồm các node mô lả yêu cầu phần cứng khi hệ
thống thực hiện. Nó chí ra việc triển khai hệ thống trong 1 kiến trúc
vật lý có dùng máy tính và các thiết bị (các nút). Nói cách khác là nó
mồ tả việc triển khai vật lý của hệ thống. View này dành cho người
phát tricn. tích hợp và kiểm thử.
2.4. Mô hình hoá với UML
Khi xây dựng một hệ thống sử dụng U M L thì không chỉ là việc xây dựng
một mô hình đơn gián mà có rất nhiều mô hình trong các pha (phase) khác
nhau của quá trình phát triển và mục tiêu của các mô hình cũng khác nhau.
Trong pha phân tích, mục tiêu của mô hình là để nắm bắt các yêu cầu của hệ
thốn2 và đổ mô hình các lớp cơ bán vé thế giới thực và các sự cộng tác. Trong
pha thiết kế mục tiêu là để mở rộng mô hình, đưa mô hình vào một giải pháp
kỹ thuật thực hiện công việc trong môi trường thực hiện. Trong pha thực hiện,
mò hình là các mã nguồn thực sự mà theo hình thức đã được lập trình và biên
dịch vào chương trình. Cuối cùng trong mô hình triển khai là các mô tá giải
ihích làm thế nào để hệ thống triển khai trong cấu trúc vật lý. Sự thay đổi givra
các pha và các mô hình là dược duy trì qua các tính chất và các mối quan hệ
xác định trước giữa chúng.
U M L có khái niệm pha độc lập, có nghĩa rằng cùng một ngôn ngữ, cùng
các biểu đồ được sử dụng đế mô hình cho các thứ khác nhau trong các pha
khác nhau, nó phụ thuộc vào người mô hình hoá quyết định chọn mục tiêu và
phạm vi của m ô hình.
/•
C ác c ô n g c ụ (T o o ls)
Các công cụ cung cấp các chức năng sau:
- Draw diagrams: Các công cụ phải giúp biểu diễn dễ dàng các bicii đồ
trong ngôn ngữ mô hình hoá.
- Act as a repository: Công cụ phải trợ giúp một kho chứa chung cho
các thông tin của mô hình để có thể tự lưu vào một vị trí. Nếu tên lớp
mà thay đổi thì phải có sự thay đổi tương ứng trong tất cả các biểu đồ

có sử dụng lớp đó.
- Support navigation: Phải dỗ dàng liên kết giữa các mô hình, để tìm ra
một phần tử từ một biểu đồ hoặc biểu đồ khác hoặc mở rộng mô tả
của phần lử.
- Provide multiuser support: Phải trợ giúp cho nhiều user và chúng có
khá năng làm việc trên cùng một mô hình mà không gây phicn phức
và rối loạn cho nhau.
- Generate code: Một công cụ nâng cao có khả năng dịch ra mã chương
trình, tất cả các thông tin trong mô hình được dịch thành bộ khung mã
chương trình là cơ sở cho pha thực hiện.
- Reverse engineer: M ột mô hình có thể được tạo ra từ một mã chương
trình đã tồn tại.
- Integrate with other tool: Một công cụ có khả năng tích hợp với các
công cụ khác, với môi trường phát triển như là một người soạn thảo,
biên dịch, gỡ lồi và với các công cụ để quán lý cấu hình, quản lý các
hệ thống điều khiển.
- Cover the model at all abstraction levels: Dễ dàng đi từ mô tá ở mức
cao nhất của hệ thống (các package) đến mức thấp nhất là mã chương
trình.
- Interchange models: M ột mô hình hoặc một biểu đồ riêng của mô
hình có khả năng xuất ra một công cụ và nhập vào một công cụ khác.
2 . T rợ g iú p c h o k ý h o ạ ( D ra w in g S u p p o rt)
Một công cụ phải tạo ra các biêu đồ một cách dễ dàng và nhanh chóng.
Công cụ không chi thực hiện việc lựa chọn, xác định vị trí, kết nối và định
nghĩa các phẩn tử trong biểu đồ mà nó còn phải trợ giúp cho người mô hình có
được một biểu đồ đúng.
3. Kho lưu giữ của mô hình (M odel Repository)
Công cụ CASE phải có một kho lưu giữ mô hình cung cấp một cơ sở dữ
liệu với tất cả các thông tin về các phần tử sử dụng trong mô hình, (không chú
ý tới thông tin của biểu đổ đến từ đâu) và các nhiệm vụ mà công cụ có thể

thực hiện với sự trợ giúp của kho lưu giữ:
- Kiểm tra tính không vững chắc (Cheeking lor inconsistency): Nếu
một phần tử là được sử dụng không nhất quán trong các biểu đồ, công
cụ sẽ thông báo hoặc ngăn cấm. Nếu người mô hình hoá xoá một
phần tử mà nó được sử dụng ở các biếu đồ khác thì sẽ có sự cảnh báo.
- Sự phê phán (Critiquing): Khi mô hình sử dụng thông tin trong kho
lưu trữ, thì một công cụ có thổ phê phán mô hình, chỉ ra những phần
ngoài không được chỉ rõ và áp dụng để tìm ra các lỗi có thể hoặc
những giải pháp không thích hợp.
- Sự trình báo (Reporting): Công cụ cố thể tự động dịch ra hoàn toàn
và mớ rộng tài liệu về tất cả các phần tử như lớp, biểu đồ trong một
mô hình.
- Sự dùng lại các phần tử và các biểu đồ (Reusing elements or
diagrams): Một kho lưu trữ có thể trợ giúp cho việc dùng lại các giải
pháp mô hình hoặc các phần của một giải pháp trong đó một đc án có
thể dễ dàng dùng lại từ một đề án khác. Trong UM L cả mô hình và
mã chương trình đều được dùng lại trong các dự án khác nhau.
4. S ự hướng đạo (Navigation)
Khi một số VIEW và biểu đồ được sử dụng cùng với nhau để mô tả một
hệ thống, thì khi đó vấn để vô cùng quan trọng là việc kết nối truyền thông
giữa chúng. Các công cụ phải trợ giúp cho việc truyền thông qua các View và
các hiếu đồ một cách dỗ dàng.
5. Trợ
g iú p c h o đ a
người dùng (Multiuser Support)
Một công cụ có the cho phcp một số user cùng làm việc trên một mô
hình mù không nhiễu hoặc gây phiền phức cho nhau.
6. S in h ra m ã c h ư ơ n g trìn h (C od e g e ne ra te )
Các công cụ hiện đại có trợ giúp cho việc sinh ra mã chương trình. Phần
này được thực hiện từ giai đoạn mô hình và không được lặp lại khi giai đoạn

thực hiện bắt đầu. Những mã chương trình được sinh ra là những thông tin tĩnh
và các khai báo lớp bao gồm các thuộc tính và các khai báo về các phương
pháp. Thân của các phương pháp chứa đựng các mã chương trình thực sự,
phần này sẽ do người lập trinh thực hiện.
Thông thường, các ngôn ngữ ỉập trình hướng đối tượng như c ++ hoặc Java
dược sử dụng để viết mã chương trình cho các mô hình được sinh ra mã từ
những ngôn nsữ đặc tá dựa theo các khái niệm của UM L, những ngôn ngữ
như SQL hoặc 1DL cũng có ihc được dùng.
7. Kỹ thuật sinh từ code ra mở hỉnh (Reverse Engineering)
Chức năng sinh từ code ra mô hình là đối lập với chức năng sinh từ mô
hình ra code (code generation). Mã chương trình được đọc và phân tích bởi
công cụ và các biểu đồ được chỉ ra cấu trúc của mã chương trình. Các cấu trúc
biếu đồ tĩnh là các biểu đồ lớp được xây dựng từ mã chương trình: Thông tin
tĩnh đưực trích ia từ mã chương trình.
8. S ụ tíc h h ọ p (In te g ra tio n )
Các công cụ mô hình truycn thống trớ nên thích hợp hơn với các công cụ
khác sử dụng trong phát triển hệ thống.
- Môi trường phát triển: Với các công cụ này nó có thể đi trực tiếp từ
một mô hình phần tử trong một biểu đồ đến một môi trường phát
triển, ở đó mã chương trinh được lập, sửa chữa và gỡ lỗi.
- Câu hình và điểu khiển version: Các công cụ này cung cấp một vài
CUU hình khác nhau của hệ thống và các version khác nhau của cả hệ
thống và các phần tử riêng lẻ. Version-control được dùng cho cả mô
hình và mã chương trình.
- Các công cụ làm tài liệu (Documentation tools): Các công cụ này có
thê tự động dịch ra tài liệu từ kho lưu giữ mô hình.
- Các công cụ kicm thử (Testing lools): Các công cụ kiếm thử là chủ
yếu dùng cho sự quản lý các tiến trình kiểm thử - sự lựa chọn và duy
Irì các báo cáo kiểm thử. Sự kiểm thử thực sự là sự xác nhận (Chúng
ta đã xây dựng tốt hệ thống chưa?) và sự thẩm tra (Chúng ta đã xây

dựng hệ thống hằng cách tốt chưa?) của quá trình phát triển hệ thống.
- Công cụ xây dựng đồ hoạ (G UI builder
) ：
Có những liên kết từ các lớp
irong mô hình đến các mô tả đồ hoạ trong một GUT builder, ở đó tổ
chức của giao diện người sử dụng được lưu giữ. Nó có khả năng tự
động sinh ra các dạng đổ hoạ của các lớp trong mô hình.
- Các công cụ đặc tả yêu cầu (Requirement Specification tools): UM L
có các uses case đê nắm bắt các yêu cầu chức năng của hệ thống. Tuy
nhiên, có những yêu cầu phi chức năng của hệ thống và chúng đều có
thể được mô tả sử dụng các công cụ đặc tả yêu cầu.
- Các công cụ quản lý dự án và trợ giúp quá trình (Project management
and process support tools): Một công cụ quản lý dự án được đặt ra để
giúp đỡ cho người quản lý dự án xác định các lịch thời gian, các kế
hoạch phân chia tài nguyên và các thực hiện tiếp theo trên sự phát
triển. Người quản lý dự án có thể dễ dàng kiểm tra được sự phát triển
của công việc mô hình hoá. Sự tích hợp với các công cụ trợ giúp tiến
trình hầu như chắc chắn là không có quyền ưu tiên cao nhất và thông
thường sán phẩm của mô hình là một phần đáng kể của bất kỳ một
phương pháp hoặc một quá trình nào.
9. Sự th a y th ế lẫ n n h a u củ a c ác m ò h ỉn h (in te rc h a n g e m o d e ls)
Khổng dễ dàng có thể tạo ra một mô hình bằng một công cụ rồi sau đó
đưa nó vào một công cụ khác. Điểu kiện đầu tiên là phải chuẩn hoá mô hình