Bài Giảng Phân Tích Thiết Kế Hệ Thống Điện Tử

1 MỤC LỤC CHƯƠNG 1 5 TỔNG QUAN VỀ HỆ THỐNG 5 1 1 Định nghĩa hệ thống 5 1 1 1 Hệ thống 5 1 1 2 Môi trường của hệ thống 5 1 2 Hệ thống kinh doanh 5 1 3 Hệ thống thông tin 6 1 3 1 Định nghĩa hệ thống thô[.]

M ỤC LỤC

CH ƯƠNG 1 5

T ỔNG QUAN VỀ HỆ THỐNG 5

1.1 Định nghĩa hệ thống 5

1.1.1 Hệ thống 5

1.1.2 Môi trường của hệ thống 5

1.2 Hệ thống kinh doanh 5

1.3 Hệ thống thông tin 6

1.3.1 Định nghĩa hệ thống thông tin 6

1.3.2 Phân loại hệ thống thông tin 6

1.4 Quy trình phát triển hệ thống thông tin 7

1.5 Cách tiếp cận hướng cấu trúc và tiếp cận hướng đối tượng 11

1.5.1 Phương pháp hướng cấu trúc 11

1.5.2 Phương pháp hướng đối tượng 12

CH ƯƠNG 2 14

MÔ HÌNH HÓA H ƯỚNG ĐỐI TƯỢNG 14

2.1 Đại cương về mô hình hóa 14

2.1.1 Khái niệm mô hình 14

2.1.2 Phương pháp mô hình hóa 14

2.2 Ngôn ngữ mô hình hóa UML 14

2.2.1 Lịch sử của UML 14

2.2.2 UML Ngôn ngữ mô hình hóa đối tượng 15

2.2.3 Các góc nhìn của UML 16

2.2.4 Giới thiệu các biểu đồ của UML 17

2.3 Tiến trình RUP (Rational Unified Process) 19

2.3.1 Các nguyên tắc cơ bản của RUP 19

2.3.2 Các pha và công đoạn của RUP 20

2.3.3 Một tiến trình đơn giản 20

CH ƯƠNG 3 24

PHÂN TÍCH CH ỨC NĂNG 24

3.1 Mô hình hóa nghiệp vụ với biểu đồ hoạt động 24

3.1.1 Mục đích 24

3.1.2 Biểu đồ hoạt động 24

3.2 Mô hình hóa với biểu đồ ca sử dụng (USE CASE) 27

3.2.1 Giới thiệu 27

3.2.2 Tác nhân (Actor) 27

3.2.3 USECASE (Ca sử dụng) 30

3.2.4 Xác định mối quan hệ 33

3.2.5 Đặc tả UseCase 35

3.2.4 Xây dựng biểu đồ useCase 41

3.2.5 Phân rã Usecase 42

3.2.6 Phân chia UseCase vào các gói 44

CH ƯƠNG 4 46

PHÂN TÍCH C ẤU TRÚC VỚI BIỂU ĐỒ LỚP 46

4.1 Các khái niệm trong biểu đồ lớp 46

4.1.1 Đối tượng 46

4.1.2 Lớp 46

4.1.3 Xác định thuộc tính và thao tác của đối tượng 46

4.1.4 Xác định mối quan hệ giữa các lớp 48

4.2 Lập biểu đồ lớp và biểu đồ đối tượng 57

4.2.1 Phát hiện các lớp lĩnh vực 58

4.2.2 Phát hiện các lớp tham gia ca sử dụng 61

4.3 Lập biểu đồ lớp cho ca sử dụng 62

CH ƯƠNG 5 66

PHÂN TÍCH HÀNH VI 66

5.1 Giới thiệu về mô hình hóa hành vi 66

5.2 Mô hình hóa sự tương tác 67

5.2.1 Mô hình hóa sự tương tác với biểu đồ trình tự (Sequence Diagram) 72 5.2.2 Mô hình hóa với biểu đồ giao tiếp (Collaboration Diagram) 75

5.2.3 Đối chiếu và chỉnh sửa các mô hình 78

5.3 Biểu đồ trạng thái (Statechart Diagram) 80

5.3.1 Ý nghĩa của biểu đồ trạng thái 80

5.3.2 Các chuyển tiếp (transition) 83

5.3.3 Xây dựng biểu đồ trạng thái 83

5.3.4 Đối chiếu giữa các mô hình 85

CH ƯƠNG 6 89

THI ẾT KẾ HỆ THỐNG 89

6.1 Mục đích của giai đoạn thiết kế 89

6.2 Quá trình thiết kế 89

6.2.1 Thiết kế các lớp 90

6.2.2 Thiết kế các liên kết 92

6.2.3 Thiết kế các thuộc tính 94

6.2.4 Thiết kế các thao tác 96

6.3 Thiết kế chi tiết các tầng 96

6.3.1 Thiết kế tầng trình bày 96

6.3.2 Thiết kế tầng ứng dụng 97

6.3.3 Thiết kế tầng nghiệp vụ 100

6.3.4 Thiết kế việc lưu trữ các dữ liệu 100

6.4 Mô hình hóa cài đặt hệ thống 105 6.4.1 Xây dựng biểu đồ thành phần 105 6.4.2 Xây dựng biểu đồ triển khai 107

CH ƯƠNG 1

1.1 Định nghĩa hệ thống

1.1.1 H ệ thống

Đ

ị

ràng buộc lẫn nhau và cùng hoạt động hướng tới một mục đích chung (ví dụ một cỗ máy là một hệ thống các chi tiết liên kết với nhau thực hiện chức năng của cỗ máy )

1.1.2 Môi tr ường của hệ thống

Môi trường của hệ thống là tập hợp các phần tử không thuộc về hệ thống nhưng trao đổi thông tin với hệ thống Việc xác định môi trường (hay còn gọi là khoanh vùng hệ thống) dựa trên mục tiêu cơ bản trên toàn hệ thống

1.2 H ệ thống kinh doanh

Là khái niệm chung dùng cho các tổ chức kinh tế như nhà máy, xí nghiệp, công ty, tổ chức dịch vụ có mục đích phục vụ cho kinh doanh (business) Kinh doanh có thể vì l

ợ

ặ

ợ

ậ

Ví dụ: - Các công ty, nhà máy, dịch vụ là các hệ thống kinh doanh vì lợi nhuận

- Các trường học, các công trình công cộng, bệnh viện, là các hệ thống kinh doanh vì lợi ích

Các thành ph ần của hệ thống kinh doanh

• Hệ quyết định: Hệ quyết định gồm con người, phương tiện, phương pháp

để đề xuất các quyết định, các chiến lược kinh doanh, nó có liên quan đến mọi hoạt động của toàn hệ thống Quá trình ra một quyết định trải qua hai bước:

-Tìm hiểu tình hình -Lựa chọn giải pháp

Hình 1 môi trường và hệ thống

Môi trường

Hệ thống

Tuỳ theo tầm quan trọng, phạm vi ảnh hưởng ta chia làm 2 loại quyết định:

- Quyết định chiến lược: Là quyết định cho một kế hoạch tổng thể lâu dài, có tính chất định hướng

- Quyết định chiến thuật: Quyết định này có tính chất cục bộ có phạm vi hẹp trong thời gian ngắn để hỗ trợ cho quyết định chiến lược

• Hệ tác nghiệp: Hệ tác nghiệp bao gồm con người, phương tiện… trực tiếp

thực hiện các nhiệm vụ của hệ thống kinh doanh để đạt mục tiêu đã xác định

• Hệ thống thông tin: Bao gồm con người, phương tiện và phương pháp tham

gia vào quá trình thu thập, lưu trữ, xử lý thông tin đảm báo mỗi quan hệ giữa

hệ quyết định và hệ tác nghiệp

1.3 H ệ thống thông tin

1.3.1 Định nghĩa hệ thống thông tin

H ệ thống thông tin (Information System - IS) trong một tổ chức có chức năng

