uml và ứng dụng để xây dựng mô hình cho hệ thống tín dụng

Thập niên 90 đã xuất hiện một số phương pháp hướng đôí tượng chủ yếu sau xem [2]: > Grady Booch: định nghĩa các khái niệm mà trong đó hệ thống được phân tích thành 1 số các view, mổi vie

MAI THỊ THANH HƯỜNG

UML VÀ ÚNG DỤNG ĐỂ XÂY DỤNG MÔ HÌNH CHO HỆ THỐNG TÍN DỤNG

LUẬN VĂN THẠC s ĩ KHOA HỌC• • •

0A> H ÇC C.UOC G f>- Î" ft

TRŨKGTÀM ■ S’HGÎÎ-'- í H ư '

H À N Ộ I, N Ă M 2001

MAI THỊ THANH HƯỜNG

UML YÀ ÚNG DỤNG ĐỂ XÂY DựNG MÔ HÌNH CHO HỆ THỐNG TÍN DỤNG

C H U YÊ N N G À N H : CÔNG NG H Ệ THÔNG T IN

M Ả SỐ:

LUẬN VĂN THẠC s ĩ KHOA HỌC• « a

H À NỘ I, N Á M 2001

1.1 Mục đích của việc xây dựng mồ hình cho hệ thống 3

1.2 Lịch sử phát triển của U M L 5

1.3 Mục liêu của U M L 7

1.4 ứ n g dụng của U M L 7

1.5 Các thảnh phần của UML 8

1.5.1 Các phần tử mô hình 8

1.5.2 Các biểu đ ồ 9

1.5.3 Các view 13

1.5.4 Các cơ chế chung của U M L 16

CHƯƠNG 2 PHÂN TÍCH, THIÊT KẾ HƯỚNG ĐÔÍ TƯỢNG s ử DỤNG UML ! 19

2.1 Phân tích Use case 22

2.1.1 Actor 22

2.1.2 Xác định các Actor 23

2.1.3 Use case 24

2.1.4 Các mối quan h ệ 30

2.1.5 Biếu đồ Use c a s e 31

2.2 Tim lớ p 34

2.2.1 Đối tượng 34

2.2.2 L ớ p r 34

2.2.3 Các quan h ệ 38

2.2.4 G ói 42

2.2.5 Biểu đồ đối tượng 44

2.3 Phàn tích sự tương tác giữa các đối tượng 45

2.3.1 Kịch b ả n 45

2.3.2 Biểu đồ trình tự 47

2.3.3 Biểu đồ hợp tác 49

2.4 Them vào các thuộc tính và phương thức cho lớp 50

2.4.1 Thuộc tín h 50

2.4.2 Phương thức 51

2.5 Xác định ứng xử của đối tượng 52

2.5.1 Biểu đồ trạng th á i 52

2.5.2 Biêu đồ hoạt động 55

2.6 Xác định kiến trúc của hệ thống 57

2.6.1 Thành phần (xem [3]) 57

2.6.2 Biểu đồ thành phần 57

2.6.3 Biêu đồ triển k h a i 58

CHƯƠNG 3 - ÚNG DỤNG ƯML ĐỂ XÂY D ựN G MÔ HÌNH CHO HỆ THỐNG TÍN D Ụ N G 59

3 1 Phát biểu bài to án 59

3.2 Mô tá nghiệp vụ 59

3.3 Mỏ tả quy trình kỹ thuật 60

3.4 Yêu cầu 60

3.5 Phân tích Use case 61

3.5.1 Các Actor của hệ thống 61

3.5.2 Danh sách Use case: 62

3.5.3 Mô tả các Use case 66

3.5.4 Các biểu đồ Use case 71

3.6 Biểu đồ lớ p 74

3.6.1 Các lớp thực thể (Entity Class) 74

3.6.2 Các lớp biên (Boundary Classes) 83

3.6.3 Các lớp điều khiển (Control Classes) 102

3.7 Sự tương tác giữa các đối tư ợ n g 103

3.7.1 Kịch b ả n 7 ' 103

3.7.2 BỈểu đồ trình tự 104

3.7.3 Biểu đổ hợp tác 105

3.8 Biêu đồ triển k h a i 106

KẾT LUẬN 107

những người làm tin học nói chung và những người làm phần mềm nói riêng Vậy UML là gì nó được sử dụng để làm gì, cách thức sử dụng nó như thế nào? Luận văn

“ UML và ứng dụng để xây dựng mô hình cho hệ thống tín dụng” sẽ trả lời cho các câu hỏi đó

Luận văn này gồm 3 phần Phần I giới thiệu tổng quan về ƯML, sự ra đời, phát triển và các thành phần của ƯML UML là một ngổn ngữ mô hình hoá thống nhất, nó tổng hợp được ưu điểm trong các phương pháp của 3 nhà sáng lập (Grady Booch, James Rumbaugh và Ivar Jacobson) và hạn chế khuyết điểm trong các phương pháp đó UML được sử dụng đê mổ hình cho rất nhiều hệ thống, không nhất thiết phái là các hệ thống phần mềm

Phần II xây dựng quy trình cho việc phân tích thiết kế hệ thống sử dụng ƯML Quy trình này bao gồm các bước như sau:

Bước 1 : Cách xác định các Actor, các use case, mối quan hệ giữa các use case từ đó xây dựng được biểu đồ use case

Bước 2: Cách xác định các lớp, các đối tượng, mối quan hệ giữa các lớp hay giữa các đối tượngbiểu đổ lớp và biểu đồ đối tượng

Bước 3: Cách xác định các kịch bản từ use case, từ đó xây dựng biểu đồ trình

tự và biểu đồ hợp tác

Bước 4: Thêm vào các thuộc tính và phương thức cho các lớp

Bước 5: Cách xác định các ứng xử của mỗi đối tượng thông qua biểu đồ trạng thái và biêu đồ hoạt động Một số gợi ý để có thể xây dựng biểu đồ trạng thái từ biểu

dạne các yêu cầu mà hệ thống cần phải đáp ứng Trên cơ sở các yêu cầu đó xây dựng nên một mô hình, việc xây dựng mô hình này áp dụng các lý thuyết đã được nêu ở phần II Đầu tiên là xác định các Actor của hệ thống, sau đó liệt kê các use case có thể có dựa trên các yêu cầu đã được xác định trong phần trên Việc xác định các lớp thực thể, các lớp biên và các lớp điểu khiển dựa vào các Actor và các use case đã tìm được Việc mô tả chi tiết các use case giúp tìm kiếm các kịch bản và từ các kịch bản này các biểu đồ trình tự và biểu đồ hợp tác được xây dựng Từ đó ta có thê hình dung được hệ thống theo cả hai mặt tĩnh và động Phần này sử dụng công

cụ Rational Rose để vẽ các lớp, các Actor cũng như các biểu đồ Thông qua phần này, ta có thế hiểu được cách thức sử dụng UML đê’ giải quyết một bài toán trong thực tế

Trong quá trình làm chắc chắn không thể tránh khỏi những sai sót, em rất mong nhộn được sự góp ý của các thầy cô Em cũng xin gửi lời cảm ơn chân thành đến PGS Nguyền Quốc Toản, người đã giúp đỡ em rất nhiều để em có thể hoàn thành luận vãn này

Hà Nội ngày 14 tháng 11 năm 2001

Mai Thị Thanh Hường

Mô hình hóa là một cách xem xét bài toán thông qua việc sử dụng các mỏ hình Mó hình sẽ giúp con người hiểu rõ bài toán, và thông qua mô hình việc trao đổi thống tin giữa những người liên quan như khách hàng, chuyên gia, người phân tích, người thiết kế trở nên thuận tiện hơn Mô hình giúp cho việc xác định các yêu cầu tốt hơn, thiết kế rõ ràng hơn và khả năng bảo trì hệ thống cao hơn.

Mô hình là sự trừu tượng hóa, mô tả mặt bản chất của một vấn đề hoặc một cấu trúc phức tạp bằng cách loại bò những chi tiết không quan trọng, khiến cho bài toán trở nên dễ hiểu và dễ nắm bắt hơn Người ta đã sử dụng mô hình hoá để giải quyết các vấn đề của cuộc sống đời thường Chẳng hạn trước khi sản xuất một chiếc

ô tố, ta phải có bản thiết kế của chiếc ô tô đó, hình dáng của nó ra sao, màu sắc như thế nào? Việc phát triển các hệ thống phần mềm cũng tương tự như vậy Để xây dựng một hệ thống phức tạp, những người phát triển phải trừu tượng hóa những View khác nhau của hệ thống, xây dựng các mô hình bằng cách sử dụng các kí hiệu, kiểm tra xem các mô hình đã thoả mãn các yêu cầu của hệ thống chưa và dần dần thêm vào các chi tiết để có thể chuyển đổi từ mô hình sang một cài đặt cụ thể

