Đồ án tốt nghiệp
Xây dựng ứng dụng J2EE với
Rational Rose và UML
LE QUANG DUNG
TH40

LỜI NÓI ĐẦU
Nếu như trước đây phần mềm (software) được bán kèm theo máy tính, phần mềm coi
như được cho không thì ngày nay hoàn toàn khác, giá cả phần cứng hạ xuống và phần
mềm dần dần trở nên thống lĩnh. Máy tính trở nên hữu dụng trong mọi mặt của cuộc sống,
sản xuất kinh doanh, khoa học kỹ thuật, quản lý, giáo dục Để có thể áp dụng máy tính
vào những nhu cầu của đời sống xã hội ta phải có các chương trình điều khiển, quản lý,
tính toán và thực hiện các chức năng như mong muốn mà ta gọi đó là phần mềm. Quy trình
để sản xuất được một phần mềm gồm nhiều công đoạn từ phân tích thiết kế, đặc tả yêu câu
khách hàng cho tới lập trình, bảo trì Mỗi công đoạn là cả quá trình đòi hỏi kỹ sư phần
mềm phải khảo sát tỉ mỉ, chính xác trong từng thao tác. Chất lượng phần mềm do khâu
phân tich thiết kế quyết định là chủ yếu, do vậy phân tích thiết kế và đặc tả các yêu cầu là
giai đoạn quan trọng nhất.
Nói đến công nghệ phần mềm chúng ta phảI kể đến các hệ thống phân tán. Trong thời

Trừu tượng hóa bao gồm việc tập trung vào các khía cạnh bản chất cố hữu của một
thực thể và lờ đi các đặc tính phụ của nó. Trong phát triển hệ thống, điều này có nghĩa là
tập trung vào đối tượng là cái gì và làm cái gì, trước khi quyết định nó được cài đặt như thế
nào. Sử dụng trừu tượng hoá giữa quyền thực hiện các quyết định lâu dài nhằm tránh các
ràng buộc vội vã tới các chi tiết. Việc sử dụng trừu tượng hóa trong khi phân tích có nghĩa
là chỉ giải quyết với các khái niệm lĩnh vực ứng dụng, không thực hiện các quyết định thiết
kế và cài đặt trước khi hiểu vấn đề. Sử dụng chính xác trừu tượng hoá cho phép cùng một
mô hình được sử dụng cho cả phân tích, thiết kế mức cao, cấu trúc chương trình, cấu trúc
dữ liệu và tài liệu.
1.1.2. Bọc kín (Encapsulation)
Bọc kín (che giấu thông tin) bao gồm việc phân tách các khía cạnh bên ngoài của đối
tượng, từ các chi tiết cài đặt bên trong của đối tượng. Bọc kín ngăn ngừa một chương trình
trở nên quá phụ thuộc lẫn nhau đến nỗi một thay đổi nhỏ cũng có các hiệu ứng lớn. Việc
cài đặt một đối tượng có thể bị thay đổi mà không ảnh hưởng đến các ứng dụng có dùng
đến nó. Việc bọc kín là không duy nhất đối với các ngôn ngữ hướng đối tượng, nhưng khả
năng kêt hợp cấu trúc dữ liệu và hành vi trong một thực thể đơn thực hiện việc bọc kín là
kỳ diệu hơn so với các ngôn ngữ truyền thống.
1.1.3. Kết hợp dữ liệu và hành vi(data - behavior)
Nơi gọi một thao tác không cần xem xét việc thực hiện thao tác đã cho tồn tại như thế
nào. Đa hình đã di chuyển gánh nặng của việc quyết định sử dụng cài đặt nào từ việc gọi

mã tới phân cấp lớp. Trong một hệ thống hướng đối tượng, phân cấp cấu trúc dữ liệu là
đồng nhất với phân cấp kế thừa thao tác.
1.1.4. Phân chia
Kỹ thuật hướng đối tượng đề xướng việc phân chia tại vài mức khác nhau. Việc kế
thừa cả cấu trúc dữ liệu và hành vi cho phép cấu trúc chung được chia sẻ trong vài lớp con
giống nhau mà không dư thừa. Việc phân chia mã sử dụng kế thừa là một trong những tiến
bộ chính của ngôn ngữ hướng đối tượng.
Phát triển hướng đối tượng không chỉ cho phép chia sẻ thông tin trong ứng dụng mà
còn đưa ra triển vọng của việc sử dụng lại các thiết kế và mã trong các đề án tượng lai.

