Chuong1 - Modau

8/8/2019 Chuong1 - Modau

http://slidepdf.com/reader/full/chuong1-modau 1/19

Chươ ng 1: M ở đầu Tr ần Đình Qu ế

CHƯƠ NG 1

MỞ ĐẦU1

1.1 GIỚ I THIỆUHiện nay, phát tri ển phần mềm theo cách ti ế p cận hướ ng đối tượ ng đã tr ở thành ph ổbiến r ộng rãitrong công nghi ệ p phần mềm. Mục đích của chươ ng này tr ướ c hết nhằm trình bày các d ạng hệ thống thông tin, nh ững khái ni ệm cơ bản trong h ướ ng đối tượ ng như đối tượ ng, lớ p, đóng gói, cácquan h ệ lớ p…Sau đó, sẽ đi sâu phân tích các quan h ệgiữa các l ớ p, ưu điểm của đóng gói, cáccách sửdụng lại mã ngu ồn đặc biệt là mẫu thiết k ế(design pattern).

1.2 CÁC KIỂU HỆ THỐNG THÔNG TINTrong th ực tế có r ất nhiều kiểu hệthống thông tin và đểdễphân lo ại ngườ i ta chia các h ệthốngthông tin thành 4 m ức:

• Các hệthống mức vận hành (Operational-level Systems)

• Các hệthống mức tri th ức (Knowledge-level Systems)

• Các hệthống mức quản lý (Management-level Systems)

• Các hệthống mức chiến lượ c (Strategic-level Systems)

Mứ c Sử dụng Mục đích Các kiểu hệthống Ví dụ Các hệ thốngmứ c vậnhành

Nhà quản lý v ậnhành hay ng ườ i

phụtrách h ệthống(operationalmanagers).

Tr ả lờ i các câu h ỏithườ ng ngày. L ưu vếttrình t ự các ho ạt độngvà giao d ịch hàng ngày

Hệthống xử lý giaodịch(TPS : TransactionProcessingSystems)

Điều khiển máy móc,lưu tr ữ giao d ịch, lậ plịch cho máy móc, x ử lý đơ n hàng, điềukhiển dây chuy ền.

Các hệ thốngmứ c trithứ c

Nhân viên trithức và d ữ liệu(knowledge anddata workers).

Giúp t ổ chức, phát hi ệnvà tích h ợ p tri th ức mớ itừ tri thức đang tồn tạivào nghi ệ p vụ của họ.Giúp điều khiển luồngcông vi ệc văn phòng.

Hệthống hoạt đôngdựa trên tri th ức(KWS: KnowledgeWork Systems). H ệ thống tự động hóavăn phòng

Hệ xử lý ngôn ng ữ,lậ p l ịch

Các hệ thốngmứ c quảnlý

Nhà qu ản lý trunggian (middlemanagers).

Phục vụ việc giám sát,điều khiển, ra quy ếtđịnh và các ho ạt độngquản tr ị. Hỗ tr ợ ra cácquyết định quan tr ọng(ít có c ấu trúc) v ớ i cácyêu cầu về thông tinkhông rõ ràng.

Hệ thông tin qu ảnlý (MIS:ManagementInformationSystems), H ệhỗ tr ợ quyết định ( DSS: Decision SupportSystems)

Quản lý bán hàng,hàng t ồn kho, ngânsách hàng n ăm, lậ pk ế hoạch sản xuất,

phân tích chi phí, phân tích giá cả/lợ inhuận.

Các hệ thốngmứ c chiếnlượ c

Nhà qu ản lý chính(senior managers).

Giúp gi ải quyết và v ạchra các v ấn đề chiếnlượ c và các xu h ướ nglâu dài: so sánh kh ả năng của tổ chức vớ inhững thay đổi và c ơ hội xảy ra trong kho ảng

Hệ hỗ tr ợ thực thi(Executive SupportSystems – ESS)

Dự đoán ngân sách,xu hướ ng bán hàngtrong 5 n ăm. K ế hoạch ho ạt độngtrong 5 n ăm. K ế hoạch về lợ i nhuận,nhân l ực.

1 Tài liệu tham kh ảo dành cho sinh viên n ăm cuối và Cao h ọc ngành CNTT. Tác gi ảgiữbản quyền

1




thờ i gian dài c ủa môitr ườ ng bên ngoài.

Nhưvậy, có 6 ki ểu hệthống thống tin t ươ ng ứng vớ i 4 mức:

• Hệthống xử lý giao d ịch (Transaction Processing Systems – TPS).

• Hệthống hoạt động dựa trên tri th ức (Knowledge Work Systems – KWS). • Hệthống tự động hóa v ăn phòng (Office Automation Systems – OAS).

• Hệthống thông tin qu ản lý (Management Information Systems – MIS).

• Hệtr ợ giúp quy ết định (Decision Support Systems – DSS).

• Hệtr ợ giúp th ực thi (Executive Support Systems – ESS).

Tươ ng ứng vớ i các ki ểu hệthống thông tin, các quá trình x ử lý đượ c cho trong các hình sau đây:

Hình 1.1: Quá trình xử lý trong TPS và MIS

Hình 1.2: Quá trình xử lý trong DPS

2




Hình 1.3: Quá trình xử lý trong ESSQuan h ệgiữa các ki ểu hệthống thông tin đượ c cho trong Hình 1.4

Hình 1.4: Quan hệgiữ a các kiểu hệthống thông tin

3




1.3 MÔ HÌNH HỆTHỐNG DỰ A TRÊN CÁCH TIẾP CẬN HƯỚ NGĐỐI TƯỢ NG

1.3.1 Mô hình hệthốngMô hình h ệthống dựa vào cách ti ế p cận hướ ng đối tượ ng là ph ươ ng pháp phân tích các yêu c ầucủa hệthống nhằm mục đích xác định các h ệthống con th ỏa mãn các tính ch ất sau:

• Mỗi hệthống con có trách nhi ệm rõ ràng trong vi ệc thực hiện một phần của tác v ụ.• Mỗi hệthống con nên là độc lậ p và tựchủ.

• Mỗi hệthống con nên bi ết các h ệthống con khác làm gì và làm th ếnào đểgửi thông điệ pđểyêu cầu chúng h ợ p tác và hoàn thành công vi ệc của mình.

• Hệthống con nên ẩn giấu dữ liệu mà nó s ửdụng so v ớ i thếgiớ i bên ngoài.

• Hệthống con nên đượ c thiết k ế đểcó thểdùng lại.

Mô hình h ệthống dựa vào cách ti ế p cận hướ ng đối tượ ng đượ c sửdụng r ộng rãi trong th ực tếvì:

• Làm cho nh ững thay đổi trong phát tri ển các ch ức năng suốt vòng đờ i của hệthống tr ở

nên dễdàng h ơ n.• Làm cho vi ệc dùng l ại code c ủa các h ệthống con trong khi thi ết k ếcác hệthống hơ n tr ở

nên dễdàng h ơ n.

• Làm cho vi ệc tích h ợ p các h ệthống con thành h ệthống lớ n tr ở nên dễdàng h ơ n.

• Làm cho vi ệc thiết k ếcác hệthống phân tán tr ở nên dễdàng h ơ n.

Mô hình h ệthống dựa vào cách ti ế p cận hướ ng đối tượ ng đượ c sửdụng trong nh ững tình hu ốngsau đây:

• Cần thay đổi một hệthống đang tồn tại bằng cách thêm ch ức năng mớ i.• Hệthống lớ n có th ể đượ c thiết k ếbằng cách thu th ậ p các đối tượ ng sẵn có đểsửdụng lại.

1.3.2 UMLTrong môn Công ngh ệphần mềm, chúng ta đã làm quen v ớ i UML. Ph ần này trình bày t ổng quanđểcó cái nhìn đầy đủhơ n 13 ki ểu biểu đồ trong UML. Đặc tảUML không nói các bi ểu đồnàynên sửdụng ở đâu trong t ừng phươ ng pháp lu ận nên chúng ta đượ c phép t ựdo sửdụng chúng ở

bất cứ lúc nào th ấy thích h ợ p.

• Biểu đồuse case (use case diagram)• Biểu đồlớ p (class diagrams)• Biểu đồ đối tượ ng (Object diagrams)• Biểu đồhoạt đông (Activity

diagrams)• Biểu đồmáy tr ạng thái (State

machine diagrams)• Biểu đồtruyền thông

(Communication diagrams)• Biểu đồdãy (Sequence diagrams)• Biểu đồgói (Package diagrams)

• Biểu đồtriển khai (Deploymentdiagrams)

• Biểu đồthành ph ần (Componentdiagrams)

• Biểu đồtổng quan t ươ ng tác (Interactionoverview diagrams)

• Biểu đồthờ i gian (Timing diagrams)• Biểu đồcấu trúc h ợ p (Composite

structure diagram)

4




Hình 1.5: Phân loại các kiểu biểu đồUMLCác bi ểu đồ nhóm c ấu trúc (Structure diagram) th ườ ng đượ c dùng k ết hợ p vớ i nhóm bi ểu đồ hành vi (behavior diagram) đểmô tảmột khía c ạnh nào đó của hệthống. Mỗi lớ p có m ột biểu đồ máy tr ạng thái (state machine diagram) t ươ ng ứng đểxác định hành vi đượ c điều khiển bở i sự kiện của các th ểhiện của lớ p đó. Nếu k ết hợ p biểu đồ đối tượ ng (object diagram) v ớ i k ịch bản(scenario), ta có bi ểu đồ tươ ng tác (interaction diagram) đểbiểu diễn thứ tự các thông điệ p theothờ i gian ho ặc theo s ựkiện.

• Biểu đồgói (Package diagram): dùng đểtổchức các s ản phẩm của quá trình phát tri ển,cung c ấ p cho chúng ta kh ảnăng biểu diễn các thành ph ần UML theo nhóm.

• Biểu đồ thành phần (Component diagram): dùng đểmô hình các module, các thành phần của hệthống. Một thành ph ần là m ột phần của hệthống đượ c đóng gói, có th ểdùnglại và có kh ảnăng thay th ế. Ví dụ: loggers, XML parsers, online shopping cards… Đây làcác thành ph ần chung đượ c cộng đồng sử dụng, nhưng bạn có th ểtự tạo các thành ph ầnriêng cho mình.

• Biểu đồ triển khai (Deployment diagram): mô hình ph ần mềm gắn vớ i phần cứng trongthếgiớ i thực. Nó ch ỉ ra cách t ổ chức vật lý và cách giao ti ế p giữa phần mềm vớ i phần

cứng.• Biểu đồ đối tượ ng (Object diagram): dùng khi mu ốn miêu t ả cách mà các đối tượ ng

trong h ệthống sẽlàm vi ệc vớ i nhau trong m ột tr ườ ng hợ p cụthể.

• Biểu đồ cấu trúc hợ p (Composite structure diagram): ch ỉ ra cách các đối tượ ng tạonên một bức tranh l ớ n. Chúng mô hình cách mà các đối tượ ng làm vi ệc vớ i nhau trongmột lớ p, hoặc cách các đối tượ ng đạt đượ c mục đích.

• Biểu đồuse case (Use case diagram): mô hình các ch ức năng mà h ệthống cung c ấ p.

5




• Biểu đồhoạt đông (Activity diagram): mô hình các ti ến trình nghi ệ p vụ. Một tiến trìnhnghiệ p vụlà sựk ết hợ p của các tác v ụnhằm đạt đượ c một mục đích nghi ệ p vụnào đó. Vídụ, phân ph ối đơ n hàng c ủa khách hàng…

