Sử dụng hiệu quả ngôn ngữ đặc tả UML trong phát triển phần mềm

Bảng thuật ngữ chuyên môn Artifact Sản phẩm trong quy trình RUP Association Liên kết Business Modeling Mô hình hóa tác nghiệp Class Diagram Biểu đồ lớp Development Case Một tập hợp các A

ĐẠI HỌC CÔNG NGHỆ

- - Trần Thịnh Phong

SỬ DỤNG HIỆU QUẢ NGÔN NGỮ ĐẶC TẢ UML

TRONG PHÁT TRIỂN PHẦN MỀM

Ngành: Công nghệ thông tin

Mã số: 1.01.10

LUẬN VĂN THẠC SĨ

NGƯỜI HƯỚNG DẪN KHOA HỌC

PGS.TSKH Nguyễn Xuân Huy

Hà Nội - 2008

Mục lục

Mở đầu 6

Chương 1: Tổng quan 7

1.1 Mô tả vấn đề 7

1.2 Mục tiêu 7

Chương 2: Ngôn ngữ mô hình hóa thống nhất UML 8

2.1 Khái quát 8

2.2 Các biểu đồ của UML 8

2.2.1 Use Case Diagram – Biểu đồ Use Case 8

2.2.2 Class Diagram – Biểu đồ Lớp 9

2.2.3 Statechart Diagram – Biểu đồ Trạng thái 10

2.2.4 Activity Diagram – Biểu đồ hoạt động 11

2.2.5 Sequence Diagram – Biểu đồ Tuần tự 12

2.2.6 Collaboration Diagram – Biểu đồ cộng tác 13

2.2.7 Component Diagram – Biểu đồ Thành phần 14

2.2.8 Deployment Diagram – Biểu đồ Triển khai 15

Chương 3: Phương pháp hướng đối tượng 17

3.1 Lập trình hướng cấu trúc 17

3.2 Cách tiếp cận hướng đối tượng 17

3.3 Phân tích và Thiết kế hướng đối tượng là gì 18

Chương 4: Quy trình phát triển phần mềm 19

4.1 Mô hình thác nước 19

4.2 Mô hình xoắn ốc 20

4.3 Cơ cấu lặp, tăng dần – Iterative, Incremental Framework 22

4.3.1 Pha khởi đầu – Inception 22

4.3.2 Pha chuẩn bị - Elaboration 22

4.3.3 Pha xây dựng – Construction 22

4.3.4 Pha chuyển giao – Transition 23

4.3.5 Phân bổ thời gian của một dự án tiêu biểu 23

4.4 Microsoft Solution Framework 24

4.5 Rational Unified Process (RUP) 25

Chương 5: Áp dụng UML 29

5.1 Pha khởi đầu (Inception) 29

5.1.1 Khái quát 29

5.1.2 Các sản phẩm(Artifact) có thể bắt đầu trong pha khởi đầu 30

5.1.3 Tìm hiểu yêu cầu(Requirement) 30

5.1.4 Mô hình Use Case: Viết yêu cầu trong ngữ cảnh 31

5.2 Pha chuẩn bị - Vòng lặp 1 33

5.2.1 Mô hình Use Case: Vẽ các Sơ đồ tuần tự hệ thống 33

5.2.2 Mô hình Nghiệp vụ: Hình tượng hóa các Khái niệm 34

5.2.3 Mô hình Nghiệp vụ: Thêm các Liên kết 35

5.2.4 Mô hình Nghiệp vụ: Thêm các Thuộc tính 36

5.2.5 Các biểu đồ tương tác 36

5.2.6 GRASP: Thiết kế các đối tượng cùng các Trách nhiệm 37

5.2.7 Mô hình Thiết kế: Hiện thực hóa Use Case với các khuôn mẫu GRASP 38 5.2.8 Mô hình Thiết kế: Xác định tính khả năng thấy được 39

5.2.9 Mô hình Thiết kế: Tạo ra các Biểu đồ Lớp Thiết kế 40

Chương 6: Áp dụng UML để phân tích thiết kế ứng dụng 41

6.1 PHÁT BIỂU BÀI TOÁN 41

6.2 SƠ ĐỒ TỔNG THỂ NGHIỆP VỤ BÀI TOÁN 43

6.3 SƠ ĐỒ USE CASE 44

6.3.1 Sơ đồ use case Main: 44

6.3.2 Sơ đồ use case Main 2: 45

6.4 CÁC TÁC NHÂN 46

6.4.1 Tác nhân – Cán bộ tiếp nhận 46

6.4.2 Tác nhân – Trưởng phòng 46

6.4.3 Tác nhân – Cán bộ thụ lý 46

6.4.4 Tác nhân – Văn thư lưu trữ 46

6.4.5 Tác nhân – Lãnh đạo 46

6.4.6 Tác nhân – Người quản trị 46

6.5 MÔ TẢ CHI TIẾT CÁC USE CASE 47

6.5.1 Use Case – Tiếp nhận hồ sơ 47

6.5.2 Use Case – Thụ lý 57

6.5.3 Use Case – Phê duyệt 68

6.5.4 Use Case – Trả hồ sơ thu lệ phí 73

6.5.5 Use Case – Quản lý sau cấp phép 77

6.5.6 Use Case – Lập báo cáo 83

6.5.7 Use Case – Tra cứu WEB 87

6.5.8 Use Case – Tiện ích hỗ trợ 89

6.5.9 Use Case – Quản trị hệ thống 98

6.5.10 Use Case – Quản lý các danh mục 103

Kết luận 113

Tài liệu tham khảo 114

Danh mục hình vẽ

Hình 2.1 Ví dụ về biểu đồ Use case 9

Hình 2.2 Ví dụ về biểu đồ lớp 10

Hình 2.3 Ví dụ về biểu đồ trạng thái 11

Hình 2.4 Ví dụ về biểu đồ hoạt động 12

Hình 2.5 Ví dụ về biểu đồ tuần tự 13

Hình 2.6 Ví dụ về biểu đồ cộng tác 14

Hình 2.7 Ví dụ về biểu đồ thành phần 15

Hình 2.8 Ví dụ về biểu đồ triển khai 16

Hình 4.1 Mô hình “Thác nước” truyền thống 19

Hình 4.2 Nguy cơ và chi phí xử lý lỗi trong mô hình “Thác nước” 20

Hình 4.2 Một quy trình “Xoắn ốc” 21

Hình 4.4 Bốn pha của “Cơ cấu lặp, tăng dần” 22

Hình 4.5 Pha “Xây dựng” bao gồm một chuỗi các “Thác nước nhỏ” 23

Hình 4.6 Độ dài mỗi pha cho một dự án dài 2 năm 24

Hình 4.7 Mô hình quy trình MSF 24

Hình 4.8 Các pha và mốc thời gian của mô hình quy trình MSF 25

Hình 4.9 Các discipline trong RUP 27

Hình 4.10 Các Artifact(sản phẩm) và khung thời gian của RUP 28

Hình 5.1 Biểu đồ tuần tự hệ thống cho tình huống xử lý bán hàng 34

Hình 5.2 Một mô hình nghiệp vụ 35

Hình 5.3 Một mô hình nghiệp vụ với các liên kết 36

Hình 5.4 Biểu đồ cộng tác 37

Hình 5.5 Biểu đồ tuần tự 37

Hình 5.6 Biểu đồ tuần tự dùng hiện thực hóa Use Case 39

Hình 5.7 Minh họa khả năng nhìn thấy 40

Hình 5.8 Minh họa biểu đồ lớp thiết kế 40

Bảng thuật ngữ chuyên môn

Artifact Sản phẩm trong quy trình RUP

