Phân tích thiết kế hướng đối tượng hệ thống quản lý hồ sơ và kết quả học tập

Vì vậy, để xây dựng một phần mềm tốt cần phải chú ý tới các vấn đề chính sau: - Dữ liệu đối tượng và cấu trúc của hệ thống - Những hành vi thể hiện chức năng của hệ thống - Điều khiển hà

lời mở đầu 3

Ch-ơng 1 ph-ơng pháp h-ớng đối t-ợng 5

1.1 Quy trình chung để phát triển phần mềm h-ớng đối t-ợng 5

1.2 Công cụ hỗ trợ phát triển h-ớng đối t-ợng UML 8

1.3 Đặc tr-ng tiến trình phát triển phần mềm h-ớng đối t-ợng với UML 27

CHƯƠNG 2 GIỚI THIỆU GRASP - CÁC MẪU DÙNG CHO GÁN TRÁCH NHIỆM 31

2.1 Cỏc khỏi niệm cơ bản 31

2.2 Cỏc mẫu trongGRASP : 37

Ch-ơng 3 Xây dựng hệ thống quản lý hồ sơ và kết quả học tập bằng ph-ơng pháp tiếp cận h-ớng đối t-ợng 64

3.1 Mô tả nghiệp vụ 64

3.2 Phân tích ca sử dụng 73

ch-ơng 4 phân tích và cài đặt ch-ơng trình quản lý hồ sơ và kết quả học tập 114

4.1 Kiến trúc hệ thống quản lý hồ sơ và điểm 114

4.2 Kiến trúc hệ thống 114

4.3 Phân tích cài đặt hệ thống quản lý hồ sơ và điểm 115

Kết luận 143

Tài liệu tham khảo 144

LỜI MỞ ĐẦU

Trong những năm gần đây việc ứng dụng và phát triển công nghệ phần mềm là một phần quan trọng trong khâu sản xuất phần mềm Nhiều dự án, nhiều chương trình phần mềm đã được thực hiện nhưng chưa kết thúc hoặc xây dựng xong vẫn không thực hiện được hoặc còn nhiều lỗi không đáp ứng được yêu cầu của người sử dụng Vì vậy, để xây dựng một phần mềm tốt cần phải chú ý tới các vấn đề chính sau:

- Dữ liệu đối tượng và cấu trúc của hệ thống

- Những hành vi thể hiện chức năng của hệ thống

- Điều khiển hành vi tổng thể của hệ thống

Trên thực tế, cấu trúc dữ liệu của hệ thống phải thường xuyên thay đổi theo yêu cầu của người sử dụng Vì vậy, việc khảo sát, phân tích, thiết kế, hệ thống là một công việc hết sức phức tạp, và quan trọng trong quá trình xây dựng và phát triển phần mềm Phân tích bài toán, lựa chọn phương pháp phát triển hệ thống có tính mở, dễ thích nghi, chất lượng cao, giúp cho việc bảo trì hệ thống đỡ tốn kém

Trong các giải pháp phát triển phần mềm hiện nay, giải pháp phát triển phần mềm hướng đối tượng là một giải pháp tốt cho những hệ thống phần mềm, nó có nhiều ưu điểm so với phương pháp hướng chức năng truyền thống khác

Do đó, việc nghiên cứu và vận dụng phương pháp phân tích, thiết kế hướng đối tượng sử dụng UML (UML là ngôn ngữ mô hình hoá, ngôn ngữ chuẩn thống nhất để viết ra bản kế hoạch chi tiết phần mềm) để phát triển phần mềm, giải quyết những bài toán lớn có dữ liệu phân tán là hết sức cần thiết Bài toán phát triển hệ thống quản lý hồ sơ và kết quả học tập là một trong những bài toán ứng dụng công nghệ này Tuy nhiên, hiện nay ở các

trường Đại học có quy mô như trường Đại học Công đoàn thì chưa có một

hệ thống quản lý hồ sơ và kết quả học tập hoàn chỉnh để đáp ứng được các yêu cầu đặt ra do đó việc ứng dụng công nghệ thông tin vào công tác quản lý trở nên hết sức cấp thiết Với đề tài “ Phân tích hướng đối tượng hệ thống quản lý hồ sơ và kết quả học tập” gồm những nội dung sau:

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

Chương 2: Grasp – Cỏc mẫu dựng cho gỏn trỏch nhiệm

Chương 3: Xây dựng hệ thống quản lý hồ sơ và kết quả học tập bằng phương pháp tiếp cận hướng đối tượng

Chương 4: Phân tích và cài đặt chương trình quản lý hồ sơ và kết quả học tập

Nội dung của đề tài giới thiệu phương pháp hướng đối tượng, các công

cụ hỗ trợ phát triển hướng đối tượng Đặc biệt, đề tài đã vận dụng các công

cụ thiết kế hướng đối tượng sử dụng UML – một ngôn ngữ mô hình hoá thống nhất đang được sử dụng rộng rãi trên thế giới để ứng dụng vào việc phân tích thiết kế hệ thống quản lý hồ sơ và kết quả học tập tại trường Đại học Công đoàn

Hà nội, ngày tháng năm 2006 Dương Chí Thiện

CHƯƠNG 1 PHƯƠNG PHÁP HƯỚNG ĐỐI TƯỢNG

1.1 QUY TRÌNH CHUNG ĐỂ PHÁT TRIỂN PHẦN MỀM HƯỚNG ĐỐI TƯỢNG

Nội dung cơ bản của tiến trình phát triển phần mềm hướng đối tượng là tiến trình thực hiện một bước lặp bao gồm: xác định yêu cầu của hệ thống, phân tích, thiết kế, triển khai và kiểm thử Trong đó, hoạt động phân tích và thiết kế có nhiều vấn đề nan giải hơn cả Đặc điểm của phân tích và thiết kế hướng đối tượng coi hệ thống như một tập các đối tượng tương tác với nhau

để tạo ra các hành động, từ đó cho ra kết quả cao Để đạt được điều đó ta

phải sử dụng hệ thống mô hình các đối tượng với những đặc trưng sau:

Tính trừu tượng hóa cao

Tính bao gói thông tin

Tính modul hóa

Tính kế thừa

1.1.1 Lập mô hình nghiệp vụ

Mô hình nghiệp vụ là một mô tả chức năng nghiệp vụ của một tổ chức

và những mối quan hệ bên trong các chức năng đó cũng như các quan hệ của chúng với môi trường bên ngoài Vì thế, để có thể nắm bắt được yêu cầu của

hệ thống trước hết phải nắm và hiểu được hệ thống nghiệp vụ Việc mô tả các yêu cầu của hệ thống nghiệp vụ đầy đủ là cần thiết để đạt được sự nhất trí giữa khách hàng và người phát triển hệ thống cần làm và không nên làm những điều kiện ràng buộc đặt ra cho chúng Mục tiêu của bước này là để hiểu đúng và đầy đủ về hệ thống mà ta cần phải tin học hóa thuần túy về mặt nghiệp vụ Bên cạnh đó cần tìm các ca sử dụng nghiệp vụ từ các chức năng của hệ thống mà qua đó con người và các hệ thống khác sử dụng chúng [1]

1.1.2 Xác định yêu cầu hệ thống

Nhiệm vụ chính trong xác định yêu cầu phát triển mô hình hệ thống cần xây dựng bằng cách dùng các ca sử dụng Bởi vì các yêu cầu về chức năng được cấu trúc thành các ca sử dụng và do phần lớn các yêu cầu phi chức năng đều là riêng đối với một ca sử dụng đơn nên chúng cũng được xử lý trong các ca sử dụng đó Để mô tả các yêu cầu nghiệp vụ dưới góc độ phát triển phần mềm ta cần tìm các tác nhân và các ca sử dụng để chuẩn bị một phiên bản đầu tiên của mô hình ca sử dụng Sau đó ta sẽ xác định các ca sử dụng có ý nghĩa về mặt kiến trúc và sắp xếp thứ tự ưu tiên các ca sử dụng sẽ được triển khai trong bước lặp hiện thời

