Đề cương phân tích thiết kế hướng đối tượng với UML

Quy trình của một phần mềm c thể được chia thành các giai đoạn như sau: - Nghi n cứu sơ bộ Preliminary Investigation hay còn g i là Feasibility Study - Phân tích y u cầu Analysis - Thiết

Trang 1

Bộ môn Công nghệ phần mềm Trang 1

MỤC LỤC

Bài 1: Tổng quan về phân tích thiết kế hệ thống 3

1.1 Giới thiệu về hệ thống phần mềm 3

1.2 Các mô hình phát triển phần mềm 3

1.2.1 Tổng quan về quy trình phát triển phần mềm 3

1.3 Các cách tiếp cận trong phân tích thiết kế hệ thống thông tin 16

1.4 Lịch sử hướng đối tượng 17

1.5 Các khái niệm cơ bản của hướng đối tượng 19

1.6 Ưu, nhược điểm của mô hình hướng đối tượng 23

1.7 Các bước phân tích thiết kế hướng đối tượng 23

Bài 2: Giới thiệu về UML 26

2.1 Tổng quát về UML 26

2.2 Mô hình khái niệm của UML 30

2.4 Kiến trúc hệ thống 36

2.5 Các biểu đồ trong UML 38

2.6 Giới thiệu công cụ Visual Paradigm 46

Bài 3: Thảo luận về phương pháp hướng đối tượng 50

Bài 4: Phân tích hướng đối tượng (1) 51

4.1 Tổng quan về phân tích hướng đối tượng 51

4.2 Mô hình Use case 53

Bài 5: Thực hành 1: Thực hành về mô hình Use Case 73

6.1 Vấn đề xác định lớp 73

6.2 Xây dựng biểu đồ lớp trong pha phân tích 84

6.3 Biểu diễn biểu đồ lớp trong Visual Paradigm 90

Bài 7: Bài thực hành 2 – Thực hành biểu đồ lớp 92

8.1 Khái quát về mô hình động 92

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

8.3 Xây dựng biểu đồ trạng thái trong VP 96

Bài 9: Thảo luận về phân tích hướng đối tượng 97

Trang 2

Bài 10: Pha thiết kế hướng đối tượng (1) 97

10.1 Tổng quan về thiết hướng đối tượng 97

10.2 Các biểu đồ tương tác 98

Bài 11: Thực hành 3 – Biểu đồ trạng thái và biểu đồ tương tác 104

Bài 12: Thảo luận về thiết hướng đối tượng 105

Bài 13: Pha thiết kế hướng đối tượng (2) 113

13.1 Biểu đồ lớp chi tiết 113

13.3 Thiết kế chi tiết 119

Bài 14: Thực hành 4 – Xây dựng biểu đồ lớp chi tiết 123

Bài 15: Thực hành 5 – Xây dựng cơ sở dữ liệu 123

Bài 16: Thiết kế hướng đối tượng(3) 123

16.1 Biểu đồ thành phần 123

16.2 Biểu đồ triển khai 127

Bài 17: Thực hành 6 – Xây dựng biểu đồ thành phần, biểu đồ triển khai 130

Bài 18: Thực hành 7 – Triển khai phần mềm hướng đối tượng 132

Bài 19: Thực hành 8 – Kiểm tra thực hành 133

Trang 3

Bài 1: Tổng quan về phân tích thiết kế hệ thống 1.1 Giới thiệu về hệ thống phần mềm

Hệ thống là tổ hợp phần cứng, phần mềm cung cấp giải pháp cho vấn đề cần giải quyết Ngày nay, trong khi hệ thống quá phức tạp mà tri thức lại quá chuy n ngành cho nên một ngư i không thể biết m i khía cạnh tác nghiệp Một ngư i không thể hiểu đồng

th i m i vấn đề của hệ thống: t thiết kế giải pháp, viết m trình, triển khai tr n nền phần cứng đến đảm bảo ch c ch n m i thành phần phần cứng đều làm việc tốt với nhau Tiến trình phát triển phần mềm phức tạp phải được nhiều ngư i thực hiện Trước hết là khách hàng, đ là ngư i đưa ra vấn đề cần giải quyết Phân tích vi n làm tài liệu vấn đề của khách hàng và chuyển n tới ngư i phát triển, đ là những lập trình vi n xây dựng phần mềm để giải quyết, kiểm tra và triển khai n tr n các phần cứng Phát triển phần mềm c thể được thực hiện b ng nhiều con đư ng khác nhau Các dự án c thể tuân thủ một trong các loại tiến trình l p và t ng dần M i loại c ưu và nhược điểm ri ng

1.2 Các mô hình phát triển phần mềm

1.2.1 Tổng quan về quy trình phát triển phần mềm

Cũng như m i ngành sản xuất khác, qui trình là một trong những yếu tố cực kỳ quan tr ng đem lại sự thành công cho các nhà sản xuất phần mềm, n giúp cho m i thành

vi n trong dự án t ngư i cũ đến ngư i mới, trong hay ngoài công ty đều c thể xử lý

Trang 4

đồng bộ công việc tương ứng vị trí của mình thông qua cách thức chung của công ty, hay

ít nhất ở cấp độ dự án

Quy trình của một phần mềm c thể được chia thành các giai đoạn như sau:

- Nghi n cứu sơ bộ (Preliminary Investigation hay còn g i là Feasibility Study)

- Phân tích y u cầu (Analysis)

- Thiết kế hệ thống (Design of the System)

- Xây dựng phần mềm (Software Construction)

- Thử nghiệm hệ thống (System Testing)

- Thực hiện, triển khai (System Implementation)

- Bảo trì, nâng cấp (System Maintenance)

a Nghiên cứu sơ bộ:

Câu hỏi quan tr ng nhất khi phát triển một hệ thống hoàn toàn không phải câu hỏi mang tính phương pháp luận Mà cũng chẳng phải câu hỏi về kỹ thuật N là một câu hỏi dư ng như c vẻ đơn giản, nhưng thật ra đ c biệt kh trả l i: “Đây c đúng là một

hệ thống để thực hiện không?” Đáng buồn là chính câu hỏi này trong thực tế thư ng chẳng hề được đ t ra và lại càng không được trả l i M c dù việc lầm lẫn về phương pháp hay quyết định sai lầm về kỹthuật cũng c thể dẫn tới thất bại, nhưng thư ng thì

dự án c thể được cứu v n nếu c đầy đủ tài nguy n cùng sự cố g ng qu n mình của các nhân vi n tài giỏi Nhưng sẽ chẳng một ai và một điều gì cứu v n cho một hệ thống phần mềm hoàn toàn chẳng được cần tới ho c cố g ng tự động h a một quy trình lầm lạc

Trước khi b t tay vào một dự án, bạn phải c một ý tưởng cho n Ý tưởng này đi song song với việc n m b t các y u cầu và xuất hiện trong giai đoạn khởi đầu N hoàn tất một phát biểu: "Hệ thống mà chúng ta mong muốn sẽ làm được những việc như sau " Trong suốt giai đoạn này, chúng ta tạo n n một bức tranh về ý tưởng đ , rất nhiều giả thuyết sẽ được công nhận hay loại bỏ Các hoạt động trong th i gian này thư ng bao gồm thu thập các ý tưởng, nhận biết rủi ro, nhận biết các giao diện b n ngoài, nhận biết các các chức n ng chính mà hệ thống cần cung cấp, và c thể tạo một vài nguy n mẫu dùng để “minh chứng các khái niệm của hệ thống” Ý tưởng c thể đến t nhiều nguồn khác nhau: khách hàng, chuy n gia lĩnh vực, các nhà phát triển khác, chuy n gia về kỹ nghệ, các bản nghi n cứu tính khả thi cũng như việc xem xét các hệ thống khác đang tồn tại Một khía cạnh cần nh c tới là code viết trong th i kỳ này thư ng sẽ bị "bỏ đi”, bởi chúng được viết nh m mục đích thẩm tra hay trợ giúp các giả thuyết khác nhau, chứ chưa phải thứ code được viết theo kết quả phân tích và thiết kế thấu đáo

Trong giai đ an nghi n cứu sơ bộ, nh m phát triển hệ thống cần xem xét các

y u cầu của doanh nghiệp (cần dùng hệ thống), những nguồn tài nguy n c thể sử dụng, công nghệ cũng như cộng đồng ngư i dùng cùng các ý tưởng của h đối với hệ thống mới C thể thực hiện thảo luận, nghi n cứu, xem xét khía cạnh thương mại, phân tích khả n ng l i-l , phân tích các trư ng hợp sử dụng và tạo các nguy n mẫu để xây

Trang 5

dựng n n một khái niệm cho hệ thống đích cùng với các mục đích, quyền ưu ti n và phạm vi của n

Thư ng trong giai đoạn này ngư i ta cũng tiến hành tạo một phi n bản thô của lịch trình và kếhoạch sử dụng tài nguy n

Một giai đoạn nghi n cứu sơ bộ thích đáng sẽ lập n n tập hợp các y u cầu (dù ở mức độ khái quát cao) đối với một hệ thống khả thi và được mong muốn, kể cả về phương diện kỹ thuật lẫn x hội Một giai đoạn nghi n cứu sơ bộ không được thực hiện thoả đáng sẽ dẫn tới các hệ thống không được mong muốn, đ t tiền, bất khả thi và được định nghĩa lầm lạc – những hệ thống th ơng chẳng được hoàn tất hay sử dụng

Kết quả của giai đoạn nghi n cứu sơ bộ là Báo Cáo Kết Quả Nghi n Cứu Tính Khả Thi Khi hệ thống tương lai được chấp nhận dựa tr n bản báo cáo này cũng là lúc giai đoạn Phân tích b t đầu

b Phân tích yêu cầu

Sau khi đ xem xét về tính khả thi của hệ thống cũng như tạo lập một bức tranh

sơ bộ của dự án, chúng ta bước sang giai đoạn thư ng được coi là quan tr ng nhất trong các công việc lập trình: hiểu hệ thống cần xây dựng Ngư i thực hiện công việc này là nhà phân tích

Quá trình phân tích nhìn chung là hệ quả của việc trả l i câu hỏi "Hệ thống cần phải làm gì?" Quá trình phân tích bao gồm việc nghi n cứu chi tiết hệ thống doanh nghiệp hiện th i, tìm cho ra nguy n lý hoạt động của n và những vị trí c thể được nâng cao, cải thiện B n cạnh đ là việc nghi n cứu xem xét các chức n ng mà hệ thống cần cung cấp và các mối quan hệ của chúng, b n trong cũng như với phía ngoài hệ thống Trong toàn bộ giai đoạn này, nhà phân tích và ngư i dùng cần cộng tác mật thiết với nhau để xác định các y u cầu đối với hệthống, tức là các tính n ng mới cần phải được đưa vào hệ thống

