BÁO cáo phát triển phần mềm hướng dịch vụ chapter 6phân tích và tạo mô hình với các dịch vụ web và microservices

Bắt đầu đệ trình Bảng chấm công Bước Xác minh Bảng chấm công thực sự là một quy trình con theo đúng nghĩa của nó và có thể do đó, hãy chia nhỏ thành các bước chi tiết hơn sau: 2a.. Xác

Trang 1

Học viện Công nghệ Bưu chính Viễn Thông

-*** -BÁO CÁO Phát triển phần mềm hướng dịch vụ

Trang 2

MỤC LỤC:

6.1 Quy trình mô hình hóa dịch vụ web 2

6.1.1 Bước 1: Phân tách Quy trình kinh doanh 3

6.1.2 Bước 2: Lọc ra các hành động không phù hợp 8

6.1.3 Bước 3: Xác định ứng cử viên entity service (Define Entity Service Candidates) 10

6.1.4 Bước 4: Xác định logic cụ thể của quy trình(Identify Process-Specific Logic) 15

6.1.5 Bước 5: Áp dụng hướng dịch vụ 17

6.1.6 Bước 6: Xác định các ứng cử viên thành phần dịch vụ 19

6.1.7 Bước 7: Phân tích các yêu cầu xử lý 20

6.1.8 Bước 8: Xác định ứng viên dịch vụ tiện ích 22

6.1.9 Bước 9: Xác định ứng viên Microservice (Define Microservice Candidates) 23

6.1.10 Bước 10: Áp dụng Định hướng Dịch vụ (Apply Service-Orientation) .24

6.1.11 Bước 11: Điều chỉnh các ứng cử viên thành phần dịch vụ 25

6.1.12 Bước 12: Sửa đổi nhóm ứng viên năng lực 26

2

Trang 3

Nội dung

6.1 Quy trình mô hình hóa dịch vụ web

Về cơ bản, một quy trình mô hình hóa dịch vụ có thể được xem như một bài tập trong việc tổ chức thông tin chúng tôi thu thập được trong Bước 1 và 2 của quy trình phân tích hướng dịch vụ gốc đã được mô tả trong Chương 4 Hình6.1 cung cấp một quy trình mô hình hóa dịch vụ chung phù hợp cho các dịch vụ Web có thể được tùy chỉnh thêm Chương này theo sau dịch vụ chung này quá trình mô hình hóa bằng cách mô tả từng bước và cung cấp thêm các ví dụ

nghiên cứu điển hình

Hình 6.1 Quy trình mô hình hóa dịch vụ mẫu cho các dịch vụ Web

Trang 4

6.1.1 Bước 1: Phân tách Quy trình kinh doanh

Chúng tôi bắt đầu bằng cách sử dụng quy trình kinh doanh được lập thành văn bản và chia nhỏ thành một loạt các bước quy trình chi tiết Logic quy trình công việc của quy trình kinh doanh cần được phân tách thành trình bày chi tiết nhất về các bước xử lý, có thể khác với mức mức độ chi tiết mà tại đó các bước của quy trình ban đầu được lập thành văn bản

Ví dụ về nghiên cứu điển hình

Dưới đây là bảng phân tích các bước của quy trình kinh doanh hiện tại:

1 Nhận Bảng chấm công

2 Xác minh Bảng chấm công

3 Nếu Bảng chấm công được xác minh, hãy chấp nhận việc gửi lên

và kết thúc bảng chấm công

4 Từ chối gửi bảng chấm công

Mặc dù nó chỉ bao gồm bốn bước tại thời điểm này, nhưng doanh nghiệp này còn nhiều hơn thế nữa quy trình Các chi tiết được tiết lộ khi nhóm TLS phân tích logic quy trình Họ bắt đầu với bước Nhận Bảng chấm công, được chia thành hai bước nhỏ hơn:

1a Nhận tài liệu về bảng chấm công vật lý

1b Bắt đầu đệ trình Bảng chấm công