Association Liên kết

Business Modeling Mô hình hóa tác nghiệp

Class Diagram Biểu đồ lớp

Development Case Một tập hợp các Artifact cho một quy trình phát triển dự án cụ

thể

Domain Model Mô hình nghiệp vụ

GRASP Hình mẫu phần mềm gán trách nhiệm chung

Interaction Diagram Biểu đồ tương tác

Problem Domain Vùng nghiệp vụ

RUP Rational Unified Process - Quy trình phần mềm hợp nhất

Đây là lúc mà UML(Unified Modeling Language – Ngôn ngữ mô hình hóa thống nhất) xuất hiện để giải quyết vấn đề UML là hệ thống ký hiệu chuẩn công nghiệp để mô hình hóa cho các hệ thống hướng đối tượng và là nền tảng cho khả năng phát triển nhanh ứng dụng

Tuy nhiên thực tế cho thấy khả năng sử dụng hiệu quả UML trong phát triển phần mềm là còn rất hạn chế trong các công ty phần mềm ở Việt nam, luận văn này sẽ nghiên cứu và trình bày cách thức sử dụng UML một cách hiệu quả trong các dự án phần mềm

Chương 1: Tổng quan

1.1 Mô tả vấn đề

Công cụ sản xuất phần mềm với sự trợ giúp của máy tính (CASE tool) là một công cụ

sử dụng máy tính để hỗ trợ quy trình phát triển phần mềm, nhờ đó tăng năng suất và giảm thiểu khả năng thất bại của dự án CASE tool có thể là một trình dịch (Compiler)

để tạo ra phần mềm từ mã nguồn Một kiểu khác của CASE tool không tham gia trực tiếp vào việc tạo ra sản phẩm phần mềm Ví dụ như là các công cụ đánh giá và hoạch định, để đánh giá chi phí của dự án phát triển phần mềm và giúp quản lý nguồn lực cho dự án phát triển phần mềm

Phương pháp phát triển phần mềm đưa ra các hạng mục cho quy trình phát triển phần mềm Một phương pháp phát triển phần mềm có thể được hỗ trợ bởi một CASE tool Mục đích của một công cụ như vậy là bao phủ mọi thông tin mà có bất kỳ quan hệ nào với sản phẩm phần mềm Nó cung cấp khả năng quản lý tất cả từ yêu cầu cho đến cấu trúc ứng dụng rồi các mô đun và thành phần của phần mềm cũng như quan hệ giữa chúng Mô hình này của sản phẩm phần mềm giúp ta hiểu được quan hệ giữa yêu cầu

và kiến trúc của ứng dụng vì thế nó rất hữu dụng khi có yêu cầu thay đổi sản phẩm Thông thường các ký hiệu đồ họa được sử dụng để biểu diễn mô hình này, vì nó dễ đọc hơn đối với mọi người Trong quá khứ người ta đã sử dụng nhiều ngôn ngữ hình tượng để biểu diễn một mô hình sản phẩm phần mềm Hiện nay Ngôn ngữ Mô hình hóa Hợp nhất (UML) là ngôn ngữ hình tượng chuẩn cho mục đích này UML định nghĩa làm thế nào để mô tả một đối tượng phần mềm trừu tượng Có nghĩa là UML độc lập với ngôn ngữ và môi trường lập trình và nó có thể mô tả kiến trúc phần mềm

mà ta có thể triển khai trên mọi môi trường phát triển

Phát triển phần mềm dựa trên phương pháp hướng đối tượng, có ưu thế vượt trội so với phương pháp hướng cấu trúc, đã ra đời để đáp ứng các bài toán lớn và phức tạp

Và UML là ngôn ngữ phù hợp nhất dành cho phân tích và thiết kế hướng đối tượng Việc áp dụng hiệu quả UML vào quá trình phát triển phần mềm sẽ đem lại lợi ích lớn cho các dự án phần mềm Để áp dụng hiệu quả UML chúng ta cần hiểu rõ về nó, cách thức áp dụng nó và các công cụ hỗ trợ liên quan

1.2 Mục tiêu

Đồ án có những mục tiêu sau:

 Nghiên cứu và trình bày vai trò của UML trong công nghệ phần mềm

 Nghiên cứu và trình bày các Quy trình phát triển phần mềm tiêu biểu

 Trình bày phương pháp ứng dụng UML trong phân tích thiết kế

 Áp dụng UML trong phân tích thiết kế một ứng dụng hệ thông tin quản lý cụ

thể: “Chương trình quản lý cấp phép xây dựng”

Chương 2: Ngôn ngữ mô hình hóa thống nhất UML

ra các phần của mã chương trình từ các sơ đồ này

2.2 Các biểu đồ của UML

UML 2.0 có tất cả 13 biểu đồ chia làm 3 loại: Có 6 biểu đồ là biểu đồ cấu trúc, 3 biểu

đồ hành vi và 4 biểu đồ tương tác thể hiện trong sơ đồ khối dưới đây

Sau đây chúng ta sẽ xem xét 7 biểu đồ chính của UML

2.2.1 Use Case Diagram – Biểu đồ Use Case

Khái niệm tác nhân: là những người, hệ thống khác ở bên ngoài phạm vi của hệ thống

Một ví dụ về biểu đồ Use case trong hình 2.1 Trong biểu đồ này một tác nhân

Salesperson được gán cho một use case Place Order Use case này bao gồm 3 use

cases Supply Customer Data, Order Product và Arrange Payment

Supply Customer Data Order Product

Một hệ thống thường sẽ có một loạt các biểu đồ lớp – chẳng phải bao giờ tất cả các biểu đồ lớp này cũng được nhập vào một biểu đồ lớp tổng thể duy nhất – và một lớp có thể tham gia vào nhiều biểu đồ lớp

Một ví dụ về biểu đồ lớp ở trong hình 2.2

Hình 2.2 Ví dụ về biểu đồ lớp 2.2.3 Statechart Diagram – Biểu đồ Trạng thái

Một biểu đồ trạng thái thường là một sự bổ sung cho lời miêu tả một lớp Nó chỉ ra tất

cả các trạng thái mà đối tượng của lớp này có thể có, và những sự kiện (event) nào sẽ gây ra sự thay đổi trạng thái Một sự kiện có thể xảy ra khi một đối tượng tự gửi thông điệp đến cho nó - ví dụ như để thông báo rằng một khoảng thời gian được xác định đã qua đi – hay là một số điều kiện nào đó đã được thỏa mãn Một sự thay đổi trạng thái

được gọi là một sự chuyển đổi trạng thái (State Transition) Một chuyển đổi trạng thái

cũng có thể có một hành động liên quan, xác định điều gì phải được thực hiện khi sự chuyển đổi trạng thái này diễn ra

Biểu đồ trạng thái không được vẽ cho tất cả các lớp, mà chỉ riêng cho những lớp có một số lượng các trạng thái được định nghĩa rõ ràng và hành vi của lớp bị ảnh hưởng

và thay đổi qua các trạng thái khác nhau Biểu đồ trạng thái cũng có thể được vẽ cho

hệ thống tổng thể

Một ví dụ về biểu đồ trạng thái ở hình 2.3 Biểu đồ này chỉ ra trạng thái của một đơn đặt hàng

Checking do/ check item

Dispatching do/ initiate delivery

Waiting

Delivered

/ get first item

[ not all items checked ] / get next item

item received[ some items not in stock ]

[ all items checked and some items not in stock ]

[ all items checked and

all items available ]

item received [ all items available ]

delivered

Hình 2.3 Ví dụ về biểu đồ trạng thái 2.2.4 Activity Diagram – Biểu đồ hoạt động