Một câu hỏi đặt ra là tại sao chúng ta phải xây dựng mô hình của hệ thống, đặc biệt là những hệ thống phức tạp? Bởi vì chúng ta không thể hình dung, không thể hiểu trọn vẹn một lúc toàn bộ hệ thống đó Ví dụ như khi thêu một bông hoa chúng ta có thể thêu ngay, nhưng khi thêu một bức tranh ta phải có một bức tranh mẫu trên giấy Trong việc sản xuất phần mềm cũng tương tự như vậy Hệ thống càng phức tạp thì việc xây dựng mô hình càng quan trọng Xây dựng mô hình cho phép người thiết kế thấy được bức tranh tổng quan của hệ thống, thấy được các thành phần của hệ thống tương tác với nhau như thế nào, hình dung được hệ thống từ nhiều View khác nhau

Ngày nav việc xây dựng các ứng dụng không còn là vấn đề, mà vấn đé là ớ chỗ xây dựng được các ứne dụng có chất lượng cao, đáp ứng đầy đủ các yêu cầu của khách hàng, đúng thời hạn và với chi phí hợp lý Một tổ chức phát triển phần mềm

lốt Người ta xây dựng mô hình để trao đổi, bàn bạc về cấu trúc và ứng xử (behavior) mong muốn của hệ thống Người ta xây dựng mô hình để trực quan hóa và kiểm soát kiến trúc của hệ thống.

Mô hình có thể mô tả các cấu trúc, nhấn mạnh về mặt tổ chức của hệ thống hoặc nó có thể mô tả các hành vi, tập trung vào mặt động của hệ thống

Việc xây dựng mô hình giúp chúng ta hiểu rõ hơn về hệ thống mà mình đang xây dựng, tạo ra cơ hội đê đơn giản hóa và tái sử dụng Xâv dựng mô hình cũng giúp chúng ta Irong việc kiểm soát rủi ro

Việc xây dựng mô hình giúp chúng ta đạt được 4 mục đích sau:

• Mô hình giúp chúng ta trực quan hóa hệ thống như là nó vốn có hay theo cách mà chúng ta muốn nó sẽ như vậy

• Mồ hình cho phép chúng ta chỉ rõ cấu trúc và ứng xử của hệ thống

• Mô hình cho một khuôn mẫu đế hướng dẫn chúng ta trong quá trình xây dựng hệ thống

• Mô hình đưa ra các dẫn chứng bằng tài liệu về các quyết định mà chúng ta đã đưa ra trong quá trình thiết kế hệ thống

Bằng việc mô hình hoá, tại một thời điểm chúng ta chỉ tập trung nghiên cứu một khía cạnh nào đó của bài toán Điều này cũng giống như việc chia một bài toán lớn thành các bài toán nhỏ mà ta có thê’ giải quyết được

Mỏ hình hóa là việc đơn gián hóa thực tế, loại bót những điểm không cần thiết, nhưng ta vẫn phải đảm bảo rầng mình không bỏ sót một chi tiết quan trọng nào

Tùy thuộc vào vêu cầu của từng bài toán, tuv vào đặc điểm của từng hệ thống, mỗi mô hình có thể tập trung vào những View khác nhau của hệ thống

1.2 Lịch sử phát triển của UML

Khái niệm đối tượng ra đời kéo theo sự ra đời của các phương pháp hướng đối tượng Thập niên 90 đã xuất hiện một số phương pháp hướng đôí tượng chủ yếu sau (xem [2]):

> Grady Booch: định nghĩa các khái niệm mà trong đó hệ thống được phân tích thành 1 số các view, mổi view được mỏ tả bằng một số biểu đồ mô hình Phương pháp này có một khuyết điểm là có một số các ký hiệu khó sử dụng, khó vẽ

> OMT (Object Modeling Techique): do James Rumbaugh (trước làm ở General Electric) đưa ra Nó là một tiến trình mạnh để kiểm nghiệm dựa trên việc đặc tả các yêu cầu Được mô tả bởi một số các mô hình như mô hình đối tượng, mô hình động, mô hình chức năng, mô hình Use-case

> OOSE (Object - Oriented Software Engineering) /Objectory: do Ivar Jacobson đưa ra OOSE là một phương pháp hướng đối tượng, phương pháp Objectory được sử dụng để xây dựng các hệ thống như hệ thống viễn thông cho Ericson, hệ thống k ế toán cho công ty WallStreat Cả hai phương pháp đéu dựa trên các Use-case mô tả các yêu cầu đầu tiên của hệ thống như là được các Actor ngoài nhìn thấy Sau đó Use-case được thi hành trong tất cả các pha khi phát triển, tất cả các cách để kiềm nghiệm hệ thống khi nó được (lùng đê kiểm thử hệ thống

> Fusion do Hewlett-Packard đưa ra.

> Coad/Yourdon (OOA/OOD)

Các phương pháp trên, mỗi phương pháp lại có những điểm mạnh và điểm yếu riêng Vấn đề là làm sao để có được một phương pháp tích hợp được những ưu điểm của mọi phương pháp trên và hạn chế những khuyết điểm của chúng Ngoài việc tích hợp các ưu điểm, hạn chế các khuyết điểm, phương pháp mới này còn phải thống nhất được các ký hiệu của các phương pháp Bởi vì cùng một ký hiệu nhưng dùng trong các phương pháp khác nhau lại có thể mang V nghĩa khác nhau Vì vậy việc thống nhất được cách dùng các ký hiệu cũng là điều rất quan trọng

nhóm này) Mục tiêu của họ là tạo ra một phương pháp mới, phương pháp thống nhất dựa trên các phương pháp của Booch, Rumbaugh và Jacobson Dựa vào việc hợp nhất các kv hiệu sử dụng trong khi phân tích, thiết k ế của các phương pháp đó, UML đưa ra một nền tảng chuẩn cho việc phân tích, thiết kế.

Tháng 7-1997 phiên bản 1.0 được còng bố và coi là chuẩn của tổ chức OMG (Object Management Group)

Vé cơ bản ƯML dựa trên Booch của Booch, OM T của James Rumbaugh và OOSE của Ivar Jacobson nhưng họ cũng kết hợp một vài ý tưởng cuả các phương pháp khác như State Charts của David Hareỉ và chuyển nó thành State Diagram trong UML hay sử dụng thao tác đánh dấu trong chú thích của Fusion trong biểu đồ hợp tác (collaboration diagram)

UML (Unified Modeling Laguage) được dùng để mô hình cho các hệ thống hay dùng trong những giai đoạn khác nhau của phát triển hệ thống từ đặc tả đến kiểm thử hệ thống cuối cùng

Hình 1.1

R um h au g h

numbering

1.3 Mục tiêu của UML

■ Mô hình các hệ thống (không chỉ các hệ thống phần m ềm), sử dụng các kháiniệm hướng đối tượng

■ Tạo ra một ngôn ngữ mô hình có thể sử dụng được bởi cả người và máy

1.4 ứ n g dụng của UML

ƯML có ứng dụng rất rộng rãi, không chỉ trong các hệ thống phần mềm mà còn ở nhiều lĩnh vực khác như các hệ thống kỹ thuật hay các hệ thống kinh doanh, nghiệp vụ Một số hệ thống mà ƯML có thể mô tả là:

■ Hệ thông tin: lưu trữ, tìm kiếm, biến đổi và trình bày thông tin cho ngườidùng Phái giải quyết một số lượng lớn dữ liệu với mối quan hệ phức tạpthường được cất giữ trong CSDL quan hệ hav CSDL đối tượng

mức thấp và đòi hỏi sự hỗ trợ thời gian thực

* Hệ phân bố: được phân bố trên một số máy tính còn dữ liệu được truyền từ máy nọ sang maý kia Hệ này đòi hỏi truyền thông đồng bộ, được xây dựng dựa trên các hệ hướng đối tượng như CORBA, COM/DCOM, JavaBean

■ Phần mềm hệ thống: hệ điều hành, CSDL

■ Hệ thống nghiệp vụ: mô tả các mục tiêu các nguồn tài nguvên (con người, máy tính), các quy tắc (luật, chiến lược kinh doanh) và công việc thực tại trong nghiệp vụ

1.5 Các thành phần của UML

UML có 3 thành phần chính đó là các phần tử mô hình, các biểu đồ và các view Phẩn tử mô hình là những khái niệm mà người la sử dụng trong các biểu đồ, hiểu hiện cho các khái niệm đối tượng nói chung Nó được dùng trong nhiều biểu đồ khác nhau nhưng có cùng ký hiệu về ngữ nghĩa View được tạo nên từ các biểu đồ Mỗi view cung cấp cho ta một cái nhìn về một khía cạnh nào đó của hệ thống Tập hợp các view cho ta một cái nhìn toàn cảnh về hệ thống

