Lập trình hướng đối tượng - Chương 11 pot

Chương 11


Phát triển các hệ thống hướng đối tượng






•
Giới thiệu

•
Các mô hình hướng-thủ tục

•
Các công cụ phát triển hướng-thủ tục

•
Mô hình hướng đối tượng

•
Các ký hiệu và đồ thò hướng đối tượng

•
Các bước phân tích hướng đối tượng

•
Các bước thiết kế hướng đối tượng

•
Cài đặt

•
Mô hình mẫu

•
Tóm tắt


Chương 11
Phát triển hệ thống hướng đối tượng



338

Chương 11
Phát triển hệ thống hướng đối tượng

339
I/ Giới thiệu

Các kỹ sư phần mềm đã dùng nhiều
công cụ
(tools),
phương pháp
(methods)

và
thủ
tục
(procedures) khác nhau để thực hiện tiến trình phát triển phần mềm nhằm xây
dựng các sản phẩm phần mềm chất lượng cao với hiệu suất ngày càng cải tiến.

Các phương pháp
cung cấp khái niệm “làm như thế nào” để xây dựng phần mềm
trong khi
các công cụ
cung ứng các hổ trợ tự động và bán tự động cho các phương
pháp. Họ sử dụng mọi giai đoạn phát triển của tiến trình phát triển phần mềm, đó là,
lập kế hoạch, phân tích, thiết kế, phát triển và bảo trì.

Các thủ tục
phát triển phần mềm tích hợp các phương pháp và các công cụ lại với
nhau và làm cho sự phát triển các hệ thống phần mềm trở nên hợp lý và hợp thời.
(hình 11.1). Chúng cung cấp các nguyên tắc chỉ đạo như làm thế nào áp dụng các
phương pháp và công cụ, làm thế nào để tiến hành phân phối ở mỗi giai đoạn, các
điều khiển nào sẽ áp dụng, và những cột mốc nào được dùng để đánh giá sự phát

triển.

Software development
Procedures
Methods

Tools






Hình 11.1 Các thành tố phát triển phần mềm

Có một số mô hình phát triển phần mềm, mỗi mô hình bao gồm một tập hợp các
phương pháp và công cụ khác nhau. Việc lựa chọn một mô hình phụ thuộc vào bản
chất của một ứng dụng, ngôn ngữ lập trình được dùng, những điều khiền và phân
phối được yêu cầu.

Chương 11
Phát triển hệ thống hướng đối tượng



340
Sự phát triển một hệ thống hoàn chỉnh không những phụ thuộc vào những phương
pháp và kỹ thuật thích hợp mà còn phụ thuộc các ràng buộc của những nhà phát
triển vào các đối tượng của hệ thống. Một hệ thống hoàn chỉnh phải là :
1. thoả mãn những yêu cầu của người dùng.

2. trở nên dể hiểu đối với người dùng và người vận hành
3. trở nên dể thao tác
4. có giao diện tốt
5. dễ dàng chỉnh lý
6. có thể phát triển được
7. có những điều khiển bảo mật thích hợp chống lại sự lạm dụng dữ liệu
8. bắt lỗi và xử lý ngoại lệ thật hài lòng
9. phân phối sản phẩm theo đúng ngày giờ đã ấn đònh

Trong chương này chúng ta sẽ xem xét một vài cách tiếp cận truyền thống được ứng
dụng rộng rãi trong phát triển phần mềm và thảo luận một vài ý tưởng hiện nay có
thể áp dụng được vào phát triển phần mềm hướng đối tượng.

II/ Các mô hình hướng-thủ tục
Prolem
definition


Analysis



Design



Coding

Testing



Maintenance


Hình 11.2 Chu kỳ sống phát triển phần mềm cổ điển
(mô hình “thác nước” nhúng được)
Chương 11
Phát triển hệ thống hướng đối tượng



341
Phát triển phần mềm thường được mô tả bởi một bộ các trạng thái mô tả các tác vụ
khác nhau bao gồm trong tiến trình phát triển. Hình 11.2 minh hoạ chu kỳ sống phần
mềm cổ điển được ứng dụng rộng rãi trong phát triển hướng-thủ tục (procedure-
oriented).

Chu kỳ sống cổ điển dựa trên một mô hình cơ bản, thông thường là mô hình “thác
nước”. Mô hình này cố gắng làm rõ những hoạt động có thể nhận biết được trong
một chuỗi các hành động, mỗi một trong số chúng phải hoàn tất trước khi hành động
khác lại bắt đầu. Các hoạt động bao gồm, xác đònh vấn đề, phân tích các yêu cầu,
thiết kế, lập trình, kiểm nghiệm, và bảo trì. Sự tinh chế hơn nữa cho mô hình này
bao gồm các bước lặp quay lui những giai đoạn trước đó nhằm kết hợp chặt chẽ bất
kỳ sự biến đổi nào hoặc các liên kết còn thiếu.