Một biểu đồ hoạt động chỉ ra một trình tự lần lượt của các hoạt động (activity) Biểu

đồ hoạt động thường được sử dụng để miêu tả các hoạt động được thực hiện trong một thủ tục, mặc dù nó cũng có thể được sử dụng để miêu tả các dòng chảy hoạt động khác, ví dụ như trong một Use case hay trong một trình tự tương tác Biểu đồ hoạt động bao gồm các trạng thái hành động, chứa đặc tả của một hoạt động cần phải được thực hiện (một hành động - action) Một trạng thái hành động sẽ qua đi khi hành động được thực hiện xong (khác với biểu đồ trạng thái: một trạng thái chỉ chuyển sang trạng thái khác sau khi đã xảy ra một sự kiện rõ ràng !) Dòng điều khiển ở đây chạy giữa các trạng thái hành động liên kết với nhau Biểu đồ còn có thể chỉ ra các quyết định, các điều kiện, cũng như phần thực thi song song của các trạng thái hành động Biểu đồ ngoài ra còn có thể chứa các loại đặc tả cho các thông điệp được gửi đi hoặc được nhận về, trong tư cách là thành phần của hành động được thực hiện

Một ví dụ về biểu đồ hoạt động ở trong hình 2.4 Biểu đồ này biểu diễn hoạt động chuẩn bị của một đồ uống

Find Beverage

Put Coffee in

Filter

Add Water to Reservoir

Get Cups

Put Filter in

Machine

Turn on Machine

Brew Coffee

Pour Coffee Drink

Get Cans of Cola [ found coffee ]

/ coffeePot.turnOn

[ no coffee ]

[ found cola ] [ no cola ]

light goes out

Hình 2.4 Ví dụ về biểu đồ hoạt động 2.2.5 Sequence Diagram – Biểu đồ Tuần tự

Một biểu đồ trình tự chỉ ra một cộng tác động giữa một loạt các đối tượng Khía cạnh quan trọng của biểu đồ này là chỉ ra trình tự các thông điệp (message) được gửi giữa các đối tượng Nó cũng chỉ ra trình tự tương tác giữa các đối tượng, điều sẽ xảy ra tại một thời điểm cụ thể nào đó trong trình tự thực thi của hệ thống Các biểu đồ trình tự chứa một loạt các đối tượng được biểu diễn bằng các đường thẳng đứng Trục thời gian có hướng từ trên xuống dưới trong biểu đồ, và biểu đồ chỉ ra sự trao đổi thông điệp giữa các đối tượng khi thời gian trôi qua Các thông điệp được biểu diễn bằng các đường gạch ngang gắn liền với mũi tên (biểu thị thông điệp) nối liền giữa những đường thẳng đứng thể hiện đối tượng Trục thời gian cùng những lời nhận xét khác thường sẽ được đưa vào phần lề của biểu đồ

Một ví dụ về biểu đồ tuần tự ở trong hình 2.5

caller exchange receiver

1: lift receiver 2: dial tone 3: dial digit

4: route 6: ringing tone 5: phone rings

7: answer phone 8: stop ringing 9: stop tone

Hình 2.5 Ví dụ về biểu đồ tuần tự 2.2.6 Collaboration Diagram – Biểu đồ cộng tác

Một biểu đồ cộng tác chỉ ra một sự cộng tác động, cũng giống như một biểu đồ trình

tự Thường người ta sẽ chọn hoặc dùng biểu đồ trình tự hoặc dùng biểu đồ cộng tác

Bên cạnh việc thể hiện sự trao đổi thông điệp (được gọi là tương tác), biểu đồ cộng tác

chỉ ra các đối tượng và quan hệ của chúng (nhiều khi được gọi là ngữ cảnh) Việc nên

sử dụng biểu đồ trình tự hay biểu đồ cộng tác thường sẽ được quyết định theo nguyên tắc chung sau: Nếu thời gian hay trình tự là yếu tố quan trọng nhất cần phải nhấn mạnh thì hãy chọn biểu đồ trình tự; nếu ngữ cảnh là yếu tố quan trọng hơn, hãy chọn biểu đồ cộng tác Trình tự tương tác giữa các đối tượng được thể hiện trong cả hai loại biểu đồ này

Biểu đồ cộng tác được vẽ theo dạng một biểu đồ đối tượng, nơi một loạt các đối tượng được chỉ ra cùng với mối quan hệ giữa chúng với nhau (sử dụng những ký hiệu như trong biểu đồ lớp/ biểu đồ đối tượng) Các mũi tên được vẽ giữa các đối tượng để chỉ

ra dòng chảy thông điệp giữa các đối tượng Các thông điệp thường được đính kèm theo các nhãn (label), một trong những chức năng của nhãn là chỉ ra thứ tự mà các thông điệp được gửi đi Nó cũng có thể chỉ ra các điều kiện, chỉ ra những giá trị được trả về, v.v Khi đã làm quen với cách viết nhãn, một nhà phát triển có thể đọc biểu đồ cộng tác và tuân thủ theo dòng thực thi cũng như sự trao đổi thông điệp Một biểu đồ cộng tác cũng có thể chứa cả các đối tượng tích cực (active objects), hoạt động song song với các đối tượng tích cực khác

Một ví dụ về biểu đồ cộng tác ở trong hình 2.6 Biểu đồ này biểu diễn sự cộng tác khi một đơn đặt hàng được thực hiện

: Order Entry Window

: Order

Macallan line : Order Line

: Stock Item

: Reorder Item : Delivery

Item

5: needToReorder() 1: prepare()

2: prepare()

3: check() 4: [check = true] remove()

Hình 2.6 Ví dụ về biểu đồ cộng tác 2.2.7 Component Diagram – Biểu đồ Thành phần

Một biểu đồ thành phần chỉ ra cấu trúc vật lý của các dòng lệnh (code) theo khái niệm thành phần code Một thành phần code có thể là một tập tin source code, một thành phần nhị phân (binary) hay một thành phần thực thi được (executable) Một thành phần chứa các thông tin về các lớp logic hoặc các lớp mà nó thi hành, như thế có nghĩa

là nó tạo ra một ánh xạ từ hướng nhìn logic vào hướng nhìn thành phần Biểu đồ thành phần cũng chỉ ra những sự phụ thuộc giữa các thành phần với nhau, trợ giúp cho công việc phân tích hiệu ứng mà một thành phần được thay đổi sẽ gây ra đối với các thành phần khác Thành phần cũng có thể được miêu tả với bất kỳ loại giao diện nào mà chúng bộc lộ, ví dụ như giao diện OLE/COM; và chúng có thể được nhóm góp lại với nhau thành từng gói (package) Biểu đồ thành phần được sử dụng trong công việc lập trình cụ thể

Hình 2.7 Ví dụ về biểu đồ thành phần

2.2.8 Deployment Diagram – Biểu đồ Triển khai

Biểu đồ triển khai chỉ ra kiến trúc vật lý của phần cứng cũng như phần mềm trong hệ thống Bạn có thể chỉ ra từng máy tính cụ thể và từng trang thiết bị cụ thể (node) đi kèm sự nối kết giữa chúng với nhau, bạn cũng có thể chỉ ra loại của các mối nối kết

đó Bên trong các nút mạng (node), các thành phần thực thi được cũng như các đối tượng sẽ được xác định vị trí để chỉ ra những phần mềm nào sẽ được thực thi tại những nút mạng nào Bạn cũng có thể chỉ ra sự phụ thuộc giữa các thành phần

