Mô hình hóa hệ thống sử dụng UML

1/49

Đoàn Văn Ban OOA & D with UML

Mô hình hóa hệ thống sử dụng UML

Giới thiệu về UML Phân tích và đặc tả các yêu cầu hệ thống

+ Ca sử dụng

+ Tác nhân

+ Xác định các ca sử dụng và các tác nhân

+ Đặc tả các ca sử dụng Biểu đồ User Case Biểu đồ hành động (Activity Diagram) + Các hành động và quyết định + Sự đồng bộ và tương tranh giữa các hoạt động + Các luồng họat động + Xây dựng Biểu đồ họat động

CHAPTER 2

2/50

Đoàn Văn Ban OOA&D with UML

2.1. Giới thiệu

3/50


1. Mô hình được các hệ thống và sử dụng được tất cả các khái niệm hướng đối tượng một cách thống nhất.

2. Cho phép đặc tả, hỗ trợ để đặc tả tường minh mối quan hệ giữa các khái niệm cơ bản trong hệ thống, đồng thời mô tả được mọi trạng thái hoạt động của hệ thống đối tượng.

3. Tận dụng được những khả năng sử dụng lại và kế thừa ở phạm vi diện rộng để xây dựng được những hệ thống phức tạp và nhạy cảm như: các hệ thống động, hệ thống thời gian thực, hệ thống nhúng thời gian thực, v.v.

4. Tạo ra những ngôn ngữ mô hình hoá sử dụng được cho cản người lẫn máy tính.

Mục đích chính của UML

4/50


Các phần tử của UML

GóiMô hình

Hệ thống conKhung công việc

Ca sử dụngLogic

Thành phầnSự tương tranh

Triển khaiCa sử dụngLớp

Giao diện Thành phần

Cộng tácNút

Sự tương tácMáy trạng

thái

UML

Các quan sátCác sự vật Các biểu đồ

Các mối quan hệ

Hành viCấu trúc Gộp nhóm Phụ thuộcKết hợp

Kết nhậpTổng quát hoá

(kế thừa)

Chú dẫn Ca sử dụngLớp

Đối tượng Trình tựCộng tác

Trạng tháiHoạt động

Thành phầnTriển khai

5/50


Các quan sát (Views)

Quan sát thành phần

Quan sát triển khai Quan sát tương tranh

Quan sát logic

Quan sát ca sử dụng

6/50


Các quan sát (Views) + Quan sát các ca sử dụng: mô tả các chức năng, nhiệm vụ của hệ thống, được thể hiện trong các biểu đồ ca sử dụng (Use Case Diagram) và có thể ở một vài biểu đồ trình tự, cộng tác, v.v. + Quan sát logic biểu diễn tổ chức logic của các lớp và các quan hệ của chúng với nhau, được thể hiện trong các biểu đồ lớp, biểu đồ đối tượng, biểu đồ tương tác (Collaboration Diagram), biểu đồ biến đổi trạng thái (State Diagram). + Quan sát thành phần (quan sát cài đặt) xác định các mô đun vật lý hay tệp mã chương trình và sự liên hệ giữa chúng để tổ chức thành hệ thống phần mềm, được thể hiện trong các biểu đồ thành phần (Component Diagram) và các gói (package). + Quan sát tương tranh (quan sát tiến trình) biểu diễn sự phân chia các luồng thực hiện công việc, các lớp đối tượng cho các tiến trình (process) và sự đồng bộ giữa các luồng (thread) trong hệ thống. + Quan sát triển khai mô tả sự phân bổ tài tài nguyên và nhiệm vụ trong hệ thống, mô tả các tiến trình và chỉ ra những tiến trình nào trên máy nào.

7/50


Các biểu đồ (Diagrams)