Những mục tiêu cụ thể của giai đoạn phân tích là:

Trang 6

Sau giai đoạn phân tích, khi các y u cầu cụ thể đối với hệ thống đ được xác định, giai đoạn tiếp theo là thiết kế cho các y u cầu mới Công tác thiết kế xoay quanh câu hỏi chính: Hệ

thống làm cách nào để thỏa m n các y u cầu đ được n u trong Đ c Tả Y u Cầu?

Một số các công việc thường được thực hiện trong giai đoạn thiết kế:

- Nhận biết form nhập liệu tùy theo các thành phần dữ liệu cần nhập

- Nhận biết reports và những output mà hệ thống mới phải sản sinh

- Thiết kế forms (vẽ tr n giấy hay máy tính, sử dụng công cụ thiết kế)

- Nhận biết các thành phần dữ liệu và bảng để tạo database

- Ước tính các thủ tục giải thích quá trình xử lý t input đến output

Kết quả giai đoạn thiết kế là Đ c Tả Thiết Kế (Design Specifications) Bản Đ c

Tả Thiết Kế Chi Tiết sẽ được chuyển sang cho các lập trình vi n để thực hiện giai đoạn xây dựng phần mềm

d Xây dựng phần mềm

Đây là giai đoạn viết lệnh (code) thực sự, tạo hệ thống T ng ngư i viết code thực hiện những y u cầu đ được nhà thiết kế định sẵn Cũng chính ngư i viết code chịu trách nhiệm viết tài liệu li n quan đến chương trình, giải thích thủ tục (procedure) mà anh ta tạo n n được viết như thế nào và lý do cho việc này

Để đảm bảo chương trình được viết n n phải thoả m n m i y u cầu c ghi trước trong bản Đ c Tả Thiết Kế Chi Tiết, ngư i viết code cũng đồng th i phải tiến hành thử nghiệm phần chương trình của mình Phần thử nghiệm trong giai đoạn này c thể được chia thành hai bước chính:

Thử nghiệm đơn vị:

Ngư i viết code chạy thử các phần chương trình của mình với dữ liệu giả (test/dummy data) Việc này được thực hiện theo một kế hoạch thử, cũng do chính ngư i viết code soạn ra Mục đích chính trong giai đoạn thử này là xem chương trình c cho ra những kết quả mong đợi Giai đoạn thử nghiệm đơn vị nhiều khi được g i là "Thử hộp

tr ng" (White Box Testing)

Y u Cầu và những mong ch của ngư i dùng c được thoả m n Dữ liệu thử cần được

ch n l c đ c biệt, kết quả cần được phân tích để phát hiện m i lệch lạc so với mong ch

f Thực hiện, triển khai

Trang 7

Nghi n cứu sơ bộ

Preliminary

Investigation

Phân tích y u cầu System Analysis

Thiết kế hệ thống System Design

Xây dựng phần mềm Software Construction

Thử nghiệm hệ thống System Testing

Thử hiện triển khai Implemention

Bảo trì, nâng cấp Maintenance

Trong giai đoạn này, hệ thống v a phát triển sẽ được triển khai sao cho phía ngư i dùng Trước khi để ngư i dùng thật sự b t tay vào sử dụng hệ thống, nh m các nhà phát triển cần tạo các file dữ liệu cần thiết cũng như huấn luyện cho ngư i dùng,

để đảm bảo hệ thống được sử dụng hữu hiệu nhất

Trang 8

1.2.2 Mô hình Waterfall

Hình 1.2 Mô hình thác nước

Mô hình này bao gồm các giai đoạn xử lý nối tiếp nhau

 Xác định yêu cầu và tài liệu đặc tả (Requirements and Specifications): là giai đoạn

xác định những “đòi hỏi” (“What”) li n quan đến chức n ng và phi chức n ng mà hệ thống phần mềm cần c Giai đoạn này cần sự tham gia tích cực của khách hàng và kết thúc b ng một tài liệu được g i là “Bản đ c tả y u cầu phần mềm” hay SRS (software requirement specification), trong đ bao gồm tập hợp các y u cầu đ được duyệt (reviewed) và nghiệm thu (approved) bởi những ngư i c trách nhiệm đối với

dự án (t phía khách hàng) SRS chính là nền tảng cho các hoạt động tiếp theo cho đến cuối dự án

 Phân tích hệ thống và thiết kế (System Analysis and Design): là giai đoạn định ra

“làm thế nào” (“How”) để hệ thống phần mềm đáp ứng những “đòi hỏi” (“What”) mà

Trang 9

khách hàng y u cầu trong SRS Đây là chính là cầu nối giữa “đòi hỏi” (“What”) và

m (Code) được hiện thực để đáp ứng y u cầu đ

 Cài đặt và kiểm thử đơn vị (Coding and Unit Test): là giai đoạn hiện thực “làm thế

nào” (“How”) được chỉ ra trong giai đoạn “Phân tích hệ thống và thiết kế”

 Tích hợp và kiểm thử(Test): giai đoạn này sẽ tiến hành kiểm thử m (code) đ được

hiện thực, bao gồm kiểm thử tích hợp cho nh m các thành phần và kiểm thử toàn hệ thống (system test) Một khâu kiểm thử cuối cùng thư ng được thực hiện là nghiệm thu (acceptance test), với sự tham gia của khách hàng trong vai trò chính để xác định

hệ thống phần mềm c đáp ứng y u cầu của h hay không

 Vận hành và bảo trì(Deployment and Maintenance): đây là giai đoạn cài đ t, cấu

hình và huấn luyện khách hàng Giai đoạn này sửa chữa những l i của phần mềm (nếu

c ) và phát triển những thay đổi mới được khách hàng y u cầu (như sửa đổi, th m hay bớt chức n ng/đ c điểm của hệ thống)

Thực tế cho thấy đến những giai đoạn sau mới c khả n ng nhận ra sai s t trong những giai đoạn trước và phải quay lại để sửa chữa Đây chính là kiểu waterfall dạng l p (Iterative Waterfall)

Một thực tế là các dự án hiếm khi được thực hiện đầy đủ các bước trong suốt chu

kỳ dự án Đ c biệt là giai đoạn kiểm thử khi gần đến ngày giao hàng chẳng hạn, nếu c trục tr c xảy ra do y u cầu phần mềm không rõ ràng hay thiết kế c l i, xu hướng là mã nguồn được sửa đổi trực tiếp mà không qua các bước bổ sung theo đúng mô hình, n n dẫn đến bản đ c tả phần mềm cũng như một số sản phẩm trung gian khác như bản thiết

kế, cho dù c được cập nhật sau này cũng c thể không phản ánh đầy đủ những gì đ được sửa đổi trong m nguồn

Ngư i sử dụng không c cơ hội tham gia trong suốt th i gian của các giai đoạn trung gian t thiết kế cho đến kiểm thử Đ c biệt với những dự án lớn, ngư i sử dụng chỉ

Trang 10

c thể nhận ra r ng hệ thống phần mềm không phù hợp cho nhu cầu của h vào th i điểm cuối dự án

N i chung, mô hình này thư ng ẩn chứa nhiều rủi ro mà chỉ c thể phát hiện ở giai đoạn cuối cùng và chi phí để sửa chữa c thể rất cao

Trang 11

Tinh thần chủ đạo của V-model là các hoạt động kiểm thử phải được tiến hành song song (theo khả n ng c thể) ngay t đầu chu trình cùng với các hoạt động phát triển

Ví dụ, các hoạt động cho việc lập kế hoạch kiểm thử toàn hệ thống c thể được thực hiện song song với các hoạt động phân tích và thiết kế hệ thống

Ưu điểm:

Các hoạt động kiểm thử được chú tr ng và thực hiện song song với các hoạt động

li n quan đến đ c tả y u cầu và thiết kế Hay n i cách khác, mô hình này khuyến khích các hoạt động li n quan đến kế hoạch kiểm thử được tiến hành sớm trong chu kỳ phát triển, không phải đợi đến lúc kết thúc giai đoạn hiện thực

Trang 12

Trong mô hình này, việc phân tích và giải quyết những vấn đề c rủi ro cao tập trung vào thiết kế t ng khía cạnh cụ thể chứ không dựa vào việc xử lý các vấn đề một cách chung chung

Mô hình xo n ốc với các giai đoạn l p theo chu kỳ xoay vòng, trong đ m i chu

kỳ bao gồm 4 giai đoạn con như sau:

1 Xác định mục ti u chất lượng cho sản phẩm được thực hiện, đồng th i xác định sự lựa ch n mua, tái sử dụng hay tự thiết kế và hiện thực các thành phần của hệ thống

2 Phân tích sự lựa ch n và các rủi ro c thể xảy ra Việc này được thực hiện bởi nhiều hoạt động khác nhau thông qua làm mẫu hay mô phỏng

3 Phát triển và kiểm định sản phẩm ở mức tiếp theo dựa tr n kết quả định hướng được chỉ ra trong giai đoạn con số 2 (phân tích rủi ro)

4 Kiểm duyệt tất cả các kết quả của các giai đoạn con xảy ra trước đ và lập kế hoạch cho chu kỳ l p tiếp theo

Ưu điểm:

Phân tích đánh giá rủi ro được đẩy l n như một phần thiết yếu trong m i “spiral”

để t ng mức độ tin cậy của dự án

Kết hợp những tính chất tốt nhất của mô hình waterfall và tiến h a

Cho phép thay đổi tùy theo điều kiện thực tế dự án tại m i “spiral”

Đây chính là mô hình tổng quát nhất, tất cả các mô hình khác đều c thể xem là một hiện thực của mô hình tổng quát này, hay cũng c thể xem n là mô hình tổng hợp các mô hình khác Đ c biệt, n được ứng dụng không chỉ trong phát triển phần mềm mà còn trong phát triển phần cứng

Nhược điểm:

Phức tạp và không phù hợp cho dự án nhỏ với ít rủi ro

Cần c kỹ n ng tốt về phân tích rủi ro

Ứng dụng:

Dự án lớn c nhiều rủi ro hay sự thành công của dự án không c được sự đảm bảo nhất định; những dự án đòi hỏi nhiều tính toán, xử lý như hệ thống h trợ quyết định

Đội ngũ thực hiện dự án c khả n ng phân tích rủi ro

Trang 13

Tr n đây là một số so sánh giữa các mô hình, thực sự việc lựa ch n cụ thể mô hình nào không phải dễ dàng và tr n thực tế ngư i ta thư ng dùng mô hình lai, kết hợp một số

mô hình với nhau sao cho phù hợp với dự án