Biểu đồ triển khai chỉ ra hướng nhìn triển khai, miêu tả kiến trúc vật lý thật sự của hệ thống Đây là một hướng nhìn rất xa lối miêu tả duy chức năng của hướng nhìn Use case Mặc dù vậy, trong một mô hình tốt, người ta có thể chỉ tất cả những con đường dẫn từ một nút mạng trong một kiến trúc vật lý cho tới những thành phần của nó, cho tới lớp mà nó thực thi, cho tới những tương tác mà các đối tượng của lớp này tham gia

để rồi cuối cùng, tiến tới một Use case Rất nhiều hướng nhìn khác nhau của hệ thống được sử dụng đồng thời để tạo ra một lời miêu tả thấu đáo đối với hệ thống trong sự tổng thể của nó

Hình 2.8 Ví dụ về biểu đồ triển khai

Chương 3: Phương pháp hướng đối tượng

Trong phần này chúng ta sẽ xem xét khái niệm hướng đối tượng UML đã được thiết

kế để hỗ trợ hướng đối tượng, và trước khi đi sâu vào việc áp dụng UML sẽ hữu ích khi chúng ta tìm hiểu các lợi ích mà hướng đối tượng đem lại cho phát triển phần mềm

3.1 Lập trình hướng cấu trúc

Trước hết chúng ta hãy xem xét các hệ thống phần mềm được thiết kế như thế nào sử dụng cách tiếp cận hướng cấu trúc (hay đôi khi còn gọi là hướng chức năng)

Trong lập trình hướng cấu trúc, phướng pháp chung là xem xét vấn đề, rồi sau đó thiết

kế một tập hợp các hàm thực thi các nhiệm vụ được yêu cầu Nếu như các hàm này quá lớn thì chúng được chia nhỏ tới khi đủ để có thể hiểu và điều khiển Quá trình này gọi là phân dã chức năng

Vấn đề đối với cách tiếp cận này đó là nếu bài toán mà chúng ta đang giải quyết trở nên quá phức tạp thì việc bảo trì phần mềm cũng trở nên vô cùng khó khăn

3.2 Cách tiếp cận hướng đối tượng

Phương pháp hướng đối tượng giảm thiểu ảnh hưởng của vấn đề bằng cách đơn giản

đó là tổ hợp các chức năng và dữ liệu liên quan vào cùng một mô đun

Có vài điểm đáng chú ý với hệ thống mới này như sau:

 Khi chương trình chạy thì có thể tồn tại nhiều thực thể của cùng một mô đun Mỗi thực thể sẽ có giá trị dữ liệu của riêng nó và tất nhiên là chúng có những cái tên khác nhau

 Mô đun thì có thể nói chuyện với các mô đun khác bằng cách gọi các hàm của nhau

Khái niệm đóng gói (Encapsulation): Các thực thể là chủ nhân của một mục dữ liệu thì mới được phép sửa hay đọc nó Khái niệm này gọi là đóng gói, nó làm cho cấu trúc của hệ thống bền vững hơn và tránh được các nhược điểm của hệ thống hướng cấu trúc khi một thay đổi nhỏ tới thành viên dữ liệu sẽ dẫn tới sự thay đổi liên hoàn Với khái niệm đóng gói thì ảnh hưởng của sự thay đổi dữ liệu được cô lập trong phạm vi một

mô đun mà thôi

Một điểm yếu của Hướng đối tượng trong quá khứ đó là nó rất mạnh khi làm việc ở mức lớp và đối tượng nhưng lại rất tồi khi biểu diễn hành vi của toàn bộ hệ thống Phương pháp tiếp cận hiện đại được hỗ trợ bởi UML đó là không quan tâm tới đối các đối tượng và các lớp vào giai đoạn đầu của dự án, thay vào đó là tập trung vào việc hệ thống phải làm được cái gì Sau đó, khi dự án tiến triển thì các lớp dần dần được dây dựng để thực hiện các chức năng hệ thống được yêu cầu

3.3 Phân tích và Thiết kế hướng đối tượng là gì

Trong phân tích hướng đối tượng, người ta chú trọng vào việc tìm kiếm và mô tả các đối tượng hoặc khái niệm trong problem domain(vùng vấn đề) Ví dụ trong trường hợp

hệ thống thư viện có một số khái niệm bao gồm: Sách, Thư viện và Người mượn Trong thiết kế hướng đối tượng, người ta chú trọng vào việc định nghĩa các đối tượng phần mềm và việc chúng cộng tác thế nào để đáp ứng các yêu cầu Ví dụ trong hệ thống thư viện thì Đối tượng phần mềm Sách có thể có thuộc tính Tiêu đề và thương thức getChapter()

Chương 4: Quy trình phát triển phần mềm

Khi phát triển UML các tác giả đã quyết định rõ ràng là phải loại bỏ mọi vấn đề liên quan tới quy trình ra khỏi ngôn ngữ này, lý do là vì các quy trình thường hay mâu thuẫn, một quy trình có thể đúng với công ty A nhưng sẽ là thảm họa với công ty B Vì vậy UML là một ngôn ngữ rộng và chung tạo khả năng để các khía cạnh chính của phát triển phần mềm có thể được mô tả trên ”giấy”

Nói cách khác UML chỉ là đơn giản là một ngôn ngữ, một ký hiệu, một cú pháp và quan trọng là nó không nói cho chúng ta phát triển phần mềm như thế nào

Để học cách sử dụng UML một cách hiệu quả, chúng ta sẽ theo một quy trình đơn giản, và cố gắng hiểu UML sẽ giúp được gì trong mỗi giai đoạn Nhưng trước hết chúng ta hãy xem xét ưu nhược vài quy trình phần mềm cơ bản

 Ngay cả các hệ thống lớn cũng phải được hiểu đầy đủ trước khi có thể tiến tới giai đoạn thiết kế Độ phức tạp tăng lên và trở nên quá sức đối với các lập trình viên

 Mạo hiểm tăng Các vấn đề lớn thường phát sinh ở giai đoạn sau của quá trình, đặc biệt là lúc tích hợp hệ thống Và chi phí để xử lý lỗi tăng hàm số mũ với trục thời gian

 Với các dự án lớn thì mỗi pha sẽ trải qua các giai đoạn rất dài Một pha kiểm thử dài 2 năm không phải là phương pháp để giữ nhân viên

Hình 4.2 Nguy cơ và chi phí xử lý lỗi trong mô hình “Thác nước”

4.2 Mô hình xoắn ốc

Một phương pháp tiếp cận khác đó là mô hình xoắn ốc Trong cách tiếp cận này chúng

ta thực hiện dự án theo một loạt các chu kỳ ngắn, mỗi chu kỳ kết thúc với một phiên bản phần mềm có thể thực hiện

Hình 4.3 Một quy trình “Xoắn ốc”

Ưu điểm của phương pháp này là:

 Đội phát triển có thể làm việc hết cả chu trình(Phân tích, thiết kế, lập trình và kiểm thử) chứ không phải tiêu tốn cả năm trời chỉ cho một hoạt động

 Chúng ta nhận được phản hồi sớm của khách hàng một cách đều đặn, và có thể phát hiện các vấn đề tiềm tàng trước khi đi quá xa

 Loại bỏ nguy cơ Các vòng lặp đặc biệt mạo hiểm có thể được phát triển trước

 Quy mô và độ phức tạp của công việc có thể được phát hiện sớm hơn

 Những thay đổi trong công nghệ có thể được kết hợp dễ dàng hơn

 Các phiên bản phần mềm thường xuyên sẽ cải thiện tinh thần làm việc

 Trạng thái của dự án có thể được xác định chính xác hơn