Chúng ta đưa ra phương pháp phát triển hướng đối tượng và các ký hiệu đồ họa cho
việc biểu diễn các khái niệm hướng đối tượng. Phương pháp bao gồm việc xây dựng một
mô hình của lĩnh vực ứng dụng, sau đó thêm các chi tiết vào nó trong khi thiết kế hệ thống.
Có nhiều phương pháp phân tích và thiết kế hướng đối tượng khác nhau – tiêu biểu là
các phương pháp Booch của Grady Booch, phương pháp OMT (Object Modeling
Technique) của James Rumbaugh, phương pháp OOSE (Object Oriented Software
Engineering) của Ivar Jacobson. Nhìn chung, một cách chắc chắn rằng các phương pháp
này đều bao gồm các bước: phân tích, thiết kế hệ thống, thiết kế đối tượng, cài đặt. Mặc dù
vậy, mỗi phương pháp có cách thức mô hình hoá khác nhau.
Trong đồ án này, em sẽ trình bày phương pháp hướng đối tượng với việc sử dụng ký
pháp của UML để mô hình hoá.
1.4. Lợi ích và sức mạnh của OO
 Cách tiếp cận hướng chức năng
Trước kia chúng ta thường hay sử dụng phương pháp hướng chức năng để xây dựng
hệ thống. Với phương pháp này, dữ liệu và chức năng(hành vi hay xử lý) được tách ra
riêng rẽ. Ở đó, chức năng được coi như là những hành vi có tính chủ động, còn dữ liệu là
bộ phận nắm giữ thông tin một cách bị động và được tác động bởi các chức năng. Hệ thống
được chia thành các chức năng nhỏ dần cho tới khi nó có thể dễ dàng cho việc mã hoá, còn
dữ liệu được gửi giữa các chức năng này. Một hệ thống được phát triển theo cách này
thường trở nên khó bảo trì. Một vấn đề quan trọng với phương pháp hướng chức năng là tất
cả các chức năng phải biết làm thế nào dữ liệu được lưu trữ, cấu trúc dữ liệu của nó. Các
kiểu khác nhau của dữ liệu có những định dạng khác nhau, vì thế việc mã hoá chương trình
trở nên rắc rối. Hơn nữa, khi ta thay đổi cấu trúc dữ liệu, dẫn đến ta phải thay đổi tất cả các

chức năng liên quan đến cấu trúc này. Hệ thống được phát triển theo phương pháp này trở
nên có tính ổn định kém. Một chút thay đổi sẽ gây nên hậu quả nghiêm trọng.
Một vấn đề khác đối với phương pháp hướng chức năng là chúng ta thường không có
những tư duy một cách tự nhiên về cấu trúc của vấn đề nó được cấu tạo như thế nào. Do
vậy việc xây dựng hệ thống trở nên khó khăn hơn.
Một nguyên nhân khác đối với phương pháp hướng chức năng là hệ thống rất khó để

thức (giao tiếp)
 Trực quan hóa hệ thống : được sử dụng để diễn tả hệ thống một cách trực quan trước
khi nó được thực hiện.
 Xây dựng hệ thống : được sử dụng để hiện thực hóa hệ thống.
 Làm sưu liệu : được sử dụng để nắm bắt kiến thức về hệ thống thông qua vòng đời
của nó.
UML không phải là :
 Một ngôn ngữ lập trình trực quan, mà nó là một ngôn ngữ mô hình.
 Một công cụ, mà nó là một ngôn ngữ đặc tả mô hình
 Một xử lý, mà nó cho phép xử lý
UML thích hợp với việc giải quyết vấn đề hướng đối tượng. Bất kì ai quan tâm đến
UML đều quen thuộc với nguyên lý cơ bản về việc giải quyết vấn đề hướng đối tượng, bắt
đầu với việc xây dựng mô hình. Mô hình (model ) là sự trừu tượng hoá vấn đề cơ bản.
Phạm vi (domain ) là thế giới thực mà vấn đề đó mang đến.
Hình 1.1: sự hợp nhất của UML

