Nghiên cứu, phát triển và ứng dụng kiến trúc hướng mô hình trong công nghệ phần mềm

Ba mục tiêu cơ bản của MDA là khả năng di động, tính xuyên chức năng và sự sử dụng lại thông qua việc tách rời các mối liên quan, ví dụ như là: mô hình độc lập với thao tác tính toán,

- -

LÂM THỊ THÚY HOA

NGHIÊN CỨU, PHÁT TRIỂN VÀ ỨNG DỤNG KIẾN TRÚC HƯỚNG MÔ HÌNH TRONG

- -

LÂM THỊ THÚY HOA

NGHIÊN CỨU, PHÁT TRIỂN VÀ ỨNG DỤNG KIẾN TRÚC HƯỚNG MÔ HÌNH TRONG

MỤC LỤC

Trang Chương 1 - CÁC NGUYÊN TẮC MÔ HÌNH HÓA TRỰC QUAN VÀ CÁC

ĐẶC TRƯNG TRONG CÔNG NGHỆ HƯỚNG ĐỐI TƯỢNG 21.1 Các nguyên tắc mô hình hóa trực quan 21.2 Các đặc trưng trong công nghệ hướng đối tượng 3Chương 2 - TỔNG QUAN VỀ KIẾN TRÚC HƯỚNG MÔ HÌNH (MDA –

2.2.1 Mô hình độc lập với thao tác tính toán (CIM) 62.2.2 Mô hình độc lập với nền công nghệ (PIM) 72.2.3 Mô hình theo nền công nghệ cụ thể (PSM) 8

2.3.3 Chuyển đổi mô hình trong một hệ thống phức tạp 16Chương 3 - PHƯƠNG PHÁP PHÂN TÍCH VÀ THIẾT KẾ HƯỚNG ĐỐI TƯỢNG PHẦN MỀM ỨNG DỤNG THEO KIẾN TRÚC HƯỚNG MÔ

3.1.1 Xác định các tầng kiến trúc của hệ thống 18

3.1.3 Sự tham chiếu các tầng kiến trúc với MDA 22

3.2.1 Xác định các trừu tượng hóa chính 223.2.2 Xác định các tác nhân và các trường hợp sử dụng 233.2.3 Biều diễn mối quan hệ giữa tác nhân và trường hợp sử dụng 263.2.4 Bổ sung mô tả cho trường hợp sử dụng 283.3 Chuyển đổi mô hình CIM sang mô hình PIM 29

3.3.1 Chuyển đổi các thành phần của mô hình CIM thành các phần tử

3.3.2 Chuyển đổi các phần tử phân tích thành các phần tử thiết kế trong

3.4 Chuyển đổi mô hình PIM sang mô hình PSM 463.4.1 Lựa cho ̣n nền công nghê ̣ thực thi hệ thống 463.4.2 Các luâ ̣t chuyển đổi phần tử thiết kế trong PIM sang PSM 483.4.3 Thiết kế chi tiết các trường hợp sử dụng 49

Chương 4 - ÁP DỤNG PHƯƠNG PHÁP PHÂN TÍCH THIẾT KẾ HƯỚNG ĐỐI TƯỢNG THEO KIẾN TRÚC HƯỚNG MÔ HÌNH VÀO VIỆC PHÁT TRIỂN HỆ THỐNG QUẢN LÝ TÍN DỤNG TRONG NGÂN HÀNG 57

4.2 Giới thiệu tổng quan hệ thống Quản lý tín dụng trong ngân hàng 604.3 Phân tích thiết kế chi tiết một trường hợp sử dụng Quản lý Hợp đồng vay 67

Chương 5 - SO SÁNH VÀ ĐÁNH GIÁ MDA VỚI CÁC PHƯƠNG PHÁP

DANH MỤC CÁC CHỮ VIẾT TẮT

Ký hiệu

BUS Business System Hệ thống con nghiệp vụ

CIM Computation Independent

Model

Mô hình độc lập với thao tác tính toán

CNTT Công nghệ thông tin Công nghệ thông tin

CSDL Cơ sở dữ liệu Cơ sở dữ liệu

DAO Data Access Object Đối tượng truy xuất dữ liệu GDTD Giao dịch tín dụng Nhân viên giao dịch tín dụng

J2EE Java 2 Platform, Enterprise

Edition MDA Model Driven Architecture Kiến trúc hướng mô hình

MOF Meta Object Facility Khả năng siêu hướng đối tượng OMG Object Management Group Tổ chức quản trị đối tượng

OODBMS Object-Oriented Database

RDBMS Relational Database

Management System

Hệ quản trị cơ sở dữ liệu quan

hệ UML Unified Modeling Language Ngôn ngữ mô hình hoá hợp nhất VOPC View Of Participating

Classes Tổng quan về các lớp tham gia

DANH MỤC CÁC HÌNH VẼ

Trang Hình 1.1 Tổng quan các đặc trưng trong công nghệ hướng đối tượng 3 Hình 2.1 Sự phân loại các mô hình chính trong MDA 5 Hình 2.2 Ví dụ một quá trình phát triển phần mềm theo MDA 6

Hình 3.2 Ví dụ về một kết quả xác định các tầng kiến trúc 19 Hình 3.3 Ví dụ về mối liên hệ giữa các cơ chế kiến trúc 21 Hình 3.4 Ví dụ về các trừu tượng hóa chính 23 Hình 3.5 Ví dụ một tác nhân “Người quản lý hợp đồng vay” 23 Hình 3.6 Ví dụ một trường hợp sử dụng “Quản lý Hợp đồng vay” 24 Hình 3.7 Ví dụ về quan hệ “sử dụng” giữa các trường hợp sử dụng 25 Hình 3.8 Ví dụ về quan hệ “tổng quan hóa” giữa các trường hợp sử du ̣ng 25 Hình 3.9 Ví dụ về quan hệ “mở rộng” giữa các trường hợp sử dụng 26 Hình 3.10 Ví dụ một b iểu đồ diễn tiến thể hiê ̣n sự tương tác giữa tác nhân và trườ ng hơ ̣p sử du ̣ng trong chức năng “Ta ̣o mới mô ̣t Hợp đồng vay” 27 Hình 3.11 Ví dụ một biểu đồ hoạt động thể hiện dòng sự kiện rẽ nhánh 28

Hình 3.12 Ví dụ về việc bổ sung thông tin cho trường hợp sử dụng 29 Hình 3.13 Tổng quan về các lớp phân tích 30 Hình 3.14 Ví dụ một lớp biên “HopDongVayForm” 31 Hình 3.15 Ví dụ một lớp điều khiển “HopDongVayControl” 32 Hình 3.16 Ví dụ một lớp thực thể “HopDongVay” 33 Hình 3.17 Ví dụ việc mô tả thuộc tính của lớp thực thể “HopDongVay” 34 Hình 3.18 Ví dụ mô ̣t mối quan hệ “liên kết” giữa hai lớp “DMKhachHang” và

Hình 3.19 Ví dụ một biểu đồ diễn tiến thể hiê ̣n mối quan hê ̣ giữa các lớp phân tích trong chức năng “Tạo mới một Hợp đồng vay” 36 Hình 3.20 Biểu đồ tổng quan các lớp phân tích tham gia trường hợp sử dụng

Hình 3.21 Ví dụ sự chuyển đổi các lớp phân tích thành các lớp thiết kế 39 Hình 3.22 Ví dụ về các thành phần của một hệ thống con “Hê ̣ thống Quản lý

Hình 3.23 Ví dụ một biểu đồ diễn tiến thể hiê ̣n mối quan hê ̣ giữa các lớp thiết

kế trong chức năng “Tạo mới một Hợp đồng vay” 45 Hình 3.24 Ví dụ sự phân phối các cơ chế kiến trúc cho các lớp thiết kế 45 Hình 3.25 Biểu đồ tổng quan các lớp thiết kế tham gia trường hợp sử dụng

Hình 3.26 Tổng quan các thành phần của nền công nghệ NET 47 Hình 3.27 Mô hình kiến trúc thiết kế ứng dụng với NET 48 Hình 3.28 Ví dụ một hệ thống con UI của trường hợp sử dụng “Quản lý Hợp

Hình 3.31 Biểu đồ diễn tiến thể hiê ̣n mối quan hê ̣ giữa các hệ thống con thiết

kế trong chức năng “Tạo mới một Hợp đồng vay” 52

Hình 3.32 Biểu đồ tổng quan về các gói hệ thống con thiết kế tham gia trường

Hình 3.33 Ví dụ về việc chuyển đổi một lớp thực thể thiết kế thành một mô

Hình 3.34 Ví dụ một sự ánh xạ quan hệ giữa các lớp thực thể thiết kế thành

quan hệ giữa các bảng trong mô hình dữ liệu 56 Hình 4.1 Các tác nhân chính tham gia hệ thống “Quản lý tín dụng” 61 Hình 4.2 Biểu đồ tổng quan các gói nghiệp vụ của hệ thống “Quản lý tín

Hình 4.3 Gói các trường hợp sử dụng “Quản lý Hợp đồng vay” 63 Hình 4.4 Gói các trường hợp sử dụng “Quản lý Tài sản bảo đảm” 63 Hình 4.5 Gói các trường hợp sử dụng “Quản lý thu nợ” 64 Hình 4.6 Gói các trường hợp sử dụng “Quản lý báo cáo” 65 Hình 4.7 Gói các trường hợp sử dụng “Quản lý danh mục” 66 Hình 4.8 Gói các trường hợp sử dụng “Quản lý hệ thống” 66

MỞ ĐẦU

Trong kỷ nguyên công nghệ và nền kinh tế đa chiều, phần mềm đã và đang đóng một vai trò vô cùng quan trọng trong việc định hướng phát triển cho mọi doanh nghiệp và góp phần gia tăng giá trị cạnh tranh trong cộng đồng Đối với chính phủ, phần mềm là một trong những yếu tố cơ bản trong viêc xây dựng nền tảng phát triển kinh tế của quốc gia và cải thiện các chính sách nhằm nâng cao chất lượng cuộc sống của người dân

Phương pháp tiếp cận Kiến trúc hướng theo mô hình (MDA: Model-Driven Architecture) do tổ chức OMG (Object Management Group) phát triển là một cách tiếp cận dùng các mô hình để phát triển phần mềm ứng dụng Ba mục tiêu cơ bản của MDA là khả năng di động, tính xuyên chức năng và sự sử dụng lại thông qua việc tách rời các mối liên quan, ví dụ như là: mô hình độc lập với thao tác tính toán, (CIM - Computation Independent Model), mô hình độc lập với nền công nghệ (PIM - Platform Independent Model), mô hình cụ thể của nền công nghệ (PSM - Platform Specific Model), sự chuyển đổi mô hình và các mẫu của MDA v.v…

Luận văn này được thực hiện nhằm mu ̣c đích nghiên cứu về kiến trúc hướng

mô hình, phương pháp tiếp cận theo kiến trúc hướng mô hình trong công nghiệp phát triển phần mềm và minh họa việc áp dụng lý thuyết nghiên cứu vào việc phát triển hệ thống thực tế

Luận văn bao gồm 5 chương chính như sau:

Chương 1 Các nguyên tắc mô hình hoá trực quan và các đặc trưng trong công nghệ hướng đối tượng

Chương 2 Tổng quan về kiến trúc hướng mô hình (MDA – Model Driven

Chương 5 So sánh MDA với các phương pháp khác

Chương 1 - CÁC NGUYÊN TẮC MÔ HÌNH HÓA TRỰC QUAN VÀ CÁC ĐẶC TRƯNG TRONG CÔNG NGHỆ HƯỚNG ĐỐI TƯỢNG 1.1 Các nguyên tắc mô hình hóa trực quan

Mô hình hoá trực quan là việc sử dụng các ngôn ngữ thiết kế có tính chất đồ hoạ và các mô tả ngắn gọn để thể hiện các bản thiết kế phần mềm, ví dụ: ngôn ngữ

mô hình hoá hợp nhất UML Mô hình hóa trực quan cho phép trừu tượng hoá các hệ thống ở mức cao hơn, trong khi đó vẫn duy trì được ngữ nghĩa và cấu trúc căn bản của hệ thống, giúp cho người đọc bản thiết kế dễ nắm bắt cấu trúc tĩnh và ứng xử động của hệ thống Mô hình hoá trực quan có bốn nguyên tắc cơ bản như sau:

Nguyên tắc 1: Các mô hình được tạo ra chi phối sâu sắc đến cách tiếp cận

và định hướng giải quyết một vấn đề

Trong phát triển phần mềm, việc chọn các mô hình có thể ảnh hưởng rất lớn đến thế giới quan của người làm phần mềm Mỗi thế giới quan sẽ dẫn tới một loại

mô hình khác nhau với chi phí và lợi ích khác nhau Nếu xây dựng hệ thống theo con mắt của người thiết kế CSDL, kết quả nhận được sẽ là mô hình quan hệ thực thể nêu ra cách xử lý trong các thủ tục lưu trữ và các trigger Nếu xây dựng hệ thống thông qua con mắt của người phân tích thiết kế hướng đối tượng, kết quả đầu

ra sẽ là một hệ thống có kiến trúc xoay quanh nhiều lớp và mẫu tương tác với nhau, điều khiển các lớp đó làm việc với nhau

Các mô hình đúng sẽ làm sáng tỏ những bài toán phát triển phần mềm phức tạp, giúp cho người phát triển hệ thống không bị sa lầy vào những vấn đề không cần thiết Một mô hình sai sẽ làm cho người phát triển dễ bị lạc hướng vì tập trung vào những vấn đề không liên quan

Nguyên tắc 2: Mỗi mô hình được thể hiện ở mức độ chi tiết khác nhau

Mỗi mô hình được chọn ở các mức chi tiết khác nhau tùy thuộc vào việc ai là người sử dụng mô hình và tại sao cần sử dụng mô hình

Ví dụ: Người sử dụng sử dụng khung nhìn trường hợp sử dụng (Use Case View) để biết hệ thống có đáp ứng được yêu cầu nghiệp vụ của họ không, người phân tích thiết kế sử dụng khung nhìn logic (Logical View) trong quá trình phân tích thiết kế hệ thống, người triển khai sử dụng khung nhìn triển khai (Deployment View) để chuẩn bị môi trường cho việc triển khai v.v

Nguyên tắc 3: Các mô hình tốt nhất là các mô hình được liên hệ trong thực tế

Tất cả các mô hình đều là sự đơn giản hoá của thực tế Một mô hình tốt sẽ phản ánh đầy đủ những đặc trưng không thể thiếu về năng lực hệ thống và không che lấp đi bất kỳ một chi tiết quan trọng nào Mô hình vật lý của một hệ thống cũng

có thể không được đáp ứng trên thực tế do bị hạn chế về nguồn tài nguyên và kinh phí Vì vậy, mỗi mô hình khi xây dựng cần được xem xét và đặt trong thực tế

Nguyên tắc 4: Không có một mô hình đơn lẻ nào là đầy đủ Một hệ thống tốt nhất phải được tiếp cận thông qua một tập các mô hình độc lập tương đối với nhau

“Độc lập tương đối” có nghĩa là các mô hình có thể được xây dựng và xem xét độc lập nhau, nhưng chúng vẫn phải có mối quan hệ tương quan với nhau

Ví dụ: Để hiểu cấu trúc của một hệ thống hướng đối tượng, những người phát triển phần mềm cần kết hợp xem xét trên một số khung nhìn: khung nhìn trường hợp sử dụng (Use Case View), khung nhìn logic (Logical View), khung nhìn

xử lý (Process View), khung nhìn thực thi (Implementation View), khung nhìn triển khai (Deployment View) Mỗi khung nhìn được xây dựng từ những góc nhìn khác nhau để thể hiện cấu trúc và ứng xử của hệ thống Chúng cùng nhau tạo nên một bản thiết kế đầy đủ, chi tiết cho một hệ thống phần mềm

1.2 Các đặc trưng trong công nghệ hướng đối tượng

Công nghệ hướng đối tượng là một tập các nguyên tắc hướng dẫn xây dựng phần mềm với các ngôn ngữ, các cơ sở dữ liệu và các công cụ hỗ trợ cho các nguyên tắc đó Có bốn đặc trưng cơ bản trong công nghệ hướng đối tượng như sau:

Hình 1.1 Tổng quan các đặc trưng trong công nghệ hướng đối tượng

 Đặc trưng 1: Tính trừu tượng hoá (Abstraction)

Tính trừu tượng hoá cho phép người phát triển phần mềm giải quyết những bài toán phức tạp bằng cách bỏ qua hay không chú ý đến một số khía cạnh chi tiết

của thông tin để tập trung vào các đặc trưng cốt yếu của một thực thể, các đặc trưng làm thực thể đó nổi bật so với tất cả các thực thể khác Trừu tượng hoá phụ thuộc vào phạm vi và ngữ cảnh, những gì quan trọng trong ngữ cảnh này có thể không quan trọng trong một ngữ cảnh khác

 Đặc trƣng 3: Tính mô đun hoá (Modularity)

Mô đun hoá là tính chất cho phép chia một mô đun lớn và phức tạp thành một tập các mô đun con và đơn giản hơn để xử lý Các bài toán này có thể được phân tích, thiết kế, thực thi độc lập và sau đó được tích hợp với nhau thành một hệ thống lớn thông qua các giao diện của các mô đun con, để xử lý toàn bộ vấn đề

Mô đun hoá làm cho một hệ thống dễ dàng hơn trong việc thiết kế, thực thi, bảo trì và nâng cấp sau này, cũng như thuận lợi hơn cho việc tái sử dụng Các mô đun của một hệ thống có thể được thực thi, gỡ bỏ, kích hoạt, vô hiệu hóa thông qua

hệ thống quản lý mô đun

 Đặc trƣng 4: Tính phân cấp (Hierarchy )

Cấu trúc chung của một hệ thống hướng đối tượng là sự phân cấp các thành phần theo các mức độ trừu tượng hoá như phân cấp lớp, phân cấp thừa kế, phân cấp đặc tả v.v Các thành phần ở cùng một mức phân cấp thì nên tổ chức trong cùng mức trừu tượng hoá

Chương 2 - TỔNG QUAN VỀ KIẾN TRÚC HƯỚNG MÔ HÌNH (MDA

– MODEL DRIVEN ARCHITECTURE) 2.1 Tổng quan về MDA

Kiến trúc hướng mô hình (MDA) là một cách tiếp cận mô hình hoá trực quan trong suốt quá trình tìm hiểu, phân tích, thiết kế, thực thi một hệ thống phần mềm MDA phân chia các mô hình đặc tả về hệ thống từ mức độ trừu tượng hóa cao cho đến mức chi tiết và cung cấp các luật chuyển đổi cho phép chuyển đổi giữa các mô hình

Các mô hình chính của MDA bao gồm:

 Mô hình độc lập với thao tác tính toán (CIM - Computation Independent Model) thể hiện hệ thống ở mức nghiệp vụ

 Mô hình độc lập với nền công nghệ (PIM - Platform Independent Model) đặc tả các chức năng hệ thống nhưng độc lập với các nền công nghệ thực thi hệ thống

 Mô hình theo nền công nghệ cụ thể (PSM - Platform Specific Model) đặc tả các chức năng hệ thống theo một nền công nghệ cụ thể được lựa chọn để thực thi hệ thống;

Hình 2.1 trình bày một cách tổng quan về sự phân loại các mô hình chính của MDA theo trật tự từ mức độ trừu tượng hóa đến cụ thể hoá

Hình 2.1 Sự phân loại các mô hình chính trong MDA

Ví dụ: Hình 2.2 trình bày ví dụ về một quá trình phát triển phần mềm theo kiến trúc hướng mô hình

Hình 2.2 Ví dụ một

2.2 Các mô hình trong MDA

2.2.1 Mô hình độc lập với thao tác tính toán (CIM)

Mô hình độc lập với thao tác tính toán (CIM – Computation Model Model) là sự xem xét hệ thống từ góc độ độc lập với các thao tác tính toán Mô hình CIM tập trung vào sự đặc tả hệ thống bằng các thuật ngữ gần gũi với người làm nghiệp

vụ, và được xác định bởi sự kết hợp làm việc giữa người phân tích nghiệp vụ và những người làm nghiệp vụ sẽ sử dụng hệ thống Và chính vì vậy, mô hình CIM còn được gọi là mô hình phạm vi hay mô hình nghiệp vụ

Ví dụ: Hình 2.3 trình bày một ví dụ về mô hình CIM Trong mô hình này không có thông tin nào chỉ ra giải pháp dựa trên thao tác tính toán

Hình 2.3 Ví dụ về CIM

2.2.2 Mô hình độc lập với nền công nghệ (PIM)

Mô hình độc lập với nền công nghệ (PIM – Platform Independent Model) tập trung vào việc mô hình hoá các thao tác của hệ thống, nhưng ở góc độ độc lập với các nền công nghệ cho phép thực thi các chức năng hệ thống, tức là chưa chỉ ra những chi tiết cần thiết để thực thi các chức năng hệ thống trên một nền công nghệ

cụ thể PIM biểu diễn phần đặc tả về hệ thống mà các đặc tả này không bị thay đổi giữa nền công nghệ này với nền công nghệ khác Các đặc tả này có thể được chuyển thành các mô hình của hệ thống cụ thể theo những nền công nghệ khác nhau được lựa chọn để thực thi hệ thống

Ví dụ: Hình 2.4 trình bày một ví dụ về PIM xuất phát từ ví dụ về CIM được

mô tả trên hình 2.3 Mô hình này có bao gồm các ứng xử của hệ thống đã tiến gần tới việc thực thi nhưng không gắn với một nền công nghệ nào cả

Hình 2.4 Ví dụ về PIM - dựa theo hình 2.3

2.2.3 Mô hình theo nền công nghệ cụ thể (PSM)

Mô hình theo nền công nghệ cụ thể (PSM – Platform Specific Model) đặc tả

hệ thống bằng các thông tin được xác định trong PIM kết hợp với chi tiết các kiểu của một nền công nghệ cụ thể được lựa chọn để thực thi hệ thống, ví dụ như: nền công nghệ NET, J2EE v…v

Hình 2.5 chỉ ra ví dụ về PSM xuất phát từ ví dụ về PIM được mô tả trên hình 2.4 Trong mô hình này, PSM đã thể hiện các thông tin của PIM thông qua các thuật ngữ và cấu trúc của một công nghệ cụ thể đó là NET

Hình 2.5 Ví dụ về PSM - dựa theo hình 2.4 với công nghệ NET

2.3 Sƣ ̣ chuyển đổi mô hình trong MDA

Sự chuyển đổi mô hình trong MDA là việc sử dụng một cơ chế nào đó để biến đổi các mô hình ở mức trừu tượng hoá cao thành các mô hình ở mức cụ thể và chi tiết hơn dựa trên sự định nghĩa các luật chuyển đổi Đó là sự chuyển từ CIM sang PIM, từ PIM sang PSM, và từ PSM có thể chuyển thành mã chương trình cụ thể thực thi hệ thống Việc chuyển đổi giữa các mô hình có thể được thực hiện qua thao tác bằng tay, chuyển đổi tự động dựa vào các mẫu chuyển đổi khác nhau tuỳ thuộc vào những công cụ chuyển đổi và nền công nghệ đích, hoặc kết hợp cả hai

phương thức Cho đến nay, các công cụ hỗ trợ việc chuyển đổi mô hình trong MDA tập trung chủ yếu vào giai đoạn chuyển đổi từ PIM sang PSM, chỉ có một số ít chuyển đổi từ CIM sáng PIM

2.3.1 Chuyển đổi từ CIM sang PIM

Mục đích của phần này chính là cách tiếp cận để chuyển đổi một CIM sang một PIM trong MDA Đầu tiên sử dụng sơ đồ hoạt động UML2.x để xử lý các tác

vụ của người sử dụng Sơ đồ hoạt động này được chỉ rõ trong các yêu cầu hệ thống Các thành phần hệ thống được suy luận từ mô hình yêu cầu Cuối cùng một bộ các nguyên mẫu giúp các thành phần hệ thống tạo ra PIM

Hình 2.6 Mô hình chuyển từ CIM sang PIM

Elementary Business Process (EBP)

Một thực thể nghiệp vụ (EBP) được định nghĩa như một nhiệm vụ được thực hiện bởi một người, tại một địa điểm và trong một thời điểm, phục vụ một sự kiện nào đó, làm tăng khả năng thêm hiệu quả có thể đo đếm được cho nghiệp vụ và lưu lại dữ liệu ở trạng thái ổn định

Xây dựng CIM

CIM được xây dựng trên mô hình sử dụng sơ đồ hoạt động UML2.x bằng một kỹ thuật đơn giản:

 Mô hình quy trình nghiệp vụ - Business Process Model (BPM)

- Chia nhỏ các quy trình thành các nhóm EBP liên quan đến luồng công việc từ người này tới người khác

- Mô tả mỗi EBP bằng cả hai hành động (mặt hoạt động, biến đổi) và các đối tượng cần thiết (mặt cố định)

 Mô hình yêu cầu - Requirement Model

- Giới thiệu trong BPM hệ thống như người thực hiện những xử lý mong muốn

- Xây dựng các mô hình tình huống (Use Case) dùng sơ đồ hoạt động ULM2.x (mỗi EBP sử dụng một Use Case)

Hình 2.7 Mô hình tình huống

Xây dựng PIM

Từ mô hình Use Case, chúng ta xác định hai thành phần khác biệt là:

- Thành phần quy trình nghiệp vụ tương ứng với quy trình xử lý

- Thành phần thực thể nghiệp vụ tương ứng với các tài nguyên và sản phẩm hay dịch vụ

- Mỗi Use Case thường được chuyển thành các thành phần quy trình rồi liên kết với các thực thể tùy thuộc vào vai trò của các thực thể trong quy trình

Thành phần quy trình là Moment-Interval Archetype

Thành phần thực thể là PPT và/hoặc Mô tả và/hoặc vai trò nguyên mẫu Archetypes

PIM được hoàn thành bởi việc chọn các thuộc tính và phương thức từ các thực thể tổng quan của từng nguyên mẫu

2.3.2 Chuyển đổi từ PIM sang PSM

2.3.2.1 Theo vết mô hình

Hình 2.8 Đánh dấu mô hình Hình 2.8 mở rộng mô hình MDA nhằm miêu tả chi tiết một trong những cách mà một chuyển đổi có thể được thực hiện

Một nền công nghệ cụ thể được lựa chọn Ánh xạ cho nền công nghệ này sẵn có và được chuẩn bị Ánh xạ này bao gồm một bộ thiết bị đánh dấu Các dấu được sử dụng nhằm đánh dấu các yếu tố mô hình để hướng dẫn cho quá trình biến đổi mô hình Việc sử dụng ánh xạ sẽ làm cho PIM đánh dấu được biến đổi xa hơn nhằm tạo

ra PSM

2.3.2.2 Quá trình biến đổi siêu mô hình – Metamodel

Hình 2.9 Quá trình biến đổi Metalmodel

Hình 2.9 mở rộng các mô hình MDA để diễn tả thêm chi tiết của một trong những cách mà một chuyển đổi có thể được thực hiện

Mô hình được chuẩn bị bằng cách sử dụng một ngôn ngữ độc lập với nền công nghệ được xác định bởi một metamodel Một nền công nghệ cụ thể được lựa chọn Đặc tả mô hình chuyển đổi nền tảng này hiện có sẵn hoặc được chuẩn bị Sự chuyển đổi đặc tả này dưới dạng ánh xạ giữa các metamodel Ánh xạ chỉ dẫn sự chuyển đổi của PIM tạo ra PSM

2.3.2.3 Quá trình biến đổi mô hình

Hình 2.10 Quá trình biến đổi mô hình

Mô hình được chuẩn bị bằng cách sử dụng các kiểu độc lập nền công nghệ trong mô hình Các kiểu có thể là phần của một khung phần mềm Các yếu tố trong PIM là các kiểu phụ của dạng độc lập nền công nghệ Một nền công nghệ cụ thể được lựa chọn Dạng biến đổi đặc tả nền công nghệ này sẵn có hoặc được chuẩn bị sẵn Sự biến đổi này là ánh xạ giữa các kiểu độc lập nền tảng và các kiểu phụ thuộc nền tảng Các yếu tố trong PSM là kiểu phụ của các kiểu đặc tả nền tảng

Cách tiếp cận này khắc hẳn với ánh xạ metamodel chủ yếu bằng các kiểu đặc

tả trong một mô hình mà được sử dụng cho ánh xạ, thay thế cho các khái niệm đặc

tả bởi mô hình metamodel

2.3.2.4 Ứng dụng mẫu

Mở rộng các phương pháp tiếp cận ánh xạ siêu mô hình và mô hình bao gồm các mẫu cùng với các kiểu hay các khái niệm ngôn ngữ mô hình

Hình 2.11 Ứng dụng mẫu Ngoài các kiểu độc lập nền tảng, mô hình chung có thể cung cấp các mẫu Cả hai kiểu và mẫu này có thể được ánh xạ tới các mẫu và các kiểu đặc tả nền tảng

Phương pháp tiếp cận ánh xạ mô hình metamodel có thể sử dụng các mẫu cùng một cách

Hình 2.12 Một cách khác để sử dụng các mẫu Hình 1.12 chỉ ra một cách khác để sử dụng các mẫu: khi các tên của nền tảng

cụ thể đánh dấu, có nghĩa là, tên của các mẫu thiết kế quy định cho một nền tảng

2.3.2.5 Mô hình kết hợp

Có một số cách tiếp cận MDA dựa vào các mô hình kết hợp

Hình 2.13 Mô hình kết hợp Hình 2.13 mở rộng mô hình MDA theo một cách khác nhằm miêu tả chi tiết một trong những cách chuyển đổi khác có thể được thực hiện

2.3.2.6 Thông tin bổ sung

Ngoài những PIM và các nền tảng cụ thể đánh dấu, thông tin bổ sung có thể được cung cấp để hướng dẫn việc chuyển đổi

Thông tin bổ sung sẽ thường xuyên dựa trên các kiến thức thực tế của nhà thiết kế

Hình 2.14 Bổ sung thông tin để chuyển sang PSM Hình vẽ mở rộng mẫu MDA đơn giản nhằm chỉ ra cách sử dụng của thông tin bổ sung

Hình 2.15 Sử dụng thông tin bổ sung trong kỹ thuật biến đổi cụ thể Hình 2.15 mở rộng thêm mẫu MDA nhằm chỉ ra cách sử dụng thông tin bổ sung trong kỹ thuật biến đổi cụ thể

Trong quá trình chuẩn bị mô hình PIM, ngoài việc sử dụng các tên mẫu có sẵn thì các thông tin khác có thể được thêm vào để tạo ra PIM đánh dấu Ngoài các mẫu ra, các thông tin thêm cũng có thể được sử dụng khi PIM đánh dấu được biến đổi thêm nhằm tạo ra PSM

2.3.3 Chuyển đổi mô hình trong một hệ thống phức tạp

Đối với những hệ thống phức tạp, mỗi mô hình của MDA có thể được tinh chỉnh nhiều lần trước khi chuyển sang loại mô hình khác

Ví dụ: Hình 2.16 mô tả quá trình chuyển đổi các mô hình trong một hệ thống phức tạp: mô hình CIM được tinh chỉnh nhiều lần trước khi chuyển sang mô hình PIM, mô hình PIM được tinh chỉnh nhiều lần trước khi chuyển sang mô hình PSM và mô hình PSM cũng được tinh chỉnh nhiều lần trước khi chuyển sang code thực thi

Hình 2.16 Ví dụ về quy trình MDA cho một hệ thống phức tạp

Chương 3 - PHƯƠNG PHÁP PHÂN TÍCH VÀ THIẾT KẾ HƯỚNG ĐỐI TƯỢNG PHẦN MỀM ỨNG DỤNG THEO KIẾN TRÚC

HƯỚNG MÔ HÌNH 3.1 Phân tích kiến trúc hệ thống

Phân tích kiến trúc hệ thống là việc xem xét lựa chọn một cách tổ chức cấu trúc cơ bản cho việc phát triển một hệ thống phần mềm dựa trên các mẫu kiến trúc Mỗi mẫu kiến trúc cung cấp một tập các gói được định nghĩa trước, chỉ rõ các nhiệm vụ của các gói đó, và bao gồm các luật và các nguyên tắc thiết lập quan hệ giữa các gói

Một số mẫu kiến trúc như sau:

 Mẫu các tầng (Layer): Trong mẫu này một ứng dụng được phân chia thành các mức trừu tượng hóa khác nhau Các tầng giới hạn trong phạm vi từ các tầng ứng dụng cụ thể ở trên đến các tầng thực thi hoặc nền công nghệ cụ thể ở dưới

 Mẫu Mô hình - Hiển thị - Điều khiển (Model - View - Controller): Trong mẫu này một ứng dụng được phân chia thành 3 phần:

- Mô hình thể hiện các luật nghiệp vụ và dữ liệu cơ bản,

- Phần hiển thị thể hiện các thông tin được trình diễn cho người sử dụng,

- Và các điều khiển xử lý thông tin đầu vào từ người sử dụng

 Mẫu ống dẫn và bộ lọc (Pipes and Filters): Trong mẫu này dữ liệu được xử lý thành các luồng qua ống dẫn từ bộ lọc này đến bộ lọc khác Ống dẫn (Pippe) ở đây giống như hàng đợi, thông tin được xử lý trên cơ sở vào trước, ra trước (first-in, first-out)

Mỗi mẫu kiến trúc đưa ra các đặc trưng nhất định cho hệ thống, các đặc trưng

về sự trình bày, về tiến trình xử lý và sự phân phối các thành phần trong kiến trúc Tùy vào đặc trưng của mỗi hệ thống phần mềm mà người phân tích kiến trúc có thể

sử dụng một mẫu kiến trúc hoặc kết hợp nhiều mẫu kiến trúc cho hệ thống

Dựa trên đặc điểm của MDA là đi từ mô hình ở mức trừu tượng hóa cao đến

mô hình cụ thể hóa (được trình bày ở chương 2) và dựa trên đặc điểm của các mẫu kiến trúc, kiến trúc tầng là loại kiến trúc hệ thống phù hợp nhất cho phương pháp phân tích và thiết kế hệ thống theo MDA

3.1.1 Xác định các tầng kiến trúc của hệ thống

Xác định các tầng kiến trúc của hệ thống là đưa ra cách tổ chức các phần tử

mô hình hoá trong giai đoạn phân tích thiết kế hệ thống Việc xác định các tầng kiến trúc được thực hiện theo cách nhóm các chức năng cùng loại: các chức năng cụ thể của ứng dụng được đặt ở tầng trên, các chức năng mở rộng phạm vi ứng dụng đặt ở các tầng giữa, chức năng cho môi trường triển khai đặt ở tầng dưới

Hình 3.1 trình bày một mô hình kiến trúc tầng kinh điển của hệ thống bao gồm 4 tầng cơ bản: tầng ứng dụng, tầng nghiệp vụ, tầng giữa và tầng phần mềm hệ thống

Hình 3.1 Các tầng kiến trúc hệ thống

 Tầng ứng dụng (Application): bao gồm các lớp biên, các lớp điều khiển (được định nghĩa ở mục 3.3.1.2) cho hệ thống phần mềm đang được phát triển

 Tầng nghiệp vụ (Business): bao gồm một số các hệ thống con cụ thể có thể tái

sử dụng cùng với các giao diện của chúng cho các kiểu nghiệp vụ (được định nghĩa ở mục 3.3.2.2 và 3.3.2.3) và các lớp thực thể (được định nghĩa ở mục 3.3.1.2)

 Tầng giữa (Middleware): cung cấp các hệ thống con cho các tầng tiện ích và các dịch vụ độc lập với nền công nghệ thực hiện phân chia các đối tượng tính toán trong môi trường khác thể

 Tầng phần mềm hệ thống (System Software): bao gồm phần mềm cho hạ tầng thực sự như các hệ điều hành, các giao diện để xác định phần cứng, các thiết

bị ngoại vi v.v

Một kiến trúc được phân tầng hợp lý sẽ thể hiện rõ các phần tử thiết kế (các lớp, các gói, các hệ thống con); các thành phần ở tầng trên chỉ sử dụng dịch vụ của

các tầng dưới (không có chiều ngược lại); các thành phần không sử dụng các dịch

vụ của tầng khác nếu có thể sử dụng dịch vụ của tầng ngay dưới nó

Ví dụ: Hình 3.2 trình bày ví dụ một kiến trúc hệ thống bao gồm các gói được tạo sẵn ra để chứa các phần tử mô hình hóa được xác định trong quá phân tích và thiết kế một hệ thống phần mềm

Hình 3.2 Ví dụ về một kết quả xác định các tầng kiến trúc Trong ví dụ này kiến trúc hệ thống được phân chia dựa trên kiến trúc kinh điển gồm 4 tầng cơ bản:

 Tầng ứng dụng (tầng 4 và 5): tầng ứng dụng được chia nhỏ thành hai tầng con là tầng 4 và tầng 5 Tầng 5 chứa các code ứng dụng tùy biến dựa trên code ứng dụng của tầng 4

 Tầng nghiệp vụ (tầng 3): bao gồm các gói được tạo ra để chứa các trừu tượng hóa chính, các lớp

 Tầng giữa (tầng 2): bao gồm các gói được tạo ra để chứa các cơ chế, các dịch

thể cho một lớp hoặc thành phần liên quan đến nghiệp vụ; hoặc tương ứng với sự thực thi tương đồng giữa các lớp và/ hoặc các thành phần Các cơ chế kiến trúc có thể được thực thi như một khung dựng sẵn (Framework)

Các cơ chế kiến trúc bao gồm:

 Cơ chế phân tích: là cơ chế kiến trúc ở mức khái niệm

 Cơ chế thiết kế: là cơ chế ở mức cụ thể hơn của cơ chế phân tích Trong cơ chế này, một số các chi tiết của môi trường thực thi được giả định, nhưng không ràng buộc bởi một sự thực thi cụ thể như cơ chế thực thi (ví dụ: giả định môi trường là RDBMS hoặc OODBMS)

 Cơ chế thực thi: là cơ chế xác định chính xác việc thực thi cơ chế thiết kế

Cơ chế thực thi phụ thuộc vào một nền công nghệ cụ thể, ngôn ngữ cài đặt, nhà cung cấp hoặc một số nhân tố khác (ví dụ: nền công nghệ cụ thể là NET hoặc J2EE)

Ví dụ một số cơ chế kiến trúc:

 Cơ chế bền vững (Persistence): là cơ chế cho cơ sở dữ liệu, bao gồm các đặc

tả sau:

- Độ mịn: phạm vi kích thước của các đối tượng bền vững

- Dung lượng: số các đối tượng tuân thủ tính bền vững

- Thời gian có hiệu lực: thời gian mà các đối tượng tuân thủ tính bền vững

- Cơ chế truy cập: một hoặc nhiều đối tượng duy nhất đưa ra được xác định và được lấy như thế nào

- Tần suất truy cập (ví dụ: cho việc tạo/ xoá, sửa, đọc): các đối tượng

ít thay đổi hay được thay đổi và cập nhật thường xuyên

- Tính tin cậy: các đối tượng có thể tồn tại trong quá trình xử lý, bộ xử

 Cơ chế bảo mật (Security): là cơ chế việc cho các trường hợp sử dụng, bao gồm các đặc tả sau:

- Độ mịn dữ liệu: mức gói, mức lớp, mức thuộc tính

- Độ mịn thông tin người sử dụng: người sử dụng, các vai trò (role) hoặc các nhóm

- Các quy tắc bảo mật: dựa trên các giá trị dữ liệu, trên các thuật toán căn cứ trên dữ liệu và trên các thuật toán căn cứ trên dữ liệu và người

sử dụng

- Các quyền: đọc, ghi, tạo mới, xoá, thực thi một số thao tác khác

 Cơ chế phân phối (Distribution): cơ chế cho các lớp điều khiển, bao gồm các đặc tả sau:

- Khả năng mở rộng (Latency)

- Sự đồng bộ

- Kích thước của thông điệp

- Giao thức (Protocol)

Ví dụ: Hình 3.3 trình bày một ví dụ về mối liên hệ giữa các cơ chế kiến trúc:

từ cơ chế phân tích qua cơ chế thiết kế và đến cơ chế thực thi

Hình 3.3 Ví dụ về mối liên hệ giữa các cơ chế kiến trúc Dựa trên đặc điểm của các cơ chế phân tích, thiết kế và thực thi người ta có thể đưa ra các mẫu phân tích thiết kế nhằm đưa ra giải pháp chung cho các vấn đề chung trong phát triển phần mềm

3.1.3 Sự tham chiếu các tầng kiến trúc với MDA

Dựa vào đặc điểm của MDA (trình bày ở chương 2) và đặc điểm của các tầng kiến trúc (trình bày ở mục 3.1.1), cũng như tối ưu việc tổ chức các phần tử mô hình hoá, kiến trúc hướng mô hình có thể tham chiếu với các tầng kiến trúc hệ thống như sau:

Mô hình độc lập với thao tác tính toán (CIM) bao gồm: Tầng ứng dụng và một phần tầng nghiệp vụ (Ví dụ: các thông tin của thực thể)

Mô hình độc lập với nền công nghệ (PIM) bao gồm: Tầng nghiệp vụ (ví dụ: thực thể, hệ thống con và các giao diện của chúng) và một phần tầng giữa (ví dụ: cơ chế truy xuất CSDL)

Mô hình cụ thể của nền công nghệ (PSM) bao gồm: một phần tầng giữa (ví dụ: các cơ chế cụ thể theo nền công nghệ sử dụng) và tầng phần mềm hệ thống

3.2 Xác định nội dung của mô hình CIM

Mô hình CIM chủ yếu tập trung vào mối quan hệ giữa hệ thống với môi trường xung quanh nó (sự tương tác giữa các tác nhân và hệ thống được phát triển),

mô tả các tình huống hệ thống sẽ được sử dụng nhưng chưa định nghĩa chi tiết về cấu trúc tĩnh bên trong của hệ thống

3.2.1 Xác định các trừu tƣợng hóa chính

Các trừu tượng hoá chính là các đối tượng then chốt và đặc điểm chung của các đối tượng mà hệ thống cần nắm bắt được Việc xác định các trừu tượng hoá chính thực hiện dựa vào phạm vi hiểu biết, các yêu cầu, định nghĩa các thuật ngữ, và đặc biệt là mô hình đối tượng nghiệp vụ

Giai đoạn xác định các trừu tượng hóa chính chưa phát triển hoàn thiện mô hình lớp mà chỉ định nghĩa các đối tượng chính và các mối quan hệ cơ bản giữa chúng để làm cơ sở cho quá trình phân tích

Ví dụ: Hình 3.4 trình bày ví dụ các trừu tượng hóa chính là

“DMKhachHang”, “HopDongVay” và mối quan hệ giữa chúng

Hình 3.4 Ví dụ về các trừu tượng hóa chính

3.2.2 Xác định các tác nhân và các trươ ̀ ng hơ ̣p sử du ̣ng

Trong giai đoạn phân tích các trường hợp sử dụng, người phân tích hệ thống

sẽ tập trung vào việc tìm hiểu vấn đề, tìm hiểu yêu cầu nghiệp vụ để có cái nhìn tổng quan về hệ thống, xác định các chức năng chính hệ thống cần đáp ứng cho người sử dụng nhưng chưa đi chi tiết vào việc hệ thống thực hiện các chức năng đó như thế nào

 Xác định các tác nhân (Actor) của hệ thống

Các tác nhân không phải là một phần của hệ thống Tác nhân bao gồm các hệ thống bên ngoài hoặc con người có sự tương tác trực tiếp với hệ thống được phát triển

Một tác nhân có thể chỉ cung cấp thông tin cho hệ thống, chỉ lấy thông tin từ

hệ thống, hoặc vừa lấy thông tin từ hệ thống vừa cung cấp thông tin cho hệ thống

Ví dụ: Hình 3.5 ký hiệu một tác nhân “Người quản lý hợp đồng vay” của hệ thống

Hình 3.5 Ví dụ một tác nhân “Người quản lý hợp đồng vay”

 Xác định các trường hợp sử dụng (Use Case) của hệ thống

Các ứng xử nghiệp vụ của hệ thống sẽ được chuyển thành các trường hợp sử dụng của hệ thống Một trường hợp sử dụng là tổ hợp các chức năng của hệ thống mà những chức năng đó có thể được thực hiện trên cùng nhóm thực thể Tùy theo mức độ phức tạp và độ lớn của chức năng mà người ta có thể chia ra các loại trường hợp sử dụng:

- Từ 1đến 3 chức năng: trường hợp sử dụng đơn giản

- Từ 4 đến 7 chức năng: trường hợp sử dụng có độ phức tạp trung bình

- Từ 8 - 15 chức năng: trường hợp sử dụng phức tạp

- Nếu có nhiều hơn 15 chức năng: trường hợp sử dụng này nên được tách thành các trường hợp sử dụng nhỏ hơn

Ví dụ: Hình 3.6 ký hiệu một trường hợp sử dụng “Quản lý Hợp đồng vay”

Hình 3.6 Ví dụ một trường hợp sử dụng “Quản lý Hợp đồng vay”

 Xác định quan hệ giữa các tác nhân với các trường hợp sử dụng của hệ thống

Tác nhân luôn có mối quan hệ truyền đạt với các trường hợp sử dụng liên quan Dưới đây là một số các quan hệ giữa tác nhân và hệ thống:

 Quan hệ sử dụng (Include):

Nếu một số trường hợp sử dụng cùng có chung một số chức năng thì các chức năng chung đó nên được tách ra một trường hợp sử dụng con và các trường hợp chính sẽ sử dụng trường hợp sử dụng con đó

Ví dụ: Hình 3.7 trình bày ví dụ về quan hệ “sử dụng” giữa các trường hợp sử dụng Trong Hệ thống “Quản lý Tín dụng trong ngân hàng”, hai trường hợp sử dụng

“Quản lý Hợp đồng vay” và “Quản lý danh mục” đều bắt đầu việc đăng nhập hệ thống Vì vậy chức năng “Đăng nhập hệ thống” được tách ra thành một trường hợp

sử dụng con chung cho hai trường hợp sử dụng “Quản lý Hợp đồng vay” và “Quản

lý danh mục” sử du ̣ng

Hình 3.7 Ví dụ về quan hệ “sử dụng” giữa các trường hợp sử dụng

 Quan hệ tổng quan hóa (Generalization):

Một trường hợp sử dụng thừa kế từ một trường hợp sử dụng khác có nghĩa là trường hợp sử dụng đó có đầy đủ các chức năng của trường hợp sử dụng được thừa

kế, và ngoài ra có thể có thêm các chức năng khác

Ví dụ: Hình 3.8 trình bày một ví dụ trường hợp sử dụng “Quản lý tín dụng” đươ ̣c tổng quan hóa từ hai trường hợp sử du ̣ng “Quản lý Hợp đồng vay” và “Quản

lý Khế ước”

Hình 3.8 Ví dụ về quan hệ “tổng quan hóa” giữa các trường hợp sử du ̣ng

 Quan hệ mở rộng (Extends):

Quan hệ mở rộng dùng để chỉ:

- Các chức năng tùy chọn (có thể thực hiện hoặc không)

- Các hành vi mà chỉ thực hiện trong một số điều kiện nhất định

- Các hành vi sẽ được thực hiện tùy thuộc vào sự lựa chọn của người

sử dụng

Ví dụ: Hình 3.9 trình bày một ví dụ về quan hệ “mở rộng” giữa các trường hợp sử dụng Trong hệ thống “Quản lý Tín dụng trong ngân hàng”, người sử dụng có thể chọn chức năng lập báo cáo thống kê về các hợp đồng vay theo một số tiêu chí tùy chọn như: theo chi nhánh cho vay, theo khoảng thời gian phát vay, theo sản phẩm vay, theo loại tiền Vì vậy trường hợp sử dụng

“Thống kê hợp đồng vay theo chi nhánh”, “Thống kê hợp đồng vay theo khoảng thời gian phát vay”, “Thống kê hợp đồng vay theo sản phẩm vay”,

“Thống kê hợp đồng vay theo loại tiền” là các trường hợp sử dụng mở rộng của trường hợp sử dụng “Báo cáo thống kê về Hợp đồng vay”

Hình 3.9 Ví dụ về quan hệ “mở rộng” giữa các trường hợp sử dụng

3.2.3 Biều diễn mối quan hệ giữa tác nhân và trường hợp sử dụng

Sau khi đã nắm được chi tiết nghiệp vụ hệ thống, người phân tích hệ thống cần biểu diễn các ứng xử tương tác qua lại giữa tác nhân và các trường hợp sử dụng của hệ thống thông qua các biểu đồ tương tác như: biểu đồ diễn tiến (cho các dòng

sự kiện chính) và biểu đồ hoạt động (cho các dòng sự kiện rẽ nhánh) Các biểu đồ này nhằm làm rõ các tác động của tác nhân vào hệ thống và các hoạt động hệ thống thực hiện đáp trả lại tác nhân

Ví dụ: Hình 3.10 trình bày ví dụ một biểu đồ diễn tiến thể hiện dòng sự kiện chính sự tương tác giữa tác nhân “ Người quản lý tín dụng” và trường hợp sử dụng

“Quản lý Hợp đồng vay” trong chức năng “Tạo mới một Hợp đồng vay”

Hình 3.10 Ví dụ một biểu đồ diễn tiến thể hiê ̣n sự tương tác giữa tác nhân và trườ ng hơ ̣p sử du ̣ng trong chức năng “Ta ̣o mới mô ̣t Hợp đồng vay”

Ví dụ: Hình 3.11 trình bày ví dụ mô ̣t biểu đồ hoạt động thể hiện dòng sự kiện rẽ nhánh “Nhập trùng mã hợp đồng vay” trong chức năng “Tạo mới một Hợp đồng vay” của trường hợp sử dụng “Quản lý Hợp đồng vay”

Hình 3.11 Ví dụ một biểu đồ hoạt động thể hiện dòng sự kiện rẽ nhánh

“Nhập trùng mã hợp đồng vay”

3.2.4 Bổ sung mô tả cho trường hợp sử dụng

Mô tả của mỗi trường hợp sử dụng thường không đủ để tìm ra các lớp phân tích và các đối tượng của chúng Hệ thống được mô tả như một “hộp đen”, mới xác định được đầu vào, đầu ra mà chưa thể hiện bên trong hệ thống hoạt động như thế nào, thực hiện những ứng xử gì để có thông tin đáp lại các hành động của tác nhân

Trong giai đoạn này, các ứng xử bên trong “hộp đen” cần được làm rõ, tức là người phân tích cần mô tả cụ thể những ứng xử bên trong mà hệ thống cần thực hiện và tiến hành cung cấp thông tin chi tiết đến mức tối đa có thể để làm rõ thêm nghiệp vụ của hệ thống

Ví dụ : Hình 3.12 mô phỏng viê ̣c bổ sung thông tin chi tiết cho chức năng

“Xem danh sách các Hợp đồng vay” trong trường hợp sử dụng “Quản lý Hợp đồng vay”

Hình 3.12 Ví dụ về việc bổ sung thông tin cho trường hợp sử dụng

3.3 Chuyển đổi mô hình CIM sang mô hình PIM

3.3.1 Chuyển đổi các thành phần của mô hình CIM thành các phần tử

phân tích trong mô hình PIM

Mục đích bước này là với mỗi thực thi trường hợp sử dụng, người phân tích

hệ thống sẽ tìm tất cả các lớp phân tích bao gồm: lớp biên, lớp điều khiển, lớp thực thể từ ứng xử của trường hợp sử dụng và phân phối các ứng xử cho các lớp

3.3.1.1 Các luật chuyển đổi

 Mỗi cặp tác nhân/ trường hợp sử dụng sẽ có một hoặc nhiều lớp biên (Boundary Class) (được đi ̣nh nghĩa chi tiết ở mục 3.3.1.2)

 Mỗi trường hợp sử dụng sẽ được chuyển đổi thành một lớp điều khiển (Control Class) (được đi ̣nh nghĩa chi tiết ở mục 3.3.1.2) Lớp này sẽ chứa tất cả các thao tác nghiệp vụ của hệ thống

 Các thông tin được xử lý bởi lớp điều khiển trong một trường hợp sử dụng được quản lý và lưu trữ trong một hoặc nhiều lớp thực thể (Entity Class) (đươ ̣c

đi ̣nh nghĩa chi tiết ở mục 3.3.1.2)

 Ứng xử của mỗi trường hợp sử dụng được thể hiện qua biểu đồ diễn tiến (Sequence Diagram) có các tác nhân và các lớp phân tích tham gia

3.3.1.2 Xác định các lớp phân tích của trường hợp sử dụng

Xác định các lớp phân tích là việc xác định các lớp có khả năng thực hiện các ứng xử được mô tả trong trường hợp sử dụng Các lớp phân tích bao gồm: các lớp biên, các lớp điều khiển, các lớp thực thể

Hình 3.13 Tổng quan về các lớp phân tích

 Xác định các lớp biên

Một lớp biên mô hình hoá sự tương tác giữa tác nhân với hệ thống Sự tương tác bao gồm việc chuyển đổi và biên dịch các sự kiện và tập trung vào các thao tác và sự kiện phát sinh trong hệ thống

Hệ thống được phát triển thường có 3 loại lớp biên như sau:

- Các lớp giao diện người sử dụng (User Interface Class): là trung gian giao tiếp giữa người sử dụng hệ thống và hệ thống được phát triển

- Các lớp giao diện hệ thống (System Interface Class): là trung gian giao tiếp giữa hệ thống được phát triển với các hệ thống khác, và có nhiệm vụ quản lý các đối thoại với hệ thống bên ngoài

- Các lớp giao diện điều khiển (Device Interface Class): cung cấp giao diện

để nhận biết và điều khiển các thiết bị ngoại vi

Ví dụ: Hình 3.14 trình bày ví dụ một lớp biên “HopDongVayForm” là trung gian giao tiếp giữa tác nhân “Người quản lý tín dụng” với trường hợp sử dụng “Quản lý Hợp đồng vay”

Hình 3.14 Ví dụ một lớp biên “HopDongVayForm”

 Xác định các lớp điều khiển

Lớp điều khiển thể hiện các hoạt động của hệ thống, quản lý các tác vụ và các luồng điều khiển chính và rẽ nhánh của hệ thống, mô hình hóa các ứng xử điều khiển cụ thể cho một hoặc nhiều trường hợp sử dụng

Khi hệ thống thi hành trường hợp sử dụng, một đối tượng điều khiển được tạo ra và chúng mất đi khi trường hợp sử dụng tương ứng với chúng đã được thi hành

Các lớp điều khiển cung cấp các ứng xử:

- Định nghĩa các logic điều khiển (sắp xếp thứ tự giữa các sự kiện) và các giao dịch trong một trường hợp sử dụng

- Sử dụng hoặc bố trí các thông tin của các lớp thực thể có liên quan, và do

đó cần kết hợp ứng xử của các lớp thực thể đó

- Không thực thi theo một cách như nhau ở mỗi thời điểm được kích hoạt

Ví dụ: Hình 3.15 trình bày ví dụ một lớp điều khiển “HopDongVayControl” cung cấp các ứng xử của trường hợp sử dụng “Quản lý HopDongVay”

Hình 3.15 Ví dụ một lớp điều khiển “HopDongVayControl”

 Xác định các lớp thực thể

Chức năng chính của các lớp thực thể là lưu trữ và quản lý thông tin trong hệ thống Các đối tượng thực thể (các trường hợp của lớp thực thể) được sử dụng để chứa và cập nhật thông tin về một số các hiện tượng như: một sự kiện, một người, hoặc một đối tượng thực sự tồn tại Chúng thường bền vững, có các thuộc tính và các mối quan hệ cần thiết cho một giai đoạn dài, đôi khi cho cả vòng đời của hệ thống

Ví dụ: Hình 3.16 trình bày ví dụ một lớp thực thể “HopDongVay” của trường hợp sử dụng “Quản lý HopDongVay” có chứa các thuộc tính