1.5.1 Các phần tử mô hình

Các khái niệm dùng trong các biểu đồ gọi là các phần tử m ô hình Một phần

tứ mô hình được định nghĩa với ngữ nghĩa, 1 định nghĩa hình thức cho phần tử đó hay V nghĩa đích xác của điều nó biếu diễn

Một phần tử mô hình có một phần tử view tương írng là một thể hiện đồ hoạ của phần tử đó hay ký hiệu đồ hoạ được dùng để thể hiện phần tử trong các biểu đồ Một phần tử có thể có mặt trong một vài loại biểu đồ khác nhau nhưng có một luật

để xác định phần tử nào có thể có mặt trong biểu đổ nào Một vài ví dụ về các phần

tử mô hình là class, object, State, node, package, component

Class Object

attributes attributes

oprations oprations

•S Association: Kết nối các phần tử và liên kết các thực thể

s Generalization: còn gọi là sự kế thừa, nghĩa là một phần tử có thể là trường

hợp riêng của một phần tử khác, còn gọi là quan hệ chung - riêng

s Dependency: một phần tử phụ thuộc một phần tử khác theo một cách nào đó

s Aggregation: là một dạng của quan hệ association mà trong đó một phần tử

chứa một hay nhiều phần tử khác, còn gọi là quan hệ toàn thể - bộ phận

associationdependency

aggregation (a form of association)

- ^ ^

generalization

>

Hình 1.3 - Các liên kết1.5.2 Các biểu đồ

Biểu đổ (diagram) là các đồ thị mô tả các nội dung chứa trong view UML có

9 loại hiểu đồ khác nhau Phần lớn các biểu đổ được thể hiện như một đổ thị gồm các đinh (các sự vật) và các cung (các quan hệ) ([6])

UML có 9 loại biếu đồ chia thành 2 nhóm khác nhau Nhóm thứ nhất gồm 4 loại hiểu đổ là biểu đồ lớp (class diagram), biểu đồ đối tượng (object diagram), biểu

đổ thành phần (component diagram) và biểu đổ triển khai (deployment diagram) Nhóm này mô tả các phần tĩnh của hệ thống và được gọi là các biểu đổ cấu trúc

(stmctural diagrams) hay biểu đồ tĩnh Nhóm thứ hai gồm các biếu đồ: biểu đồ Use- case (Use-case diagram), biểu đồ trình tự (sequence diagram), biểu đồ hợp tác (collaboration diagram), biểu đồ trạng thái (state diagram) và biểu đồ hoạt động (activity diagram) Các biếu đồ này mô tả phần động của hệ thống và được gọi là các biểu đồ cư xử (behavioral diagrams) hay biểu đồ động (dynamic diagrams).

1.5.2.1 Các biểu đồ câu trúc (structural diagrams)

Bốn loại biểu đồ cấu trúc của UML cho phép ta hình dung, chỉ ra, xây đựng

và làm tài liệu các khía cạnh tĩnh của hệ thống Có thể coi các khía cạnh tĩnh của hệ thống như một sự thể hiện tương đối phần khung cố định Giống như các mặt tĩnh của một ngôi nhà bao gồm các vật và cách sắp xếp như các bức tường, các cửa sổ, các ống dẫn và các lỗ Ihông, các mặt tĩnh của hệ thống phần mềm bao gồm các lớp, các giao diện, các sự hợp tác, các thành phần và các nút

Các biểu đồ cấu trúc của UML được tổ chức dựa trên các nhóm sự vật chính như sau: biểu đồ lớp dùng các lớp, các giao diện và các sự hợp tác, biểu đồ đối tượng dùng các đối tượng, biểu đồ thành phần dùng các thành phần còn biểu đồ triển khai

dùng các nút.

1.5.2.1.1 Biểu đó lớp (class diagram)

Biêu đồ lớp: chỉ ra tập hợp các lớp, các giao diện, các sự hợp tác và các mối quan hệ của chúng Người ta sử dụng các biểu đồ lớp để minh hoạ thiết kế tĩnh của

hệ thống Các lớp biểu diễn cho các sự vật được xử lý bên trong hệ thống Các lớp có thể có quan hệ với nhau theo một số cách sau:

s Liên kết (lớp nọ nối với lớp kia)

s Phụ thuộc ( 1 lớp này phụ thuộc hay dùng lớp kia)

S Đặc biệt hoá (lớp này ỉà một phần tử đặc biệt của lớp kia)

s Đóng gói (nhiều lớp gộp lại)

Một hệ thống có nhiều biểu đổ lớp và ngược lại một biểu đồ lớp có thể có mặt

ở nhiều hệ thống

1.5.2.1.2 Biêu đó đỏi tượng (object diagram)

Biểu đồ đối tượng chỉ ra tập hợp các đối lượng và các mối quan hệ của chúng Người ta sử dụng biểu đồ đối tượng để minh hoạ các cấu trúc dữ liệu, các thực thế của các lớp trong biểu đồ lớp Có thê coi biểu đồ đối tượng là một biến thể cùa biểu đồ lớp, nó dùng các ký hiệu hầu hết giông biếu đổ lớp Biểu đồ đối tượng chí ra một số thể nghiệm đối tượng của một lớp.

1.5.2.1.3 Biểu dó thành phần (component diagram)

Biểu đồ thành phần chỉ ra tập hợp các thành phần và các mối quan hệ của chúng Người ta sử dụng biểu đồ thành phần để minh hoạ sự Ihực thi tĩnh của hệ thống Các biểu đồ thành phần được liên kết với các biểu đổ lớp khi thành phần đó ánh xạ đến một hoặc nhiều lớp giao diện hay các sự hợp tác Thành phần (component) có chứa thông tin về lớp logic mà nó cài đặt, và do vậy tạo ra một ánh

xạ từ logical view sang component view Biểu đồ thành phần được đùng trong công việc lập trình thực tế

1.5.2.1.4 Biểu đồ triển khai (deployment diagram)

Biểu đồ triển khai chỉ ra tập hợp các nút và các mối quan hệ của chúng Người ta sử dụng các biểu đồ triển khai để minh hoạ phần triển khai tĩnh của kiến trúc (chỉ ra các máy tính và các thiết bị thực tế và các liên kết của chúng với nhau) Các biểu đồ triển khai được liên kết với biểu đổ thành phần khi mà nút đó bao gồm một hoặc nhiều thành phần Bên trong mỗi nút các thành phần Ihực hiện được và các đối tượng được cấp phát để chỉ ra các đơn vị phần mềm nào thực hiện ở những nút nào

1.5.2.2 C ác biểu đồ cư xử hay biểu đồ động (behavioral diagrams)

Nãm loại biểu đồ cư xử do UML cung cấp được sử dụng để hình dung, xác định, xây dựng và làm tài liệu về các khía cạnh động của hệ thống Ta có thể coi các khía cạnh động của hệ thống thê hiện cho các phần có thể thay đổi đó là luồng các thông báo và sự di chuyển vật lý của các thành phần trong mạng Trong đó biểu đồ use-case thiết lập các cư xử của hệ thống, biểu đồ trình tự tập trung vào trình tự thời gian của các thông báo, biểu đổ hợp tác tập trung vào tổ chức về mặt cấu trúc của

các đối tượng truyền nhận thông báo, biểu đồ trạng thái tập trung vào sự thay đổi trạng thái của hệ thống tác động bởi các sự kiện còn biểu đổ hoạt động tập trung vào

mô tả các sự cư xử có nhiều tiến trình song song

1.5.2.2.1 Biêu đồ Use-case (Use-case diagram) (xem [4])

Biếu đổ Use-case chi ra 1 số Actor và mối nối của chúng với các trường hợp

sử dụng (Use-case) mà hệ thống cung cấp Nó mô tả về mặt chức năng mà hệ thống cung cấp, được mô tả bằng lời hoặc bằng biểu đồ Ưse-case Đồng thời nó định nghĩa các yêu cầu chức năng cuả hệ thống Các Actor ngoài không nhất thiết phải là con người mà có thể là các hình vẽ trong ban thân Ưse-casc diagram Actor ngoài cũng

có thổ là một hệ thống ngoài cần lấv thông tin từ hệ thống hiện thời

Biểu đồ Use-case là một công cụ cần thiết trong việc nắm bắt các yêu cầu, lên kế hoạch và kiểm soát dự án lặp lại

1.5.2.2.2 Biểu đồ trình tự (sequence diagram)

Biểu đồ trình tự chỉ ra sự hợp tác động giữa một số đối tượng Tầm quan trọng của biểu đồ này là chỉ ra trình tự các thông báo được gửi đi giữa các đôí tượng, chỉ ra lương tác giữa các đối lượng

