|
UML đưa ra khái niệm Use Case để nắm bắt các yêu cầu
của khách hàng (người sử dụng). UML sử dụng biểu đồ Use case (Use Case Diagram)
để nêu bật mối quan hệ cũng như sự giao tiếp với hệ thống.
Qua phương pháp mô hình hóa Use case, các tác nhân (Actor)
bên ngoài quan tâm đến hệ thống sẽ được mô hình hóa song song với chức năng mà
họ đòi hỏi từ phía hệ thống (tức là Use case). Các tác nhân và các Use case
được mô hình hóa cùng các mối quan hệ và được miêu tả trong biểu đồ Use case
của UML. Mỗi một Use case được mô tả trong tài liệu, và nó sẽ đặc tả các yêu
cầu của khách hàng: Anh ta hay chị ta chờ đợi điều gì ở phía hệ thống mà không
hề để ý đến việc chức năng này sẽ được thực thi ra sao.
Giai đoạn phân tích quan tâm đến quá trình trừu tượng hóa
đầu tiên (các lớp và các đối tượng) cũng như cơ chế hiện hữu trong phạm vi vấn
đề. Sau khi nhà phân tích đã nhận biết được các lớp thành phần của mô hình cũng
như mối quan hệ giữa chúng với nhau, các lớp cùng các mối quan hệ đó sẽ được
miêu tả bằng công cụ biểu đồ lớp (class diagram) của UML. Sự cộng tác giữa các
lớp nhằm thực hiện các Use case cũng sẽ được miêu tả nhờ vào các mô hình động
(dynamic models) của UML. Trong giai đoạn phân tích, chỉ duy nhất các lớp có
tồn tại trong phạm vi vấn đề (các khái niệm đời thực) là được mô hình hóa. Các
lớp kỹ thuật định nghĩa chi tiết cũng như giải pháp trong hệ thống phần mềm, ví
dụ như các lớp cho giao diện người dùng, cho ngân hàng dữ liệu, cho sự giao
tiếp, trùng hợp, v.v..., chưa phải là mối quan tâm của giai đoạn này.
Trong giai đoạn này, kết quả của giai đoạn phân tích sẽ được
mở rộng thành một giải pháp kỹ thuật. Các lớp mới sẽ được bổ sung để tạo thành
một hạ tầng cơ sở kỹ thuật: Giao diện người dùng, các chức năng để lưu trữ các
đối tượng trong ngân hàng dữ liệu, giao tiếp với các hệ thống khác, giao diện
với các thiết bị ngoại vi và các máy móc khác trong hệ thống, .... Các lớp
thuộc phạm vi vấn đề có từ giai đoạn phân tích sẽ được "nhúng" vào hạ
tầng cơ sở kỹ thuật này, tạo ra khả năng thay đổi trong cả hai phương diện:
Phạm vi vấn đề và hạ tầng cơ sở. Giai đoạn thiết kế sẽ đưa ra kết quả là bản
đặc tả chi tiết cho giai đoạn xây dựng hệ thống.
Trong giai đoạn xây dựng (giai đoạn lập trình), các lớp của
giai đoạn thiết kế sẽ được biến thành những dòng code cụ thể trong một ngôn ngữ
lập trình hướng đối tượng cụ thể (không nên dùng một ngôn ngữ lập trình hướng
chức năng!). Phụ thuộc vào khả năng của ngôn ngữ được sử dụng, đây có thể là một
công việc khó khăn hay dễ dàng. Khi tạo ra các mô hình phân tích và thiết kế
trong UML, tốt nhất nên cố gắng né tránh việc ngay lập tức biến đổi các mô hình
này thành các dòng code. Trong những giai đoạn trước, mô hình được sử dụng để
dễ hiểu, dễ giao tiếp và tạo nên cấu trúc của hệ thống; vì vậy, vội vàng đưa ra
những kết luận về việc viết code có thể sẽ thành một trở ngại cho việc tạo ra
các mô hình chính xác và đơn giản. Giai đoạn xây dựng là một giai đoạn riêng
biệt, nơi các mô hình được chuyển thành code.
Như đã trình bày trong phần Chu Trình Phát Triển Phần Mềm,
một hệ thống phần mềm thường được thử nghiệm qua nhiều giai đoạn và với nhiều
nhóm thử nghiệm khác nhau. Các nhóm sử dụng nhiều loại biểu đồ UML khác nhau
làm nền tảng cho công việc của mình: Thử nghiệm đơn vị sử dụng biểu đồ lớp
(class diagram) và đặc tả lớp, thử nghiệm tích hợp thường sử dụng biểu đồ thành
phần (component diagram) và biểu đồ cộng tác (collaboration diagram), và giai
đoạn thử nghiệm hệ thống sử dụng biểu đồ Use case (use case diagram) để đảm bảo
hệ thống có phương thức hoạt động đúng như đã được định nghĩa từ ban đầu trong
các biểu đồ này.
Ngôn ngữ UML bao gồm một loạt các phần tử đồ họa (graphic
element) có thể được kếp hợp với nhau để tạo ra các biểu đồ. Bởi đây là một
ngôn ngữ, nên UML cũng có các nguyên tắc để kết hợp các phần tử đó.
Một số những thành phần chủ yếu của ngôn ngữ UML:
Hướng nhìn (view): Hướng nhìn chỉ ra
những khía cạnh khác nhau của hệ thống cần phải được mô hình hóa. Một hướng
nhìn không phải là một bản vẽ, mà là một sự trừu tượng hóa bao gồm một loạt các
biểu đồ khác nhau. Chỉ qua việc định nghĩa của một loạt các hướng nhìn khác
nhau, mỗi hướng nhìn chỉ ra một khía cạnh riêng biệt của hệ thống, người ta mới
có thể tạo dựng nên một bức tranh hoàn thiện về hệ thống. Cũng chính các hướng
nhìn này nối kết ngôn ngữ mô hình hóa với quy trình được chọn cho giai đoạn
phát triển.
Biểu đồ (diagram): Biểu đồ là các
hình vẽ miêu tả nội dung trong một hướng nhìn. UML có tất cả 9 loại biểu đồ
khác nhau được sử dụng trong những sự kết hợp khác nhau để cung cấp tất cả các
hướng nhìn của một hệ thống.
Phần tử mô hình hóa (model element):
Các khái niệm được sử dụng trong các biểu đồ được gọi là các phần tử mô hình,
thể hiện các khái niệm hướng đối tượng quen thuộc. Ví dụ như lớp, đối tượng,
thông điệp cũng như các quan hệ giữa các khái niệm này, bao gồm cả liên kết,
phụ thuộc, khái quát hóa. Một phần tử mô hình thường được sử dụng trong nhiều
biểu đồ khác nhau, nhưng nó luôn luôn có chỉ một ý nghĩa và một kí hiệu.
Cơ chế chung: Cơ chế chung cung cấp
thêm những lời nhận xét bổ sung, các thông tin cũng như các quy tắc ngữ pháp
chung về một phần tử mô hình; chúng còn cung cấp thêm các cơ chế để có thể mở
rộng ngôn ngữ UML cho phù hợp với một phương pháp xác định (một quy trình, một
tổ chức hoặc một người dùng).
Mô hình hóa một hệ thống phức tạp là một việc làm khó khăn.
Lý tưởng nhất là toàn bộ hệ thống được miêu tả chỉ trong một bản vẽ, một bản vẽ
định nghĩa một cách rõ ràng và mạch lạc toàn bộ hệ thống, một bản vẽ ngoài ra
lại còn dễ giao tiếp và dễ hiểu. Mặc dù vậy, thường thì đây là chuyện bất khả
thi. Một bản vẽ không thể nắm bắt tất cả các thông tin cần thiết để miêu tả một
hệ thống. Một hệ thống cần phải được miêu tả với một loạt các khía cạnh khác
nhau: Về mặt chức năng (cấu trúc tĩnh của nó cũng như các tương tác động), về
mặt phi chức năng (yêu cầu về thời gian, về độ đáng tin cậy, về quá trình thực
thi, v.v. và v.v.) cũng như về khía cạnh tổ chức (tổ chức làm việc, ánh xạ nó
vào các code module, ...). Vì vậy một hệ thống thường được miêu tả trong một
loạt các hướng nhìn khác nhau, mỗi hướng nhìn sẽ thể hiện một bức ảnh ánh xạ
của toàn bộ hệ thống và chỉ ra một khía cạnh riêng của hệ thống.
Hình
3.1- Các View trong UML
Mỗi một hướng nhìn được miêu tả trong một loạt các biểu đồ,
chứa đựng các thông tin nêu bật khía cạnh đặc biệt đó của hệ thống. Trong thực
tế khi phân tích và thiết kế rất dễ xảy ra sự trùng lặp thông tin, cho nên một
biểu đồ trên thật tế có thể là thành phần của nhiều hướng nhìn khác nhau. Khi
nhìn hệ thống từ nhiều hướng nhìn khác nhau, tại một thời điểm có thể người ta
chỉ tập trung vào một khía cạnh của hệ thống. Một biểu đồ trong một hướng nhìn
cụ thể nào đó cần phải đủ độ đơn giản để tạo điều kiện giao tiếp dễ dàng, để
dính liền với các biểu đồ khác cũng như các hướng nhìn khác, làm sao cho bức
tranh toàn cảnh của hệ thống được miêu tả bằng sự kết hợp tất cả các thông tin
từ tất cả các hướng nhìn. Một biểu đồ chứa các kí hiệu hình học mô tả các phần
tử mô hình của hệ thống. UML có tất cả các hướng nhìn sau:
- Hướng
nhìn Use case (use case view) : đây là hướng nhìn chỉ ra khía cạnh chức
năng của một hệ thống, nhìn từ hướng tác nhân bên ngoài.
- Hướng
nhìn logic (logical view): chỉ ra chức năng sẽ được thiết kế bên trong hệ
thống như thế nào, qua các khái niệm về cấu trúc tĩnh cũng như ứng xử động
của hệ thống.
- Hướng
nhìn thành phần (component view): chỉ ra khía cạnh tổ chức của các thành
phần code.
- Hướng
nhìn song song (concurrency view): chỉ ra sự tồn tại song song/ trùng hợp
trong hệ thống, hướng đến vấn đề giao tiếp và đồng bộ hóa trong hệ thống.
- Hướng
nhìn triển khai (deployment view): chỉ ra khía cạnh triển khai hệ thống
vào các kiến trúc vật lý (các máy tính hay trang thiết bị được coi là trạm
công tác).
Khi bạn chọn công cụ để vẽ biểu đồ, hãy chọn công cụ nào tạo
điều kiện dễ dàng chuyển từ hướng nhìn này sang hướng nhìn khác. Ngoài ra, cho
mục đích quan sát một chức năng sẽ được thiết kế như thế nào, công cụ này cũng
phải tạo điều kiện dễ dàng cho bạn chuyển sang hướng nhìn Use case (để xem chức
năng này được miêu tả như thế nào từ phía tác nhân), hoặc chuyển sang hướng
nhìn triển khai (để xem chức năng này sẽ được phân bố ra sao trong cấu trúc vật
lý - Nói một cách khác là nó có thể nằm trong máy tính nào).
Ngoài các hướng nhìn kể trên, ngành công nghiệp phần mềm còn
sử dụng cả các hướng nhìn khác, ví dụ hướng nhìn tĩnh-động, hướng nhìn
logic-vật lý, quy trình nghiệp vụ (workflow) và các hướng nhìn khác. UML không
yêu cầu chúng ta phải sử dụng các hướng nhìn này, nhưng đây cũng chính là những
hướng nhìn mà các nhà thiết kế của UML đã nghĩ tới, nên có khả năng nhiều công
cụ sẽ dựa trên các hướng nhìn đó.
Hướng nhìn Use case miêu tả chức năng của hệ thống sẽ phải
cung cấp do được tác nhân từ bên ngoài mong đợi. Tác nhân là thực thể tương tác
với hệ thống; đó có thể là một người sử dụng hoặc là một hệ thống khác. Hướng
nhìn Use case là hướng nhìn dành cho khách hàng, nhà thiết kế, nhà phát triển
và người thử nghiệm; nó được miêu tả qua các biểu đồ Use case (use case
diagram) và thỉnh thoảng cũng bao gồm cả các biểu đồ hoạt động (activity
diagram). Cách sử dụng hệ thống nhìn chung sẽ được miêu tả qua một loạt các Use
case trong hướng nhìn Use case, nơi mỗi một Use case là một lời miêu tả mang
tính đặc thù cho một tính năng của hệ thống (có nghĩa là một chức năng được
mong đợi).
Hướng nhìn Use case mang tính trung tâm, bởi nó đặt ra nội
dung thúc đẩy sự phát triển các hướng nhìn khác. Mục tiêu chung của hệ thống là
cung cấp các chức năng miêu tả trong hướng nhìn này – cùng với một vài các
thuộc tính mang tính phi chức năng khác – vì thế hướng nhìn này có ảnh hưởng
đến tất cả các hướng nhìn khác. Hướng nhìn này cũng được sử dụng để thẩm tra
(verify) hệ thống qua việc thử nghiệm xem hướng nhìn Use case có đúng với mong
đợi của khách hàng (Hỏi: "Đây có phải là thứ bạn muốn") cũng như có
đúng với hệ thống vừa được hoàn thành (Hỏi: "Hệ thống có hoạt động như đã
đặc tả?”).
Hướng nhìn logic miêu tả phương thức mà các chức năng của hệ
thống sẽ được cung cấp. Chủ yếu nó được sử dụng cho các nhà thiết kế và nhà
phát triển. Ngược lại với hướng nhìn Use case, hướng nhìn logic nhìn vào phía
bên trong của hệ thống. Nó miêu tả kể cả cấu trúc tĩnh (lớp, đối tượng, và quan
hệ) cũng như sự tương tác động sẽ xảy ra khi các đối tượng gửi thông điệp cho
nhau để cung cấp chức năng đã định sẵn. Hướng nhìn logic định nghĩa các thuộc
tính như trường tồn (persistency) hoặc song song (concurrency), cũng như các
giao diện cũng như cấu trúc nội tại của các lớp.
Cấu trúc tĩnh được miêu tả bằng các biểu đồ lớp (class
diagram) và biểu đồ đối tượng (object diagram). Quá trình mô hình hóa động được
miêu tả trong các biểu đồ trạng thái (state diagram), biểu đồ trình tự
(sequence diagram), biểu đồ tương tác (collaboration diagram) và biểu đồ hoạt
động (activity diagram).
Là một lời miêu tả của việc thực thi các modul cũng như sự
phụ thuộc giữa chúng với nhau. Nó thường được sử dụng cho nhà phát triển và
thường bao gồm nhiều biểu đồ thành phần. Thành phần ở đây là các modul lệnh
thuộc nhiều loại khác nhau, sẽ được chỉ ra trong biểu đồ cùng với cấu trúc cũng
như sự phụ thuộc của chúng. Các thông tin bổ sung về các thành phần, ví dụ như
vị trí của tài nguyên (trách nhiệm đối với một thành phần), hoặc các thông tin
quản trị khác, ví dụ như một bản báo cáo về tiến trình của công việc cũng có
thể được bổ sung vào đây.
Hướng nhìn song song nhắm tới sự chia hệ thống thành các qui
trình (process) và các bộ xử lý (processor). Khía cạnh này, vốn là một thuộc
tính phi chức năng của hệ thống, cho phép chúng ta sử dụng một cách hữu hiệu
các nguồn tài nguyên, thực thi song song, cũng như xử lý các sự kiện không đồng
bộ từ môi trường. Bên cạnh việc chia hệ thống thành các tiểu trình có thể được
thực thi song song, hướng nhìn này cũng phải quan tâm đến vấn đề giao tiếp và
đồng bộ hóa các tiểu trình đó.
Hướng nhìn song song giành cho nhà phát triển và người tích
hợp hệ thống, nó bao gồm các biểu đồ động (trạng thái, trình tự, tương tác và
hoạt động) cùng các biểu đồ thực thi (biểu đồ thành phần và biểu đồ triển
khai).
Cuối cùng, hướng nhìn triển khai chỉ cho
chúng ta sơ đồ triển khai về mặt vật lý của hệ thống, ví dụ như các máy tính
cũng như các máy móc và sự liên kết giữa chúng với nhau. Hướng nhìn triển khai
giành cho các nhà phát triển, người tích hợp cũng như người thử nghiệm hệ thống
và được thể hiện bằng các biểu đồ triển khai. Hướng nhìn này cũng bao gồm sự
ánh xạ các thành phần của hệ thống vào cấu trúc vật lý; ví dụ như chương trình
nào hay đối tượng nào sẽ được thực thi trên máy tính nào.
Biểu đồ là các hình vẽ bao gồm các ký hiệu phần tử mô hình
hóa được sắp xếp để minh họa một thành phần cụ thể hay một khía cạnh cụ thể của
hệ thống. Một mô hình hệ thống thường có nhiều loại biểu đồ, mỗi loại có nhiều
biểu đồ khác nhau. Một biểu đồ là một thành phần của một hướng nhìn cụ thể; và
khi được vẽ ra, nó thường thường cũng được xếp vào một hướng nhìn. Mặt khác,
một số loại biểu đồ có thể là thành phần của nhiều hướng nhìn khác nhau, tùy
thuộc vào nội dung của biểu đồ.
Phần sau miêu tả các khái niệm căn bản nằm đằng sau mỗi loại
biểu đồ. Tất cả các chi tiết về biểu đồ, ngữ cảnh của chúng, ý nghĩa chính xác
của chúng và sự tương tác giữa chúng với nhau được miêu tả chi tiết trong các
chương sau (mô hình đối tượng – mô hình động). Các biểu đồ lấy làm ví dụ ở đây
được lấy ra từ nhiều loại hệ thống khác nhau để chỉ ra nét phong phú và khả
năng áp dụng rộng khắp của ULM.
Một biểu đồ Use case chỉ ra một số lượng các tác nhân ngoại
cảnh và mối liên kết của chúng đối với Use case mà hệ thống cung cấp (nhìn hình
3.2). Một Use case là một lời miêu tả của một chức năng mà hệ thống cung cấp.
Lời miêu tả Use case thường là một văn bản tài liệu, nhưng kèm theo đó cũng có
thể là một biểu đồ hoạt động. Các Use case được miêu tả duy nhất theo hướng
nhìn từ ngoài vào của các tác nhân (hành vi của hệ thống theo như sự mong đợi
của người sử dụng), không miêu tả chức năng được cung cấp sẽ hoạt động nội bộ
bên trong hệ thống ra sao. Các Use case định nghĩa các yêu cầu về mặt chức năng
đối với hệ thống. Các biểu đồ Use case sẽ được miêu tả chi tiết hơn trong
chương 4 (Use case).
Hình
3.2- Biểu đồ use case của một công ty
bảo hiểm
Một biểu đồ lớp chỉ ra cấu trúc tĩnh của các lớp trong hệ
thống (nhìn hình 3.3). Các lớp là đại diện cho các “vật” được xử lý trong hệ
thống. Các lớp có thể quan hệ với nhau trong nhiều dạng thức: liên kết
(associated - được nối kết với nhau), phụ thuộc (dependent - một lớp này phụ
thuộc vào lớp khác), chuyên biệt hóa (specialized - một lớp này là một kết quả
chuyên biệt hóa của lớp khác), hay đóng gói ( packaged - hợp với nhau thành một
đơn vị). Tất cả các mối quan hệ đó đều được thể hiện trong biểu đồ lớp, đi kèm
với cấu trúc bên trong của các lớp theo khái niệm thuộc tính (attribute) và thủ
tục (operation). Biểu đồ được coi là biểu đồ tĩnh theo phương diện cấu trúc
được miêu tả ở đây có hiệu lực tại bất kỳ thời điểm nào trong toàn bộ vòng đời
hệ thống.
Một hệ thống thường sẽ có một loạt các biểu đồ lớp – chẳng
phải bao giờ tất cả các biểu đồ lớp này cũng được nhập vào một biểu đồ lớp tổng
thể duy nhất – và một lớp có thể tham gia vào nhiều biểu đồ lớp. Biểu đồ lớp
được miêu tả chi tiết trong chương sau.
Hình
3.3 - Biểu đồ lớp cho một giao dịch Tài
chính
Một biểu đồ đối tượng là một phiên bản của biểu đồ lớp và
thường cũng sử dụng các ký hiệu như biểu đồ lớp. Sự khác biệt giữa hai loại
biểu đồ này nằm ở chỗ biểu đồ đối tượng chỉ ra một loạt các đối tượng thực thể
của lớp, thay vì các lớp. Một biểu đồ đối tượng vì vậy là một ví dụ của biểu đồ
lớp, chỉ ra một bức tranh thực tế có thể xảy ra khi hệ thống thực thi: bức
tranh mà hệ thống có thể có tại một thời điểm nào đó. Biểu đồ đối tượng sử dụng
chung các ký hiệu của biểu đồ lớp, chỉ trừ hai ngoại lệ: đối tượng được viết
với tên được gạch dưới và tất cả các thực thể trong một mối quan hệ đều được
chỉ ra (nhìn hình 3.4).
Biểu đồ đối tượng không quan trọng bằng biểu đồ lớp, chúng
có thể được sử dụng để ví dụ hóa một biểu đồ lớp phức tạp, chỉ ra với những
thực thể cụ thể và những mối quan hệ như thế thì bức tranh toàn cảnh sẽ ra sao.
Một biểu đồ đối tượng thường thường được sử dụng làm một thành phần của một
biểu đồ cộng tác (collaboration), chỉ ra lối ứng xử động giữa một loạt các đối
tượng.
Hình
3.4 - Biểu đồ lớp và biểu đồ đối tượng
thể hiện của lớp
Một biểu đồ trạng thái thường là một sự bổ sung cho lời miêu
tả một lớp. Nó chỉ ra tất cả các trạng thái mà đối tượng của lớp này có thể có,
và những sự kiện (event) nào sẽ gây ra sự thay đổi trạng thái (hình 3.5). Một sự
kiện có thể xảy ra khi một đối tượng tự gửi thông điệp đến cho nó - ví dụ như
để thông báo rằng một khoảng thời gian được xác định đã qua đi – hay là một số
điều kiện nào đó đã được thỏa mãn. Một sự thay đổi trạng thái được gọi là một
sự chuyển đổi trạng thái (State Transition). Một chuyển đổi trạng thái
cũng có thể có một hành động liên quan, xác định điều gì phải được thực hiện
khi sự chuyển đổi trạng thái này diễn ra.
Biểu đồ trạng thái không được vẽ cho tất cả các lớp, mà chỉ
riêng cho những lớp có một số lượng các trạng thái được định nghĩa rõ ràng và
hành vi của lớp bị ảnh hưởng và thay đổi qua các trạng thái khác nhau. Biểu đồ
trạng thái cũng có thể được vẽ cho hệ thống tổng thể. Biểu đồ trạng thái được
miêu tả chi tiết hơn trong chương sau (Mô hình động).
Hình
3.5- Một ví dụ về biểu đồ trạng thái
Một biểu đồ trình tự chỉ ra một cộng tác động giữa một loạt
các đối tượng (xem hình 3.6). Khía cạnh quan trọng của biểu đồ này là chỉ ra
trình tự các thông điệp (message) được gửi giữa các đối tượng. Nó cũng chỉ ra
trình tự tương tác giữa các đối tượng, điều sẽ xảy ra tại một thời điểm cụ thể
nào đó trong trình tự thực thi của hệ thống. Các biểu đồ trình tự chứa một loạt
các đối tượng được biểu diễn bằng các đường thẳng đứng. Trục thời gian có hướng
từ trên xuống dưới trong biểu đồ, và biểu đồ chỉ ra sự trao đổi thông điệp giữa
các đối tượng khi thời gian trôi qua. Các thông điệp được biểu diễn bằng các
đường gạch ngang gắn liền với mũi tên (biểu thị thông điệp) nối liền giữa những
đường thẳng đứng thể hiện đối tượng. Trục thời gian cùng những lời nhận xét
khác thường sẽ được đưa vào phần lề của biểu đồ.
Hình
3.6 - Một biểu đồ trình tự cho Print
Server
Một biểu đồ cộng tác chỉ ra một sự cộng tác động, cũng giống
như một biểu đồ trình tự. Thường người ta sẽ chọn hoặc dùng biểu đồ trình tự
hoặc dùng biểu đồ cộng tác. Bên cạnh việc thể hiện sự trao đổi thông điệp (được
gọi là tương tác), biểu đồ cộng tác chỉ ra các đối tượng và quan hệ của
chúng (nhiều khi được gọi là ngữ cảnh). Việc nên sử dụng biểu đồ trình tự hay
biểu đồ cộng tác thường sẽ được quyết định theo nguyên tắc chung sau: Nếu thời
gian hay trình tự là yếu tố quan trọng nhất cần phải nhấn mạnh thì hãy chọn
biểu đồ trình tự; nếu ngữ cảnh là yếu tố quan trọng hơn, hãy chọn biểu đồ cộng
tác. Trình tự tương tác giữa các đối tượng được thể hiện trong cả hai loại biểu
đồ này.
Biểu đồ cộng tác được vẽ theo dạng một biểu đồ đối tượng,
nơi một loạt các đối tượng được chỉ ra cùng với mối quan hệ giữa chúng với nhau
(sử dụng những ký hiệu như trong biểu đồ lớp/ biểu đồ đối tượng). Các mũi tên
được vẽ giữa các đối tượng để chỉ ra dòng chảy thông điệp giữa các đối tượng.
Các thông điệp thường được đính kèm theo các nhãn (label), một trong những chức
năng của nhãn là chỉ ra thứ tự mà các thông điệp được gửi đi. Nó cũng có thể
chỉ ra các điều kiện, chỉ ra những giá trị được trả về, v.v... Khi đã làm quen
với cách viết nhãn, một nhà phát triển có thể đọc biểu đồ cộng tác và tuân thủ
theo dòng thực thi cũng như sự trao đổi thông điệp. Một biểu đồ cộng tác cũng
có thể chứa cả các đối tượng tích cực (active objects), hoạt động song song với
các đối tượng tích cực khác (hình 3.7). Biểu đồ cộng tác được miêu tả chi tiết
trong chương sau.
Hình
3.7 - Một biểu đồ công tác của một
printer server
Một biểu đồ hoạt động chỉ ra một trình tự lần lượt của các
hoạt động (activity) (hình 3.8). Biểu đồ hoạt động thường được sử dụng để miêu
tả các hoạt động được thực hiện trong một thủ tục, mặc dù nó cũng có thể được
sử dụng để miêu tả các dòng chảy hoạt động khác, ví dụ như trong một Use case
hay trong một trình tự tương tác. Biểu đồ hoạt động bao gồm các trạng thái hành
động, chứa đặc tả của một hoạt động cần phải được thực hiện (một hành động -
action). Một trạng thái hành động sẽ qua đi khi hành động được thực hiện xong
(khác với biểu đồ trạng thái: một trạng thái chỉ chuyển sang trạng thái khác
sau khi đã xảy ra một sự kiện rõ ràng !). Dòng điều khiển ở đây chạy giữa các
trạng thái hành động liên kết với nhau. Biểu đồ còn có thể chỉ ra các quyết
định, các điều kiện, cũng như phần thực thi song song của các trạng thái hành
động. Biểu đồ ngoài ra còn có thể chứa các loại đặc tả cho các thông điệp được
gửi đi hoặc được nhận về, trong tư cách là thành phần của hành động được thực
hiện.
Hình
3.8 - Một biểu đồ hoạt động cho một
printer server
Một biểu đồ thành phần chỉ ra cấu trúc vật lý của các dòng
lệnh (code) theo khái niệm thành phần code. Một thành phần code có thể là một
tập tin source code, một thành phần nhị phân (binary) hay một thành phần thực
thi được (executable). Một thành phần chứa các thông tin về các lớp logic hoặc
các lớp mà nó thi hành, như thế có nghĩa là nó tạo ra một ánh xạ từ hướng nhìn
logic vào hướng nhìn thành phần. Biểu đồ thành phần cũng chỉ ra những sự phụ
thuộc giữa các thành phần với nhau, trợ giúp cho công việc phân tích hiệu ứng
mà một thành phần được thay đổi sẽ gây ra đối với các thành phần khác. Thành
phần cũng có thể được miêu tả với bất kỳ loại giao diện nào mà chúng bộc lộ, ví
dụ như giao diện OLE/COM; và chúng có thể được nhóm góp lại với nhau thành từng
gói (package). Biểu đồ thành phần được sử dụng trong công việc lập trình cụ thể
(xem hình 3.9).
Hình
3.9 - Một biểu đồ thành phần chỉ ra sự
phụ thuộc giữa các thành phần mã
Biểu đồ triển khai chỉ ra kiến trúc vật lý của phần cứng
cũng như phần mềm trong hệ thống. Bạn có thể chỉ ra từng máy tính cụ thể và
từng trang thiết bị cụ thể (node) đi kèm sự nối kết giữa chúng với nhau, bạn
cũng có thể chỉ ra loại của các mối nối kết đó. Bên trong các nút mạng (node),
các thành phần thực thi được cũng như các đối tượng sẽ được xác định vị trí để
chỉ ra những phần mềm nào sẽ được thực thi tại những nút mạng nào. Bạn cũng có
thể chỉ ra sự phụ thuộc giữa các thành phần.
Biểu đồ triển khai chỉ ra hướng nhìn triển khai, miêu tả
kiến trúc vật lý thật sự của hệ thống. Đây là một hướng nhìn rất xa lối miêu tả
duy chức năng của hướng nhìn Use case. Mặc dù vậy, trong một mô hình tốt, người
ta có thể chỉ tất cả những con đường dẫn từ một nút mạng trong một kiến trúc
vật lý cho tới những thành phần của nó, cho tới lớp mà nó thực thi, cho tới
những tương tác mà các đối tượng của lớp này tham gia để rồi cuối cùng, tiến
tới một Use case. Rất nhiều hướng nhìn khác nhau của hệ thống được sử dụng đồng
thời để tạo ra một lời miêu tả thấu đáo đối với hệ thống trong sự tổng thể của
nó.
Hình
3.10 - Một biểu đồ triển khai chỉ ra
kiến trúc vật lý của hệ thống
Các khái niệm được sử dụng trong các biểu đồ được gọi là các
phần tử mô hình (model element). Một phần tử mô hình được định nghĩa với ngữ
nghĩa (semantic), đó là một định nghĩa về bản chất phần tử hay là một xác định
ý nghĩa chính xác xem nó sẽ thể hiện điều gì trong những lời khẳng định rõ
ràng. Mỗi phần tử mô hình còn có một sự miêu tả trực quan, một ký hiệu hình học
được sử dụng để miêu tả phần tử này trong biểu đồ. Một phần tử có thể tồn tại
trong nhiều dạng biểu đồ khác nhau, nhưng cũng có những nguyên tắc xác định
loại phần tử nào có thể được chỉ ra trong loại biểu đồ nào. Một vài ví dụ cho
phần tử vô hình là lớp, đối tượng, trạng thái, nút mạng, gói, thành phần (hình
3.11).
Hình
3.11- Các thành phần mô hình thường dùng
Hình 3.12 chỉ ra một vài ví dụ của mối quan hệ, đây cũng là
một dạng phần tử mô hình, chúng được sử dụng để nối các phần tử mô hình khác
với nhau. Một vài loại quan hệ đáng chú ý:
- Nối
kết (Association) : nối các phần tử và các thực thể nối (link).
- Khái
quát hóa (Generalization): còn được gọi là tính thừa kế, có ý nghĩa
rằng một phần tử này có thể là một sự chuyên biệt hóa của một phần tử
khác.
- Sự
phụ thuộc (Dependency): chỉ ra rằng một phần tử này phụ thuộc trong
một phương thức nào đó vào một phần tử khác.
- Kết
tập (Aggregation): Một dạng của nối kết, trong đó một phần tử này chứa
các phần tử khác.
Ngoài ra còn có các phần tử mô hình khác như thông điệp
(Message), hành động (action) và khuôn mẫu (stereotype). Tất cả các phần tử mô
hình, ý nghĩa của chúng cũng như những ứng dụng đều được giải thích kỹ lưỡng
hơn trong các chương sau.
UML thể hiện một số các cơ chế chung trong tất cả các biểu
đồ nhằm mục đích cung cấp thêm các thông tin bổ sung, thường đây là những thông
tin không thể được thể hiện qua các chức năng và khả năng cơ bản của các phần
tử mô hình.
Các sự trang trí trực quan có thể được sử dụng kèm thêm vào
các phần tử mô hình trong biểu đồ. Động tác trang trí bổ sung thêm ngữ nghĩa
cho phần tử. Một ví dụ là kỹ thuật được sử dụng để phân biệt một loại thực thể
(lớp) và một thực thể. Khi thể hiện một loại, tên phần tử sẽ được in đậm. Khi
cũng chính phần tử đó thể hiện chỉ một thực thể của loại này, tên phần tử sẽ
được gạch dưới và có thể được coi là cả tên của thực thể lẫn tên của loại đó.
Một hình chữ nhật thể hiện lớp với tên được in đậm sẽ thể hiện một lớp và tên
được gạch dưới sẽ thể hiện một đối tượng, đây là một ví dụ tiêu biểu của
adornment. Cũng nguyên tắc đó được áp dụng cho các nút mạng, khi ký hiệu nút
được in đậm là thể hiện một loại nút, ví dụ như máy in (Printer), khi ký
hiệu được gạch dưới là thể hiện một thực thể của lớp nút mạng này ví dụ John’s
HP 5MP-printer. Các kiểu trang trí khác là các lời đặc tả về số lượng trong
quan hệ (multiplicity), nơi số lượng là một số hay một khoảng số chỉ ra bao
nhiêu thực thể của các loại thực thể được nối với nhau sẽ có thể tham gia trong
một quan hệ. Kí hiệu trang trí được viết gần phần tử mô hình được mà nó bổ sung
thông tin (hình 3.13).
Hình
3.13 - Phân biệt giữa lớp và đối tượng
bằng trang trí
Cho dù một ngôn ngữ mô hình hóa có được mở rộng đến bao
nhiêu chăng nữa, nó cũng không thể định nghĩa tất cả mọi việc. Nhằm tạo điều kiện
bổ sung thêm cho một mô hình những thông tin không thể được thể hiện bằng phần
tử mô hình, UML cung cấp khả năng kèm theo lời ghi chú. Một lời ghi chú có thể
được để bất kỳ nơi nào trong bất kỳ biểu đồ nào, và nó có thể chứa bất kỳ loại
thông tin nào. Dạng thông tin của bản thân nó là chuỗi ký tự (string), không
được UML diễn giải. Lời ghi chú thường đi kèm theo một số các phần tử mô hình
trong biểu đồ, được nối bằng một đường chấm chấm, chỉ ra phần tử mô hình nào
được chi tiết hóa hoặc được giải thích (hình 3.14).
Một lời ghi chú thường chứa lời nhận xét hoặc các câu hỏi
của nhà tạo mô hình, ví dụ lời nhắc nhở cần phải xử lý vấn đề nào đó trong thời
gian sau này. Lời ghi chú cũng có thể chứa các thông tin dạng khuôn mẫu
(stereotype).
Hình
3.14 - Một ví dụ về ghi chú
Các phần tử mô hình có thuộc tính (Property) chứa các giá
trị dữ liệu về phần tử này. Một thuộc tính được định nghĩa với một tên và một giá
trị đính kèm (tagged value), thường chúng ở trong một dạng thông tin được
xác định trước, ví dụ như số nguyên hay chuỗi kí tự. Có một loạt thuộc tính đã
được định nghĩa trước, ví dụ như tài liệu (docement), trách nhiệm
(Responsibility), sự trường tồn (Persistence) và tính song song (Conccurency).
Thuộc tính được sử dụng để thêm các đặc tả bổ sung về một
phần tử, những thông tin bình thường ra không được thể hiện trong biểu đồ. Ví
dụ tiêu biểu là một lớp sẽ được miêu tả bằng một tài liệu văn bản nhất định,
cung cấp nhiều thông tin hơn về trách nhiệm cũng như khả năng của lớp này. Loại
đặc tả này bình thường ra không được chỉ ra trong các biểu đồ, nhưng thường thì
trong đa phần các công cụ mô hình hóa chúng sẽ có thể được truy cập qua hành
động nhấp nút vào một phần tử nào đó, hiệu quả là một cửa sổ chứa đặc tả với
tất cả các thuộc tính sẽ được chỉ ra (Hình 3.15).
Hình
3.15- Một cửa sổ đặc tả thể hiện các đặc
tính của class
Hình
3.12 – các ví dụ về vài loại quan hệ
7- Mở rộng UML
UML có thể được mở rộng hoặc có thể được sửa đổi để phù hợp
với một phương pháp đặc biệt, một tổ chức cụ thể hay một người dùng cụ thể.
Chúng ta sẽ bàn luận sơ qua đến ba cơ chế mở rộng UML: khuôn mẫu (stereotype),
giá trị đính kèm (tagged value) và hạn chế (constraint).
Cơ chế mở rộng khuôn mẫu định nghĩa một loại phần tử mô hình
mới dựa trên một phần tử mô hình đã tồn tại. Khuôn mẫu có thể được coi là
"tương tự" như một phần tử đã có sẵn, cộng thêm phần quy định ngữ
nghĩa (semantic) riêng biệt không có trong phần tử gốc kia. Khuôn mẫu của một
phần tử có thể được sử dụng trong cùng tình huống như phần tử căn bản. Khuôn
mẫu dựa trên tất cả các loại phần tử mô hình sẵn có - lớp, nút mạng, thành
phần, cũng như các mối quan hệ như liên kết, khái quát hóa, sự phụ thuộc. Ngôn
ngữ UML có chứa một số lượng lớn các khuôn mẫu được định nghĩa sẵn và chúng
được sử dụng để sửa đổi các phần tử mô hình sẵn có, thay cho việc phải định
nghĩa hoàn toàn mới. Cơ chế này giúp gìn giữ tính đơn giản của nền tảng ngôn ngữ
UML.
Khuôn mẫu được miêu tả qua việc đưa tên của chúng vào trong
một cặp ký tự ngoặc nhọn <<>>, theo như trong hình 3.16. Ký tự
ngoặc nhọn này được gọi là guillements. Khuôn mẫu cũng có thể có kí hiệu hình
học riêng. Một phần tử của một loại khuôn mẫu cụ thể có thể được thể hiện bởi
tên khuôn mẫu đi kèm ký hiệu hình học mô tả phần tử căn bản, hay là sự kết hợp
của cả hai yếu tố này. Bất kỳ khi nào một phần tử mô hình được nối kết với một
tên hoặc kí hiệu khuôn mẫu, ta sẽ đọc "đây là một loại phần tử thuộc loại
khuôn mẫu...". Ví dụ, một lớp với <<Window>> sẽ được gọi là
"một lớp trong dạng khuôn mẫu cửa sổ", ý nghĩa của nó là một dạng lớp
cửa sổ. Những thuộc tính cụ thể mà một lớp cửa sổ cần phải có sẽ được định
nghĩa khi khuôn mẫu này được định nghĩa.
Như đã nói, khuôn mẫu là một cơ chế mở rộng xuất sắc, là một
cơ chế ngăn cho ngôn ngữ UML không trở nên quá phức tạp, mặc dù vẫn cho phép
thực hiện sự mở rộng và sửa đổi cần thiết. Đa phần các phần tử mô hình mới mà
bạn cần đến đều có một khuôn mẫu nền tảng trong ngôn ngữ UML. Một khuôn mẫu sau
đó có thể được sử dụng để cộng thêm các ngữ nghĩa cần thiết, nhằm mục đích định
nghĩa nên các phần tử mô hình còn thiếu.
Hình
3.16- Customer là một lớp khuôn mẫu
<<Actor>>
Như đã nói, các phần tử mô hình có thể có các thuộc tính
chứa một cặp tên-giá trị về bản thân chúng (hình 3.17). Các thuộc tính này cũng
còn được gọi là các gía trị đính kèm. UML có chứa một loạt các thuộc tính được
định nghĩa trước, nhưng kể cả người sử dụng cũng có thể định nghĩa ra các thuộc
tính mới để chứa các thông tin bổ sung về các phần tử mô hình. Mọi hình dạng
thông tin đều có thể được đính kèm vào phần tử: các thông tin chuyên biệt về
phương pháp, các thông tin của nhà quản trị về tiến trình mô hình hóa, các
thông tin được sử dụng bởi các công cụ khác, ví dụ như các công cụ tạo code,
hay bất kỳ một loại thông tin nào mà người sử dụng muốn đính kèm vào phần tử mô
hình.
Hình
3.17 - Một ví dụ về Tagged Value
Một sự hạn chế là một sự giới hạn về sự sử dụng hoặc ý nghĩa
của một phần tử. Sự hạn chế hoặc sẽ được khai báo trong công cụ và được sử dụng
nhiều lần trong rất nhiều biểu đồ khác nhau, hay được định nghĩa và sử dụng
trong chỉ một biểu đồ, theo như nhu cầu.
Hình 3.18 chỉ ra mối quan hệ nối kết giữa nhóm các công dân
lớn tuổi và lớp con người, chỉ ra rằng nhóm công dân có thể có nhiều người liên
quan. Mặc dù vậy, để miêu tả rằng chỉ những người nào lớn hơn 60 tuổi mới có
thể tham gia vào nhóm này, người ta định nghĩa một sự hạn chế, hạn hẹp tiêu
chuẩn tham gia đối với chỉ những người nào mà thuộc tính tuổi tác có giá trị
lớn hơn 60. Định nghĩa này sẽ hạn chế số lượng những người được sử dụng trong
mối quan hệ. Nếu không có nó, người ta rất dễ hiểu lầm khi diễn tả biểu đồ.
Trong trường hợp tồi tệ, nó có thể dẫn đến sự thực thi sai trái của hệ thống.
Trong trường hợp này, hạn chế được định nghĩa và ứng dụng
trực tiếp trong chính biểu đồ mà nó được cần tới. Nhưng nhìn chung thì hạn chế
cũng có thể được định nghĩa với tên cùng lời đặc tả riêng, ví dụ như:
"công dân già" và "người có tuổi lớn hơn 60", và hạn chế
này sẽ được sử dụng trong nhiều biểu đồ khác nhau. UML có chứa một loạt các hạn
chế được định nghĩa sẵn, chúng được miêu tả chi tiết trong các chương sau.
Hình 3.18- Một
ràng buộc hạn chế đối tượng Person góp phần vào quan hệ kết hợp
Khi xây dựng hệ thống với UML, người ta không chỉ xây dựng
duy nhất một mô hình. Sẽ có nhiều mô hình khác nhau trong những giai đoạn phát
triển khác nhau, nhắm đến các mục đích khác nhau. Trong giai đoạn phân tích,
mục đích của mô hình là nắm bắt tất cả các yêu cầu đối với hệ thống và mô hình
hóa nền tảng bao gồm các lớp và các cộng tác "đời thực". Trong giai
đoạn thiết kế, mục đích của mô hình là mở rộng mô hình phân tích, tạo thành một
giải pháp kỹ thuật khả thi, có chú ý đến môi trường của công việc xây dựng
(viết code). Trong giai đoạn xây dựng code, mô hình chính là những dòng code
nguồn thật sự, được viết nên và được dịch thành các chương trình. Và cuối cùng,
trong giai đoạn triển khai, một lời miêu tả sẽ giải thích hệ thống cần được
triển khai ra sao trong kiến trúc vật lý. Khả năng theo dõi xuyên suốt nhiều
giai đoạn và nhiều mô hình khác nhau được đảm bảo qua các thuộc tính hoặc các
mối quan hệ nâng cao (refinement).
Mặc dù đó là các mô hình khác nhau, nhưng chúng đều được xây
dựng nên để mở rộng nội dung của các mô hình ở giai đoạn trước. Chính vì thế,
tất cả các mô hình đều cần phải được gìn giữ tốt để người ta có thể dễ dàng đi
ngược lại, mở rộng ra hay tái thiết lập mô hình phân tích khởi đầu và rồi dần
dần từng bước đưa các sự thay đổi vào mô hình thiết kế cũng như các mô hình xây
dựng (hình 3.19).
Hình
3.19- Một hệ thống được mô tả trong
nhiều mô hình
Bản thân ngôn ngữ UML không phụ thuộc vào giai đoạn, có
nghĩa là cũng những nguyên tắc ngôn ngữ đó và cũng những biểu đồ đó được sử
dụng để mô hình hóa những sự việc khác nhau trong những giai đoạn khác nhau.
Nhà thiết kế nắm quyền quyết định xem một mô hình sẽ phải thay đổi nhằm đạt
được những mục đích nào và bao trùm những phạm vi nào. Ngôn ngữ mô hình hóa chỉ
cung cấp khả năng để tạo ra các mô hình trong một phong cách mở rộng và nhất
quán.
Khi mô hình hóa bằng ngôn ngữ UML, toàn bộ công việc cần
phải được thực hiện theo một phương pháp hay một qui trình, xác định rõ những
bước công việc nào phải được tiến hành và chúng phải được thực thi ra sao. Một
qui trình như vậy thường sẽ chia công việc ra thành các vòng lặp kế tiếp, mỗi
vòng lặp bao gồm các công việc: phân tích yêu cầu/ phân tích/ thiết kế/ thực
hiện/ triển khai. Mặc dù vậy, cũng có một quy trình nhỏ hơn đề cập tới nội
dung của việc mô hình hóa. Bình thường ra, khi sản xuất một mô hình hoặc sản
xuất chỉ một biểu đồ duy nhất, công việc sẽ bắt đầu bằng việc thu thập một nhóm
thích hợp các cá nhân khác nhau, trình bày vấn đề và mục tiêu; họ cộng tác cho
một giai đoạn hội thảo khoa học và phác thảo, trao đổi những sáng kiến và ý
tưởng về mô hình có thể. Công cụ được sử dụng trong giai đoạn này là hết sức
khác biệt và mang tính ngẫu hứng - thường là giấy dán post it hay bảng
trắng. Công việc được quyết định chừng nào những người tham gia có cảm giác họ
đã có được một nền tảng thực tiễn cho một mô hình (giống như một tiêu đề). Kết
quả sau đó sẽ được đưa vào một công cụ, mô hình tiêu đề được tổ chức, và sau đó
một biểu đồ thực sự sẽ được tạo dựng nên, phù hợp với những quy định của ngôn
ngữ mô hình hóa. Sau đó, mô hình được chi tiết hóa qua những công việc mang
tính vòng lặp, càng ngày càng có nhiều chi tiết về giải pháp được phát hiện,
được dữ liệu hóa và được bổ sung. Khi đã có nhiều thông tin hơn được thu thập
về vấn đề cũng như giải pháp của nó, tiêu đề ban đầu dần dần trở thành một lời
chuẩn đoán cho một mô hình có khả năng sử dụng. Khi mô hình đã gần hoàn thiện,
một sự tích hợp và thẩm định sẽ được thực hiện, dẫn tới việc mô hình hoặc biểu
đồ sẽ được tích hợp với những mô hình và biểu đồ khác trong cùng dự án để đảm
bảo sự nhất quán. Mô hình sau đó cũng được kiểm tra lại để chắc chắn nó đang
giải quyết đúng vấn đề cần giải quyết (hình 3.20).
Hình
3.20 - Một tiến trình cho công việc mô
hình hoá thực tế
Cuối cùng, mô hình sẽ được thực thi và triển khai thành một
loạt các nguyên mẫu (prototype), nguyên mẫu này sẽ được kiểm tra để tìm khiếm
khuyết. Các khiếm khuyết bao gồm kể cả các chức năng còn thiếu, sự thực hiện
tồi tệ hay phí sản xuất và phát triển quá cao. Những khiếm khuyết thường sẽ ép
nhà phát triển rà đi rà lại công việc của mình để khắc phục chúng. Nếu vấn đề
là quá lớn, nhà phát triển có thể sẽ đi ngược lại tất cả các bước công việc của
mình cho tới tận giai đoạn sơ phác đầu tiên. Nếu các vấn đề này không lớn, nhà
phát triển có lẽ chỉ cần thay đổi một vài thành phần trong tổ chức hoặc đặc tả
của mô hình. Xin nhớ rằng bước tạo nguyên mẫu không thể được thực hiện ngay lập
tức sau khi hoàn tất biểu đồ; nó chỉ nên được thực hiện khi đã có một số lượng
lớn các biểu đồ liên quan. Nguyên mẫu sau này có thể được vứt đi, có thể được
tạo dựng nên chỉ để nhằm mục đích kiểm tra, hoặc là nếu bước tạo nguyên mẫu này
thành công, nó sẽ trở thành một vòng lặp trong quy trình phát triển thật sự.
Sử dụng một ngôn ngữ mô hình hóa phức tạp và rộng mở như UML
cần thiết sự trợ giúp của công cụ. Mặc dù phác thảo đầu tiên của một mô hình có
thể được thực hiện bằng bảng trắng cùng giấy và mực, nhưng công việc bảo trì,
đồng bộ hóa và đảm bảo sự nhất quán trong một loạt các biểu đồ khác nhau thường
lại không thể trở thành khả thi nếu không có công cụ.
Thị trường công cụ mô hình hóa đã dừng trong mức độ sơ khởi
suốt một thời gian dài kể từ khi xuất hiện ý tưởng đầu tiên về các chương trình
trợ giúp cho việc tạo chương trình. Rất nhiều công cụ trong thực tế chỉ thông
minh hơn các chương trình vẽ một chút, sử dụng một vài quy chế kiểm tra tính
nhất quán hoặc một vài kiến thức về phương pháp và ngôn ngữ mô hình hóa. Mặc dù
đã có một vài bước tiến nhất định và nhiều công cụ hôm nay đã tới gần sáng kiến
khởi thủy kia nhiều hơn (Rational Rose), nhưng thị trường vẫn còn không ít công
cụ chưa được gọt giũa, vẫn còn chứa lỗi hoặc những nét kỳ quặc, kể cả những vấn
đề đơn giản như copy và dán. Những công cụ này còn hạn chế ở phương diện rằng
tất cả bọn chúng đều có ngôn ngữ mô hình hóa riêng, hay ít nhất thì cũng có
những định nghĩa riêng của chúng về ngôn ngữ này.
Cùng với sự ra đời của ngôn ngữ UML, các nhà cung cấp công
cụ mô hình hóa giờ đây có thể dành nhiều thời gian hơn cho việc nâng cấp công
cụ, bởi họ không cần phải dồn tâm dồn sức cho việc định nghĩa các phương pháp
mới cũng như các ngôn ngữ mới.
Một công cụ mô hình hóa hịên đại cần phải cung cấp các chức
năng sau:
TV biểu đồ: cần phải tạo điều kiện dễ
dàng vẽ ra các biểu đồ trong ngôn ngữ mô hình hóa. Công cụ cần phải đủ khả năng
thông minh để hiểu mục đích của các biểu đồ và biết được những ngữ nghĩa cũng
như các quy tắc đơn giản, đủ để nó có thể cảnh báo hoặc ngăn chặn việc sử dụng
không thích hợp các phần tử mô hình.
Hoạt động như một nhà kho (Repository):
công cụ cần phải hỗ trợ một nhà kho trung tâm để tất cả các thông tin về mô
hình được lưu trữ trong cùng một chỗ. Nếu ví dụ tên của một lớp bị thay đổi
trong một biểu đồ, thì sự thay đổi này cần phải xảy ra trong tất cả các biểu đồ
khác có sử dụng lớp này.
Hỗ trợ định hướng (Navigation):
công cụ cần phải tạo điều kiện dễ dàng cho người sử
dụng định hướng và chuyển dịch trong mô hình
để theo dõi một phần tử từ biểu đồ này sang biểu đồ khác, hoặc để mở rộng lời
miêu tả của một phần tử.
Hỗ trợ nhiều người sử dụng (multiuser
support): Công cụ cần hỗ trợ cho nhiều người sử dụng, và tạo điều kiện
cho họ cùng làm việc với một mô hình mà không ngăn chặn hoặc quấy phá lẫn nhau.
Tự động tạo code (code generate): một
công cụ cao cấp cần phải có khả năng tạo ra code, nơi tất cả các thông tin
trong mô hình được chuyển tải thành các khung code (code skeletons), được sử
dụng làm nền tảng cho giai đoạn xây dựng chương trình.
Tái tạo mô hình (Reserve engineer):
Một công cụ cao cấp cần phải có khả năng đọc những thành phần code đang tồn tại
và từ đó sản xuất ra mô hình. Từ đó suy ra, một mô hình có thể được làm từ
những dòng code đã tồn tại; hoặc một nhà phát triển có thể dễ dàng chuyển đi
chuyển về giữa công việc mô hình hóa và công việc lập trình.
Tích hợp với các công cụ khác: một
công cụ cần phải có khả năng tích hợp với những công cụ khác, với cả việc phát
triển môi trường, ví dụ như các trình soạn thảo (editor), chương trình dịch
(compiler), chương trình tìm lỗi (debugger) cũng như các công cụ của doanh
nghiệp khác như công cụ quản trị cấu hình, hệ thống theo dõi các phiên bản.
Bao quát mô hình ở tất cả các mức độ trừu
tượng hóa khác nhau: công cụ cần phải dễ chuyển tải từ lời miêu tả ở
cấp trừu tượng hóa cao nhất của hệ thống (tức là ở dạng một lượng các gói khác
nhau) đi xuống cho tới cấp của những dòng code thật sự. Sau đó, để truy xuất
những dòng lệnh code cho một thủ tục cụ thể nào đó trong một lớp nào đó, bạn có
thể chỉ cần nhấp chuột vào tên của thủ tục đó trong một biểu đồ.
Trao đổi mô hình: Một mô hình hay một
biểu đồ của một mô hình nào đó cần phải có khả năng được xuất ra từ một công cụ
này rồi nhập vào một công cụ khác, giống như những dòng lệnh code được sản sinh
trong một công cụ này có thể được sử dụng trong một công cụ khác. Nguyên tắc
trao đổi đó cần phải được áp dụng cho các mô hình trong một ngôn ngữ mô hình
hóa được định nghĩa chính xác.
UML tổ chức một mô hình thành một loạt các hướng nhìn, thể
hiện các khía cạnh khác nhau của hệ thống. Chỉ khi kết hợp tất cả các hướng
nhìn lại với nhau, người ta mới co được một bức tranh trọn vẹn về hệ thống. Một
hướng nhìn không phải là một hình vẽ, nội dung của nó được miêu tả qua các biểu
đồ, đây là những hình vẽ chứa đựng các phần tử mô hình hóa. Một biểu đồ bình
thường chỉ trình bày một phần nội dung của một hướng nhìn, và một hướng nhìn
được định nghĩa với rất nhiều biểu đồ. Một biểu đồ chứa các phần tử mô hình, ví
dụ như lớp, đối tượng, nút mạng, thành phần và những mối quan hệ như nối kết,
khái quát hóa, phụ thuộc. Các phần tử này có ý nghĩa (semantic) và các ký hiệu
hình học.
Các loại biểu đồ trong UML là: biểu đồ lớp, biểu đồ đối
tượng, biểu đồ Use case, biểu đồ trạng thái, biểu đồ trình tự, biểu đồ cộng
tác, biểu đồ hành động, biểu đồ thành phần và biểu đồ triển khai. Mục đích của
các loại biểu đồ cũng như quy tắc vẽ chúng sẽ được miêu tả chi tiết trong
chương sau.
UML có một số cơ chế chung để bổ sung thông tin không thể
được thể hiện trong quá trình vẽ biểu đồ. Những thông tin này bao gồm ví dụ
những thành phần trang trí, các lời ghi chú có thể chứa bất kỳ loại thông tin
nào cũng như các thuộc tính đặc tả. Ngoài ra còn có các cơ chế mở rộng, bao gồm
giá trị đính kèm, hạn chế đối với phần tử, và khuôn mẫu, định nghĩa một loại
phần tử mô hình mới dựa trên một phần tử sẵn có.
Một hệ thống sẽ được miêu tả trong nhiều loại mô hình khác
nhau, mỗi loại mô hình nhằm một mục đích khác nhau. Mô hình phân tích miêu tả
những yêu cầu về mặt chức năng và mô hình hóa các lớp ngoài đời thực. Mô hình
thiết kế chuyển tải kết quả phân tích thành một giải pháp kỹ thuật, theo khái
niệm của một thiết kế phần mềm hoạt động hoàn chỉnh. Mô hình xây dựng code thể
hiện hệ thống qua việc thảo chương cho nó trong một ngôn ngữ lập trình hướng
đối tượng. Và cuối cùng, mô hình triển khai định vị chương trình vừa được tạo
nên trong một kiến trúc vật lý bao gồm các máy tính và các trang thiết bị. Công
việc được làm theo nhiều vòng lặp khác nhau chứ không phải chỉ là một chuỗi
thực hiện một lần.
Để sử dụng UML một cách nghiêm chỉnh cho một dự án có thật
ngoài đời, bạn cần công cụ. Một công cụ tân tiến có khả năng cho người dùng vẽ
biểu đồ, trữ tất cả các thông tin vào một kho chung, cho phép dễ dàng dịch chuyển
giữa các hướng nhìn và biểu đồ khác nhau trong mô hình, tạo báo cáo và tài
liệu, tạo khung code từ mô hình, đọc những dòng code sẵn có rồi sản sinh ra mô
hình từ đó, và dễ dàng tích hợp với các công cụ phát triển khác.
Hỏi: UML có công cụ nào giúp nắm bắt các yêu
cầu của khách hàng (người sử dụng)?
Đáp: Use Case
Hỏi: Một biểu đồ trong UML có bao chứa các
hướng nhìn khác nhau.
Đáp: Sai, một hướng nhìn bao gồm một loại các
biểu đồ khác nhau
Hỏi: Hãy liệt kê các thành phần chủ yếu của
ngôn ngữ UML
Đáp: Hướng nhìn( View), Biểu đồ (Diagram),
Phần tử mô hình, Cơ chế chung.
Hỏi: UML có công cụ nào phục vụ cho giai đoạn
thử nghiệm đơn vị (Unit Testing)?
Đáp: Biểu đồ lớp và đặc tả lớp
Hỏi: UML có công cụ nào phục vụ cho giai đoạn
thử nghiệm hệ thống (System Testing)?
Đáp: Use case Diagram
Hỏi: UML tạo nền tảng cho việc giao tiếp giữa
khách hàng, nhà phân tích, nhà thiết kế và lập trình viên.
Đáp: Đúng
Số lượt đọc:
2152
-
Cập nhật lần cuối:
24/03/2008 11:19:22 AM | 