Biểu đồ chứa đựng các nội dung của các quan sát dưới các góc độ khác nhau và một thành phần của hệ thống có thể xuất hiện trong một hay nhiều biểu đồ. +Biểu đồ các ca sử dụng: mô tả sự tương tác giữa các tác nhân ngoài (External Actor) và hệ thống thông qua các ca sử dụng. Các ca sử dụng là những nhiệm vụ chính, các dịch vụ, những trường hợp sử dụng cụ thể mà hệ thống cung cấp cho người sử dụng và ngược lại. +Biểu đồ lớp (Class Diagram) mô tả cấu trúc tĩnh, mô tả mô hình khái niệm bao gồm các lớp đối tượng và các mối quan hệ của chúng trong hệ thống hướng đối tượng. + Biểu đồ trình tự (Sequence Diagram) thể hiện sự tương tác của các đối tượng với nhau, chủ yếu là trình tự gửi và nhận thông điệp (message) để thực thi các yêu cầu, các công việc theo thời gian. + Biểu đồ cộng tác (Collaboration Diagram) nhấn mạnh vào sự tương tác của các đối tượng trên cơ sở cộng tác với nhau bằng cách trao đổi các thông điệp để thực hiện các yêu cầu theo ngữ cảnh công việc . +Biểu đồ trạng thái (State Diagram) thể hiện chu kỳ hoạt động của các đối tượng, của các hệ thống con và của cả hệ thống.

8/50


Các biểu đồ (Diagrams) - TT

+ Biểu đồ hành động (Activity Diagram) chỉ ra dòng hoạt động của hệ thống , bao gồm các trạng thái hoạt động, trong đó từ một trạng thái hoạt động sẽ chuyển sang trạng thái khác sau khi một hoạt động tương ứng được thực hiện . + Biểu đồ thành phần (Component Diagram) chỉ ra cấu trúc vật lý của các thành phần trong hệ thống, bao gồm: các thành phần mã nguồn, mã nhị phân, thư viện và các thành phần thực hiện được . + Biểu đồ triển khai (Deployment Diagram) chỉ ra cách bố trí vật lý các thành phần theo kiến trúc được thiết kế của hệ thống .

9/50


Các biểu đồ (Diagrams) - TT

10/50


11/50


Your Experiences, Please!2.1.1.

Defines Who is doing What, When to do it, and How to reach a certain goal.

12/50


2.1.1.

13/50


2.1.1.

14/50


2.1.1.

15/50


2.1.1.

16/50


2.1.1.

17/50


2.1.1.

18/50


2.1.2.

19/50


Nội dung:+ Mục đích của NSD và sự tương tác của các hệ

thống

+ Con người và các tác nhân của hệ thống

+ Quan hệ mở rộng giữa các Use Cases

+ Quan hệ sử dụng giữa Use Cases

2.2. Biểu đồ Use Case – Phân tích yêu cầu

20/50


21/50


2.2.1. Use CasesUse cases mô tả tập các hoạt động của hệ thống theo quan điểm

của các tác nhân ngoài (Actor). Nó mô tả các yêu cầu của hệ thống và trả lời cho câu hỏi:

Hệ thống phải làm cái gì (What ?). .

• “Hoạt động” là các chức năng, nhiệm vụ hay gọi chung là dịch vụ của hệ thống và nó thường được mô tả bằng các động từ, hay mệnh đề động từ đơn, ví dụ: bán hàng, thanh toán, khởi động hệ thống, v.v.

• Actor (Tác nhân) là thực thể bên ngoài có tương tác với hệ thống, bao gồm người, vật, thiết bị hay các hệ thống khác có trao đổi thông tin với hệ thống.

Hoạt động

Actor

22/50


2.2.2. Actor Actor đóng vai trò NSD hoặc là hệ thống khác có quan hệ

tương tác, trao đổi thông tin với hệ thống cần phát triển. Ví dụ:

• Giám đốc kinh doanh• Thương nhân• Người bán hàng• Hệ thống kế toán

Một actor trong một Biểu đồ use case có thể đóng nhiều vai trò sử dụng khác nhau.

Một actor có thể thực hiện nhiều use cases với những vai trò khác nhau.

23/50


Ví dụ:

24/50


2.2.3. Mối quan hệ giữa các Use Cases

1. Quan hệ Include thể hiện một hoạt động có thể là một phần chung của một số use cases. Quan hệ này được sử dụng khi có một UC cần thực hiện lặp lại một số lần (>= 2) trong các UC riêng biệt, nhưng lại muốn tránh việc viết lại UC đó.

2. Tổng quát hóa Use Case (Generalization) xuất hiện khi có một use case tương tự như use case khác, nhưng nó làm nhiều hơn chút ít.

3. Quan hệ Extend để mô tả sự thay đổi của một UC và muốn sử dụng dạng mở rộng của nó để thực hiện được nhiều hơn. Sự mở rộng use case không làm thay đổi được, do vậy cần