1.1.3 Phân tích

Nhiệm vụ của pha phân tích là làm mịn các yêu cầu đã nhận được từ pha trước và tạo cấu trúc cho chúng Thông qua đó, các yêu cầu được hiểu chính xác hơn, từ đó đưa ra cấu trúc cho toàn bộ hệ thống

Nhiệm vụ của pha phân tích là tìm ra cách thức để thực hiện yêu cầu của hệ thống đã được xác định trong các ca sử dụng Cụ thể là, cần phân tích

mô hình ca sử dụng bằng cách tìm ra cách tổ chức các thành phần bên trong của hệ thống để thực hiện mỗi ca sử dụng Những thành phần cấu trúc bên trong của hệ thống ở đây là ba loại lớp phân tích Công việc xác định các lớp không phải làm tùy tiện mà thực hiện theo từng ca sử dụng, trước hết cho các ca sử dụng theo thứ tự ưu tiên được sắp Sau đó, cấu trúc lại cách tổ chức lại các thành phần này của hệ thống Để đạt được mục tiêu ấy cần tiến hành các hoạt động sau:

Phân tích kiến trúc hệ thống

Phân tích một ca sử dụng

Phân tích một lớp

Phân tích một gói

Trong quá trính phân tích ta sẽ liên tục tìm ra các gói, các lớp phân tích mới và các yêu cầu chung khi tiếp tục làm mịn mô hình bằng cách phân tích các gói và duy trì các gói đó

1.1.4 Thiết kế

Trong thiết kế, chúng ta định hình hệ thống và tìm hình thức thể hiện về mặt vật lý của nó để thực hiện mọi yêu cầu được đặt ra cho hệ thống Một đầu vào cho thiết kế là mô hình phân tích Khi thiết kế ta sẽ cố gắng bảo tồn được càng nhiều càng tốt cấu trúc của hệ thống được định hình từ mô hình phân tích Kết quả của thiết kế là mô hình thiết kế và mô hình triển khai được thể hiện dưới dạng một loạt các mô hình cụ thể Mô hình thiết kế thực thi mô hình phân tích khi tính đến các điều kiện của môi trường để thực thi

hệ thống Để nhận được mô hình thiết kế ta cần thực hiện các công việc sau:

1.1.5 Các ưu điểm của tiếp cận hướng đối tượng

Những đối tượng được thiết kế tốt trong hệ thống hướng đối tượng là cơ

sở để kết hợp các đơn thể được sử dụng lại thành hệ thống có chất lượng cao hơn Cơ chế tương tác bằng cách truyền thông điệp giữa các đối tượng đảm

bảo cho việc mô tả các giao diện giữa các modul bên trong hệ thống và bên ngoài hệ thống trở nên dễ dàng hơn

Việc phân tích và thiết kế theo cách phân bài toán thành các đối tượng

là hướng tới lời giải của thế giới thực là tự nhiên hơn so với cách phân rã theo chức năng từ trên xuống

Nguyên lý che dấu thông tin hỗ trợ cho việc xây dựng các hệ thống thông tin an toàn

Tiếp cận hướng đối tượng cung cấp cho ta công cụ để làm giảm bớt độ phức tạp của bài toán bằng việc phân rã thành các thực thể độc lập tương đối với nhau

Hệ thống hướng đối tượng dễ dàng mở rộng thành các hệ thống có quy

mô lớn hơn nhờ tương tác giữa các đối tượng thông qua việc gửi thông báo Việc phát triển và bảo trì hệ thống đơn giản hơn

Xóa bỏ ngăn cách giữa các bước phát triển, thiết kế và cài đặt trong quá trình phát triển phần mềm [2]

1.2 CÔNG CỤ HỖ TRỢ PHÁT TRIỂN HƯỚNG ĐỐI TƯỢNG UML

UML (Unified Modeling Language) là ngôn ngữ mô hình hóa, trước hết

nó là mô tả ký pháp thống nhất, ngữ nghĩa và định nghĩa về mô hình hóa, nó không mô tả về phương pháp phát triển UML được sử dụng để hiển thị đặc

tả xây dựng, làm tài liệu các vật phẩm của phân tích hình thức và thiết kế trong quá trình xây dựng hệ thống phần mềm theo hướng đối tượng UML được sử dụng cho mọi tiến trình phát triển phần mềm, xuyên suốt vòng đời phát triển và độc lập với các công nghệ cài đặt hệ thống

1.2.1 Khái quát về UML

1.2.1.1 UML là một ngôn ngữ chuyên dụng

UML được đưa vào sử dụng từ năm 1997 và nhanh chóng được công nghiệp phần mềm chấp nhận là ngôn ngữ đồ họa chuẩn để đặc tả, xây dựng

và làm tài liệu cho các hệ thống phần mềm chuyên sâu UML là ngôn ngữ

mô hình hóa, ngôn ngữ chuẩn thống nhất để viết ra bản kế hoạch chi tiết phần mềm Nó mô tả ký pháp thông nhất, ngữ nghĩa và các định nghĩa chính

mô hình hóa Các khung nhìn ngôn ngữ cho phép nhìn nhận hệ thống phát triển ở các mức độ khác nhau, dễ sử dụng, dễ hiểu UML có các ký pháp và tập các qui tắc sử dụng để mô hình hóa các hệ thống [1]

1.2.1.3 UML là ngôn ngữ để biểu diễn đồ họa

Với nhiều lập trình viên, không có khoảng cách giữa ý tưởng cài đặt mã trình và chuyển nó thành mã, họ suy nghĩ mã trình và viết ngay mã trình cho

nó Tuy nhiên, việc giao tiếp giữa mô hình khái niệm với những cái khác trong vòng đời phát triển phần mềm sẽ gặp khó khăn khi mọi người không

sử dụng chung một ngôn ngữ cho dự án Đặc biệt có những dự án và tổ chức phát triển phần mềm đưa ra ngôn ngữ riêng của họ thì người mới tham gia

dự án sẽ gặp nhiều khó khăn Hơn nữa một vấn đề của hệ thống phần mềm

sẽ được hiểu rõ hơn thông qua mô hình, nếu người viết mã không bao giờ viết thành các mô hình thì thông tin có thể mất hoặc viết lại một cách đầy đủ nếu chỉ xem mã lệnh trong khi người viết mã lệnh chuyển đi nơi khác

Để khắc phục những nhược điểm trên ta sử dụng ngôn ngữ UML để xây dựng các mô hình khác nhau:

- Mỗi ký pháp trong UML mang một ngữ nghĩa rõ ràng

- Các cấu trúc mô tả dưới dạng mô hình đồ họa

- Mô hình rõ ràng sẽ làm cho việc trao đổi, giao tiếp dễ dàng hơn

1.2.1.4 UML là ngôn ngữ đặc tả

Đặc tả là mô tả rõ ràng những điểm mấu chốt của vấn đề UML cho phép

mô tả chính xác, rõ ràng và hoàn thiện UML tập trung đặc tả thiết kế, phân tích và cài đặt quan trọng trong quá trình phát triển và triển khai hệ thống phần mềm

1.2.1.5 UML là ngôn ngữ để tạo mã

UML không phải là ngôn ngữ lập trình trực quan, nhưng mô hình của nó

có thể kết nối trực tiếp với các ngôn ngữ lập trình khác Điều đó có nghĩa là

có thể ánh xạ mô hình trong UML sang một ngôn ngữ lập trình khác như Java, C++ hay các bảng CSDL quan hệ hoặc CSDL hướng đối tượng Đồng thời cho khả năng biến đổi ngược lại từ cài đặt về mô hình UML có nghĩa rằng nó cho khả năng làm việc với văn bản hay đồ họa một cách nhất quán [1]