Mô hình chứa các đối tượng (objects) tác động lẫn nhau bằng cách gởi các thông tin
(messages) khác nhau. Nếu một đối tượng đang tồn tại thì đối tượng đó có thuộc tính
(attributes) và có các hành vi (behaviors hoặc operations). Giá trị của các thuộc tính trong
đối tượng được xác định bởi trạng thái của nó (state).
Lớp (Classes) là bảng thiết kế cho các đối tượng. Lớp bao gồm các thuộc tính (dữ liệu)
và các hành vi (phương thức hoặc hàm) trong một thực thể riêng biệt đơn giản. Các đối
tượng là các thể hiện (instance) của các lớp.
1.5.1. Các đặc điểm của UML
Bốn đặc điểm chính của UML để có thể phân biệt với các ngôn ngữ mô hình khác :
 Đa năng (general-purpose)
 Khả năng ứng dụng rộng rãi (broadly applicable)
 Được hỗ trợ bởi các công cụ (tool- supported)
 Là một chuẩn công nghiệp (industrial standerdized)
1.5.2 Kiến trúc tổng quát của UML

 Logical View
Lược đồ lớp (Class Diagram) : mô tả cấu trúc tĩnh của hệ thống thể hiện các phần mà
hệ thống có thể xử lý được.
Lược đồ đối tượng (Object Diagram): mô tả cấu trúc tĩnh của hệ thống tại một thời
điểm, nó có thể xem như một thể hiện của lược đồ lớp.
 Process View
Lược đồ tuần tự ( Sequence Diagram ) :Mô tả sự tương tác giữa các thành phần trong
hệ thống theo thời gian.
Lược đồ cộng tác (Collaboration Diagram) : mô tả sự tương tác giữa các thành phần
trong hệ thống theo thời gian và không gian.
Lược đồ trạng thái (State Diagram) : mô tả trạng thái, sự hồi đáp của một thành phần
trong hệ thống khi có những tác động vào nó.
Lược đồ hoạt động (Activity Diagram) : mô tả sự hoạt động của các thành phần trong
hệ thống.
 Implementation View
Lược đồ thành phần (Component) : mô tả tổ chức của các thành phần thực thi trong hệ
thống.
 Invironmen View
Lược đồ triển khai (Deployment Diagram) : mô tả cấu hình của các thành phần môi
trường và trình tự của các thành phần thực thi trên đó.
1.5.3. Các lược đồ trong UML
Trọng tâm của việc giải quyết vấn đề hướng đối tượng là xây dựng một mô hình. Mô
hình trừu tượng hóa các chi tiết cần thiết của vấn đề cơ bản về thế giới thực. Trọng tâm
của UML được thể hiện qua 8 loại lược đồ khác nhau :
 Use case diagrams (Lược đồ Use case)
 Class diagrams (Lược đồ lớp)

 Sequence diagrams (Lược đồ tuần tự)
 Collaboration diagrams (Lược đồ cộng tác)
 Statechart diagrams (Lược đồ trạng thái)

 Phát sinh các trường hợp test : tập hợp các sự kiện cho một use case có thể đề
nghị các trường hợp cho các sự kiện này.
Chi tiết lược đồ Use case
Lược đồ Use case phát hoạ tổng quan của hệ thống. Mỗi lược đồ Use case có các actor,
các use case, các quan hệ. Một lược đồ Use case đơn giản được mở rộng với các đặc trưng
thêm vào để hiển thị thông tin hơn (hình 1.6).
Các đặc trưng của lược đồ Use case
 system boundaries (kết hợp hệ thống)
 generalizations (tổng quát hoá)
 includes (bao hàm)
 extensions (mở rộng) Hình 1.6: lược đồ use case mở rộng
Lược đồ Use case mở rộng lược đồ với các đặc trưng thêm vào.
Hình chữ nhật kết hợp hệ thống ( system boundary ) phân chia hệ thống từ các actor
mở rộng.
Tổng quát hoá (generalization) use case biểu diễn rằng một use case là một loại đặc
biệt đơn giản khác.Pay Bill là use case cha và Bill Insurance là use case con .Use case con
được thay thế bởi use case cha bất cứ khi nào cần thiết. Sự tổng quát hoá xuất hiện như
một dòng với mũi tên hình tam giác ở đầu hướng về use case cha.
Quan hệ bao hàm ( Include ) quản lý use case thành use case thêm vào.Quan hệ bao
hàm hữu ích khi cùng use case được phân chia thành hai use case khác nhau. Cả Make
Appointment và Request Medication quan hệ bao hàm với như công việc con. Trong
lược đồ, kí hiệu bao hàm là đường gạch đứt, bắt đầu ở use case cơ sở và kết thúc với mũi
tên đến use case bao hàm. Đường gạch đứt được gán nhãn <<include>>.
Quan hệ mở rộng (extend) chỉ ra một use case là một biến đổi của use case khác. Kí
hiệu quan hệ mở rộng là đường gạch đứt, có nhãn là <<extend>> và một mũi tên hướng về
use case cơ sở. Điểm mở rộng (extension point) được xác định khi use case mở rộng là
thích hợp và được viết bên trong use case cơ sở.