thiết phải tạo ra UC con của UC cho trước.

25/50


Cập nhật danh sách(UC1)

Tìm danh sách(UC2)

<<includes>>

Ví dụ: UC1 <<Includes>> UC2 nếu việc thực hiện UC1 luôn kéo theo việc thực hiện UC2.

Ví dụ: UC1 <<extends>> UC2 nếu UC1 cung cấp thêm chức năng mà UC2 chưa có.

Đăng nhập HT

Kiểm tra mật khẩu

<<extends>>

Ca sử dụng mở rộng

Ca sử dụng cơ sở

Để đăng nhập được vào một hệ thống phần mềm, ngoài việc kiểm tra mật khẩu (password) còn phải khai báo một số thuộc tính khác ví dụ như tên NSD chẳng hạn.

26/50


Ví dụ: Use Cases

Đối với NSD CSDL, use case có thể:• “Liệt kê tất cả những khách hàng đặt mua một sản phẩm nào đó”• “Tạo lập danh sách 10 khách hàng mua hàng nhiều nhất”• “Yêu cầu gửi các fax một cách tự động“

Người phát triển chịu trách nhiệm với đánh giá phí tổn:• “Danh sách 10 khách hàng có thể phát triển trong 1 tuần.”• “Tạo lập chức năng chuyển fax tự động có thể làm trong 1 tháng.”

NSD và Người phát triển có thể thỏa thuận với nhau về mức ưu tiên của UC:• Người phát triển: “Muốn bắt đầu bằng UC “Lập danh sách các sản phẩm

đã bán”

• NSD: “Cần danh sách 10 khách hàng đầu tiên”, …

27/50


2.2.4. Lập kế hoạch: Phân loại các Use Cases

NSD phải chỉ rõ mức độ ưu tiên của các UC.• “Tôi cần phải có chức năng này cho hệ thống.”• “Tôi có thể không cần chức năng này trong một thời gian ngắn• “Đây là chức năng quan trọng, nhưng chưa thật cần thiết lúc này.”

Người phát triển cần xem xét các rủi ro về kiến trúc• Không bỏ qua use cases mà sau đó phải thực hiện lại nhiều công việc

liên quan đến những UC đó. • Tập trung vào những use cases liên quan đến những thách thức của

công nghệ. Người phát triển phải biết trước về rủi ro trong lịch biểu thực hiện

dự án• “Cần phải biết công việc này phải thực hiện trong bao lâu”• “Đánh giá ước lượng thời gian theo người/tháng.”

28/50


2.2.5. Mục tiêu của NSD và sự tương tác của hệ thống

Nhiệm vụ của UC có thể khác nhau theo các quan điểm:• Mức miền ứng dụng (Application domain level): phản ánh được mục tiêu của NSD mong muốn thực hiện.• Mức thiết kế hệ thống (System design level): Thể hiện được sự tương tác của hệ thống yêu cầu.

Tầm quan trọng của việc xác định các mục tiêu

• Tìm các cách khác nhau để đạt được mục đích• Nắm bắt tất cả các yêu cầu của NSD.

Tầm quan trọng của sự tương tác hệ thống • Phục vụ cho việc xây dựng cấu trúc của hệ thống• Để thiết kế các chức năng, nhiệm vụ của hệ thống.

29/50


Sự tương tác với các hệ thống ngoài

Đối với sự tương tác với hệ thống ngoài có 4 cách tiếp cận:1. Chỉ ra mọi sự tương tác với hệ thống từ xa trên biểu đồ.2. Chỉ rõ sự tương tác bên ngoài khi có hệ thống khác bắt đầu

tương tác với hệ thống.3. Chỉ ra các tác nhân hệ thống chỉ khi họ là những đối tượng cần

use case.4. Không đối xử hệ thống như các tác nhân, nhưng sử dụng các

yêu cầu của NSD.+ Sử dụng các sự kiện bên ngoài để xác định use cases mà chưa xác định được thông qua các tác nhân.

+ Đề cập đến mọi sự kiện từ thế giới biên ngoài mà hệ thống cần phải tương tác.

30/50