Bước Xác minh Bảng chấm công thực sự là một quy trình con theo đúng nghĩa của nó và có thể do đó, hãy chia nhỏ thành các bước chi tiết hơn sau:

2a So sánh số giờ được ghi trên Bảng chấm công với số giờ được lập hóa đơn cho khách hàng

2b Xác nhận rằng đã được cấp phép cho bất kỳ giờ làm thêm nào đã ghi

4

Trang 5

2c Xác nhận rằng số giờ được ghi lại cho bất kỳ dự án cụ thể nào không vượt quá Giới hạn được xác định trước cho dự án đó

2d Xác nhận rằng Tổng số giờ được ghi lại trong một tuần không vượt quá mức tối đa được xác định trước cho người lao động đó

Khi phân tích tiếp theo, TLS phát hiện thêm rằng Bảng chấm công từ chối Bước quy trình đệ trình có thể được phân tích thành các bước chi tiết sau:

4a Cập nhật Hồ sơ của Người lao động để Theo dõi các Bảng chấm công bị Từ chối

4b Phát hành Thông báo từ chối Bảng chấm công cho Nhân viên 4c Đưa ra Thông báo cho Người quản lý của Người lao động

Sau khi đi sâu vào các bước của quy trình ban đầu, TLS hiện có một lượng lớn hơn các bước quy trình Nó tổ chức các bước này thành một quy trình kinh doanh mở rộng quy trình làm việc (Hình 6.3):

• Nhận Bảng chấm công

• So sánh số giờ được ghi trên Bảng chấm công với số giờ được lập hóa đơn cho khách hàng

Trang 7

Hình 6.3 Quy trình nghiệp vụ Đệ trình Bảng chấm công TLS đã sửa đổi.

Nếu số giờ không khớp, hãy từ chối việc gửi bảng chấm công

• Xác nhận rằng đã được cấp phép cho bất kỳ giờ làm thêm nào đã ghi

• Nếu xác nhận ủy quyền không thành công, hãy từ chối gửi bảng chấm công

• Xác nhận rằng số giờ được ghi cho bất kỳ dự án cụ thể nào không vượt quá a

Giới hạn được xác định trước cho dự án đó

• Xác nhận rằng Tổng số giờ được ghi lại trong một tuần không vượt quá mức tối đa được xác định trước cho người lao động đó

• Nếu xác nhận đã ghi giờ không thành công, hãy từ chối gửi bảng chấm công

• Từ chối gửi Bảng chấm công

• Tạo thông báo giải thích lý do từ chối

• Phát hành Thông báo từ chối Bảng chấm công cho Nhân viên

• Đưa ra Thông báo cho Người quản lý của Người lao động

• Nếu Bảng chấm công được xác minh, hãy chấp nhận việc đệ trình và kết thúc quy trình chấm công

Cuối cùng, TLS đơn giản hóa hơn nữa logic quy trình nghiệp vụ thành tập hợp sau của các hành động chi tiết:

• Bắt đầu đệ trình Bảng chấm công

Trang 8

• Nhận số giờ ghi lại cho khách hàng và phạm vi ngày

• Nhận Giờ lập hóa đơn cho Khách hàng và Phạm vi Ngày

• So sánh số giờ đã ghi với số giờ đã lập hóa đơn

• Nếu số giờ không khớp, hãy từ chối việc gửi bảng chấm công

• Nhận giờ làm thêm cho phạm vi ngày

• Nhận ủy quyền

• Xác nhận ủy quyền

• Nhận giới hạn số giờ hàng tuần

• So sánh giới hạn số giờ hàng tuần với số giờ đã ghi

• Cập nhật lịch sử nhân viên

• Gửi tin nhắn cho nhân viên

• Gửi tin nhắn cho người quản lý

6.1.2 Bước 2: Lọc ra các hành động không phù hợp

Một số bước trong quy trình kinh doanh có thể dễ dàng được xác định