khác. Bản số là một số hoặc một dãy số. Ví dụ : một Order chỉ có một Customer, nhưng
một Customer có nhiều Orders.

Bản số Giải thích
0 1
0 hoặc 1 thể hiện.
0 * hoặc *
Không giới hạn số thể hiện
1
Chính xác 1 thể hiện
1 *
Ít nhất 1 thể hiện

Hình 1.7: bản số trong lược đồ lớp
Mỗi lược đồ lớp có các lớp, các quan hệ, và các bản số. Tính định hướng và các vai trò
là các mẫu tuỳ chọn đặt trong lược đồ để làm sáng tỏ.
Chi tiết lược đồ lớp Lược đồ lớp gồm các lớp, các liên kết, các bản số. Lược đồ lớp có thể
biểu diễn nhiều thông tin.
 compositions (thành phần)
 class member visibility and scope (phạm vi và tầm vực của lớp thành viên)
 dependencies and constraints (phụ thuộc và ràng buộc)
 interfaces (giao diện)
Composition and aggregation (Thành phần và thu nạp)
Quan hệ kết hợp trong đối tượng là phần mở rộng của quan hệ thu nạp. Thành phần
(Composition ) là quan hệ kết hợp với phần (part) thuộc về toàn bộ (whole), phần không

tồn tại nếu không có toàn bộ. Thành phần được hiển thị bởi hình thoi đặc ở phía cuối toàn
bộ.
Trong lược đồ này biểu diễn rằng, một BoxOffice thuộc về một MovieTheater.Nếu
bỏ MovieTheater thì sẽ huỷ BoxOffice. T

SessionTalk). ShuttleSchedule với danh sách các ShuttleStop là phần quan trọng để đăng
kí ở tại khách sạn. Trong lược đồ có một ràng buộc, ShuttleStop được phân cấp.
Có ba giao diện trong lược đồ : IDated, ILocatable, và ITimed. Tên của giao diện bắt
đầu bằng kí tự I và đi kèm với các phương thức trừu tượng được viết bằng chữ nghiêng.
Một lớp như lớp ShuttleStop, với các phương thức kết hợp trong giao diện như
ILocatable, là implementation ( hoặc realization ) của giao diện.

Lớp ShuttleStop có kiểu mẫu ( stereotype ) << place>>. Kiểu mẫu qui định phương
pháp mở rộng UML, là thành phần mô hình mới được tạo từ các kiểu tồn tại. Tên kiểu mẫu
được viết trên tên lớp. Giao diện là một loại đặc biệt của kiểu mẫu.
Có hai cách kí hiệu giao diện trong UML : một là kí hiệu như trên, hai là kí hiệu hình
que hoặc hình tròn.
Trong hình tròn chú thích, giao diện là hình tròn với đường thẳng kết nối đến lớp thi
hành.

Hình 1.11:các lớp giao diện trong lược đồ.

Hình 1.12: các lớp giao diện và khuôn mẫu
Packages (Gói) và objects (Đối tượng)

Để tổ chức các lược đồ lớp phức tạp, ta có thể nhóm các lớp phức tạp vào trong các gói
(packages). Một gói là một tập hợp các thành phần UML liên quan. Lược đồ dưới đây là
một mô hình nghiệp vụ với các lớp được nhóm vào các gói. Các gói có dạng hình chữ nhật
với các nhãn (tab)ở đầu. Tên gói trong nhãn hoặc trong hình chữ nhật. Đường gạch nối là
quan hệ phụ thuộc (dependencies). Một gói phụ thuộc vào một gói khác nếu sự thay đổi
của gói khác có ảnh hưởng đến sự thay đổi ngay lúc đầu.
Hình 1.13: lược đồ thành phần
1.5.3.3. Object diagrams (Lược đồ đối tượng) là một loại đặc biệt của lược đồ lớp, biểu
diễn các thể hiện thay vì các lớp. Chúng dùng để giải thích các mối quan hệ phức tạp, đặc
biệt là quan hệ đệ qui.