2.2.6. Scenarios, Workflow, Object StructuresKịch bản (Scenario)+ Một dãy các hoạt động thể hiện sự tương tác giữa các tác nhân và hệ thống.

+ Một kịch bản được gọi là thể hiện của use case. Kịch bản chỉ ra một tập các hoạt động và tổ hợp các điều kiện bên trong use case.

Ví dụ, Đặt mua hàng:• Scenario 1: Tất cả các mặt hàng đều có.• Scenario 2: Thiếu một số mặt hàng .• Scenario 3: Tài khoản không đủ tiền.

Các quá trình (Processes) liên quan đến các use cases khác nhau trong các luồng công việc (workflows),

Cấu trúc Ví dụ, Quá trình từ đặt hàng, giao hàng và thanh toán. Cấu trúc (structure) của đối tượng (and actors) xuất hiện trong use cases

được mô tả bởi các lớp (classes),Ví dụ, Khách hàng, mặt hàng, hóa đơn.

31/50


2.2.7. Xây dựng biểu đồ UC+ Biểu đồ UC chỉ ra mối quan hệ giữa các tác nhân và các UC trong hệ thống

+ Mỗi UC cần phải biểu diễn trọn vẹn một giao dịch giữa NSD và hệ thống

Xác định các tác nhân. Một trong các kỹ thuật hỗ trợ để xác định các tác nhân là dựa trên các câu trả

lời những câu hỏi sau: Ai sẽ sử dụng các chức năng chính của hệ thống? Ai cần sự hỗ trợ của hệ thống để thực hiện các công việc hàng

ngày? Ai quản trị, bảo dưỡng để đảm bảo cho hệ thống hoạt động thường

xuyên? Hệ thống quản lý, sử dụng những thiết bị nào? Hệ thống cần tương tác với những bộ phận, hệ thống nào khác? Ai hay cái gì quan tâm đến kết quả xử lý của hệ thống?

32/50


2.2.7. Xây dựng biểu đồ UC (TT) + Biểu đồ UC chỉ ra mối quan hệ giữa các tác nhân và các UC trong hệ thống . + Mỗi UC cần phải biểu diễn trọn vẹn một giao dịch giữa NSD và hệ thống

Xác định các UC. Có hai phương pháp chính hỗ trợ giúp ta xác định các ca sử dụng:

1. Phương pháp thứ nhất là dựa vào các tác nhân Với mỗi tác nhân, tìm những tiến trình (chức năng) được khởi đầu,

hay giúp các tác nhân thực hiện, giao tiếp / tương tác với hệ thống.

2. Phương pháp thứ hai để tìm các ca sử dụng là dựa vào các sự kiện

Xác định những sự kiện bên ngoài có tác động đến hệ thống hay hệ thống phải trả lời ?

Tìm mối liên quan giữa các sự kiện và các ca sử dụng ?

33/50


2.2.7. Xây dựng biểu đồ UC (TT)

Đặc tả các UC: Format đặc tả UC

Ca sử dụng: Tên của ca sử dụng bắt đầu bằng động từ Các tác nhân: Danh sách các tác nhân liên quan đến ca sử

dụng, chỉ rõ ai bắt đầu với ca sử dụng Mô tả: Mô tả tóm tắt tiến trình xử lý công việc cần thực hiện Tham chiếu: Các chức năng, ca sử dụng và những hệ thống

liên quan

34/50



Trước khi xây dựng biểu đồ ca sử dụng chúng ta cần lưu ý:

Mỗi ca sử dụng luôn được ít nhất một tác nhân kích hoạt một cách trực tiếp hay gián tiếp, nghĩa là giữa tác nhân và ca sử dụng thường có mối quan hệ giao tiếp (kết hợp).

Ca sử dụng cung cấp các thông tin cần thiết cho tác nhân và ngược lại, tác nhân cung cấp dữ liệu đầu vào cho ca sử dụng thực hiện.

35/50



Ví dụ: Biểu đồ UC cho hệ thống bán hàng

Bán hàng

Đăng nhập hệ thống

Thu tiền

Người bán hàng

Bộ phận kiểm duyệt séc

Người quản lý Quản trị hệ thống

Khách hàng

Thu bằng thẻ tín dụngThu bằng séc

Thu tiền mặt

Khởi động hệ thống

Thêm / Loại bỏ NSDĐóng hệ thống

<<uses>>

