Bài giảng Phân tích và thiết kế hệ thống thông tin: Chương 3

CHƯƠNG 3

PHÂN TÍCH VÀ THIẾT KẾ HTTT THEO HƯỚNG ĐỐI TƯỢNG

ANALYSIS AND DESIGN INFORMATION SYSTEMS IN OBJECT ORIENTED

PGS.TS. Nguyễn Mậu Hân

Khoa CNTT-ĐHKH HUẾ

nmhan2005@yahoo.com 196

NỘI DUNG

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

3.2. PHÂN TÍCH YÊU CẦU HỆ THỐNG

3.3. ĐẶC TẢ CÁC YÊU CẦU CỦA HT

3.4. THIẾT KẾ HƯỚNG ĐỐI TƯỢNG

3.5. CÁC NHÓM MẪU THIẾT KẾ

3.6. THIẾT KẾ GIAO DIỆN, BÁO BIỂU, AN TOÀN HỆ THỐNG

3.1 QUÁ TRÌNH PHÁT TRIỂN PHẦN MỀM HĐT

Nhận xét: Quá trình xây dựng một sản phẩm phần mềm hoặc nâng cấp một sản phẩm đã có được gọi là quá trình phát triển phần mềm (Software Development Process).

Quá trình phát triển một phần mềm là quá trình xác định:

198

 làm cái gì (WHAT?),  làm ở đâu (WHERE?)  làm khi nào (WHEN?)  làm như thế nào (HOW?).

3.1 QUÁ TRÌNH PHÁT TRIỂN PHẦN MỀM HĐT

Có 5 bước chính cần thực hiện trong quá trình phát triển phần mềm theo hướng đối tượng:

1. Nghiên cứu hiện trạng và xác định các yêu cầu

2. Phân tích hệ thống

3. Thiết kế hệ thống

4. Lập trình và kiểm thử hệ thống

199

5. Vận hành và bảo trì hệ thống.

3.1. QUÁ TRÌNH PHÁT TRIỂN PHẦN MỀM HĐT ...

3.1.1 Nghiên cứu hiện trạng và xác định các yêu cầu

Từ các yêu cầu của khách hàng chúng ta xác định được mục tiêu của phần mềm cần phát triển.

Thường đó là các yêu cầu chức năng về những gì mà hệ thống phải thực hiện. Ở giai đoạn này chưa cần chỉ ra các chức năng đó thực hiện như thế nào.

Việc xác định đúng và đầy đủ các yêu cầu của bài toán là nhiệm vụ rất quan trọng, nó làm cơ sở cho các bước tiếp theo.

200

Do đó, phải đặc tả được các yêu cầu của hệ thống (Sử dụng các Use Case để đặc tả các yêu cầu).

3.1.1 Nghiên cứu hiện trạng và xác định các yêu cầu

Các công việc cần phải làm trong giai đoạn này:

Nắm bắt các yêu cầu của khách hàng/người sử dụng

Hiểu rõ miền xác định của bài toán (Domain Understanding)

Phân loại (Classification): theo tầm quan trọng hay theo chức năng chính của những người sử dụng.

201

Thẩm định (Validation): Kiểm tra xem các yêu cầu có thống nhất với nhau và đầy đủ không, đồng thời tìm cách giải quyết các mối mâu thuẫn giữa các yêu cầu nếu có.

3.1.1 Nghiên cứu hiện trạng và xác định các yêu cầu

Nghiên cứu khả thi (Feasibility Study):

Tính khả thi của một dự án tin học phải được thực hiện dựa trên các yếu tố bao gồm các khía cạnh:

 tài chính

 chiến lược

 thị trường

 con người, đối tác

 kỹ thuật

202

 công nghệ và phương pháp mô hình hoá, v.v.

3.1.1 Nghiên cứu hiện trạng và xác định các yêu cầu

203

Tóm lại, giai đọan nghiên cứu sơ bộ, cần xem xét: Các yêu cầu của NSD, những nguồn tài nguyên có thể sử dụng, công nghệ, các ý tưởng của người sử dụng đố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ỗ 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. Kết quả của giai đoạn nghiên cứu sơ bộ là bản 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.

3.1.1 Nghiên cứu hiện trạng và xác định các yêu cầu

Cho phép các System Developer hiểu rõ hơn các

Mục đích cụ thể của bước xác định yêu cầu: Đi đến thỏa thuận với khách hàng và người dùng về các chức năng của hệ thống-Những gì mà hệ thống phải thực hiện

yêu cầu đối với hệ thống

Phân định ranh giới của hệ thống Cung cấp cơ sở để hoạch định nội dung kỹ thuật

của các vòng lặp

204

Xác định giao diện người dùng cho hệ thống

3.1.1 Nghiên cứu hiện trạng và xác định các yêu cầu

Khi nào thì kết thúc giai đoạn này?

Đã nêu được đầy đủ các yêu cầu về chức năng (dịch vụ), đầu vào/ra và những dữ liệu cần thiết chưa?

205

Khách hàng/người sử dụng (NSD) và những người phát triển đã hiểu hoàn toàn hệ thống chưa?

3.1.1 Nghiên cứu hiện trạng và xác định các yêu cầu

Mối quan hệ giữa các công việc trong pha phân tích các yêu cầu

206

3.1.2 Phân tích hướng đối tượng

 Hệ thống gồm những thành phần, bộ phận, đối tượng nào?  Hệ thống cần thực hiện những cái gì?

Kết quả chính của việc phân tích hệ thống hướng đối tượng là: biểu đồ lớp, biểu đồ trạng thái, biểu đồ trình tự, biểu đồ cộng tác và biểu đồ thành phần.

207

 Là giai đoạn quan trọng của quá trình phát triển phần mềm, trong đó mô hình khái niệm phải được mô tả chính xác. Phân tích hướng đối tượng tập trung vào việc tìm kiếm các đối tượng, khái niệm trong lĩnh vực bài toán và xác định mối quan hệ của chúng trong hệ thống. Phân tích hệ thống cần trả lời các câu hỏi sau:

3.1.2 Phân tích hướng đối tượng ...

Tóm lại, mục tiêu cụ thể của giai đoạn phân tích là: Xác định hệ thống cần phải làm gì.

Nghiên cứu đầy đủ các chức năng cần cung cấp và những yếu tố liên quan.

Nhờ chuyên gia lĩnh vực đánh giá, góp ý.

Xây dựng một mô hình nêu bật bản chất vấn đề từ một hướng nhìn có thực (trong đời sống thực).

208

Kết quả của giai đoạn phân tích là bản Đặc Tả Yêu Cầu (Requirements Specifications).

3.1.3 Thiết kế hướng đối tượng

Hệ thống làm như thế nào? (HOW?)

 Hệ thống được tổ chức thành tập các đối tượng tương tác với nhau và mô tả được cách để hệ thống thực thi nhiệm vụ của bài toán.  Giai đoạn này cần trả lời các câu hỏi:

209

 Trong hệ thống có những lớp đối tượng nào, trách nhiệm của chúng như thế nào?  Các đối tượng tương tác với nhau như thế nào?  Các nhiệm vụ mà mỗi lớp đối tượng phải thực hiện như thế nào?  Dữ liệu nghiệp vụ và các giao diện được xây dựng như thế nào?  Kiến trúc và cấu hình của hệ thống như thế nào?

3.1.3 Thiết kế hướng đối tượng

Tóm lại, nhiệm vụ chính của thiết kế hệ thống là: Xây dựng các thiết kế chi tiết mô tả các thành phần của hệ thống ở mức cao hơn (khâu phân tích) để phục vụ cho việc cài đặt.

Đưa ra được kiến trúc của hệ thống để đảm bảo cho hệ thống có thể thay đổi, có tính mở, dễ bảo trì, thân thiện với NSD, ...

Những kết quả trên được thể hiện trong các biểu đồ: biểu đồ lớp (chi tiết), biểu đồ hành vi, biểu đồ thành phần và biểu đồ triển khai.

210

Trong các tài liệu thiết kế phải mô tả cụ thể những thành phần nào, làm những gì và làm như thế nào.

3.1.3 Thiết kế hướng đối tượng

211