thu nhận và quản lý dữ liệu để cung cấp những thông tin hữu ích nhằm hỗ trợ cho tổ chức đó và các nhân viên, khách hàng, nhà cung cấp hay đối tác của nó Ngày nay, nhiều tổ chức xem các hệ thống thông tin là yếu tố thiết yếu giúp họ

có đủ năng lực cạnh tranh và đạt được những bước tiến lớn trong hoạt động Hầu hết các tổ chức nhận thấy rằng tất cả nhân viên đều cần phải tham gia vào quá trình phát triển các hệ thống thông tin

- Hệ thống thông tin là một hệ thống bao gồm con người, dữ liệu, các quy trình

và công nghệ thông tin tương tác với nhau để thu thập, xử lý, lưu trữ và cung cấp thông tin cần thiết ở đầu ra nhằm hỗ trợ cho một hệ thống

- Hệ thống thông tin hiện hữu dưới mọi hình dạng và quy mô

1.3.2 Phân lo ại hệ thống thông tin

Các hệ thống thông tin có thể được phân loại theo các chức năng chúng phục

vụ

- H ệ thống xử lý giao dịch (Transaction processing system - TPS) là một hệ

thống thông tin có chức năng thu thập và xử lý dữ liệu về các giao dịch nghiệp

vụ

- H ệ thống thông tin quản lý (Management information system - MIS) là một

hệ thống thông tin cung cấp thông tin cho việc báo cáo hướng quản lý dựa trên việc xử lý giao dịch và các hoạt động của tổ chức

- Hệ thống hỗ trợ quyết định (Decision support system - DSS) là một hệ

thống thông tin vừa có thể trợ giúp xác định các thời cơ ra quyết định, vừa có thể cung cấp thông tin để trợ giúp việc ra quyết định

- Hệ thống thông tin điều hành (Excutive information system - EIS) là một hệ

thống thông tin hỗ trợ nhu cầu lập kế hoạch và đánh giá của các nhà quản lý điều hành

- Hệ thống chuyên gia (Expert System) là hệ thống thông tin thu thập tri thức

chuyên môn của các chuyên gia rồi mô phỏng tri thức đó nhằm đem lại lợi ích cho người sử dụng bình thường

- Hệ thống truyền thông và cộng tác (Communication and collaboration

system) là một hệ thống thông tin làm tăng hiệu quả giao tiếp giữa các nhân viên, đối tác, khách hàng và nhà cung cấp để củng cố khả năng cộng tác giữa

họ

- Hệ thống tự động văn phòng (Office automation system) là một hệ thống

thông tin hỗ trợ các hoạt động nghiệp vụ văn phòng nhằm cải thiện luồng công việc giữa các nhân viên

1.4 Quy trình phát tri ển hệ thống thông tin

Có nhiều loại chu trình phát triển phần mềm khác nhau:

(i) Mô hình thác nước (Waterfall): Đây là chu trình phát triển đầu tiên, được Royce đề xuất năm 1970 để mô tả sự phát triển hệ thống tin học Quá trình phần mềm được chia thành dãy các giai đoạn (các pha) liên tiếp từ phân tích yêu cầu, phân tích các thành phần, thiết kế, lập trình đến thử nghiệm và triển khai hệ thống Giai đoạn sau chỉ được bắt đầu khi giai đoạn trước đã hoàn thành (không được chờm lên nhau) Vì vậy chu trình phát triển này còn được gọi là chu trình tuyến tính

Mô hình này được thiết lập theo cách tiếp cận hướng chức năng và phù hợp cho những dự án lớn, phức tạp Nhược điểm chính của chu trình phát triển thác nước là ở chỗ không có sự quay lui Sự quay lui là một nhu cầu rất tự nhiên trong quá trình phát triển phần mềm, vì nhiều khi thực hiện ở giai sau người ta mới phát hiện ra những thiếu sót của giai đoạn trước và do vậy cần phải quay lại giai đoạn đó để chỉnh sửa, bổ sung cho đầy đủ Ngoài ra, trong quá trình phát triển phần mềm theo chu trình thác nước, không có sự tham gia trực tiếp của người dùng trong mỗi giai đoạn, mà chỉ tiếp xúc với hệ thống sau khi nó đã được hoàn thành

Chính vì vậy mà đã cĩ nhiều phương pháp cải tiến chu trình thác nước, cho

phép sự quay lui Chẳng hạn chu trình phát triển hình chữ V [35], được AFCIQ

(Association Française pour le Contrơle Industriel de la Qualité) đề nghị bao

gồm cả các bước quay lui, và ngồi ra cịn đặt tương ứng các pha kiểm thử, tích

hợp trong giai đoạn phân tích và thiết kế Khi một sai sĩt được phát hiện thì giai

đoạn đĩ được xem lại và chu trình bắt đầu lại từ đĩ

(ii) Chu trình tăng trưởng: Chu trình tăng trưởng, do D R Graham đề xuất năm

1989, dựa trên các bước tăng trưởng dần, cho phép hồn thành hệ thống từng

phần một Mỗi bước tăng trưởng thực hiện một tiến trình tuyến tính gồm các

bước phân tích, thiết kế, lập trình, kiểm định và chuyển giao từng phần Quá

trình này lặp lại nhiều lần cho đến khi cĩ được phương án hồn chỉnh cho cả hệ

thống

Rõ ràng cách làm này chỉ thích hợp với các hệ thống cĩ thể chia cắt và chuyển

giao theo từng phần

(iii) Chu trình xoắn ốc Chu trình xoắn ốc hay chu trình lặp được Boëhm đề

xuất năm 1988, với các đặc điểm sau:

• Tiến trình lặp lại một dãy các giai đoạn nhất định

• Qua mỗi vòng lặp, tạo ra một nguyên mẫu và được hoàn thiện dần

• Nhấn mạnh sự khắc phục các nguy cơ, những rủi ro có thể xuất hiện trong quá trình phát triển phần mềm, trong đó có nguy cơ bắt nguồn từ các sai sót trong đặc tả yêu cầu

Trong tin học, phần mềm nguyên mẫu (Prototype) là một hệ thống:

• Có khả năng làm việc được trên các dữ liệu thực, nghĩa là nó đã vượt qua giai đoạn dự án trên giấy và như vậy có thể được đánh giá bởi người thiết kế hoặc người sử dụng (khách hàng)

• Có thể được phát triển thêm để tiến tới hệ thống hoàn chỉnh, hoặc có thể làm cơ sở để phát triển hệ thống theo đơn đặt hàng

• Được tạo lập nhanh và ít tốn kém

• Dùng để kiểm chứng các giả định về nhu cầu cần đáp ứng, các lược đồ thiết kế về logic của các chương trình

Như vậy, việc tạo ra các nguyên mẫu nhanh chóng là có ích trên nhiều phương diện:

• Chính xác hoá các yêu cầu của hệ thống Thường thì các nhu cầu của người dùng không được phát biểu rành mạch, khó mà đặc tả được một cách hoàn toàn đúng đắn Một nguyên mẫu sẽ phô diễn cụ thể, tường minh để người dùng nhìn và cảm nhận thấy nó có đáp ứng trúng nhu cầu của mình hay không

• Phát hiện được các hành vi lệch lạc, các sai sót Trong thiết kế, có những điểm rất nhạy cảm, người thiết kế không lường hết được mọi tình huống Xây dựng nguyên mẫu giúp ta có thể phát hiện được hành vi lệch lạc, các khiếm khuyết của hệ thống

• Đánh giá được hiệu năng của hệ thống Hiệu năng của hệ thống liên quan chặt chẽ tới sự thích ứng của ngôn ngữ lập trình, các nền (Platform)

và các phần cứng như máy tính Nguyên mẫu phản ánh hiệu năng tương đối của chương trình và thông qua nguyên mẫu ta có thể phát hiện được những nguyên nhân cơ bản của sự chậm chạp từ bên trong chương trình,

từ những khâu giao tiếp người/máy, v.v