Nhược điểm của quy trình xoắn ốc là:

 Quy trình thường được gắn với “Rapid Application Development” (Phát triển ứng dụng thần tốc) cái được nhiều người xem là hiến chương của tin tặc

 Quy trình rất khó để quản lý Trong khi mô hình thác nước phù hợp với các kỹ thuật quản lý dự án cổ điển như sơ đồ Gantt, thì quy trình xoắn ốc đỏi hỏi cách tiếp cận khác

Để khắc phục các nhược điểm của mô hình xoắn ốc, chúng ta hãy xem xét một cách tiếp cận tương tự nhưng chính thống hơn, đó là Cơ cấu lặp tăng dần

4.3 Cơ cấu lặp, tăng dần – Iterative, Incremental Framework

Cơ cấu lặp, tăng dần là một mở rộng logic đối với mô hình xoắn ốc Cơ cấu này được chia thành 4 pha chính: Inception(Khởi đầu), Elaboration(Chuẩn bị), Construction (Xây dựng) và Transition(Chuyển giao) Các pha này được thực hiện tuần tự nhưng chúng ta không được lầm lẫn với các giai đoạn của mô hình thác nước

Hình 4.4 Bốn pha của “Cơ cấu lặp, tăng dần”

4.3.1 Pha khởi đầu – Inception

Pha khởi đầu được quan tâm vơi việc thiết lập phạm vi dự án và định nghĩa tầm nhìn cho dự án Với dự án nhỏ thì có thể chỉ là cuộc nói chuyện tại quán cà phê với sự cam kết tiến hành, trong các dự án lớn hơn thì cần có một “Khởi đầu” kỹ lưỡng hơn Các sản phẩm có thể của pha này bao gồm:

 Một tài liệu về tầm nhìn

 Một thăm dò ban đầu về các yêu cầu của khách hàng

 Một bảng chú giải thuật ngữ liên quan trong dự án

 Một bản phân tích đầu tư(Bao gồm tiêu chí thành công và một dự báo về tài chính, tính toán hiệu quả đầu tư)

 Một phân tích ban đầu về rủi ro

 Một kế hoạch dự án

4.3.2 Pha chuẩn bị - Elaboration

Mục đích của pha này là phân tích vấn đề, phát triển tiếp kế hoạch dự án và loại trừ các vùng rủi ro hơn của dự án Đến cuối của pha Chuẩn bị chúng ta cần có hiểu biết chung về toàn bộ dự án cho dù không cần thiết phải hiểu kỹ lưỡng

Hai mô hình UML rất có giá trị trong giai đoạn này đó là mô hình Use case giúp chúng

ta hiểu yêu cầu khách hàng và Biểu đồ lớp để xem xét các khái niệm chính mà khách hàng hiểu

4.3.3 Pha xây dựng – Construction

Trong pha này chúng ta xây dựng sản phẩm giống như cách trong mô hình xoắn ốc, bằng cách đi theo một chuỗi các chu kỳ lặp Mỗi chu kỳ lặp là một mô hình thác nước đơn giản Bằng cách giữ cho mỗi chu kỳ lặp càng ngắn càng tốt chúng ta sẽ tránh được các nhược điểm của mô hình thác nước

Hình 4.5 Pha “Xây dựng” bao gồm một chuỗi các “Thác nước nhỏ”

4.3.4 Pha chuyển giao – Transition

Pha cuối cùng được quan tâm với việc chuyển sản phẩm cuối cùng cho khách hàng Các hoạt động trong pha này bao gồm:

 Phiên bản bêta để kiểm thử bởi cộng đồng người dùng

 Kiểm thử nhà máy, hay chạy sản phẩm song song với hệ thống hiện tại mà sản phẩm sẽ thay thế

 Chuyển đổi dữ liệu(Cải tạo cơ sở dữ liệu hiện tại sang định dạng mới)

 Đào tạo người sử dụng mới

 Marketing, phân phối và bán hàng

Pha chuyển giao không nên nhầm lẫn với pha kiểm thử truyền thống tại cuối kỳ của

mô hình thác nước Vào thời kỳ đầu của pha chuyển giao thì một sản phẩm chạy tốt, đầy đủ và đã qua kiểm thử phải sẵn sàng cho người sử dụng

4.3.5 Phân bổ thời gian của một dự án tiêu biểu

Mỗi trong bốn pha trên nên kéo dài bao lâu? Điều này hoàn toàn phụ thuộc vào từng

dự án, tuy nhiên có một hướng dẫn sơ bộ như sau:

Hình 4.6 Độ dài mỗi pha cho một dự án dài 2 năm

4.4 Microsoft Solution Framework

Mô hình MSF mô tả một tuần tự được tổng quát hóa các hoạt động để xây dựng và triển khai các giải pháp doanh nghiệp Quy trình này mềm dẻo và có thể thích hợp với thiết kế và phát triển một dải rộng các dự án doanh nghiệp Quy trình MFS dựa trên các pha, các mốc hoàn thành và là mô hình chu kỳ lặp, nó có thể áp dụng để phát triển

và triển khai các ứng dụng truyền thống, các giải pháp doanh nghiệp cho thương mại điện tử, và các ứng dụng Web phân tán

Mô hình quy trình MSF tổ hợp các nguyên lý tốt nhất của các mô hình thác nước và xoắn ốc Nó tổ hợp nguyên lý hoạch địch dựa trên mốc thời gian của mô hình thác nước và khả năng dự đoán trước với ưu điểm về phản hồi và sáng tạo của mô hình xoắn ốc

Hình 4.7 Mô hình quy trình MSF

Mô hình quy trình MSF bao gồm 5 pha riêng biệt, mỗi pha kết thúc tại một mốc thời gian (Milestone)

 Envisioning (Hình tượng hóa)

 Planning (Hoạch định)

 Developing (Phát triển)

 Stabilizing (Ổn định hóa)

 Deploying (Triển khai)

Hình 4.8 Các pha và mốc thời gian của mô hình quy trình MSF

4.5 Rational Unified Process (RUP)

RUP là một trường hợp được biết đến nhiều nhất của cơ cấu chu kỳ lặp tăng dần hiện đang được sử dụng RUP được phát triển bởi cùng tác giả đã phát triển UML bởi vậy

nó là thành phần bổ sung cho UML RUP là một cách thức để sử dụng hiệu quả ngôn ngữ UML

RUP là một quy trình có thể cấu hình tùy biến vì không một quy trình đơn lẻ nào tương thích với mọi dự án phát triển phần mềm RUP thích hợp với đội phát triển nhỏ cũng như tổ chức phát triển lớn, nó có thể biến đổi để phù hợp với nhiều tình huống khác nhau

RUP chứa đựng nhiều kinh nghiệm trong phát triển phần mềm hiện đại, thích thích hợp với nhiều mô hình dự án và tổ chức Nhờ tích hợp những kinh nghiệm này mà khi

sử dụng RUP, đội phát triển sẽ tận dụng được nhiều lợi thế Sau đây là sáu kinh nghiệm của RUP trong phát triển phần mềm:

 Phát triển phần mềm theo chu kỳ lặp

 Quản lý các yêu cầu

 Sử dụng các kiến trúc dựa trên thành phần (component-based)

 Mô hình hóa phần mềm bằng hình tượng

 Xác nhận chất lượng phần mềm

 Kiểm soát thay đổi của phần mềm

Một dự án tuân theo quy trình RUP tổ chức công việc và các chu trình lặp qua bốn pha chính như sau:

1 Inception(Khởi đầu): Nhận thức khái quát, tình huống công việc (business case), phạm vi, các đánh giá sơ bộ

2 Elaboration(Sửa soạn): vi chỉnh nhận thức, thực hiện triển khai các kiến trúc cơ bản, giải quyết các vấn đề mạo hiểm cao, xác định hầu hết các yêu cầu và phạm