Một số các công việc thường được thực hiện trong giai đoạn thiết kế: Thiết kế database Thiết kế các chức năng, thủ tục mô tả các quá trình xử lý từ input đến output. Thiết kế các forms nhập dữ liệu tùy theo các thành phần dữ liệu cần nhập. Thiết kế các reports và những output mà hệ thống mới phải sản sinh Kết quả giai đoạn thiết kế là bản Đặ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.

3.1.4 Lập trình và kiểm thử hệ thống

Mỗi mô đun này sẽ được kiểm chứng hoặc thử nghiệm theo các tài liệu đặc tả của giai đoạn thiết kế.

Trong giai đoạn này, mỗi thành phần đã được thiết kế sẽ được lập trình thành những mô đun chương trình (chương trình con).

Quá trình xây dựng phần mềm

212

 Công việc này được mô tả như sau:

3.1.4 Lập trình và kiểm thử hệ thống

Phần kiểm 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).

Mục đích chính trong giai đoạn kiểm thử này là xem chương trình có cho ra những kết quả mong muốn.

213

Giai đoạn thử nghiệm đơn vị còn được gọi là “Kiểm thử hộp trắng" (White Box Testing)

3.1.4 Lập trình và kiểm thử hệ thống

Kiểm thử đơn vị độc lập Công việc này do một thành viên khác đảm trách. Cần chọn người không có liên quan trực tiếp đến việc viết code của đơn vị chương trình cần thử nghiệm để đảm bảo tính “độc lập”. Kiểm thử hệ thống Sau khi các thủ tục đã được thử nghiệm riêng, cần phải thử nghiệm toàn bộ hệ thống.

214

Dữ liệu kiểm 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 các sai sót so với bản thiết kế.

Mọi thủ tục được tích hợp và chạy thử, kiểm tra xem mọi chi tiết ghi trong Đặc Tả Yêu Cầu.

3.1.5 Vận hành và bảo trì hệ thống

Cài đặt hệ thống phần mềm trong môi trường sử dụng của khách hàng

Chỉnh sửa phần mềm đúng như những gì đã thiết kế và yêu cầu của người sử dụng

Về bảo trì phần mềm:

 Đảm bảo sự thích nghi đối với sự thay đổi của môi trường của hệ thống hay sự sửa đổi cho phù hợp với những thay đổi của chính sách, qui chế mới

215

 Nâng cao hiệu quả của hệ thống

3.1. QUÁ TRÌNH PHÁT TRIỂN PHẦN MỀM HĐT ...

216

Qui trình xây dựng các biểu đồ UML trong phân tích, thiết kế hệ thống HĐT

3.2. PHÂN TÍCH YÊU CẦU HỆ THỐNG

BÀI TOÁN 1: HỆ THỐNG BÁN HÀNG (HBH) Một Công ty muốn xây dựng HTTT để phục vụ và quản lý các hoạt động kinh doanh. Công ty có nhiều điểm bán hàng đầu cuối (POST: Point Of Sale Terminal), đó là những cửa hàng, siêu thị, ... Do đó hệ thống cần phải ghi nhận các hoạt động bán hàng và xử lý các công việc thanh toán với khách hàng, chủ yếu khách hàng mua lẻ. Ngoài ra hệ thống còn giúp lãnh đạo Công ty theo dõi được các hoạt động kinh doanh, tự động kiểm kê các mặt hàng tồn đọng trong kho, các mặt hàng bán chạy,... để hỗ trợ ra quyết định trong các hoạt động kinh doanh của Công ty. Trong mỗi cửa hàng đầu cuối đều có các thiết bị phần cứng như: máy tính, máy đọc mã vạch và phần mềm hệ thống để chạy hệ thống sẽ được xây dựng”.

217

Mục đích của hệ thống HBH

 Tăng nhanh hoặc tự động hoá việc bán hàng, ghi nhận các mặt hàng: loại sản phẩm, mô tả sản phẩm, số lượng và xác định giá bán, tính tiền, v.v., đáp ứng mọi yêu cầu của khách hàng,

 Thanh toán nhanh với khách hàng bằng các phương thức:

tiền mặt, thẻ tín dụng, hay séc.

 Phân tích, xử lý các kết quả bán hàng nhanh và chính xác để

hỗ trợ quyết định trong các hoạt động kinh doanh.

 Thực hiện tự động kiểm kê các mặt hàng trong kho, theo dõi được những mặt hàng bán chạy, những mặt hàng tồn kho để có được những quyết định kịp thời trong kinh doanh.

 Tóm lại, hệ thống xây dựng nhằm tự động hoá các hoạt động kinh doanh, phục vụ khách hàng nhanh hơn, tốt hơn và rẻ hơn.

218

Trong giai đoạn phân tích

Đối với bài toán 1, giai đoạn OOA sẽ nhận biết được các

...

đối tượng như: - Cửa hàng, siêu thị - Khách hàng - Mặt hàng - Người thanh toán - Tương tác và quan hệ giữa các đối tượng trên là: - Khách hàng chọn hàng - Khách hàng trả tiền -

...

219

BÀI TOÁN 2: HỆ THỐNG ATM

Ngân hàng VietinBank có các máy rút tiền tự động (ATM) đặt ở những vị trí khác nhau trong thành phố. Chúng được nối với Trung tâm tại trụ sở Ngân hàng thông qua hệ thống mạng máy tính. Máy tính trung tâm lưu trữ và quản trị CSDL khách hàng, xử lý những công việc chuyên ngành của ngân hàng và yêu cầu ATM trả tiền.

Máy rút tiền tự động bao gồm máy đọc thẻ từ, màn hình và bàn phím để tương tác với người sử dụng.

xem số dư trong tài khoản và thực hiện thanh toán với hệ thống tín dụng của Ngân hàng.

220

Khách hàng có thể rút tiền tự động, chuyển tiền,

BÀI TOÁN 2: HỆ THỐNG ATM ...

221

Trong những trường hợp đặc biệt như bị mất thẻ, hay muốn thay đổi số thẻ thì khách hàng có thể thay đổi mật khẩu cá nhân (PIN) và tương tự như vậy, khi khách hàng báo bị mất thẻ thì Ngân hàng cũng có thể quyết định thay đổi số thẻ và báo cho khách hàng biết để đảm bảo không cho những người không phải chủ sở hữu rút được tiền.

BÀI TOÁN 3: HỆ THỐNG ĐĂNG KÝ HỌC PHẦN

 Đại học Huế cần xây dựng một hệ thống thông tin giúp sinh

viên (SV) đăng ký học phần (HP) mới. Hệ thống cho phép SV đăng ký học phần và xem điểm từ một máy tính cá nhân được kết nối vào hệ thống mạng của ĐHH. Các giáo viên cũng có thể truy cập vào hệ thống này để biết được lớp dạy và nhập điểm cho các HP.

 Vào đầu mỗi học kỳ SV dựa vào TKB và giáo viên sẽ phụ trách

môn học để đăng ký HP được giảng dạy trong học kỳ đó. Thông tin về mỗi HP bao gồm: tên HP, tên giáo viên giảng dạy, Khoa chuyên môn, các HP tiên quyết,... để giup SV đăng ký.  Hệ thống mới cho phép SV chọn 4 học phần được mở trong

học kỳ tới. SV cũng có thể chọn 2 HP tự chọn trong trường hợp không thể đăng ký theo nguyện vọng chính.

 Số tối thiểu và tối đa SV cho mỗi HP là 30 và 60. Các HP có ít hơn 30 SV sẽ bị hủy. Đầu mỗi HP SV có một khoảng thời gian để thay đổi các HP đã đăng ký.

BÀI TOÁN 3: HỆ THỐNG ĐĂNG KÝ HỌC PHẦN

 Khi quá trình đăng ký hoàn tất cho mỗi SV hệ thống sẽ gửi thông tin đến ngân hàng VietinBank để SV có thể đóng học phí qua thẻ ATM

 Nếu một lớp bị hết chỗ trong quá trình đăng ký, SV sẽ được thông báo về sự thay đổi trước khi xác nhận đăng ký HP  Cuối học kỳ SV có thể truy cập vào hệ thống để xem phiếu điểm. Hiễn nhiên, mỗi SV được hệ thống cung cấp một tài khoản cá nhân để bảo mật thông tin của mình.

 Các giáo viên có thể truy cập vào hệ thống để biết TKB và