1.5.2.2.3 Biểu đổ trạng thái (state diagram)

Biểu đồ trạng thái chỉ ra tất cả các trạng thái có thể có mà các đối tượng của lớp có thể nhận được và những biến cố nào gây nên việc thay đổi trạng thái Một biến cố có thê là một thông báo do đối lượng khác truyền đến hoặc là một điều kiện nào đó đã được hoàn thành Việc thay đổi trạng thái được gọi là một phép chuyển Một chuyển cũng có thể có một hành động được nối với nó để xác định ra cái gì cần được thực hiện sau Loại biểu đồ nàv không được vẽ cho tất cả các lớp mà chỉ vẽ cho những lớp có 1 số trạng thái đã được xác định rõ và hành vi của lớp ấy bị ảnh hưởng,

bị thay đổi bởi các trạng thái khác nhau

1.5.2.2.4 Biểu đó hoạt động (activity diagram)

Biểu đổ hoạt động chi’ ra luồng tuần tự các hoạt động, về cơ bản được dùng

để mô tả cho các hoạt động được thực hiện trong một thao tác nhưng nó cũng có thể

Á

dưực dùng để mô tả cho các luồng hoạt động khác như Use-case hay interact Biểu

đồ nàv bao gồm các trạng thái hành động, có chứa một đặc tả về hoạt động cần được thực hiện Một Irạng thái hành động sẽ từ bỏ trạng thái dó khi hành động được thực hiện xong Các quvết định và các điều kiện cũng như việc thực hiện song song các trạng thái hành động cũng có thể được biểu thị trong biểu đồ này Nó kết hợp các ý tưởng từ rriột vài kỹ thuật như biểu đồ sự kiện (event diagram) của Jim Odell, kỹ thuật mô hình trạng thái SDL, workflow modeling và mạng Petri Các biểu đồ này đặc biệt hữu dụng khi kết hợp với workflow và trong việc mô tả sự cư xử mà sự cư

xử đó có nhiều tiến trình song song Biểu đồ hành động là một biến thể của biểu đồ trạng thái trong trường hợp các trạng thái là các trạng thái hành động

1.5.2.2.5 Biểu đổ hợp tác (collaboration diagram)

Biểu đồ hợp tác chỉ ra sự hợp tác động, nó giống như biểu đồ trình tự nhưng Ihường là sự lựa chọn để biểu thị sự hợp tác hoặc như một biểu đồ tuần tự Nó là một cách khác đê thể hiện một tình huống có thể xảy ra trong hệ thống nhưng tập trung vào việc thê hiện việc trao đổi qua lại các thông báo giữa các đối tượng chứ không quan tâm đến thứ tự của các thông báo đó Qua biểu đổ này ta sẽ nhanh chóng biết được giữa 2 đối tượng cụ thê nào đó có trao đổi những thông báo gì cho nhau

Hình 1.4

1.5.3.1 Use-case view

Use-case view chỉ ra chức năng của hệ thống như được Actor ngoài cảm nhận thấy Nó không chỉ ra cách cấu trúc của hệ thống mà dùng là cơ sở đê' làm hợp lệnh kiểm chứng cuối cùng để xem hệ thống có đáp ứng được yêu cầu đề ra hay không Người dùng thông qua view này để kiểm tra xem các yêu cầu của mình có được đáp ứng đầy đủ không, có cần thay đổi gì trong các chức năng của hệ thống hay không? Thông thường view này được dành cho khách hàng, người thiết kế, lập trình và kiểm thử Biểu đồ dùng cho view này là biểu đổ Use Case

1.5.3.2 Logical view

Logical view mô tả cách mà chức năng của hệ thống được cung cấp Nó xác định cả tính bền vững và tính tương tranh cũng như các giao diện và cấu trúc bên trong lớp Ngược với Use-case view, logical view xem xét bên trong hệ thống Nó

mỏ tả cách thức, chức năng được thiết kế bên trong hệ thống dưới dạng cấu trúc tĩnh

(các lớp, các đối tượng và các mối quan hệ) và các sự hợp tác động xuất hiện khi các đối tượng gửi thông báo cho nhau để cung cấp các chức năng đã được đưa ra Cấu trúc tĩnh được mô tả trong các biểu đồ lớp và đối tượng Mô hình động được mô tả trong các biểu đồ trạng thái (state diagram), biểu dồ tuần tự (sequence diagram), hiểu đổ hợp tác (collaboration diagram), biêu đồ hoạt động (activity diagram) View này chủ vếu dùng cho người thiết kế và ngưưì phát triến.

1.5.3.3 Component view

Component view chi ra việc tổ chức các thành phần của chương trình Nó mô

lá các modul cài đặt và sự phụ thuộc lẫn nhau cho các modul đó, bao gồm biểu đồ thành phần (component diagram) View này chủ yếu dùng cho người phát triển Các thông tin thêm về sự quản trị như các báo cáo về sự tiến bộ của công việc cũng có thể được thêm vào

1.5.3.4 Concurrency view

Concurrency view chỉ ra tính chất tương tranh trong hệ thống đề cập đến các vấn đề liên quan đến truyền thông và đồng bộ hoá thường có ở trong các hệ thống tương tranh Nó chia các hệ thống tương tranh thành các tiến trình và các bộ xử lý, cho phép người ta sử dụng tài nguyên một cách hiệu quả, thực hiện song song và giải quyết các vấn đề không đổng bộ Giải quyết việc truyền thông và đồng bộ hoá giữa các mạch View này dành cho người phát triển và người thiết lập hệ thống View này bao gồm các biểu đổ động (dynamic diagram) như biểu đồ trạng thái (state diagram), biểu đồ trình tự (sequence diagram), biểu đồ hợp tác (collaboration diagram), biểu đồ hoạt động (activity diagram) và các biểu đổ thực thi (implementation diagram) như biểu đồ thành phần (component diagram) và biểu đồ triển khai (deployment diagram)

1,5.4 Các cơ chê chung của UML

Các cơ chế chung đưa ra các lời chú thích phụ, các thông tin, các ngữ nghĩa cho các phần tử mô hình, đưa ra các cơ chế mở rộng UML cho từng tổ chức, cho từng chương trình riêng

1.5.4.1 Chú thích

Dù cho mức độ bao quát của một ngôn ngữ có cao đến đâu thì cũng có những thứ chưa được định nghĩa trong ngôn ngữ đó Để có thể đưa thêm thông tin vào mô hình mà nếu không thì không thể thể hiện được hết mọi điều, ƯML cung cấp khả nâng chú thích Một chú thích có thể được đặt bất cứ chỗ nào trong biểu đồ và có thể chứa bất kỳ loại thông tin nào Loại thông tin mà nó chứa là một chuỗi không được thông dịch bởi UML Chú thích được gắn vào một vài phần tử trong biểu đổ vói đường không liền nét chỉ ra phần tử nào được giải thích thêm hay chi tiết hoá với thông tin trên chú thích Một chú thích thường chứa các dẫn giải hay các câu hỏi từ người làm mô hình như là một trình nhấc để giải quyết các tình trạng khó xử trong thời gian sau Một chú thích có thể có các khuôn mẫu (stereotype) mô tả kiểu chú thích Một chú thích biểu diễn một lời chú giải không có ảnh hướng về ngữ nghĩa, nghĩa là nội dung của nó không làm thay đổi nghĩa của mô hình mà nó gắn vào Điều này giải thích tại sao các chú thích thường được sử dụng để đặc tả các thứ như các yêu cầu, các nhận xét và các sự giải thích và các ràng buộc ([6])

Một chú thích có thể chứa bất kỳ sự phối hợp văn bản hay đồ thị nào Ta có thể đưa vào một URL, thậm chí liên kết hay nhúng vào một tài liệu khác Theo cách

ta bạn có thê dùng UML để tổ chức tất cả các artifact bạn sẽ sinh ra hay dùng trong khi phát triển

Một chú thích là một biểu tượng đồ hoạ để diễn tả các ràng buộc hoặc các lời chú giải gắn vào một hay một tập hợp các phần tử Bằng biểu đồ, một chú thích được biêu diễn như một hình chữ nhật với một nếp quân ở góc, cùng với chú giải bằng văn bản hoặc đồ hoạ

1.5.4.2 Trang trí

Các trang trí đưa thêm ngữ nghĩa cho các phần tử mô hình Các trang trí đồ hoạ có thể được gắn vào các phần tử mô hình trong các biẻu đổ Một ví dụ về trang trí là kv thuật chia thực thê thành các loại Khi một phần tử thể hiện một loại, tên nó được hiển thị với kiểu chữ đậm, nhưng khi cũng phần tử đó thể hiện một thực thể của loại đó Ihì tên nó được gạch dưới và có thể chỉ định cả tên của thực thế cũng như tên của loại Hình chữ nhật với tên chữ đậm thê hiện một lớp và tên gạch chân thê hiện một đối tượng Tương tự cho các nút, khi biểu tượng nút có thể là loại chữ đậm