1.2.1.6 UML là ngôn ngữ làm tài liệu

UML hướng tới làm tài liệu kiến trúc hệ thống và các chi tiết nhỏ của nó

UML cho khả năng biểu diễn yêu cầu, thử nghiệm, mô hình hóa các hoạt động lập kế hoạch và quản lý sản phẩm

- UML cho biết giới hạn của hệ thống và các chức năng của nó thông qua các ca sử dụng và các tác nhân

- Trong UML các ca sử dụng được mô tả bằng biểu đồ logic

- Biểu diễn cấu trúc tĩnh của hệ thống nhờ biểu đồ lớp

- Mô hình hóa các hành vi của đối tượng bằng biểu đồ chuyển trạng thái

- Phản ánh kiến trúc cài đặt vật lý bằng biểu đồ thành phần và biểu đồ triển khai

- Mở rộng khả năng mô tả các chức năng và hành vi hệ thống bằng khuôn mẫu (stereotypes) [5]

1.2.2 Kiến trúc trong UML

Kiến trúc phần mềm cho ta một cái nhìn khái quát nhất về hệ thống phần mềm ở các góc độ khác nhau Mỗi khung nhìn phản ánh về một khía cạnh của tổ chức và cấu trúc của hệ thống, tập trung vào từng mặt cụ thể giúp ta hiểu và sử dụng hệ thống tốt nhất

- Khung nhìn UC (Use Case) cho ta cách sử dụng chức năng để mô tả

hành vi của hệ thống khi nhìn nhận hệ thống dưới góc độ người dùng cuối cùng và các nhà phát triển

Nó chứa các tác nhân, UC, các biểu đồ UC

- Khung nhìn thiết kế 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, nó bao gồm các lớp, các biểu đồ lớp, biểu đồ đối tượng, biểu đồ tương tác, biểu đồ biến đổi trạng thái và các gói

- Khung nhìn tiến trình của hệ thống gồm các luồng và các tiến trình công

việc tạo nên cơ chế hoạt động tương tranh

- Khung nhìn triển khai của hệ thống bao gồm các thành phần và các file

được kết hợp lại cho ra các hệ thống vật lý Khung nhìn này hướng đến việc quản lý cấu hình của hệ thống

- Khung nhìn cài đặt bao gồm các nút tạo nên kết cấu phần cứng mà trên

đó hệ thống vận hành Khung nhìn này chủ yếu hướng đến sự phân tán và cài đặt cụ thể của hệ thống

Hình 1.1 Mô hình hoá kiến trúc hệ thống 1.2.2.1 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 phả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 Các khối để hình thành mô hình UML gồm 3 loại sau: Phần tử, quan hệ và biểu đồ

Hình 1.2 Xác định cấu trúc thành phần của UML

vi

Phần

tử nhóm gộp

Phần

tử chú thích

Phụ thụôc Liên kết

Tổng quát hóa

Ca sử dụng Lớp Đối tượng Tuần tự Cộng tác Trạng thái Hoạt động Thành phần

Gói

Mô hình

Hệ thống con Khung làm việc

Ghi chú

1.2.2.2 Các khối xây dựng

Các phần tử là các trìu tượng hóa, là phần tử lớp đầu tiên để xây dựng nên các mô hình trong UML Các quan hệ gắn kết các phần tử này lại với nhau, các biểu đồ nhóm các phần tử

a Các phần tử cấu trúc: Bao gồm:

* Lớp (Class): mô tả một tập hợp các đối tượng cùng chung thuộc

tính thao tác quan hệ và ngữ nghĩa Lớp được biểu diễn bằng hình chữ nhật bên trong có tên, thuộc tính và thao tác Tên lớp là danh từ Ví dụ Sinh viên

- Đối tượng: là khái niệm dùng để mô hình hóa một vật hoặc một khái niệm trong thế giới thực, có thể là một phần của bất kỳ loại hệ thống nào như máy móc hay một tổ chức

Trong UML đối tượng được thể hiện bằng một hình chữ nhật với tên bên trong, tên đối tượng được gạch chân

* Giao diện: là một tập hợp các tác vụ đặc tả một dịch vụ của một lớp

hoặc một thành phần Một giao diện biểu diễn bằng một hình tròn với tên của nó

* Sự cộng tác: xác định các hoạt động bên trong hệ thống và là một bộ

các nguyên tắc Các phần tử khác nhau cùng làm việc để cung cấp một hành

vi hợp tác lớn hơn tổng hành vi của tất cả các phần tử Sự cộng tác được biểu diễn bằng một hình elip với đường nét đứt và thường chỉ gồm có tên

* Ca sử dụng (Use Case): Mô tả một chuỗi các hành động mà hệ thống sẽ

thực hiện để đạt được kết quả có ý nghĩa đối với một tác nhân Use case được biểu diễn bằng hình elíp nét liền, tên Use case được đặt bên trong hoặc bên dưới

+ Tác nhân (Actor): Thể hiện một tập hợp các vai trò mà các thực thể ngoài có thể thực hiện khi sử dụng hệ thống Nó thể hiện một nhóm người một bộ phận, một tổ chức hoặc các hệ thống khác có tương tác với hệ thống

đó Tương tác của tác nhân với hệ thống có thể là:

- Cung cấp thông tin cho hệ thống

- Lấy thông tin từ hệ thống

- Nhận thông tin từ hệ thống và cung cấp thông tin cho hệ thống Một số đặc điểm của tác nhân:

- Tác nhân có tên và tên đó phản ánh vai trò của tác nhân chứ không phản ánh chức năng của tác nhân

- Tác nhân tương tác với hệ thống bằng cách gửi và nhận thông báo với hệ thống như nó thực hiện với các ca sử dụng

Hình 1.6 Cộng tác Hình 1.7 Ca sử dụng

- Các tác nhân tương tác trực tiếp với hệ thống gọi là tác nhân chính (tác nhân trực tiếp) tác nhân còn lại gọi là tác nhân thứ yếu

Để xác định các tác nhân, ta đi tìm câu trả lời cho các câu hỏi sau:

- Ai là người sẽ dùng hệ thống này để nhập thông tin ?

- Ai là người sẽ dùng hệ thống này để nhận thông tin ?

- Các hệ thống nào tương tác với hệ thống này ?

Tác nhân được biểu diễn bằng hình tượng sau:

+ Xác định ca sử dụng:

Để tìm ra các Use case ta trả lời các câu hỏi sau:

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

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

- Có cần thông báo cho tác nhân về sự kiện xảy ra trong hệ thống ?

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

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

* Thành phần (Component): Là một bộ phận vật lý Một thành phần

biểu diễn một gói vật lý các phần tử logic khác nhau như các lớp, các giao diện và sự cộng tác Nó được biểu diễn bằng một hình chữ nhật với các bảng, một thành phần thường bao gồm chỉ có tên của nó

Tên thành

phần

Hình 1.8 Thành phần

Sinh viên Masv:string Tênsv:string Nhập()

Tên tác nhân

* Lớp hoạt động (Active class): Là lớp có đối tượng làm chủ một hay

nhiều tiến trình hoặc một dãy các thao tác Bởi vậy nó có thể khởi động hoạt động điều khiển Một lớp chủ động được biểu diễn như một lớp

thông thường nhưng có đường viền đậm

* Nút (Node): 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 và 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 Nó được biểu diễn bằng một hình hộp thường bao gồm tên của

nó

b Các phần tử hành vi (Behavioral thinks)

Là bộ phận động của mô hình UML, mô tả hành vi của hệ thống theo thời gian và không gian Có hai loại chính là tương tác và trạng thái

* Tương tác (Interaction): 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ể Một thông báo được biểu diễn bằng một đường thẳng có hướng và tên thao tác của nó