• Biểu đồmáy trạng thái (State machine diagram): mô hình các tr ạng thái c ủa một đốitượ ng.

• Biểu đồ tuần tự (Sequence diagram): cho phép mô hình m ột cách chính xác cách cácthành ph ần của hệthống tươ ng tác v ớ i nhau..

• Biểu đồgiao tiếp (Communication diagram): tậ p trung vào liên k ết tươ ng tác. Nó ch ỉ racác liên k ết nào c ần thiết đểtruyền thông điệ p tươ ng tác gi ữa các bên tham gia

• Biểu đồ thờ i gian (Timing diagram): mỗi sự kiện có thông tin v ềthờ i gian t ươ ng ứngvớ i nó. Bi ểu đồnày miêu t ảchính xác khi nào s ựkiện xảy ra, m ất bao lâu đểbên tham gianhận đượ c sựkiện đó và m ất bao lâu đểbên nh ận sựkiện chuy ển tr ạng thái.

• Biểu đồ tổng quan tươ ng tác (Interaction overview diagram): cung c ấ p cái nhìn m ức

cao vềcách mà m ột sốtươ ng tác làm vi ệc vớ i nhau đểcài đặt hệthống.

1.4ĐỐI TƯỢ NG VÀ LỚ P

1.4.1Đối tượ ngĐối tượ ng là m ột sựvật, một thực thể, một danh t ừhoặc bất cứcái gì mà b ạn có th ểnhặt lên ho ặcđá đi, hay nh ững gì mà b ạn có th ểtưở ng tượ ng ra v ớ i một số đặc tính c ủa nó. Trong khi m ột số đối tượ ng thì đang tồn tại, một số thì không có hi ện thờ i. Ví d ụ, xe hơ i, ngườ i, ngôi nhà, cái bàn,chậu cây ho ặc áo m ưa, hóa đơ n bán hàng…

Các đối tượ ng đều có m ột số thuộc tính. Ví d ụ, xe hơ i có các thu ộc tính là nhà s ản xuất, số hiệu model, màu s ắc, giá…Con chó có các thu ộc tính là gi ống chó, tu ổi thọ, màu lông, đồchơ iyêu thích. Các đối tượ ng c ũng có hành vi c ủa nó nh ưxe hơ i có th ểdi chuy ển từnơ i này đến nơ ikhác, chó có th ểsủa…

Mô tả đối tượ ngMột khi đã quyết định làm vi ệc vớ i đối tượ ng, ta c ần phải có cách đểbiểu diễn chúng theo bi ểuđồ đểcó thểmiêu t ảvà suy ngh ĩ vềchúng. Bi ểu đồ đối tượ ng trong UML có d ạng nhưhình v ẽ:

anObjectattribute1attribute2

operation1()operation2()operation3()

Mỗi đối tượ ng đượ c mô t ảbở i 3 thành ph ần:

- Tên của đối tượ ng (có g ạch chân).

- Các thu ộc tính (tri th ức về đối tượ ng).

- Các thao tác (hành vi c ủa đối tượ ng).

6




Ví dụ Đối tượ ng máy pha cà phê t ự động aCoffeeMachine bao gồm các thao tác:

- Hiển th ị đồuống

- Lựa chọn đồuống.

- Nhận tiền.

- Pha ch ế đồuống.Máy pha cà phê c ần biết những gì đểcó thểthực hiện các thao tác trên:

- Các đồuống đang có s ẵn.

- Giá đồuống.

- Công th ức pha ch ế đồuống.

Nhưvậy ta có th ểbiểu diễn đối tượ ng máy pha cà phê nh ưsau:

1.4.2 Lớ p

aCoffeeMachine

drinkPricesavailableDrinksdrinkRecipes

displayDrinks()selectDrink()dispenseDrink()acceptMoney()

Một lớ p đóng gói các đặc điểm chung c ủa một nhóm các đối tượ ng. Các nhà phát tri ển hướ ng đốitượ ng sử dụng các l ớ p đểmô tảcác thành ph ần mà các d ạng đối tượ ng cụ thểsẽcó. Không cólớ p, ta sẽphải thêm các thành ph ần này vào t ừng đối tượ ng riêng bi ệt. Biểu diễn lớ p trong UML

tươ ng tựnhưbiểu diễn đối tượ ng nhưng tên l ớ p không g ạch chân.

1.5ĐÓNG GÓIMột trong các cách c ơ bản để đảm bảo thiết k ếlớ p tốt là tạo ra vi ệc đ óng gói d ữ liệu. Ví dụ, tạolớ p Employee chứa các thông tin mà ứng dụng cần đểmiêu t ảmột nhân viên:

public class Employee {public int employeeID;public String firstName;public String lastName;

}

Các thu ộc tính đều ghi là public ngh ĩ a là chúng có th ể đượ c truy c ậ p từmọi lớ p bằng các câu l ệnhsau:

Employee emp = new Employee();emp.employeeID = 123456;emp.firstName = “John”;emp.lastName = “Smith”;

Mặc dù Java cho phép đọc và sửa đổi các tr ườ ng theo cách này, nh ưng thông th ườ ng thì b ạnkhông nên làm nh ưvậy. Thay vào đó, ta c ần thay đổi phạm vi truy c ậ p tớ i các tr ườ ng đểgiớ i hạn

7




khảnăng truy c ậ p của chúng b ằng cách s ử dụng các ph ươ ng thức set, get cho m ỗi tr ườ ng đểcóthểtruy c ậ p tớ i thuộc tính.

public class Employee {protected int employeeID;protected String firstName;protected String lastName;public int getEmployeeID() {

return employeeID;}public void setEmployeeID(int id) {

employeeID = id;}public String getFirstName() {

return firstName;}public void setFirstName(String name) {

firstName = name;}

public String getLastName() {return lastName;

}public void setLastName(String name) {

lastName = name;}

}

Lợ i ích của việc đóng gói• Đóng gói an toàn