Xác đònh vấn đề
: Hành động này yêu cầu một đònh nghóa chính xác về vấn đề trong

những thuật ngữ đang dùng. Một phát biểu rõ ràng của vấn đề là một quyết đònh cho
sự thành công của sản phẩm. Nó không chỉ giúp cho nhà phát triển mà còn giúp
người sử dụng hiểu vần đề được tốt hơn.

Phân tích các yêu cầu
: Điều này bao trùm sự nghiên cứu chi tiết về những yêu cầu
của cả người dùng lẫn sản phẩm. Hành động này là một bước cơ bản có liên quan
đến “cái gì” (
What
) của hệ thống như là :
•
Những đầu vào cho hệ thống là cái gì ?
•
Các tiến trình yêu cầu cái gì ?
•
Những đầu ra mong muốn sẽ là cái gì ?
•
Những ràng buộc (
constraints
) là gì ?

Thiết kế
: pha thiết kế giải quyết những quan niệm khác nhau của thiết kế hệ thống
như cấu trúc dữ liệu, kiến trúc sản phẩm, và các thuật toán. Pha này chuyển những
yêu cầu vào cách biểu diễn (
representation
) của sản phẩm. Giai đoạn này trả lời câu
hỏi “
How
”.

Lập trình
: Mã hoá có liên quan đến sự chuyển dòch bản thiết kế sang dạng mã-máy-
có-thể-đọc-được. Chi tiết hoá bản thiết kế, dễ dàng hơn đó là sự mã hoá và làm cho
tính tin cậy của thiết kế được tốt hơn.

Kiểm nghiệm
: một bản mã lệnh được viết xong , cần phải kiểm nghiệm nghiêm ngặt
giúp cho bản mã và kết quả được tốt nhất. Sự kiểm nghiệm có thể là một vài modul
Chương 11
Phát triển hệ thống hướng đối tượng



342
riêng lẽ hoặc có khi là toàn bộ hệ thống. Nó yêu cầu một kế hoạch chi tiết như kiểm
tra cái gì, khi nào và làm như thế nào (
what, when, how to
test)

Bảo trì
: sau khi sản phẩm đã được hoàn chỉnh, nó có thể phải chòu một vài thay đổi.
Điều này thường xảy ra theo yêu cầu của người dùng và của cả môi trường điều
hành, hoặc một lỗi nào đó trong sản phẩm bò sót trong quá trình kiểm nghiệm. Sự
bảo trì bảo đảm rằng mọi thay đổi sẽ được kết hợp chặt chẽ bất cứ lúc nào thấy cần
thiết.
Mỗi pha của chu kỳ sống đều có mục đích và đầu ra. Đầu ra của pha này sẽ là đầu
vào của pha tiếp theo. Bảng 11.1 sẽ chiû ra các kiểu của đầu ra

Pha Đầu ra (
outputs
)
Xác đònh vấn đề * Phiếu phát biểu của vấn đề
(why) * Tài liệu đề nghò của dự án
Phân tích * Tài liệu yêu cầu
(what) * Báo cáo khả thi
* Tài liệu đặc tả
* Tiêu chuẩn kiểm nghiệm được công nhận
Thiết kế * Tài liệu thiết kế
(how) * Thiết kế các tình huống cho kiểm nghiệm
Mã hoá * Tài liệu mã hoá (chương trình)
(how) * Kế hoạch kiểm nghiệm
* Tài liệu cho người dùng
Kiểm nghiệm * Các mã hoá đã được kiểm nghiệm
(what & how) * Các kết quả kiểm nghiệm
* Tài liệu cho hệ thống
Bảo trì * Các phiếu nhật ký bảo trì
* Tài liệu các phiên bản

Bảng 11.1 Các đầu ra của chu kỳ sống phần mềm cổ điển

Chu kỳ sống phần mềm, được mô tả ở trên, thường được xem như kỹ thuật phân rã
chức năng (
the functional decomposition
), được biết rộïng rãi như cách tiếp cận từ
trên xuống (
top-down)
, hoặc theo modun (
modular)

. Kỹ thuật phân rã chức năng dựa
trên sự thể hiện không gian vấn đề và nó chuyển sang không gian lời giải như là sự
thông dòch một tập các hàm. Các hàm được phân rã theo trình tự tăng dần, những
Chương 11
Phát triển hệ thống hướng đối tượng



343
hàm đơn giản nhất sẽ được thực thi cuối cùng. Hệ thống cuối cùng được xem như
một tập các hàm được tổ chức theo cấu trúc phân cấp
top-down .


Cũng có một vài thiếu sót trong cách tiếp cận
top-down
, tiếp cận phân rã chức năng.
Chúng bao gồm :
1. Không cho phép những thay đổi tiến hoá trong phần mềm.
2. Hệ thống được đặc trưng bởi một hàm đơn (
a single function
) ở đỉnh của cây
phân cấp nhưng không phải lúc nào cũng hoàn toàn đúng. Trong nhiều
trường hợp thực tế các hệ thống không có hàm