* Máy trạng thái (state machine): 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 có thể được xác định bằng máy trạng thái Một máy trạng thái gồm một

số các phần tử biểu diễn các trạng thái, các dịch chuyển, các sự kiện Nó được biểu diễn bằng một hình chữ nhật góc tròn trong đó có tên trạng thái và các trạng thái con của nó (nếu có)

c Các phần tử nhóm gộp (grouping thinks)

Có một phần tử thuộc nhóm này có tên là gói (package) nó là công cụ tổ chức các thành phần của một mô hình thành các nhóm một mô hình có thể được phân chia vào trong các gói Gói cung cấp một số cơ chế nhóm gộp để:

- Chỉ ra một bức tranh lớn không quá đi sâu vào chi tiết

- Chỉ ra sự phụ thuộc giữa các lớp

- Chỉ ra chi tiết các tập hợp con cô lập

Thông thường một gói là một tập hợp các lớp nhưng nó cũng có thể chứa các gói khác Một lớp chỉ thuộc vào duy nhất một gói Một gói có thể tham chiếu đến các gói khác hoặc phụ thuộc vào các gói các lớp khác Tham chiếu của một gói chỉ ra rằng có một số lớp thuộc gói đó phụ thuộc vào một số lớp thuộc vào gói mà nó tham chiếu đến

Một gói được biểu diễn như một bảng, thường chỉ gồm có tên và đôi khi

có nội dung của nó

d Các phần tử chú thích (Annotational):

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à lời chú

Hình 1.14 Gói Hình 1.13 Chú thích

thích (note) Nó được biểu diễn như một hình chữ nhật với một nếp quăn ở góc cùng với chú giải bằng văn bản hoặc đồ hoạ bên trong

1.2.2.3 Các quan hệ trong UML

a Quan hệ giữa ca sử dụng và tác nhân

Quan hệ này thường gọi là quan hệ tương tác vì nó thể hiện sự tương tác giữa tác nhân và ca sử dụng Thông thường đây là quan hệ 1-1 không có hướng để chỉ ra rằng tác nhân có thể liên lạc với ca sử dụng theo cả hai hướng Quan hệ này thể hiện bằng một đường thẳng nối giữa tác nhân và ca

sử dụng

b Quan hệ giữa ca sử dụng với ca sử dụng

Các ca sử dụng quan hệ với nhau theo ba kiểu quan hệ là: mở rộng, bao gồm và tổng quát hoá

* Quan hệ mở rộng (Extends): Quan hệ này cho phép Use case mở rộng

tuỳ ý chức năng do Use case khác cung cấp Nó chỉ ra rằng trong một điều kiện nào đó một Use case được mở rộng bằng Use case khác, nghĩa là khả năng gộp vài hành vi của Use case tổng quát hơn để sử dụng lại

* Quan hệ bao gồm (Include): Quan hệ này cho phép một Use case sử

dụng một chức năng của Use case khác Nó thường được sử dụng để mô hình hoá một vài chức năng sử dụng lại, dùng chung cho hai hay nhiều Use case

Hình 1.15 Quan hệ mở rộng

mở rộng

<<extend>>

* Quan hệ tổng quát hoá (Generalization): Khi một số các ca sử dụng

kiểm soát các chức năng tương tự nhau có liên hệ với nhau theo một cách nào đó, chúng có thể được gói lại thành một gói trong UML Các nhóm gói liên hệ với các phần tử mô hình có thể được mở rộng hoặc thu bớt lại thành một biểu tượng cho phép người phát triển nhìn một gói tại một thời điểm Gói dùng để tập hợp các ca sử dụng có các chức năng tương tự hoặc có các liên hệ với nhau

c Quan hệ giữa các lớp

Trong UML gồm có 4 quan hệ chính sau: quan hệ phụ thuộc, kết hợp, khái quát hoá và hiện thực hoá

* Quan hệ phụ thuộc (Dependency): Là quan hệ ngữ nghĩa giữa hai

phần tử, trong đó thay đổi phần tử độc lập sẽ tác động để ngữ nghĩa của phần tử phụ thuộc

Quan hệ phụ thuộc được dùng trong các trường hợp sau:

- Lớp sử dụng một biến toàn cục là đối tượng của lớp khác

- Trong phương thức của một lớp có khai báo một biến cục bộ là đối tượng của lớp khác

- Trong phương thức của một lớp có tham số là đối tượng của một lớp khác

* Quan hệ kết hợp (Association): Là quan hệ cấu trúc để mô tả tập liên

kết Khi đối tượng của lớp này gửi / nhận thông điệp đến từ thông điệp đối tượng của lớp kia Chúng có thể chứa tên nhiệm vụ và tính nhiều (multiplicity) Tính nhiều cho biết số lượng các thể hiện của lớp ở đầu bên kia của kết hợp so với một thể hiện của lớp ở đầu bên này của kết hợp

Hình 1.16 Quan hệ phụ thuộc

+ Kết tập (Aggregation): được dùng để cho biết một thể hiện của một lớp bao gồm hoặc chứa các thể hiện của lớp khác, nó biểu diễn mối quan

hệ toàn thể-bộ phận

+ Hợp thành (composition): Giống quan hệ kết tập, tuy nhiên quan hệ hợp thành còn hàm ý cùng gắn kết

* Quan hệ khái quát hoá (Generalization): Là quan hệ đặc biệt hoá

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

* Quan hệ hiện thực hoá (Realization): Là quan hệ ngữ nghĩa giữa giao

diện và lớp (thành phần) hiện thực lớp, giữa Use case và sự cộng tác để thực hiện Use case

1.2.2.4 Các biểu đồ trong UML

Biểu đồ là biểu diễn đồ hoạ tập các phần tử mô hình Vẽ biểu đồ để biểu

diễn hệ thống đang xây dựng dưới các góc độ quan sát khác nhau Có thể biểu đồ là ánh xạ của hệ thống Một phần tử có thể xuất hiện trong một hay nhiều biểu đồ Biểu đồ bao gồm tổ hợp các phần tử đồ họa và các quan hệ UML có khả năng xây dựng một vài biểu đồ trực quan để biểu diễn các khía

Hình 1.17 Quan hệ kết hợp

Hình 1.19 Quan hệ kết tập Hình 1.18 Quan hệ hợp thành

cạnh khác nhau của hệ thống Bao gồm: biểu đồ ca sử dụng (use case diagram), biểu đồ trình tự (sequence diagram), biểu đồ lớp (class diagram), biểu đồ cộng tác (collaboration diagram), biểu đồ biến đổi trạng thái (state transition diagram), biểu đồ hoạt động (activity diagram), biểu đồ thành phần (component diagram), biểu đồ triển khai (deployment diagram)

a Biểu đồ ca sử dụng (Use case diagram):

Chỉ ra tương tác giữa các ca sử dụng và tác nhân Ca sử dụng biểu diễn các chức năng hệ thống Tác nhân là con người hay hệ thống khác, cung cấp hay thu nhận thông tin từ hệ thống đang được xây dựng Biểu đồ ca sử dụng tập trung vào quan sát trạng thái tĩnh của các ca sử dụng trong hệ thống Nó đặc biệt quan trọng trong việc tổ chức và mô hình hoá hệ thống Biểu đồ loại này chỉ ra tác nhân nào khởi động ca sử dụng và khi nào tác nhân nhận thông tin từ hệ thống

Biểu đồ ca sử dụng dùng để:

- Mô hình hoá các chuỗi hành động mà hệ thống sẽ thực hiện, nhằm cung cấp một kết quả có ý nghĩa cho một người dùng nào đó hoặc một hệ thống bên ngoài

- Cung cấp một cái nhìn tổng thể về những gì mà hệ thống sẽ làm và ai

sẽ dùng nó