Việc cải tiến các mô hình phát triển phần mềm luôn là đề tài nghi n cứu hấp dẫn, với sự tham gia tích cực không những t các nhà sản xuất phần mềm mà còn t các viện đại h c kh p thế giới Ri ng với các nhà phát triển phần mềm, h luôn cố g ng cải tiến liên tục qui trình phát triển của mình nh m không ng ng đổi mới, nâng cao n ng suất và chất lượng sản phẩm Tuy nhi n, một điều dễ thấy là việc lựa ch n, tùy biến mô hình phù hợp cho các dự án đ kh , nhưng việc vận hành n vào trong quá trình phát triển sản phẩm càng kh hơn Đ chính là thách thức cho các nhà phát triển phần mềm

1.2.5 Quy trình phát triển phần mềm Rup

Hình 1.5 (a) Quy trình phát triển phần mềm của Rup

Trang 14

Hình 1.5 (b) Các hoạt động trong qui trình RUPđược thể hiện trong việc phát

triển phần mềm thực tế

RUP (Rational Unified Process) là framework qui trình phát triển phần mềm mang tính l p được tạo bởi Công ty Rational Software (được IBM mua n m 2003) IBM Rational Method Composer (RMC) được tích hợp vào RUP với mục đích c thể chỉnh sửa qui trình theo mục đích ri ng (customization)

Một mô hình qui trình hiện đại rút ra t việc xây dựng UML (Unified Modeling Language)

Dựa trên 6 kinh nghiệm thực tiễn của công nghệ phần mềm hiện đại:

1) Phát triển l p với “rủi ro” là nhân tố dẫn d t chính

2) Quản lý y u cầu

3) Sử dụng kiến trúc thành phần (component)

4) Mô hình phần mềm một cách trực quan

5) Kiểm tra chất lượng li n tục

6) Kiểm soát sự thay đổi

RUP ra đời trở thành chiến lược vững vàng của Rational:

 Một qui trình hướng dẫn phát triển phần mềm

 Công cụ tạo tự động ứng dụng theo qui trình

 Dịch vụ làm cho Qui trình và Tool được hiệu quả hơn

Các Giai đoạn và các vòng lặp trong vòng đời phát triển (Phases and Iterations)

M i vòng đ i phần mềm được chia thành nhiều vòng (cycles), m i vòng (cycle) làm việc

tr n một phi n bản mới của sản phẩm RUP chia 1 vòng phát triền (development cycle)

Trang 15

thành 4 giai đoạn (phase) li n tiếp: Inception phase, Elaboration phase, Construction phase, Transition phase

CHI TIẾT VỀ RUP

Cấu trúc tĩnh của qui trình

Một qui trình mô tả ai (who) đang làm gì (what), làm như thế nào (how) và làm khi nào (when) RUP sử dụng 4 yếu tố chính trong mô hình

b) Activity: của một worker là một đơn vị công việc được giao cho một cá nhân thực

hiện Activity c mục đích rõ ràng, thư ng là y u cầu tạo mới ho c update một số artifacts như là model, class, ho c plan M i một activity được phân công cho một workder rõ ràng

c) Artifact là một mẫu thông tin được tạo, chỉnh sửa ho c được sử dụng bởi qui trình

Artifact là những sản phẩm hữu hình của dự án, là vật mà dự án tạo ra ho c sử dụng để đạt đến sản phẩm cuối cùng Artifact thư ng được nhập bởi worker để thực hiện một activity, ho c là kết quả của các activities

Artifact c thể c rất nhiều dạng:

-Mô hình: use-case model, design model

-Yếu tố mô hình: class, use-case ho c subsystem

-Tài liệu: Business case ho c tài liệu kiến trúc phần mềm

-Source code

-Các file thực thi (Executables)

Trang 16

d) Workflow :Chỉ là một bản liệt k các workers, activities và artifact thì không thể tạo

thành qui trình Chúng ta cần một cách mô tả tuần tự đầy ý nghĩa các activities để tạo ra kết quả c giá trị và chỉ rõ sự tương tác giữa các worker Workflow là một chu i các hành động diễn ra li n tiếp nh m tạo ra kết quả c giá trị rõ ràng Trong UML, workflow c thể diễn đạt b ng sequence diagram, collaboraion diagram

ho c activity diagram

1.3 Các cách tiếp cận trong phân tích thiết kế hệ thống thông tin

Trong những n m 70-80, phương pháp hướng cấu trúc được coi là phương pháp chuẩn để phát triển phần mềm Tuy nhi n, phương pháp này tỏ ra không phù hợp trong phát triển phần mềm lớn và đ c biệt là kém hiệu quả trong sử dụng lại – một y u cầu quan tr ng trong công nghiệp phần mềm Thập ni n 90 chứng kiến sự nở rộ trong nghi n cứu và xấy dựng phương pháp luận phát triển phần mềm hướng đối tượng và nhanh

ch ng trở thành phổ biến trong công nghiệp phần mềm ngày nay Để hiểu rõ phần nào sự khác biệt này phần này dành so sánh một số khác biệt giữa hai phương pháp này

1.3.1 Phương pháp hướng chức năng:

Đây là lối tiếp cận truyền thống của ngành Công nghệ phần mềm Theo lối tiếp cận này, chúng ta quan tâm chủ yếu tới những thông tin mà hệ thống sẽ giữ gìn Chúng ta hỏi ngư i dùng xem h sẽ cần những thông tin nào, rồi chúng ta thiết kế ngân hàng dữ liệu để chứa những thông tin đ , cung cấp Forms để nhập thông tin và in báo cáo để trình bày các thông tin Nói một cách khác, chúng ta tập trung vào thông tin và không mấy để

ý đến những gì có thể xảy ra với những hệ thống đ và cách hoạt động (ứng xử) của hệ thống là ra sao Đây là lối tiệm cận xoay quanh dữ liệu và đ được áp dụng để tạo nên hàng ngàn hệ thống trong suốt nhiều n m tr i Lối tiếp cận xoay quanh dữ liệu là phương pháp tốt cho việc thiết kế ngân hàng dữ liệu và n m b t thông tin, nhưng nếu áp dụng cho việc thiết kế ứng dụng lại có thể khiến phát sinh nhiều kh kh n Một trong những thách thức lớn là yêu cầu đối với các hệ thống thư ng xuy n thay đổi Một hệ thống xoay quanh dữ liệu có thể dể dàng xử lý việc thay đổi ngân hàng dữ liệu, nhưng lại khó thực thi những thay đổi trong nguyên t c nghiệp vụ hay cách hoạt động của hệ thống.Phương pháp hướng đối tượng đ được phát triển để trả l i cho vấn đề đ Với lối tiếp cận hướng đối tượng, chúng ta tập trung vào cả hai m t của vấn đề : thông tin và cách hoạt động

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

Hướng đối tượng là thuật ngữ thông dụng hiện th i của ngành công nghiệp phần

mềm Các công ty đang nhanh ch ng tìm cách áp dụng và tích hợp công nghệ mới này vào các ứng dụng của h Thật sự là đa phần các ứng dụng hiện th i đều mang tính hướng đối tượng Nhưng hướng đối tượng c nghĩa là gì?

Trang 17

Lối tiếp cận hướng đối tượng là một lối tư duy về vấn đề theo lối á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 lối tiếp cận này, chúng ta chia ứng dụng thành các thành phần nhỏ, g i là các đối tượng, chúng tương đối độc lập với nhau Sau đ ta c thể xây dựng ứng dụng b ng cách ch p các đối tượng đ lại với nhau

H y nghĩ đến trò chơi xây lâu đài b ng các mẫu g Bước đầu tiên là tạo hay mua một vài loại mẫu g c n bản, t đ tạo nên các khối xây dựng c n bản của mình Một khi đ c các khối xây dựng đ , bạn có thể ch p ráp chúng lại với nhau để tạo lâu đài Tương tự như vậy một khi đ xây dựng một số đối tượng c n bản trong thế giới máy tính, bạn có thể ch p chúng lại với nhau để tạo ứng dụng của mình

Xin lấy một ví dụ đơn giản: vấn đề rút tiền m t tại nhà b ng Các “mẫu g “ thành phần ở đây sẽ là ánh xạ của các đối tượng ngoài đ i thực như tài khoản, nhân viên, khách hàng, …Và ứng dụng sẽ được sẽ được nhận diện cũng như giải đáp xoay quanh các đối tượng đ

1.4 Lịch sử hướng đối tượng

Khái niệm hướng đối tượng hình thành t ngôn ngữ lập trình Simula, nhưng n chỉ trở n n quen thuộc khi xuất hiện ngôn ngữ C++ và SmallTalk vào cuối những n m 80

của thế kỳ XX Sơ đồ trong hình 1.3 chỉ ra th i gian xuất hiện và quan hện của các ngôn ngữ lập trình OES00 Trong hình vuông với g c tròn là t n các ngôn ngữ lập trình hướng đối tượng

Trang 18

Smalltalk-80 Objective C

ObjectPascal

ObjectCobol Ada 9

Trang 19

trình và công cụ h trợ ri ng Chúng đều c ưu điểm và nhược điểm ri ng Ngư i sử dụng rất kh kh n để ch n cho mình một phương pháp phù hợp Do nhận biết đươc các vấn đề này, vào n m 1994 các tác giả của các phương pháp này đ hợp tác nh m tạo ra

phương pháp mới B t đầu là sự thống nhất phương pháp Booch với OMT-2 của Rumbagh để hình thành Unified Method 0.8 tại Rational Rose Corporation Tháng 6 n m

1995, Ivar Jacobson (tác giả của OOSE/Objectory) gia nhập với h T th i điểm này,

nh m phát triển phương pháp hướng đối tượng n i tr n cho r ng nhiệm vụ của h là tạo

ra ngôn ngữ mô hình h a thống nhất cho cộng đồng hướng đối tượng Do vậy, h đ đổi

t n công việc của mình thành Unified Modeling Language – UML (Ngôn ngữ mô hình

h a thông nhất) Booch, Rumbaugh và Jacobson đ đưa ra nhiều phi n bản UML, trong

đ phi n bản UML 0.9 xuất hiện n m 1995, UML xuất hiện vào n m 1997 Phần lớn

UML được xây dựng tr n nền tảng của các phương pháp Booch, OMT và OOSE, nhưng UML còn bao gồm cả các khái niệm c nguồn gốc t các phương pháp khác như David Harel, Gamma – Helm – Johnson – Vlissides và Fusion UML còn là kết quả của sự đ ng