đơn ở đỉnh.
3. Dữ liệu không được xem là đáng quan trọng.
4. Nó không khuyến khích việc tái sử dụng mã lệnh đã có.

III/ Các công cụ phát triển hướng-thủ tục

Các công cụ phát triển hiện nay có thể phân loại theo 3 thế hệ.
Các công cụ thế hệ 1 được phát triển vào thập niên 60 và 70 được gọi là các công cụ
truyền thống.

Các công cụ thế hệ 2 được giới thiệu vào cuối thập niên 70 và đầu thập niên 80 dành
cho phân tích và thiết kế các
hệ thống có cấu trúc
và do đó chúng được biết như là
các
công cụ có cấu trúc.


Các công cụ thế hệ 3 được giới thiệu vào cuối thập niên 80 cho đến nay dành cho
phân tích và thiết kế các
hệ thống hướng đối tượng.


Bảng 11.2 chỉ cho thấy một số công cụ thông dụng dành cho các tiến trình phát triển
theo 3 chủng loại. Phần này sẽ giới thiệu tổng quát một vài công cụ thường dùng ở
thế hệ 1 và 2.

Process First
generation
Second generation Third generation
Physical
processes
System

flowcharts
Context diagrams Inheritance graphs
Object-relationship
charts

Data Layout forms Data dictionary Objects
Chương 11
Phát triển hệ thống hướng đối tượng



344
representation Grid charts Object dictionary

Logic
processes
Playscript
English
narrative
Decision tables
trees
Data flow
diagrams
Inheritance graphs
Data flow diagrams

Program
representation
Program
flowcharts

I/O layouts
Structure charts
Warrier/Orr
diagrams
State change diagrams
Ptech diagrams
Coad/Yourdon charts

Bảng 11.2 Các công cụ phát triển hệ thống


!"
Lưu đồ hệ thống (System flowcharts)
!"
Lưu đồ chương trình (Program flowcharts)
!"
Kòch bản từng giai đoạn (Playscripts)
!"
Các khuôn dạng sơ bộ (Layout forms) cho việc nhập và xuất kết quả .
!"
Biểu đồ (Grid charts) biểu diễn mối quan hệ giữa các modun của hệ thống.
!"
Lược đồ ngữ cảnh (Context diagrams) biểu diễn đầu vào với tài nguyên của
chúng và đầu ra với các đích của chúng.
!"
Lược đồ dòng dữ liệu (Data flow diagrams) biểu diễn dòng dữ liệu giữa các thành
phần khác nhau của hệ thống
!"
Từ điển dữ liệu (Data dictionary)
!"

Biểu đồ cấu trúc (Structures chart) biểu diễn đồ thò các điều khiển logic giữa các
modun của hệ thống.
!"
Bảng quyết đònh (Decision table) một bảng các tình huống bất ngờ dành cho việc
xác đònh vấn đề và các hành động để thực hiện.
!"
Cây quyết đònh (Decision tree)
!"
Lược đồ Warnier/Orr : một biểu đồ phân cấp hàng ngang sử dụng một tập các dấu
móc, mã giả (pseudo-code) và các ký hiệu logic để chỉ các cấu trúc chương trình.





Chương 11
Phát triển hệ thống hướng đối tượng



345
IV/ Mô hình hướng-đối tượng

Mô hình hướng-đối tượng đặt nặng trên lý thuyết hệ thống tổng quát như là nền tảng
thuộc về khái niệm.
Một hệ thống có thể được xem như một sự tập hợp các thực thể
(entities), chúng tương tác với nhau nhằm đạt đến mục tiêu nào đó
(hình 11.3).

Các thực thể có thể biểu diễn các đối tượng vật lý như các thiết bò hay con người, và

các khái niệm trừu tượng như các file dữ liệu hoặc các hàm. Trong phân tích hướng-
đối tượng các thực thể được gọi là các đối tượng (
objects
).

PROCESS



INPUT OUTPUT





Hình 11.3 Một hệ thống với các quan hệ-bên trong của các thực thể

Theo như tên gọi, mô hình hướng-đối tượng đặt để tầm quan trọng nhất vào các đối
tượng đó là tính đóng gói dữ liệu và hàm. Chúng đóng vai trò trung tâm trong mọi
giai đoạn của phát triển phần mềm và do đó sẽ tồn tại ở mức cao sự gối lên nhau
(
overlap
) và sự lặp đi lặp lại (
iteration
) giữa các giai đoạn. Tiến trình phát triển toàn
thể trở thành sự tiến hoá như trong tự nhiên. Bất kỳ một biểu diễn đồ hoạ nào của
các phiên bản hướng-đối tượng của chu kỳ phát triển phần mềm đều phải lưu tâm
đến hai khía cạnh gối lên nhau và và sự lặp đi lặp lại. Kết quả là mô hình “vòi phun
nước” (
fountain model

) đã thay thế mô hình “thác nước cổ điển” (hình 11.4).