- Đưa ra cơ sở để xác định giao tiếp người - máy đối với hệ thống

- Dùng để mô hình hoá các kịch bản cho một ca sử dụng

- Để người dùng cuối có thể hiểu được và có thể giao tiếp với hệ thống ở mức tổng thể

- Làm cơ sở cho việc phác thảo ra các đặc tả kiểm tra

UC1

b Biểu đồ lớp (Class diagram):

Biểu đồ lớp chỉ ra tương tác giữa các lớp trong hệ thống Người ta sử dụng biểu đồ lớp để mô hình hoá khung nhìn thiết kế tĩnh của hệ thống Các lớp biểu diễn cho sự vật được xử lý bên trong hệ thống Ta thường sử dụng biểu đồ lớp để:

- Mô hình hoá bảng từ vựng của hệ thống

- Mô hình hóa các sự cộng tác đơn giản

- Mô hình hoá CSDL logic

Các lớp có thể có quan hệ với nhau theo một số cách như sau:

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

- Phụ thuộc (một lớp này sử dụng hay phụ thuộc lớp kia)

- Đặc biệt hóa (lớp nay là một phần tử chuyên biệt của lớp kia)

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

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

c Biểu đồ đối tƣợng (Object diagram)

Biểu đồ đối tượng chỉ ra tập hợp các đối tượng và các mối quan hệ của chúng Người ta sử dụng biểu đồ đối tượng để minh họa các câu trúc dữ liệu, các thực thể của lớp trong biểu đồ lớp Có thể coi biểu đồ đối tượng là một

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

Quan hệ

biến thể của biểu đồ lớp, nó dùng các biểu diễn giống biểu đồ lớp Biểu đồ đối tượng chỉ ra một số thể hiện đối tượng của lớp

d Biểu đồ trình tự (Sequence diagram)

Biểu đồ trình tự chỉ ra sự tương tác giữa các đối tượng và tập trung vào

mô tả trật tự các thông điệp theo thời gian Mỗi mũi tên trong biểu đồ thể hiện thông điệp truyền giữa tác nhân và đối tượng hay đối tượng với đối tượng để thực hiện chức năng cụ thể Chú ý rằng biểu đồ trình tự hiển thị phần tử mô hình đối tượng chứ không phải lớp

e Biểu đồ cộng tác (Collaboration diagram)

Biểu đồ cộng tác chỉ ra các thông tin như biểu đồ trình tự nhưng theo cách khác, nó tập trung vào tổ chức cấu trúc của các đối tượng gửi và nhận thông điệp Trong biểu đồ cộng tác các đối tượng giao tiếp trực tiếp với nhau được thể hiện bằng đường nối

Hình 1.24 Biểu đồ trình tự

Tác nhân

f Biểu đồ trạng thái (State transition)

Biểu đồ này mô tả vòng đời của đối tượng từ khi nó được sinh ra dến khi

nó bị phá hủy Biểu đồ chuyển trạng thái cung cấp cách thức mô hình hóa các trang thái khác nhau của đối tượng Trong khi biểu đồ lớp cung cấp bức tranh tĩnh về các lớp và quan hệ của chúng thì biểu đồ chuyển trạng thái dùng để mô hình hóa các hành vi của hệ thống Biểu đồ trạng thái chỉ ra hành vi của đối tượng

g Biểu đồ hoạt động (Activity diagram)

Biểu đồ này là một phương tiện mô tả các dòng công việc và được dùng theo nhiều cách khác nhau, nó bao gồm việc mô hình hóa các bước tuần tự trong một tiến trình xử lý Biểu đồ trạng thái và biểu đồ hoạt động biểu diễn khía cạnh động của hệ thống Chúng có thể dùng cho việc mô hình hóa vòng đời của một đối tượng Ta sử dụng biểu đồ hoạt động để:

- Mô hình hóa luồng công việc (có thể rẽ nhánh, phân nhánh )

- Mô hình hóa một tác vụ ( một thủ tục tính toán)

h Biểu đồ thành phần (Component diagram)

Biểu đồ thành phần chỉ ra tập hợp các thành phần và các mối quan hệ của chúng Người ta sử dụng biểu đồ này để mô tả cấu trúc phần mềm, các thành phần thực thi tĩnh của hệ thống Các thành phần có thể là : tập tin,

Trạng thái 1 Trạng thái 2

Hình 1.26 Biểu đồ trạng thái

chương trình thi hành, tài liệu, thư viện, bảng dữ liệu Chúng được liên kết với nhau bằng các mối quan hệ Mục đích của biểu đồ thành phần là:

- Mô hình vật lý các phần cứng và các kênh liên lạc giữa chúng

i Biểu đồ triển khai ( Deployment diagram):

Biểu đồ triển khai mô hình hóa các khía cạnh vật lý của một hệ thống hướng đối tượng Nó biểu diễn cấu hình các nút xử lý đang vận hành và các thành phần đang hoạt động trên nó Nó bao gồm các nút và các ràng buộc

Nó hướng vào mô hình hóa sự phân tán, gửi đi và cài đặt các phần tạo nên

hệ thông vật lý Sử dụng biểu đồ triển khai để:

- Mô hình hóa các hệ thống nhúng

- Mô hình hóa hệ thống máy khách, máy phục vụ

- Mô hình hóa các hệ thống phân tán đầy đủ

1.2.3 Các quy tắc của UML

Mô hình hóa một hệ thống không đơn giản là lắp ghép các khối xây

dựng trong UML một cách ngẫu nhiên Giống như mọi ngôn ngữ khác, UML cũng có một số quy tắc chỉ ra rằng một mô hình được xây dựng tốt là

mô hình có một ngữ nghĩa chắc chắn và đồng bộ với tất cả các mô hình có quan hệ với nó UML đưa ra các quy tắc ngữ nghĩa sau:

- Tên gọi: Là các sự vật, các mối quan hệ và các biểu đồ

- Phạm vi: Là khuôn khổ cho ý nghĩa cụ thể đối với một tên gọi

- Tính trực quan: Có thể nhìn thấy và được phần tử khác sử dụng

- Tính tích hợp: Các sự vật có thể liên kết với các sự vật khác

- Tính thực hiện được: Có ý nghĩa để vận hành và mô phỏng một mô

hình động

Những nguyên tắc cần biết để xây dựng tốt các mô hình:

- Sự lược đi: Một số phần tử được dấu đi làm đơn giản việc nhìn nhận

mô hình

- Sự không đầy đủ: Một số phần tử có thể bỏ qua

1.2.4 Các cơ chế chung

UML cung cấp 4 cơ chế chung để áp dụng trong mô hình hóa:

- Các đặc tả: UML cung cấp một cách diễn tả bằng văn bản theo cú pháp

và ngữ nghĩa của khối đồ họa sử dụng, như một tập đầy đủ các thuộc tính, các tác vụ và các hành vi của lớp Nhờ vậy việc dùng các ký pháp đồ họa để làm trực quan hóa hệ thống, dùng các đặc tả của UML để chỉ ra các chi tiết của hệ thống

- Các bài trí: Hầu hết các phần tử trong UML đều có biểu diễn đồ họa

duy nhất cung cấp một sự thể hiện trực quan về những khía cạnh của phần tử

đó Ví dụ: biểu diễn về lớp đưa ra các khía cạnh quan trọng nhất của một lớp như tên, thuộc tính, các thao tác

- Các phân hoạch chung:

Cách 1: Đó là sự phân hoạch của lớp và đối tượng Một lớp là một trừu tượng, đối tượng là một biểu hiện của lớp Hầu hết mọi khối xây dựng trong UML đều thuộc lớp hay đối tượng, UML thường phân biệt lớp và đối tượng lớp đó bằng cách gạch chân tên đối tượng