g p t các h ng lớn như Digital Equipment Corporation (DEC), Hewlett – Packard (HP), I-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software Corporation, Texas Instrument, Taskon, ObjectTime và Unisys Phi n bản UML 1.1 đ được đệ trình l n OMG (Object Management tháng 11-1997 Phi n bản UML 1.3 xuất hiện vào n m 1999 Phi n bản UML 1.4 xuất hiện vào tháng 2-2000

1.5 Các khái niệm cơ bản của hướng đối tượng

Phần này trình bày một số khái niệm cơ bản áp dụng trong phân tích và thiết kế hướng đối tượng

Phương pháp (method) Phương pháp (hay phương thức) là cách thức cấu trúc

các suy nghĩ và hành động của con ngư i N cho biết chúng ta phải làm cái gì, làm như thế nào, làm khi nào và tại sao phải làm như vậy để hình thành hệ thông phần mềm

ối tương (object) Theo nghĩa thông thư ng thì đối tượng là ngư i, vật hay hiện

tượng mà con ngư i nh m vào trong suy nghĩ, trong hành động PHE96 ; là bất kỳ cái gì nhìn thầy và s m được Trong phương pháp hướng đối tượng thì đối tượng là tr u tượng cái gì đ trong lĩnh vực vấn đề hay trong cài đ t của n ; phản ảnh khả n ng hệ thống lưu giữ thông tin về n và tương tác với n ; g i các giá trị thuộc tính và các dịch

vụ (phương thức, phương pháp) OCAD91

Lớp (class) Theo nghĩa thông thư ng thì lớp là nh m của nhiều ngư i hay vật c

tính tương tự nhất định hay đ c điểm chung (t điển Webster‟s) Trong phương pháp hướng đối tượng thì lớp là mô tả một hay nhiều đối tượng, mô tả tập thống nhất các thuộc tính và phương thức N còn c thể mô tả cách tạo đối tượng mới trong lớp như thế nào [COAD91]

Tr u tượng (abstract) Tr u tượng là nguy n lý bỏ qua những khía cạnh của chủ

thể (subject) không li n quan đến mục đích hiện tại để tập trung đầy đủ hơn vào các khía cạnh còn lại Như vậy c thể n i r ng tr u t n l n n t t m t thông minh Tr u tượng cho khả n ng tổng quát h a và ý tưởng h a vấn đề đang xem xét

Chúng loại bỏ đi các chi tiết dư th a mà chỉ tập chung và các điểm chính, cơ bản [LIBE98]

Trang 20

Mô hình (model) Nếu phải xây ngôi nhà thì ch c ch n không làm đơn giản là cứ

mua gạch, s t thép về l p dần đến khi hình thành nhà ở, mà phải c kế hoạch chi tiết và thiết kế trước N i cách khác là phải xây dựng mô hình Tương tự như vậy, trong lĩnh vực phần mềm, mô hình là kế hoạch chi tiết của hệ thống, n giúp ta lập kế hoạch trước khi xây dựng hệ thống Mô hình giúp ta khẳng định tính đúng đ n của thiết kế, phù hợp y u cầu, hệ thống vẫn giữ vững khi y u cầu ngư i dùng thay đổi Phương pháp hướng đối tượng xem một phần của thế giới thực như các đối tượng Máy điện thoại, xe ô tô, con ngư i … là các đối tượng Các đối tượng này lại bao gồm nhiều đối tượng khác như xe ô

tô c tay lái, bánh xe, … con ngư i c tay, chân, m t, mũi … Đối tượng thế giới thực c thế c cấu trúc rất phức tạp, làm cho con ngư i kh nhận thức được chúng Trong cuộc sống hàng ngày ta đơn giản h a đối tượng khi suy nghĩ, hay n i cách khác ta làm việc với

mô hình Thí dụ, quả địa cầu là mô hình của trái đất Mô hình chỉ lựa ch n một vài khía cạnh c ý nghĩa cho việc thực hiện công việc cụ thể nào đ Chúng cho phép dự đoán, hiểu các khía cạnh của vấn đề đang quan tâm Thí dụ khi làm việc với đối tượng con ngư i: trong sổ lương c t n, số bảo hiểm x hội và tiền lương Nhưng trong sổ điện thoại lại chỉ c t n, số điện thoại và địa chỉ Vậy, mô hình là bức tranh hay mô tả của vấn đề đang được cố g ng giải quyết hay biểu diễn Mô hình còn c thể là mô tả chính giải pháp Trong phát triển phần mềm, thay cho đối tượng thực, ta sẽ làm việc với biểu tượng (hình 1.7) Tiến trình phát triển phần mềm là làm giảm một số đ c trưng của đối tượng để hình thành mô hình: làm giảm độ phức tạp b ng mô hình tr u tượng

Hình 1.7 Mô hình thế giời thực Phương pháp luận (methodology) Phương pháp luận mô tả cách thức suy nghĩ

về phần mềm và phát triển phần mềm N bao gồm ngôn ngữ mô hình h a metamodel

(mô hình của mô hình) và tiến trình Phương pháp luận khác với phương pháp Phương

pháp luận là nghi n cứu phương pháp Metamodel mô tả hình thức các phần tử mô hình,

cú pháp và ngữ nghĩa của các ký pháp trong mô hình

Lĩnh vực vấn đề (domain problem) Mục ti u của tiếp cận hướng đối tượng là mô

hình h a các đ c tính tĩnh và động của môi trư ng, nơi xác định y u cầu phần mềm Môi trư ng này được g i là lĩnh vực vấn đề Vấn đề là câu hỏi đ t ra để giải quyết ho c xem xét Lĩnh vực là không gian (vùng) của các hoạt động ho c ảnh hưởng N là vùng tác nghiệp hay kinh nghiệm của con ngư i trong đ phần mềm được sử dụng Vậy, lĩnh vực vấn đề là vùng mà ta đang cố g ng xem xét Thí dụ của lĩnh vực vấn đề c thể là tài chính, giáo dục,…

Trang 21

Phân tích ( nalysis) Phân tích là tách, chia nhỏ tổng thể thành các phần để tìm

ra đ c tính, chức n ng, quan hệ… của chúng (t điển Webster‟s) Khái niệm phân tích trong tiếp cận hướng đối tượng là thực hiện nghi n cứu lĩnh vực vấn đề, dẫn tới đ c tả hành vi quan sát t ngoài và các thông báo nhất quán, hoàn chỉnh, khả thi của những cái cần COAD91 Phân tích hướng đối tượng tập trung vào tìm kiếm, mô tả các đối tượng (khái niệm) trong lĩnh vực vấn đề Thí dụ hệ thống thư viện c khái niệm Sách, Thư viện

…

Thiết kế(Design) Là tập tài liệu kỹ thuật toàn bộ, gồm c bản tính toán, bản vẽ…

để c thể theo đ mà xây dựng công trình, sản xuất thiết bị, làm sản phẩm… PHE96 Khái niệm phân tích trong tiếp cận hướng đối tượng là thực hiện đ c tả các hành vi b n ngoài, bổ sung chi tiết nếu cần thiết để cài đ t hệ thống tr n máy tính, bao gồm tương tác ngư i - máy, quản lý nhiệm vụ, quản lý dữ liệu COAD91 Thiết kế hướng đối tượng tập trung vào xác định đối tượng phần mềm logic sẽ được cài đ t b ng ngôn ngữ hướng đối tượng

Xây dựng (lập trình) hướng đối tượng: là thiết kết các modun sẽ được cài đ t

Thí dụ lớp Book sẽ được cài đ t b ng C++, Java … như thế nào

Mô hình h a (modeling)

Mục ti u của giai đoạn phân tích hệ thống là sản xuất ra một mô hình tổng thể của hệ thống cần xây dựng Mô hình này cần phải được trình bày theo hướng nhìn (View) của khách hàng hay ngư i sử dụng và làm sao để h hiểu được Mô hình này cũng c thể được sử dụng để xác định các y u cầu của ngư i dùng đối với hệ thống và qua đ giúp chúng ta đánh giá tính khả thi của dự án

Tầm quan tr ng của mô hình đ được lĩnh hội một cách thấu đáo trong hầu như tất cả các ngành khoa h c kỹ thuật t nhiều thế k nay Bất kỳ ở đâu, khi muốn xây dựng một vật thể nào đ , đầu ti n ngư i ta đ tạo n n các bản vẽ để quyết định cả ngoại hình lẫn phương thức hoạt động của n Chẳng hạn các bản vẽ kỹ thuật thư ng

g p là một dạng mô hình quen thuộc Mô hình nhìn chung là một cách mô tả của một vật thể nào đ Vật đ c thể tồn tại trong một số giai đoạn nhất định, dù đ là giai đoạn thiết kế hay giai đoạn xây dựng ho c chỉ là một kế hoạch Nhà thiết kế cần phải tạo ra các mô hình mô tả tất cả các khía cạnh khác nhau của sản phẩm Ngoài ra, một mô hình

c thể được chia thành nhiều hướng nhìn, m i hướng nhìn trong số chúng sẽ mô tả một khía cạnh ri ng biệt của sản phẩm hay hệ thống cần được xây dựng Một mô hình cũng

c thể được xây dựng trong nhiều giai đoạn và ở m i giai đoạn, mô hình sẽ được bổ sung

th m một số chi tiết nhất định

Mô hình thư ng được mô tả trong ngôn ngữ trực quan, điều đ c nghĩa là đa phần các thông tin được thể hiện b ng các ký hiệu đồ h a và các kết nối giữa chúng, chỉ khi cần thiết một sốthông tin mới được biểu diễn ở dạng v n bản; Theo đúng như câu ngạn ngữ "Một bức tranh n i nhiều hơn cả ngàn t " Tạo mô hình cho các hệ thống phần mềm trước khi thực sự xây dựng n n chúng, đ trở thành một chuẩn mực trong việc phát triển phần mềm và được chấp nhận trong cộng đồng làm phần mềm giống như trong bất kỳ một ngành khoa h c kỹ thuật nào khác Việc biểu diễn mô hình phải thoã

m n các yếu tố sau:

- Chính xác (accurate): Mô tả đúng hệ thống cần xây dựng

Trang 22

- Đồng nhất (consistent): Các view khác nhau không được mâu thuẩn với nhau

- C thể hiểu được (understandable): Cho những ngư i xây dựng lẫn sử dụng

- Dễ thay đổi (changeable)

- Dễ dàng li n lạc với các mô hình khác

C thể n i th m r ng mô hình là một sự đơn giản hoá hiện thực Mô hình được xây dựng n n để chúng ta dễ dàng hiểu và hiểu tốt hơn hệ thống cần xây dựng Tạo mô hình sẽ giúp cho chúng ta hiểu thấu đáo một hệ thống phức tạp trong sự toàn thể của n

Nói tóm lại, mô hình hóa một hệ thống nhằm mục đích:

- Hình dung một hệ thống theo thực tế hay theo mong muốn của chúng

ta

- Chỉ rõ cấu trúc ho c ứng xử của hệ thống

- Tạo một khuôn mẫu hướng dẫn nhà phát triển trong suốt quá trình xây dựng hệ thống

- Ghi lại các quyết định của nhà phát triển để sử dụng sau này

Mô hình h a trực quan Mô hình h a trực quan là tiến trình lấy thông tin t mô

hình và hiển thị đồ h a b ng tập các phần t đồ h a chuẩn Ti u chuẩn là cốt lõi để thực hiện một trong các lợi thế của mô hình trực quan, đ là vấn đề giao tiếp Giao tiếp giữa ngư i dùng, ngư i phát triển, phân tích vi n, kiểm tra vi n, ngư i quản lý và những ngư i khác tham gia dự án là mục ti u quan tr ng nhất của mô hình h a trực quan Tương tác này c thể được thực hiện b ng v n bản Nh mô hình trực quan mà ta c thể

chỉ ra các t n mà hệ thống làm việc, bao gồm tương tác giữa ngư i dùng với hệ thống,

tương tác giữa các đối tượng trong hệ thống hay giữa các hệ thông với nhau Sau khi tạo

mô hình, ta c thể chỉ ra t ng phần quan tâm Thí dụ, ngư i dùng c thể quan sát tương tác giữa h với hệ thông t mô hình, phân tích vi n quan sát tương tác các đối tượng t

mô hình, ngư i phát triển sẽ quan sát được đối tượng mà h sẽ phát triển… Các nhà tin

h c đ rất cố g ng để hình thành ký pháp mô hình h a trực quan Một số ký pháp quen

thuộc là của Booch, OMT và UML Phần mềm công cụ Rational Rose 2000 trợ giúp các

ký pháp này T m lại, lý do cơ bản để mô hình h a là: xây dựng mô hình để hiểu sâu s c hơn về hệ thống đang được xây dựng Chúng ta xây dưng mô hình cho các hệ thống phức tạp vi ta không thể hiểu n như tổng thể Nh mô hình h a ta sẽ đạt được các mục ti u sau:

 Mô hình giúp ta hiển thị hệ thống như chính n hay như cách mà ta muốn n hiển thị

 Mô hình cho phép ta đ c tả cấu trúc hay hành vi hệ thống

 Mô hình cho ta mấu để hướng đẫn trong việc xây dựng hệ thống

 Mô hình giúp ta làm tài liệu cho các quyết định khi phân tích thiết kế hệ thống

Trang 23

1.6 Ưu, nhược điểm của mô hình hướng đối tượng

 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 đ

1.7 Các bước phân tích thiết kế hướng đối tượng

 Phân tích hướng đối tượng (Object Oriented nalysis - OOA):

Là giai đ an phát triển một mô hình chính xác và súc tích của vấn đề, c thành phần là các đối tượng và khái niệm đ i thực, dễ hiểu đối với ngư i sử dụng

Trong giai đoạn OOA, vấn đề được trình bày b ng các thuật ngữ tương ứng với các đối tượng c thực Th m vào đ , hệ thống cần phải được định nghĩa sao cho ngư i không chuy n Tin h c c thể dễ dàng hiểu được

Dựa tr n một vấn đề c sẵn, nhà phân tích cần ánh xạ các đối tượng hay thực thể

c thực như khách hàng, ô tô, ngư i bán hàng, … vào thiết kế để tạo ra được bản thiết kế gần cận với tình huống thực Mô hình thiết kế sẽ chứa các thực thể trong một vấn đề c thực và giữ nguy n các mẫu hình về cấu trúc, quan hệ cũng như hành vi của chúng N i một cách khác, sử dụng phương pháp hướng đối tượng chúng ta c thể

mô hình h a các thực thể thuộc một vấn đề c thực mà vẫn giữ được cấu trúc, quan hệ cũng như hành vi của chúng

Đối với ví dụ một phòng bán ô tô, giai đoạn OOA sẽ nhận biết được các thực thể như:

Tương tác và quan hệ giữa các đối tượng tr n là:

- Ngư i bán hàng dẫn khách hàng tham quan phòng trưng bày xe

- Khách hàng ch n một chiếc xe

- Khách hàng viết phiếu đ t xe

Trang 24

- Khách hàng trả tiền xe

- Xe ô tô được giao đến cho khách hàng

Đối với ví dụ nhà b ng lẻ, giai đoạn OOA sẽ nhận biết được các thực thể như:

- Loại tài khoản: ATM (rút tiền tự động), Savings (tiết kiệm), Current (bình thư ng), Fixed (đầu tư),

- Khách hàng

- Nhân viên

- Phòng máy tính

Tương tác và quan hệ giữa các đối tượng tr n:

- Một khách hàng mới mở một tài khoản tiết kiệm

- Chuyển tiền t tài khoản tiết kiệm sang tài khoản đầu tư

- Chuyển tiền t tài khoản tiết kiệm sang tài khoản ATM

Xin chú ý là ở đây, như đ n i, ta chú ý đến cả hai khía cạnh: thông tin và cách hoạt động của hệ thống (tức là những gì c thể xảy ra với những thông tin đ )

Lối phân tích b ng kiểu ánh xạ "đ i thực” vào máy tính như thế thật sự là ưu điểm lớn của phương pháp hướng đối tượng

 Thiết kế hướng đối tượng (Object Oriented Design - OOD):

Là giai đoạn tổ chức chương trình thành các tập hợp đối tượng cộng tác, m i đối tượng trong đ là thực thể của một lớp Các lớp là thành vi n của một cây cấu trúc với mối quan hệ th a kế

Mục đích của giai đoạn OOD là tạo thiết kế dựa tr n kết quả của giai đoạn OOA, dựa tr n những quy định phi chức n ng, những y u cầu về môi trư ng, những y u cầu

về khả n ng thực thi, OOD tập trung vào việc cải thiện kết quả của OOA, tối ưu h a giải pháp đ được cung cấp trong khi vẫn đảm bảo thoả m n tất cả các y u cầu đ được xác lập

Trong giai đoạn OOD, nhà thiết kế định nghĩa các chức n ng, thủ tục (operations), thuộc tính (attributes) cũng như mối quan hệ của một hay nhiều lớp (class)

và quyết định chúng cần phải được điều chỉnh sao cho phù hợp với môi trư ng phát triển Đây cũng là giai đoạn để thiết kế ngân hàng dữ liệu và áp dụng các kỹ thuật ti u chuẩn hóa

Về cuối giai đoạn OOD, nhà thiết kế đưa ra một loạt các biểu đồ (diagram) khác nhau Các biểu đồ này c thể được chia thành hai nh m chính là Tĩnh và động Các biểu

đồ tĩnh biểu thị các lớp và đối tượng, trong khi biểu đồ động biểu thị tương tác giữa các lớp và phương thức hoạt động chính xác của chúng Các lớp đ sau này c thể được nh m thành các g i (Packages) tức là các đơn vị thành phần nhỏ hơn của ứng dụng

 Lập trình hướng đối tượng (Object Oriented Programming - OOP):

Trang 25

Giai đoạn xây dựng phần mềm c thể được thực hiện sử dụng kỹ thuật lập trình hướng đối tượng Đ là phương thức thực hiện thiết kế hướng đối tượng qua việc sử dụng một ngôn ngữ lập trình c h trợ các tính n ng hướng đối tượng Một vài ngôn ngữ hướng đối tượng thư ng được nh c tới là C++ , Java, DotNet Kết quả chung cuộc của giai đoạn này là một loạt các code chạy được, n chỉ được đưa vào sử dụng sau khi đ trải qua nhiều vòng quay của nhiều bước thử nghiệm khác nhau

Trang 26

Bài 2: Giới thiệu về UML

2.1 Tổng quát về UML

2.1.1 Giới thiệu về UML

 Trước khi UML ra đời:

Đầu những n m 1980, ngành công nghệ phần mềm chỉ c duy nhất một ngôn ngữ hướng đối tượng là Simula Sang nửa sau của thập k 1980, các ngôn ngữ hướng đối tượng như Smalltalk và C++ xuất hiện Cùng với chúng, nảy sinh nhu cầu mô hình hoá các hệ thống phần mềm theo hướng đối tượng Và một vài trong số những ngôn ngữ

mô hình hoá xuất hiện những n m đầu thập k 90 được nhiều ngư i dùng là:

- Grady Booch‟s Booch Modeling Methodology

- James Rambaugh‟s Object Modeling Technique – OMT

- Ivar Jacobson‟s OOSE Methodology

- Hewlett- Packard‟s Fusion

- Coad and Yordon‟s OOA and OOD

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, khiến nảy ra cuộc tranh luận phương pháp nào là tốt nhất Đây là cuộc tranh luận kh c câu trả l i, bởi tất cả các phương pháp tr n đều c những điểm mạnh và điểm yếu ri ng Vì thế, các nhà phát triển phần mềm nhiều kinh nghiệm thư ng sử dụng phối hợp các điểm mạnh của m i phương pháp cho ứng dụng của mình Trong thực tế, sự khác biệt giữa các phương pháp đ hầu như không đáng kể và theo cùng tiến trình th i gian, tất cả những phương pháp tr n đ tiệm cận lại và bổ sung lẫn cho nhau Chính hiện thực này đ được những ngư i ti n phong trong lĩnh vực mô hình hoá hướng đối tượng nhận ra và h quyết định 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 cho lĩnh vực công nghệ phần mềm

 Sự ra đời của ngôn ngữ UML

Trong bối cảnh tr n, ngư i ta nhận thấy cần thiết phải cung cấp một phương pháp tiệm cận được chuẩn hoá và thống nhất cho việc mô hình hoá hướng đối tượng Y u cầu

cụ thể là đưa ra một tập hợp chuẩn hoá các ký hiệu (Notation) và các biểu đồ (Diagram)

để n m b t các quyết định về m t thiết kế một cách rõ ràng, rành mạch Đ c ba công trình tiên phong nh m tới mục ti u đ , chúng được thực hiện dưới sự l nh đạo của James Rumbaugh, Grady Booch và Ivar Jacobson Chính những cố g ng này dẫn đến kết quả là xây dựng được một Ngôn NgữMô Hình Hoá Thống Nhất (Unifield Modeling Language – UML)

UML là một ngôn ngữ mô hình hoá thống nhất c phần chính bao gồm những ký hiệu hình h c, được các phương pháp hướng đối tượng sử dụng để thể hiện và mi u tả các thiết kế của một hệ thống N là một ngôn ngữ để đ c tả, trực quan hoá, xây dựng

Trang 27

và làm sưu liệu cho nhiều khía cạnh khác nhau của một hệ thống c nồng độ phần mềm cao UML có thể được sử dụng làm công cụ giao tiếp giữa ngư i dùng, nhà phân tích, nhà thiết kế và nhà phát triển phần mềm

Trong quá trình phát triển c nhiều công ty đ h trợ và khuyến khích phát triển UML c thể kể tới như: Hewlett Packard, Microsoft, Oracle, IBM, Unisys

 Ngôn ngữ UML

Ngôn ngữ mô hình h a thống nhất (Unifield Modeling Language – UML) là một ngôn ngữ để biểu diễn mô hình theo hướng đối tượng với chủ đích là:

- 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 một kết nối 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 đề về mức độ th a kế trong các hệ thống phức tạp, c 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

 Phương pháp và các ngôn ngữ mô hình h a

Phương pháp hay phương thức (method) là một cách trực tiếp cấu trúc hoá sự suy nghĩ và hành động của con ngư i Phương pháp cho ngư i sử dụng biết phải làm gì, làm như thế nào, khi nào và tại sao (mục đích của hành động) Phương pháp chứa các mô hình (model), các mô hình được dùng để mô tả những gì sử dụng cho việc truyền đạt kết quả trong quá trình sửdụng phương pháp Điểm khác nhau chính giữa một phương pháp và một ngôn ngữ mô hình hoá (modeling language) là ngôn ngữ mô hình hoá không c một tiến trình (process) hay các câu lệnh (instruction) mô tả những công việc ngư i sử dụng cần làm

Một mô hình được biểu diễn theo một ngôn ngữ mô hình hoá Ngôn ngữ mô hình hoá bao gồm các ký hiệu – những biểu tượng được dùng trong mô hình – và một tập các quy t c chỉ cách sử dụng chúng Các quy t c này bao gồm:

- Syntactic (Cú pháp): cho biết hình dạng các biểu tượng và cách kết hợp chúng trong ngôn ngữ

- Semantic (Ngữ nghĩa): cho biết ý nghĩa của m i biểu tượng, chúng được hiểu thế nào khi n m trong ho c không n m trong ngữ cảnh của các biểu tượng khác

- Pragmatic: định nghĩa ý nghĩa của biểu tượng để sao cho mục đích của mô hình được thể hiện và m i ngư i c thể hiểu được

2.1.2 UML trong phân tích và thiết kế hệ thống

UML c thể được sử dụng trong nhiều giai đoạn, t phát triển, thiết kế cho tới thực hiện và bảo trì Vì mục đích chính của ngôn ngữ này là dùng các biểu đồ hướng đối

Trang 28

tượng để mô tả hệ thống n n miền ứng dụng của UML bao gồm nhiều loại hệ thống khác nhau như:

- Hệ thống thống tin (Information System): Cất giữ, lấy, biến đổi biểu diễn thông

tin cho ngư i sử dụng Xử lý những khoảng dữ liệu lớn c các quan hệ phức tạp , mà chúng được lưu trữ trong các cơ sở dữ liệu quan hệ hay hướng đối tượng

- Hệ thống kỹ thuật (Technical System): Xử lý và điều khiển các thiết bị kỹ thuật

như viễn thông, hệ thống quân sự, hay các quá trình công nghiệp Đây là loại thiết bị phải

xử lý các giao tiếp đ c biệt , không c phần mềm chuẩn và thư ng là các hệ thống th i gian thực (real time)

- Hệ thống nhúng (Embeded System): Thực hiện tr n phần cứng g n vào các thiết

bị như điện thoại di động, điều khiển xe hơi, … Điều này được thực hiện b ng việc lập trình mức thấp với h trợ th i gian thực Những hệ thống này thư ng không c các thiết

bị như màn hình đĩa cứng, …

- Hệ thống phân bố ( Distributed System): Được phân bố tr n một số máy cho

phép truyền dữ liệu t nơi này đến nơi khác một cách dễ dàng Chúng đòi hỏi các cơ chế

li n lạc đồng bộ để đảm bảo toàn vẹn dữ liệu và thư ng được xây dựng tr n một số các

kỹ thuật đối tượng như CORBA, COM/DCOM, hay Java Beans/RMI

- Hệ thống Giao dịch (Business System): Mô tả mục đích, tài nguy n (con ngư i,

máy tính, …), các quy t c (luật pháp, chiến thuật kinh doanh, cơ chế, …), và công việc hoạt động kinh doanh

- Phần mềm hệ thống (System Software): Định nghĩa cơ sở hạ tầng kỹ thuật cho

phần mềm khác sử dụng, chẳng hạn như hệ điều hành, cơ sở dữ liệu, giao diện ngư i sử dụng

UML và các giai đoạn phát triển hệ thống

- Preliminary Investigation: use cases thể hiện các y u cầu của ngư i dùng Phần mi u tả use case xác định các y u cầu, phần diagram thể hiện mối quan hệ và giao tiếp với hệ thống

- Analysis: Mục đích chính của giai đ an này là tr u tượng h a và tìm hiểu các cơ cấu c trong phạm vi bài toán Class diagrams tr n bình diện tr u tượng h a các thực thể ngoài đ i thực được sử dụng để làm rõ sự tồn tại cũng như mối quan hệ của chúng Chỉ những lớp (class) n m trong phạm vi bài toán mới đáng quan tâm

- Design: Kết quả phần analysis được phát triển thành giải pháp kỹ thuật Các lớp được mô hình h a chi tiết để cung cấp hạ tầng kỹ thuật như giao diện, nền tảng cho database, … Kết quả phần Design là các đ c tả chi tiết cho giai đoạn xây dựng phần mềm

- Development: Mô hình Design được chuyển thành code Programmer sử dụng các UML diagrams trong giai đoạn Design để hiểu vấn đề và tạo code

Trang 29

- Testing: Sử dụng các UML diagrams trong các giai đoạn trước C 4 hình thức kiểm tra hệ thống:

o Unit testing (class diagrams & class specifications): kiểm tra t ng đơn thể, được dùng để kiểm tra các lớp hay các nh m đơn thể

o Integration testing (integration diagrams & collaboration diagrams): kiểm tra tích hợp là kiểm tra kết hợp các component với các lớp để xem chúng hoạt động với nhau c đúng không

o System testing (use-case diagrams): kiềm tra xem hệ thống c đáp ứng được chức n ng mà ngư i sử dụng y u cầu hay không

o Acceptance testing: Kiểm tra tính chấp nhận được của hệ thống, thư ng được thực hiện bởi khách hàng, việc kiểm tra này thực hiện tương tự như kiểm tra hệ thống

2.1.3 UML và quy trình phát triển phần mềm

1- Giai đoạn nghiên cứu sơ bộ:

UML đưa ra khái niệm Use Case để n m b t các y u cầu của khách hàng (ngư i

sử dụng) UML sử dụng biểu đồ Use case (Use Case Diagram) để n u bật mối quan hệ cũng như sự giao tiếp với hệ thống

Qua phương pháp mô hình h a Use case, các tác nhân (Actor) b n ngoài quan tâm đến hệ thống sẽ được mô hình h a song song với chức n ng mà h đòi hỏi t phía hệ thống (tức là Use case) Các tác nhân và các Use case được mô hình h a cùng các mối quan hệ và được mi u tả trong biểu đồ Use case của UML M i một Use case được mô

tả trong tài liệu, và n sẽ đ c tả các y u cầu của khách hàng: Anh ta hay chị ta ch đợi điều gì ở phía hệ thống mà không hề để ý đến việc chức n ng này sẽ được thực thi

ra sao

2- Giai đoạn phân tích:

Giai đoạn phân tích quan tâm đến quá trình tr u tượng h a đầu ti n (các lớp và các đối tượng) cũng như cơ chế hiện hữu trong phạm vi vấn đề Sau khi nhà phân tích đ nhận biết được các lớp thành phần của mô hình cũng như mối quan hệ giữa chúng với nhau, các lớp cùng các mối quan hệ đ sẽ được mi u tả b ng công cụ biểu đồ lớp (class diagram) của UML Sự cộng tác giữa các lớp nh m thực hiện các Use case cũng sẽ được mi u tả nh vào các mô hình động (dynamic models) của UML Trong giai đoạn phân tích, chỉ duy nhất các lớp c tồn tại trong phạm vi vấn đề (các khái niệm đ i thực)

là được mô hình h a Các lớp kỹ thuật định nghĩa chi tiết cũng như giải pháp trong hệ thống phần mềm, ví dụ như các lớp cho giao diện ngư i dùng, cho ngân hàng dữ liệu, cho sự giao tiếp, trùng hợp, v.v , chưa phải là mối quan tâm của giai đoạn này

3- Giai đoạn thiết kế:

Trong giai đoạn này, kết quả của giai đoạn phân tích sẽ được mở rộng thành một giải pháp kỹ thuật Các lớp mới sẽ được bổ sung để tạo thành một hạ tầng cơ sở kỹ thuật: Giao diện ngư i dùng, các chức n ng để lưu trữ các đối tượng trong ngân hàng

dữ liệu, giao tiếp với các hệ thống khác, giao diện với các thiết bị ngoại vi và các máy

Trang 30

m c khác trong hệ thống, Các lớp thuộc phạm vi vấn đề c t giai đoạn phân tích sẽ được "nhúng" vào hạ tầng cơ sở kỹ thuật này, tạo ra khả n ng thay đổi trong cả hai phương diện: Phạm vi vấn đề và hạ tầng cơ sở Giai đoạn thiết kế sẽ đưa ra kết quả là bản đ c tả chi tiết cho giai đoạn xây dựng hệ thống

4- Giai đoạn xây dựng:

Trong giai đoạn xây dựng (giai đoạn lập trình), các lớp của giai đoạn thiết kế sẽ được biến thành những dòng code cụ thể trong một ngôn ngữ lập trình hướng đối tượng

cụ thể (không n n dùng một ngôn ngữ lập trình hướng chức n ng!) Phụ thuộc vào khả

n ng của ngôn ngữ được sử dụng, đây c thể là một công việc kh kh n hay dễ dàng Khi tạo ra các mô hình phân tích và thiết kế trong UML, tốt nhất n n cố g ng né tránh việc ngay lập tức biến đổi các mô hình này thành các dòng code Trong những giai đoạn trước, mô hình được sử dụng để dễ hiểu, dễ giao tiếp và tạo n n cấu trúc của hệ thống;

vì vậy, vội vàng đưa ra những kết luận về việc viết code c thể sẽ thành một trở ngại cho việc tạo ra các mô hình chính xác và đơn giản Giai đoạn xây dựng là một giai đoạn ri ng biệt, nơi các mô hình được chuyển thành code

5- Thử nghiệm:

Như đ trình bày trong phần Chu Trình Phát Triển Phần Mềm, một hệ thống phần mềm thư ng được thử nghiệm qua nhiều giai đoạn và với nhiều nh m thử nghiệm khác nhau Các nh m sử dụng nhiều loại biểu đồ UML khác nhau làm nền tảng cho công việc của mình: Thử nghiệm đơn vị sử dụng biểu đồ lớp (class diagram) và đ c

tả lớp, thử nghiệm tích hợp thư ng sử dụng biểu đồ thành phần (component diagram) và biểu đồ cộng tác (collaboration diagram), và giai đoạn thử nghiệm hệ thống sử dụng biểu đồ Use case (use case diagram) để đảm bảo hệ thống c phương thức hoạt động đúng như đ được định nghĩa t ban đầu trong các biểu đồ này

2.2 Mô hình khái niệm của UML

Để hiểu được UML ta phải hình dung được mô hình khái niệm của ngôn ngữ N đòi hỏi n m được ba vấn đề chính, bao gồm các phần tử cơ bản để xây dựng mô hình, quy t c li n kết các phần tử mô hình và một số cơ chế chung sử dụng cho ngôn ngữ Khi

n m vững được các vấn đề này thì ta c thể đ c được mô hình UML và tạo ra một vài mô hình cơ bản

2.2.1 Phần tử mô hình trong UML

Các khối hình thành mô hình UML gồm ba loại như sau: phần tử, quan hệ và biểu

đồ Phần tử là tr u tượng c n bản trong mô hình, các quan hệ g n các phần tử này lại với nhau; còn biểu đồ nh m tập hợp các phần tử Trong UML c bốn loại phần tử mô hình,

đ là cấu trúc, hành vi, nh m và chú thích Các phần tử này là các khối để xây dựng hướng đối tượng cơ bản của UML

 Phần tử cấu trúc

Phần t cấu trúc là các danh t trong mô hình UML Chúng là bộ phận tĩnh của

mô hình để biểu diễn các thành phần khái niệm hay vật lý C bảy loại phẩn tử cấu trúc như mô tả sau đây:

Trang 31

1- Lớp Lớp mô tả tập các đối tượng cùng chung thuộc tinh, thao tác, quan hệ

và ngữ nghĩa Một lớp cài đ t một hay nhiều ghép nối Hình 2.1 biểu diễn

đồ h a lớp b ng hình chữ nhật, thông thư ng chú c t n, thuộc tính và thao tác

2- Giao diện Giao diện là tập hợp các thao tác làm dịch vụ của lớp hay thành

phần Giao diện mô tả hành vi thấy được t ngoài của thành phần Giao diện biểu diễn toàn bộ hay một phần hành vi của lớp Giao diện định nghĩa tập đ c tả thao tác chứ không định nghĩa cài đ t của chúng Ký pháp đồ h a của n được mô tả tr n hình 2.2 Giao diện thư ng không đứng một mình

mà được g n vào lớp hay thành phần thực hiện giao diện

3- Phần tử cộng tác Phần tử cộng tác là mô tả ngữ cảnh của tương tác Ký

pháp đồ h a của n là hình elíp với đư ng vẽ nét đứt, kèm theo t n như tr n hình 2.3 Phần tử cộng tác thể hiện một giải pháp thi hành b n trong hệ thống, bao gồm các lớp, quan hệ và tương tác giữa chúng để đạt được một chức n ng mong đợi của UC

n n t Hình 2.4 Use case

4- Trường hợp sử dụng (Use case) Mô tả chình tự các hành động mà hệ

thống sẽ thực hiện để đạt được một kết quả cho tác nhân nào đ Tác nhân

là những gì b n ngoài tương tác với hệ thống Tập hợp các UC của hệ thống

sẽ hình thành các trư ng hợp mà hệ thống được sử dụng Sử dụng UC để cấu trúc các phần tử c tính hành vi trong mô hình N được hiện thực h a bởi phần tử cộng tác như v a mô tả tr n Hình 2.4 là ký pháp đồ h a của

UC

5- Lớp tích cực (active class) Lớp tích cực là lớp c đối tượng làm chủ một

hay nhiều lớp tiến trình hay luồng Lớp tích cực được xem như lớp thông thư ng nhưng đối tượng của n biểu diễn các thành phần c hành vi đang tương tranh với các thành phần khác Ký pháp đồ h a của n tương tự lớp thông thư ng nhưng bi n chữ nhật được tô đậm Thông thư ng chúng cũng

c t n, thuộc tính và thao tác

Interface

Trang 32

6- Thành phần (Component) Thành phần biểu diễn vật lý m nguồn, các tệp

nhị phân trong quá trình phát triển hệ thống Ký pháp đồ h a của n đươc biểu diễn tr n hình 2.5

7- Nút (node) Nút là thể hiện thành phần vật lý, tồn tại khi chương trình chạy

và biểu diễn các tài nguy n tính toán C thể đ t tập các thành phần tr n nút chuyển t nút này sang nút khác Nút c thể là máy tính, thiết bị phần cứng

Ký pháp đồ h a của chúng được mô tả tr n hình 2.6

n .5 Thành ph n (Component) n N t No

 Phần tử hành vi

Phần tử hành vi là bộ phận động của mô hình UML Chúng là các động t của mô hình, biểu diễn hành vi theo th i gian và không gian C hai loại chính là tương tác và trạng thái

1- Tương tác Tương tác là hành vi bao gồm tập các thông điệp trao đổi giữa

các đối tượng trong ngữ cảnh cụ thể để thực hiện mục đích cụ thể Hành vi của nh m đối tượng hay của m i thao tác c thể được chỉ ra b ng tương tác Biểu diễ đồ h a của thông điệp được thể hiện như tr n hình 2.7, bao gồm mũi t n và t n thao tác của n

n n p Hình 2.8 Trạng thái

2- Máy trạng thái Máy trạng thái là hành vi chỉ ra trật tự các trạng thái mà

đối tượng hay tương tác sẽ đi qua để đáp ứng sự kiện Hành vi của lớp hay cộng tác của lớp c thể được xác định b ng máy trạng thái Máy trạng thái kích hoạt nhiều phần tử, bao gồm trạng thái, chuyển tiếp (t trạng thái này sang trạng thái khác), sự kiện và các hoạt động (đáp ứng sự kiện) Ký pháp

đồ h a của trạng thái được thể hiện tr n hình 2.8, n chứa t n và trạng thái con nếu c

 Phần tử nh m

Phần tử nh m là bộ phận tổ chức của mô hình UML Chỉ c một phần tử thuộc

nh m này c t n là g i (package) G i là cơ chế đa n ng để tổ chức các phần tử vào

nh m Các phần tử cấu trúc, hành vi và ngay cả phần tử nh m c thể cho vào g i Không

giống thành phần (component), phần tử nh m hoàn toàn là khái niệm, c nghĩa r ng

chúng chỉ tồn tại vào th i điểm phát triển hệ thống chứ không tồn tại vào th i gian chạy

Trang 33

chương trình Ký pháp đồ h a của nh m được biểu diễn tr n hình 2.9 g i giúp ta quan

sát hệ thống ở mức tổng quan hơn

Chú thích (annotaitonal)

Phần tử chú thích là bộ phận chú giải của mô hình UML Đ là l i giải thích áp

dụng để mô tả các phần tử khác trong mô hình Phần tử chú thích được g i là ghi chú

(note) Ký pháp đồ h a của chúng thể hiện tr n hình 2.9

Hình 2.9 Nhóm và lời ghi ch 2.2.2 Các quan hệ trong UML

C bốn loại quan hệ trong UML, bao gồm quan hệ phụ thuộc, kết hợp, khái quát

và hiện thực h a Chúng là cơ sở đễ xây dựng m i quan hệ trong UML

1- Phụ thuộc (dependency) Phục thuộc là quan hệ ngữ nghĩa hai phần tử trong đ

thay đổi phần tử độc lập sẽ tác động đến ngữ nghĩa của phần tử phục thuộc Ký

pháp đồ h a của n được thể hiện tr n hình 2.10

n ụ thu c n K t p

2- Kết hợp (association) Kết hợp là quan hệ cấu trúc để mô tả tập li n kết (một li n

kết là kết nối giữa các đối tượng) Khi đối tượng của lớp này gửi/nhận thông điệp

đến/t đối tượng của lớp kia thì ta g i chúng là c quan hệ kết hợp Ký pháp đồ

h a của kết hợp được mô tả tr n hình 2.11 chúng c thể chứa t n nhiệm vụ và tính

nhiều (multiplicity) Tụ hợp (aggregation) là dạng đ c biệt của kết hợp, n biểu

diễn quan hệ cấu trúc giữa toàn thể và bộ phận Ký pháp đồ h a của n tr n hình

2.12 một dạng d c biệt của tụ hợp là quan hệ hợp thành (composition), trong đ

nếu như đối tượng toàn thể bị hủy bỏ thì các đối tượng bộ phận của n cũng bị hủy

bỏ theo Biểu diễn đồ h a của tập hợp như tr n hình 2.13

n ụ p n p t n

3- Khái quát h a (generalization) Khái quát h a là quan hệ đ c biệt h a/ khái quát

h a mà trong đ đối tượng cụ thể sẽ kế th a các thuộc tính và phương pháp của

đối tượng tổng quát Ký pháp đồ h a của khái quát h a được mô tả tr n hình 2.14

Các luật thương mại

Đây là chú thích

0 1

Ông chủ Nhân viên

n

Trang 34

n K qu t Hình 2.15 Hiện thực

4- Hiện thực h a (realization) Hiện thực h a là quan hệ ngữ nghĩa giữa giao diện

và lớp (hay thành phần) hiện thực lớp; giữa UC và hợp tác hiện thực UC Biểu

diễn đồ h a của n dược mô tả tr n hình 2.15

2.2.3 Kiểu dữ liệu

Kiểu dữ liệu không phải là phần tử mô hình trong UML Kiểu dữ liệu cơ sở là kiểu

dữ liệu không c cấu trúc UML c các kiểu dữ liệu sau:

- Boolean: là kiểu đếm với hai giá trị True và False

- u t xpr ss on là xâu ký tự c cú pháp

- n n u Mult pl ty là tập không r ng của các số nguy n dương và ký

tự * (để biểu thị tính nhiều vô hạn)

- Tên (Name): là xâu ký tự cho khả n ng đ c tả phẩn tử

- n uy n nt r là kiểu cơ bản và là phần tử của tập vô hạn các sô

nguy n âm và dương

- Xâu (String): là trật tự cảu các ký tự, được sử dụng là t n

- n m xâu ký tự biểu dirn giá trị tuyệt đối hay khoảng tương

Trang 35

Thành phần mô hình chính trong UML là các biểu đồ:

 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ì để thỏa 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 chỉ ra các lớp đối tượng 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 đồ 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 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 bi n ngoài C hai loại biểu đồ tương tác:

o 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

o Biểu đồ cộng tác: Biểu diễn mối quan hệ giữa các đối tượng và giữa các

đối tượng và các 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 đồi 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 h a 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:

o Biều đồ g i

o Biểu đồ đối tượng và lớp

o Biểu đồ thành phần

o Biểu đồ triển khai

 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ử bi n trong và

b n ngoài hệ thống Các dạng biểu đồ trong mô hình động bao gồm:

o Biểu đồ use case

Trang 36

o Biểu đồ tương tác dạng tuần tự

sử dụng cuối cùng, nhà phân tích, ngư i phát triển, ngư i tích hợp hệ thống, kiểm tra

vi n, ngư i quản lý dự án …) c cách quan sát hệ thống khác nhau vào các th i điểm