vi theo chu kỳ lặp, đánh giá chính xác hơn

3 Construction(Xây dựng): Xây dựng các phần tử dễ và ít mạo hiểm hơn theo chu

kỳ lặp, chuẩn bị cho việc triển khai áp dụng

4 Transition(Chuyển đổi): Kiểm thử bê ta, triển khai áp dụng

Quy trình RUP mô tả các hoạt động công việc(Vd: viết use case) trong các discipline

(Hồi đầu gọi là workflow), một cách không chính thức thì discipline là tập hợp các hoạt động(Và các artifact liên quan) trong một khu vực nào đó, chẳng hạn các hoạt động trong phân tích yêu cầu Trong RUP thì artifact là từ để chỉ các sản phẩm công việc như: mã nguồn, đồ họa web, csdl, tài liệu, sơ đồ, mô hình.v.v

Có rất nhiều Discipline trong RUP nhưng chúng ta sẽ tập trung vào các artifact trong

ba Discipline sau đây:

1 Business Modeling: Mô hình hóa các đối tượng nghiệp vụ

2 Requirements: phân tích yêu cầu cho ứng dụng, chẳng hạn viết use case và xác định các yêu cầu phi chức năng

3 Design: Mọi khía cạnh của thiết kế, bao gồm kiến trúc tổng thể, các đối tượng, csdl, mạng và các vấn đề khác

Hình 4.9 Các discipline trong RUP

Chú ý rằng mặc dù một chu kỳ lặp bao gồm công việc của hầu hết tất cả các discipline nhưng mức độ và khối lượng là khác nhau qua các chu kỳ lặp

Chúng ta sẽ tập trung nghiên cứu pha Inception và Elaboration, đông thời tập trung vào các Artifact trong các discipline: Business Modeling, Requirement và Design vì đây là chỗ mà phân tích yêu cầu, thiết kế hướng đối tượng, pattern(khuôn mẫu), và UML được áp dụng

Hình 4.10 Các Artifact(sản phẩm) và khung thời gian của RUP

Chương 5: Áp dụng UML

Chúng ta sẽ nghiên cứu việc áp dụng UML vào phân tích thiết kế phần mềm trong các pha phát triển như sau:

1 Pha Khởi đầu(Inception): Giới thiệu các vấn đề căn bản của phân tích yêu cầu

2 Pha Chuẩn bị - Vòng lặp 1: Giới thiệu phân tích thiết kế hướng đối tượng căn bản và làm thế nào gán trách nhiệm cho các đối tượng

3 Pha Chuẩn bị - Vòng lặp 2: tập trung vào thiết kế đối tượng, đặc biệt giới thiệu những khuôn mẫu thiết kế hay dùng(Design patterns)

4 Pha Chuẩn bị - Vòng lặp 3: Giới thiệu nhiều chủ đề như phân tích kiến trúc và thiết kế cơ cấu khung

Một hệ thống thông tin hướng đối tượng tiêu biểu được thiết kế theo nhiều lớp kiến trúc hoặc hệ thống con Ví dụ các lớp sau đây:

- Giao diện người dùng: Giao diện đồ họa, cửa sổ

- Logic ứng dụng và các đối tượng nghiệp vụ(domain objects): Các đối tượng

phần mềm biểu diễn các khái niệm nghiệp vụ mà đáp ứng các yêu cầu ứng dụng

- Các dịch vụ kỹ thuật: Các đối tượng và hệ thống con đáp ứng mục đích chung,

cung cấp các dịch vụ kỹ thuật hỗ trợ như giao tiếp với cơ sở dữ liệu hoặc ghi nhớ lỗi Các dịch vụ này thường là độc lập với ứng dụng và có thể sử dụng lại qua nhiều hệ thống

Phân tích thiết kế hướng đối tượng thường thích hợp nhất cho mô hình hóa các lớp logic ứng dụng và dịch vụ kỹ thuật

5.1 Pha khởi đầu (Inception)

5.1.1 Khái quát

Hầu hết các dự án cần có một bước khởi đầu ngắn, trong đó các câu hỏi sau đây được tìm hiểu:

- Nghiệp vụ cũng như bức tranh tổng thể của dự án là gì?

- Có khả thi hay không?

- Sẽ mua sản phẩm hay tự xây dựng?

- Chi phí sơ bộ cho dự án là bao nhiêu?

- Chúng ta nên tiếp tục hay dừng lại?

Để xác đinh bức tranh tổng thể cũng như đánh giá chi phí sơ bộ thì chúng ta cần phải thực hiện tìm hiểu yêu cầu Tuy nhiên mục đích của pha Khởi đầu này không phải là

để xác định tất cả các yêu cầu, hay tạo ra các đánh giá chi phí và kế hoạch dự án một cách chính xác mà ý tưởng ở đây chỉ là thực hiện điều tra đủ để hình thành những ý kiến hợp lý về mục đích tổng thể và tính khả thi của một hệ thống mới, và quyết định

nó có đáng để đầu tư xem xét sâu hơn không

Với mục đích của pha Khởi đầu như trên ngoài sơ đồ Use Case đơn giản không xuất hiện các sơ đồ khác của UML, hầu hết các sơ đồ UML sẽ xuất hiện trong pha tiếp theo

là pha Chuẩn bị(Elaboration)

5.1.2 Các sản phẩm(Artifact) có thể bắt đầu trong pha khởi đầu

- Bức tranh tổng thể và tình huống nghiệp vụ(Vision and Business Case): Mô tả các mục tiêu, ràng buộc mức cao, mô tả các tình huống nghiệp vụ

- Mô hình Use-Case: Mô tả các yêu cầu chức năng và yêu cầu phi chức năng

- Bảng đặc tính phụ: Mô tả các yêu cầu khác

- Bảng thuật ngữ: Các thuật ngữ nghiệp vụ chính

- Danh sách các nguy cơ và kế hoạch quản lý mạo hiểm: Mô tả các mạo hiểm về kinh doanh, kỹ thuật, nguồn lực, lịch trình và các ý kiến để giảm thiểu nguy cơ cũng như kế hoạch hành động khi tình huống mạo hiểm xảy ra

- Nguyên mẫu và bằng chứng của các khái niệm: Làm rõ bức tranh tổng thể và xác nhận lại các sáng kiến kỹ thuật

- Kế hoạch pha và kế hoạch phát triển phần mềm: Dự đoán sơ bộ về thời gian và nguồn lực cần thiết cho pha Chuẩn bị(Elaboration) Các công cụ, con người, đào tạo và các nguồn lực khác

- Tình huống phát triển(Development Case): Mô tả các bước và sản phẩm(artifact) trong quy trình RUP được thiết lập tùy biến cho dự án

5.1.3 Tìm hiểu yêu cầu(Requirement)

Yêu cầu là những năng lực và điều kiện mà hệ thống hay nói rộng hơn là dự án phải đáp ứng Một trong những thử thách chính của công việc tìm hiểu yêu cầu đó là tìm ra, giao tiếp và ghi nhớ những thứ thực sự cần thiết theo một định dạng mà khách hàng và thành viên của đội phát triển có thể hiểu một cách rõ ràng

Trong quy trình phần mềm RUP, các yêu cầu được phân loại dựa trên mô hình FURPS+, nó có nghĩa như sau:

- Funtional(Chức năng): Các đặc điểm, các khả năng và tính an toàn

- Usability(Khả năng dễ sử dụng): Các nhân tố con người, trợ giúp, tài liệu

- Reliability(Tính tin cậy): Tần suất gặp lỗi, khả năng phục hồi, khả năng dự đoán