là không thuộc về tiềm năng logic cần được đóng gói bởi một ứng viên dịch vụ Chúng có thể bao gồm quy trình thủ công các bước không thể hoặc không nên được tự động hóa và các bước xử lý do kế thừa hiện có thực hiện logic mà gói ứng viên dịch vụ không phải là một tùy chọn Bằng cách lọc ra những phần này, chúng tôi còn lại với các bước xử lý phù hợp nhất với quy trình tạo mô hình dịch vụ của chúng tôi.

8

Trang 9

Ví dụ về nghiên cứu điển hình

Sau khi xem xét từng bước của quy trình kinh doanh, những bước không thể hoặc không làm được không thuộc về một giải pháp hướng dịch vụ bị loại bỏ Danh sách sau đây truy cập lại các hành động bị phân hủy Hành động đầu tiên bị gạch bỏ vì nó được thực hiện do nhân viên kế toán thực hiện thủ công.

• Nhận Giờ lập hóa đơn cho Khách hàng và Phạm vi Ngày

• So sánh số giờ đã ghi với số giờ đã lập hóa đơn

• Nếu số giờ không khớp, hãy từ chối việc gửi bảng chấm công

• Xác nhận ủy quyền

• So sánh giới hạn số giờ hàng tuần với số giờ đã ghi

Trang 10

Mỗi hành động còn lại được coi là một ứng cử viên khả năng phục vụ.

6.1.3 Bước 3: Xác định ứng cử viên entity service (Define Entity Service Candidates)

Xem lại các bước xử lý còn lại và xác định một hoặc nhiều ngữ cảnh hợp lý màcác bước này có thể được nhóm lại Mỗi ngữ cảnh đại diện cho một ứng viêndịch vụ Các bối cảnh mà bạn kết thúc sẽ phụ thuộc vào các loại hình dịch vụkinh doanh mà bạn đã chọn để xây dựng Ví dụ, các task service sẽ yêu cầu mộtngữ cảnh cụ thể cho quy trình, trong khi các entity service sẽ đưa ra nhu cầunhóm các bước xử lý theo mối quan hệ của chúng với các thực thể đã xác địnhtrước đó SOA cũng có thể bao gồm sự kết hợp của các loại dịch vụ kinh doanhnày

Điều quan trọng là bạn không nên quan tâm đến việc có bao nhiêu bước thuộc

về mỗi nhóm Mục đích chính là thiết lập một tập hợp các ngữ cảnh cần thiết

Việc trang bị cho các ứng viên dịch vụ thực thể với các ứng viên năng lực bổsung để tạo điều kiện sử dụng lại trong tương lai cũng được khuyến khích Do

đó, phạm vi của bước này có thể được mở rộng để bao gồm phân tích các ứngviên năng lực dịch vụ bổ sung không được quy trình kinh doanh hiện tại yêucầu, nhưng được thêm vào để hoàn thiện các dịch vụ thực thể với một tập hợp

hoàn chỉnh các hoạt động có thể tái sử dụng

Case Study Example

Các nhà phân tích nghiệp vụ TLS hỗ trợ nỗ lực mô hình hóa dịch vụ bằng cáchtạo ra một mô hình thực thể có liên quan đến logic quy trình nghiệp vụ Gửibảng chấm công (Hình 4)

10

Trang 11

Hình 4: Một mô hình thực thể TLS hiển thị các thực thể kinh doanh có liên quan

đến quy trình nghiệp vụ đệ trình bảng chấm công

Nhóm TLS nghiên cứu mô hình này, cùng với danh sách các ứng viên khả năngdịch vụ dạng hạt được xác định trong bước phân tích trước đó Sau đó, họ xácđịnh các ứng viên năng lực dịch vụ được coi là agnostic Tất cả những thứ đượcphân loại là non-agnostic đều được in đậm, như sau:

• Bắt đầu đệ trình bảng chấm công

• Nhận giờ lập hóa đơn cho khách hàng và phạm vi ngày

• So sánh số giờ đã ghi với số giờ đã lập hóa đơn

Trang 12

• Nếu số giờ không khớp, hãy từ chối việc gửi bảng chấm công

• Xác nhận ủy quyền

