OBJE CT - Oriented analysis and design
Trang 1ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN
ĐỒ ÁN: OBJECT-ORIENTED ANALYSIS AND DESIGN
GVHD: Nguyễn Công Hoan
Trang 2LỜI CÁM ƠN!
Để có thể hoàn thành tốt bài tiểu luận này, chúng em xin gửi lời cám ơn chân thành tới thầy Nguyễn Công Hoan đã trực tiếp giảng dạy chúng em môn Phương Pháp mô hình hóa cũng như các thầy cô trong trường Đại Học Công Nghệ Thông Tin – Đại Học Quốc Gia Thành Phố Hồ Chí Minh đã nhiệt giúp đỡ chúng em hoàn thành đồ án này!
Bài viết là đề tài OBJECT-ORIENTED ANALYSIS AND DESIGN.
Dù các thành viên trong nhóm đã cố gắng làm việc miệt mài và nghiêm túc, song
do thời gian hạn hẹp và kiến thức còn hạn chế nên không tránh khỏi sơ xuất, mong bạn đọc góp ý!
T.P Hồ Chí Minh, tháng 12/2013 Nhóm SVTH :
1 Võ Duy Cương 11520036
2 Nguyễn Văn Tiến 11520408
3 Nguyễn Chí Linh 11520210
Page 2
Trang 3Đề tài: OOAD
Nhận xét của giảng viên:
MỤC LỤC:
Trang 4CHƯƠNG I: GIỚI THIỆU
Lập trình hướng đối tượng (gọi tắt là OOP, từ chữ Anh ngữ object-oriented programming), hay còn gọi là lập trình định hướng đối tượng, là kĩ thuật lập trình hỗ trợ công nghệ đối tượng OOP được xem là giúp tăng năng suất, đơngiản hóa độ phức tạp khi bảo trì cũng như mở rộng phần mềm bằng cách chophép lập trình viên tập trung vào các đối tượng phần mềm ở bậc cao hơn Ngoài ra, nhiều người còn cho rằng OOP dễ tiếp thu hơn cho những người mới học về lập trình hơn là các phương pháp trước đó
Page 4
Trang 5Đề tài: OOAD
Một cách giản lược, đây là khái niệm và là một nỗ lực nhằm giảm nhẹ các thao tác viết mã cho người lập trình, cho phép họ tạo ra các ứng dụng mà cácyếu tố bên ngoài có thể tương tác với các chương trình đó giống như là tương tác với các đối tượng vật lý
Những đối tượng trong một ngôn ngữ OOP là các kết hợp giữa mã và dữ liệu mà chúng được nhìn nhận như là một đơn vị duy nhất Mỗi đối tượng cómột tên riêng biệt và tất cả các tham chiếu đến đối tượng đó được tiến hành qua tên của nó Như vậy, mỗi đối tượng có khả năng nhận vào các thông báo, xử lý dữ liệu (bên trong của nó), và gửi ra hay trả lời đến các đối tượng khác hay đến môi trường
CHƯƠNG II: PHÂN TÍCH VÀ THIẾT
KẾ HƯỚNG ĐỐI TƯỢNG
I.
OOAD:
Một cách tiếp cận phát triển phần mềm
Mô hình hệ thống thành nhóm các đối tượng
Tạo điều kiện cho một loạt các quy trình để phân tích và phát triển hệ thống
II.
Áp dụng kỹ thuật mô hình đối tượng để phân tích các yêu cầu, chức năng cho hệ thống
Nhiệm vụ:
o Thiết lập cách nhìn tổng quan về hệ thống
Trang 6o Liệt kê các nhiệm vụ mà hệ thống cần thực hiện.
o Đưa ra hướng giải quyết bài toán
o Phát triển những vấn đề liên quan trong miền quan tâm của bài toán
Ví dụ: Phân tích hệ quản lý thư viện điện tử đơn giản
o Bước 1: Mô hình UseCase
Page 6
Trang 7Đề tài: OOAD
o Bước 2: Mô hình lớp
Trang 8o Bước 3: Biểu đồ trạng thái
Page 8
Trang 9Đề tài: OOAD
III.
OOD dựa trên các mô hình phân tích được tạo bởi OOA
OOA nhấn mạnh hệ thống làm được cái gì (What)?
OOD nhấn mạnh cách để hệ thống làm nó (How)?
Những quy tắc thiết kế Hướng đối tượng:
a Nguyên lí Mở-Đóng (Open-Closed Principle)
b Nguyên lí thay thế Liskov(The Liskov Substitution Principle)
c The Single Responsibility Principle(SRP)
d Nguyên lý nghịch đảo phụ thuộc(Dependency Inversion Principle)
e Nguyên lí chia tách giao diện(Interface Segragation Principle)
Trang 10Ví dụ về vẽ hình tròn và hình vuông:
Page 10
Trang 11Đề tài: OOAD
Trang 12Vậy điều gì xảy ra khi chúng ta muốn vẽ thêm một đối tượng khác, hình tam giác?
Page 12
Trang 13Đề tài: OOAD
DrawAllShape đã bị thay đổi Vi phạm nguyên lý Mở-Đóng.Hướng giải quyết:
Trang 14Page 14
Trang 15Đề tài: OOAD
Trang 162 The Liskov Substitution Principle(LSP):
Lớp D được gọi là kế thừa từ lớp B khi và chỉ khi với mọi hàm F thao tác trên các đối tượng của B, cách cư xử (behavior) của F không đổi khi thay thếcác đối tượng của B bằng các đối tượng của D
Trang 17Đề tài: OOAD
Nếu chúng ta xây dựng thêm lớp Hình vuông Kế thừa từ lớp Regtangle
Trang 18Hoạt động tốt trên lớp cơ sở nhưng không tốt trên lớp dẫn xuất.
Page 18
Trang 19Đề tài: OOAD
Thỏa mãn nguyên lý Liskov
Nhưng nếu ta mở rộng:
Khi truyền vào đối tượng Rectangle, assert thành công nhưng nếu truyền
và đối tượng Square, assert không thành công
Kết luận: Lớp Square không nên kế thừa từ lớp Rectangle do không thoả
mản nguyên lí Liskov
3 The Single Responsibility Principle(SRP):
Mỗi đối tượng chỉ có một mục đích(resoinsibility) duy nhất và mục đích đó được gói trong một lớp
Trang 204 Nguyên lý nghịch đảo phụ thuộc:
Các đơn thể cấp cao không nên phụ thuộc vào các đơn thể cấp thấp
Cả hai nên phụ thuộc vào những cái trừu tượng
Cái trừu tượng không nên phụ thuộc vào cái chi tiết Cái chi tiết nên phụ thuộc vào cái trừu tượng
Ví dụ: Đọc kí tự được nhập từ bàn phím sau đó xuất ra
Hàm Copy ở cấp cao, hai hàm ReadKeyboard và WritePrinter ở cấp thấp
Khi yêu cầu thay đổi, Đọc kí tự từ bàn phím và xuất ra máy in hoặc đĩa cứng???
Page 20
Trang 21Đề tài: OOAD
Hàm cấp cao Copy đã bị phụ thuộc vào các hàm cấp thấp
ReadKeyboard, WritePrinter, WriteDisk Vi phạm nguyên lý Đảo phụ thuộc.Sửa lại theo nguyên lý: Cả hai nên phụ thuộc vào những cái trừu tượng
Trang 22Page 22
Trang 23Đề tài: OOAD
5 Nguyên lý phân tách giao diện:
Không nên để các thực thể(phần mềm) khách phụ thuộc vào các giao diện mà chúng không hề sử dụng
Đóng vai trò định hướng trong việc thiết kế các lớp trừu tượng
Xét ví dụ vi phạm:
Trang 24Page 24
Trang 25Đề tài: OOAD
V.
CÂU HỎI:
1 Hãy cho biết các quy tắc khi thiết kế hướng đối tượng?
2 Thiết kế hướng đối tượng gồm mấy bước? Trình bày nội dung chính của các bước đó?
3 Nếu vi phạm nguyên lý phân tách giao diện sẽ gây ra hậu quả gì?
Trả lời:
1 Các nguyên tắc khi thiết kế hướng đối tượng là:
o Nguyên lí Mở-Đóng (Open-Closed Principle)
o Nguyên lí thay thế Liskov(The Liskov SubstitutionPrinciple)
o The Single Responsibility Principle(SRP)
o Nguyên lý nghịch đảo phụ thuộc(Dependency Inversion Principle)
o Nguyên lí chia tách giao diện(Interface Segragation Principle)
2 Các bước phân tích hướng đối tượng:
Gồm 3 bước: tương ứng với 3 dạng mô hình trong UML
o Mô hình use case: Xây dựng mô hình chức năng của sản phẩm phần mềm nhìn từ quan điểm của người sử dụng
o Mô hình lớp: Biểu diễn các lớp, các thuộc tính và mối quan hệ giữa các lớp
o Mô hình động: Biểu diễn các hoạt động liên quan đến 1 lớp hay lớp con
Trang 263 Nếu vi phạm nguyên lý phân tách giao diện sẽ gây ra hậu quả:
o Mọi giao diện dẫn xuất từ giao diện vi phạm sẽ bị béo phì(fat interface), tức là giao diện dẫn xuất sẽ tích lũy những hàm không cần thiết trong cây phâncấp kế thừa
o Nếu chấp nhận không phân tách, ta có hai giải pháp, hoặc là đặt hàm đó trong lớp dẫn xuất là hàmrỗng(không thân hàm) hoặc giải pháp khác là đặt ngay ở giao diện cha là hàm rỗng( không còn là hàm ảo) Hai giải pháp sẽ gây nguy cơ cao vi Hai giải pháp sẽ gây nguy cơ cao vi phạm nguyên lý thay thế Liskov
VI.
Page 26