- Performance(Hiệu năng): Thời gian đáp ứng, năng lực chịu tải, độ chính xác, tính sẵn sàng, sử dụng tài nguyên

- Supportibility(Khả năng hỗ trợ): Khả năng thích ứng, khả năng duy trì, khả năng quốc tế hóa và khả năng cấu hình

Dấu + trong FURPS+ chỉ một số nhân tố con, phụ thuộc như sau:

- Implementation(Thực hiện): Hạn chế tài nguyên, các ngôn ngữ, công cụ, phần cứng

- Interface(Giao diện): Những ràng buộc liên quan tới giao tiếp với hệ thống bên ngoài

- Operations(Điều hành): Quản lý hệ thống trong thiết lập hoạt động của nó

- Packaging(Đóng gói)

- Legal(Hợp pháp): Giấy phép

Sử dụng mô hình FURPS+ như là một danh sách kiểm tra cho việc tìm hiểu yêu cầu rất hữu dụng để có thể giảm thiểu nguy cơ bỏ sót những vấn đề quan trọng của hệ thống

Trong sử dụng thông thường, các yêu cầu thường được phân loại thành Yêu cầu chức năng và Yêu cầu phi chức năng

Các yêu cầu chức năng được tìm hiểu và ghi nhớ trong Mô hình Use Case và trong danh sách đặc tính của Vision artifact(Bức tranh tổng thể)

Các yêu cầu khác có thể được ghi nhớ trong các Use Case liên quan tới nó hoặc trong bảng đặc tính phụ

5.1.4 Mô hình Use Case: Viết yêu cầu trong ngữ cảnh

Các Use Case được sử dụng rộng rãi để tìm ra và ghi nhớ các yêu cầu(Đặc biệt là các yêu cầu chức năng) Viết các Use Case là một kỹ thuật rất tốt để hiểu và mô tả các yêu cầu Quy trình RUP định nghĩa Mô hình Use Case trong Requirement Discipline, về

cơ bản đây là một tập hợp các Use Case, hoặc một mô hình các chức năng và môi trường của hệ thống

Use Case là các tài liệu dạng mô tả bằng lời, không phải các sơ đồ và công việc mô hình hóa Use Case về cơ bản là hành động viết chứ không phải vẽ Tuy nhiên UML định nghĩa ra sơ đồ Use Case để minh họa tên của các Use Case và các Actor cũng như quan hệ giữa chúng

Use Case là một tập hợp các tình huống thành công hoặc thất bại có liên hệ với nhau

mà mô tả các tác nhân sử dụng hệ thống để hỗ trợ một mục tiêu cụ thể

Các loại và các định dạng Use Case

Use Case hộp đen là loại thông dụng và được khuyên dùng nhất, nó không mô tả hoạt động bên trong của hệ thống cũng như các thành phần hoặc thiết kế, mà ngược lại hệ thống được mô tả là có trách nhiệm gì, một hình thức của tư duy hướng đối tượng Bằng cách định nghĩa trách nhiệm của hệ thống với các Use Case hộp đen chúng ta có thể xác định hệ thống phải làm gì(Các yêu cầu chức năng) mà không phải quyết định

nó sẽ làm như thế nào(Thiết kế) Trong phân tích yêu cầu cần tránh đưa ra các quyết định “như thế nào” và chỉ xác định hành xử bên ngoài của hệ thống như là một hộp đen Sau này, trong giai đoạn thiết kế sẽ tạo ra các giải pháp đáp ứng các đặc tính yêu cầu

Tùy vào nhu cầu Use Case có thể được viết theo nhiều định dạng:

- Vắn tắt: Một đoạn tổng kết súc tích, thường là mô tả tình huống thành công chính yếu nhất

- Bình thường: Định dạng các đoạn mô tả không chính thống Nhiều đoạn văn mô

tả các tình huống khác nhau

- Đầy đủ: Dạng kỹ lưỡng nhất, tất cả các bước và các tình huống được viết chi tiết đồng thời có các phần hỗ trợ như là các điều kiện tiên quyết và các đảm bảo thành công

Định dạng của một Use Case loại đầy đủ có thể có các phần như sau:

- Tác nhân chính

- Các thành phần tham gia hệ thống và mối quan tâm tương ứng

- Điều kiện tiên quyết

- Điều kiện xác định thành công

- Tình huống thành công chính yếu

- Các tình huống mở rộng

- Các yêu cầu đặc biệt

- Danh mục các công nghệ và dữ liệu

- Tần suất xuất hiện

- Các vấn đề để mở

Mục tiêu và phạm vi của một Use Case

Làm thế nào xác định được các Use Case? Chúng ta thường không chắc chắn một Use Case tạo ra liệu có hợp lý hoặc hữu dụng không Các nhiệm vụ có thể nhóm với nhau theo nhiều mức, từ một hay vài bước nhỏ cho tới cấp các hoạt động của doanh nghiệp Vậy Use Case nên được diễn đạt ở mức nào và phạm vi nào?

Để phân tích yêu cầu cho một ứng dụng phần mềm ta tập trung vào các Use Case ở mức EBP(Quy trình tác nghiệp cơ sở)

EBP là thuật ngữ trong lĩnh vực quy trình tác nghiệp được định nghĩa như sau: Một nhiệm vụ được thực hiện bởi một người trong một nơi tại một thời điểm để đáp ứng một sự kiện tác nghiệp mà đem lại một giá trị nghiệp vụ có ý nghĩa đồng thời để lại dữ liệu ở trạng thái ổn định

Đôi khi ta cũng không phải tuân thủ quá chặt chẽ từng câu chữ của định nghĩa, chẳng hạn liệu một Use Case có vi phạm EBP nếu cần thiết có 2 người, hoặc có một người phải chuyển động vòng quanh Use Case không phải là một bước nhỏ như “Xóa một dòng” hay “In tài liệu” mà một tình huống thành công chính yếu có thể bao gồm 5 hay

10 bước, nó không kéo dài cả ngày và qua nhiều phiên làm việc, nó là công việc hoàn thành trong một phiên làm việc đơn lẻ

Các tác nhân có mục tiêu và sử dụng ứng dụng để thỏa mãn các mục tiêu này Do vậy một Use Case mức EBP được gọi là một Use Case mức mục tiêu người sử dụng, để

nhấn mạnh là nó phục vụ để đáp ứng một mục đích của người dùng hệ thống, hay tác nhân chính Điều này dẫn tới thủ tục sau đây:

1 Chọn biên của hệ thống Nó chỉ là ứng dụng phần mềm, phần cứng kết hợp ứng dụng, cộng với người sử dụng nó, hay là toàn bộ tổ chức?

2 Xác định các tác nhân chính là người sử dụng có mục tiêu được đáp ứng qua việc sử dụng các dịch vụ của hệ thống

3 Với mỗi tác nhân, xác định các mục tiêu người sử dụng Đưa chúng lên mức cao nhất của mục tiêu người sử dụng mà thỏa mãn định nghĩa EBP

4 Định nghĩa các Use Case mà thỏa mãn các mục tiêu người dùng; Đặt tên chúng theo các mục tiêu của chúng Thông thường thì có sự tương ứng một một giữa các Use Case mức mục tiêu người dùng và các Mục tiêu người dùng

5.2 Pha chuẩn bị - Vòng lặp 1

5.2.1 Mô hình Use Case: Vẽ các Sơ đồ tuần tự hệ thống

Một biểu đồ tuần tự hệ thống là một artifact được tạo ra nhanh và dễ dàng, nó biểu diễn các sự kiện đầu vào và đầu ra liên quan tới hệ thống đó