như Printer hay một thực thể của loại nút như Huong’s HP LaserJet 4

1.5.4.3 Các cơ chê mở rộng

Người ta không thê đưa hết mọi khái niệm vào trong một ngôn ngữ vì như thế ngôn ngữ đó sẽ trở nên quá phức tạp, rối rắm Thay vì việc định nghĩa tất cả các phần tử, ƯML cung cấp một số phần tử cơ bản và các cơ chê để mở rộng các phần tử sao cho phù hợp với mục đích của người sử dụng và yêu cầu của từng hệ thống.UML đưa ra 3 cơ chế mở rộng đó là:

> Stereotype (khuôn mẫu): khuôn mẫu định nghĩa loại phần tử mô hình mới dựa trôn các phần tử mô hình đã có Vì thế, một khuôn mẫu giống như một phần tử mô hình đã tồn tại cộng thêm một số ngữ nghĩa mở rộng mà không được thê hiện trong các phần tử mô hình trước Một khuôn mẫu của một phần

tử mỏ hình có thể được sử dụng trong cùng một tình huống mà phần tử mô hình gốc được sử dụng Khuôn mẫu dựa trên toàn bộ các loại phần tử mô hình như lớp, các nút, các thành phần, các chú thích, các mối quan hệ như quan hệ association, quan hệ generalization và quan hệ dependency Một số khuôn mẫu đã được định nghĩa trước trong UML và chúng được sử dụng để sửa lại các phần tử mô hình đã có thay vì định nghĩa một cái mơí Điều này đảm bảo tính đơn giản của UML

Một khuôn mẫu được mô tả bằng cách đặt tên chúng như là 1 chuỗi gần tên của phần tử Các dấu ngoặc góc được gọi là các guillemet Một khuôn mẫu

có thể hiện đổ hoạ của riêng nó, chẳng hạn như một hình tượng nối tới nó

V-yLy

&Ị-> Tagged Value (giá trị the): mở rộng thuộc tính của các Ihành phần của UML,

làm việc hợp tác để tạo ra một sản phẩm, ta muốn chi ra các phiên bản và tác giả của một đối tượng nào đó Điều này không được xây dựng sẩn trong UML mà có thể thực hiện thông qua việc thêm vào một giá trị thẻ

> Contraints (ràng buộc): một ràng buộc là một sự hạn chế trên một phần tử để giới hạn cách sử dụng của phần tử hoặc ngữ nghĩa của phần tử đó

cH ƯƠ NG 2 PHẢN TÍCH, THIẾT KÊ HƯỚNG ĐÔÍ

TƯỢNG SỬ DỤNG UML

Trong chương I, luận vãn đã đề cập tới tầm quan trọng của việc lập mô hình

và tổng quan về UML, lịch sử phát triển và các thành phần cơ bản của UML Chương này ỉuận văn sẽ đề cập đến việc sử dụng UML khi phân tích, thiết kế hướng đối tượng

Cho đến nay, những người làm phần mềm vẫn quen với cách tiếp cận truyền thống, đó là cách tiếp cận chức năng Theo cách tiếp cận này ta chia hệ thống thành một bộ các chức năng có tương tác với trạng thái hệ thống dùng chungcho các chức năng đó Các chức năng này có thể có các thông tin trạng thái cục bộ nhưng chỉ dùng cho quá trình thực hiện chức năng đó Ngoài ra các chức năng này chia sẻ với nhau trạng thái hệ thống, trạng thái này tập trung và mọi chức năng đều có thể truy cập được Thiết kế hướng chức năng gắn các chi tiết của một thuật toán của chức năng đó nhưng các thông tin trạng thái hệ thống là không bị che dấu Điều này có thể gây ra vấn đề khi một chức năng thay đổi trạng thái theo cách mà các chức năng khác không ngờ tới Việc thay đổi một chức năng và cách nó sử dụng trạng thái của

hệ thống có thể gây ra những tương tác bất ngờ đối với các chức năng khác Do đó cách tiếp cận này tốt nhất trong trường hợp khối lượng thông tin trạng thái hệ thống

là nhỏ nhất và thông tin dùng chung nhau là rõ ràng

Hướng đối tượng là một cách tiếp cận khác với cách tiếp cận chức năng truyền Ihống Với cách tiếp cận hướng đối tượng, hệ thống được nhìn nhận như một

bộ các đối tượng Hệ thống được phân tán, mỗi đối tượng có những trạng thái riêng của nó Mỗi đối tượng là một bộ các “thuộc tính” xác định trạng thái của đối tượng

đó và các phép toán thực hiện trên các thuộc tính đó Các đối tượng liên lạc với nhau bàng cách trao đổi các thông báo

Một trong những thách thức đối với người làm phần mềm hiện nay là làm sao

để tạo ra được những hệ thống có khả năng thích nghi, giảm thiểu chi phí bảo hành, sửa chữa hệ thống và đặc biệt là tăng khả năng sử dụng lại của các thành phần trong

hệ thống

Khái niệm hướng đối lượng ra đời đã giúp ta có cơ hội để giải quyết những thách thức trên Do các đối tưựng là các thực thê độc lập, các thav đổi trong thực hiện một đối tượng hoặc thêm các dịch vụ sẽ không cần sự tham khảo cũng như không làm ảnh hưởng tới các đối tượng khác trong hệ thống nên hệ thống sẽ trở nên

dẻ hao trì hơn Cũng do tính độc lập của các đối tượng mà chúng tổ thành các thành phần có thê dùng lại được Các hệ thống khác có thể dùng lại các đối tượng đã được thiết kế trong hệ thống trước Và vì các đối tượng này đã được thử nghiệm trong hệ thống cũ nên rất ít khi xảv ra các rủi ro về lỗi

UML được xây dựng và phát triển bởi các chuvên gia hàng đầu trong lĩnh vực hướng đối tượng, những người đã đề xuất ra những phương pháp phân tích thiết kế hướng đối tượng được coi là điển hình nhất, như kỹ thuật phân tích Use case của Ivar Jacobsson, biểu đồ chuyến trạng thái của Harel do đó nếu vận dụng UML một cách hợp lý thì ta sẽ xây dựng được những hệ thống tốt

Thông thường việc phân tích và thiết kế hệ thống được thực hiện theo các bước sau:

> Phân tích yêu cầu: UML có các Ưse-case để thâu tóm yêu cầu của khách

hàng Thông qua mô hình ưse-case, các Actor được mô hình cùng với các chức năng mà nó đòi hỏi lừ hệ thống Các Actor và các Use-case được mô hình với các mối quan hệ và có sự kết hợp mang tính truyền thông với nhau hav được chia theo mô hình phân cấp Các Actor và các Use-case được mô tả trong Use-case diagram Mỗi Use-case được mô tả trong m ột văn bản và nó

đặc tả yêu cầu của khách hàng, những cái mà họ mong đợi ở hệ thống mà

khôns quan tâm đến việc các chức năng của hệ thống được thực hiện như thế nào Đây là một bước quan trọng quyết định sự thành công hay thất bại của

dự án Bởi vì hệ thống chỉ được coi là thành công nếu nó đáp ứng đúng và đầv đủ các yêu cầu của khách hàng

> Phân tích: Pha phân tích liên quan đến các sự trừu tượng chính như các lớp hay các đối tượng và các kỹ thuật thể hiện trong vùng chính (primary domain) Các lớp mà mô hình đã được xác định cùng với các mối quan hệ của chúng với nhau được mô tả trong class diagram Sự hợp tác giữa các lớp

được the hiện trong các Use-case cũng được mô tả thông qua bất kỳ mô hình động nào trong UML Trong pha phân tích chí có một số lớp được mô hình, các lớp kỹ thuật xác định các chi tiết và các giải pháp trong hệ thống phần mềm như các lớp cho giao diện người sử dụng, dữ liệu, truyền thông không được đề cập đến.

> Thiết kế: Trong pha này, kết quả của pha phân tích được mở rộng thành giải

pháp kỹ thuật Các lớp mới được thêm vào để cung cấp cơ sở hạ tầng kỹ thuật như giao diện người sử dụng, kiểm soát dữ liệu để chứa các đối tượng trong

dữ liệu, truyền thông với các hệ thống khác, Kết quả của pha thiết kế được đặc tả chi tiết trong pha xây dựng

Việc phân tích thiết kế hướng đối tượng được hệ thống hóa như sau:

1 Phân tích Use case

1.1 Tim Actor

1.2 Tim Use case

1.3 Xây dựng biểu đổ Use case

2.5 Xây dựng biểu đồ đối tượng