<<uses>>

<<uses>> Bộ phận kiểm duyệt thẻ

36/50


2.3. Biểu đồ hoạt động AD (Activity Diagrams)

Hoạt động, quyết định Sự đồng bộ và tương tranh (Concurrency

& Synchronization) Các tuyến công việc (Swimlanes) Xây dựng biểu đồ hoạt động

37/50


2.3.1. Vai trò của AD trong UML

38/50


2.3.1. Vai trò của AD trong UML (TT)

39/50


2.3.2. Điều kiện (Guards)

Điều kiện xác định nhánh nào (trigger) được chọn để thực hiện.

Mỗi thời điểm chỉ một nhánh được thực hiện.

Do vậy, điều kiện (guards) thực sự phải loại trừ lẫn nhau!

40/50


2.3.3. Hành động theo quyết định

41/50


2.3.4. Các hoạt động tương tranh

Có sự khác nhau giữa lưu đồ (flowcharts) và AD ở chỗ trong AD, các hoạt động có thể thực hiện song song hoặc tương tranh với nhau.

Vấn đề quan trọng trong mô hình nghiệp vụ là những quá trình không cần thực hiện tuần tự thì có thể thiết kế để thực hiện song song nhằm nâng cao tốc độ thực hiện.

Do đó, cải thiện được tính hiệu quả và sự thuận tiện của quá trình nghiệp vụ.

AD được sử dụng rất hữu hiệu cho việc mô tả các chương trình song song, ta có thể sử dụng đồ họa để mô tả các luồng thực hiện đồng thời và cho phép đồng bộ (synchronize) khi cần thiết.

42/50


2.3.4.1. Thanh đồng bộ Thanh đồng bộ (Synchronization bars) khởi đầu những bộ phận có thể thực

hiện đồng thời (concurrent sections) trong AD. Trong các bộ phận đồng thời, tất cả các nhánh có thể thực hiện song song và

không yêu cầu tuần tự.

43/50


2.3.4.1. Thanh đồng bộ (TT) Thanh đồng bộ cho phép các hoạt động xảy ra đồng thời.

44/50


2.3.4.2. Điều kiện đồng bộ

Xác định điều xảy ra đồng thời.

45/50


2.3.4.2. Điều kiện đồng bộ (TT)Nhiều nhánh vào

Đối với các thanh đồng bộ, nhánh ra sẽ được thực hiện chỉ khi tất cả các nhánh vào đã thực hiện xong.

46/50


2.3.4.2. Điều kiện đồng bộ (TT)

47/50


2.3.5. Tuyến công việc (Swimlanes)

Activity diagrams thể hiện cái gì sẽ xảy ra, nhưng nó không nêu được ai làm cái gì. Về phương diện cài đặt, có nghĩa là AD không thể hiện được lớp đối

tượng nào chịu trách nhiệm thực hiện công việc nào. Về phương diện miền ứng dụng, không thể hiện được người nào

chịu trách nhiệm thực hiện công việc nào.

Tuyến công việc là cách để giải quyết vấn đề trên. Tuyến công việc được thể hiện trên AD bằng các đường đứt nét để

tách các vùng theo các nhóm người thực hiện. Mỗi vùng được dành riêng cho một lớp đối tượng, người hay phòng

ban nào đó, …

48/50


49/50


2.3.5. Tuyến công việc (TT) Khi nào cần Activity Diagrams?

Activity diagrams thể hiện những hành vi trải rộng qua nhiều use cases để mô tả luồng công việc của cả quá trình.

Đối với những đối tượng tương tác với nhau ở mức cao, activity diagrams sẽ rất hiệu quả để biểu diễn những quá trình tương tranh.

Khong sử dụng activity diagrams để mô tả sự tương tác của các đối tượng. Activity diagrams không mô tả được chính xác hoạt động của các đối tượng

theo thời gian.

50/50


2.3.5. Tuyến công việc (TT) Ví dụ: Biểu đồ hành động “Thanh toán bằng Credit”

:Khách hàng : Người bán hàng :CreaditAuthorizationService :HBH

Trả bằng CreditNhận Credit

Kiểm duyệt

Trừ vào CreditTrả bằng Credit

[Hợp lệ]

[Không hợp lệ]

Documents

Mô hình hóa hệ thống sử dụng UML