danh sách SV của HP sẽ dạy

 Giáo viên có nhiệm vụ nhập các điểm QTHT, điểm thi, kiểm

tra sau khi HP kết thúc

223

Các công cụ để mô tả yêu cầu người dùng

224

Các chức năng, nhiệm vụ của hệ thống là gì?

Chức năng của hệ thống là những gì mà hệ thống

được yêu cầu thực hiện.

Các chức năng có thể phân loại theo lĩnh vực chức năng để tránh sự nhầm lẫn giữa chúng. Các chức năng hệ thống có thể chia thành:

 Chức năng ẩn (Hiddent): cập nhật dữ liệu, tồn kho

 Chức năng hiển (Evident): chọn hàng, tính tiền,...

225

 Chức năng tuỳ chọn (optional): tăng mức độ thân thiện của hệ thống nhưng không ảnh hưởng tới giá trị cũng như các chức năng khác.

Các chức năng, nhiệm vụ của hệ thống là gì?

Các chức năng của hệ thống phải được chia thành

Chú ý:

các nhóm theo các mối liên hệ với nhau.

Ví dụ: Các chức năng của hệ thống HBH có thể chia

Dựa vào cách phân chia các chức năng để sau này chia nhỏ hệ thống thành các gói, các hệ thống con trong quá trình phân tích và thiết kế hệ thống.

thành hai nhóm chính:

 Các chức năng bán hàng

226

 Các chức năng thanh toán.

Bảng liệt kê các chức năng

227

Bảng liệt kê các chức năng

 Các chức năng hệ thống thường được đánh số theo các qui tắc tham chiếu (Reference Rule) để tiện cho việc sử dụng tham chiếu trong các mục phân tích sau này.

228

3.3. ĐẶC TẢ CÁC YÊU CẦU CỦA HỆ THỐNG 1. Use Case Use Case mô tả tập các hoạt động của hệ thống

Hệ thống phải làm gì (What ?)

theo quan điểm của các tác nhân (Actor). Nó mô tả các yêu cầu của hệ thống và trả lời cho câu hỏi:

Một Use Case có thể bao gồm nhiều biểu đồ Use

Use Case mô tả rõ ràng và nhất quán về việc hệ

Case

thống cần phải làm gì (What?).

229

Use Case mô tả các yêu cầu về mặt chức năng của hệ thống -các chức năng này có từ sự thỏa thuận giữa khách hàng và nhóm phát triển phần mềm.

2. Mục tiêu của Use Case

 người phân tích viên hiểu

Làm cơ sở để:

 người lập trình cài đặt các chức năng

 người thiết kế xây dựng các kiến trúc

của hệ thống.

 người kiểm thử kiểm tra các kết quả thực hiện

230

Làm công cụ giao tiếp cho những người phát triển, đảm bảo hệ thống thỏa mãn đúng những yêu cầu của Users

3. Ai cần Use Case? - Để làm gì?

Nhà phát triển cần đến các mô hình Use Case để hiểu hệ thống cần phải làm gì, và qua đó có được một nền tảng cho những công việc tương lai

tả chức năng của hệ thống và mô tả xem hệ thống có thể và sẽ được sử dụng như thế nào.

Customers/Users quan tâm đến Use Case vì nó đặc

Những người liên quan đến những hoạt động liên kết đến chức năng của hệ thống như nhóm tiếp thị, bán hàng, hỗ trợ khách hàng và nhóm soạn thảo tài liệu.231

Tester cần đến Use Case để thử nghiệm và kiểm tra xem hệ thống có đảm bảo sẽ thực hiện đúng chức năng đã được đặc tả trong giai đoạn đầu.

Actors

Hệ thống

Use Case

4. Cách thể hiện một biểu đồ Use Case

232

Một biểu đồ Use Case thể hiện: Hệ thống Tác nhân Use Case. Ví dụ biểu đồ Use Case trong UML:

a. Hệ thống

Hệ thống là một thành phần của Use Case nên ranh giới của hệ thống cần phải được xác định rõ ràng.

Một hệ thống không nhất thiết là một hệ thống phần

mềm; nó có thể là một chiếc máy, hoặc là một doanh nghiệp.

Ký hiệu của hệ thống: hình chữ nhật có kèm theo tên

233

hệ thống

b. Tác nhân

với hệ thống, sử dụng hệ thống.

Người hoặc một vật nào đó tương tác

Một tác nhân có thể là người, thiết bị mà cũng có thể

là một hệ thống khác.

Tên gọi của tác nhân được mô tả bằng các danh từ (chung) và thường phải đặc tả được vai trò của nó đối với hệ thống.

234

Một tác nhân là một dạng tập thực thể (một lớp) chứ không phải một thực thể. Tác nhân mô tả và đại diện cho một vai trò, chứ không phải là một người sử dụng thật sự và cụ thể của hệ thống.

 Dùng để giải thích các khái niệm, định nghĩa, thuật ngữ, ngôn

ngữ công việc trong hệ thống

235

c. Bảng chú giải

5. Cách xác định các tác nhân và các Use Case

a. Để xác định các tác nhân là dựa trên các câu trả lời những câu hỏi sau:

công việc hàng ngày?

Ai sẽ sử dụng các chức năng chính của hệ thống? Ai cần sự hỗ trợ của hệ thống để thực hiện các

Ai quản trị, bảo dưỡng để đảm bảo cho hệ thống

hoạt động thường xuyên?

Hệ thống quản lý, sử dụng những thiết bị nào? Hệ thống cần tương tác với những bộ phận, hệ

thống nào khác?

236

Ai hay cái gì quan tâm đến kết quả xử lý của hệ

thống?

5. Cách xác định các tác nhân và các Use Case

 Xác định Use Case dựa vào các tác nhân:

b. Có hai phương pháp để xác định các Use Case

Với mỗi tác nhân, tìm những tiến trình (chức năng) được khởi đầu, hay giúp các tác nhân thực hiện, giao tiếp/tương tác với hệ thống.

237

Xác định những tác nhân liên quan đến hệ thống hoặc đến tổ chức, nghĩa là tìm và xác định những tác nhân là NSD hay những hệ thống khác tương tác với hệ thống cần xây dựng.

Xác định các Use Case và các sự kiện

hệ thống hay hệ thống phải trả lời.

Xác định những sự kiện bên ngoài có tác động đến

 Nhiệm vụ chính của các tác nhân là gì?  Tác nhân cần phải đọc, ghi, sửa đổi, cập nhật, hay lưu trữ

thông tin hay không?

 Những thay đổi bên ngoài hệ thống thì tác nhân có cần

phải thông báo cho hệ thống hay không?

 Những tác nhân nào cần được thông báo về những thay

đổi của hệ thống?

 Hệ thống cần có những đầu vào/ra nào? từ đâu và đến

đâu?

238

Tìm mối liên quan giữa các sự kiện và các UC. Hãy trả lời những câu hỏi sau để tìm ra các UC:

Ví dụ1: Xác định các Actor và Use Case của HBH

a. Xác định các actor: Danh sách các actor

+ Khách hàng: là những người được hệ HBH phục vụ,

là khách hàng.

năng bán hàng của hệ thống để thực hiện nhiệm vụ của mình.

+ Người bán hàng: những người cần sử dụng chức

hay kết thúc cả hệ thống tại các điểm bán hàng đầu cuối.

+ Người quản lý: những người được phép khởi động

+ Người quản trị hệ thống: có thể bổ sung, thay đổi

239

những NSD.

Ví dụ1: Xác định các Actor và Use Case của HBH ...

 Bán hàng, mua hàng (Buy Items) là nhiệm vụ của

b. Xác định các Use Case: Danh sách các Use Case

hệ thống HBH liên quan trực tiếp tới khách hàng và người bán hàng. Use Case Use Case này liên quan đến cả người bán hàng và khách hàng.

 Thanh toán, trả tiền mua hàng hay thu tiền là chức

240