khác nhau Kiến trúc hệ thống là v t p m quan tr ng nhất, được sử dụng để quản lý các

điểm nhìn khác nhau để điều khiển phát triển hệ thống t ng dần và l p trong suốt chu kỳ sống Kiến trúc là tập các quyết định về:

Tổ chức của hệ thống phần mềm

Lựa ch n các phần tử cấu trúc và giao diện cho hệ thống

Hành vi của chúng thể hiện trong hợp tác giữa các phần tử

Tổ hợp các phần tử cấu trúc và hành vị vaò hệ thống con lớn hơn

Kiến trúc phần mềm không chỉ li n quan đến cấu trúc và hành vi mà cả chức n ng, tính sử dụng lại, dễ hiểu, ràng buộc công nghệ …

Hình 3.1 Mô hình hóa kiến tr c hệ thống

Trang 37

Kiến trúc hệ thống phần mềm được mô tả b ng các khung nhìn Các khung nhìn ánh xạ vào tổ chức và cấu trúc hệ thống, m i khung nhìn tập trung vào khía cạnh cụ thể của hệ thống (hình 3.1)

Theo biểu đồ của Philippe Krutchen LIBE98 ta c n m khung nhìn như sau: khung nhìn trư ng hợp sử dụng (Use case view), khung nhìn logic (Logical view), khung nhìn cài đ t (Implementation view), khung nhìn triển khai (Deployment view) và khung nhìn tiến trình (Process view) M i khung nhìn phục vụ mục đích ri ng