Use Case thì mô tả các tác nhân bên ngoài tương tác với hệ thống phần mềm như thế nào Trong quá trình tương tác này một tác nhân sinh ra các sự kiện đối với hệ thống, thường là yêu cầu vài hoạt động đáp trả UML có các biểu đồ tuần tự có thể minh họa các tương tác của tác nhân và các hoạt động kích hoạt bởi chúng

Một Biểu đồ Tuần tự Hệ thống (SSD) là một bức tranh mà chỉ ra trong tình huống cụ thể của một Use Case các sự kiện mà tác nhân bên ngoài sinh ra, thứ tự của chúng và các sự kiện liên hệ thống Tất cả các hệ thống được xem như các hộp đen, điểm quan trọng của biểu đồ là các sự kiện đi qua biên của hệ thống từ các tác nhân tới các hệ thống

Hình 5.1 Biểu đồ tuần tự hệ thống cho tình huống xử lý bán hàng

5.2.2 Mô hình Nghiệp vụ: Hình tượng hóa các Khái niệm

Mô hình nghiệp vụ được sử dụng rộng rãi như là nguồn cảm hứng để thiết kế các đối tượng phần mềm và sẽ là đầu vào bắt buộc cho nhiều Artifact mà ta sẽ đề cập tiếp theo

Một mô hình nghiệp vụ biểu diễn các lớp khái niệm có ý nghĩa trong một vùng nghiệp

vụ, nó là Artifact quan trọng nhất cần tạo trong phân tích hướng đối tượng UML chứa các ký hiệu dưới dạng biểu đồ lớp để biểu diễn các mô hình nghiệp vụ

Một mô hình nghiệp vụ là một biểu diễn của các lớp khái niệm thế giới thực, không phải các thành phần phần mềm Nó không phải tập các biểu đồ mô tả các lớp phần mềm hay các đối tượng phần mềm cùng các trách nhiệm

RUP định nghĩa mô hình nghiệp vụ như là một Artifact mà có thể tạo ra trong Business Modeling Discipline

Sử dụng các ký hiệu của UML, một mô hình nghiệp vụ được minh họa bởi một tập các Biểu đồ lớp trong đó không hoạt động nào được định nghĩa Nó có thể biểu diễn:

- Các lớp khái niệm hoặc các đối tượng nghiệp vụ

- Kiểu liên kết giữa các lớp khái niệm

- Các thuộc tính của các lớp khái niệm

Hình 5.2 Một mô hình nghiệp vụ

5.2.3 Mô hình Nghiệp vụ: Thêm các Liên kết

- Cần tập trung vào các mối liên kết mà kiến thức về mối quan hệ cần được lưu giữ trong một khoảng thời gian nào đó(Gọi là các liên kết “need to know”)

- Việc xác định các lớp khái niệm quan trọng hơn là việc tìm các liên kết

- Quá nhiều mối liên kết sẽ gây rối mô hình nghiệp vụ, việc tìm ra chúng có thể mất thời gian

- Tránh chỉ ra các liên kết dư thừa và liên kết hệ quả

Sau đây là các loại liên kết được ưu tiên và luôn hữu dụng khi bao gồm trong mô hình nghiệp vụ:

- A là một phần vật lý hoặc lôgic của B

- A được chứa một cách vật lý hoặc lôgic trong B

- A được ghi nhớ trong B

Hình 5.3 Một mô hình nghiệp vụ với các liên kết

5.2.4 Mô hình Nghiệp vụ: Thêm các Thuộc tính

Một thuộc tính là giá trị dữ liệu logic của một đối tƣợng, chúng ta sẽ đƣa các thuộc tính vào trong mô hình nghiệp vụ khi trong các yêu cầu có gợi ý hoặc đề nghị cần phải nhớ thông tin

Hình 5.4 Biểu đồ cộng tác

Hình 5.5 Biểu đồ tuần tự

Mỗi loại biểu đồ có điểm mạnh và điểm yếu, biểu đồ cộng tác có thể vẽ trên diện tích

có chiều ngang hẹp, còn biểu đồ tuần tự thì diễn đạt tốt hơn tuần tự các thông điệp

5.2.6 GRASP: Thiết kế các đối tượng cùng các Trách nhiệm

Sau khi xác định yêu cầu và tạo ra mô hình nghiệp vụ, việc thêm các phương thức vào các lớp phần mềm và định nghĩa các thông điệp để đáp ứng các yêu cầu là một cách để

mô tả quá trình thiết kế đối tượng

GRASP được biểu diễn như là các hình mẫu dùng để mô tả các nguyên lý căn bản về thiết kế đối tượng và gán trách nhiệm cho đối tượng

UML định nghĩa “Trách nhiệm” như là một hợp đồng, một bắt buộc đối với một phân lớp, về cơ bản các “Trách nhiệm” này được chia làm hai loại sau:

- Trách nhiệm biết

- Trách nhiệm làm

Trách nhiệm làm của một đối tượng bao gồm:

- Tự làm gì đó, chẳng hạn tạo ra một đối tượng, hoặc thực hiện một tính toán

- Khởi tạo hành động trong các đối tượng khác

- Điều khiển và phối hợp hành động trong các đối tượng khác

Trách nhiệm biết của một đối tượng bao gồm:

- Biết dữ liệu đóng gói riêng

- Biết các đối tượng liên quan

- Biết những điều mà nó có thể thừa kế hoặc tính toán

Trách nhiệm được gán cho các lớp của đối tượng trong khi thiết kế đối tượng

Năm hình mẫu đầu tiên của GRASP là:

- Information Expert (Chuyên gia thông tin): Gán trách nhiệm cho lớp mà có chứa thông tin cần thiết để đáp ứng trách nhiệm

- Creator (Người tạo): Gán trách nhiệm cho lớp B tạo ra thực thể của lớp A khi một trong các điều kiện sau đây là đúng:

o B tập hợp các đối tượng của A

o B chứa các đối tượng của A

o B ghi nhớ các thực thể của A

o B sử dụng gần các đối tượng A

o B có dữ liệu khởi tạo mà sẽ được truyền cho A khi A được tạo ra

- High Cohesion (Cố kết cao): Gán trách nhiệm sao cho sự cố kết duy trì ở mức cao

- Low Coupling (Móc nối thấp): Gán trách nhiệm sao cho sự móc nối duy trì ở mức thấp

- Controller (Bộ điều khiển): Gán trách nhiệm nhận và xử lý các thông điệp sự kiện hệ thống cho lớp mà đại diện cho một trong các lựa chọn sau:

o Biểu diễn tổng thể hệ thống, thiết bị, hoặc thiết bị con

o Biểu diễn một ngữ cảnh Use Case trong đó sự kiện hệ thống xảy ra

5.2.7 Mô hình Thiết kế: Hiện thực hóa Use Case với các khuôn mẫu GRASP

Hiện thực hóa Use Case mô tả một Use Case sẽ được hiện thực như thế nào trong mô hình thiết kế Chính xác hơn, một người thiết kế có thể mô tả thiết kế của một hay nhiều tình huống của Use Case, mỗi công việc này gọi là hiện thực hóa Use Case Hiện thực hóa Use Case là một thuật ngữ của RUP, hay một khái niệm được sử dụng

để nhắc chúng ta về mối liên kết giữa những yêu cầu được thể hiện bởi các Use Case

và các thiết kế đối tượng thỏa mãn những yêu cầu đó

Các biểu đồ tương tác của UML là ngôn ngữ chung để minh họa việc hiện thực hóa Use Case Và có các nguyên lý, hình mẫu của thiết kế đối tượng, như là “Chuyên gia Thông tin”, “Móc nối thấp”, có thể áp dụng cho quá trình thiết kế này