Hướng dẫn phân tích và thiết kế hướng đối tượng bằng UML

MỤC LỤC

THẹ DU Vẽ NGệN NGƯ OOP

Cếu truc 1 chương trònh MDI ₫ơn gian

    Interface chỉ ₫ươc dung trong trương hơp ₫ăc bi t va kh ng tương ₫ương vơi abstract type.

    Hử̃ trơ abstract class

    Bử mửn Cửng nghù phờ̀n mù̀m Khoa CNTT. ĐH Bach Khoa Tp.HCM. Mửn Phõn tớch & Thiết kế hướng ₫ối tượng dựng UML Slide 39. Bử mửn Cửng nghù phờ̀n mù̀m Khoa CNTT. ĐH Bach Khoa Tp.HCM. Mửn Phõn tớch & Thiết kế hướng ₫ối tượng dựng UML Slide 41. package graphics;. public class Circle extends Graphic implements Draggable {. la package default. trong phat bi ̉u package).

    Hử̃ trơ package

    Dịch thuửc tủnh dư liùu

    Mửn Phõn tớch & Thiết kế hướng ₫ối tượng dựng UML Slide 55 Chương 3: Nguy n tăc dịch OOP.

    Tử́i ưu hoa code tao ra

    Mửn Phõn tớch & Thiết kế hướng ₫ối tượng dựng UML Slide 63 Chương 3: Nguy n tăc dịch OOP.

    Tử́i ưu hoa code tao ra (tt)

    Mửn Phõn tớch & Thiết kế hướng ₫ối tượng dựng UML Slide 65 Chương 3: Nguy n tăc dịch OOP.

    Key concepts

    Architecture and Models

    Mửn Phõn tớch & Thiết kế hướng ₫ối tượng dựng UML Slide 105 Trương Đai Hoc Bach Khoa Tp.

    Cac né́i quan hã giưa cac actor va actor

    Mửn Phõn tớch & Thiết kế hướng ₫ối tượng dựng UML Slide 117 C us tom er.

    CÝ́u truc lai mé hÉnh Use-Case

    Mửn Phõn tớch & Thiết kế hướng ₫ối tượng dựng UML Slide 127 Trương Đai Hoc Bach Khoa Tp.

    PhÝn tÈch package

    Mửn Phõn tớch & Thiết kế hướng ₫ối tượng dựng UML Slide 147 Trương Đai Hoc Bach Khoa Tp.

    Thiã́t kã́ hã thé́ng con (Subsystem)

    Mửn Phõn tớch & Thiết kế hướng ₫ối tượng dựng UML Slide 175 Trương Đai Hoc Bach Khoa Tp.

    Tổng quát về hoạt ₫ộng debug ứng dụng

    ₫ểbiếtứng dụng chạy₫úng hay sai theo yêu cầu, lịch sử gọi hàm trong call strack, thêm/bớt các ₫iều kiện dừng,… ₫iều khiển việc thi hành tiếp theo của ứng dụng, lúc nàyứng dụng sẽchuyển sang chế ₫ộ Running. Mỗi khiứng dụng₫ược chạy tiếp, nó chuyển qua chế ₫ộRunning, nhưng sẽnhanh chóng chạy₫ến lệnh dừng và chuyển vềchế ₫ộPause (trừphi bị'blocked' chờI/O hay bị'loop' trong các vòng lặp vô tận).

    Tổng quát về tiện ích debug tích hợp trong VC++

    Trong quá trình debug, ứng dụng ở chế ₫ộ Pause chủ yếu thời gian và người debug tương tác vớiứng dụng chủyếuở chế ₫ộnày. Đểhiệu chỉnh giá trị của 1 biến nào ₫ó (do ₫ã bị sai, nhưng muốn sửa lại cho ₫úng hầu có thể kiểm thử các lệnh còn lại), người debug có thể dời cursor về cell chứa giá trị hiện hành của biến ₫ó (trong cửa sổ Variable hay trong cửa sổ Watch rồi hiệu chỉnh lại giá trị mới).

    Các thao tác ₫ể xem và hiệu chỉnh biến dữ liệu

    ƒ dời chuột ₫ến tên biến trong cửa sổ code, 1 cửa sổ nhỏ chứa giá trị của biến. ƒ nhập biểu thức (thường là biến dữliệu) vào vùng Name của cửa sổWatch ₫ể xem nội dung của nó.

    Các thao tác ₫ể xem vị trí thi hành hiện tại

    ƒ Xem danh sách các ₫iểm dừng hiện hành, có thể xóa hết chúng bằng cách chọn button “Remove All”, có thể xóa từng ₫iểm dừng bằng cách chọn nó rồi ấn button “Remove”. ƒ Muốn thiết lập ₫iểm dừng mới, chọn tab “Location”, nhập vị trí lệnh cần dừng và ₫iều kiện dừng mong muốn (mặc ₫ịnh là luôn luôn dừng ở vị trí qui ₫ịnh).

    Các lệnh thiết lập ₫iều kiện dừng

    ƒ Muốn thiết lập ₫iểm dừng mới dựa trên 1 biến nào ₫ó bị thay ₫ổi giá trị, chọn tab “Data”, nhập biểu thức cần tính toán (biến cần quan tâm). ƒ Muốn thiết lập ₫iểm dừng mới dựa trên thông báo (message) của Windows, chọn tab “Message”, chọn hàm xử lý, chọn thông báo cần dừng.

    Các lệnh ₫iều khiển chạy tiếp ứng dụng

    Ta có thể(và nên) thiết lập nhiều ₫iểm dừng₫ồng thời ₫ể'rào chắn' nhiều luồng thi hành khác nhau của chương trình. ƒ chọn menu Debug.Break ₫ể dừng ₫ột ngột việc chạy ứng dụng, lệnh ₫ang thực hiện sẽ ₫ược₫ỏnh dấu₫ểta dễtheo dừi.

    Các lệnh ₫iều khiển khác

    ƒ chọn menu Debug.Restart₫ểkết thúc việc chạyứng dụng rồi bắt₫ầu chạy lại từ ₫ầu. Nếuứng dụng₫ang bị 'block' chờ biến cốI/O, sẽkhông có lệnh nào₫ược dánh dấu cả.

    CÁC MẪU CẤU TRÚC

    ‰ Thiết kế phần mềm là một vấn ₫ề rất khó khăn, nhất là khi phần mềm lớn, mối quan hệ giữa các phần tử nhiều →bản thiết kế thường không hiệu quả hoặc có lỗi. ‰ Mục tiêu của thiết kế: không chỉ thiết kế những phần mềm ₫úng mà còn có thể hạn chế hoặc hỗ trợ tái thiết kế trong tương lai.

    Giới thiệu

    ‰ Các lỗi thiết kế thường phải trả giá cao do ảnh hưởng ₫ến nhiều giai. Tuy nhiên việc xây dựng những phần mềm HĐT như thế phụ thuộc nhiều vào khả năng người thiết kế.

    Giới thiệu (tt)

    ‰ Một biện pháp ₫ược ₫ề xuất ₫ể có những bản thiết kế tốt: sử dụng lại những mẫu thiết kế của những chuyên gia ₫ã qua kiểm nghiệm thực tế. ‰ Giúp người tìm hiểu nắm vững hơn ₫ặc ₫iểm ngôn ngữ lập trình, nhất là lập trình hướng ₫ối tượng.

    Vai trò của design pattern

    ‰ Có nhiều loại Software patterns: analysis patterns, design patterns, organization patterns, process patterns… Bài giảng này chỉ tập trung vào Object Oriented Design Patterns (từ ₫ây về sau gọi là Design Patterns hay mẫu thiết kế). ƒ Structural — Cung cấp cơ chế xử lý những lớp không thể thay ₫ổi (lớp thư viện của third party…), ràng buộc muộn (lower coupling) và cung cấp các cơ chế khác ₫ể thừa kế.

    Phân loại software patterns

    ƒ Creational — Khắc phục các vấn ₫ề khởi tạo ₫ối tượng, hạn chế sự phụ thuộc platform. ƒ Behavioral — Che dấu hiện thực của ₫ối tượng, che dấu giải thuật, hỗ trợ việc thay ₫ổi cấu hình ₫ối tượng một cách linh ₫ộng.

    Phân loại Object Oriented Design Patterns

    ‰ Xác ₫ịnh số lượng và kích thước ₫ối tượng: trong trường hợp hệ thống cần ràng buộc số lượng xác ₫ịnh ₫ối tượng ₫ang hoạt ₫ộng hay người thiết kế băn khoăn về việc nên tập trung một số chức năng nào ₫ó vào trong 1 ₫ối tượng hay tách ra thành nhiều ₫ối tượng. ‰ Giúp thiết kế theo hướng tái sử dụng và linh ₫ộng bằng cách sử dụng mối quan hệ giữa các ₫ối tượng (bao gộp, thừa kế…) một cách phù hợp và thiết kế theo hướng tiên ₫oán trước các thay ₫ổi trong tương lai.

    Khả năng ứng dụng design patterns

    ‰ Tìm kiếm ₫ối tượng: việc phân chia hệ thống thành một tập hợp các ₫ối tượng hoạt ₫ộng hiệu quả là công việc khó khăn. ₫ưa ra những ₫ối tượng thường gặp trong những trường hợp thiết kế tương tự ₫ã gặp trước ₫ây.

    Cấu trúc design pattern sẽ trình bày

    ‰ Các mẫu cấu trúc (Structural Patterns) tập trung giải quyết vấn ₫ề kết hợp các lớp và/hoặc ₫ối tượng thành một kiến trúc lớn hơn. ‰ Các mẫu cấu trúc ₫ối tượng (structural object patterns) tập trung vào việc kết hợp các ₫ối tượng ₫ể thực hiện những chức năng nào ₫ó.

    Structural Patterns

    Tương tự quá trình ₫a thừa kế: một lớp thừa kế từ nhiều lớp cha sẽ mang ₫ặc ₫iểm của tất cả các lớp cha gộp lại. ‰ Trong các slide tiếp theo, chúng ta sẽ tìm hiểu các mẫu: Adapter, Composite, Proxy, Decorator, Facade, Flyweight.

    Adapter

    ‰ Các mẫu cấu trúc lớp (structural class patterns) sử dụng thừa kế ₫ể kết hợp các lớp hay các interface.

    Các phần tử tham gia

    ‰ muốn dùng một lớp ₫ã có sẵn nhưng interface của nó không tương thích với interface ₫ang sử dụng trong khi chúng ta chỉ muốn dùng interface. ‰ (₫ối với mẫu object adapter) muốn sử dụng nhiều lớp con ₫ã có sẵn nhưng sẽ không hiệu quả nếu phải chuyển interface (bằng mẫu Adapter) của từng lớp con.

    Các ngữ cảnh nên dùng mẫu Adapter

    ‰ muốn tạo ra các lớp có thể giao tiếp với các lớp khác nhưng chưa biết trước interface của những lớp ₫ó.

    Sơ ₫ồ cấu trúc của mẫu Composite

    ƒ Khai báo interface và hiện thực một số tác vụ chung cho các ₫ối tượng của những lớp thừa kế (gọi chung là các component). Ví dụ: compiler (chương trình con hay module có thể bao gộp các chương trình con hay module khác…); chương trình giao diện GUI (window là ₫ối tượng phức, button là ₫ối tượng ₫ơn); chương trình text editor….

    Các ngữ cảnh nên dùng mẫu Composite

    ‰ Mục tiêu : Cung cấp ₫ối tượng ₫ại diện cho một ₫ối tượng khác ₫ể hỗ trợ hoặc kiểm soát quá trình truy xuất ₫ối tượng ₫ó. ƒ Những ₫ối tượng lớn khi khởi tạo sẽ tốn nhiều tài nguyên, do ₫ó nên trì hoãn thời ₫iểm khởi tạo thực sự các ₫ối tượng này.

    Sơ ₫ồ cấu trúc của mẫu Proxy

    ƒ kiểm soát quá trình truy xuất ₫ến ₫ối tượng RealSubject, có thể tạo hoặc delete ₫ối tượng này. + virtual proxy: chứa các thông tin về ₫ối tượng realSubject ₫ể có thể khởi tạo lại nó sau này.

    Sơ ₫ồ cấu trúc của mẫu Decorator

    ƒ ₫ịnh nghĩa interface cho các ₫ối tượng mà ta cần thêm trách nhiệm cho chúng 1 cách ₫ộng. ƒ chứa tham khảo ₫ến ₫ối tượng Component và ₫ịnh nghĩa interface tương thích với interface của Component.

    Các ngữ cảnh nên dùng mẫu Decorator

    Để dịch source code, ta có thể viết 1 ứng dụng gọi dịch vụ của từng class ₫ể duyệt token, parser, xây dựng cây cú pháp, tạo code ₫ối tượng. Cách khắc phục là ₫ịnh nghĩa 1 class mới với giao tiếp hợp nhất tên là Compiler, nó cung cấp 1 hàm Compile (file), ứng dụng nào cần dịch source code chỉ cần gởi thông ₫iệp Compile ₫ến ₫ối tượng Compiler.

    Facade

    ƒ tối thiểu hóa tính "coupling" giữa các hệ thống con ₫ể tối thiểu hóa giao tiếp giữa các hệ thống con. ƒ hệ thống con biên dịch có nhiều class phục vụ các bước biên dịch rời ràc như Scanner, Parser, ProgramNode, BytecodeStream,.

    Thí dụ về cấu trúc Facade

    ‰ Mục tiêu : cung cấp interface hợp nhất cho tập các interface của 1 hệ thống con. Facade ₫ịnh nghĩa 1 interface cấp cao hơn các interface có sẵn ₫ể làm cho hệ thống con dễ sử dụng hơn.

    Sơ ₫ồ cấu trúc của mẫu Flyweight

    ƒ ₫ịnh nghĩa interface cho ₫ối tượng nhận yêu cầu và hoạt ₫ộng theo trạng thái ngoài. ‰ nhiều nhóm ₫ối tượng có thể ₫ược thay thế bằng 1 số nhỏ ₫ối tượng khi các trạng thái ngoài của chúng bị loại bỏ.

    Các ngữ cảnh nên dùng mẫu Flyweight

    Mửn Phõn tớch & Thiết kế hướng ₫ối tượng dựng UML Slide 263 Trường Đại Học Bách Khoa Tp.

    Creational Patterns

    Khi ₫ó nếu muốn thay ₫ổi lớp sẽ tạo ₫ối tượng thì chỉ cần tạo một subclass thừa kế MazeGame, trong ₫ó override các phương thức khởi tạo ₫ối tượng ở trên. ‰ CreateMaze ₫ược truyền 1 ₫ối tượng mà có thể tạo mêlộ mới dùng các tác vụ thêm phòng, cửa và tường vào mêlộ mà nó xây dựng rồi ta dùng thừa kế ₫ể thay ₫ổi các phần của mêlộ hay cách thức xây dựng mêlộ.

    Giải pháp khắc phục

    ‰ Truyền cho phương thức CreateMaze một ₫ối tượng có khả năng sinh ra room, wall, door theo ₫ặc thù của ứng dụng. ‰ Code trong CreateMaze gọi các phương thức thông thường (hoặc virtual) ₫ể khởi tạo ₫ối tượng thay vì gọi constructor của lớp tương ứng.

    Abstract Factory

    ‰ CreateMaze ₫ược truyền các ₫ối tượng room, door, wall có khả năng sinh ra ₫ối tượng tương tự chúng (clone). ƒ Để khởi tạo một ₫ối tượng cụ thể, cần xây dựng 2 lớp concrete: một lớp hiện thực interface AbstractFactory ₫ể khởi tạo ₫ối tượng từ lớp hiện thực.

    Thí dụ về mẫu AbstractFactory

    ƒ Cung cấp interface cho các ₫ối tượng dự ₫ịnh sẽ ₫ược khởi tạo khi hệ thống chạy, gọi là AbstractProduct.

    Sơ ₫ồ cấu trúc của mẫu AbstractFactory

    ƒ Client dựa vào interface của các ₫ối tượng ConcreteProduct ₫ược khai báo trong AbstractProduct ₫ể sử dụng các ₫ối tượng này. ‰ hệ thống muốn tương tác với một họ trong một tập hợp họ ₫ối tượng và việc chọn họ ₫ối tượng ₫ược xác ₫ịnh tại thời ₫iểm run-time.

    Các ngữ cảnh nên dùng mẫu Abstract Factory

    ƒ chương trình nhất quán trong việc sử dụng một họ các phần tử của cùng một kiểu maze, không xảy ra trường hợp 2 phần tử của 2 họ khác nhau cùng tồn tại trong code của client. ƒ việc bổ sung một loại phần tử vào maze sẽ gặp khó khăn vì phải bổ sung vào lớp MazeFactory, do ₫ó sẽ ảnh hưởng ₫ến hầu như tất cả các lớp khác.

    Sơ ₫ồ cấu trúc của mẫu Factory method

    ‰ một lớp muốn lớp con của mình thay ₫ổi hay xác ₫ịnh lớp của ₫ối tượng cần khởi tạo. ‰ một lớp muốn chuyển quá trình hiện thực một nhiệm vụ nào ₫ó cho một trong các lớp con nhưng cho phép ứng dụng xác ₫ịnh lớp con cụ thể.

    Các ngữ cảnh nên dùng mẫu Factory Method

    ƒ Định nghĩa các lớp thừa kế từ các lớp thể hiện các phần tử tương ứng VD: RoomWithABomb thừa kế Room. ƒ Định nghĩa lớp thừa kế lớp MazeGame, trong lớp này override factory method tạo ra ₫ối tượng muốn thay ₫ổi.

    Sơ ₫ồ cấu trúc của mẫu Prototype

    ‰ Class có thể cung cấp phương thức ₫ể set giá trị cho ₫ối tượng sau khi ₫ược tạo ra bằng cách copy từ prototype. ‰ Nếu số lượng prototype trong ứng dụng không cố ₫ịnh, nên quản lý chúng bằng một ₫ối tượng prototype manager.

    Một số vấn ₫ề hiện thực

    Đối tượng này chứa các tham khảo ₫ến các prototype và các key tương ứng ₫ể truy xuất chúng.

    Các ngữ cảnh nên dùng mẫu Prototype

    ‰ Định nghĩa lớp MazePrototypeFactory thừa kế lớp MazeFactory, ₫ối tượng lớp này ₫ược cung cấp các prototype ₫ể tạo ra các ₫ối tượng cùng loại. ‰ Khi bổ sung phần tử sản phẩm mới (VD: roomWithABomb), không cần phải cung cấp lớp Factory (BombedMazeFactory) ₫ể sinh ra các sản phẩm này mà chỉ cần cung cấp prototype của sản phẩm ₫ó.

    Sơ ₫ồ cấu trúc của mẫu Builder

    ƒ xây dựng và lắp ghép các phần của Product bằng cách hiện thực interface của class Builder. ƒ bao gồm các class ₫ịnh nghĩa các thành phần bao gồm interface phục vụ việc lắp ghép các thành phần thành kết quả cuối cùng.

    Các ngữ cảnh nên dùng mẫu Builder

    ‰ Ta hiệu chỉnh hàm CreateMaze() của class MazeGame thành : Maze* Mazegame::CreateMaze (MazeBuilder& builder) {. ‰ Ta có thể ₫ịnh nghĩa các subclass của class MazeBuilder ₫ể tạo ra các Maze khác nhau và tạo ₫ối tượng của subclass này rồi truyền nó như là tham số của hàm CreateMaze() ₫ể tạo các Maze khác nhau.

    Sơ ₫ồ cấu trúc của mẫu Singleton

    ‰ Cộng tác giữa các ₫ối tượng : các clients truy xuất instance của class Singleton thông qua việc gọi tác vụ Instance() của class.

    CÁC MẪU BEHAVIORAL

    ‰ Các slide sau sẽ giới thiệu các pattern Chain of Responsibility, Template Method (class pattern), Strategy (object pattern) và Command (object Pattern),.

    Lược ₫ồ cấu trúc của mẫu Chain of Responsibility

    ƒ hơn 1 ₫ối tượng có thể xử lý request nhưng ₫ối tượng nào sẽ xử lý thì chưa biết trước. ƒ bạn muốn gởi request ₫ến 1 ₫ối tượng xử lý nào ₫ó nhưng không xác ₫ịnh rừ ràng.

    Sơ ₫ồ cấu trúc mẫu Template Method

    ‰ ConcreteClass (MyApplication) : hiện thực các primitive operation ₫ể can thiệp một phần vào quá trình thực hiện hoạt ₫ộng ở lớp cha. ƒ kiểm soát quá trình override của lớp con: chỉ cho phép override những ₫iểm hook qui ₫ịnh sẵn.

    Các ngữ cảnh nên dùng mẫu Template Method

    ƒ ₫ịnh nghĩa các primitive operation cho lớp con override ₫ể hiện thực một phần của hoạt ₫ộng. ƒ hiện thực một phần cố ₫ịnh của hoạt ₫ộng và cho phép lớp con hiện thực phần có thể thay ₫ổi.

    Lược ₫ồ cấu trúc của mẫu Strategy

    Có thể nhận pointer ₫ến ₫ối tượng Context trong quá trình khởi tạo ₫ối tượng ₫ể truy xuất dữ liệu trong Context. ƒ Một lớp có nhiều hành vi loại loại trừ lẫn nhau và quá trình chuyển từ hành vi này sang hành vi khác cần ₫ược thực hiện dễ dàng.

    Các ngữ cảnh nên dùng mẫu Strategy

    ƒ tại thời ₫iểm dịch: chỉ sử dụng ₫ối tượng kiểu Strategy khi xác ₫ịnh giải thuật cho vấn ₫ề cần xử lý. ƒ tại thời ₫iểm run-time: ₫ược cung cấp một ₫ối tượng giải thuật cụ thể thay thế cho ₫ối tượng Strategy.

    Mẫu Command

    Phần tử nhận của PasteCommand là ₫ối tượng Document mà PasteCommand ₫ược cung cấp trong lúc "instantiation". ‰ Tác vụ Execute của OpenCommand thì khác : nó hiển thị cửa sổ yêu cầu user nhập tên document rồi tạo ₫ối tượng Document tương ứng,.

    Lược ₫ồ cấu trúc của mẫu State

    ƒ hành vi của ₫ối tượng phụ thuộc vào trạng thái của nó và phải thay ₫ổi run- time khi trạng thái thay ₫ổi. ƒ các tác vụ có những lệnh ₫iều kiện số học lớn phụ thuộc vào trạng thái ₫ối tượng.

    Lược ₫ồ cấu trúc của mẫu Observer

    ƒ khi việc thay ₫ổi ₫ối tượng này ₫òi hỏi phải thay ₫ổi các ₫ối tượng khác nhưng bạn không biết trước có bao nhiêu ₫ối tượng cần thay ₫ổi. ƒ khi ₫ối tượng cần có khả năng cảnh báo các ₫ối tượng khác nhưng không muốn chúng ghép nối chặt với nhau.