Cách 2: Đó là sự phân chia giữa giao diện và triển khai một giao diện, khai báo hợp đồng và sự thực thi hợp đồng để thi hành việc cụ thể của hợp đồng Trong UML ta có thể mô hình cả giao diện và sự triển khai

- Các cơ chế khả năng mở rộng: UML cung cấp ngôn ngữ chuẩn viết các

bản thiết kế phần mềm nhưng nó không đủ để diễn đạt mọi sắc thái của các

mô hình trong mọi lĩnh vực và trong mọi thời điểm Vì thế UML được thiết

kế mở cho phép nó có khả năng mở rộng và quản lý được Các cơ chế dùng

để mở rộng là: Các khuôn mẫu, các giá trị thẻ, các ràng buộc Sự mở rộng từ vựng ngôn ngữ UML cho phép tạo ra các khối xây dựng mới có sẵn và cụ

thể cho vấn đề bằng cách thêm vào biểu diễn khuôn mẫu, giá trị thẻ hay ràng buộc

1.2.5 Ứng dụng của UML

UML không chỉ là công cụ mạnh trợ giúp phát triển các hệ thống phần

mềm quy mô lớn, phức tạp mà còn trợ giúp phát triển nhiều hệ thống khác,

tổ chức các hệ kinh doanh, các hệ kỹ thuật Một số hệ thống mà UML có thể

mô tả là:

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

- Hệ thống kỹ thuật: Giải quyết các hệ thống viễn thông, quân sự hoặc các tiến trình công nghiệp

- Hệ thống thời gian thực chìm: Thực hiện thông qua lập trình mức thấp

và đòi hỏi hỗ trợ thời gian thực

- Hệ phân bố: Được phân bố trên một số máy tính với dữ liệu được truyền từ máy này sang máy khác Hệ này đòi hỏi truyền thông đồng bộ xây dựng dựa trên các hệ thống đối tượng

- Phần mềm hệ thống: Hệ điều hành, Cơ sở dữ liệu

- Hệ thống nghiệp vụ: Mô tả các mục tiêu, các nguồn tài nguyên, các quy tắc và công việc thực tại trong nghiệp vụ

1.3 Đặc trưng tiến trình phát triển phần mềm hướng đối tượng với UML

Quá trình phát triển phần mềm hướng đối tượng sử dụng công cụ UML

có những đặc trưng sau:

- Ca sử dụng điều khiển quá trình phát triển

- Lấy kiến trúc làm trung tâm

- Tiến trình phát triển là quá trình lặp và tăng dần

1.3.1 Ca sử dụng điều khiển toàn bộ quá trình phát triển

Một ca sử dụng (use case) là một phần chức năng của hệ thống cung cấp cho người dùng để đem lại một kết quả nào đó khi sử dụng nó Các ca sử dụng dùng để nắm bắt các yêu cầu chức năng Tập hợp tất cả các ca sử dụng lập thành mô hình ca sử dụng mô tả chức năng đầy đủ của hệ thống

Ca sử dụng không chỉ là một công cụ để đặc tả các yêu cầu của hệ thống

mà còn điều khiển quá trình phân tích, thiết kế, cài đặt và kiểm thử theo nghĩa theo nghĩa như sau: trước hết ca sử dụng phản ánh yêu cầu của hệ thống cần phải thực hiện Dựa trên mô hình ca sử dụng, người phát triển tạo ra một loạt các mô hình phân tích, thiết kế và cài đặt nhằm vào việc thực hiện các ca sử dụng ở những mức khác nhau và xem xét để sao cho mỗi mô hình này là phù hợp với việc thực hiện mô hình ca sử dụng xây dựng được Những người

Triển khai

Kiểm thử

Hình 1.28 Ca sử dụng điều khiển các hoạt động phát triển

kiểm thử sẽ kiểm tra các cài đặt để đảm bảo rằng các thành phần được cài đặt thực hiện đúng các ca sử dụng Do vậy, ta nói rằng: ca sử dụng điều khiển quá trình phát triển có nghĩa là quá trình phát triển tuân theo các luồng công việc được điều khiển bởi ca sử dụng

1.3.2 Quá trình phát triển lấy kiến trúc làm trung tâm

Khái niệm kiến trúc phần mềm chứa đựng những khía cạnh tĩnh và động

có ý nghĩa nhất đối với hệ thống Nó được phát triển dựa theo yêu cầu của tổ chức, theo cảm nhận của người dùng và các tổ chức có liên quan khác Mặt khác, nó cũng chịu ảnh hưởng của rất nhiều nhân tố khác, chẳng hạn như phần nền của hệ thống, các khối xây dựng lại được có sẵn, các cân nhắc về điều kiện triển khai, các hệ thống có sẵn trong môi trường tương tác với nó,

và cả các yêu cầu phi chức năng Kiến trúc là một cái nhìn thiết kế tổng thể những đặc điểm quan trọng nhất về hệ thống phần mềm khi tạm bỏ qua các chi tiết

Mọi sản phẩm phần mềm đều bao gồm chức năng và hình thức thể hiện Hai yếu tố này phải cân bằng với nhau để đem lại kết quả tốt nhất Chức năng tương ứng với ca sử dụng và hình thức thể hiện tương ứng với kiến trúc Do vậy, kiến trúc phải cung cấp chỗ dựa cho việc thực hiện các ca sử dụng ngay khi bắt đầu tiến trình phát triển hệ thống và cả trong tương lai

Mỗi ca sử dụng được lựa chọn là sự cụ thể hóa đặc trưng của kiến trúc

và được thực hiện dưới dạng các hệ thống con, các lớp, và các thành phần chủ yếu

1.3.3 Tiến trình phát triển là quá trình và tăng dần

Việc phát triển một phần mềm nói chung đòi hỏi một số lượng lớn công việc và có thể diễn ra trong một khoảng thời gian Việc chia nhỏ toàn bộ công việc thành các phần nhỏ hoặc các dự án con là yêu cầu thiết thực Mỗi dự án con là một bước lặp và tạo nên một sự tăng trưởng Điều này dễ dàng thực

hiện được khi phát triển phần mềm hướng đối tượng vì phần mềm được cấu thành từ các thành phần độc lập ghép nối lại với nhau Để đạt hiệu quả nhất các bước lặp phải được điều khiển, tức là chúng phải được lựa chọn và tiến hành theo một cách có kế hoạch từ trước

Lựa chọn cái gì cần cài đặt trong một bước lặp dựa trên hai yếu tố sau Thứ nhất bước lặp phải liên quan tới một nhóm các ca sử dụng để mở rộng tính khả dụng của hệ thống khi phát triển Thứ hai, bước lặp phải giải quyết những rủi ro quan trọng nhất

Trong mỗi bước lặp, người thiết kế xác định các ca sử dụng liên quan, tạo lập một thiết kế dựa trên một kiến trúc đã chọn, triển khai thiết kế dưới dạng các thành phần, và kiểm tra mức độ tương ứng giữa các thành phần và các ca sử dụng Nếu một bước lặp thoả mãn được các mục đích của nó thì có thể chuyển sang bước lặp tiếp theo Nếu không, người thiết kế sẽ phải xem lại

CHƯƠNG 2

GIỚI THIỆU GRASP - CÁC MẪU DÙNG CHO GÁN TRÁCH NHIỆM

2.1 CÁC KHÁI NIỆM CƠ BẢN

2.1.1 Giới thiệu chung:

Một hệ thống hướng đối tượng bao gồm các đối tượng có chức năng gửi thông báo tới các đối tượng khác để hoàn thành các tác vụ Những dự đoán sơ

bộ tốt nhất về trách nhiệm và tiền điều kiện cho các hoạt động của hệ thống nhất được chỉ ra trong các hợp đồng Biểu đồ tương tác minh hoạ cho các giải pháp-theo thuật ngữ về các đối tượng tương tác đó nhằm thoả mãn các trách nhiệm và tiền điều kiện đó