Với việc làm nguyên mẫu thì quá trình phát triển phần mềm sẽ có nhiều khác biệt so với quá trình tuyến tính nêu trên Theo Jekins, Milton và Naumann (Đại học Indiana City), chu trình xoắn ốc có thể chia thành bốn giai đoạn cho mỗi vòng lặp chính

Chu trình xoắn ốc có thể chia thành bốn giai đoạn cho mỗi vòng lặp chính như hình sau:

Giai đoạn 1: Với vòng lặp đầu tiên thì giai đoạn này nhằm phát hiện các yêu

cầu cơ bản, rõ nét nhất thông qua các phương pháp thông thường như: khảo sát, phỏng vấn, xem xét tài liệu, v.v Không cần phải vét cạn các yêu cầu mà nhanh chóng chuyển sang giai đoạn sau Từ vòng lặp thứ hai, thì giai đoạn này tập trung xác định các mục tiêu của vòng lặp hiện tại, các phương án và các ràng buộc từ kết quả vòng lặp trước

Giai đoạn 2: Đánh giá các phương án có thể, phát hiện ngay các nguy cơ tiềm

ẩn và tìm cách giải quyết chúng Các nguy cơ, rủi ro có thể xuất phát từ phía những công nghệ mới, những đối tác cạnh tranh, từ thị trường và khách hàng,

từ phía ngân sách, tài chính, v.v., trên cơ sở đó đánh giá tính khả thi của dự án

Giai đoạn 3: Thiết kế và tạo lập nguyên mẫu, tập trung vào những điều cốt yếu Giai đoạn 4: Thử nghiệm nguyên mẫu Trước hết giới thiệu nó cho một số

người dùng chọn lọc, thu thập các phê phán, các góp ý của họ Tuỳ theo mức độ quan trọng, một số điều chỉnh được thực hiện ở những vòng tiếp sau

Các vòng lặp được tiếp tục cho đến khi xét thấy nguyên mẫu là tốt thì có thể chuyển sang sản xuất thực sự

Tóm lại, khuôn cảnh chung của kỹ nghệ phần mềm có thể được mô tả như sau:

Các giai đoạn của quá trình phát triển phần mềm có thể thực hiện theo những phương pháp khác nhau tuỳ thuộc vào khả năng của nhóm thực hiện dự án Tuy nhiên, để cho thống nhất và hiệu quả thì tốt nhất là nên chọn một phương pháp, phương pháp hướng chức năng hay hướng đối tượng cho cả quá trình phát triển phần mềm Xu thế hiện nay là nên chọn phương pháp hướng đối tượng với sự hỗ trợ của nhiều công cụ hiện đại

1.5 Cách ti ếp cận hướng cấu trúc và tiếp cận hướng đối tượng

1.5.1 Ph ương pháp hướng cấu trúc

Đặc trưng của phương pháp hướng cấu trúc là phân chia chương trình chính thành nhiều chương trình con, mỗi chương trình con nhằm đến thực hiện một công việc xác định

Trong phương pháp hướng cấu trúc, phần mềm được thiết kế dựa trên một trong hai hướng : hướng dữ liệu và hướng hành động

- Cách tiếp cận hướng dữ liệu xây dựng phần mềm dựa trên việc phân rã phần mềm theo các chức năng cần đáp ứng và dữ liệu cho các chức năng đó Cách tiếp cận hướng dữ liệu sẽ giúp cho những người phát triển hệ thống dễ dàng xây dựng ngân hàng dữ liệu

- Cách tiếp cận hướng hành động lại tập trung phân tích hệ phần mềm dựa trên các hoạt động thực thi các chức năng của phần mềm đó

Cách thức thực hiện của phương pháp hướng cấu trúc là phương pháp thiết kế từ trên xuống (top-down) Phương pháp này tiến hành phân rã bài toán

thành các bài toán nhỏ hơn, rồi tiếp tục phân rã các bài toán con cho đến khi nhận được các bài toán có thể cài đặt được ngay sử dụng các hàm của ngôn ngữ lập trình hướng cấu trúc

Phương pháp hướng cấu trúc có ưu điểm là tư duy phân tích thiết kế rõ ràng, chương trình sáng sủa dễ hiểu Tuy nhiên, phương pháp này có một số nhược điểm sau:

- Không hỗ trợ việc sử dụng lại Các chương trình hướng cấu trúc phụ thuộc chặt chẽ vào cấu trúc dữ liệu và bài toán cụ thể, do đó không thể dùng lại một modul nào đó trong phần mềm này cho phần mềm mới với các yêu cầu về

dữ liệu khác

- Không phù hợp cho phát triển các phần mềm lớn Nếu hệ thống thông tin lớn, việc phân ra thành các bài toán con cũng như phân các bài toán con thành các modul và quản lý mối quan hệ giữa các modul đó sẽ là không phải là

dễ dàng và dễ gây ra các lỗi trong phân tích và thiết kế hệ thống, cũng như khó kiểm thử và bảo trì

1.5.2 Ph ương pháp hướng đối tượng

Khác với phương pháp hướng cấu trúc chỉ tập trung hoặc vào dữ liệu hoặc vào hành động, phương pháp hướng đối tượng tập trung vào cả hai khía cạnh của hệ thống là dữ liệu và hành động

Cách tiếp cận hướng đối tượng là một lối tư duy theo cách ánh xạ các thành phần trong bài toán vào các đối tượng ngoài đời thực Với cách tiếp cận này, một hệ thống được chia tương ứng thành các thành phần nhỏ gọi là các đối tượng, mỗi đối tượng bao gồm đầy đủ cả dữ liệu và hành động liên quan đến đối tượng đó

Các đối tượng trong một hệ thống tương đối độc lập với nhau và phần mềm sẽ được xây dựng bằng cách kết hợp các đối tượng đó lại với nhau thông qua các mối quan hệ và tương tác giữa chúng Các nguyên tắc cơ bản của phương pháp hướng đối tượng bao gồm:

✓ Trừu tượng hóa (abstraction): trong phương pháp hướng đối tượng, các thực thể phần mềm được mô hình hóa dưới dạng các đối tượng Các đối tượng này được trừu tượng hóa ở mức cao hơn dựa trên thuộc tính và phương thức mô tả đối tượng để tạo thành các lớp Các lớp cũng sẽ được trừu tượng hóa ở mức cao hơn nữa để tạo thành một sơ đồ các lớp được kế thừa lẫn nhau Trong phương pháp hướng đối tượng có thể tồn tại những lớp không có đối tượng tương ứng, gọi là lớp trừu tượng

Như vậy, nguyên tắc cơ bản để xây dựng các khái niệm trong hướng đối tượng là sự trừu tượng hóa theo các mức độ khác nhau

✓ Tính đóng gói (encapsulation) và ẩn dấu thông tin: các đối tượng có thể

có những phương thức hoặc thuộc tính riêng (kiểu private) mà các đối tượng khác không thể sử dụng được Dựa trên nguyên tắc ẩn giấu thông tin này, cài đặt của các đối tượng sẽ hoàn toàn độc lập với các đối tượng khác, các lớp độc lập với nhau và cao hơn nữa là cài đặt của hệ thống hoàn toàn độc lập với người sử dụng cũng như các hệ thống khác sử dụng kết quả của nó

✓ Tính modul hóa (modularity): các bài toán sẽ được phân chia thành những vấn đề nhỏ hơn, đơn giản và quản lý được

✓ 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à dạng phân cấp theo các mức độ trừu tượng từ cao đến thấp

Ưu điểm nổi bật của phương pháp hướng đối tượng là đã giải quyết được các vấn đề nảy sinh với phương pháp hướng cấu trúc:

✓ Hỗ trợ sử dụng lại mã nguồn : Chương trình lập trình theo phương pháp hướng đối tượng thường được chia thành các gói là các nhóm của các lớp đối tượng khác nhau Các gói này hoạt động tương đối độc lập và hoàn toàn có thể sử dụng lại trong các hệ thống thông tin tương tự

