4. Process view
4.4. Biểu đồ hoạt động (Activity diagram):
Biểu đồ hoạt động nắm bắt hành động và các kết quả của chúng. Biểu đồ
hoạt động tập trung vào công việc được thực hiện trong khi thực thi
một thủ
tục (hàm), các hoạt động trong một lần thực thi một trường hợp sử dụng
hoặc trong một đối tượng. Biểu đồ hoạt động là một biến thể của biểu đồ
trạng thái và có một mục tiêu tương đối khác, đó là nắm bắt hành động
(công việc và những hoạt động phải được thực hiện) cũng như kết quả của
chúng theo sự biến đổi trạng thái. Các trạng thái trong biểu đồ hoạt động
(được gọi là các trạng thái hành động) sẽ chuyển sang giai đoạn kế
tiếp khi
hành động trong trạng thái này đã được thực hiện xong (mà không
xác định
bất kỳ một sự kiện nào theo như nội dung của biểu đồ trạng thái).
Một sự
- Để nắm bắt công việc (hành động) sẽ phải được thực thi khi
một thủ
tục được thực hiện. Đây là tác dụng thường gặp nhất và quan trọng
nhất của
biểu đồ hoạt động.
- Để nắm bắt công việc nội bộ trong một đối tượng.
- Để chỉ ra một nhóm hành động liên quan có thể được thực thi
ra sao,
và chúng sẽ ảnh hưởng đến những đối tượng nằm xung quanh chúng như
thế nào.
-Để chỉ ra một trường hợp sử dụng có thể được thực thể hóa
như thế
nào, theo khái niệm hành động và các sự biến đổi trạng thái của đối tượng.
-Để chỉ ra một doanh nghiệp hoạt động như thế nào theo các khái
niệm công nhân (tác nhân), qui trình nghiệp vụ (workflow), hoặc tổ
chức và
đối tượng (các khía cạnh vật lý cũng như tri thức được sử dụng trong doanh
nghiệp).
Biểu đồ hoạt động có thể được coi là một loại Flow chart. Điểm khác biệt là
Flow Chart bình thường ra chỉ được áp dụng đối với các qui trình tuần tự,
4+lView Architecture in UML37
Khi một người gọi tác vụ PrintAIICustomer (trong lớp CustomerVVindovv), các hành động khởi động, hành động đầu tiên là hiện một hộp thông báo lên
màn hình; hành động thứ hai là tạo một tập tin PostScript; hành động thứ ba
là gởi file PostScript đến máy in; và hành động thứ tư là xóa hộp thông báo trên màn hình. Các hành động được chuyển tiếp tự động; chúng xảy ra ngay
khi hành động trong giai đoạn nguồn được thực hiện.
Các sự thay đổi có thể được bảo vệ bởi các điều kiện canh giữ (Guard- condition), các điều kiện này phải được thỏa mãn thì sự thay đổi mới nổ ra. Một ký hiệu hình thoi được sử dụng để thể hiện một quyết định. Ký hiệu
quyết định có thể có một hoặc nhiều sự thay đổi đi vào và một hoặc nhiều
sự thay đổi đi ra được dán nhãn đi kèm các điều kiện bảo vệ. Bình thường
ra, một trong số các sự thay đổi đi ra bao giờ cũng được thỏa mãn (là đúng).
Một sự thay đổi được chia thành hai hay nhiều sự thay đổi khác sẽ dẫn đến
các hành động xảy ra song song. Các hành động được thực hiện đồng thời,
mặc dù chúng cũng có thể được thực hiện lần lượt từng cái một. Yếu
tố quan
trọng ở đây là tất cả các thay đổi đồng thời phải được thực hiện trước khi
chúng được thống nhất lại với nhau (nếu có). Một đường thẳng nằm ngang
kẻ đậm (còn được gọi là thanh đồng hộ hóa - Synchronisation Bar)
- Thanh đồng bộ hóa (Synchronisation bar): chúng cho phép ta
mở ra
Thanh đồng bộ hóa
- Điều kiện canh giữ (Guard Condition): các biểu thức logic có
giá trị
hoặc đúng hoặc sai. Điều kiện canh giữ được thể hiện trong ngoặc
vuông, ví
[Customer existing].
- Điểm quyết định (Decision Point)’. được sử dụng để chỉ ra các
sự thay
đổi khả thi. Kí hiệu là hình thoi.
Hình sau đây miêu tả một đoạn biểu đồ hoạt động của máy ATM. Sau
khi thẻ
được đưa vào máy, ta thấy có ba hoạt động song song: - Xác nhận thẻ
- Xác nhận mã số PIN
- Xác nhận số tiền yêu cầu được rút
4+lView Architecture in UML39
Biểu đồ hoạt động của máy ATM
4.5 LƯỢC đô thành phần (Component diagram):
Mô tả mối liên hệ giữa các thành phàn trong hệ thống, mỗi thành phần trong
hệ thống bao gồm có: > Tập tin source code.
> Thư viện liên kết (DLL). M
> Chương trình thực thi (EXE). o
> Cơ sở dữ liệu. °
ư-> QJ
Component diagram mô tả hệ thống quản lý TKB
4.6 LƯỢC đồ triển khai (deployment diagram):
Mô tả kiến trúc vật lý các thành phần bên trong hệ thống và tương
tác giữ chúng, bao gồm kiến trúc phần cứng và phần mềm. một hệ
thống có thể triển khai theo các lược đồ sau: > Triển khai theo máy đơn.
£> ■ w Ar c hi te ct ur e in U M
4+lView Architecture in UML42
Mô tả quản lý thời khóa biểu
0 0
r
5. Loqỉcal vỉew
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 hệ thống. 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 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.
Cấu trúc tĩnh được miêu tả bằng các biểu đồ lớp (class diagram) và biểu đồ
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)
4+lView Architecture in UML44
Hình 2.1: Biểu đồ lớp tổng quát cho môt Project
5.2 Object diagrams
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. Chúng giúp hiểu biểu đồ lớp dễ dàng hơn khi các mối quan hệ
giữa các
lớp trở nên phức tạp.
Hình 2.2: Biểu đồ lớp của trường ĐHBKHN
5.3 Package diagrams
Package Diagrams chỉ đơn giản là một loại biểu đồ bao gồm các "gói", Khi
một biểu đồ có các gói này thì thường nó không được định rõ là một loại biểu
đồ nào cả, mặc dù nó mang trong mình các thành phần đặc trưng
Biểu đồ này thường được dùng để gom nhóm các phần tử trong mô hình hướng đối tượng. Như gom nhóm các classes in Class Diagrams, gom nhóm
các components hoặc processes trong Component Diagrams, hoặc gom
5.4 Composite structure Diagrams
Biểu đồ này chỉ ra cấu trúc bên trong của các class, bao gồm cả sự
tương tác
giữa các phần trong hệ thống. Nó thể hiện cả hình dáng và mối quan
4+lView Architecture in UML47
5.5 State machine diagrams
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 o
loaithuoc
nuocSX
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 đồ
Hình 2.3: Biểu đồ máy trạng thái tính năng search cho một trang có đăng nhập
5.6 Mô hình hóa với góc nhìn Logic
Khi mô hình hóa với góc nhìn Logic, bắt đầu là biểu đồ Class và Package và s mở rộng nếu cần thiết. UML cũng có thế mô hình hóa dữ liệu dùng biếu đồs quan hệ thực thể (Entity Relationship Diagram). ER Diagram có thể được coi
ưì' là một dạng khác của Logic view. Một số kiến trúc phần mềm khác phân ER
<u donvitỉnhlD loaithuocID nuocID
Có thuocl I) Thuộc * thuoc ---S| Z" (^ngay nhâp^) Gồm Gồm 2k. donnhap donnhapll) donthuoc Thuộc
nhacungcap dỡituong % benhnharì
nhaeungcaplD c doiiuonglD bcnhnhanỉD
0 0 rsl Entity Relationship Diagram của Hệ thống quản lý dược phẩm
4+lView Architecture in UML50
Các bước mô hình hóa với Logical View
Bl: Dùng Class Diagram để mô hình hóa hệ thống.
B2: Dùng Package Diagram để gom nhóm các Lớp hay các phần tử có cùng
namespace. [Tùy chon:]
B3: Dùng Object Diagram để biếu diễn mối quan hệ giữa các thực thế của
các lớp
B4: Dùng State Diagram khi các trạng thái bên trong của một class cần được
giải thích rõ ràng.
B5: Dùng Composite structure Diagram khi muốn thể hiện quan hệ giữa
00
6. Mối liên hệ giữa các View
Logical View và Process View cùng ở cấp độ khái niệm và đều được sử
dụng từ phân tích đến thiết kế. Implementation View và Deployment View ở
mức độ physical và miêu tả các thành phần ứng dụng thực tế đã được xây
dựng và triển khai.
Logical View và Implementation View có mối liên hệ chặt chẽ với nhau.
Chúng mô tả bằng cách nào mà các chức năng được mô hình hóa và thực
hiện. Process View và Deployment View thực hiện các khía cạnh phi chức năng sử dụng các mô hình hành vi và vật lý. 0 0 r O)
4+lView Architecture in UML52
7. Kết luận
UML 2 đã tạo ra nhưng cải thiện đáng kể trong cấu trúc của nó và có ảnh
hưởng đến các mô tả trong Logical View và Process View. Các View thêm vào
như Security View và Data View có thể được thêm vào dựa trên các yêu cầu
0 0
r