• Đóng gói làm đơ n giản hóa vi ệc chuy ển đổi một lớ p đang tồn tại thành m ột lớ p đượ c

dùng đểtạo các đối tượ ng phân tán (t ừ xa). Đối tượ ng phân tán th ườ ng nằm ở máy ch ủ,các phươ ng thức của nó có th ể đượ c gọi bở i các ứng dụng nằm trên các máy khác (nóicách khác là có th ể đượ c gọi thông qua m ạng). Do đó, các tr ườ ng thu ộc đối tượ ng đókhông th ể đượ c gọi tr ực tiế p như vớ i đối tượ ng cục bộ. Tuy nhiên, n ếu định ngh ĩ a các

phươ ng thức set và get, ta có th ểlàm đượ c điều này.

• Ngoài ra, vi ệc sửdụng các ph ươ ng thức set và get s ẽcô lậ p chúng ta kh ỏi những thay đổitrong cài đặt một tính ch ất. Ví d ụ, có th ể đổi employeeID t ừkiểu int sang ki ểu String màkhông ảnh hưở ng tớ i các lớ p khác, mi ễn là chúng ta th ực hiện việc chuy ển đổi thích h ợ ptrong các ph ươ ng thức set và get.

Đóng góiẩn giấu việc vàiđặt chi tiếtpublic class Employee {

protected String employeeID;protected String firstName;protected String lastName;

public int getEmployeeID() {return Integer.parseInt(employeeID);

} public void setEmployeeID(int id) {

employeeID = Integer.toString(id);

8




}public String getFirstName() {

return firstName;}

public void setFirstName(String name) {firstName = name;

}public String getLastName() {

return lastName;}public void setLastName(String name) {

lastName = name;}

}Mặc dù, vi ệc cài đặt thuộc tính employeeID b ị thay đổi, nhưng các l ớ p khác khi đọc và sửa đổithuộc tính này s ẽkhông nhìn th ấy bất k ỳ thay đổi nào trong hành vi c ủa nó, vì vi ệc thay đổi trongcài đặt đượ c che gi ấu bở i các ph ươ ng thức set và get. Đóng gói các thu ộc tính c ủa lớ p cho phépđịnh ngh ĩ a các giá tr ị dẫn xuất có kh ảnăng truy c ậ p. Ví dụ, bạn có th ể định ngh ĩ a phươ ng thứcgetFullName() trong l ớ p Employee đểtr ảvềhọtên đầy đủdướ i dạng một chuỗi đơ n:

public String getFullName() {Return firstName + “ “ + lastName;

}Tất nhiên, có th ểlấy giá tr ị dẫn xuất mà không c ần tạo phươ ng thức get, nh ưng thườ ng sẽtạo racác đoạn mã trùng nhau khi d ẫn xu ất giá tr ị. Ví dụ, đểdẫn xuất tên đầy đủ ở một sốvị trí trongứng dụng, bạn phải copy đoạn mã (firstName + “ “ + lastName) vào các v ị trí đó vànếu thay đổi cài đặt, bạn phải thay đổi từng v ị trí như khi bạn muốn có thêm middleName .

Nhưng khi s ử dụng phươ ng thức getFullName() thì bạn ch ỉ cần thay đổi ở một v ị trí trongmã ngu ồn mà thôi.

1.6 QUAN HỆGIỮ A CÁC LỚ P

1.6.1 Các quan hệphụ thuộc: Association, aggregation và CompositionKhông có m ột đối tượ ng nào có th ểtồn tại riêng l ẻ. Tất cảcác đối tượ ng đều đượ c liên k ết vớ icác đối tượ ng khác, tr ực tiế p hoặc gián ti ế p, mạnh hoặc yếu. Các liên k ết cho phép ta tìm ra nhi ềuthông tin và hành vi ph ụ. Ví dụ, nếu ta đang xử lý một đối tượ ng Customer biểu diễn tên Lanvà ta mu ốn gửi cho Lan m ột bức thư thì ta c ần phải biết Lan s ống ở số42 Nguy ễn Trãi, Hà n ội.Ta mu ốn có thông tin v ề địa ch ỉ đượ c lưu tr ữ trong đối tượ ng Address , vì vậy cần có k ết nốigiữa Customer và Address đểbiết thư đượ c gửi đến đâu.

Khi mô hình hóa đối tượ ng, cần liên k ết chúng theo hai cách chính sau đây: association vàaggregation. R ất khó đểchỉ ra sựkhác bi ệt giữa hai cách này, sau đây là m ột sốgợ i ý:

• Associationlà một dạng liên k ết yếu; các đối tượ ng là m ột phần của một nhóm, ho ặc mộthọcác đối tượ ng nhưng chúng không hoàn toàn ph ụthuộc vào đối tượ ng khác. Ví d ụ, xétcác đối tượ ng xe h ơ i, ngườ i lái xe và hai khách đi xe. Khi ng ườ i lái xe và 2 khách đi xe ở trong xe, h ọ đượ c liên k ết vớ i nhau vì h ọ cùng đi vềmột hướ ng, họ cùng chi ếm một

9




khoảng không gian…nh ưng liên k ết sẽmất khi xe tr ảmột vị khách nào đó đến nơ i yêucầu, v ị khách đó sẽkhông còn liên k ết vớ i các đối tượ ng xe và ng ườ i lái xe n ữa.

• Aggregation: ngh ĩ a là đặt các đối tượ ng có liên k ết vớ i nhau cùng nhau để tạo ra đổitượ ng lớ n hơ n. Ví d ụ, máy tính đượ c tạo bở i các b ộ phận màn hình, ổ cứng, bàn

phím…Aggregation th ườ ng có d ạng phân c ấ p bộ phận-toàn thể (part-whole) .Aggregation ám ch ỉ sự phụ thuộc giữa bộ phận và toàn th ể, ví dụ, màn hình v ẫn là mànhình n ếu lấy nó ra kh ỏi máy tính, nh ưng máy tính s ẽmất tác d ụng nếu thiếu màn hình.