✓ Phù hợp với các hệ thống lớn: Phương pháp hướng đối tượng không chia bài toán thành các bài toán nhỏ mà tập trung vào việc xác định các đối tượng, dữ liệu và hành động gắn với đối tượng và mối quan hệ giữa các đối tượng Các đối tượng hoạt động độc lập và chỉ thực hiện hành động khi nhận được yêu cầu từ các đối tượng khác Vì vậy, phương pháp này hỗ trợ phân tích, thiết kế và quản lý một hệ thống lớn, có thể

mô tả các hoạt động nghiệp vụ phức tạp bởi quá trình phân tích thiết kế không phụ thuộc vào số biến dữ liệu hay số lượng thao tác cần thực hiện

mà chỉ quan tâm đến các đối tượng tồn tại trong hệ thống đó

CH ƯƠNG 2

MÔ HÌNH HÓA H ƯỚNG ĐỐI TƯỢNG

2.1 Đại cương về mô hình hóa

2.1.1 Khái ni ệm mô hình

Mô hình là một dạng thức trừu tượng về một hệ thống, được hình thành

để hiểu hệ thống trước khi xây dựng hoặc thay đổi hệ thống đó Theo Efraim Turban, mô hình là một dạng trình bày đơn giản hóa của thế giới thực Bởi vậy,

hệ thống thực tế rất phức tạp và rộng lớn, khi tiếp cận hệ thống , có những chi tiết, những mức độ phức tạp không cần thiết phải được mô tả và giải quyết Mô hình cung cấp một phương tiện (các khái niệm) để quan niệm hóa vấn đề và giúp chúng ta có thể trao đổi các ý tưởng trong một hình thức cụ thể trực quan, không mơ hồ

Mỗi mô hình có các đặc điểm sau:

- Diễn đạt mức độ trừu tượng hóa (ví dụ: mức quan niệm, mức tổ chức, mức vật lý, )

- Tuân theo một quan điểm (quan điểm của người mô hình hóa)

- Có một hình thức biểu diễn (văn bản, đồ họa: sơ đồ, biểu đồ hoặc đồ thị,…)

2.1.2 Ph ương pháp mô hình hóa

▪ Quá trình mô hình hóa phải được thực hiện theo một phương pháp nào đó

▪ Phương pháp là một sự kết hợp của ba thành phần:

- Một kí pháp

- Một tiến trình

- Một (hay một số) công cụ hỗ trợ (CASE)

• Hầu hết các kỹ thuật mô hình hóa sử dụng trong phân tích thiết kế là các ngôn ngữ đồ họa (đa số sử dụng sơ đồ - diagram), các ngôn ngữ này bao gồm một tập các kí hiệu Các kí hiệu này được dùng đi kèm theo các nguyên tắc của phương pháp luận giúp cho việc trao đổi quan hệ thông tin phức tạp được rõ ràng hơn việc mô tả bằng văn bản

2.2 Ngôn ng ữ mô hình hóa UML

2.2.1 L ịch sử của UML

Việc áp dụng rộng rãi phương pháp hướng đối tượng đã đặt ra yêu cầu cần phải xây dựng một phương pháp mô hình hóa để có thể sử dụng như một chuẩn chung cho những người phát triển phần mềm hướng đối tượng trên khắp

thế giới Trong khi các ngôn ngữ hướng đối tượng ra đời khá sớm, ví dụ như Simula-67 (năm 1967), Smalltalk (đầu những năm 1980), C++, CLOS (giữa những năm 1980)…thì những phương pháp luận cho phát triển hướng đối tượng lại ra đời khá muộn Cuối những năm 80, đầu những năm 1990, một loạt các phương pháp luận và ngôn ngữ mô hình hóa hướng đối tượng mới ra đời, như Booch của Grady Booch, OMT của James Rambaugh, OOSE của Ivar Jacobson, hay OOA and OOD của Coad và Yordon

Mỗi phương pháp luận và ngôn ngữ trên đều có hệ thống ký hiệu riêng, phương pháp xử lý riêng và công cụ hỗ trợ riêng Chính điều này đã thúc đẩy những người tiên phong trong lĩnh vực mô hình hoá hướng đối tượng ngồi lại cùng nhau để tích hợp những điểm mạnh của mỗi phương pháp và đưa ra một

mô hình thống nhất chung Nỗ lực thống nhất đầu tiên bắt đầu khi Rumbaugh gia nhập nhóm nghiên cứu của Booch tại tập đoàn Rational năm 1994 và sau đó Jacobson cũng gia nhập nhóm này vào năm 1995

James Rumbaugh, Grady Booch và Ivar Jacobson đã cùng cố gắng xây dựng được một Ngôn Ngữ Mô Hình Hoá Thống Nhất và đặt tên là UML (Unifield Modeling Language) (Hình 2.1) UML đầu tiên được đưa ra năm 1997

và sau đó được chuẩn hoá để trở thành phiên bản 1.0 Hiện nay chúng ta đang

sử dụng ngôn ngữ UML phiên bản 2.2

2.2.2 UML Ngôn ng ữ mô hình hóa đối tượng

UML (Unified Modelling Language) là ngôn ngữ mô hình hoá tổng quát được xây dựng để đặc tả, phát triển và viết tài liệu cho các khía cạnh trong phát triển phần mềm hướng đối tượng UML giúp người phát triển hiểu rõ và ra quyết định liên quan đến phần mềm cần xây dựng UML bao gồm một tập các khái niệm, các ký hiệu, các biểu đồ

UML hỗ trợ xây dựng hệ thống hướng đối tượng dựa trên việc nắm bắt khía cạnh cấu trúc tĩnh và các hành vi động của hệ thống:

- Các cấu trúc tĩnh định nghĩa các kiểu đối tượng quan trọng của hệ thống, nhằm cài đặt và chỉ ra mối quan hệ giữa các đối tượng đó

- Các hành vi động (dynamic behavior) định nghĩa các hoạt động của các đối tượng theo thời gian và tương tác giữa các đối tượng để hướng tới đích Các mục đích của ngôn ngữ mô hình hoá thống nhất UML:

- Mô hình hoá các hệ thống sử dụng các khái niệm hướng đối tượng

- Thiết lập sự liên hệ từ nhận thức của con người đến các sự kiện cần mô hình hoá

- Giải quyết vấn đề ở mức độ thừa kế trong các hệ thống phức tạp với nhiều ràng buộc khác nhau

- Tạo một ngôn ngữ mô hình hoá có thể sử dụng được bởi người và máy UML quy định một loạt các ký hiệu và quy tắc để mô hình hoá các pha trong quá trình phát triển phần mềm hướng đối tượng dưới dạng các biểu đồ

(2) Góc nhìn thi ết kế (góc nhìn logic): Hướng nhìn logic miêu tả phương thức

mà các chức năng của hệ thống sẽ được cung cấp Chủ yếu nó được sử dụng cho các nhà thiết kế và nhà phát triển Ngược lại với hướng nhìn Use case, hướng nhìn logic nhìn vào phía bên trong của hệ thống Nó miêu tả kể cả cấu trúc tĩnh (lớp, đối tượng, và quan hệ) cũng như sự tương tác động sẽ xảy ra khi các đối tượng gửi thông điệp cho nhau để cung cấp chức năng đã định sẵn Hướng nhìn logic định nghĩa các thuộc tính như trường tồn (persistency) hoặc song song (concurrency), cũng như các giao diện cũng như cấu trúc nội tại của các lớp Cấu trúc tĩnh được miêu tả bằng các biểu đồ lớp (class diagram) và

Góc nhìn thiết kế (lớp, gói, đối tượng)

Góc nhìn thực thi (thành phần)

Góc nhìn quá trình (trình tự, giao tiếp, trạng thái, hoạt động)

Góc nhìn bố trí (thành phần, bố trí) Góc nhìn ca sử dụng

biểu đồ đối tượng (object diagram) Quá trình mô hình hóa động được miêu tả trong các biểu đồ trạng thái (state diagram), biểu đồ trình tự (sequence diagram), biểu đồ tương tác (collaboration diagram) và biểu đồ hoạt động (activity diagram)