Entity Entity

Entity


Entit
y
Entit
y

Chương 11
Phát triển hệ thống hướng đối tượng



346
Maintenance Further development


Application

Object-oriented OOP Objects
programming in program

Object-oriented OOD Objects
design in solution space

Object-oriented OOA Objects
analysis in problem space


Hình 11.4 Mô hình “vòi phun nước” trong phát triển
phần mềm hướng-đối tượng

Phân tích hướng-đối tượng
(OOA) có liên quan đến các phương pháp của các yêu
cầu đặc tả của phần mềm theo thuật ngữ các đối tượng của thế giới thực, các hành vi
ứng xử và các tương tác của chúng.

Thiết kế hướng-đối tượng
(OOD) chuyển những yêu cầu của phần mềm sang những
đặc tả cho đối tượng và các lớp dẫn xuất phân cấp từ đó các đối tượng sẽ được tạo ra.

Lập trình hướng-đối tượng
(OOP) có liên quan đến cài đặt chương trình trong một
ngôn ngữ lập trình hướng đối tượng như C++.

Tương phản với cách tiếp cận phân rã chức năng top-down, tiếp cận hướng đối tượng

sử dụng các thiết kế top-down lẫn bottom-up. Kỹ thuật phân rã chức năng từ trên
xuống có thể áp dụng để thiết kế các lớp riêng lẽ trong khi hệ thống cuối có thể
được xây dựng với sự trợ giúp các modun lớp sử dụng tiếp cận từ dưới lên.

Problem space Objects defined
Chương 11
Phát triển hệ thống hướng đối tượng



347
in problem space during analysis

!

!


!

!







!

!

!

!
Solution specific
objects defined

!

!

!
during design
Solution space

Hình 11.5 Các tầng của các đặc tả đối tượng


V/ Các ký hiệu và đồ thò hướng đối tượng

Các ký hiệu đồ hoạ (
graphical notations
) là phần không thể thiếu của bất kỳ quá
trình thiết kế và phát triển nào, thiết kế hướng đối tượng cũng vậy. Chúng ta cần các
ký hiệu để biểu diễn các lớp, các đối tượng, các lớp con, và mối quan hệ qua lại của
chúng. Thật không may, không có các ký hiệu chuẩn để biểu diễn các đối tượng và
các tương tác ủua chúng. Mỗi tác giả và các nhà nghiên cứu đều có cách ký hiệu
riêng của mình. Dưới đây là một số ký hiệu thông dụng , từ hình 11.6 đến 11.14

1. lớp và đối tượng
2. các thể hiện của đối tượng
3. message truyền thông giữa các đối tượng
4. quan hệ kế thừa
5. quan hệ phân loại
6. quan hệ hợp thành
7. biểu đồ phân cấp thứ bậc
8. quan hệ client-server
9. các tiến trình
Classname
Classname Classname
Function 1
Chương 11
Phát triển hệ thống hướng đối tượng



348
Functions Data Data



Functions






(a) (b) (c)

Hình 11.6 Các dạng khác nhau dùng biểu diễn lớp/đối tượng


Person Class






is-a is-a is-a


John Hung Ahmed

objects

Hình 11.7 Các thể hiện của các đối tượng


Object A Object B




Hình 11.8 message truyền thông giữa các đối tượng

A
Base class

Function 2
Function 3
data
Chương 11
Phát triển hệ thống hướng đối tượng



349





B


Derived class

Hình 11.9 quan hệ kế thừa

Vehicle




a-kind-of


Car Cycle

(a)


Vehicle









Car Cycle


(b)
Hình 11.10 quan hệ phân loại
House


Chương 11
Phát triển hệ thống hướng đối tượng



350

a-part-of


Door Window


(a)

House







Door Window


(b)
Hình 11.11 quan hệ hợp thành


A



B C D

B1 B2

Hình 11.12 biểu đồ phân cấp thứ bậc




X Y


Chương 11
Phát triển hệ thống hướng đối tượng



351

Server Client

Hình 11.13 quan hệ client-server


Process
A
Process
B

Process
C
Process
D

Hình 11.14 các tiến trình
(một tiến trình có thể có từ 5 đến 7 đối tượng tiêu biểu)


VI/ Các bước trong phân tích hướng đối tượng

Phân tích hướng đối tượng (OOA) cung cấp cho chúng ta một cơ chế đơn giản nhưhg
đầy sức mạnh để nhận biết các đối tượng, các khối xây dựng (
the buiding blocks
) của
phần mềm đã được phát triển.

