Mô hình hóa quy trình kinh doanh với sơ đồ hoạt động

• Trong chương này chúng ta sẽ thảo luận về cách Thu thập thông tin bằng cách sử dụng các kỹ thuật được tổ chức và trình bày dưới dạng các hoạt động diagrams và các use case • Một mô hình quy trình có thể được sử dụng để ghi lại hệ thống hiện tại hoặc một hệ thống tương lai • Ngày nay đều sử dụng sơ đồ hoạt động và sử dụng các trường hợp để lập tài liệu và sắp xếp các yêu cầu thu được trong quá trình phân tích giai đoạn. Được sử dụng cho bất kỳ loại hoạt động mô hình hóa quy trình nào.

Mục lục

I Giới thiệu khái quát 3

II Mô hình hóa quy trình kinh doanh với sơ đồ hoạt động 4

1 Các yếu tố của một sơ đồ hoạt động 4

2 Nguyên tắc tạo sơ đồ hoạt động: 7

III Tạo mô tả Use-case 8

1 Mô tả Use-case: 8

2 Các loại Use-case: 9

IV Sơ đồ Usecase: 9

V Câu hỏi trắc nghiệm 15

I Giới thiệu khái quát.

 Trong chương này chúng ta sẽ thảo luận về cách Thu thập thông tin bằng cách sử dụng các kỹ thuật được tổ chức và trình bày dưới dạng các hoạt động diagrams và các use- case

 Một mô hình quy trình có thể được sử dụng để ghi lại hệ thống hiện tại hoặc một hệ thống tương lai

 Ngày nay đều sử dụng sơ đồ hoạt động và sử dụng các trường hợp để lập tài liệu và sắp xếp các yêu cầu thu được trong quá trình phân tích giai đoạn Được sử dụng cho bất kỳ loại hoạt động mô hình hóa quy trình nào

 Định nghĩa Usecase: Usecase là một chuỗi các hành động mà hệ thống thực

hiện mang lại một kết quả quan sát được đối với actor Có thể hiểu một Use-Case là một chức năng của hệ thống, mang một ý nghĩa nhất định đối với người dùng Use case là một cách chính thức để biểu diễn, trong đó hệ thống kinh doanh tương tác với môi trường của nó

 Mô hình use cases thường được coi là một cái nhìn bên ngoài hoặc chức

năng của một doanh nghiệp quy trình trong đó nó hiển thị cách người dùng xem quy trình & ghi lại hệ thống hiện tại hoặc hệ thống mới đang được phát triển Là mô hình logic (mô hình mô tả các hoạt động của lĩnh vực kinh doanh mà không đề xuất cách chúng được tiến hành) Sơ đồ hoạt động và các Usecase là các mô hình logic - các mô hình mô tả các hoạt động của lĩnh vực kinh doanh mà không đề xuất cách chúng được tiến hành

 Định nghĩa Activity diagrams:Là một mô hình logic dùng để mô hình hoá các hoạt động trong một quy trình nghiệp vụ (hay là sơ đồ luồng xử lý của

hệ thống) dùng để mô tả các hoạt động trong một chức năng của hệ thống (hay là luồng xử lý của một Use–Case) Mô tả hoạt động chính và mối quan

hệ giữa các hoạt động này trong quy trình (hay là mô tả cả luồng xử lý chính của hệ thống bao gồm các luồng con, luồng xử lý của các Use – Case gom lại mà thành)

 Một mảnh thông tin được thu thập dưới dạng giấy hoặc qua Web; hoặc nếu thông tin được đặt trong một tủ đựng hồ sơ hoặc một cơ sở dữ liệu lớn Các chi tiết này được gọi là chi tiết vật lý được xác định trong quá trình thiết kế khi các mô hình logic được chỉnh thành các mô hình vật lý Các mô hình này cung cấp thông tin cần thiết để cuối cùng xây dựng hệ thống Bằng cách tập trung vào các hoạt động logic trước tiên, có thể tập trung vào cách hoạt động của doanh nghiệp mà không bị phân tâm bởi các chi tiết liên quan

 Cách thức hoạt động: Bước đầu tiên, nhóm dự án thu thập các yêu cầu từ