(3) Góc nhìn quá trình (còn g ọi là góc nhìn song hành): Phản ánh các lộ trình

điều khiển, các quá trình thực hiện, cho thấy sự hoạt động song hành hay đồng

bộ của hệ thống Với UML thì góc nhìn này được thể hiện cùng với các biểu đồ như góc nhìn thiết kế, nhưng tập trung chú ý vào các lớp chủ động, là các lớp biểu diễn cho các lộ trình điều khiển và quá trình thực hiện

(4) Góc nhìn th ực thi (còn gọi là góc nhìn thành phần): Là góc nhìn đối với

đối dạng phát hành của phần mềm (hệ thống vật lý) bao gồm các thành phần và tệp tương đối độc lập; có thể lắp ráp theo nhiều cách để tạo ra hệ thống chạy được Với UML, sắc thái tĩnh của góc nhìn này được thể hiện bởi các biểu đồ thành phần Còn sắc thái động của góc nhìn này thể hiện qua các biểu đồ tương tác, biểu đồ máy trạng thái và biểu đồ hoạt động

(5) Góc nhìn b ố trí: Là góc nhìn tôpô của phần cứng mà trên đó hệ thống được

thực hiện Nó chỉ rõ sự phân bố, sự sắp đặt các phần của hệ thống vật lý trên các đơn vị phần cứng Với UML, sắc thái tĩnh của góc nhìn này thể hiện qua các biểu đồ bố trí Còn sắc thái động của góc nhìn này thể hiện qua các biểu đồ tương tác, biểu đồ trạng thái và biểu đồ hoạt động

Có thể vận dụng các góc nhìn nói trên một cách tách biệt, vì với mỗi loại người quan tâm tới hệ thống, như người dùng cuối, người phân tích, người thiết kế, người tích hợp, người kiểm định, người quản lý dự án…thường chỉ tập trung tới một phương diện nào đó của hệ thống Tuy nhiên năm góc nhìn trên phải có

sự tương hợp lẫn nhau, chẳng hạn các nút trong góc nhìn bố trí phải tương ứng với các thành phần trong góc nhìn thực thi và các thành phần này lại là sự thực hiện vật lý của các lớp, các giao diện, các hợp tác và các lớp chủ động của hai góc nhìn thiết kế và quá trình Lý do góc nhìn ca sử dụng được vẽ chính giữa bởi vì góc nhìn này có ảnh hưởng xuyên suốt với bốn góc nhìn còn lại Vì vậy, thiết kế, thực thi, nghiên cứu quá trình hay bố trí đều phải nhằm đáp ứng các nhiệm vụ cơ bản của hệ thống tức là các ca sử dụng

2.2.4 Gi ới thiệu các biểu đồ của UML

• Biểu đồ use case biểu diễn sơ đồ chức năng của hệ thống Từ tập yêu cầu của hệ thống, biểu đồ use case sẽ phải chỉ ra hệ thống cần thực hiện điều gì

để thoả mãn các yêu cầu của người dùng hệ thống đó Đi kèm với biểu đồ use case là các kịch bản

• Biểu đồ lớp mô tả các lớp trong hệ thống, các thuộc tính và phương thức của từng lớp và các mối quan hệ giữa những lớp đó

• Biểu đồ đối tượng gồm các đối tượng và các liên kết biểu diễn một bức ảnh của hệ thống tại một thời điểm

• Biểu đồ trạng thái tương ứng với mỗi lớp sẽ chỉ ra các trạng thái mà đối tượng của lớp đó có thể có và sự chuyển tiếp giữa những trạng thái đó

• Các biểu đồ tương tác biểu diễn mối liên hệ giữa các đối tượng trong hệ thống và giữa các đối tượng với các tác nhân bên ngoài Có hai loại biểu đồ tương tác:

- Biểu đồ tuần tự: Biểu diễn mối quan hệ giữa các đối tượng và giữa các đối tượng và tác nhân theo thứ tự thời gian

- Biểu đồ cộng tác (Biểu đồ giao tiếp): Biểu diễn mối quan hệ giữa các đối tượng và giữa các đối tượng và tác nhân nhưng nhấn mạnh đến vai trò của các đối tượng trong tương tác

• Biểu đồ hoạt động biểu diễn các hoạt động và sự đồng bộ, chuyển tiếp các hoạt động, thường được sử dụng để biểu diễn các phương thức phức tạp của các lớp

• Biểu đồ thành phần định nghĩa các thành phần của hệ thống và mối liên hệ giữa các thành phần đó

• Biểu đồ triển khai mô tả hệ thống sẽ được triển khai như thế nào, thành phần nào được cài đặt ở đâu, các liên kết vật lý hoặc giao thức truyền thông nào được sử dụng

Dựa trên tính chất của các biểu đồ, UML chia các biểu đồ thành hai lớp mô hình:

• Biểu đồ mô hình cấu trúc (Structural Modeling Diagrams): biểu diễn các cấu trúc tĩnh của hệ thống phần mềm được mô hình hoá Các biểu đồ trong mô hình tĩnh tập trung biểu diễn khía cạnh tĩnh của hệ thống, liên quan đến cấu trúc cơ bản cũng như các phần tử chính trong miền quan tâm của bài toán Các biểu đồ trong mô hình tĩnh bao gồm:

• Biểu đồ mô hình hành vi (Behavioral Modeling Diagrams): Nắm bắt đến các hoạt động và hành vi của hệ thống, cũng như tương tác giữa các phần tử bên trong và bên ngoài hệ thống Các dạng biểu đồ trong mô hình động bao gồm:

- Biểu đồ use case

- Biểu đồ tuần tự

- Biểu đồ cộng tác

- Biểu đồ trạng thái

- Biểu đồ hoạt động

2.3 Ti ến trình RUP (Rational Unified Process)

Tiến trình RUP (Rational Unified Process) là một tiến trình mô hình hóa UML

2.3.1 Các nguyên t ắc cơ bản của RUP

Tiến trình RUP là một tiến trình phát triển phần mềm dựa trên các nguyên tắc: “lặp và tăng trưởng, tập trung vào kiến trúc, dẫn dắt theo các ca sử dụng và khống chế bởi các nguy cơ”

a) L ặp và tăng trưởng

Dự án được cắt thành những vòng lặp hoặc giai đoạn ngắn cho phép kiểm soát dễ dàng sự tiến triển của dự án Cuối mỗi vòng lặp thì một phần thi hành được của hệ thống được sản sinh theo cách tăng trưởng (thêm vào dần dần)

b) T ập trung vào kiến trúc

Toàn bộ hệ thống phức tạp được phân chia thành từng phần (các môdun)

để có thể dễ dàng triển khai và duy tu, tạo nên một kiến trúc Kiến trúc này phải được trình bày theo năm góc nhìn khác nhau và bởi các biểu đồ của UML

c) D ẫn dắt theo các ca sử dụng

RUP nhấn mạnh sự đáp ứng các nhu cầu của người dùng, thể hiện bởi các ca sử dụng Do đó các ca sử dụng ảnh hưởng và dẫn đường cho mọi giai đoạn phát triển hệ thống Nắm bắt nhu cầu là để phát hiện các ca sử dụng Phân tích là đi sâu vào các ca sử dụng Thiết kế và cài đặt là để xây dựng hệ thống theo từng ca sử dụng

d) Kh ống chế bởi các nguy cơ

Các nguy cơ chính đối với dự án phải phát hiện sớm và phải loại bỏ càng sớm càng tốt Yêu cầu này cũng là căn cứ để xác định thứ tự trước sau của các vòng lặp

2.3.2 Các pha và công đo ạn của RUP

Tiến hành RUP được tiến hành thành bốn pha (phase) nối tiếp trong thời gian là: khởi đầu, triển khai, xây dựng và chuyển giao

a) Pha kh ởi đầu

Pha khởi đầu (inception) nhằm cho một cái nhìn tổng quát về hệ thống cần xây dựng (chức năng, hiệu năng và công nghệ v.v…) Từ đó đưa ra kết luận

là nên phát triển hay nên loại bỏ dự án