Việc phân tích có liên quan về cơ bản đến sự phân rã của vấn đề thành các bộ phận
cấu thành (
component parts
) của nó và thiết lập một mô hình logic nhằm mô tả các
chức năng của hệ thống.

Tiếp cận phân tích hướng đối tượng gồm có các bước sau đây :
1. Hiểu và nắm vững vấn đề
2. Phác thảo những đặc tả yêu cầu của người dùng và của phần mềm
3. Nhận biết các đối tượng và các thuộc tính của chúng
4. Nhận biết các dòch vụ trong đó mỗi đối tượng được mong đợi cung cấp (giao

diện)
5. Thiết lập các quan hệ nối liền với nhau (cộng tác -
collaborations
) giữa các đối
tượng dưới dạng các dòch vụ được yêu cầu và các dòch vụ đáp lại (services
rendered) .
Chương 11
Phát triển hệ thống hướng đối tượng



352

Mặc dù, chúng ta đã chỉ ra các tác vụ như một tập các bước riêng lẻ, ba bước cuối
được thực hiện phụ thuộc lẫn nhau như hình 11.15

Problem
definition




Requirement
specifications


Objects in
problem space Identify
Objects

Identify
services
Identify
collaborations



Design

Hình 11.15 Các hoạt động của phân tích hướng đối tượng

1/ Hiểu và nắm vững vấn đề
(
problem understanding
)
Phát biểu vấn đề phải rõ ràng và xác đònh lại dưới dạng công nghệ hệ thống máy
tính sao cho gợi ý ra những lời giải dựa trên máy tính. Phát biểu vấn đề cung cấp cơ
sở cho việc phác thảo đặc tả các yêu cầu của cả người dùng lẫn phần mềm.

2/ Đặc tả các yêu cầu
(
requirements specification
)
Một khi vấn đề được xác đònh rõ ràng, bước tiếp theo sẽ biết được điều gì hệ thống
được yêu cầu thực hiện. Điều quan trọng ở giai đoạn này là tạo cho được một danh
sách các yêu cầu của người dùng. Một sự hiểu biết thông suốt phải có giữa người

dùng và nhà phát triển (
developer
) với cái gì được yêu cầu. Dựa trên những yêu cầu
của người dùng, các đặc tả cho phần mềm sẽ được phác thảo. Nhà phát triển phải
diễn đạt hết sức rõ ràng (what) :
•
Các đầu ra (
outputs
) được yêu cầu là gì
•
Các tiến trình nào được gọi để cho ra các đầu ra đó
Chương 11
Phát triển hệ thống hướng đối tượng



353
•
Những đầu vào (inputs) cần thiết đó là gì
•
Những tài nguyên nào được yêu cầu

Những đặc tả này thường dùng như một tham khảo để kiểm nghiệm sản phẩm cuối
nhằm thực thi các tác vụ mong đợi.

3/ Nhận biết các đối tượng
(
Identication of objects
)
Các đối tượng thường được nhận biết dùi dạng các đối tượng thế giới thực hơn là

các đối tượng trừu tượng. Do đó, nơi tốt nhất để xem xét các đối tượng là ngay chính
ứng dụng. Ứng dụng có thể được phân tích bằng cách sử dụng một trong hai tiếp cận
sau đây :
•
Các lược đồ dòng dữ liệu (DFD –
Data flow diagram
s)
•
Phân tích theo nguyên bản (TA –
Textual analysis
)

a/ Lược đồ dòng dữ liệu
Một ứng dụng có thể biểu diễn dưới dạng DFD chỉ cho thấy dữ liệu sẽ được lưu
chuyển từ nơi này đến nơi khác trong hệ thống. Các ký hiệu hộp (boxe) và khung
lưu trữ dữ liệu (data store) trong DFD là những ứng viên tốt cho biểu diễn các đối
tượng.

Tiến trình nổi bọt “
bubbles
” sẽ tương ứng với các thủ tục. Hình 11.16 minh hoạ một
lược đồ dòng dữ liệu điển hình. Nó cũng được biết đến như một đồ thò dòng dữ liệu
(
data flow graph
) hoặc một biểu đồ nổi bọt (
bubble chart
)

Bookseller : ngøi bán sách
Order : đơn đặt hàng

Process order : xử lý đơn đặt hàng
Shipping instructions : chỉ thò/lời chỉ dẫn về vận chuyển hàng bằøng đøng thủy
Stores/ Warehouse : cửa hàng/ kho hàng
Check credit status : kiểm tra tình trạng của thẻ tín dụng
Shipment information : thông tin về việc gởi hàng lên tàu thủy
Shipping notice : lời báo trước/thời hạn về vận chuyển hàng bằøng đøng thủy




Data store
Books database
Chương 11
Phát triển hệ thống hướng đối tượng



354


boxe





Shipping

Bookseller Order Process
order

instructions Stores


Check credit status



Data store
Customer
database