3 Phân tích sự tương tác giữa các đối tượng

3.1 Kịch bản

3.2 Xây dựng biểu đồ trình tự

3.3 Xây dựng biểu đồ hợp tác

4 Thêm vào các thuộc tính và các phương thức cho các lớp

5 Xác định ứng xử cuả đối tượng

5.1 Xây dựng biểu đổ trạng thái

5.2 Xây dựng biểu đổ hoạt động

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

6.1 Xây dựng biểu đồ thành phần

6.2 Xây dựng biểu đổ triển khai

2.1 Phân tích Use case

Những chức năng mà hệ thống cung cấp sẽ được mô tả trong mô hình Use case Trong đó mô tả những chức năng, những thành phần ở bên ngoài (Actor) tương tác với hệ thống và mối quan hệ giữa Use case và Actor (biểu đồ Use case) Một cách không hình thức, Use-case ỉà một câu chuvện hav một trường hợp mà người sử dụng dùng hệ thống để thực hiện các tiến trình Nói một cách chính xác hơn, Use-case mô tả trình tự các hành động của một loại người dùng nào đó, gọi là các Actor, sử dụng một phần chức năng của hệ thống để hoàn thành một tiến trình

Vì thế, đối với người sử dụng, Use case là một cách để họ sử dụng hệ thống Use case được mô tả bằng trình tự các tương tác giữa một số Actor và hệ thống thông qua dịch vụ mà hệ thống cung cấp cho các Actor Mỗi Use case chiếm một bộ phận các yêu cầu chức nãng cho một số người sử dụng Kết hợp tất cả các Use case lại với nhau ta có được mô tả vé toàn bộ các vêu cầu chức năng của hệ Ihống Tất cả các Use case cho phép những người phát triển phần mềm và khách hàng thoả thuận được

về các yêu cáu, các điểu kiện cũng như các khả năng mà hệ thống phaỉ tuân theo Ngoài ra nó còn chuyển đổi những yêu cầu về mặt nghiệp vụ của người đùng thành những yêu cầu cụ thể mà lập trình viên có thể hiểu một cách rõ ràng

2.1.1 Actor

2.1.1.1 Định nghĩa

Một Actor thể hiện một lập hợp chặt chẽ các vai trò mà các thực thể ngoài (đối với hệ thống) có thể thực hiện khi sử dụng hệ thống hơn là thể hiện một cá nhân riêng biệt Một Actor thể hiện một loại người dùng của hệ thống hoặc các hệ thống ngoài có tương tác với hệ thống đó Nói cách khác, một Actor là một ai đó hoặc một cái gì đó tương tác với hệ thống, nó là ai hay cái gì sử dụng hệ Ihống Một Aclor có

s Chỉ cung cấp thông tin cho hệ thống.

S Chỉ lấy thông tin từ hệ thống.

s Nhận thông tin từ hệ thống và cung cấp thông tin cho hệ thống

2.1.1.2 Một só đặc điểm của Actor

❖ Một Actor có tên và tên đó nên phản ánh vai trò của Actor Tên không nên phản ánh một thực thể đặc trưng của Actor và cũng không phản ánh chức năng của Actor

❖ Các Actor tương tác với hệ thống bằng cách gửi và nhận thông báo với hệ thống như nó thực hiện các Ưse-case

❖ Các Actor mô hình bất cứ cái gì cần thiết để tương tác với hệ thống để trao đổi thông tin: những người sử dụng, các hệ thống máy tính, các thiết

bị điện tử và cơ học

❖ Nếu có nhiều hơn một Actor trong một Use-case thì Actor kích thích được

gọi là Actor khởi đầu hay “Actor chủ động" và các Actor còn lại được gọi

là các Actor tham dự hay “Actor bị động".

❖ Các Actor tương tác trực tiếp với hệ thống được gọi là các Actor chính hay các Actor trực tiếp, các Actor còn lại đựơc gọi là các Actor thứ yếu

2.1.2 Xác định các Actor

Dựa vào việc nhận dạng các Actor, chúng ta lập ra các thực thể quan tâm đến việc sử dụng và tương tác với hệ thống Muốn thế, chúng ta phải xác định xem các Actor đòi hỏi gì ở hệ thống và các Actor cần những Use-case nào? Để xác định được các Actor, chúng ta phải trả lời 6 câu hỏi sau:

1 Ai sẽ sử dụng các chức năng chính của hệ thống Đó là các “Actor chính -

primary Actor".

2 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?

3 Ai cần bảo trì, quản lý và giữ cho hệ thống hoạt động Đó sẽ là các

“Secondary Actor".

4 Hệ thống cần những thiết bị phần cứng nào?

5 Hệ Ihống cần tương tác với các hệ thống nào? Có thể chia các hộ thốngthành hai loại: các hệ thống cần hệ thống của chúng ta và các hệ thống mà

hệ thống ta xây dựng sẽ cần tới Các hệ thống bao gồm các hệ thống máy tính khác cũng như các ứng dụng khác trên máy tính m à hệ thống sẽ thực hiện

6 Ai hay cái gì quan tâm đến các kết quả mà hệ thống tạo ra

Khi mô tả một Actor ta cần chỉ rõ vai trò của Actor khi tương tác với hệthông Chẳng hạn đối với hệ thống bán hàng ta có một Actor là khách hàng, ta cóthể mô tả Actor này một cách ngắn gọn như sau:

Khách hàng: là những người đến mua hàng tại cửa hàng

2 Một dòng hoàn thiện các sự kiện, được khởi tạo bởi một Actor

3 Một sự tương tác logic giữa Actor và hệ thống

Một Ưse-case chí ra trình tự các hoạt động mà hệ thống có thể thực hiện và diều đó mang lại kết quả là các gía trị có thể nhìn thấy được đôí với một Actor đặc biệt Một Use-case là một câu chuyện end-to-end về việc sử dụng hệ thống để làm nhiệm vụ nào đó chứ không phải là sự kết hợp một số bước trong thao tác điện toán