người dùng

II Mô hình hóa quy trình kinh doanh với

sơ đồ hoạt động.

Mô hình quy trình kinh doanh mô tả các hoạt động khác nhau, khi kết hợp với nhau để hỗ trợ một quy trình kinh doanh Các quy trình kinh doanh thường tác động (cut across) đến các bộ phận chức năng & từ một quan điểm hướng đối tượng, chúng sẽ tác động đến nhiều đối tượng → có hướng bỏ qua quy trình kinh doanh làm mẫu, tập trung vào UC & mô hình hành vi Mô hình bản thân các quy trình kinh doanh là một hoạt động mang tính xây dựng được sử dụng để thực hiện nhận ra các yêu cầu đã được thu thập Có xu hướng củng cố một tư duy phân rã chức năng Là một công cụ rất mạnh để truyền đạt sự hiểu biết hiện tại của nhà phân tích về các yêu cầu với người dùng Sơ đồ hoạt động gồm ký hiệu đề cập đến việc mô hình hóa các hoạt động song song & các quá trình quyết định phức tạp →

có thể được sử dụng để mô hình hóa bất kỳ loại quy trình nào

1. Các yếu tố của một sơ đồ hoạt động

Action

■ Là một hành vi đơn giản, không thể phân hủy

■ Được gắn nhãn theo tên của nó

Activity

■ Được sử dụng để đại diện cho một tập hợp các

hành động

■ Được gắn nhãn theo tên của nó

Object node:

■ Được sử dụng để biểu diễn một đối tượng được

kết nối với một tập hợp các luồng đối tượng

-Control flow

■ Hiển thị trình tự thực hiện

Object flow

■ Hiển thị luồng của một đối tượng

từ một hoạt động (hoặc hành động)

sang hoạt động khác (hoặc hành động)

Fork: được sử dụng để chia hành

vi của quy trình nghiệp vụ thành

nhiều luồng song song hoặc đồng

thời (tức là cả hai đường dẫn đều

được thực thi đồng thời)

Join: thể hiện trường hợp phải

thực hiện hai hay nhiều hành động

trước rồi mới thực hiện hành động

tiếp theo

Initial node

■ Vẽ chân dung phần đầu của một

tập hợp các hành động hoặc hoạt động

Final-activity node

■ Được sử dụng để dừng tất cả các

luồng điều khiển và luồng đối tượng

trong một hoạt động (hoặc hành động)

Final-flow node

■ Được sử dụng để dừng một

luồng điều khiển hoặc luồng đối tượng

cụ thể

Decision node

■ Được sử dụng để đại diện cho

một điều kiện kiểm tra để đảm bảo

rằng luồng điều khiển hoặc luồng đối

tượng

chỉ đi xuống một con đường

■ Được gắn nhãn với các tiêu chí

quyết định để tiếp tục đi theo con

đường cụ thể

Merge node

■ Được sử dụng để tập hợp lại các

đường dẫn quyết định khác nhau đã

được tạo bằng cách sử dụng nút quyết

định

Hình 5-2 trình bày một sơ đồ hoạt động đại diện cho một phần của hệ thống đặt hẹn cho phòng khám bác sĩ

(Actions and Activities) có thể thể hiện hành vi thủ công hoặc được máy tính

hóa Cho thấy sáu tỷ lệ riêng biệt nhưng có liên quan đến hệ thống cuộc hẹn điển hình được sử dụng trong phòng khám bác sĩ: Lấy thông tin bệnh nhân, Tạo bệnh nhân mới, Sắp xếp thanh toán, Tạo cuộc hẹn, Cancel Cuộc hẹn và Thay đổi cuộc hẹn

(Object Nodes) Về cơ bản, các nút đối tượng đại diện cho luồng thông tin từ