Shipping
notice



Shipment information
Collect
customer
order


Hình 11.16 DFD cho xử lý đơn đặt hàng và vận chuyển hàng cho cty sách


Một DFD có thể được sử dụng để biểu diễn một hệ thống ở bất kỳ mức trừu tượng
nào. Lấy ví dụ, DFD được chỉ ra ở hình 11.16 có thể mở rộng để bao gồm nhiều
thông tin hơn nữa (như các chi tiết trả tiền) hoặc cô đọng lại như minh hoạ trong hình
11.17 để trình bày chỉ cho một nổi bọt.

Order Instructions


Hình 11.17 Lược đồ dòng dữ liệu cơ sở

b/ Phân tích theo nguyên bản
Tiếp cận này dựa trên sự mô tả nguyên bản của vấn đề hoặc lời giải được đề xuất.
Mô tả này có thể là một trong hai câu hoặc một trong hai đoạn tùy thuộc vào kiểu và
sự phức tạp của vấn đề. Các danh từ là những bộ chỉ thò (
indicator
) tốt của các đối
tượng. Các tên có thể được phân loại hơn nữa như các danh từ chính xác (
proper
nouns
), các danh từ chung (
common nouns
), và các danh từ số nhiều (
mass nouns
)
hoặc các danh từ trừu tượng (
abstract nouns
). Bảng 11.3 chỉ cho thấy các kiểu khác
nhau của các danh từ và ý nghóa của chúng
Customer
Process order
Warehouse
Chương 11
Phát triển hệ thống hướng đối tượng

355

Type of noun Meaning Examples
Commun
noun
Describe classes of things
(entities)
Vehicle, customer, income
(lợi tức), deduction
Proper noun Names of specific things Maruti car, John,
ABC Company
Mass or
abstract
noun
Describe a quality,
quantity or an activity
associated with a noun
Salary-income,
House-loan, feet,
traffic

Bảng 11.3 Các kiểu của các danh từ

Điều quan trọng cần chú ý là ngữ cảnh và ngữ nghóa phải được sử dụng để xác đònh
các loại danh từ. Một từ đặc thù có ý nghóa là một danh từ chung trong ngữ cảnh này
và một danh từ số nhiều hoặc một danh từ trừu tượng trong ngữ cảnh khác.

Các tiếp cận này chỉ là một sự hướng dẫn và không phải là các công cụ cuối cùng.
Sự nhận thức sáng tạo và khả năng trực giác của các nhà phát triển có kinh nghiệm

đóng một vai trò quan trọng trong việc nhận biết các đối tượng.

Để sử dụng một trong những cách tiếp cận trên, cần chuẩn bò một danh sách các đối
tượng cho vấn đề ứng dụng. Điều này phải bao gồm những tác vụ sau :

1. Chuẩn bò một bảng đối tượng
2. Nhận biết những đối tượng có liên quan đến
không gian lời giải
và những đối
tượng chỉ liên quan đến
không gian vấn đề (the problem space)
. Các đối tượng
của không gian vấn đề sẽ ở bên ngoài phạm vi của phần mềm.
3. Nhận biết những thuộc tính của các đối tượng không gian lời giải (
the
solution space objects
).


4/ Nhận biết các dòch vụ
Một khi các đối tượng trong không gian lời giải đã được nhận biết, bước tiếp theo là
nhận biết một tập hợp các dòch vụ trong đó mỗi đối tượng tương ứng phải được đề
nghò.
Chương 11
Phát triển hệ thống hướng đối tượng



356
Các dòch vụ được nhận biết bằng cách thẩm tra mọi động từ và các thành ngữ động

từ trong phát biểu mô tả vấn đề. Các động từ đó có thể diễn đạt các hành động hoặc
những biến cố có thể được phân loại theo bảng 11.4 sau

Type of verb Meaning Examples
Doing verbs Operations read, get, display, buy
Being verbs Classifications is an, belongs to
Having verbs composition has an, is part of
Compare
vebs
Operations is less than,
is equal to
Stative vebs Invariance-condition to be present, are owned

Bảng 11.4 Phân loại các động từ


5/ Thiết lập các quan hệ cộng tác
Bước này nhận biết các dòch vụ mà các đối tượng cung cấp và thu nhận (
receive
) .
Có thể dùng lược đồ dòng thông tin IFD (
information flow diagram
) hoặc lược đồ
quan hệ-thực thể ERD (
entity-relationship diagram
) để thu được thông tin này. Ở
đây chúng ta phải thiết lập mối tương quan giữa các dòch vụ và thông tin hiện tại
(các messages) bằng cách truyền thông.

VII/ Các bước thiết kế hướng đối tượng

Thiết kế có liên quan đến việc ánh xạ của các đối tượng trong không gian vấn đề
sang các đối tượng trong không gian lời giải và tạo ra một cấu trúc tổng thể (mô hình
kiến trúc) và các mô hình tính toán của hệ thống.