• Nếu xác nhận ủy quyền không thành công, hãy từ chối gửi bảng chấm

công

• So sánh giới hạn số giờ hàng tuần với số giờ đã ghi

• Nếu xác nhận đã ghi giờ không thành công, hãy từ chối gửi bảng chấm

công

• Nếu bảng chấm công được xác minh, hãy chấp nhận việc đệ trình và kết

thúc quy trình chấm công

Đầu tiên, thực thể Bảng chấm công được xem xét Thực thể này đảm bảo mộtứng cử viên entity service tương ứng được gọi đơn giản là “Timesheet” Sau khiphân tích các thuộc tính của nó, TLS xác định thêm rằng các ứng viên khả năngdịch vụ sau đây nên được nhóm với ứng viên entity servce :

12

Trang 13

Tuy nhiên, khi phân tích tiếp theo, người ta xác định rằng hai ứng cử viên khảnăng đầu tiên có thể được tái sử dụng nhiều hơn bằng cách loại bỏ yêu cầu rằngphạm vi ngày là tiêu chí truy vấn duy nhất Mặc dù quy trình kinh doanh cụ thểnày sẽ luôn cung cấp phạm vi ngày, các nhà phân tích kinh doanh chỉ ra rằngcác quy trình khác sẽ muốn yêu cầu ghi lại giờ làm thêm hoặc làm thêm dựatrên các thông số khác Kết quả là một tập hợp các ứng cử viên năng lực đãđược sửa đổi, như trong Hình 5

Hình 5: Ứng cử viên dịch vụ Timesheet

Sau đó, các nhà phân tích xem xét thực thể Invoice Một lần nữa, họ đồng ýrằng thực thể này xứng đáng được đại diện như một ứng cử viên entity serviceđộc lập Họ đặt tên cho dịch vụ này là “Invoice” và gán cho nó ứng cử viênnăng lực sau:

• Nhận Giờ lập hóa đơn cho khách hàng và phạm vi ngày

Khi nguyên tắc hướng dịch vụ của khả năng tái sử dụng dịch vụ được xem xétlại, các nhà phân tích quyết định mở rộng phạm vi của ứng viên dịch vụ nàybằng cách điều chỉnh chức năng của ứng viên năng lực đã chọn và sau đó thêmmột chức năng mới, như thể hiện trong Hình 6 Giờ đây, người tiêu dùng dịch

vụ có thể truy xuất thông tin khách hàng liên quan đến hóa đơn và thông tin giờđược lập hóa đơn một cách riêng biệt

Trang 14

Hình 6: Ứng cử viên dịch vụ Invoice

Các thực thể Employee và Employee History được xem xét tiếp theo Bởi vì họ

có liên quan chặt chẽ với nhau, nên quyết định rằng họ có thể được đại diệnchung bởi một ứng viên service duy nhất được gọi là “Employee” Hai ứng viênkhả năng phục vụ được chỉ định, dẫn đến định nghĩa ứng viên service được hiểnthị trong Hình 7

Hình 7: Ứng viên dịch vụ Employee

Nhóm TLS cũng xem xét việc thêm một ứng viên khả năng dịch vụ Gửi thôngbáo vào ứng viên dịch vụ Nhân viên, nhưng sau đó xác định rằng chức năng này

14

Trang 15

tốt nhất nên được tách riêng thành một ứng viên dịch vụ tiện ích Do đó, haihành động còn lại được tạm dừng cho đến khi các dịch vụ tiện ích được xácđịnh, ở phần sau của quá trình này:

6.1.4 Bước 4: Xác định logic cụ thể của quy trình(Identify

Process-Specific Logic)

Bất kỳ phần nào của logic quy trình kinh doanh còn lại sau khi chúng tôi hoànthành Bước 3 sẽ cần được phân loại là non-agnostic hoặc dành riêng cho quytrình kinh doanh Các loại hành động phổ biến thuộc danh mục này bao gồm cácquy tắc nghiệp vụ, logic có điều kiện, logic ngoại lệ và logic trình tự được sửdụng để thực hiện các hành động trong quy trình nghiệp vụ riêng lẻ