tạo công việc đặt chổ (Reservation) và thừ nhận việc đặt chổ này (Confirmation). Dấu
hoa thị trong self call có nghĩa lặp lại ( iteration ) để chắc chắn rằng có phòng để ở mỗi
ngày trong khách sạn. Biểu thức trong dấu ngoặc đơn là điều kiện ( condition ).
Lược đồ có một thông báo (note) để giải thích, đó là đoạn văn bản ở trong hình chữ
nhật có nếp quăn ở góc. Thông báo có thể đặt vào trong bất kì lược đồ UML nào.
1.5.3.5. Collaboration diagrams (Lược đồ cộng tác)
Collaboration diagrams cũng là lược đồ tương tác. Chúng chuyển thông tin giống
nhau như lược đồ tuần tự, nhưng chúng tập trung vào vai trò đối tượng thay vì thời gian mà
thông điệp đó gởi đến. Trong lược đồ tuần tự, vai trò đối tượng là các đỉnh và thông điệp
được kết nối.

Hình 1.17: lược đồ cộng tác
Hình chữ nhật của vai trò đối tượng được ghi trong lớp hoặc tên đối tượng hoặc cả hai.
Tên lớp được đặt trước dấu hai chấm ( : ).
Mỗi thông điệp trong lược đồ cộng tác có số tuần tự (sequence number).Thông điệp
đầu tiên được đánh số 1.
1.5.3.6. Statechart diagrams (Lược đồ trạng thái)
Các đối tượng có các hành vi và trạng thái. Trạng thái của đối tượng phụ thuộc vào
hoạt động hoặc điều kiện hiện hành. Lược đồ trạng thái (statechart diagram) hiển thị các
trạng thái của đối tượng và các biến đổi trong trạng thái.

Trong lược đồ ví dụ, mô hình đăng nhập vào hệ thống ngân hàng trên mạng.Trước hết,
đăng nhập vào số mật khẩu và số ID của người đó, sau đó submit thông tin để xác nhận.
Đăng nhập có thể thực hiện trong 4 trạng thái không trùng lắp sau :Getting SSN,
Getting PIN, Validating (tính hợp lệ), và Rejecting (loại bỏ). Từ mỗi trạng thái đến một
số chuyển tiếp(transitions) hoàn toàn, xác định được trạng thái kế tiếp.

Hình 1.18: lược đồ trạng thái
Các trạng thái được khoanh tròn trong hình chữ nhật. Các chuyển tiếp theo hướng mũi
tên từ trạng thái này đến trạng thái khác. Các sự kiện hoặc các điều kiện được viết bên

Biểu tượng Ý nghĩa
Thông điệp có thể đồng bộ hoặc không đồng bộ
Thông điệp phản hồi (không bắt buộc)
Thông điệp đồng bộ

Thông điệp không đồng bộ

Hình 1.20: các qui ước thông điệp của UML
Trùng lắp và không đồng bộ trong lược đồ trạng thái
Các trạng thái trong lược đồ trạng thái có thể lồng nhau. Quan hệ các trạng thái có thể
nhóm cùng trong một trạng thái hoàn chỉnh (composite state) đơn lẻ. Các trạng thái lồng
nhau thì cần thiết khi một hoạt động liện quan đến các hoạt động con trùng lắp hoặc không
đồng bộ.
Lược đồ trạng thái dưới đây có hai tiểu trình trùng lắp dẫn vào hai trạng thái con của
trạng thái hoàn chỉnh Auction: Bidding và Authorizing Credit. Bidding là trạng thái
hoàn chỉnh với ba trạng thái con.Authorizing Credit có hai trạng thái con.
Auction yêu cầu phân nhánh ở đầu vào thành hai tiểu trình riêng biệt. Trừ khi có một
tồn tại khác thường (như Cancelled hoặc Rejected), sự tồn tại từ trạng thái hoàn chỉnh
Auction diễn ra khi cả các trạng thái con đang tồn tại.

Hình 1.21: trùng lắp và không đồng bộ trong lược đồ trạng thái
1.5.3.7. Activity diagrams (Lược đồ hoạt động) activity diagram là một biểu đồ tiến trình (flowchart). Lược đồ hoạt động và lược đồ
trạng thái có quan hệ với nhau. Khi lược đồ trạng thái tập trung vào một đối tượng thông
qua một quá trình, lược đồ hoạt động tập trung vào luồng hoạt động liên quan đến một tiến