Sự khác nhau về chất lượng của thiết kế tương tác giữa các đối tượng và việc gán trách nhiệm là rất lớn Những lựa chọn thiếu hợp lý dẫn tới các hệ thống và các thành phần có nguy cơ đổ vỡ và khó có thể bảo trì, khó hiểu, không tái sử dụng hay mở rộng hệ thống được Dựa trên những nguyên tắc căn bản nhất của thiết kế hướng đối tượng, một sự triển khai đầy kinh nghiệm

đã được tìm ra Một vài nguyên tắc trong số đó đã được áp dụng trong quá trình xây dựng biểu đồ tương tác hay trong việc gán trách nhiệm, được hệ thống hoá trong các mẫu GRASP

a Song song với các biểu đồ tương tác

5 Xác định biểu

đồ lớp thiết kế a

3 Làm mịn kiến trúc hệ thống b

6 Xác định lược

đồ cơ sở dữ liệu

Phân tích

Những mẫu GRASP được áp dụng trong quá trình tạo các biểu đồ tương tác khi gán trách nhiệm cho các đối tượng và thiết kế sự cộng tác giữa chúng

2.1.2 Các biểu đồ tương tác được thiết kế tốt đảm bảo :

Biểu đồ tương tác là một trong những chế tác quan trọng nhất được vạch

ra trong quá trình phân tích và thiết kế hướng đối tượng

 Việc gán trách nhiệm một cách có kỹ năng khi thành lập biểu đồ tương tác là rất quan trọng

 Tổng thời gian và công sức bỏ ra để tạo sinh và xem xét kỹ lưỡng việc gán trách nhiệm cần chiếm một phần đáng kể trong pha thiết kế dự án

 Các mẫu được mã hoá, các nguyên tắc và các thành ngữ có thể được áp dụng để nâng cao chất lượng thiết kế

Các nguyên tắc thiết kế cần để xây dựng thành công các biểu đồ tương tác

có thể được mã hoá, giải thích và áp dụng một cách có phương pháp Cách

Ca sử dụng cơ bản, mở rộng

Các ca sử dụng thực

Các cửa sổ

và báo cáo

Kiểm thử các ca sử dụng

Các biểu đồ ca

sử dụng

Mô hình khái niệm

Từ điển giải thích Biểu đồ tuần tự

hệ thống

Các hợp đồng hoạt động Biểu đồ trạng thái

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

biểu đồ lớp thiết kế

Các biểu đồ gói kiến trúc

Lược đồ CSDL

Các phương thức

định nghĩa các giao diện và các lớp

SQL

Sự phụ thuộc

Hình 2.2 Sự phụ thuộc giữa các chế tác của pha xây dựng

tiếp cận để hiểu và sử dụng các nguyên tắc thiết kế là dựa trên các mẫu gán trách nhiệm

2.1.3 Các trách nhiệm và phương thức

Hai tác giả Booch và Rumpaugh định nghĩa trách nhiệm là: “một hợp đồng hoặc nghĩa vụ của một kiểu hoặc một lớp" Trách nhiệm có liên quan đến nghĩa vụ của một đối tượng trong giới hạn hành vi của chúng Nói một cách cơ bản, các trách nhiệm bao gồm hai loại:

1 Biết (knowing)

2 Thực hiện (doing)

Trách nhiệm Thực hiện của một đối tượng gồm:

- Tự thực hiệ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 các hoạt động trong các đối tượng khác

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

- Biết về dữ liệu riêng được bao gói

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

- Biết về các sự vật nó có thể điều khiển và tính toán

Trách nhiệm được gán cho từng đối tượng trong quá trình thiết kế hướng đối tượng Trách nhiệm có liên quan tới “biết” thường bắt nguồn dựa trên mô hình quan niệm bởi trên mô hình đó những thuộc tính và liên kết của nó được minh hoạ

Sự chuyển trách nhiệm vào các lớp và phương thức chịu ảnh hưởng lớn bởi yếu tố hạt nhân tạo ra trách nhiệm ấy Trách nhiệm quy định việc truy nhập vào các CSDL quan hệ, liên quan tới hàng chục lớp và hàng trăm phương thức

Trách nhiệm không đồng nhất với phương thức nhưng phương thức là

Hình 2.3 Các trách nhiệm và các phương thức quan hệ với nhau.

nhiệm phải tự in ra

nhờ các phương thức, hoặc hoạt động độc lập hoặc cộng tác với phương thức

và đối tượng khác Chẳng hạn, lớp Sinh viên có thể xác định một hoặc một vài phương thức để thực hiện việc in ấn một thể hiện Sinh viên; tức là một phương thức có tên là In ấn Nhằm thực hiện trách nhiệm đó đối tượng Sinh viên cần

cộng tác với các đối tượng khác, như gửi thông báo yêu cầu tự in

2.1.4 Trách nhiệm và biểu đồ tương tác.

Biểu đồ tương tác chỉ ra lựa chọn trong việc gán trách nhiệm cho các đối tượng Khi được tạo ra, các quyết định trong quá trình gán trách nhiệm được thực hiện sẽ phản ánh bằng các thông báo gửi tới các vùng khác nhau của đối tượng Các nguyên tắc căn bản, thiết yếu-thể hiện trong mẫu GRASP-để hướng dẫn các lựa chọn cho việc gán trách nhiệm một cách khoa học

Hình 2.3 chỉ ra rằng đối tượng Sinh viên được gán trách nhiệm tự động in ấn,

sẽ được kích hoạt với thông báo In và được giải quyết với phương thức In() tương ứng Hơn nữa, việc hoàn thành trách nhiệm này đòi hỏi phải có sự cộng tác với đối tượng Indanhsachsv - đối tượng đề nghị các đối tượng Sinh viên

tự động in

2.1.5 Mẫu (Patterns)

Các nhà phát triển hệ thống hướng đối tượng có kinh nghiệm (và các chuyên gia phần mềm khác) xây dựng lên một kho các nguyên tắc chung và các giải pháp đặc trưng giúp cho họ trong quá trình xây dựng các phần mềm Những nguyên tắc và quy uớc này, nếu được hệ thống hoá theo dạng có cấu

trúc để mô tả vấn đề và giải pháp, được gọi là mẫu Ví dụ, dưới đây là mẫu thường gặp:

Tên mẫu: Expert (Chuyên gia)

Vấn đề: Đâu là nguyên tắc cơ bản nhất để gán các trách nhiệm cho các

đối tượng ? Giải pháp: Gán trách nhiệm một lớp có thông tin cần để thực hiện nó

Trong công nghệ đối tượng, một mẫu là mô tả có tên về một cặp vấn đề

và giải pháp, nó có thể được áp dụng trong những hoàn cảnh mới Một cách lý tưởng, mẫu cung cấp chỉ dẫn về việc áp dụng nó như thế nào trong những trường hợp cụ thể khác nhau Rất nhiều mẫu cung cấp những chỉ dẫn tốt giúp cho việc gán trách nhiệm cho các đối tượng như thế nào cho những phạm trù vấn đề cụ thể

Một cách đơn giản nhất, Mẫu là một cặp “vấn đề/giải pháp” được đặt tên

có thể được áp dụng trong ngữ cảnh cụ thể, cùng với những chỉ dẫn để áp dụng nó vào hoàn cảnh cụ thể mới như thế nào

2.1.5.1 Mẫu thường không chứa những ý tưởng mới

Đặc điểm của mẫu là nó không phát triển và thể hiện được những nguyên tắc của công nghệ phần mềm mới Điều ngược lại thì đúng–các mẫu chỉ ghi lại các kiến thức, các thành ngữ và các nguyên tắc đã hoàn thiện nhiều