2.4.1 Khung nhìn Use case

Khung nhìn này đứng trước m i khung nhìn khác (hình 3.1) N được hình thành

t giai đoạn phân tích y u cầu và được sử dụng để điều khiển và thúc đẩy phần việc còn lại của thiết kế N mô tả các hành vi hệ thống theo cách nhìn của khách hàng, phân tích

vi n và kỹ sư kiểm tra, thử nghiệm Khung nhìn UC chứa các tác nhân, UC, biểu đồ UC (khía cạnh tĩnh của khung nhìn) trong hệ thống Chúng cũng c thể bao gồm vài biểu đồ trình tự, biểu đồ cộng tác (khía cạnh động của khung nhìn) và g i Khung nhìn UC tập trung vào mức độ cao của cái hệ thông sẽ làm, không quan tâm đến hệ thống làm như thế nào Chúng không xác định tổ chức của hệ thống

Khi dự án b t đầu, khách hàng, phân tích vi n và ngư i quản lý dự án làm việc với

UC, biểu đồ UC và tài liệu UC để thống nhất về hệ thống Một khi khách hàng đ nhất trí

về các UC và tác nhân thì h sẽ nhất trí về phạm vi hệ thống Hệ thống được tiếp tục phát triển b ng khung nhìn logic

2.4.2 Khung nhìn thiết kế