Như đã nói ở trên, th ật khó đểphân bi ệt giữa association và aggregation. Tuy nhiên, có th ể đặtcâu hỏi “Điều gì sẽ xảy ra n ếu bỏ đi một trong các đối tượ ng?” đểxác định quan h ệ đó làassociation hay aggregation. Nh ưng không ph ải là lúc nào nó c ũng giải quyết đượ c vấn đềmà cần

phải suy ngh ĩ thườ ng xuyên và c ần có kinh nghi ệm. Ta th ườ ng phải chọn lựa giữa association vàaggregation, vì l ựa chọn đó có th ể ảnh hưở ng đến cách ta thi ết k ếphần mềm.

Ví dụ“xử lý hóađơ n”Liên k ết (Association): Quan h ệAssociation th ườ ng đượ c miêu t ảgiống nhưquan h ệtham chi ếu(reference), trong đó một đối tượ ng nắm giữmột tham chi ếu đến đối tượ ng khác.

Hình 1.6: Quan hệliên k ết

Cài đặt:package relation;

public class Customer {private String _address;private String _code;private String _name;

}

package relation;

public class Order {

private relation.Customer _customer;private OrderLine[] _orderLine;private Currency _total;public OrderLine addLine() {

throw new UnsupportedOperationException();}public void removeLine() {

throw new UnsupportedOperationException();}

}

10




Đây là quan h ệdễcài đặt nhất, trong UML nó đượ c biểu diễn là một đườ ng thẳng nối giữa 2 lớ p.Chiều m ũi tên nói lên r ằng ta g ọi đối tượ ng Customer t ừ đối tượ ng Order nh ưng không g ọi Order từCustomer.

Tập hợ p (Aggregation)Quan h ệgiữa lớ p OrderList và lớ p Order là Aggregation. Ngh ĩ a là danh sách OrderList

bao gồm nhiều Order nhưng các Order có đờ i sống riêng c ủa nó và không c ần phải là m ột bộphận của danh sách OrderList cụthể.

Hình 1.7: Quan hệtập hợ pCài đặt:

package relation;public class Order {

private relation.Customer _customer;private OrderLine[] _orderLine;private Currency _total;public OrderLine addLine() {

throw new UnsupportedOperationException();}public void removeLine() {

throw new UnsupportedOperationException();

}}

package relation;import java.util.Vector;import aggregation.Order;