(xcm [7J> Ví dụ, chúng ta không nên kết hợp hai nhiệm vụ vào một ưse-case, chẳng hạn nhu' mượn và trả sách nếu như hai nhiệm vụ đó không xảy ra kế tiếp nhau.

Trong UML, các Use case là cách mà chúng ta thu thập các vêu cầu của người sử dụng

2.1.3.2 Các đặc điểm của Use-case

1 Một Use-case luôn dược khởi tạo hằng một Actor Một Use-case luôn được

thực hiện nhân danh Actor Một Actor phải ra lệnh cho hệ thống thực hiện Use-case một cách trực tiếp hoặc gián tiếp

2 Use-case cung cấp giá trị cho Actor Một Use-case phải trả lại kiểu gia trị

xác thực nào đó cho người sử dụng Giá trị đó không nhất thiết phải là gía trị quan trọng nhất nhưng chắc chắn phải là gía trị có thể ihấy được

3 Mộ! Use case là hoàn thiện Một Ưse-case phải là một mô tả hoàn thiện Một

Use-case là chưa hoàn thiện cho đến khi giá trị cuối cùng được tạo ra

4 Một Use case luôn luôn kết nối tới ít nhất một Actor.

5 Một Ưse-case lù một lớp chứ không phải lá một thực thể Nó mô tả chức năng

một cách tổng thể, bao gồm các sự lựa chọn, các lỗi, các ngoại lệ có thể xảy

ra khi Ưse-case đó được thực hiện

2.1.3.3 Nhận dạng các Use case

Có hai phương pháp để nhận dạng Usc-case là:

1 Dựa trên Actor {Actor-based).

s Nhận dạng các Actor tham chiếu đến 1 hệ thống hay 1 tổ chức VD tìm và

xác định các Actor bằng cách xem xem User nào sẽ sử dụng hệ thống và các hệ thống nào tương tác với hệ thống đó

s Đối với mỗi Actor, xác định các tiến trình mà Actor đó khởi xướng hoặc

tham gia bằng cách tìm xem Actor đó liên lạc hoặc sử dụng hệ thống như thế nào để làm công việc của mình

2 Dựa trên các sự kiện (Even!-based).

s Xác định các sự kiện bên ngoài mà hệ thống phải đáp ứng.

^ Liên kết các sự kiện với các Aclor và các Use-case.

Để xác định các Use-case, ta phải xem các yêu cẩu của các Actor và tiếp tục hàn hạc với những người sẽ hành động như các Actor Nó sẽ giúp la giải đáp một số câu hỏi như:

1 Actor đòi hỏi những chức nãng gì từ hệ thống? Actor cần làm gì?

2 Có phải một Actor cần đọc ghi, thay đổi, huỷ bỏ hay lưu trừ một sô' loại thông tin trong hệ thống hay không?

3 Actor có phải báo cho hệ thống biết về những sự thay đổi bên ngoài hay không?

4 Actor có được thông báo về những sự thay đổi hav không?

5 Có phải những công việc hàng ngày của Actor sẽ trở nên đơn giản và hiệu quả hơn nhờ những chức năng mới của hệ thống hay không?

Ngoài ra còn một số câu hỏi khác không liên quan đến các Actor hiện thời là:

1 Hệ thống cần những dữ liệu vào ra nào? Dữ liệu vào từ đâu và sẽ đưa ra đâu?

2 Vấn đề chính với sự thực thi hiện thời của hệ thống là gì?

Các nguyên tắc nhận ra các Ưse-case

1 Một Use-case được thấy rõ trong sự hợp tác Một sự hợp tác chỉ ra một

giải pháp thực thi-độc lập nội tại của một Use-case dưới dạng các lớp, các đối tượng và các mối quan hệ giữa chúng (còn được gọi là ngữ cảnh của

sự hợp tác) và sự ảnh hưởng lẫn nhau của chúng để đạt được chức năng đã yêu cầu (còn gọi là sự ảnh hưởng lẫn nhau trong sự hợp tác) Biểu tượng cho sự hợp tác là một hình elip không liền nét (ellipsis) chứa tên của sự hợp tác

2 Sự h(/p tác được th ể hiện trong UML như một sô'các biểu đồ chỉ ra cá ngữ

cảnh và sự tương tác giũa các thành phần tham gia vào sự hợp tác Tham

gia vào sự hợp tác là các lớp (và các thực thể hợp tác là các đối tượng) Có các loại biểu đồ là biểu đồ hợp tác (collaboration diagram), biểu đồ trình

tự (sequence diagram) và biểu đồ hoạt động (activity diagram) Các loại biểu đồ được sử dụng để đưa ra một bức tranh hoàn chỉnh về sự hợp tác phụ thuộc vào trường hợp thực tế Trong một vài trường hợp, chỉ cần một

biểu đồ hợp tác là đủ, nhưng trong một số trường hợp thì cần thiết phải phối hợp một số biểu đổ khác nhau.

3 Một kịch bản là một ví dụ của một Use-case hay một sự hợp lác Nói một

cách khác kịch bản là một thuyết minh bằng ví dụ cụ thể cúa một Use case và nó thể hiện một cách sử dụng thực tế của hệ thống

2.1.3.4 Mô tả các Use-case

Khi chúng ta sử dụng các phương pháp nêu trên đế nhận dạng các Ưse-case, đầu tiên chúng ta phải tạo ra một Use-case ở mức cao đế có một vài hiểu biết về toàn

bộ tiến trình, sau đó mở rộng nó bằng cách đưa thêm các chi tiết

Một Use-case ờ mức cao (high-level Use-case) mô tả một tiến trình một cách

ngắn gọn thường trong khoảng 2 hoặc 3 câu Chúng thường chỉ liên quan đến các hành động mà các Actor thực hiện Nó được mô tả theo khuôn dạng như sau:

Use case Tên của Use case (dùng một cụm từ bắt đầu bằng một động từ)

Các Actor Danh sách các Actor (các Actor ngoài), chỉ ra ai là người khởi tạo

Use-caseMục đích Mục đích của Use-case

Khái quát Mô tả ngắn gọn về tiến trình

Các tham Liên quan đến các Ưse-case và các chức năng của hệ thống

chiêu

Ví dụ, Use case ở mức cao cho việc QLHĐBĐTD (Quản lý hợp đồng bảo đảm tín dụng) có thể được mô tả như sau:

QLHĐBĐTD (Quản lý hợp đồng bảo đảm tín dụng)CBTD

Lưu trữ và sửa đổi các hợp đồng bảo đảm tín dụng Sau khi các hồ sơ đã được chấp nhận, CBTD lập hựp đồng bảo đảm tín dụng, tìm kiếm và sửa chữa chúng khi cần thiết Các chức năng R4.1, R4.2, R4.3, R4.4, R4.5, R4.6

Các tham chiếu đến các chức nãng của hệ thống chỉ ra rằng:

1 - Use case dược tạo dựa trên sự hiểu biết các chức năng này

2 Các tham chiếu đòi hỏi các chức năng được chỉ định đến Use-case

ư u điểm của việc này là:

1 Có khả năng xác nhận rằng toàn bộ các chức năng củe hộ thống đã được phân phối cho các Use-case

2 Cung cấp một liên kết dễ sử dụng giữa các sản phẩm được tạo ra ở các giai đoạn khác nhau trong quá trình phát triển

3 Tất cả các chức nãng của hệ thống và các Use-case có thể theo dõi trong quá trình thực thi và kiểm thử

Một Use-case mở rộng (expanded Use-case) chỉ ra chi tiết hơn một Use-case

ở mức cao, và thường được làm theo kiểu đàm thoại giữa các Actor và hệ thống Đặc biệt một Use-case mở rộng mờ rộng một Use-case ở mức cao theo hai đoạn: dòng (course) đặc biệt các sự kiện và dòng xen kẽ (alternative) các ngoại lệ

Use-case Tên của Use-case (dùng một cụm từ bắt đầu bằng một động từ)Các Actor Danh sách các Actor (các Actor ngoài), chỉ ra ai là người khởi tạo

Use-caseMục đích Mục đích của Use-case

Khái quát Mô tả ngắn gọn vẻ tiến trình

Các tham Liên quan đến các Use-case và các chức năng của hệ thống

chiếu

Dòng đặc biệt của các sự kiện (Typical course of events)

Các hành động được đánh thứ tự của các Các mô tả được đánh thứ tự của các phản

Actor hồi của hệ thốngCác dòng xen kẽ (Alternative courses)

Các sự xen kẽ có thể xuất hiện ở số dòng Nó là sự mô tả một ngoại lệ

Ví dụ Use case mờ rộng của Use case ở mức cao “Quản lý hợp đồng bảo đàm tín dụng” có thể được mô tả như sau:

Dòng đặc biệt của các sự kiện (Typical course of events)

Hành động của Actor Phản hồi của hệ thống

1 Use case nàv được bắt đầu khi các hồ

sư của khách hàng đã được thẩm định và

Các dòng xen kẽ (Alternative courses)

Dòng 2: Mã khách hàng mà cán bộ tín dụng nhập vào bị sai Trường hợp này

hệ thống sẽ đưa ra thông báo và hiên thị danh sách các khách hàng đế cán bộ tín dụng lựa chọn

Dòng 6: Có lỗi, hệ thống không thể ghi lại hợp đồng này

2.1.3.5 Kí hiệu

Một Use case được thổ hiện bởi một hình ellip kèm theo tên của Use case Ngoài ra còn có ihể có thêm các chú thích để mô tả chi tiết hơn về ý nghĩa của Use case Mỗi Use case trong hệ thống có tên phân biệt duy nhất Use case có thể được đánh số để thuận tiện cho việc tra cứu nhanh trên biểu đồ hoặc trong tài liệu mô tả

Ví dụ:

P a y by C ash

2.1.4 Các mỏi quan hệ

2.1.4.1 Quan hệ giữa Use case và Actor:

Quan hệ giữa Use case và Actor thường gọi là quan hệ tương tác vì nó thể hiện sự tương tác giữa một actor và một Use case Thông thường đây là quan hệ 1

I không có hướng để chỉ ra ràng Actor có thê liên lạc với Use case theo cả hai hướng Quan hệ này thê hiện bởi một đường thẳng nối giữa actor và Use case

2.1.4.2 Quan hệ giữa Use case với Use case:

Các Use case quan hệ với nhau theo ba kiểu quan hệ là: Uses, extends và

generalization.

1 Quan hệ Extends: là một quan hệ tổng quát hoá trong đó một Use-case mở

rộng một Use-case khác bằng cách đưa thêm các hành động vào Use-case tổng quát Use-case mở rộng có thề bao gồm cư xử từ Use-case được mở rộng, phụ thuộc vào các điều kiện mở rộng Nó không cần phải bao gồm toàn bộ cư xử, nó có thể chọn một phần cư xử của Use-case tổng quát mà nó muốn dùng lại Use-case đang được mở rộng phải là Ưse-case hoàn thiện Vì thông thường các Ưse-case được mô tả dưới dạng văn bản nên việc xác định phần nào trong Use-case mở rộng là được sử dụng lại từ Ưse-case tổng quát, phần nào là được định nghĩa lại, phần nào là được thêm vào Một Use-case

mở rộng có thể kiểm soát các ngoại lộ là các trường hợp đặc biệt của Use- case tổng quát Quan hệ mở rộng giữa hai Ưse-case được biểu diễn bằng đường nối giữa hai Ưse-case với hình tam giác rỗng hướng vào Use-case

được mở rộng và stereotype “extends” ở bên cạnh.

2 Quan hệ Uses: ỉà một quan hệ tổng quát hoá mà Use-case sử dụng một Ưse-

case khác Khi một sổ' các ưse-case có cư xử chung thì cư xử chung này có thê được mô hình trong một Use-case đơn và được các Use-case khác sử dụng Khi một Use-case sử dụng một Use-case khác, toàn bộ Use-case phải được sử dụng (mặc dù các hành động trong Use-case được sử dụng không cần cùng trình tự, chúng có thể trộn lẫn với các hành động của Ưse-case sử dụng) Nếu ưse-case dược sử dụng không bao giờ sứ dụng chính nó thì nó

được gọi là Use case trừu tượng - abstract Use case Quan hệ sử dụng giữa

hai Use-case được biểu diễn bằng đường nối giữa 2 Ưse-case với hình tam

giác rỗng hướng vào Use-case được sử dụng và sterreotypc “Uses” ở bên

cạnh

3 Quan hệ Generalization: Khi một số các Use-case kiếm soát các chức năng

tương tự nhau có liên hệ với nhau theo một cách nào đó, chúng có thể được gói lại thành một package trong UML Các nhóm package liên hệ với các phần tử mô hình, có thể được mở rộng hoặc thu bớt lại thành một biểu tượng, cho phép người phát triển nhìn một package tại một thời điểm Package khống mang ý nghĩa nào khác, nó chỉ là một tập hợp các Use case có các chức năng tương tự hoặc có liên hệ với nhau

2.1.5 Biêu đồ Use case

1 Một biểu đồ thể hiện tất cả các Use case liên quan đến một Actor nào đó

2 Một biểu đổ thể hiện tất cả các Use case được cài đặt trong một giai đoạn phát triển

3 Một biểu đồ thể hiện một Use case và tất cả các mối quan hệ của nó

Tuy nhiên nên hạn chế số lượng các biểu đồ nhưng vẫn phải đảm bảo đủ các thông tin cần thiết Bởi vì nếu quá nhiều biểu đồ sẽ gâv ra sự lộn xộn và có thể dẫn đến nhầm lẫn do đó mất đi lợi ích của việc đơn giản hóa Tập hợp các biếu đồ Use

case giúp cho khách hàng dễ dàng xem xét ở mức tổng quát hộ thống mà ta sẽ xây

dựng

2.1.5.3 Kí hiêu

Một biểu đồ Use case bao gồm một tập các Use case và các Actor Giữa Use ease và Actor có một đường nối nếu như actor khởi đầu Use case

Biếu dồ Use case có thể lồng nhau, có nghĩa là một Use case trong một biểu

đổ Use case có thể được phân nhó ra thành những Use case khác, nằm trong một biếu đồ Use case khác

Hệ thống tín dụng

Hình 1 -1 ià biểu đổ Use case “Quản lý hồ sơ” ở mức tổng quát Quản lý hổ

sơ bao gồm việc quản lý hồ sơ pháp lý cá thể, hổ sơ pháp lý doanh nghiệp, hổ sơ kinh tế doanh nghiệp và hồ sơ dự án đầu tư Hình 1-2 chi tiết hóa Use case “Quản lý

hồ sơ pháp lv cá thể” bằng cách chỉ ra các Use case mà Actor CBTD mong muốn ở

Hình 2.1 Use case “Quản lý hồ sơ” ở mức tổng quát của hệ thống tín dụng

A

/ \CBTD

Hình 2,2 Chi tiết hoá cho Use case “Quản lý hồ sơ pháp lý cá thể”

Nhìn vào các biểu đồ trên ta dễ dàng thấy được các chức năng mà hệ thống

có thể cung cấp cũng như các Actor sẽ tương tác với hệ thống Qua đó, khách hàng

có thể thẩm định được rằng hệ thống đã đáp ứng đúng và đủ các yêu cầu của mình hav chưa? Nếu không, họ có thể yêu cầu thêm các chức năng còn thiếu Chẳng hạn:

“Tỏi muốn in các hồ sơ” Như vậy những người phát triển hệ thống và khách hàng

có thể dễ dàng thoả thuận với nhau mà khách hàng không cần mất nhiều thời gian

để đọc tài liệu

Vì thế các đối tượng liên quan đến hiểu biết của chúng ta về thế giới thực.

22.2.2 Tìm lớp

Lớp là khái niệm quan trọng nhất trong hướng đối tượng Một hệ thống tốt phái dựa trên phân lớp tốt Tìm lớp là một cống việc không đơn giản, đòi hỏi phải cố gắng sáng tạo Có một sô gợi ý cho việc tìm lớp như sau:

s Thôns tin nào cần được lưu giữ hoặc phân tích? Nếu có bất kỳ thông tin nào

cần được lưu trữ, phân tích, chuyển đổi hay kiểm soát theo một cách nào đó

thì đó có thể là một lớp Các thông tin đó có thể là các khái niệm phải luồn được đăng ký trong hệ thống hav các sự kiện hoặc các giao dịch xảy ra tại một thời điếm cụ thể

s Các hệ thống ngoài cũng có thể xem như các lớp mà hệ thống của ta chứa

hoặc tương tác

s Các hình mẫu, các lớp hoặc các thành phần đã được xây dựng từ những dự án

trước cũng thường chứa các lớp

s Hệ thống cần kiểm soát những thiết bị nào?

s Việc thể hiện một tổ chức cũng được làm với các lớp, đặc biệt là các mô hình

nghiệp vụ

s Các Actor thực hiện vai trò gì khi thực thi các vấn đề nghiệp vụ? Các vai trò

đó cũng có thể xem như các lớp, chẳng hạn như người sử dụng, khách hàng

Ngoài ra bán đặc tả các yêu cầu, phân tích nghiệp vụ cũng có thể xem như cơ

sớ cho việc tìm lớp

Kỹ thuật thẻ C R C : là một kỹ thuật để phát hiện và làm tài liệu cho các lớp.

CRC = Lớp - Trách nhiệm -C ộng tác viên (Class-Responsibiỉitv-Collaborator)

Đối với mỗi lớp tiềm năng (potential class) ta tạo ra thẻ gồm 2 cột Cột “Trách

nhiệm" liệt kê các Irách nhiệm như các nhóm động từ Cột “Cộng tác viên” liệt kê

các lớp cần thiết để thực hiện nhiệm vụ đó

2.2.2.3 Các thành phần của lớp

Một lớp có ba thành phần như sau: tên lớp, các thuộc tính, các phương thức (ứng xử) của lớp

1 Tên lớp thường là danh từ, ví dụ : Invoice hay Debit

2 Các thuộc tính dùng để mô tả các đặc điểm của các đối tượng Các thuộc tính được coi là đúng nếu nó bao gồm các thông tin để mô tả và nhận dạng một thực thể cụ thể của một lớp Tuv nhiên chỉ nên đưa vào các thuộc tính mà hệ thốne quan tâm Mỏi thuộc tính đều thuộc một kiêu dữ liệu nào đó Kiểu nguyên thuỷ bao gồm các kiểu như Integer, Boolean, real, point, area và enurneric Ngoài ra các thuộc tính còn có khả năng

nhìn thấv được (visibility) bao gổm public, private và protected, Nếu một thuộc tính là public nghĩa ià một lớp khác có thê tham chiếu đến và sử dụng thuộc tính đó Nếu là private thì các lớp khác không thể tham chiếu

đến thuộc tính này

3 Các phương thức (ứng xử) của lớp: Các phương thức trong một lớp mô tả cái mà lớp đó có thể làm Các phương thức thường được gọi là các hàm (function) nhưng chúng chỉ thuộc vào lớp đó và áp dụng đối với các đối tượng của lớp đó Cũng giống như các thuộc tính, các phương thức cũng

có phạm vi và khả năng nhìn thấy được

2.2.2A Ký hiệu

Trong UML lớp được ký hiệu bằng một hình chữ nhật gồm 3 phần Phần thứ nhất chứa tên lớp, phần thứ hai chứa các thuộc tính và phần thứ ba chứa các phương thức

Ví dụ: lớp Người sẽ được thê hiện như sau:

Thông thường người ta chia lớp làm ba loại như sau: lớp thực thể ( Entity Class), lớp biên( Boundary Class) và lớp Điều khiển ( Control Class)

2.2.2.5.1 Lớp thực thể

Lớp thực thể dùng đê mỏ hình hóa các đối tượng nghiệp vụ như Invoice, insurance contract, Đây là các đối tượng được lưu trữ lâu dài trong hệ thống Nó tồn tại độc lập với các đối tượng khác

Các danh từ, cụm danh từ mó tá về các trách nhiệm (responsibility) trong các Use case là khởi đầu để phát hiện lớp thực thể Bắt đầu từ danh sách các danh từ ta