Khung nhìn thiết kế là khung nhìn logical view Khung nhìn logic biểu diễn tổ

chức của các lớp c ý nghĩa nhất và các quan hệ của chúng với nhau Khung nhìn logic tập trung vào hệ thống cài đ t hành vi trong UC như thế nào N bao gồm các lớp, biểu

đồ lớp, biểu đồ đối tượng (khía cạnh tĩnh của khung nhìn), biểu đồ tương tác, biểu đồ biến đổi trạng thái (khía cạnh động của khung nhìn) và các g i Hầu hết m i ngư i trong

dự án đều quan tâm đến khung nhìn logic

Thông thư ng đội ngũ phát triển phần mềm tiệm cận khung nhìn logic theo hai

bước Bước thứ nhất là nhận ra các lớp phân tích (analysis class) Các lớp này độc lập

với ngôn ngữ Trong UML các lớp này được biểu diễn b ng các biểu tượng sau:

Lớp phân tích c thể xuất hiện cả ở trong biểu đồ tương tác của khung nhìn UC Một khi đ nhận ra các lớp phân tích thì đội ngũ phát triển phần mềm chuyển chúng sang

lớp thiết kế (design class) Đ là những lớp phụ thuộc ngôn ngữ

Khung nhìn logic tập trung vào cấu trúc logic của hệ thống Trong khung nhìn này