public class OrderList {Vector<Order> _order = new Vector<Order>();public void add() {

throw new UnsupportedOperationException();}public int getCount() {

throw new UnsupportedOperationException();}public OrderIterator getIterator() {

throw new UnsupportedOperationException();}public void remove() {


}

11




Aggregation đượ c biểu diễn trong UML b ở i một đườ ng thẳng có hình qu ả trám r ỗng ở 1 đầu.Điều này xác định không có quan h ệsở hữu trong quan h ệnày và các th ểhiện của lớ p đượ c k ếthợ p sẽ đượ c quản lý bên ngoài l ớ p đang k ết hợ p.

Hợ p thành, cấu thành (Composition)Quan h ệgiữa Order và OrderLine là Composition. Các OrderLine của một Order đềuthuộc về Order và không có ý ngh ĩ a bên ngoài Order đó. Order có trách nhi ệm hoàn toàntrong vi ệc tạo, quản lý, và xóa b ất k ỳ OrderLine nào trong Order đó. Biểu diễn trong UMLlà đườ ng thẳng một đầu có hình qu ảtrám màu đen.

Hình 1.8: Quan hệcấu thànhCài đặt:

package relation;public class OrderLine {

private Currency _value;aggregation.Order _orderLine;

}

package relation;public class Order {

private Customer _customer;private OrderLine[] _orderLine;private Currency _total;aggregation.OrderList _unnamed_OrderList_;

public OrderLine addLine() {throw new UnsupportedOperationException();

}public void removeLine() {


}

1.6.2 K ếthừ aK ếthừa cho phép m ột lớ p lấy lại một số đặc điểm, thu ộc tính t ừ lớ p cha và sau đó thêm vào m ộtsố đặc tr ưng riêng c ủa nó. K ếthừa cho phép ta nhóm m ột số lớ p thành m ột lớ p tổng quát h ơ n để có thể đưa ra các đối tượ ng r ộng hơ n vềthếgiớ i mà ta đang sống.

Thiết k ếkiến trúc phân cấp lớ pVí dụ, ta mu ốn mô hình các b ộsưu tậ p đểlưu giữcác đối tượ ng cho s ửdụng vềsau này. Sau khi

phân tích, ta th ấy có 4 ki ểu bộsưu tậ p nhưsau:

12




• List: lưu giữcác đối tượ ng theo th ứ tựmà nó đượ c đưa vào.

• Bag: lưu các đối tượ ng nhưng không theo th ứ tự.

• LinkedList: lưu các đối tượ ng theo th ứ tự bằng cách cài đặt một chuỗi các đối tượ ngtrong đó mỗi đối tượ ng ch ỉ tớ i một đối tượ ng khác trong chu ỗi. Danh sách liên k ết cho

phép c ậ p nhật dễdàng, nh ưng truy c ậ p chậm vì ta ph ải duyệt toàn b ộdanh sách.

• ArrayList: lưu các đối tượ ng theo th ứ tự sử dụng như là một mảng, ngh ĩ a là m ột chuỗicác ô nh ớ liên ti ế p. Mảng cho phép truy c ậ p nhanh nh ưng cậ p nhật chậm vì ta có th ểphảidịch các ph ần tửhoặc tạo một mảng mớ i mỗi khi c ậ p nhật.

Làm thếnào thiết k ếkiến trúc phân cấp kiểu k ếthừ a? Điểm mấu chốt là xem xét s ự tươ ngđồng giữa các khái ni ệm vớ i nhau. Rõ ràng, chúng đều là các b ộ sưu tậ p, vì vậy lớ p Collection sẽ đưa lên đầu. Trong 4 b ộ sưu tậ p trên, ch ỉ có Bag là không l ưu các đối tượ ngtheo th ứ tự, còn lại đều lưu đối tượ ng theo th ứ tự. Do đó, ta đặt Bag tr ực tiế p ngay bên d ướ iCollection trong m ột nhánh riêng. Ta th ấy, List không có ràng bu ộc gì về cài đặt bên

trong, trong khi LinkedList và ArrayList thì có. Vì v ậy, List sẽ là lớ p cha củaLinkedList và ArrayList . Ta có b ản thiết k ếphân c ấ p lớ p nhưsau:

Hình 1.9: Thiết k ếkiến trúc phân cấpTrong th ực tế, ta thườ ng làm ng ượ c lại. Tr ướ c hết, ta miêu t ả các lớ p ở mức lá (Bag,

ArrayList và LinkedList) và sau đó, ta tìm ki ếm các khái ni ệm tổng quát h ơ n. Trong khi pháttriển mô hình k ếthừa, ta tìm các message có thểchia sẻ, đưa chúng vào mô hình k ếthừa càng ở các lớ p trên càng t ốt. Ta s ẽ tìm các message tr ướ c khi tìm các thành ph ần lớ p khác vì các

message bi ểu diễn giao ti ế p giữa các đối tượ ng vớ i thếgiớ i bên ngoài. Xét các message trong môhình phân c ấ p Collection:

• contains(:Object): boolean Tìm các đối tượ ng trong b ộsưu tậ p và tr ảvềtruenếu bộsưu tậ p chứa tham s ố, ngượ c lại tr ảvềfalse.

• elementAt(:int): Object tr ảvề đối tượ ng ở vị trí đượ c xác định bở i tham s ố truyền vào.

• numberOfElements(): int tr ảvềsốnguyên là s ố đối tượ ng trong b ộsưu tậ p.

13




Đặt các message này vào lớ p nào? Contains() có thểdùng đối vớ i mọi bộ sưu tậ p, vì vậyđặt nó trong Collection . ElementAt(: int) lấy đối tượ ng ở vị trí xác định nên ph ải đặttrong List , để tránh s ự lặ p lại nếu để trong ArrayList và LinkedList .

NumberOfElement() có thểdùng v ớ i mọi bộsưu tậ p nên đểnó trong Collection . Ta có bản thiết k ếsau đây:

Hình 1.10:Đư a các message vào các lớ pCài đặt phân cấp lớ pVì thu ật toán tìm ki ếm khác nhau đối vớ i bộ sưu tậ p như theo th ứ tự và không theo th ứ tự, nêncontains() không th ểcài đặt trong Collection. ỞBag và List ta s ẽcài đặt hàm contains() khácnhau.

//Cài đặ t hàm contains trong l ớp Listbolean contains(Object obj) {

for (int i= 0; i< numberOfElements(); ++i) {if (elementAt(i) == 0) {

return true;}

}return false;

}Hàm elementAt đượ c cài đặt khác nhau trong hai l ớ p ArrayList và LinkedList. Vì v ậy, ta ph ảicó hai ph ươ ng thức elementAt riêng: m ột cho lớ p ArrayList – truy c ậ p các ph ần tửmột cách tr ựctiế p, một cho l ớ p LinkedList – duyệt toàn b ộ danh sách. Cài đặt phươ ng thức

numberOfElements() phụ thuộc vào vi ệc ta lưu giá tr ị đó trong m ột tr ườ ng hay tính nó khicần.

• Lư u số phần t ử trong m ột tr ườ ng : tr ườ ng này s ẽtăng khi thêm ph ần tử và giảm khi xóa phần tử. Cách này cho phép ghi s ốphần tửmột cách nhanh chóng tùy thu ộc vào b ộnhớ nhưng chậm trong vi ệc thêm và xóa đối tượ ng.

• Tính toán s ố phần t ử khi cần: đối vớ i LinkedList thì ch ậm vì ph ải duyệt toàn b ộ sốphầntử. Đối vớ i ArrayList và Bag, các đối tượ ng bên trong có th ểlưu tr ữ sốphần tử, do đó sẽ nhanh h ơ n. Cách này s ẽkhông t ốn bộnhớ và không b ị chậm trong vi ệc thêm và xóa đốitượ ng.

14




Ta có thi ết k ếlớ p nhưsau:

Hình 1.11:Đư a các thôngđiệp vào các lớ pCác ph ươ ng thức in nghiêng là các ph ươ ng thức tr ừu tượ ng, còn l ại là các ph ươ ng thức thực.Phươ ng thức tr ừu tượ ng ch ỉ có tên mà không có các dòng code cài đặt, còn ph ươ ng thức thực thìngượ c lại.

Các lớ p trừ u tượ ngLớ p tr ừu tượ ng là l ớ p có ít nh ất một phươ ng thức tr ừu tượ ng – nó có th ểnằm trong l ớ p đó hoặcđượ c k ếthừa từ lớ p cha. Khi thi ết k ếphân c ấ p lớ p, ta nên hình dung trong đầu r ằng lớ p cha caonhất là tr ừu tượ ng.

Định ngh ĩ a lại các phươ ng thứ cCách ti ế p cận hướ ng đối tượ ng cho phép ta định ngh ĩ a lại các ph ần tử từ k ế thừa. Ởdạng đơ ngiản nhất, định ngh ĩ a lại cho phép l ớ p con thay đổi việc cài đặt phươ ng thức đượ c k ếthừa. Tên

phươ ng thức vẫn như cũ nhưng các dòng code trong thân s ẽ đượ c thay th ế. Hoặc tạo chuy ểnmessage t ừprivate sang public; đổi tên ho ặc kiểu của một thuộc tính. Ở đây, ta ch ỉ tậ p trung vàođịnh ngh ĩ a lại nội dung c ủa phươ ng thức, vì đó là lý do quan tr ọng nhất cho vi ệc định ngh ĩ a lại.Có 3 lý do chính gi ải thích t ại sao ta ph ải định ngh ĩ a lại:

• Phươ ng thức đượ c k ếthừa là tr ừu tượ ng và ta mu ốn biến nó thành th ực, bằng cách thêmvào một số dòng code. Ví d ụ, contains là tr ừu tượ ng trong Collection nh ưng cần là th ựctrong Bag và List

• Phươ ng thức cần phải làm thêm m ột sốcông vi ệc nằm ở lớ p con

• Ta có th ểcung c ấ p một cài đặt tốt hơ n cho l ớ p con. Ví d ụ, nếu thêm m ột ch ỉ sốvào lớ pLinkedList, ta có th ể định ngh ĩ a lại contains đểthực hiện nhanh h ơ n thuật toán tu ần tự đượ c dùng b ở i List.

Khi thêm công vi ệc, ta ph ải chắc chắn r ằng định ngh ĩ a lớ p cha v ẫn làm m ọi thứbình th ườ ng – để tăng việc chia s ẻmã ngu ồn và đơ n giản hóa vi ệc bảo trì (ví d ụ, nếu sửa đổi định ngh ĩ a của lớ pcha, lớ p con s ẽtự động có hành vi m ớ i). Mỗi ngôn ng ữhướ ng đối tượ ng cho phép ph ươ ng thứcđượ c định ngh ĩ a lại có th ểgọi phươ ng thức trong l ớ p cha.

15




//Ví d ụ trong Java:void initialize() {

//invoke the inherited initialize methodsuper.initialize();…

}