và được ghi lại, càng được sử dụng rộng rãi càng tốt thêm Do đó, các mẫu GRASP - sẽ được giới thiệu ngay sau đây - không chứa đựng bất cứ ý tưởng mới nào; chúng đơn thuần chỉ hệ thống hoá các nguyên tắc cơ bản được sử dụng rộng rãi

2.1.5.2 Mẫu có tên gọi

Mọi mẫu đều cần có và thường tên có tính gợi tả Việc đặt tên cho một mẫu là một kỹ thuật hoặc theo một số nguyên tắc có lợi sau:

 Tạo sự giao tiếp dễ dàng

Đặt tên cho ý tưởng phức tạp như mẫu là minh chứng cho sức mạnh của

sự trừu tượng hoá, biến một dạng phức tạp thành đơn giản hơn thông qua việc lược bớt một số chi tiết Vì vậy, mẫu GRASP có thể được gọi tên ngắn gọn

hơn như là chuyên gia (Expert), bộ tạo lập (Creator), bộ điều khiển (Controller)

2.1.5.3 Đặt tên mẫu giúp cho việc giao tiếp có hiệu quả hơn

Khi một mẫu có tên sẽ dễ dàng hơn cho mọi người thảo luận các nguyên tắc của chúng bằng một cái tên đơn giản Xét cuộc thảo luận dưới đây, cuộc nói chuyện của hai nhà thiết kế phần mềm, họ sử dụng chung một bảng từ vựng về mẫu (Chuyên gia, Phân chia mô hình – khung nhìn, v.v…) để cùng quyết định mẫu thiết kế:

Người A: Anh nghĩ là chúng ta nên gán trách nhiệm in ấn một Sinh viên

ở vị trí nào ?

Người B: Theo tôi Expert có lẽ thích hợp hơn bởi nó đơn giản và một

Sinh viên có đầy đủ dữ liệu cần thiết trong chương trình – Sinh viên sẽ làm

việc đó

Người A: Ồ, tôi đồng ý

Như vậy gom các diễn đạt và các nguyên tắc thiết kế với các tên dễ hiểu sẽ tăng hiệu quả giao tiếp và thúc đẩy yêu cầu lên một mức trừu tượng cao hơn

2.1.6 GRASP: Những nguyên tắc chung của mẫu trong việc gán trách nhiệm

- Gán trách nhiệm một cách có kỹ năng là yếu tố vô cùng quan trọng, cần thiết trong việc thiết kế định hướng đối tượng

- Gán trách nhiệm thường xảy ra trong quá trình tạo lập biểu đồ tương tác

- Mẫu thường là các cặp “vấn đề/ giải pháp” được đặt tên sẽ cho những lời khuyên và những nguyên tắc tốt liên quan tới việc gán trách nhiệm

Chúng ta hãy tìm hiểu các mẫu GRASP:

Câu hỏi: Mẫu GRASP là gì ?

Trả lời: Mẫu GRASP mô tả những nguyên tắc căn bản trong việc gán

trách nhiệm cho các đối tượng, thể hiện dưới dạng mẫu

GRASP là viết tắt của cụm từ General Responsibility Assignment Software

Patterns, có nghĩa là mẫu phần mềm gán trách nhiệm chung và cho thấy tầm

quan trọng của việc nắm bắt những nguyên tắc để thiết kế thành công một

phần mềm hướng đối tượng

2.2 CÁC MẪU TRONG GRASP :

Chúng ta làm quen các mẫu GRASP đầu tiên:

 Expert - Chuyên gia

 Creator – Bộ tạo lập

 High cohesion - Kết dính cao

 Low coupling - Ghép nối thấp

 Controller – Bộ điều khiển

Ngoài ra còn có những mẫu khác Đa hình (polymorphism), Giả thuần tuý

(Pure Fabrication), Gián tiếp (Indirection), Không giao tiếp với đối tượng

khác (Don‟t Talk to Strangers), nhưng năm mẫu đầu là năm mẫu quan trọng

vì chúng thể hiện những vấn đề chung và hết sức căn bản trong việc thiết kế

2.2.1 Mẫu chuyên gia (Expert)

Vấn đề: Nguyên tắc nào là cơ bản nhất để gán các trách niệm cho các đối

tượng ?

Giải pháp: Gán trách nhiệm cho một lớp có thông tin cần để thực hiện

trách nhiệm đó

Một mô hình có thể được xác định bởi hàng chục hoặc hàng trăm các lớp

phần mềm, và một ứng dụng có thể yêu cầu hàng trăm hoặc hàng nghìn trách

nhiệm phải hoàn thành Trong thiết kế hướng đối tượng, khi sự tương tác giữa đối tượng được xác định, chúng ta lựa chọn để gán trách nhiệm cho các lớp Nếu làm tốt, hệ thống sẽ trở nên dễ hiểu hơn, dễ bảo trì và mở rộng, và chúng

ta có cơ hội sử dụng lại các thành phần của nó cho ứng dụng sau

Các trách nhiệm này được xem xét và quyết định vào lúc vẽ các biểu đồ cộng tác Phương thức thành phần của một biểu đồ lớp có thể tổng kết các phương thức

Mỗi trách nhiệm được gán theo nguyên tắc cơ bản của mẫu Expert là đặt trách nhiệm cho chính đối tượng có thông tin cần để hoàn thành trách nhiệm

đó

Ví dụ:

Trong ứng dụng Quản lý hồ sơ sinh viên, một vài lớp muốn biết thông tin sinh viên nào đó Theo lời khuyên ở trên: vấn đề là lớp nào phải chịu trách nhiệm trong việc lấy thông tin của sinh viên?

DK Timkiem

Form Hoso

Hình 2.4 Các liên kết của Hososinhvien

DK Timkiem Timthongtin()

Form Hoso Hiengiaodien()

Hình 2.5 Lấy thông tin sinh viên

Hososinhvien

ngaysinh gioitinh Laythongtin()

: DK Timkiem

:Hososinhvien 1*: [for each] sli := ketiep()

:DK Timkiem 2: st := Timthongtin()

Sau cùng để hoàn thành trách nhiệm biết, thì các lớp được gán trách nhiệm như sau:

Mỗi trách nhiệm được gán theo nguyên tắc cơ bản của mẫu chuyên gia là đặt trách nhiệm cho chính đối tượng có thông tin để hoàn thành trách nhiệm

Lợi ích:

Sự bao gói được duy trì, vì các đối tượng sử dụng thông tin của chính nó

để hoàn thành công việc Điều này hỗ trợ tính ghép nối thấp, nó làm cho hệ thống vững chắc hơn và có thể bảo trì

Các hành vi được phân bổ qua các lớp có các thông tin được yêu cầu, vì vậy nó khuyến khích xác định các lớp có tính kết dính “lỏng”, dễ hiểu và dễ bảo trì

Mẫu cũng được biết đến như là: “Đặt trách nhiệm tương ứng với dữ liệu”, “Biết cái gì làm cái đó”, “sinh động”, ”tự thân vận động”, ”hãy cho các dịch vụ có các thuộc tính mà chúng cần có để làm việc”

- B tổng hợp các đối tượng của A

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

- B ghi lại các thể hiện của các đối tượng của A

- B sử dụng chặt chẽ các đối tượng A

- B có dữ liệu khởi tạo mà sẽ được chuyển tới A khi nó được tạo ra (vì thế B là một Expert trong việc khởi tạo A)

B là một bộ tạo lập các đối tượng của A

Nếu có nhiều hơn một tùy chọn áp dụng, thì lớp B kết hợp hoặc chứa lớp A Việc tạo các đối tượng là một hoạt động phổ biến nhất trong hệ thống hướng đối tượng Do vậy, có một nguyên tắc chung cho việc gán các trách nhiệm tạo lập là điều rất tốt Nếu gán tốt, thiết kế có thể hỗ trợ việc ghép nối thấp, tăng tính rõ ràng, tính bao gói và tính có thể dùng lại