một hoạt động đến một hoạt động khác Hình cho thấy đối tượng từ các hoạt động

Tạo Cuộc hẹn và Thay đổi Cuộc hẹn

(Control Flows and Object Flows) Hình 5-2 mô tả một loạt các luồng kiểm

soát thông qua hệ thống cuộc hẹn của phòng khám bác sĩ Dòng đối tượng mô hình dòng chảy của các đối tượng thông qua một quy trình kinh doanh Vì Actions and Activities sửa đổi hoặc chuyển đổi các đối tượng, các luồng đối tượng là cần thiết

để hiển thị các đối tượng chảy vào và ra khỏi các Actions and Activities.Một dòng đối tượng được mô tả như một đường đứt nét với một đầu mũi tên trên đó hiển thị hướng dòng chảy Một luồng đối tượng riêng lẻ phải được gắn với một Actions and Activities ở một đầu và một nút đối tượng ở đầu kia

Decision và Merge trong Hình 5-2, nút decision ngay bên dưới hoạt động (get patient information) nhận thông tin có hai con đường loại trừ lẫn nhau có thể được thực thi: một cho bệnh nhân cũ hoặc trước đó, một cho bệnh nhân mới Các Merge được sử dụng để kết hợp nhiều đường dẫn loại trừ lẫn nhau đã được phân chia dựa trên quyết định trước đó

Tuy nhiên, đôi khi, vì mục đích rõ ràng, tốt hơn là không nên sử dụng một nút hợp nhất trong Hình 5-3 nút Decision đang phát nhiệm vụ kép trong sơ đồ bên phải Nó cũng đóng vai trò như một nút Merge Nói về mặt kỹ thuật, chúng ta không nên bỏ qua nút Merge, tuy nhiên, đôi khi nó đúng về mặt kỹ thuật theo quy tắc lập sơ đồ của UML có thể thực sự khiến sơ đồ trở thành hợp nhất

Trong Figure 5-4, nút fork được sử dụng để chỉ ra rằng hai quá trình song song, đồng thời sẽ được thực thi Trong trường hợp này, mỗi tiến trình được thực thi bởi hai bộ xử lý riêng biệt (Parent) Mục đích của nút join tự như mục đích của nút merge Nút join chỉ đơn giản là đưa trở lại để tập hợp các luồng song song hoặc đồng thời riêng biệt trong quy trình kinh doanh thành một luồng duy nhất

(Swimlanes): Hình 5-4 các Swimlanes được sử dụng để chia parent làm bữa trưa ở trường bao gồm ăn bánh mì kẹp bơ đậu phộng và thạch, đồ uống và món tráng miệng Trong trường hợp này, sử dụng Swimlanes thẳng đứng Chúng ta cũng có thể vẽ sơ đồ hoạt động bằng cách sử dụng hướng từ trái sang phải nhiều hơn thay vì hướng từ trên xuống Trong trường hợp đó, Swimlanes sẽ được vẽ theo chiều ngang.

2. Nguyên tắc tạo sơ đồ hoạt động:

Gồm 5 nguyên tắc:

- Đặt cho sơ đồ một tiêu đề thích hợp

- Xác định các hoạt động, luồng kiểm soát và luồng đối tượng xảy ra giữa các hoạt động

- Nên xác định bất kì quyết định nào là một phần của quá trình đang được mô hình hóa

- Bạn nên cố gắng xác định bất kì triển vọng nào cho sự song song trong quá trình này

- Vẽ sơ đồ hoạt động.

III.Tạo mô tả Use-case