Lưu ý rằng không phải tất cả các hành động non-agnostic đều nhất thiết phải trởthành ứng cử viên khả năng phục vụ Nhiều hành động dành riêng cho quy trìnhbiểu thị logic quyết định và các dạng xử lý khác được thực thi trong logic dịch

thực hiện giải pháp

Case Study Example

Các hành động sau đây được coi là non-agnostic vì chúng dành riêng cho quytrình nghiệp vụ Timesheet Submission:

Trang 16

• So sánh số giờ đã ghi với số giờ đã lập hóa đơn

• Nếu số giờ không khớp, hãy từ chối việc gửi bảng chấm công

• Xác nhận ủy quyền

• Nếu xác nhận ủy quyền không thành công, hãy từ chối gửi bảng chấm công

• So sánh giới hạn số giờ hàng tuần với số giờ đã ghi

• Nếu xác nhận đã ghi giờ không thành công, hãy từ chối gửi bảng chấm công

• Nếu Bảng chấm công được xác minh, hãy chấp nhận việc đệ trình và kết thúc quy trình chấm công

Biểu mẫu hoạt động Timesheet Submission tạo cơ sở cho một ứng viên nănglực dịch vụ, như được giải thích trong phần mô tả ứng viên dịch vụ nhiệm vụTimesheet Submission sắp tới Các hành động còn lại được in đậm để chỉ rarằng chúng đại diện cho logic được thực hiện trong dịch vụ nhiệm vụ Đệ trìnhbiểu thời gian, sau khi thực hiện hành động Bắt đầu đệ trình biểu thời gian, hànhđộng này được đổi tên thành ứng cử viên khả năng dịch vụ Bắt đầu (Hình 8)

Hình 8: Ứng viên dịch vụ Đệ trình Bảng chấm công với một dịch vụ duy nhấtkhả năng khởi chạy tự động hóa nghiệp vụ Gửi Bảng chấm công tiến trình

16

Trang 17

6.1.5 Bước 5: Áp dụng hướng dịch vụ

Bước này giúp ta có cơ hội điều chỉnh và áp dụng các nguyên tắc chủ chốt trong phần mềm hướng dịch vụ Tùy thuộc vào sự hiểu biết sâu sắc mà chúng tôi có thể có về bản chất logic cụ thể sẽ được yêu cầu trong một ứng viên dịch vụ nhất định, chúng tôi có thể có cơ hội để phát triển phạm vi và cấu trúc của các ứng viên dịch vụ Các nguyên tắc như Service Loose Coupling, Service Abstraction và Service Autonomy có thể giúp đưa ra những cân nhắc phù hợp ở giai đoạn này

1 Service Loose Coupling

 Định nghĩa ngắn gọn: "Các dịch vụ được kết hợp chặt chẽ với nhau."

 Định nghĩa dài: "Các hợp đồng dịch vụ đặt ra yêu cầu kết hợp giữa người tiêu dùng thấp và bản thân chúng được tách biệt khỏi môi

trường xung quanh của chúng."

 Mục tiêu: Bằng cách liên tục thúc đẩy giảm bớt sự khớp nối bên trong

và giữa các dịch vụ, chúng tôi đang nỗ lực hướng tới một trạng thái nơi các hợp đồng dịch vụ tăng tính độc lập khỏi việc triển khai và các dịch vụ ngày càng độc lập với nhau Điều này thúc đẩy một môi

trường trong đó các dịch vụ và người tiêu dùng của họ có thể được phát triển một cách thích ứng theo thời gian với tác động tối thiểu đến nhau

o Để đạt được sự cân bằng phù hợp của khớp nối, đồng thời hỗ trợ các nguyên tắc định hướng dịch vụ khác có ảnh hưởng đến thiết kế hợp đồng, đòi hỏi phải nâng cao trình độ thiết kế hợp đồng dịch vụ

2 Service Abstraction

Định dạng
Số trang	26
Dung lượng	812,28 KB