năng của hệ thống phải thực hiện để thanh toán với khách hàng bằng phương thức mà họ lựa chọn: trả tiền mặt, thẻ tín dụng, hay trả bằng séc. Use Case này cũng liên quan đến cả người bán hàng và khách hàng.

Ví dụ1: Xác định các Actor và Use Case của HBH ...

 Đăng nhập hệ thống (Log in): Người bán hàng cần sử dụng để nhập vào hệ thống và sử dụng nó để bán hàng.

b. Xác định các Use Case: Danh sách các Use Case

 Bổ sung NSD mới, Loại bỏ NSD: Người quản trị hệ thống có thể bổ sung thêm người sử dụng mới hay loại bỏ những NSD không còn cần sử dụng hệ thống.

241

 Khởi động, đóng hệ thống: Người quản lý thực hiện để khởi động hay kết thúc hoạt động của hệ thống.

Các Actor và Use Case của hệ thống HBH

Đăng nhập hệ thống (Log In)

Người bán hàng (Cashier)

Thu tiền bán hàng (Cash Out)

Mua hàng (Buy Items)

Khách hàng (Customer)

Thu tiền, thanh toán (Refund Items)

Tác nhân Use Case

Khởi động hệ thống (Start Up) để người bán hàng có thể sử dụng HT.

Người quản lý (Manager)

Đóng hệ thống khi hết giờ

Bổ sung NSD (Add New Users)

Loại bỏ NSD (Delete User)

Hay gian hàng trưởng

242

Quản trị hệ thống (System Adminitrator)

Biểu đồ Use Case của hệ thống HBH

243

Ví dụ2: Các Actor và Use Case của hệ thống ATM

Khách hàng: những đối tượng chính mà hệ thống

a. Xác định các actor: Danh sách các actor

ATM phục vụ việc rút/gửi tiền tự động.

quản lý và phục vụ tín dụng cho khách hàng.

Hệ thống tín dụng: bộ phận tín dụng của Ngân hàng

Nhân viên ngân hàng: những người được quyền

244

thay đổi PIN của khách hàng khi cần thiết, chuyển tền vào máy.

Ví dụ2: Các Actor và Use Case của hệ thống ATM

b. Xác định các Use Case: Danh sách các Use Case

của Ngân hàng, khi cần rút tiền thì nhập số PIN, nhập số lượng tiền cần rút.

Rút tiền: những khách hàng có tiền trong tài khoản

Chuyển tiền: khách hàng có thể chuyển tiền từ một tài khoản khác về tài khoản của mình hoặc gửi tiền trực tiếp vào tài khoản.

Xem số dư trong tài khoản: khách hàng biết được

mình còn bao nhiêu tiền trong tài khoản.

Thanh toán: khách hàng có thể sử dụng để thanh toán

với hệ thống tín dụng của Ngân hàng.

Thay đổi PIN: khách hàng, hoặc nhân viên Ngân hàng 245

có thể thay đổi PIN khi cần thiết.

Biểu đồ Use Case của hệ thống ATM

246

6. Đặc tả các Use Case

cầu của hệ thống.

b. Mục đích : Để hiểu rõ hơn về tiến trình xử lý các yêu

Tên Use Case: tên của Use Case bắt đầu

Mẫu đặc tả Use Case có dạng:

bằng động từ, gợi nhớ.

quan đến Use Case.

Các tác nhân: danh sách các tác nhân liên

 Mô tả mục đích :Mô tả tóm tắt tiến trình xử lý

Tham chiếu: Các chức năng, Use Case và

công việc cần thực hiện.

247

những hệ thống liên quan.

Ví dụ

Use Case: Bán hàng (Buy Items)

Tác nhân: Khách hàng, người bán hàng.

hàng cần mua để ở trong giỏ hàng thì đưa hàng đến quầy thu tiền. Người bán (cashier) lần lượt ghi nhận các mặt hàng trong giỏ hàng của khách và thu tiền. Sau khi thanh toán xong khách hàng được mang số hàng đã mua đi ra khỏi cửa hàng.

Tham chiếu tới: Các chức năng R1.1, R1.2, R1.3,

Mô tả: Khách hàng sau khi đã chọn đủ các mặt

248

R1.6, R1.7, R1.8, R3.1, R3.2, R3.3.

Ví dụ

Bán hàng

Khách hàng

Người bán hàng

249

Use Case cho chức năng Bán hàng (Buy items)

Ví dụ

Use Case: Thu tiền (Cash Out) Tác nhân: Khách hàng, người bán hàng. Mô tả: Khách hàng có thể trả tiền theo 3 phương thức:

1. Trả tiền mặt (Pay by Cash) 3. Trả bằng thẻ tín dụng (Pay by Credit) 3. Trả bằng séc (Pay by Check)

Tham chiếu tới: Các chức năng R1.1, R1.2, R1.3,

Người bán nhận tiền mặt/thẻ tín dụng/sec rồi thanh toán tiền thừa cho khách hàng sau khi thẻ tín dụng/sec đã được kiểm duyệt.

250

R1.9, R3.1, R3.2, R3.3.

Use Case cho chức năng Thu tiền (Cash Out)

Pay by Check

Pay by Credit

Bộ phận kiểm duyệt sec

Bộ phận kiểm duyệt thẻ

Pay by Cash

Cash Out

Khách hàng

Người bán hàng

251

Use Case cho chức năng Thu tiền (Cash Out)

Chú ý: Ngoài những đặc tả nêu trên, ta còn có thể xây dựng các kịch bản (scenario) hành động để mô tả các sự kiện xảy ra trong hệ thống. Mỗi kịch bản có thể mô tả theo hai luồng:

 Luồng thực hiện của các tác nhân  Luồng tương ứng với hệ thống.

của giáo trình)

252