ta sẽ nhận ra các p n hệ thống, khảo sát thông tin và hành vi, khảo sát quan hệ giữa

các bộ phận Cần cẩn thận khi gán thông tin và hành vi cho lớp, nh m các lớp, khảo sát quan hệ giữa các lớp và g i để đảm bảo khả n ng sử dụng lại

Trang 38

2.4.3 Khung nhìn cài đặt

Khung nhìn cài đ t là khung nhìn component view Thành phần là mođun vật lý

hay tiệp m trình để l p ráp thành hệ thống vật lý Khung nhìn thành phần bao gồm: thành phần, biểu đồ thành phần và g i

Ngư i quan tâm nhất đến khung nhìn thành phần là ngư i c trách nhiệm quản lý

m trình, dích chương trình và triển khai ứng dụng Một vài thành phần là thư viện, một

số khác là m trình khả thực (exe) và thư viện (dll)

2.4.4 Khung nhìn triển khai

Khung nhìn này tập trung vào phân bổ vật lý của tài nguy n và phân bổ nhiệm vụ giữa các tài nguy n Khung nhìn triển khai li n quan đến triển khai vật lý của hệ thống, khác với kiến trục logic Thí dụ, hệ thống c kiến trúc ba tầng logic, bao gồm giao diện, logic và tác nghiệp và logic CSDL tách biệt nhau Nhưng triển khai c thể chỉ c hai tầng, trong đ logic tác nghiệp và logic CSDL tr n cùng một máy Khung nhìn triển khai bao gồm tiến trình (luông thực hiện trong vùng nhớ ri ng), bộ xử lý và thiết bị

Khung nhìn triển khai chỉ ra các tiến trình và thiết bị tr n mạng và các kết nối vật

lý giữa chúng Biểu đồ triển khai cũng hiển thị tiến trình và chỉ ra tiến trình nào chạy tr n máy nào

2.4.5 Khung nhìn tiến trình

Khung nhìn tiến trình biểu diễn phân tách các luồng thực hiện chương trình (tiến

trình – process, luồng – thread, nhiệm vụ – task,…), đồng bộ giữa các luồng, phân bổ các

đối tượng và lớp cho các luồng thực hiện khác nhau Khung nhìn tiến trình tập trung vào các nhiệm vụ tương tranh tương tác với nhau như thế nào trong hệ thông đa nhiệm

2.4.6 Cần bao nhiêu khung nhìn

Không phải tất cả các hệ thống đều đòi hỏi đầy đủ các khung nhìn mô tả tr n Hệ thống tr n máy ri ng lẻ c thể bỏ khung nhìn triển khai, nếu hệ đơn xử lý thì bỏ khung nhìn tiến trình, nếu chương trình nhỏ thì bỏ khung nhìn cài đ t

2.5 Các biểu đồ trong UML

2.5.1 Biểu đồ use case

Một biểu đồ Use case chỉ ra một số lượng các tác nhân ngoại cảnh và mối li n kết của chúng đối với Use case mà hệ thống cung cấp (nhìn hình 3.2) Một Use case là một l i mi u tả của một chức n ng mà hệ thống cung cấp L i mi u tả Use case thư ng

là một v n bản tài liệu, nhưng kèm theo đ cũng c thể là một biểu đồ hoạt động Các Use case được mi u tả duy nhất theo hướng nhìn t ngoài vào của các tác nhân (hành vi của hệ thống theo như sự mong đợi của ngư i sử dụng), không mi u tả chức n ng được cung cấp sẽ hoạt động nội bộ b n trong hệ thống ra sao Các Use case định nghĩa các y u cầu về m t chức n ng đối với hệ thống Các biểu đồ Use case sẽ được mi u tả chi tiết hơn trong bài sau (Use case)

Ví dụ biểu đồ use case

Trang 39

Dưới đây là một use case cho một hệ thống quản lý bán hàng đơn giản Nhân viên phụ trách kho và nhân vi n bán hàng thông qua đ ng nhập để thực hiện các chức n ng của hệ thống Nhân vi n phụ trách kho thực hiện các chức n ng: Quản lý thông tin nhà cung cấp, quản lý thông tin loại hàng, quản lý thông tin hàng h a, quản lý hoạt động nhập hàng, thống k báo cáo Nhân vi n bán hàng thực hiện chức n ng quản lý bán hàng

Hình 3.2 Biểu đồ use case tổng quát của hệ thống quản lý bán hàng

2.5.2 Biểu đồ lớp

Một biểu đồ lớp chỉ ra cấu trúc tĩnh của các lớp trong hệ thống (nhìn hình 3.3) Các lớp là đại diện cho các “vật” được xử lý trong hệ thống Các lớp c thể quan hệ với nhau trong nhiều dạng thức: li n kết (associated - được nối kết với nhau), phụ thuộc (dependent - một lớp này phụ thuộc vào lớp khác), chuy n biệt h a (specialized - một lớp này là một kết quả chuy n biệt h a của lớp khác), hay đ ng g i ( packaged - hợp với nhau thành một đơn vị) Tất cả các mối quan hệ đ đều được thể hiện trong biểu

đồ lớp, đi kèm với cấu trúc b n trong của các lớp theo khái niệm thuộc tính (attribute) và

Trang 40

thủ tục (operation) Biểu đồ được coi là biểu đồ tĩnh theo phương diện cấu trúc được

mi u tả ở đây c hiệu lực tại bất kỳ th i điểm nào trong toàn bộ vòng đ i hệ thống

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 Biểu đồ lớp được mi u tả chi tiết trong các bài sau

Ví dụ biểu đồ lớp

Dưới đây là ví dụ một phần của biểu đồ lớp trong hệ thống quản lý bán hàng

Hình 3.3 Biểu đồ lớp

2.5.3 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 (hình 3.5) 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ể Biểu đồ trạng thái được mi u tả chi tiết hơn trong chương sau (Mô hình động)

Ví dụ biểu đồ trạng thái

Định dạng
Số trang	133
Dung lượng	3,53 MB