1 Mô tả Use-case:

 Mô tả Use-case là những mô tả đơn giản về các chức năng của hệ thống từ cái nhìn tổng quan của người dùng Biểu đồ use-case là sơ đồ chức năng trong đó chúng mô tả các chức năng cơ bản của hệ thống — nghĩa là người dùng có thể làm gì và hệ thống sẽ phản hồi như thế nào đối với hành động của người dùng Mô tả use-case chứa tất cả thông tin cần thiết để tạo sơ đồ use-case Mô tả use-case hoặc sơ đồ use-case về mặt kỹ thuật, nó thực sự không quan trọng Cả hai đều phải được thực hiện để mô tả đầy đủ các yêu cầu mà một hệ thống thông tin phải đáp ứng Một use-case giao tiếp ở mức cao những gì hệ thống cần phải làm và tất cả các kỹ thuật lập sơ đồ UML xây dựng dựa trên điều này bằng cách trình bày chức năng use cases theo một cách khác cho một mục đích khác

 Use-cases nắm bắt sự tương tác điển hình của hệ thống với người dùng của

hệ thống

 Những tương tác này thể hiện cái nhìn bên ngoài hoặc chức năng của hệ thống từ quan điểm của người dùng Mỗi use-case mô tả một và chỉ một chức năng trong đó người dùng tương tác với hệ thống,

 Điều quan trọng cần nhớ là các use cases được sử dụng cho cả mô hình hành

vi hiện tại và tương lai

1 Viết mỗi tập hợp dưới dạng chủ ngữ-động từ-tân ngữ trực tiếp

2 Đảm bảo rõ ràng ai là người khởi xướng bước này: là người tiếp nhận hành động trong mỗi bước Thông thường, người khởi xướng nên là chủ ngữ của câu và người nhận phải là đối tượng trực tiếp của câu

3 Viết các bước từ quan điểm của người quan sát độc lập: mỗi bước có thể phải được viết trước từ quan điểm của cả người khởi tạo và người nhận

4 Viết mỗi bước ở cùng một mức độ trừu tượng: Mỗi bước sẽ tạo ra cùng một mức độ tiến bộ để hoàn thành Use case như mỗi bước khác Trên Use case cấp cao,

số lượng tiến trình có thể rất đáng kể, trong khi ở Use case cấp thấp, mỗi bước chỉ

có thể đại diện cho tiến trình gia tăng

5 Đảm bảo use cases có một tập hợp các bước hợp lý: Mỗi Use case phải đại diện cho một giao dịch, mỗi Use case nên bao gồm bốn phần:

 1 Tác nhân chính bắt đầu thực thi Use case bằng cách gửi một yêu cầu (và

có thể cả dữ liệu) vào hệ thống

 2 Hệ thống đảm bảo rằng yêu cầu (và dữ liệu) là hợp lệ

 3 Hệ thống xử lý yêu cầu (và dữ liệu) và có thể thay đổi trạng thái bên trong của chính nó

 4 Hệ thống gửi tác nhân chính kết quả xử lý

6 Áp dụng nguyên tắc KISS một cách phóng khoáng: Nếu Use case trở nên quá phức tạp và / hoặc quá dài, Use case phải được phân tách thành một tập Use case Hơn nữa, nếu luồng sự kiện bình thường của Use case trở nên quá phức tạp, thì nên

sử dụng luồng con

7 Viết hướng dẫn lặp lại sau tập hợp các bước được lặp lại: Lặp lại các bước cho đến khi đáp ứng một số điều kiện sau bước cuối Điều này làm cho trường hợp

sử dụng dễ đọc hơn đối với những người không quen với lập trình

2 Các loại Use-case:

 Overview versus detail: được sử dụng để cho phép nhà phân tích và người

dùng đồng ý về tổng quan cấp cao của các yêu cầu và được tạo ra rất sớm trong quá trình hiểu các yêu cầu hệ thống và chỉ ghi lại thông tin cơ bản về use-case

 Essential versus real: là use case chỉ mô tả những vấn đề thiết yếu tối thiểu

cần thiết để hiểu được chức năng cần thiết các use cases thiết yếu không phụ thuộc vào việc triển khai, trong khi use cases thực là các mô tả chi tiết về cách sử dụng hệ thống sau khi nó được triển khai

IV Sơ đồ Usecase:

Một nhà phân tích có thể sử dụng sơ đồ UC để hiểu rõ hơn về chức năng của hệ thống ở mức rất cao & được vẽ sớm trong SDLC (Software Development Life Cycle) Thu thập và xác định các yêu cầu cho hệ thống UC có thể khuyến khích người dùng cung cấp các yêu cầu bổ sung mà UC đã viết có thể không phát hiện ra

An Actor:

■ Là một cá nhân hoặc hệ thống thu

được lợi ích từ bên ngoài và bên ngoài

đối tượng

■ Được mô tả như một hình gậy (mặc

định) hoặc nếu một Actor không phải

của con người có liên quan, như một

hình chữ nhật với <<Actor>> trong đó

(thay thế)

■ Được gắn nhãn với vai trò của nó

■ Có thể liên kết với các Actor khác

bằng cách sử dụng kết hợp chuyên môn

hóa / siêu lớp, được biểu thị bằng một

mũi tên có đầu mũi tên rỗng

■ Được đặt bên ngoài ranh giới đối

tượng

A Use case:

■ Trình bày một phần chính của chức

năng hệ thống

■ Có thể mở rộng Use case khác

■ Có thể bao gồm một Use case khác

■ Được đặt bên trong ranh giới hệ thống

■ Được gắn nhãn với cụm động từ -

danh từ mô tả

Ranh giới chủ đề (A subject boundary)

■ Bao gồm tên của đối tượng bên trong

hoặc bên trên

■ Đại diện cho phạm vi của chủ đề, ví

dụ, một hệ thống hoặc một quy trình

kinh doanh riêng lẻ

Mối quan hệ kết hợp (An association

relationship)

■ Liên kết một diễn viên với Use case

mà nó tương tác

(An include relationship) Mối quan hệ

bao gồm:

■ Đại diện cho việc bao gồm chức năng

của một Use case trong một Use case

khác

■ Có một mũi tên vẽ từ Use case gốc

đến Use case đã sử dụng

(An extend relationship) Một mối quan

hệ mở rộng:

■ Đại diện cho phần mở rộng của Use

case để bao gồm hành vi tùy chọn

■ Có mũi tên vẽ từ Use case mở rộng

đến Use case cơ sở

(A generalization relationship) Mối quan

hệ tổng quát hóa:

■ Đại diện cho một Use case chuyên biệt

sang một Use case tổng quát hơn

■ Có một mũi tên vẽ từ Use case chuyên

dụng đến Use case cơ sở

• Overview Information: xác định use case và cung cấp thông tin cơ bản về use case Một Use case có thể có nhiều bên liên quan có lợi ích trong Use case Như vậy, mỗi Use case liệt kê từng bên liên quan với mối quan tâm của mỗi bên trong Use case

• Relationships: giải thích cách Use case liên quan đến các Use case và người dùng khác Có bốn kiểu quan hệ cơ bản: association, extend, include, and

generalization

• Association: ghi lại thông tin liên lạc diễn ra giữa Use case và các actor sử dụng Use case Actor là đại diện UML cho vai trò của người dùng trong use case

• Extend: đại diện cho việc mở rộng chức năng của use- case để kết hợp hành

vi tùy chọn

• Include: thể hiện sự bao gồm bắt buộc của một trường hợp sử dụng khác Mối quan hệ bao gồm cho phép phân tách chức năng để chia nhỏ một use-case phức tạp thành nhiều use-case đơn giản hơn

• Generalization: cho phép các use-case hỗ trợ tính kế thừa Hành vi chuyên biệt sẽ được đặt trong trường hợp sử dụng chuyên biệt thích hợp

• Flow of Events:

• Normal flow of events: bao gồm những bước thường được thực hiện trong một use-case Các bước được liệt kê theo thứ tự thực hiện

• Subflows: Normal flow of events nên được phân tách thành một tập hợp các subflows để giữ cho luồng sự kiện bình thường càng đơn giản càng tốt

• Alternate or exceptional flows: là những luồng có xảy ra nhưng không được coi là chuẩn mực Những điều này phải được lập thành văn bản