(Xem thêm phần xây dựng kịch bản ở trang 57, 58

7. Mối quan hệ giữa các Use Case

Giữa các Use Case có ba quan hệ chính:

 Quan hệ mở rộng (extends)

 Quan hệ sử dụng (uses/include)

253

 Quan hệ theo nhóm hay theo gói (package).

8. Checkpoint - Use Case Model

Kiểm tra đã hoàn tất việc xác định yêu cầu của người dùng chưa? a. Kiểm tra về Use Case Model và Use Case

2.Sau khi nghiên cứu Use Case model, bạn có hình thành được một ý tưởng rõ ràng về các chức năng của hệ thống và cách thức mà chúng liên hệ với nhau?

1.Use-case model có dễ hiểu không?

3.Đã xác định hết các actor chưa? Tất cả các yêu cầu

chức năng được thỏa mãn chưa?

4.Use-case model có chứa các hành vi vô dụng nào

không?

8. Checkpoint

đáng không?

5. Việc chia các Use Case thành các Package có xác

6. Mỗi Use Case có ít nhất một actor tương tác?

7. Các Use Case có độc lập với nhau?

8. Tồn tại các Use Case có các luồng sự kiện và các

9. Liệu các Use Case có tên duy nhất, gợi nhớ, dễ hiểu để chúng không bị nhầm lẫn trong các giai đọan sau?

10.Các customers và users có hiểu tên và mô tả của

hành vi tương tự nhau không?

các Use Case không?

8. Checkpoint - Actors

1. Đã xác định hết các actor chưa?

b. Kiểm tra các Actors

3. Mỗi actor thật sự có một vai trò (role)? Có cần

2. Mỗi actor có tham gia vào ít nhất một Use Case?

ghép hoặc tách các actor không?

Use Case không?

4. Có tồn tại 2 actor đóng cùng một vai trò đối với 1

5. Tên của các actor có gợi nhớ không? Users và

customers có hiểu tên của chúng?

8. Checkpoint - Glossary

1. Các thuật ngữ có định nghĩa rõ ràng và súc tích?

c. Kiểm tra các Glossary

2. Mỗi thuật ngữ có sử dụng đâu đó trong các mô tả

Use Case?

3. Các thuật ngữ có được sử dụng hợp lý trong các

mô tả ngắn về các actors và Use Case?

3.4. THIẾT KẾ HƯỚNG ĐỐI TƯỢNG

 Thiết kế là 1 công đoạn quan trọng trong qui trình phát triển phần mềm; là bước chuyển tiếp của giai đoạn phân tích và là bước chuẩn bị trước khi tiến hành xây dựng phần mềm.

 Thiết kế là tiến trình mà ở đó xuất hiện mô hình các kiểu

mẫu của phần mềm. Các mô hình này chính là những nét phác thảo nên phần mềm. Nó cho chúng ta biết phần mềm chúng ta đang xây dựng là gì, đã có, đang có và sẽ có những gì.

 Thiết kế là nơi mà ta có thể trả lời câu hỏi :

 “Liệu phần mềm này có thể chạy được không?”  “Phần mềm có thể đáp ứng được các yêu cầu của khách

hàng hay không?”

258

mà không cần đợi đến công đoạn phát triển sau.

3.4.1. Vai trò của thiết kế

3.4. THIẾT KẾ HƯỚNG ĐỐI TƯỢNG ...

3.4.2. Các nguyên lý thiết kế

Nguyên lý thay thế Liskov: Các chức năng của

Nguyên lý ‘đóng mở’: một modun cần “mở” đối với việc phát triển thêm tính năng nhưng phải “đóng” đối với việc sửa đổi mã nguồn

hệ thống vẫn thực hiện đúng đắn nếu ta thay bất kì một lớp đối tượng nào bằng một lớp đối tượng kế thừa.

Nguyên lý phân tách giao diện: nên có nhiều

259

Nguyên lý nghịch đảo phụ thuộc: phụ thuộc vào mức trừu tượng, không phụ thuộc vào mức chi tiết.

giao diện đặc thù với bên ngoài hơn là chỉ có một giao diện dùng chung cho một mục đích.

3.5. CÁC NHÓM MẪU THIẾT KẾ

Trong bất kỳ một hệ thống hướng đối tượng nào

3.5.1. Sự quan trọng của mẫu thiết kế

cũng có thể gặp các vấn đề lặp lại. Do đó, một mẫu thiết kế là một giải pháp tổng thể cho các vấn đề chung trong thiết kế phần mềm.

 Mẫu thiết kế tuân thủ nghiêm ngặt các nguyên lý

thiết kế hướng đối tượng ở trên.

260

 Mẫu thiết kế không phụ thuộc vào ngôn ngữ lập trình, công nghệ, và nó có các quy tắc biểu diễn của ngôn ngữ UML.

3.5. CÁC NHÓM MẪU THIẾT KẾ ...

Mẫu thiết kế sẽ giúp cho việc giải quyết vấn đề

3.5.2. Sự quan trọng của mẫu thiết kế ...

nhanh, gọn hơn và hợp lý hơn.

Mẫu thiết kế còn được sử dụng nhằm cô lập các thay đổi trong mã nguồn, từ đó làm cho hệ thống có khả năng tái sử dụng cao.

261

Chúng ta sẽ tìm hiểu một số mẫu thiết kế kinh điển GoF - Gang of Four - bốn tác giả Erich Gamma, Richard Helm, Ralph Johnson và John Vlissides của cuốn sách Design Patterns: Elements of Reusable Object-Oriented Software (Download ở site: http://www.uml.org.cn/c++/pdf/DesignPatterns.pdf)

3.5. CÁC NHÓM MẪU THIẾT KẾ ...

GoF đề xuất 23 mẫu thiết kế được chia theo 3

3.5.3. Các loại mẫu thiết kế

nhóm theo mục đích sử dụng:

 Structural Patterns – Các mẫu kiến trúc

 Creational Patterns – Các mẫu kiến tạo

262

 Behavioral Patterns – Các mẫu tương tác

a. CÁC NHÓM MẪU THIẾT KẾ

1. Các mẫu thuộc nhóm kiến tạo - Creational Patterns

2. Các mẫu thuộc nhóm kiến trúc - Structural Patterns

263

a. CÁC NHÓM MẪU THIẾT KẾ ...

1. Các mẫu thuộc nhóm tương tác - Behavioral Patterns

264

b. CÁC MẪU THUỘC NHÓM KIẾN TẠO - CREATIONAL PATTERNS

Mục đích chung: Các mẫu này được dùng để khởi tạo các đối tượng

trong hệ thống.

 Đơn giản – Một vài mẫu làm cho việc khởi tạo đối tượng

trở nên dễ dàng, vì vậy lớp “gọi” khởi tạo đối tượng không phải viết mã nhiều cũng như phức tạp

265

Hầu hết các hệ thống hướng đối tượng phức tạp yêu cầu nhiều đối tượng được thể hiện theo thời gian, và các mẫu này hỗ trợ cho việc tạo các tiến trình bằng việc cung cấp các khả năng:  Sự thể hiện chung – Điều này cho phép các đối tượng được tạo ra trong hệ thống không cần phải định nghĩa một đặc tả kiểu lớp trong mã nguồn

Mẫu Abstract Factory

1.Ý nghĩa: Abstract Factory cung cấp 1 giao diện để tạo ra đối

tượng mà không phải mô tả các lớp cụ thể.

266

Abstract Factory dùng để đóng gói một nhóm gồm những lớp đóng vai trò là “phân xưởng” (Factory) trong ứng dụng, đây là những lớp được dùng để tạo lập các đối tượng. Các lớp “phân xưởng” này có chung một giao diện lập trình được kế thừa từ một lớp cha thuần ảo gọi là “lớp phân xưởng ảo”

2. Cấu trúc mẫu:

267

268

Trong đó:  AbstractFactory: là lớp trừu tượng, tạo ra các đối tượng thuộc 2 lớp trừu tượng là: AbstractProductA và AbstractProductB  ConcreteFactoryX: là lớp kế thừa từ AbstractFatory, lớp này sẽ tạo ra một đối tượng cụ thể  AbstractProduct: là các lớp trừu tượng, các đối tượng cụ thể sẽ là các thể hiện của các lớp dẫn xuất từ lớp này.

2. Cấu trúc mẫu:

1 game, trong đó có thú ăn thịt và thú ăn cỏ Thú ăn thịt: Sư tử, Sói Thú ăn cỏ: Linh dương, Bò rừng Phân biệt theo các châu

Châu Phi: Sư tử, Linh dương Châu Mỹ: Sói, Bò rừng

269

The classes and/or objects participating in this pattern are:

AbstractFactory (ContinentFactory)

declares an interface for operations that create abstract products

ConcreteFactory (AfricaFactory,

AmericaFactory)

implements the operations to create concrete product objects

AbstractProduct (Herbivore, Carnivore) declares an interface for a type of product object

Product (Wildebeest, Lion, Bison, Wolf) defines a product object to be created by the corresponding concrete factory implements the AbstractProduct interface

Client (AnimalWorld)

uses interfaces declared by AbstractFactory and AbstractProduct classes

270

Xem code in C# tại: http://www.dofactory.com/Patterns/PatternAbstract.aspx

Mẫu Abstract Factory

3. Tình huống áp dụng Phía trình khách sẽ không phụ thuộc vào việc những

sản phẩm được tạo ra như thế nào.

sản phẩm.

Ứng dụng sẽ được cấu hình với một hoặc nhiều họ

Các đối tượng cần phải được tạo ra như một tập

Chúng ta muốn cung cấp một tập các lớp và chúng ta muốn thể hiện các ràng buộc, các mối quan hệ giữa chúng mà không phải là các thực thi của chúng (interface).

271

hợp để có thể tương thích với nhau.

Mẫu Abstract Factory ...

Giả sử ta cần viết một ứng dụng quản lý địa chỉ và số điện thoại cho các quốc gia trên thế giới. Điạ chỉ và số địa thoại của mỗi quốc gia sẽ có 1 số điểm giống nhau và 1 số điểm khác nhau. Ta xây dựng sơ đồ lớp như sau:

272

4. Ví dụ:

Ta sẽ xây dựng các phương thức tạo Address, và PhoneNumber cụ thể trong các lớp:

• USAAddressPhoneFactory • FrechAddressPhoneFactory.

Với phương thức createProductAddress() của lớp USAAddressPhoneFactory sẽ trả về đối tượng của lớp USAAddress Với phương thức createProductAddress() của lớp FrechAddressPhoneFactory sẽ trả về đối tượng của lớp FrechAddress Tương tự với PhoneNumber.

273

Mẫu Builder

Tách các thành phần của một đối tượng phức hợp, để có thể cùng khởi tạo một lần mà có thể tạo nên nhiều định dạng khác nhau.

274

1.Ý nghĩa:

2. Cấu trúc mẫu:

Trong đó,  Director: là lớp điều khiển tạo ra một đối tượng Product  Builder: là lớp trừu tượng cho phép tạo ra đối tượng Product từ các phương thức nhỏ khởi tạo từng thành phần của Product  ConcreteBuilder: là lớp dẫn xuất của Builder, khởi tạo từng đối tượng cụ thể, lớp này sẽ khởi tạo đối tượng.

275

Mẫu Builder ...

3. Tình huống áp dụng Có cấu trúc bên trong phức tạp (đặc biệt là một biến

là một tập các đối tượng liên quan với nhau)

Có các thuộc tính phụ thuộc vào các thuộc tính khác Sử dụng các đối tượng khác trong hệ thống mà có

thể khó khởi tạo hoặc khởi tạo phức tạp.

4. Ví dụ

276

Ta lại xét đối tượng Address, có các thành phần sau: Street, City và Region. Ta phân tách việc khởi tạo 1 đối tượng Address thành các phần : buildStreet, buildCity và buildRegion.

Mẫu Builder ...

Trong đó:  AddressDirector: là lớp tạo ra đối tượng Address  AddressBuilder: là lớp trừu tượng cho phép tạo ra 1 đối tượng Address bằng các phương thức khởi tạo từng thành phần của Address  USAddressBuilder: là lớp tạo ra các Address. USAddressBuilder sẽ tạo ra địa chỉ theo chuẩn của USA 277

Mẫu Factory Method

Định nghĩa một phương thức chuẩn để khởi tạo đối tượng, như là một phần của phương thức tạo, nhưng việc quyết định kiểu đối tượng nào được tạo ra thì phụ thuộc vào các lớp con.

278

1.Ý nghĩa:

2. Cấu trúc mẫu:

Trong đó,  Creator là lớp trừu tượng,

khai báo phương thức factoryMethod() nhưng không cài đặt

279

 Product cũng là lớp trừu tượng  ConcreteCreatorA và ConcreteCreatorB là 2 lớp kế thừa từ lớp Creator để tạo ra các đối tượng riêng biệt  ConcreteProductA và ConcreteProductB là các lớp kế thừa của lớp Product, các đối tượng của 2 lớp này sẽ do 2 lớp ConcreteCreatorA và ConcreteCreatorB tạo ra

Mẫu Factory Method ...

Khi bạn muốn 1 lớp con, mở rộng từ 1 lớp cha,

3. Tình huống áp dụng Khi bạn muốn tạo ra một framework có thể mở rộng, có nghĩa là nó cho phép tính mềm dẻo trong một số quyết định như chỉ ra loại đối tượng nào được tạo ra

quyết định lại đối tượng được khởi tạo.

nhưng không biết loại đối tượng nào được khởi tạo Bạn cần một vài khai báo chồng phương thức tạo

Khi bạn biết khi nào thì khởi tạo một đối tượng

280

với danh sách các tham số như nhau, điều mà Java không cho phép. Thay vì điều đó ta sử dụng các Factory Method với các tên khác nhau.

4. Ví dụ: Xét lại ví dụ về các địa chỉ ở phần Abstract Pattern

281

4.3.4. Mẫu Prototype

Giúp khởi tạo đối tượng bằng cách copy một đối tượng khác đã tồn tại (đối tượng này là “prototype” – nguyên mẫu).

282

1.Ý nghĩa:

Mẫu Prototype

Trong đó: Prototype là lớp trừu tượng cài đặt phương thức myClone() là phương thức copy bản thân đối tượng đã tồn tại. ConcretePrototype1 và ConcretePrototype2 là các lớp kế thừa lớp Prototype.

283

2. Cấu trúc mẫu:

Mẫu Prototype

3. Tình huống áp dụng Khi bạn muốn khởi tạo một đối tượng bằng cách sao

chép từ một đối tượng đã tồn tại.

Pattern

284

4. Ví dụ: Xét lại ví dụ về các địa chỉ ở phần Abstract

Mẫu Singleton

Mẫu này được thiết kế để đảm bảo cho một lớp chỉ có thể tạo ra duy nhất một thể hiện của nó.

2. Cấu trúc mẫu:

Trong đó:

Singleton cung cấp một phương thức tạo private, duy trì một thuộc tính tĩnh để tham chiếu đến một thể hiện của lớp Singleton này, và nó cung cấp thêm một phương thức tĩnh trả về thuộc tính tĩnh này.

285

1.Ý nghĩa:

Mẫu Singleton ...

3. Tình huống áp dụng Khi bạn muốn lớp chỉ có 1 thể hiện duy nhất và nó

286

có hiệu lực ở mọi nơi.

c. NHÓM CÁC MẪU CẤU TRÚC- Structural Patterns

Mục đích chung: Đề cập đến việc các đối tượng kết hợp với nhau để

tạo thành các cấu trúc hữu dụng hơn

Các mẫu Structural diễn tả một cách có hiệu quả cả việc phân chia hoặc kết hợp các phần tử trong một ứng dụng.

ứng dụng rất rộng: chẳng hạn,  Mẫu Adapter có thể làm cho hai hệ thống không tương

thích có thể giao tiếp với nhau,

 Mẫu Façade cho phép bạn làm đơn giản hóa một giao

tiếp để sử dụng mà không cần gỡ bỏ tất cả các tùy biến đã có trong hệ thống.

287

Những cách mà các mẫu Structural áp dụng vào

Mẫu Adapter

thống một lớp đối tượng mong muốn nào đó.

1. Ý nghĩa: Tạo một giao diện trung gian để gắn kết vào hệ

Tagret là một interface định nghĩa chức năng, yêu cầu mà Client cần sử dụng Adaptee là lớp chức các chức năng mà Target cần sử dụng để tạo ra được chức năng mà Target cần cung cấp cho Client Adapter thực thi từ Target và sử dụng đối tượng lớp Adaptee, Apdater có nhiệm vụ gắn kết Adaptee vào Target để có được chức năng mà Client mong muốn

288

2. Cấu trúc mẫu:

Mẫu Adapter

tương thích với yêu cầu hiện tại

 Muốn tạo 1 lớp có thể sử dụng lại mà lớp này có thể làm việc

được với những lớp khác không liên hệ gì với nó, và là những lớp không cần thiết tương thích trong giao diện.

3. Tình huống áp dụng  Muốn sử dụng 1 lớp có sẵn nhưng giao tiếp của nó không

 Trước đó ta đã có một lớp có một chức năng là lấy các kí tự

số trong một chuỗi

 Giờ ta muốn sử dụng chức năng lấy kí tự số vào hệ thống lấy

289

số điện thoại

4. Ví dụ:  Có một hệ thống PhoneTarget cần thực hiện một chức năng gì đó, trong đó có một phương thức trả về số điện thoại trong một chuỗi đầu vào

Mẫu Bridge

1. Ý nghĩa: Một thành phần trong OOP thường có 2 phần: phần ảo – định nghĩa các chức năng và phần thực thi – thực thi các chức năng được định nghĩa trong phần ảo. Hai phần này liên hệ với nhau qua quan hệ kế thừa. Những thay đổi trong phần ảo dẫn đến các thay đổi trong phần thực thi. Mẫu Bridge được sử dụng để tách thành phần ảo và thành phần thực thi riêng biệt, do đó các thành phần này có thể thay đổi độc lập và linh động. Thay vì liên hệ với nhau bằng quan hệ kế thừa hai thành phần này liên hệ với nhau thông qua quan hệ “chứa trong”.

290

2. Cấu trúc mẫu:

291

Trong đó: o Abstraction: là lớp trừu tượng khai báo các chức năng và cấu trúc cơ bản, trong lớp này có 1 thuộc tính là 1 thể hiện của giao tiếp Implementation, thể hiện này bằng các phương thức của mình sẽ thực hiện các chức năng abstractionOp() của lớp Abstraction o Implementation: là giao tiếp thực thi của lớp các chức năng nào đó của Abstraction o RefineAbstraction: là định nghĩa các chức năng mới hoặc các chức năng đã có trong Absrtaction. o ConcreteImplement: là các lớp định nghĩa tường minh các thực thi trong lớp giao tiếp Implementation

4.4.2 Mẫu Bridge

Mẫu Bridge

3. Tình huống áp dụng

Khi bạn muốn những thay đổi của phần thực thi sẽ không ảnh hưởng đến client.

Khi bạn muốn tạo ra sự mềm dẻo giữa 2 thành phần ảo và thực thi của một thành phần, và tránh đi mối quan hệ tĩnh giữa chúng.

Bạn định nghĩa nhiều thành phần ảo và thực thi.

292

Phân lớp con một cách thích hợp, nhưng bạn muốn quản lý 2 thành phần của hệ thống một các riêng biệt

1. Ý nghĩa: Mẫu này nhằm gom các đối tượng vào trong một cấu trúc cây để thể hiện được cấu trúc tổng quát của nó. Trong khi đó cho phép mỗi phần tử của cấu trúc cây có thể thực hiện một chức năng theo một giao tiếp chung.

2. Cấu trúc mẫu:

293

Mẫu Composite

Trong đó: Component: là một giao tiếp định nghĩa các phương thức cho tất cả các phần của cấu trúc cây. Component có thể được thực thi như một lớp trừu tượng khi bạn cần cung cấp các hành vi cho tất cả các kiểu con. Bình thường, các Component không có các thể hiện, các lớp con hoặc các lớp thực thi của nó, gọi là các nốt, có thể có thể hiện và được sử dụng để tạo nên cấu trúc cây.

Composite: là lớp được định nghĩa bởi các thành phần mà nó chứa. Composite chứa một nhóm động các Component, vì vậy nó có các phương thức để thêm vào hoặc loại bổ các thể hiện của Component trong tập các Component của nó. Những phương thức được định nghĩa trong Component được thực thi để thực hiện các hành vi đặc tả cho lớp Composite và để gọi lại phương thức đó trong các nốt của nó. Lớp Composite được gọi là lớp nhánh hay lớp chứa Leaf: là lớp thực thi từ giao tiếp Component. Sự khác nhau giữa lớp Leaf và Composite là lớp Leaf không chứa các tham chiếu đến các Component khác, lớp Leaf 294 đại diện cho mức thấp nhất của cấu trúc cây.

Mẫu Composite

3. Tình huống áp dụng

Khi có một mô hình thành phần với cấu trúc nhánh – lá, toàn bộ – bộ phận, …

Bạn muốn thăm cấu trúc thành phần theo một cách qui chuẩn, sử dụng các thao tác chung thông qua mối quan hệ kế thừa. 4. Ví dụ:

Khi cấu trúc có thể có vài mức phức tạp và động

295

 Trở lại ví dụ về dự án, một Project (Composite) có nhiều tác vụ Task (Leaf), ta cần tính tổng thời gian của dự án thông qua thời gian của tất cả các tác vụ

1.Ý nghĩa: Bổ sung trách nhiệm cho đối tượng tại thời điểm thực thi. Đây được xem là sự thay thế hiệu quả cho phương pháp kế thừa trong việc bổ sung trách nhiệm cho đối tượng và mức tác động là ở mức đối tượng thay vì ở mức lớp như phương pháp kế thừa. 2. Cấu trúc mẫu:

296

Mẫu Decorator

Trong đó: Component: là một interface chứa các phương thức ảo (ở đây là defaultMethod) ConcreteComponent: là một lớp kế thừa từ Component, cài đặt các phương thức cụ thể (defaultMethod được cài đặt tường minh) Decorator: là một lớp ảo kế thừa từ Component đồng thời cũng chứa 1 thể hiện của Component, phương thức defaultMethod trong Decorator sẽ được thực hiện thông qua thể hiện này. ConcreteDecoratorX: là các lớp kế thừa từ Decorator, khai báo tường minh các phương thức, đặc biệt trong các lớp này khai báo tường minh các “trách nhiệm” cần thêm vào khi run-time

297

Mẫu Decorator

3. Tình huống áp dụng Khi bạn muốn thay đổi động mà không ảnh hưởng đến người dùng, không phụ thuộc vào giới hạn các lớp con. Khi bạn muốn thành phần có thể thêm vào hoặc rút bỏ đi khi hệ thống đang chạy Có một số đặc tính phụ thuộc mà bạn muốn ứng dụng một cách động và bạn muốn kết hợp chúng vào trong một thành phần.

298

Mẫu Decorator

4. Ví dụ:

tính

khác

299

 Giả sử trong thư viện có liệu: sách, video… các tài Các loại tài liệu này có các nhau, thuộc phương thức hiển thị của giao tiếp LibraryItem sẽ hiển thị các thông tin này. Giả sử, ngoài các thông tin ta thuộc tính trên, đôi khi muốn hiển thị độc giả mượn một cuốn sách (chức năng hiển thị độc giả này không phải lúc nào cũng muốn hiển thị), hoặc muốn xem đoạn video(không thường xuyên).

1.Ý nghĩa:

Cung cấp một giao tiếp hợp nhất của một tập các giao tiếp trong hệ thống con. Façade định nghĩa một giao tiếp mức cao hơn để làm cho hệ thống con dễ sử dụng

2. Cấu trúc mẫu:

300

Mẫu Façade

Trong đó: Class1 và Class2 là các lớp đã có trong hệ thống Façade là lớp sử dụng các phương thức của Class1 và Class2 để tạo ra một giao diện mới, thường được sử dụng, đỡ phức tạp hơn khi sử dụng riêng Class1 và Class2

301

Mẫu Façade

302

3. Tình huống áp dụng Làm cho một hệ thống phức tạp dễ sử dụng hơn bằng cách cung cấp một giao tiếp đơn gian mà không cần loại bỏ các lựa chọn phức tạp Giảm bớt sự ràng buộc giữa client và các hệ thống con.

4. Ví dụ:

 Giả sử hệ thống cũ đã có các lớp: Địa chỉ, Số điện thoại, Tên tuổi về thông tin của một người, giờ ta muốn quản lý các thông tin trên của một người, ta tận dụng lại hệ thống cũ, xây một lớp Người sử dụng lại các lớp ở trên.

303

Mẫu Façade

1.Ý nghĩa:

Làm phương tiện dùng chung để quản lý một cách hiệu quả một số lượng lớn các đối tượng nhỏ có các đặc điểm chung, mà các đối tượng nhỏ này lại được sử dụng tuỳ thuộc vào hoàn cảnh, điều kiện ngoài.

304

Mẫu Flyweight

2. Cấu trúc mẫu:

305

Trong đó: o FlyweightFactory: tạo ra và quản lý các đối tượng Flyweight o Flyweight là một giao tiếp định nghĩa các phương thức chuẩn o ConcreteFlyweightX: là các lớp thực thi của Flyweight, các thể hiện của các lớp này sẽ được sử dụng tuỳ thuộc vào điều kiện ngoài.

4.4.6 Mẫu Flyweight

Mẫu Flyweight

3. Tình huống áp dụng

Ứng dụng sử dụng nhiều đối tượng giống hoặc gần giống nhau

Với các đối tượng gần giống nhau, những phần không giống nhau có thể tách rời với các phần giống nhau để cho phép các phần giống nhau có thể chia sẻ

Nhóm các đối tượng gần giống nhau có thể được thay thế bởi một đối tượng chia sẻ mà các phần không giống nhau đã được loại bỏ

306

Nếu ứng dụng cần phân biệt các đối tương gần giống nhau trong trạng thái gốc của chúng

4. Ví dụ:

Một ví dụ cổ điển của mẫu flyweight là các kí tự được

lưu trong một bộ xử lí văn bản (word processor). Mỗi kí tự đại diện cho một đối tượng mà có dữ liệu là loại font (font face), kích thước font, và các dữ liệu định dạng khác. Bạn có thể tưởng tượng là, với một tài liệu (document) lớn với cấu trúc dữ liệu như thế này thì sẽ bộ xử lí văn bản sẽ khó mà có thể xử lí được. Hơn nữa, vì hầu hết dữ liệu dạng này là lặp lại, phải có một cách để giảm việc lưu giữ này – đó chính là mẫu Flyweight. Mỗi đối tượng kí tự sẽ chứa một tham chiếu đến một đối tượng định dạng riêng rẽ mà chính đối tượng này sẽ chứa các thuộc tính cần thiết. Điều này sẽ giảm một lượng lớn sự lưu giữ bằng cách kết hợp mọi kí tự có định dạng giống nhau trở thành các đối tượng đơn chỉ chứa tham chiếu đến cùng một đối tượng đơn chứa định dạng chung đó.

307

Mẫu Flyweight

308

Mẫu Flyweight

1.Ý nghĩa:

Đại diện một đối tượng phức tạp bằng một đối tượng đơn giản, vì các mục đích truy xuất, tốc độ và bảo mật

2. Cấu trúc mẫu:

309

Mẫu Proxy

310

Trong đó: o Service: là giao tiếp định nghĩa các phương thức chuẩn cho một dịch vụ nào đó o RealService: là một thực thi của giao tiếp Service, lớp này sẽ khai báo tường minh các phương thức của Service, lớp này xem như thực hiện tốt tất cả các yêu cầu từ Service o Proxy: kế thừa Service và sử dụng đối tượng của RealService

Mẫu Proxy

311

3. Tình huống áp dụng Sử dụng mẫu Proxy khi bạn cần một tham chiếu phức tạp đến một đối tượng thay vì chỉ một cách bình thường Remote proxy – sử dụng khi bạn cần một tham chiếu định vị cho một đối tượng trong không gian địa chỉ(JVM) Virtual proxy – lưu giữ các thông tin thêm vào về một dịch vụ thực vì vậy chúng có thể hoãn lại sự truy xuất vào dịch vụ này Protection proxy – xác thực quyền truy xuất vào một đối tượng thực

4. Ví dụ:

Ví dụ lớp Image là một interface định nghĩa các phương thức xử lý

ảnh, nó có các lớp con là GIFImage và JPGImage. Theo hướng đối tượng thì thiết kế như thế có vẻ hợp lý, Client chỉ cần sử dụng lớp Image là đủ, còn tuỳ thuộc vào loại ảnh sẽ có các phương thức khác nhau Nhưng trong trường hợp, trên ứng dụng web chẳng hạn, một lúc ta đọc lên hàng trăm ảnh các loại và ta còn muốn xử lý tuỳ vào một điều kiện nào đó (ví dụ chỉ xử lý khi là ảnh JPG hoặc GIF). Nếu ta đặt điều kiện IF Image (sau đó sẽ tùy điều kiện này rồi xử lý riêng) thì không hợp lý, nếu đặt trong Client, nếu mỗi lần cần thay đổi IF ta lại sửa Client => không hợp lý khi Client là một ứng dụng lớn. Ta sử dụng Proxy, lớp ImageProxy chỉ là lớp đại diện cho Image, kế thừa từ Image và sử dụng các lớp GIFImage hay JPGImage. Khi cần thay đổi ta chỉ cần thay đổi trên Proxy mà không cần tác động đến Client và Image.

312

Mẫu Proxy

313

Mẫu Proxy

d. NHÓM CÁC MẪU TƯƠNG TÁC- Behavioral Patterns

314

1. Mục đích chung: mục đích mô tả sự tương tác giữa các đối tượng

Mẫu Chain of Responsibility

thống, nơi mà các thông điệp hoặc có thể được thực hiện ở tại một mức nơi mà nó được nhận lần đầu hoặc là được chuyển đến một đối tượng mà có thể thực hiện điều đóTạo một giao diện trung gian để gắn kết vào hệ thống một lớp đối tượng mong muốn nào đó.

1. Ý nghĩa: Mẫu này thiết lập một chuỗi bên trong một hệ

315

2. Cấu trúc mẫu:

Trong đó: o Handler: là một giao tiếp định nghĩa phương thức sử dụng để chuyển thông điệp qua các lần thực hiện tiếp theo. o ConcreteHandler: là một thực thi của giao tiếp Handler. Nó giữ một tham chiếu đến một Handler tiếp theo. Việc thực thi phương thức handleMessage có thể xác định làm thế nào để thực hiện phương thức và gọi một handlerMethod, chuyển tiếp thông điệp đến cho Handler tiếp theo hoặc kết hợp cả hai

316

Mẫu Chain of Responsibility

đối tượng trong hệ thống

3. Tình huống áp dụng Có một nhóm các đối tượng trong một hệ thống có thể đáp ứng tất cả các loại thông điệp giống nhau Các thông điệp phải được thực hiện bởi một vài các

317

Các thông điệp đi theo mô hình “thực hiện – chuyển tiếp”, một vài sự kiện có thể được thực hiện tại mức mà chúng được nhận hoặc tại ra, trong khi số khác phải được chuyển tiếp đến một vài đối tượng khác

Mẫu Chain of Responsibility

318

Hệ thống quản lý thông tin cá nhân có thể được sử dụng để quản lý các dự án như là các liên hệ. Ta hình dung một cấu trúc cây như sau; đỉnh là một dự án, các đỉnh con là các tác vụ của dự án đó, và cứ như vậy, mỗi đỉnh con tác vụ lại có một tập các đỉnh con tác vụ khác. Để quản lý cấu trúc này ta thực hiện như sau: -Ở mỗi đỉnh ta lưu các thông tin như sau: tên tác vụ, đỉnh cha, tập các đỉnh con -Ta xét thông điệp sau: duyệt từ đỉnh gốc (project cở sở) in ra các thông tin -Như vậy với thông điệp này, việc in thông tin ở một đỉnh là chưa đủ, ta phải chuyển tiếp đến in thông tin các đỉnh con của đỉnh gốc và chuyển tiếp cho đến khi không còn đỉnh con thì mới dừng

4. Ví dụ:

Mẫu Chain of Responsibility

319

Mẫu Command

1. Ý nghĩa: Gói một mệnh lệnh vào trong một đối tượng mà nó có thể được lưu trữ, chuyển vào các phương thức và trả về một vài đối tượng khác.

Trong đó: o Command: là một giao tiếp định nghĩa các phương thức cho Invoker sử dụng o Invoker: lớp này thực hiện các phương thức của đối tượng Command o Receiver: là đích đến của Command và là đối tượng thực hiện hoàn tất yêu cầu, nó có tất cả các thông tin cần thiết để thực hiện điều này o ConcreteCommand: là một thực thi của giao tiếp Command. Nó lưu giữa một tham chiếu Receiver mong muốn

320

2. Cấu trúc mẫu:

Luồng thực thi của mẫu Command như sau:

321

Mẫu Command

322

Client gửi yêu cầu đến GUI của ứng dụng Ứng dụng khởi tạo một đối tượng Command thích hợp cho yêu cầu đó (đối tượng này sẽ là các ConcreteCommand) Sau đó ứng dụng gọi phương thức executeCommand() với tham số là đối tượng Command vừa khởi tạo Invoker khi được gọi thông qua phương thức executeCommand() sẽ thực hiện gọi phương thức execute() của đối tượng Command tham số Đối tượng Command này sẽ gọi tiếp phương thức doAction() của thành phần Receiver của nó, được khởi tạo từ đầu, doAction() chính là phương thức chính để hoàn tất yêu cầu của Client

Mẫu Command

3. Tình huống áp dụng Hỗ trợ undo, logging hoặc transaction Thực hiện hàng đợi lệnh và thực hiện lệnh tại các

Hạn chế sự chặt chẽ của yêu cầu với đối tượng thực

thời điểm khác nhau

323

hiện hoàn tất yêu cầu đó

Mẫu Interpreter

 Ý tưởng tương tự như vậy biểu diễn các biểu thức tính

toán theo cú pháp Ba Lan

1. Ý nghĩa:  Ý tưởng chính của Interpreter là triển khai ngôn ngữ máy tính đặc tả để giải quyết nhanh một lớp vấn đề được định nghĩa. Ngôn ngữ đặc tả thường làm cho vấn đề được giải quyết nhanh hơn ngôn ngữ thông thường từ một cho đến vài trăm lần.

324

2. Cấu trúc mẫu:

Mẫu Command