Giai đoạn này thường dùng cách tiếp cận bottum-up để xây dựng cấu trúc của hệ
thống và tiếp cận phân rã chức năng top-down để thiết kế các hàm thành viên của
lớp mà chúng cung cấp các dòch vụ. Đó là điều hết sức quan trọng để xây dựng cấu
trúc phân cấp, để nhận biết các lớp trừa tượng, và để đơn giản hoá những truyền
thông (liên lạc) bên trong đối tượng (
the inter-object communications
)

Chương 11
Phát triển hệ thống hướng đối tượng



357
Việc sử dụng lại các lớp từ các thiết kế trước đó, phân loại các đối tượng vào các hệ
thống con và xác đònh các giao thức thích hợp sẽ là một số các quan tâm của giai
đoạn thiết kế.

Tiếp cận thiết kế hướng đối tượng có thể bao gồm các bước sau :
1. Xem xét các đối tượng đã tạo ra trong pha phân tích
2. Đặc tả các phụ thuộc lớp (
class dependencies
)
3. Tổ chức sự phân cấp lớp

4. Thiết kế các lớp
5. Thiết kế các hàm thành viên
6. thiết kế chương trình qua một ngôn ngữ lập trình cụ thể


1/ Xem xét các đối tượng trong không gian vấn đề
Một vài hướng dẫn giúp tiến trình xem xét đó là :
1. Nêùu chỉ một đối tượng là cần thiết cho một dòch vụ (hoặc một hoạt động), thì
nó thao tác chỉ trên đối tượng đó.
2. Nếu có hai hoặc nhiều đối tượng được yêu cầu cho một hoạt động đang diễn
ra, thì nó cần nhận biết phần việc riêng của đối tượng nào phải được nhận ra
để hành động.
3. Nếu một hoạt động yêu cầu sự hiểu biết nhiều hơn một kiểu nào đó của các
đối tượng, thì hoạt động không dính líu về mặt chức năng và cần phải loại bỏ.

p dụng các hướng dẫn này sẽ giúp chúng ta tinh lọc các dòch vụ của các đối tượng.
Hơn nữa, các đối tượng dư thừa và không liên quan sẽ được bỏ đi, các dòch vụ có
cũng nghóa được kết hợp lại và các tên của các thao tác (các hàm) được cải tiến
nhằm biểu hiện trong sáng các dạng xử lý được yêu cầu.

2/
Các phụ thuộc lớp
Phân tích các quan hệ giữa các lớp là trung tâm của cấu trúc một hệ thống. Do đó,
nó quan trọng để nhận biết các lớp thích hợp để biểu diễn các đối tượng trong không
gian lời giải và thiết lập mối quan hệ của chúng. Những quan hệ chủ yếu đóng vai
trò quan trọng trong ngữ cảnh của thiết kế đó là :
1. quan hệ kế thừa
2. quan hệ bao hàm
3. quan hệ sử dụng
Chương 11

Phát triển hệ thống hướng đối tượng



358
a/
Quan hệ kế thừa
là mối quan hệ cao nhất có thể được biểu diễn trong C++. Đó là
cách biểu diễn đầy năng lực về mối quan hệ phân cấp thứ bậc trực tiếp. Nếu xem
hình 11.12 minh họa lớp cơ sở A và các lớp kế thừa của nó thì bảng quan hệ kế thừa
sẽ được chỉ ra ở bảng 11.5 như sau :

Class Depends on
A -
B A
C A
D A
B1 B
B2 B

Bảng 11.5 Bảng quan hệ kế thừa

b/
Quan hệ bao hàm
có nghóa là dùng một đối tượng của lớp như là thành viên của
lớp khác. Đây là kỹ thuật “dâng tặng” và kỹ thuật loại trừ để dùng kế thừa lớp.
Nhưng nó thường đòi hỏi sự khéo léo để chọn lựa giữa hai kỹ thuật.

Thông thường, nếu cần để quá tải các thuộc tính hoặc các hàm, thì kế thừa là sự lựa
chọn là tốt nhất. Mặt khác, nếu chúng ta muốn biểu diễn một đặc tính bởi sự đa dạng

của các kiểu, thì quan hệ bao hàm là phương pháp cần đến. Một lúc nào đó chúng ta
cần dùng một đối tượng như một thành viên thì khi đó chúng ta cần gởi một thuộc
tính của lớp như một đối số đến hàm tạo của lớp khác. Lớp “khác” phải có một đối
tượng thành viên được biểu diễn như đối số.

Tính kế thừa biểu diễn quan hệ is_a và quan hệ bao hàm biểu diễn quan hệ has_a .

c/
Quan hệ sử dụng

Ví dụ, lớp A có thể dùng lớp B và C qua một vài cách
A đọc (
reads
) một thành viên của B
A gọi (
calls
) một thành viên của C
A tạo ra (
creates
) B sử dụng toán tử
new