b) Pha tri ển khai

Pha triển khai bao gồm một sự phân tích chi tiết hơn về hệ thống, cả về chức năng và cấu trúc tĩnh (dùng các biể đồ ca sử dụng, biểu đồ lớp, các biểu

đồ tương tác) Đồng thời một kiến trúc hệ thống cũng được đề xuất Kiến trúc này có thể dựng thành nguyên mẫu (prototype) trên đó có thể thử nghiệm nhiều

d) Pha chuy ển giao

Pha chuyển giao (transition) nhằm chuyển hệ thống đã xây dựng từ tay những người phát triển hệ thống tới tay những người dùng cuối, bao gồm các công việc như chuyển đổi các dữ liệu, đào tạo người dùng, lắp đặt và kiểm định bên A Mỗi pha nói trên, đặc biệt là pha xây dựng và có thể cả pha triển khai, lại được chia thành một số vòng lặp (kéo dài độ 2 đến 4 tuần) Mỗi vòng lặp sẽ hoàn thành một phần của hệ thống và trải qua năm công đoạn sau: nắm bắt yêu cầu, phân tích và thiết kế, thực thi, kiểm định và bố trí Tuy nhiên công việc cho mỗi công đoạn đó trong vòng lặp là tùy thuộc vòng lặp đó ở pha nào: Ở các pha đầu thì các công đoạn đầu (nắm bắt yêu cầu, phân tích thiết kế) được nhấn mạnh, còn ở các pha cuối thì các công đoạn cuối (thực thi, kiểm định và bố trí) lại được nhấn mạnh

2.3.3 M ột tiến trình đơn giản

Tiến trình RUP như đã giới thiệu ở trên, với các nguyên tắc cơ bản và sự phân chia thành các pha, các vòng lặp, các công đoạn, thì vẫn chưa phải là một

tiến trình cụ thể mà chỉ mới là một khuôn khổ hay một họ các tiến trình Để có

một tiến trình, ta còn phải chỉ rõ các bước đi, công việc phải làm trong mỗi

bước, sản phẩm phải hoàn thành sau mỗi bước, để có thể dẫn dắt một cách chắc

chắn quá trình phát triển một phần mềm từ nhu cầu đặt ra cho tới mã chương

trình chạy được và đáp ứng được các nhu cầu một cách đầy đủ và với hiệu

năng mong muốn

Sau đây là tiến trình đơn giản, gồm 10 bước với các đặc điểm sau:

• Nó thực hiện mô hình hóa với các biểu đồ UML

• Nó tuân thủ các nguyên tắc của RUP, song đã đơn giản hóa nhưng vẫn

không bỏ qua những hoạt động cơ bản về phân tích và thiết kế

• Nó chú trọng nguyên tắc dẫn dắt bởi các ca sử dụng, song cố gắng thể

hiện một cách nhẹ nhành và tự nhiên

• Nó được triển khai theo nguyên tắc lặp và tăng trưởng (trong từng bước)

và nguyên tắc khống chế bởi các nguy cơ

1) Nghiên c ứu sơ bộ: Nhằm đưa ra một “cái nhìn” khái quát về hệ thống

sẽ xây dựng (chức năng, hiệu năng, công nghệ,…) và về dự án sẽ triển

khai (phạm vi, mục tiêu, tính khả thi,…) Từ đó đưa ra kết luận nên triển

khai tiếp hay nên chấm dứt dự án Như vậy đây chính là pha khởi đầu của

RUP

2) Nh ận định và đặc tả ca sử dụng: từ việc nắm bắt các nhu cầu của

người dùng mà phát hiện các ca sử dụng Ca sử dụng là một tập hợp của những dãy hành động mà hệ thống thực hiện để đưa ra một kết quả có ích cho một đối tác của hệ thống Mỗi ca sử dụng phải được đặc tả dưới dạng văn tự (kịch bản) và/hoặc dưới dạng một biểu đồ trình tự hệ thống

3) Mô hình hóa lĩnh vực ứng dụng: Đưa ra một mô hình (dưới dạng một

biểu đồ lớp) nhằm phản ánh mọi khái niệm nghiệp vụ (thực thể và liên kết) mà người dùng cũng như người xây dựng hệ thống, khi đề cập tới hệ thống và ứng dụng đều phải sử dụng đến Các lớp xuất hiện ở đây đều là các lớp “lĩnh vực” nghĩa là các lớp thuộc tĩnh vực nghiệp vụ của ứng dụng mà chưa có các lớp phù trợ khác

4) Xác định các đối tượng/lớp tham gia các ca sử dụng: đối với mỗi ca

sử dụng, phải phát hiện các lớp lĩnh vực, cùng với các lớp điều khiển và các lớp biên (giao diện) tham gia thực hiện ca sử dụng đó Như vậy ta lập một biểu lớp (hay biểu đồ đối tượng) làm nền cho mỗi ca sử dụng Chính trên nền đó mà ta nghiên cứu sự tương tác ở bước sau

5) Mô hình hóa t ương tác trong ca sử dụng: Sử dụng sự tương tác duy

nhất có thể có giữa các đối tượng là trao đổi thông điệp Cần phải nghiên cứu sự tương tác giữa các đối tượng tham gia mỗi ca sử dụng, mà kết quả phải là tạo nên kịch bản của ca sử dụng đó Sự tương tác được trình bày dưới dạng biểu đồ trình tự hay biểu đồ giao tiếp

6) Mô hình hóa ứng dụng: Các đối tượng điều khiển khác với các đối

tượng thực thể ở chỗ có khả năng ứng xử trước các sự kiện từ ngoài đến

để đưa ra các quyết định điều khiển thích hợp Việc mô tả hành vi ứng xử của các đối tượng điều khiển được thực hiện bởi các biểu đồ máy trạng thái

7) Làm nguyên m ẫu giao diện người dùng: Với các bộ tạo lập GUI, ta

có thể thành lập sớm và nhanh một nguyên mẫu giao diện người dùng, giúp cho việc mô hình hóa và cài đặt hệ thống triển khai dễ dàng hơn

8) Thi ết kế hệ thống: Đó là sự thiết kế kiến trúc tổng thể cuả hệ thống,

bao việc vỡ hệ thống thành các hệ thống con, chọn lựa loại hình điều khiển thích hợp, miêu tả các thành phần vật lý của hệ thống (dùng biểu đồ thành phần) và bố trí các thành phần khả thi vào các phần cứng (dùng biểu

đồ bố trí) Một kiến trúc khách hàng/dịch vụ (client/server) nhiều tầng thường được chọn lựa ở đây

9) Thi ết kế chi tiết: Đó là bước thiết kế về các lớp, các liên kết, các thuộc

tính, các thao tác, thực hiện trên từng tầng của kiến trúc khách hàng/dịch

vụ (tầng trình bày, tầng ứng dụng, tầng nghiệp vụ, tầng lưu trữ dữ liệu)

và xác định các giải pháp cài đặt trên mạng

10) Cài đặt: Đó là bước thực thi hệ thống, bao gồm lập trình và kiểm

định Hệ thống được nghiệm thu dựa trên các ca sử dụng

sử dụng hay một thao tác phức tạp

▪ Có thể nói biểu đồ hoạt động là mô hình hóa UML tương đương với

sơ đồ khối hoặc biểu đồ luồng dữ liệu trong các phương pháp phân tích và thiết kế cũ Sau đây ta lần lượt đề cập đến các yếu tố tạo nên một biểu đồ hoạt động

cứu sơ bộ nhằm tìm hiểu môi trường nghiệp vụ của hệ thống tương lai Trong môi trường đó thì người, thiết bị, máy tính kết hợp với nhau hoạt động theo những quy trình nghiệp vụ nhất đinh Quy trình nghiệp vụ thường được mô tả bằng các biểu đồ hoạt động

- Hoạt động là một công việc, có thể là được xử lý bằng tay như là Điền mẫu hoặc xử lý bằng máy tính như là Hiễn thị màn hình

- Biểu diễn hoạt động