Đa k ếthừ aMỗi lớ p con có nhi ều lớ p cha. C++ cho phép đa k ếthừa nhưng cách thi ết k ếvà cài đặt k ỹ thuậtnày trong C++ không th ực sự tốt nên c ần phải tránh khi thi ết k ế; Java có m ột dạng đa k ếthừa đốivớ i interface và lớ p abstract (không cài đặt phươ ng thức).

1.7 CÁCH SỬ DỤNG LẠI MÃ NGUỒNCó một sốcách đểsửdung l ại mã ngu ồn:

• Dùng lại các chứ c năng trong một hệthống: Dạng đơ n giản nhất là dùng l ại code ( đượ csửdụng trong phát tri ển các h ệthống theo cách truy ền thống) liên quan đến việc viết các

hàm ti ện ích đượ c gọi từnhiều nơ i. Ví d ụ, bạn thấy một sốphần trong h ệthống cần đượ ctìm ki ếm thông qua m ột danh sách tên khách hàng, do đó bạn viết một hàm tìm ki ếmchung. Vi ệc viết các hàm có kh ảnăng dùng l ại khác v ớ i viết các hàm chia ti ến trình ph ứctạ p thành các b ướ c đơ n giản.

• Dùng lại các phươ ng thứ c trong một đối tượ ng: Các ph ươ ng thức đượ c đóng gói trongmột đối tượ ng có th ể đượ c gọi từ các phươ ng thức khác. Ví d ụ, phươ ng thức

drawFilledRectangle trong l ớ p GUIComponent có thể đượ c sử dụng bở i bất k ỳ phươ ng thức nào c ủa GUIComponent để tô màu m ột vùng màn hình v ớ i màu n ền xácđịnh. Bạn nên ngh ĩ đến việc sửdụng lại các ph ươ ng thức trong m ột đối tượ ng bất cứkhi

nào cần. Các ph ươ ng thức nonpublic trong m ột đối tượ ng thườ ng đượ c dùng đểchia nh ỏ các tiến trình ph ức tạ p theo ki ểu truyền thống.

• Dùng lại các lớ p trong một hệ thống: Nhiều lớ p mà ta định ngh ĩ a có th ể đượ c dùngtrong các ph ần khác nhau c ủa hệ thống. Ví d ụ, nếu bạn định ngh ĩ a lớ p Customer đểsử dụng trong h ệ thống marketing, b ạn muốn đối tượ ng Customer t ươ ng tự xuất hiện trongnhiều phần khác nhau c ủa mã ngu ồn hệ thống. Kiểu dùng l ại này là c ơ sở của cách ti ế pcận hướ ng đối tượ ng.

• Dùng lại các hàm trong nhiều hệ thống: các ch ức năng chung có th ể đượ c dùng l ại(trong phát tri ển hệ thống kiểu truyền thống c ũng như hướ ng đối tượ ng) trong các h ệ

thống khác mà b ạn và các đồng nghi ệ p tạo ra. Ví d ụ, bạn có th ểviết một chức năng lấy ranăm tham gia vào công ty t ừ số thứ tự bảng lươ ng của nhân viên. V ớ i một chức năngđượ c dùng l ại bở i đồng nghi ệ p, bạn phải giải thích cho h ọhiểu nó, có th ể đểvào nơ i chứatài nguyên dùng l ại, một cơ sở dữ liệu các ch ức năng mà các l ậ p trình viên có th ểxem xétkhi viết mã ngu ồn mớ i.

• Dùng lại các lớ p trong các hệthống: Ta có th ểtạo ra và dùng l ại toàn b ộmột lớ p (baogồm các thu ộc tính và các ph ươ ng thức) hơ n là ch ỉ một hàm đơ n độc. Ví d ụ đối tượ ng

16




Employee đóng gói các thu ộc tính và m ột tậ p các thao tác c ủa nhân viên đượ c sử dụngtrong toàn b ộcông ty. Nh ững ngườ i ưa chuộng hướ ng đối tượ ng là nh ững ngườ i muốn tạora nơ i chứa tài nguyên dùng l ại đểchứa các lớ p hơ n là các hàm.