Sự hiểu biết về các quan hệ như thế là quan trọng để thiết kế một chương trình.

Chương 11
Phát triển hệ thống hướng đối tượng

359
3/ Tổ chức sự phân cấp thứ bậc lớp
bao gồm sự nhận biết các thuộc tính và các
hàm chung nhất giữa một nhóm các lớp có quan hệ nhau và kết hợp chúng vào dạng
một lớp mới nào đó. Lớp mới này sẽ phục vụ như một siêu lớp (
super class
) và
những lớp khác như là các lớp phụ thuộc (với những thuộc tính dẫn xuất từ siêu lớp).
Lớp mới có thể hoặc không thể có ý nghóa của đối tượng bởi chính nó. Nếu một đối
tượng được tạo ra thuần túy để kết hợp các thuộc tính chung, nó được gọi là lớp trừu
tượng.

Tiến trình này có thể lặp lại ở các mức khác nhau của sự trừu tượng với một mục
đích duy nhất của việc bành trướng các lớp.

Ví dụ hình 11.18 minh họa tiến trình lặp hai mức.

A B X Y
C
D E
A B C D E

(a) Các đối tượng trong (b) Cây phân cấp mức thứ nhất
không gian lời giải

Z



X Y

A B C D E

(c) Cây phân cấp mức thứ hai


Hình 11.18 Các mức của phân cấp thứ bậc lớp

Tiến trình của tổ chức lớp có thể kết quả cuối cùng trong một mô hình cây đơn
(single-tree model) hoặc mô hình rừng cây (forest). Hình 11.19


Chương 11
Phát triển hệ thống hướng đối tượng



360
4/ Thiết kế các lớp
Chúng ta đã nhận biết các lớp, các thuộc tính của nó, và một tập hợp tối thiểu các
thao tác được yêu cầu qua khái niệm một lớp được biểu diễn. Bây giờ chúng ta hãy
xem xét các chi tiết đầy đủ mà mỗi lớp biểu diễn. Vấn đề quan trọng là quyết đònh
những hàm nào để xây dựng lớp. Với một lớp thông thường, cần có các hàm thực
hiện các chức năng sau đây :

(a) mô hình cây đơn










(b) mô hình rừng cây

Hình 11.19 Tổ chức các lớp

1. các hàm quản lý lớp
•
một đối tượng được tạo ra như thế nào ?
•
một đối tượng được hủy như thế nào ?
2. các hàm thực thi lớp

•
những thao tác nào sẽ được thực hiện trên kiểu dữ liệu của lớp ?

Chương 11
Phát triển hệ thống hướng đối tượng



361
3. các hàm truy xuất lớp
•
chúng ta sẽ lấy thông tin từ các biến bên trong của lớp như thế nào ?
4. các hàm tiện ích lớp
•
chúng ta sẽ xử lý lỗi như thế nào ?

Một vấn đề nữa cần xem xét đến :
1. Loại điều khiễn truy xuất nào được yêu cầu cho lớp cơ sở ?
2. Các hàm nàosẽ là hàm ảo ?
3. Các lớp thư viện nào sẽ dùng trong một lớp ?
Việc thiết kế các lớp riêng lẽ có ảnh hûng khá lớn đến chất lượng của phầm mềm.
Sau đây là một vài nguyên tắc chỉ đạo được dùng để xem xét trong khi thiết kế một
lớp :
1. giao tiếp chung của lớp chỉ giao cho một hàm của lớp.
2. một đối tượng của một lớp không thể gởi message trực tiếp đến thành viên
của lớp khác.
3. một hàm được khai báo là public chỉ khi nào nó được đòi hỏi sử dụng bởi các
đối tượng của lớp.
4. mỗi hàm truy xuất, thay đổi hoặc cả hai đến một vài dữ liệu của lớp mà nó
biểu diễn.

5. một lớp có thể phụ thuộc vào một vài lớp khác nếu có thể.
6. sự tươngtác giữa các lớp phải tường minh.
7. mỗi lớp phụ thuộc (
subordinate class
) phải được thiết kế như một sự chuyên
môn hoá của lớp cơ sở với một mục đích duy nhất bổ sung các đặc tính phụ.
8. lớp trên cao nhất của một cấu trúc nên biểu diễn như mô hình lớp trừu tượng.


5/ Thiết kế các hàm thành viên
Đến đây chúng ta đã nhận biết được :
1. Các lớp và cá đối tượng
2. các thành viên dữ liệu
3. các giao diện
4. các phụ thuộc và
5. phân cấp thứ bậc lớp

Lúc này cần xem xét việc thiết kế các hàm thành viên. Các hàm thành viên đònh
nghóa các thao tác dùng để thực hiện trên dữ liệu của đối tượng. Các hàm này cũng