- Dịch chuyển (Transition) là sự chuyển tiếp từ hoạt động này sang hoạt động khác

- Biểu diễn dịch chuyển:

Tên hoạt động

• Các cảnh giới (Quyết định)

- Cảnh giới là một điều kiện Bun gắn với một dịch chuyển để diễn tả

rằng dịch chuyển đó chỉ được thực hiện khi điều kiện này được

thỏa mãn

- Để thực hiện sự rẽ nhánh, UML dùng một hình thoi nhỏ với ý

nghĩa:

▪ Hoặc là một quyết định (decision), khi có một luồng vào và

nhiều luồng ra (các luồng ra phải mang các cảnh giới loại trừ lẫn

nhau)

▪ Hoặc là một hòa nhập (merge), khi nó có nhiều luồng vào và chỉ

một luồng ra (điểm hòa nhập sẽ được vượt qua khi có một luồng

vào xuất hiện)

• Đồng bộ hóa

▪ Trong biểu đồ hoạt động ta có thể dùng các thanh đồng bộ hóa để mở

hay đóng các nhánh thực hiện song song:

- Mở các nhánh song song bằng một thanh đồng bộ hóa khi nó có một

dịch chuyển vào và nhiều dịch chuyển ra – ta gọi đó là một chạc

(fork)

- Đóng các nhánh song song bằng một thanh đồng bộ hóa khi nó có

nhiều dịch chuyển vào và một dịch chuyển ra – ta gọi đó là một

chụm (join) Chụm chỉ có thể vượt qua khi mọi nhanh vào nó đều

• Phân tuyến và vùng (Luồng)

▪ Biểu đồ hoạt động có thể phân tuyến, như trong một bể bơi Mỗi hoạt

động phải đặt gọn trong một tuyến, và mỗi tuyến giành cho một hay

một số đối tượng thực hiện Các dịch chuyển có thể dịch chuyển tự

do

▪ Biểu đồ hoạt động cũng có thể được phân vùng, mỗi vùng gồm các

hoạt động cùng hướng vào một mục đích chung nào đó Có thể có một

vùng thực hiện kịch bản chính, còn các vùng khác thực hiện các kịch

bản phụ

• Các thành phần của biểu đồ hoạt động được mô tả bằng hình sau:

b) T ạo lập đối tượng và xuất nhập sự kiện

▪ Nhiều khi trong một biểu đồ hoạt động, ta lại muốn chỉ rõ rằng có một

hoạt động nào đó tạo lập (hay làm thay đổi trạng thái) một đối tượng,

hoặc nhân đôi một đối tượng để xử lý Bây giờ, ta vẽ thêm đối tượng

(với trạng thái nếu cần) vào trong biểu đồ hoạt động và nối nó với

hoạt động liên quan bằng một mũi tên đứa nét (gọi là một luồng đối

tượng) Một luồng đối tượng từ một hoạt động đến một đối tượng, rồi lại tiếp tục đi vào một hoạt động khác có thể xem là một luồng điều khiển (một dịch chuyển) giữa hai hoạt động đó

▪ Thí dụ: Hình sau đây diễn tả một quy trình hoạt động bán hàng, trong

đó có chỉ rõ một đối tượng Đơn hàng đã được tạo lập và thay đổi trạng thái qua các bước hoạt động

3.2 Mô hình hóa v ới biểu đồ ca sử dụng (USE CASE)

3.2.1 Gi ới thiệu

• Biểu đồ ca sử dụng mô tả sự tương tác giữa các tác nhân ngoài và hệ

thống thông qua các ca sử dụng Các ca sử dụng là những nhiệm vụ chính, các dịch vụ, những trường hợp sử dụng cụ thể mà hệ thống cung cấp cho người sử dụng và ngược lại

3.2.2 Tác nhân (Actor)

a) Định nghĩa: Tác nhân là vai trò của một hay nhiều người hoặc vật thể

ở ngoài hệ thống và có tương tác với hệ thống theo những hình thức sau:

Thăm

dò

Lập 1 dự toán

Đặt

hàng

Trả tiền

Làm hóa đơn

Đơn hàng [đã giao]

Giao hàng Đơn hàng

[đã trả tiền]

Khách

hàng

Người giao hàng

- Tương tác, trao đổi thông tin với hệ thống hoặc sử dụng các chức năng của hệ thống

- Cung cấp thông tin đầu vào hoặc nhận thông tin đầu ra của hệ thống

- Không điều khiển hoạt động của hệ thống

• Tác nhân được hiểu là một vai trò tham gia vào hệ thống không giống

như một con người cụ thể hoặc một công việc Mỗi đối tượng có thể tham gia vào một hoặc nhiều vai trò

• Qua quá trình khảo sát và phân tích tài liệu hệ thống, ta có thể nhận ra

các tác nhân thông qua các câu hỏi sau:

- Ai đang sử dụng hệ thống? Hoặc ai tác động bởi hệ thống? Hoặc nhóm đối tượng nào cần hệ thống trợ giúp để làm công việc (Tác nhân chính)

- Nhóm đối tượng nào cần để vận hành sự hoạt động của hệ thống (Tác nhân phụ)

- Những phần cứng hoặc hệ thống bên ngoài nào sử dụng hệ thống

Ví dụ: Trong hoạt động của máy ATM của một ngân hàng, các tác nhân được xác định là:

Trong đó, các tác nhân, Khách hàng, Nhân viên ngân hàng là các tác nhân chính (primary actor) của hệ thống ATM Vì khách hàng là mục tiêu mà

hệ thống tương tác; Nhân viên ngân hàng sử dụng hệ thống để trợ giúp công việc Trong khi đó, Nhân viên vận hành là tác nhân phụ (secondary actor) bởi vì tác nhân này đảm nhận những chức năng phụ mà hệ thống cần có để thực hiện hoạt động của nó

3.2.3 USECASE (Ca s ử dụng)

a) Định nghĩa UseCase: là một biểu diễn của một tập hợp các chuỗi hành

động của hệ thống nhằm cung cấp một kết quả cho ít nhất một tác nhân của hệ thống

b) Đặc điểm của UseCase

• Ca sử dụng phải liên kết với một hay một số tác nhân

• Ca sử dụng phải dẫn tới một kết quả cụ thể

• Ca sử dụng phải là tập hợp của nhiều chuỗi hành động (các kịch bản)

c) Bi ểu diễn UseCase

Hoặc có thể biểu diễn như hình sau:

Ghi chú: Cách đ ặt tên của UseCase: tên của UseCase phải được bắt đầu bằng một động từ sao cho phải ngắn gọn nhưng diễn đạt được đầy đủ chức năng của UseCase

d) Xác định UseCase

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

▪ Phương pháp thứ nhất là dựa vào các tác nhân:

- Xác định những tác nhân liên quan đến hệ thống hoặc đến tổ chức

- Với mỗi tác nhân, tìm những các nhiệm vụ hay chức năng mà tác nhân sẽ thi hành hoặc hệ thống cần tác nhân để thi hành và mô hình hóa nó như là usecase

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

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

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

Ghi chú: V ới mỗi tác nhân đã tìm ra, hãy trả lời các câu hỏi sau để tìm ra các Use case hệ thống

• Tác nhân yêu cầu hệ thống thực hiện chức năng nào?

• Tác nhân cần đọc, tạo lập, bãi bỏ, lưu trữ, sửa đổi các thông tin nào

trong hệ thống?

• Tác nhân cần thông báo cho hệ thống sự kiện xảy ra trong nó?

• Hệ thống cần thông báo cái gì đó cho tác nhân?

• Hệ thống cần vào/ra nào? Vào/ra đi đến đâu hay từ đâu?

• Sau khi đã xác định xong các ca sử dụng cho hệ thống thì phải kiểm

tra lại xem chúng đã được phát hiện hết chưa Công việc này được thực hiện bằng cách trả lời cho các câu hỏi sau:

- Mỗi yêu cầu chức năng của hệ thống đã có trong ít nhất một ca sử dụng chưa? Những chức năng chưa được mô tả trong các ca sử dụng sẽ không được cài đặt sau này