• Dùng lại các lớ p trong tất cảcác hệthống: một bộphận trong ph ần mềm cũng tươ ng tự nhưmột bộ phận trong ph ần cứng. Các thành ph ần trong ph ần mềm đượ c thiết k ế đểcóthểdùng l ại trong nhi ều ngữ cảnh, đượ c đóng gói ch ặt chẽ(bên yêu c ầu không bi ết côngviệc bên trong là gì), đi cùng v ớ i phong cách chu ẩn của interface, và đượ c cung c ấ p sẵn từ

bên thứ 3, thườ ng là ph ải tr ả chi phí. M ỗi ngôn ng ữ lậ p trình hướ ng đối tượ ng có m ộtkhuôn m ẫu các thành ph ần trong ph ần mềm, ví d ụJavaBeans, EJB, .NET

• Các thư viện hàm: các hàm có liên quan, có ch ất lượ ng tốt có th ể đượ c nhóm l ại thànhmột thư viện, vì v ậy chúng luôn s ẵn có. Ví d ụ thư viện stdio, b ắt nguồn từ các hệ thốngUnix, cung c ấ p khảnăng I/O cho các l ậ p trình viên C. Các th ưviện hàm đượ c dùng trongcả việc phát tri ển phần mềm truy ền thống c ũng như phát tri ển phần mềm hướ ng đốitượ ng. Các th ưviện đượ c thiết k ếtốt đôi khi đượ c chuẩn hóa b ở i các tổchức như ISO hayANSI. Các th ư viện hàm có th ể xuất phát t ừ bên trong công ty, s ử dụng miễn phí ho ặc

bán đểkiếm lờ i.• Các thư viện lớ p: là một sựphát tri ển của các th ưviện chức năng, thườ ng là các l ớ p hoàn

chỉnh chứ không đơ n thuần là các hàm. Vi ết một thư viện lớ p đòi hỏi có nhi ều kinhnghiệm. Ví d ụthưviện J2EE, cung c ấ p mã ngu ồn cho t ất cảcác kiểu dùng l ại đượ c liệt kêở trên.

• Mẫu thiết k ế: một mẫu thiết k ế(design pattern) là m ột sựmiêu t ảcách tạo ra các ph ầncủa hệthống H ĐT một cách hi ệu quả. Các b ản mẫu cũng đượ c áp dụng trong các l ĩ nh vựckhác nh ưkiến trúc h ệthống. Mỗi mẫu là m ột miêu t ảngắn, chi ti ết, cho bi ết khi nào dùngnó và code minh h ọa. Thiết k ếcác mẫu đòi hỏi ngườ i có nhi ều kinh nghi ệm, nhưng không

bằng việc tạo ra th ưviện lớ p.

• Framework : là một cấu trúc đã có sẵn đểbạn đưa code vào. Trong tr ườ ng hợ p H ĐT, m ộtframework bao g ồm một số lớ p đượ c viết tr ướ c, cùng v ớ i tài li ệu miêu t ảhướ ng dẫn lậ ptrình viên các quy t ắc phải tuân theo. Ví d ụEJB framework – bao g ồm thưviện J2EE vàtài liệu đặc tả, dài hàng tr ăm trang – ch ỉ ra cách đểlậ p trình viên vi ết đượ c các thành ph ầncó khảnăng dùng l ại, và cách đểcác bên th ứ3 cài đặt máy ch ủ ứng dụng Java. Ph ần lớ ncác framework đượ c thiết k ếbở i các chuyên gia cao c ấ p.

1.8 K ẾT LUẬNChươ ng này đã trình bày khái quát m ột số vấn đềtrong phân tích và thi ết k ếhướ ng đối tượ ng.

Nội dung t ậ p trung vào t ừ những khái ni ệm đơ n giản như đối tượ ng, lớ p… đến những vấn đề phức tạ p nhưxác định quan h ệgiữa các l ớ p. Những khái ni ệm này đã đượ c trình bày theo chu ẩnUML cùng v ớ i những ví d ụminh h ọa. Tuy nhiên, phân tích và thi ết k ếtheo hướ ng đối tượ ng baogồm nhiều vấn đềvà cần sựnghiên c ứu lâu dài c ũng như tr ải nghiệm thực tếmớ i có th ểtr ở thành

17




chuyên gia trong l ĩ nh vực thú v ị này. Các ch ươ ng tiế p theo s ẽgiúp sinh viên hi ểu rõ hơ n nhữngvấn đềnày.

BÀI TẬP1. Sinh viên tìm hi ểu và kh ảo sát các h ệquản lý học tậ p theo tín ch ỉ và sau đó đềxuất các yêu

cầu của hệthống này. Li ệt kê các actor cùng các use case có th ểcó cho h ệthống.2. Hãy ch ọn ra các l ớ p từhệquản lý học tậ p theo tín ch ỉ trong câu 1 và ch ỉ ra các quan h ệgiữa

chúng

3. Hãy thêm các thu ộc tính và các ph ươ ng thức vào các l ớ p chọn đượ c

4. Hãy gi ải thích lý do ch ọn lựa các m ức độtruy nh ậ p các thu ộc tính trên

5. Hãy gi ải thích lý do gán ph ươ ng thức vào các l ớ p

6. Sinh viên có th ểtham kh ảo các tài li ệu trên m ạng đểviết ví dụmột mẫu thiết k ế. Chú ý khitrình bày c ần ghi rõ địa ch ỉ link của tài li ệu

TÀI LIỆU THAM KHẢO THÊM[1] Brett Spell, Pro Java Programming, Second Edition, 2007 .

[2] Data Access Object Patternhttp://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

[3] Object-Oriented Analysis and Design, Understanding System Development

with UML 2.0, Mike O’Docherty, John Wiley, 2005.

[4] J2EE tutorial, http://java.sun.com/

18

http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

http://java.sun.com/

http://java.sun.com/

http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html




19

Documents

Chuong1 - Modau