- Các mối tương tác giữa các tác nhân và hệ thống đã xác định hết chưa?

- Tác nhân cung cấp những gì cho hệ thống?

sử dụng cùng mối quan hệ của chúng mô tả bức tranh khái quát về hệ thống, đặc tả đầy đủ về các yêu cầu của hệ thống Do đó, vấn đề rất quan trọng đặt ra là làm thế nào để xác định được đầy đủ và chính xác các tác nhân ngoài, các ca sử dụng của hệ thống cần xây dựng

G ử i ti ề n: Khách hàng đăng nh ập vào hệ thống và yêu cầu gửi tiền vào tài khoản Khách hàng sẽ xác định tài khoản và số tiền gửi, hệ thống sẽ tạo một giao tác gửi tiền và lưu vào hệ thống Các bước xác định như sau:

- Yêu cầu xác định tài khoản

- Hệ thống hỏi số tiền gửi

- Nhập số tiền gửi

- Khách hàng đưa tiền vào bao thư và chuyển vào máy ATM

Rút ti ề n: Khách hàng đăng nh ập hệ thống và yêu cầu rút tiền từ tài khoản Khách hàng xác định tài khoản và lượng tiền cần rút Sauk khi kiểm tra số

dư tài khoản còn đủ, hệ thống sẽ tạo một giao tác rút tiền và lưu vào hệ thống Các bước như sau:

- Yêu cầu xác định tài khoản

- Yêu cầu xác định số tiền cần rút

- Nhập số tiền rút

- Kiểm tra số dư có đủ không

- Chuyển tiền ra ngoài

Truy v ấ n thông tin tài kho ả n: Khách hàng đăng nh ập vào hệ thống và yêu cầu xem thông tin về các giao dịch của tài khoản Hệ thống hiển thị các thông itn về các giao tác đã tạo nên màn hình cho khách hàng

Kh ở i đ ộ ng h ệ th ố ng: h ệ thống khởi động khi nhân viên vận hành bật công tắc của máy Nhân viên vận hành sẽ được yêu cầu nhập vào số tiền hiện hành của máy trong két đựng tiền Sau đó, hệ thống sẽ thiết lập một kết nối tới ngân hàng và các dịch vụ của máy ATM bắt đầu vận hành

Đóng h ệ th ố ng: h ệ thống được đóng lại khi nhân viên vận hành đảm bảo rằng không có khách nào đang sử dụng máy Khi đó, nhân viên vận hành

sẽ lấy các bao tiền gửi ra, bổ sung lượng tiền, giấy,…

Ví dụ: Xác định các useCase trong hệ thống quản lý thư viện

3.2.4 Xác đ ịnh mối quan hệ

a) Liên k ết khái quát hóa giữa các tác nhân

▪ Tác nhân A có mối liên kết khái quát hóa với tác nhân B nếu B thừa kế

mọi đặc điểm của A

b) Liên k ết giao tiếp giữa một tác nhân với một ca sử dụng

▪ Đó là trường hợp tác nhân và ca sử dụng có trao đổi thông tin với

nhau

▪ Biểu diễn:

Nếu thông tin trao đổi là một chiều thì dùng mũi tên:

c) Liên quan khái quát hóa gi ữa hai ca sử dụng

▪ Ca sử dụng X là khái quát hóa của ca sử dụng Y nếu Y thừa kế mọi

đặc điểm của X (có thể điều chỉnh và thêm mới)

▪ Biểu diễn:

Rut tien

Rut tien mat Rut tien chuyen khoan

d) Liên k ết bao hàm giữa 2 ca sử dụng

▪ Đó là trường hợp mà một ca sử dụng X ghép nội dung của 1 ca sử dụng

Y vào nội dung của nó(tại 1 điểm được chỉ rõ trong đặc tả).X gọi là ca

usecase cơ sở

▪ Biểu diễn:

• UseCase trừu tượng

Quan hệ includes và extends đều có tính chất chung là cùng sử dụng chức năng do UC khác cung cấp Phần chức năng sử dụng chung có thể để trong UC trừu tượng UseCase trừu tượng không bị tác nhân kích hoạt giao tiếp

3.2.5 Đ ặc tả UseCase

• Để hiểu rõ hơn về tiến trình xử lý các yêu cầu của hệ thống, ta nên xây dựng các đặc tả cho các ca sử dụng

• Mẫu (Format) đặc tả ca sử dụng có dạng:

-

Ca s ử d ụ ng : Tên c ủa ca sử dụng bắt đầu bằng động từ

-

Các tác nhân : Danh sách các tác nhân liên quan đến ca sử dụng, chỉ

rõ ai bắt đầu với ca sử dụng này

-

Mô t ả : Mô tả tóm tắt tiến trình xử lý công việc cần thực hiện

-

Tham chi ế u: Các chức năng, ca sử dụng và những hệ thống liên quan

Điều kiện: {người dùng y/c ƯT}

Điểm mở rộng: dành ƯT

UseCase cơ sở

<<extend>>

-

Ti ề n đi ề u ki ệ n (pre-condition) : Điều kiện cần thực hiện trước khi

UC khởi động, Không phải UC nào cũng có tiền điều kiện

-

Lu ồ ng k ị ch b ả n: luồng sự kiện (flow of events) mô tả hành vi của

UC mô tả luồng logíc đi qua UC, nó mô tả người sử dụng làm gì,

hệ thống làm gì Trong một UC có nhiều luồng sự kiện: luồng chính, luồng phụ

-

Hậu điều kiện (post–conditions) Hậu điều kiện là điều kiện được thực hiện ngay sau khi kết thúc UC Nó mô tả trạng thái hệ thống hay tác nhân sau khi hoàn thành UC Thí dụ, phải đặt cờ báo hiệu

UC đã hoàn thành Tương tự tiền điều kiện, hậu điều kiện có thể chứa thông tin ra lệnh UC khác chạy không phải mọi UC trong hệ thống đều có hậu điều kiện

Tài liệu luồng sự kiện của UC rút tiền trong hệ thống rút tiền tự động Luồng chính

1 UC bắt đầu khi khách hàng đặt thẻ vào máy ATM

2 ATM hiển thị thông báo và chờ khách hàng số căn cước cá nhân (pin)

3 Khách hàng nhập pin

4 ATM khẳng định pin có hợp lệ? nếu pin không hợp lệ thì thực hiện luồng a1

5 ATM hiển thị các lựa chọn

a Gửi tiền vào tài khoản

b Rút tiền

c Chuyển tiền sang tài khoản khác

6 Khách hàng chọn rút tiền

7 ATM hiển thị câu hỏi số tiền sẽ rút

8 Khách hàng nhập số tiền muốn rút lần này

9 ATM xác định số dư còn đủ? Nếu không đủ thực hiện luồng a2 nếu phát hiện lỗi khi kiểm tra số dư thì thực hiện luồng e1

10 ATM trừ số tiền trong tài khoản của khách hàng

11 ATM chuyển tiền cho khách hàng

12 ATM in biên nhận

13 ATM trả lại thẻ tín dụng

14 UC kết thúc

Luồng nhánh A1: số căn cước cá nhân (PIN) không hợp lệ

1 ATM thông báo căn cước cá nhân (PIN) không hợp lệ

2 ATM trả lại thẻ tín dụng

3 Kết thúc UC

Luồng nhánh A2: không đủ tiền trong tài khoản để rút

1 ATM thông báo không đủ tiền

2 ATM trả lại thẻ tín dụng

3 Kết thúc UC

Luồng e1: lỗi xảy ra khi kiểm tra số dư không đủ

1 ATM thông báo lỗi

2 ATM ghi thông báo này vào tệp chứa lỗi (error log)

3 ATM trả lại thẻ tín dụng

4 Kết thúc UC

Ví d ụ: Hệ thống bán hàng

Mô tả luồng kịch bản trong use Case thanh toán

Ví d ụ: Hệ thống quản lý thư viện:

Đặc tả cho use Case thêm sách: