Tải bản đầy đủ - 72 (trang)
GIỚI THIỆU CÔNG NGHỆ 2 GIỚI THIỆU VỀ J2EE

GIỚI THIỆU CÔNG NGHỆ 2 GIỚI THIỆU VỀ J2EE

Tải bản đầy đủ - 72trang

Trang 2

PHẦN I GIỚI THIỆU CÔNG NGHỆ


CHƯƠNG 1 GIỚI THIỆU VỀ PHÂN TÍCH VÀ THIẾT KẾ HƯỚNG ĐỐI TƯỢNG VỚI UML


Mơ hình hóa và thiết kế hướng đối tượng là một cách suy nghĩ về vấn đề sử dụng các mơ hình được tổ chức xung quanh các khái niệm thế giới thực. Cấu trúc
nền tảng là đối tượng, nó kết hợp cả cấu trúc dữ liệu và hành vi vào trong một thực thể đơn. Các mơ hình hướng đối tượng là có ích cho việc hiểu vấn đề, việc
trao đổi với người dùng, mơ hình hố các tổ chức kinh doanh, chuẩn bị tài liệu và thiết kế chương trình cùng cơ sở dữ liệu.
1.1. Các nguyên tắc cơ bản của OO-Object Orientation 1.1.1. Trừu tượng hóa Abstraction
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 hố 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 ngồ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 q 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 vidata - 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.
Trang 3

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. Phát triển hướng đối tượng cung cấp các công cụ như là trừu
tượng bọc kín, kế thừa để xây dựng các thư viện của các thành phần có thể dùng lại được.
1.2. Các khái niệm cơ bản của hướng đối tượng Khi nói về hướng đối tượng, các khái niệm cơ bản sau đây cần được hiểu rõ:
• Đối tượng Object • Lớp Class
• Thuộc tính Atribute • Thao tác Operation
• Giao tiếp – đa hình Interface - Polymorphism • Thành phần Component
• Đóng gói Package • Hệ thống con Subsystem
• Quan hệ Relationship Tất cả các khái niệm này được trình bày trong phần “tổng quan về UML” ở
phần sau. 1.3. Phát triển hướng đối tượng là gì?
Phát triển hướng đối tượng là một cách suy nghĩ mới về phần mềm đặt cơ sở trên những khái niệm trừu tượng đang tồn tại trong thế giới thực. Bản chất của
việc phát triển hướng đối tượng là nhận biết và tổ chức các khái niệm thuộc lĩnh vực ứng dụng.

1.3.1. Các khái niệm mơ hình hố


Các ngơn ngữ lập trình hướng đối tượng là có ích trong việc loại bỏ các hạn chế do tính khơng mềm dẻo của các ngơn ngữ lập trình truyền thống.
Phát triển hướng đối tượng là quá trình nhận thức độc lập với ngơn ngữ lập trình cho đến các bước cuối cùng. Phát triển hướng đối tượng là hướng suy nghĩ
mới và khơng là kỹ thuật lập trình. Lợi ích của vấn đề này là giúp các chuyên gia, phát triển viên và khách hàng biểu lộ các khái niệm trừu tượng một cách rõ ràng
và truyền gởi chúng tới nơi khác. Nó có thể phục vụ như là một trung gian cho việc xác định, phân tích, lập tài liệu và giao tiếp cũng như việc lập trình.

1.3.2. Phương pháp hướng đốI tượng


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.
Trang 4 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 hố 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 hố.

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ănghà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ã hố, 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ã hố 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ó để sửa đổi, tính khả chuyển kém, nhạy cảm với sự thay đổi, vì dữ liệu và hành vi bị tách riêng.
• Cách tiếp cận hướng đối tượng
Việc phát triển hệ thống theo cách tiếp cận hướng đối tượng sẽ mang lại cho ta nhiều lợi ích, tiêu biểu là:
- Giảm chi phí bảo trì: bởi vì hầu hết các xử lý trong hệ thống được bọc kín - dữ liệu và hành vi được gom chung lại, các hành vi có thể được sử dụng lại và kết
hợp thành các hành vi mới. - Mơ hình thế giới thực: hệ thống hướng đối tượng là định hướng để mô hình
thế giới thực. Các đối tượng được tổ chức thành các lớp đối tượng, và các đối tượng được kết hợp với các hành vi. Mơ hình dựa trên đối tượng hơn là dựa trên
dữ liệu và xử lý. Cách thức này gần gũi với tư duy con người, do vậy việc xây dựng dễ dàng hơn.
- Tính tin cậy cao: bởi vì các hành vi mới được xây dựng từ các đối tượng đã có sẵn.
- Khả năng sử dụng lại mã nguồn cao: bởi cơ chế kết hợp dữ liệu với hành vi vào một đối tượng riêng biệt, cơ chế đóng gói, cơ chế bọc kín. Do vậy, dễ dàng
cho việc kế thừa, hay sử dụng lại.
Trang 5

1.5. Tổng quan về UML


UML được viết tắt của cụm từ Unified Modeling Language, tạm dịch là ngơn ngữ mơ hình hợp nhất.
UML là thế hệ kế vị của làn sóng phân tích và thiết kế hướng đối tượng OOA D xuất hiện trong những năm đầu 80 và cuối những năm 90. UML phát triển
trên sự hợp nhất trong các phương pháp của tác giả Booch, Rumbaugh OMT và Jacopson, và đã được chuẩn hóa bởi OGM.
UML được gọi là một ngơn ngữ mơ hình hóa dùng để đặc tả, trực quan hóa dùng để xây dựng và làm sưu liệu cho các hệ thống phần mềm
• Mơ hình hóa : giúp cho chúng ta hiểu được thế giới thực, mơ hình hóa thế giới thực để có thể hiểu được những đặc trưng, tính tốn các thông số và dự
đ ốn kết quả sẽ đạt được.
• Ngơn ngữ : Chức năng của UML như là một phương tiện để bày tỏ và trao đổ
i tri 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
hố 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
Trang 6 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 qt của UML aCác mơ hình .


Xét về đặc điểm tĩnh, các mơ hình nắm bắt một số đặc điểm và hành vi của hệ thống.
Xét về đặc điểm động, nắm bắt các đặc điểm của hệ thống, về cơ bản chúng lưu trữ các tri thức về mặt ngữ nghĩa.
b Cấu trúc View
Ngày nay các hệ thống phần mềm càng trở nên phức tạp, khó khăn do vậy ta khơng thể mơ hình hóa chúng chỉ bằng một lược đồ hay mơ hình. Hệ thống phải
đượ c phân tích dưới nhiều góc độ khác nhau. UML đưa ra định nghĩa về cấu trúc
View. Mỗi View là một thể hiện của hệ thống dưới một khía cạnh nào đó. Mỗi View có thể bao gồm nhiều loại lược đồ khác nhau xem hình 1.2
• Use Case View hay còn gọi là Use model view thể hiện các vấn đề về
giải pháp liên quan đến chức năng tổng quát của hệ thống. •
Logical View hay còn gọi là Structure Model view hoặc Static view: thể hiện các vấn đề liên quan đến cấu trúc thiết kế hệ thống.
Trang 7 Hình 1.2 : cấu trúc View trong UML
• Process View hay còn gọi là bihavioral model view, Dynamic hay Collaboration View thể hiện các vấn đề liên quan đến xử lý giao tiếp và
đồ ng bộ trong hệ thống.
• Deployment View hay còn gọi là Environment model View : thể hiện các vấn đề liên quan đến việc triển khai hệ thống.
• Một số model View khác có thể được sử dụng khi cần thiết.
c Các lược đồ. Lược đồ miêu tả các tri thức về mặt cú pháp được miêu tả quanh cấu trúc, Hình 1.3
Hình 1.3 : Các lược đồ của UML
Trang 8
♦ Use Case View Lược đồ người sử dụng Use Case Diagram : Mô tả các chức năng của hệ
thống. Lược đồ Use Case diễn tả các Use Case trong hệ thống và các quan hệ ràng buộc…
♦ 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
• Activity diagrams Lược đồ hoạt động • Component diagrams Lược đồ thành phần
• Deployment diagrams Lược đồ triển khai
1.5.3.1. Use case diagrams Lược đồ use case Use case diagrams mô tả hệ thống làm gì từ quan điểm của người quan sát
tổng quan. Điều quan trọng là nhấn mạnh hệ thống làm gì hơn là làm như thế nào.
Trang 9 Lược đồ Use case quan hệ gần gũi đến các sự kiện. Sự kiện scenario là
những gì xảy ra khi ai đó tương tác với hệ thống. Đây là sự kiện về một khoa y học: một bệnh nhân gọi phòng khám để hẹn gặp cho việc kiểm tra hàng năm.
Người tiếp tân tìm thời gian trống gần nhất trong sổ hẹn gặp và lịch hẹn gặp cho thời qian đó.
Use case là tập hợp các sự kiện về một công việc đơn giản hoặc mục đích của nó. actor là người tham gia vào các sự kiện trong phiên làm việc. Actor đóng
vai trò là người hoặc đối tượng hoạt động. Hình dưới là mơ tả use case là Make Appointment, actor là Patient. Mối liên hệ giữa use case và actor là mội quan hệ
kết hợp communication association gọi tắt là communication .
Hình 1.4: actor và use case Actor có hình que, Use case có hình bầu dục, mối quan hệ là đường thẳng liên
kết giữa actor và use case. Lược đồ use case là tập hợp các actor, các use case, các mối quan hệ giữa
chúng. Hình vẽ dưới cho ta 4 use case và 4 actor. Chú ý rằng một use case đơn giản có thể có nhiều actor.
Hình 1.5: lược đồ use case Lược đồ Use case hổ trợ 3 phạm vi sau :
• Xác định các đặc trưng : Use case mới thường thường phát sinh các yêu
cầu mới khi hệ thống phân tích và đưa ra các mơ hình.
• Giao tiếp với clients : các kí hiệu đơn giản giúp cho lược đồ use case có
thể giao tiếp với client.
• 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.
Trang 10
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 qt hố
• 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
Trang 11 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ở. 1.5.3.2. Class diagrams Lược đồ lớp
Class diagram đưa ra tổng quan hệ thống bằng cách hiển thị các lớp và quan
hệ giữa chúng. Lược đồ lớp là lược đồ tĩnh, hiển thị những gì tác động nhưng không xảy ra
những gì khi chúng tác động.
Lược đồ lớp dưới đây mơ tả một khách hàng đặt hàng. Lớp chính là Order, kết hợp với nó là Customer và Payment. Payment là một trong 3 loại : Cash,
Check, hoặc Credit. Order chứa OrderDetails và kết hợp với Item.
Hình 1.6:lược đồ lớp Lược đồ lớp có 3 loại quan hệ :
• association quan hệ kết hợp -- một quan hệ giữa các thể hiện của 2 lớp.
Đ ây là một quan hệ kết hợp giữa hai lớp nếu một thể hiện của một lớp phải biết
đế n thể hiện khác làm việc với nó. Trong một lược đồ, một quan hệ kết hợp là một
liên kết, kết nối đến hai lớp.
• aggregation quan hệ thu nạp-- mối kết hợp trong một lớp thuộc về một
tập hợp. Một quan hệ thu nạp có một hình thoi cuối điểm được xem là tồn thể.
Trong lược đồ này,Order có một tập hợp là OrderDetails. • generalization quan hệ tổng quát hoá-- mối liên kết kế thừa diển tả một
lớp là một lớp cha superclass của lớp khác. Quan hệ tổng qt hố có một hình tam giác biểu diễn lớp cha. Payment là lớp cha của Cash, Check, và Credit.
Một mối kết hợp có hai đầu giới hạn. Một đầu có thể có một tên vai trò role name để lọc ra tính tự nhiên của mối kết hợp. Ví dụ,OrderDetail là một đường
mẫu của Order. navigability tính định hướng : mũi tên trong quan hệ kết hợp hiển thị hướng
quan hệ có thể xem xét và truy vấn. OrderDetail có thể truy vấn về mẫu Item của nó nhưng khơng thơng qua cách khác. Trong trường hợp này, OrderDetail có
Item. Quan hệ kết hợp có mũi tên có tính định hướng .
Trang 12
multiplicity bản số của một đầu quan hệ là số thể hiện của lớp kết hợp với một đầu 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ó tồ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
Hình 1.8:lược đồ thành phần và thu nạp
Lớp thơng tin: tầm vực visibility và phạm vi scope
Trang 13 Chú thích lớp là một hình chữ nhật gồm 3 phần : tên lớp, thuộc tính
attributes và phương thức operations. Thuộc tính và phương thức được gán
theo phương thức truy xuất và phạm vi.
Hình 1.9 : lớp thông tin tầm vự và phạm vi Ví dụ minh hoạ cách sử dụng theo qui ước UML.
• Thành viên tĩnh được gạch dưới. Thành viên làm ví dụ thì khơng. • Phương
thức đượ
c trình
bày như
sau :
access specifier name parameter list : return type
• Danh sách thông số parameter list hiển thị mỗi kiểu thông số sau dấu hai
chấm Dependencies and constraints Phụ thuộc và ràng buộc
Phụ thuộc dependency là mối quan hệ giữa hai lớp mà thay đổi lớp này có
thể ảnh hưởng đến lớp khác. Phụ thuộc được vẽ như đường gạch đứt. Trong
lược đồ lớp Co op dưới đây phụ thuộc vào Company. Nếu thay đổi Company thì phải thay đổi Co op.
Trang 14 Hình 1.10: quan hệ phụ thuộc và ràng buộc trong lược đồ lớp
Ràng buộc constraint là điều kiện mà mỗi thực thi về thiết kế phải hoàn
thành. Ràng buộc được biểu diễn dưới hai dấu ngoặc mốc {}. Ràng buộc trong
lược đồ trên chỉ ra rằng một Section có thể là một phần của CourseSchedule.. Interfaces Giao diện và stereotypes Khuôn mẫu
Giao diện interface là một tập hợp các kí hiệu hoạt động. Trong C++, giao
diện được thực hiện như các lớp trừu tượng với các thành viên ảo. Trong Java chúng được thực hiện trực tiếp.
Lược đồ lớp dưới đây là một mơ hình về hội nghị nghề nghiệp. Lớp liên quan đế
n hội nghị là SessionTalk một bảng trình bày đơn giản và Session tập hợp liên quan đến 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 đồ.
Trang 15 Hình 1.12: các lớp giao diện và khn 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.
Lược đồ lớp dưới đây hiển thị một Department có thể chứa nhiều Departments khác.
Trang 16 Hình 1.14: lược đồ lớp thể hiện quan hệ đệ qui
Lược đồ đối tượng dưới đây giải thích lược đồ lớp.
Hình 1.15: lược đồ đốI tượng Mỗi hình chữ nhật trong lược đồ tương ứng với một thể hiện. Tên thể hiện
đượ c gạch dưới trong lược đồ UML. Tên lớp hoặc tên thể hiện có thể được loại
bỏ từ lược đồ đối tượng nhưng ý nghĩa lược đồ vẫn rõ. 1.5.3.4. Sequence diagrams Lược đồ tuần tự
Lược đồ lớp và lược đồ đối tượng là các cấu trúc view mơ hình tĩnh. Lược đồ
tương tác Interaction diagrams là cấu trúc động, mô tả các đối tượng cộng tác
như thế nào.
Lược đồ tuần tự sequence diagram là lược đồ tương tác
diễn tả các phương thức operations hoạt động như thế nào, thông điệp nào được gởi đến
và khi nào. Lược đồ tuần tự được tổ chức theo thời gian. Các đối tượng liên quan đế
n phương thức được liệt kê từ trái sang phải khi chúng tham gia vào thông điệp tuần tự.
Dưới đây là lược đồ tuần tự cho việc đặt chổ khách sạn. Đối tượng bắt đầu
các thông điệp tuần tự là Reservation window.
Trang 17 Hình 1.16: lược đồ tuần tự
Reservation window gởi một thông điệp makeReservationđến HotelChain. Sau đó HotelChain gởi một thơng điệp makeReservation đến Hotel. Nếu Hotel
có phòng, thì nó sẽ đặt chỗ Reservation thừa nhận việc đặt chổ này Confirmation .
Đườ
ng nét đứt gọi là lifeline, biểu diễn thời gian mà đối tượng đang tồn tại. Mỗi mũi tên là một thông điệp gọi. Mũi tên đi từ người gởi đến đỉnh activation bar
của thông điệp trong lifeline của người nhận. Activation bar biểu diễn khoảng thời gian thực thi thơng điệp.
Trong lược đồ ví dụ, Hotel sử dụng selfcall để quyết định nếu có phòng. Khi
đ
ó Hotel 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.
Trang 18 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ếptransitions hoàn toàn, xác định được trạng thái kế tiếp.
Trang 19 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 cạnh mũi tên. Trạng thái ban đầu hình tròn đen là một động tác giả để bắt đầu hoạt động.
Trạng thái cuối cùng cũng là trạng thái giả để kết thúc hoạt động. Hoạt động diễn ra khi kết quả của một sự kiện hoặc điều kiện được nhấn mạnh
trong phần trình bày hay trong hành động. Trong khi ở trạng thái hợp lệ , đối tượng khơng chờ một sự kiện bên ngồi đến một trigger chuyển đổi thay vì trình
bày một hoạt động. Kết quả của hoạt động được xác định ở trạng thái kế tiếp. Tiến trình khơng đồng bộ hoặc trùng lắp
Lược đồ tuần tự, lược đồ cộng tác, lược đồ hoạt động, lược đồ trạng thái là các cấu trúc mô hình động. Chúng cho ta thấy được cấu trúc bên trong mơ hình.
Lược đồ tuần tự và lược đồ cộng tác tập trung vào các thông điệp liên quan đến việc hồn tất một tiến trình đơn lẻ. Lược đồ trạng thái tập trung vào một đối tượng
đơ n lẻ. Lược đồ hoạt động tập trung vào luồng hoạt động trong công việc đơn lẻ.
Sau đây là phần trình bày về các hoạt động không đồng bộ hoặc trùng lắp của lược đồ tuần tự và lược đồ trạng thái .
Lược đồ tuần tự với thông điệp không đồng bộ
Thông điệp gọi là không đồng bộ asynchronous nếu nó cho phép gởi thêm
các thông điệp trong khi thông điệp ban đầu vẫn còn đang xử lý. Thời gian của một thông điệp không đồng bộ độc lập với thời gian các thông điệp xen vào.
Lược đồ tuần tự dưới đây minh hoạ hoạt động của một y tá yêu cầu kiểm tra
chuẩn đốn ở phòng mạch. Có hai thộng diệp khơng đồng bộ từ Nurse :
Trang 20 Hình 1.19 : lược đồ tuần tự với thông điệp không đồng bộ
1 u cầu phòng mạch MedicalLab đăng kí ngày để kiểm tra. 2 yêu cầu công ty bảo hiểm InsuranceCompany chấp thuận kiểm tra.
Yêu cầu của các thông điệp này được gởi hoặc được thực hiện khơng thích
hợp. Nếu InsuranceCompany chấp nhận kiểm tra thì sẽ lên lịch kiểm tra trong ngày được cung cấp bởi MedicalLab.
UML sử dụng các qui ước thông điệp sau : 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.
Trang 21
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 trình đơn. Lược đồ hoạt động biểu diễn có nhiều hoạt độ
ng này phụ thuộc vào nhiều hoạt động khác. Ví dụ chúng ta sử dụng theo tiến tình:Rút tiền ra khỏi ngân hàng thơng qua
ATM
Ba lớp liên quan đến hoạt động Customer, ATM, và Bank.Tiến trình bắt đầu ở
hình tròn đen đầu tiên phía trên và kết thúc ở hình tròn trắng trọng tâm là màu đen phía dưới.
Lược đồ hoạt động có thể phân chia thành đối tượng swimlanes để xác định đố
i tượng nào liên quan đến hoạt động này. Một chuyển đổi transition đơn giản
ra khỏi hành động để kết nối đến hành động khác. Một chuyển đổi có thể tách ra thành hai hay nhiều chuyển đổi riêng biệt qua
lại. Biểu thức chắn Guard expressions bên trong dấu [] chuyển đổi ra khỏi một nhánh. Một nhánh và nhánh kế tiếp của nó kết hợp để đánh dấu nhánh cuối xuất
hiện trong lược đồ dưới dạng hình thoi rỗng. Một chuyển đổi có thể phân nhánh thành hai hay nhiều hoạt động song song.
Sự phân nhánh và sự kết hợp các tiểu trình tiếp theo ra khỏiphân nhánh xuất hiện trong lược đồ như thanh rắn.
Trang 22 Hình 1.22: lược đồ hoạt động
Trang 23

CHƯƠNG 2 GIỚI THIỆU VỀ J2EE


Java 2 Platform Enterprise Edition 2.1. Giới thiệu sơ lược về J2EE System
J2EE là nền để phát triển các ứng dụng phần mềm phân tán của hãng. Từ lúc bắt đầu của ngơn ngữ java, nó đã thích nghi và phát triển tốt. Ngày càng nhiều
cơng nghệ đã trở thành một phần của nền Java, các API và các chuẩn mới được phát triển đến nhiều địa chỉ cần thiết. Sau cùng, Sun và 1 nhóm nhà lãnh đạo
công nghiệp, dưới sự bảo trợ của open Java Community ProcessJCP hợp nhất tất cả các chuẩn liên quan đến hãng vào nền J2EE
Một hệ thống J2EE về tổng quát có thể bao gồm 3 máy logic như sau: máy dùng cho Client, máy J2EE Server, máy dùng cho Database Server. Xét về các
lớp để xây dựng ứng dụng thì bao gồm 4 lớp chính: client tier, web tier, business tier và EIS tier.hình 2.1
Hình 2.1:tổng quát các máy logic của J2EE
Client tier: Application clients: là ứng dụng client thực thi trên máy client logic và
chuẩn bị trước một số cách thức để cho user có thể giao tiếp hệ thống J2EE để thực hiện một cơng việc nào đó. Cách thức giao tiếp có thể là thơng qua giao diện
đồ họa hoặc dòng lệnh.
Application client có thể truy xuất trực tiếp đến các EJB của lớp Business hoặc có thể thể thiết lập một kết nối HTTP đến các servlet của lớp Web.
Web Browsers: là môi trường để thực thi các ứng dụng trên web của máy
logic client
Trang 24
Applets: cũng là một hình thức của application client nhưng được thiết kế để
đượ c download xuống và thực thi trên Java VM của Web Browser, do đó khả
năng của Applet được khống chế bởi Web Browser.
JavaBeans component: client cũng có thể bao gồm một số JavaBean để
quản lý dòng data giao tiếp giữa các application client hoặc applet để giao tiếp với các component thực thi trên J2EE server.
Sau đây là sơ đồ giao tiếp giữa Client tier và J2EE server:
Hình 2.2: sơ đồ giao tiếp giữa Client tier và J2EE server
Web tier:
Bao gồm các trang JSP và các servlet và có thể có các JavaBean để quản lý các dòng dữ liệu giữa các web components và business tier của hệ thống J2EE.
Hình2.3:sơ đồ tầng Web tier
Business tier:
Business tier là một lớp logic dùng để thực hiện việc xử lý của hệ thống J2EE server.
Trang 25 Hình2.4: sơ đồ tầng Business tier.
Hình vẽ minh họa cho ta thấy 1 Enterprise Bean có thể nhận dữ liệu từ client, xử lý nó nếu cần thiết và gửi nó đến EIS tier Enterprise Information System tier
để lưu trữ. 1 Enterprise Bean cũng có thể nhận dữ liệu từ EIS tier, xử lý dữ liệu
đ ó nếu cần thiết và sau đó là gửi nó trở lại các chương trình client.
Có 3 loại Enterprise Bean: session bean, entity bean, message-driven bean. Session Bean thể hiện cho một phiên dao dịch với client, với 1 client sẽ có 1
instance của session bean tương ứng, và instance này có thể lưu giữ các thơng tin của client đó. Tuy nhiên, khi phiên giao dịch kết thúc client kết thúc việc thực
thi, các instance này cũng sẽ bị hủy. Ngược lại với session bean, entity bean có thể lưu giữ lâu dài các thơng tin về client. Còn message-driven bean là sự kết hợp
giữa sesssion bean và JMS message listener. Enterprise Information System tier EIS tier:
Lớp này thực hiện việc lưu trữ dữ liệu cho hệ thống J2EE, bao gồm cả các interface để giao tiếp với các Database khác nhau, và giữa các OS khác nhau
trong việc quản lý và lưu trữ file… Kiến trúc tổng thể của một hệ thống J2EE:
EJB container Enterprise JavaBean container quản lý việc thực thi của tất
cả các enterprise bean cho một ứng dụng J2EE. Các enterprise bean và container của nó đều được chạy trên J2EE server.
Web container quản lý và thực thi của tất cả các trang JSP và các servlet cho
một ứng dụng J2EE. Các web component và container của nó đều được chạy trên J2EE server.
Application client container quản lý và thực thi của tất cả các thành phần
application client cho một ứng dụng J2EE. Các application client và container của nó đều được thực thi trên máy client.
Applet container chính là web browser có các Java Plug-in chạy trên máy
client.
Trang 26 Hình 2.5:kiến trúc tổng thể của hệ thống J2EE.

2.2. Giới thiệu dịch vụ JNDI Java Naming and Directory Interface


JNDI là dịch vụ đăng ký và truy tìm tên đối tượng chuẩn. Enterprise JavaBeans dựa vào JNDI để truy tìm các thành phần phân tán thông qua mạng.
JNDI là một cơng nghệ chính yếu được u cầu cho mã khách kết nối đến một thành phần EJB.
Cách lấy một tham chiếu tới một home object thông qua dịch vụ JNDI được trình bày ở hình 2.6 như sau:
Hình 2.6: lấy một tham chiếu đến một home object Acquiring a reference to a home object
Trang 27
Hệ thống JNDI
Là một service trong hệ thống J2EE phục vụ cho việc đặt tên của các Object, trong đó 1 object ta có thể xem như là module, một service để thực hiện một chức
năng nào đó. Với 1 object có thể có nhiều tên được tham khảo đến. Thơng qua JNDI, client hoặc EJB có thể truy xuất đến object thơng qua tên mà khơng cần
quan tâm object đó nằm ở đâu trên mạng khái niệm tương tự như việc đánh tên cho địa chỉ IP.
Hình 2.7: sơ đồ client truy xuất đốI tượng thông qua tên Một hệ thống JNDI bao gồm 3 phần chính yếu sau: lookup services, service
providers, và clients. Trong đó lookup services đóng vai trò trung tâm, nó là cầu nối giữa service
providers và clients. Lookup services có nhiệm vụ quản lý các dịch vụ mà service providers cung cấp, service providers cung cấp các dịch vụ cho hệ thống JNDI,
còn clients là người sử dụng các dịch vụ, sẽ kết hợp các dịch vụ với nhau để thực hiện một cơng việc nào đó.
Khi một service provider “muốn” đưa ra một dịch vụ nào đó thì nó phải đăng ký dịch vụ đó với lookup services. Khi một client muốn dùng một dịch vụ nào đó của
hệ thống thì nó sẽ phải “đề xuất u cầu” với lookup service, và các dịch vụ của hệ thống có thể phục vụ cho client khi được lookup service cho phép.
Quá trình đăng ký một dịch vụ của service provider với lookup service được thực hiện như sau q trình discovery: đầu tiên service proveider cần thơng báo
cho lookup service biết ý định của mình bằng cách gửi broadcast một presence announcement packet dùng một well-known port. Khi loopkup service nhận được
một presence announcement packet một packet có tính chất thơng báo, nó sẽ mở ra và phân tích packet này và lấy các thơng tin về service provider và service
mà service provider muốn cung cấp. Nếu lookup services chấp nhận service này thì nó sẽ mở cầu nối TCP đến IP và port do presence announcement packet cung
cấp để gửi đến đó một Object, object này được gọi là service registrar. Mục đích của service registrar object là để tạo sự dễ dàng trong việc giao tiếp giữa service
providers và lookup services trong quá trình đăng ký service. Khi lookup service chấp nhận một service mới bằng cách gửi lại cho service
providers một service registrar object, thì quá trình đưa một service vào lookup service được thực hiện như sau quá trình join: service providers sẽ gọi hàm
registrer của service registrar object với thông số là một object, object này gọi là service item, nó chứa tất cả các thông tin cần thiết cho một dịch vụ cần đưa vào
hệ thống JNDI. Khi quá trình đưa Service Item vào lookup service kết thúc thành cơng thì ta có thể coi như q trình đưa một service mới vào hệ thống JNDI thành
công.
Trang 28 Service Item có bản chất là một container và nó chứa một số các Object khác,
trong đó chính yếu nhất là một object được đặt tên là service object. Đây là object mà thơng qua đó, client có thể tương tác với service. Ngồi ra, service item còn
chứa một số các Object thuộc tính khác như icon, GUIs… của service. Trong service registrar object cũng còn có một method có tên là lookup dành
cho client để yêu cầu lookup service kiểm tra tính tồn tại của 1 hoặc 1 số service trong hệ thống JNDI. Và method này trả về service object cho client. Khi client gọi
một method trong service object thì service object đó sẽ kết nối trực tiếp với service provider tương ứng để thực thi method thông qua RMI
Trong J2EE, JNDI được sử dụng bởi client để nhận ConnectionFactory object. Có 2 loại kỹ thuật có thể dùng được cho JNDI lookup của ConnectionFactory
Object: Dựa trên cơ sở của kỹ thuật Serialication: sử dụng java.io.Serializable.
Application servercomponent tạo ra một instance ManagedConnectionFactory. Instance này được cấu hình bằng cách sử dụng các thơng tin được lưu trong 1
file cấu hình theo cú pháp của XML các thông tin về server name, port, gateway…. Bước kế tiếp là servercomponent tạo ra và thiết lập cấu hình cho
một instance của ConnectionManager và truyền instance này đến method createConnectionFactory
của ManagedConnectionFactory
object. Khi
servercomponent thực hiện JNDI loookup thì nó sẽ trả về 1 ConnectionFactory object để sử dụng cho Connection này.
Dựa trên cơ sở của kỹ thuật Referenceable: sử dụng javax.naming.spi.ObjectFactory
và javax.naming.Referenceable.
ApplicationComponent tạo ra một Reference object. Reference này chứa tất cả các thông tin mà application servercomponent cần để tạo và cấu hình cho một
ManagedConnectionFactory tương ứng. Reference này có thể chứa cặp reference namelogical name được sử dụng để nhận các đặt tính của
factory, reference cũng có thể là một chuỗi nhị phân chứa các thông số dùng để thiết lập cho ManagedConnectionFactory. Method getObjectInstance sẽ được gọi
khi component thực hiện thao tác loookup của ConnectionFactory. Để
loookup 1 object from naming service, ta sử dụng Context.lookup với thông số là tên của object mà ta muốn nhận

2.3. Giới thiệu về JDBC Java Database Connectivity


JDBC là một chuẩn mở rộng của Java cho việc truy cập dữ liệu, mà cho phép người lập trình Java mã hóa đến giao diện lập trình ứng dụng cơ sở dữ liệu quan
hệ đồng nhất. Bằng cách dùng JDBC, người lập trình Java có thể trình diễn việc kết nối cơ sỡ dữ liệu, xuất các câu lệnh SQL, kết quả của việc xử lý cơ sở dữ liệu,
và nhiều cách linh động liên quan khác. Clients lập trình đến JDBC API đồng nhất,
Trang 29 cái này được thực hiện bởi trình điều khiển JDBC JDBC Driver, một trình điều
hợp mà biết cách làm thế nào giao tiếp đến cơ sở dữ liệu với cách độc quyền. JDBC tương tự như chuẩn ODBCOpen Database Connectivity, và cầu nối thông
qua hai thành phần thao tác khá tốt là JDBC-ODBC. JDBC 2.0 chứa sự hỗ trợ cho sự thăm dò kết nối cơ sở dữ liệu, tăng sự độc lập cơ sở dữ liệu đối với mã
ứ ng dụng của bạn.
Hình 2.7: kết nốI cơ sở dữ liệu qua cầu nốI JDBC Java Database Connectivity

2.4. Giới thiệu về RMI Remote Method Invocation


Mục đích là để tạo ra một Java distributed object model. Trong kiến trúc của RMI, có một yếu tố khá quan trọng mà ta cần phải xác định rõ ràng, đó là việc định
nghĩa ra các method và việc thực thi các method đó là hồn tồn khác nhau. RMI cho phép ta định nghĩa 1 method với mã thực thi của nó trên 1 JVM Java Virtual
Machine và có thể gọi để thực thi method đó trên một JVM khác.
Hình 2.8: gọi thực thi phương thức thơng qua RMI RMI Architecture Layers: kiến trúc của RMI có thể phân vào 3 lớp sau:
• Stub and Skeleton layer: lớp này có nhiệm vụ giao tiếp trực tiếp với
chương trình ứng dụng, tiếp nhận các lời gọi method của server từ client.
Trang 30 •
Remote Reference layer: lớp này quản lý các tham khảo được thiết lập từ client đến remote object service trên server. Đây cũng là lớp dùng để thiết
lập kết nối từ client đến remote object service trên server. •
Transport layer: thiết lập kết nối TCPIP giữa các máy với nhau trên mạng để truyền dữ liệu khi lớp Remote Reference yêu cầu.
Kiến trúc 3 lớp của RMI được thể hiện như hình vẽ sau:
Hình 2.9: sơ đồ kiến trúc ba lớp của RMI Làm thế nào một client có thể tìm ra một RMI remote service?
Client tìm remote service thơng qua việc sử dụng naming or directory service, 1 naming or derectory service được chạy trên một well-known host và port. Trên
máy host, 1 chương trình server tạo ra một remote service bằng cách: đầu tiên nó tạo ra một local object để thực thi service đó, sau đó nó export object đó đến RMI.
Khi một object được export, RMI tạo ra một listening service để chờ client kết nối đế
n. Sau quá trình export, server đăng ký object đó trong RMI với một public name và public name này có thể được client sử dụng để kết nối với object tương
ứ ng.
RMI Java Remote Method Invocation system là một cơ cấu cho phép 1 object trên 1 JVM Java Virtual Machine gọi method của 1 object trên 1 JVM khác. Bất
kỳ các object có method có thể được gọi “từ xa” đều phải thực thi implement interface java.rmi.Remote. Khi 1 object được gọi, các giá trị truyền cho method
đượ c gửi từ JVM cục bộ JVM có chứa chương trình phát sinh lời gọi remote
method đến JVM chứa object có method đó và kết quả trả về được gửi về lại cho JVM cục bộ.
Để tạo nên 1 remote object, chương trình phải đăng ký object đó với RMI
registry. Chương trình phải cung cấp 1 cái tên cho object đó khi đăng ký. Khi một chương trình nào đó muốn truy xuất đến 1 remote object, nó phải cung cấp cho
RMI system tên của object mà nó muốn truy xuất và hệ thống sẽ trả về cho chương trình 1 reference đến remote object đó gọi là stub. Khi chương trình
nhận được stub của 1 remote object thì nó có thể gọi các method của remote object đó có trong stub.
Chuỗi tên của 1 object được RMI register chấp nhận phải có cú pháp như sau “rmi:hostname:portremoteObjectName” trong đó hostname và port chỉ định máy
và port mà trên đó RMI registry đang chạy, và remoteObjectName là tên của remote object được đăng ký. Chú ý rằng, hostname, port và tiếp đầu ngữ rmi là
tuỳ chọn. Nếu hostname không được đặt tả thì giá trị default là localhost, giá trị default của port là 1099.
RMI được hỗ trợ bởi việc sử dụng Java Remote Method Protocol JRMP và Internet Inter-ORB Protocol IIOP. JRMP là đặt tả giao thức được thiết kế cho
Trang 31 RMI, còn IIOP là giao thức chuẩn cho việc giao tiếp giữa các CORBA object. RMI
trên IIOP cho phép các Java remote object không chỉ giao tiếp với các CORBA object viết bằng Java mà còn bằng bất kỳ ngơn ngữ khác.
2.5.Tổng quan về Enterprise JavaBeanlà thành phần chính trong đặc tả J2EE
Enterprise JavaBean là mơ hình lập trình ứng dụng đa tầng. Cấu trúc EJB là
cấu trúc Component để phát triển và triển khai các ứng dụng nghiệp vụ phân tán. Các ứng dụng được viết với cấu trúc EJB có thể bảo mật đa người dùng, chia
mức và thực hiện giao tác. Những ứng dụng này có thể được viết một lần sau đó đượ
c triển khai trên bất kỳ nền server nào mà hỗ trợ đặc tả EJB.
Môi trường mà các đối tượng Bean sẽ hoạt động gọi là trình chứa Container.
Các trình chứa sẽ kiểm sốt việc khởi tạo, cung cấp tài nguyên cho đối tượng, lưu trữ phục hồi đối tượng.
EJB server cung cấp các dịch vụ hệ thống và quản lý Containerhình 2.10.
EJB server có khả năng cung cấp các dịch vụ giao tác và dịch vụ đăng ký và truy
tìm tên đối tượng JNDI-Java Naming and Directory Interface. EJB object bao
bọc các thể hiện bean. Nó được sinh ra bởi các tiện ích của nhà cung cấp EJB Container. EJB object cài đặt remote interface của bean.
Hình 2.10 Quan hệ giữa EJB server và EJB container
EJB home gần giống với EJB object, nó được tự động sinh ra khi cài đặt
enterprise bean trong Container. Nó cài đặt các phương thức được định nghĩa bởi
home interface và chịu trách nhiệm hỗ trợ container quản lý vòng đời bean. Kết
hợp với EJB container, EJB home chịu trách nhiệm tạo, đặt, và loại bỏ enterprise bean. Khi phương thức tạo được gọi trên home interface thì EJB home tạo một
thể hiện của EJB object mà tham chiếu tới thể hiện bean có kiểu tương ứng. Khi thể hiện bean được kết hợp với EJB object thì phương thức ejbCreate tương
ứ ng của thể hiện đó sẽ được gọi. Khi hồn thành phương thức ejbCeate, EJB
home trả lại tham chiếu remote tới client cho EJB object. Sau đó client có thể làm việc trực tiếp với EJB object bằng các phương thức nghiệp vụ.
Trang 32 Để
cài đặt Enterprise JavaBean, chúng ta cần hai định nghĩa interface và một hoặc hai lớp: Home interface: định nghĩa phương thức vòng đời của bean: tạo một
thể hiện bean mới, loại bỏ bean, và tìm kiếm bean.
Remote interface: để định nghĩa các phương thức nghiệp vụ, mở rộng
javax.ejb. EJBObject-đối tượng này lại là mở rộng của java.rmi.Remote.
Bean class: cài đặt các phương thức nghiệp vụ của bean, không cài đặt các
phương thức của home interface và remote interface.
Primary key: là một lớp cực kỳ đơn giản, cung cấp con trỏ tới cơ sở dữ liệu.
Chỉ bean thực thểentity bean mới cần primary key. Hoạt động: client không bao giờ tương tác trực tiếp với lớp bean mà nó ln
ln sử dụng các phương thức giao tiếp home interface và remote interface của bean để thực hiện cơng việc của nó. Client sử dụng dịch vụ JNDI tham chiếu tới
lớp chủ. Lớp chủ sẽ triệu gọi phương thức tạo ra tham chiếu đến lớp giao tiếp của bean rồi trả về trình khách. Trình khách triệu gọi bean thông qua lớp giao tiếp
trung gian mà do lớp chủ trả về. Lớp trung gian này là giao tiếp giữa trình chứa Container và đối tượng bean thực sự.
Như ta đã giới thiệu ở trên, enterprise bean là một thành phần phần mềm ở phía Server mà có thể triển khai trong một môi trường phân tán. Một enterprise
bean có thể gồm một hay nhiều các đối tượng java tại vì một thành phần có thể là nhiều hơn một đối tượng đơn giản.
Có các loại Bean:Type of Beans Session Beans:Bean thao tác chỉ có nhiệm vụ phục vụ trình khách trong một
phiên kết nối. Bean thao tác chỉ thực hiện các hành vi xử lý, tính tốn đơn thuần khơng đòi hỏi đến việc thể hiện dữ liệu. Các Session bean có thể dùng bởi một
máy khách tại một thời điểm, chúng không chia xẻ cho các máy khách khác. Khi máy khách đang dùng một session bean máy khách đó là máy khách duy nhất giải
quyết session bean đó. Điều này trái ngược với entity bean, trạng thái của nó đượ
c chia xẻ giữa các máy khách với nhau. Trong session bean được chia làm hai loại: Stateful Session Bean và Stateless
Session Bean:
Stateful Session Bean: là các thành phần bean cần lưu lại kết quả hay vị trí
giao dịch trước đó để phục vụ cho các lần giao dịch tiếp theo - thường phục vụ cho những thao tác đòi hỏi qua nhiều bước triệu gọi trước khi trả về kết quả cuối
cùng.
Stateless Session Bean: là các thành phần bean không lưu lại trạng thái của
giao dịch trước đó để sử dụng lại cho lần giao dịch sau. Session beans quản lý các xử lý nghiệp vụ. Các session bean có thể sử dụng
entity beans để thể hiện dữ liệu mà chúng dùng. Một điểm khác biệt giữa Session Bean và Entity Bean là: Entity Bean có vòng đời lâu hơn Session Bean nhiều. Khi
ứ ng dụng Server bị sự cố thì Entity Bean có thể được xây dựng lại trong bộ nhớ
bằng cách đơn giản là đọc lại dữ liệu từ cơ sở dữ liệu bền vững.
Entity Bean: Một phần cơ bản khác của một nghiệp vụ là bền vững dữ liệu mà xử lý nghiệp
vụ sử dụng. Entity Bean chính là một thành phần mà đại diện cho bền vững dữ liệu. Entity Bean không chứa xử lý nghiệp vụ logic.
Trang 33 Có hai loại bean thực thể entity bean
Bean thực thể tự quản lýBean – Managed Persistent Entity Beans: là các
thành phần bean có khả năng tự truy vấn các hệ cơ sở dữ liệu để lấy về dữ liệu nó thể hiện. BMP Bean Managed Persistent có những ưu điểm: mình có thể viết
mã cho các phương thức, nhất là các phương thức thao tác với nhiều bảng dữ liệu cùng một lúc. Đồng thời sẽ tiện hơn khi tạo mới dữ liệu, vì ta có thể sử dụng
đị nh dạng sequence – tăng tự động chỉ số id trong bảng dữ liệu. Nhưng có một
nhựơc điểm là sẽ tốn thời gian để viết, mà chính ta viết thì có thể bị lỗi.
Bean thực thể quản lý bởi trình chứa: Container –Managed Persistent Entity Beans
Là các thành phần bean không cần sử dụng lệnh SQL để tìm kiếm hay tạo mới dữ liệu mà chỉ cần khai báo các tên trường hay cột dữ liệu tương ứng với các
bảng trong hệ CSDL. Trình chứa sẽ tự động thực hiện công việc truy vấn dữ liệu giúp thành phần bean. CMPContainer – Managed Persistent lại có một ưu điểm
rất lớn là chúng ta không phải viết mã, trình chứa đã thực hiện điều này. Và như thế chương trình khơng bao giờ có lỗi. Nhưng nó lại bất lợi ở chỗ: trường primary
key có kiểu java.math.BigDecimal nên không tận dụng được định dạng sequence của cơ sở dữ liệu. Hơn nữa, khi chúng ta cần thao tác với nhiều bảng cùng một
lúccó sự join giữa các bảng thì sẽ phức tạp hơn- cần viết thêm lớp bean kết nối hai thực thể bean của hai bảng dữ liệu kia.
Message – driven bean: xử lý các thông điệp message một cách khơng
đồ ng bộ. Nó tương tự như stateless session bean ở chỗ nó khơng lưu trữ trạng
thái giao dịch. Điểm khác với Session và Entity Bean là client không thể truy cập chúng qua interface. Message – driven bean chỉ là một lớp bean, không có
interface. Chỉ cần một bean này nó vẫn có thể xử lý nhiều message từ nhiều hoặc một client. Bean này là một khối mã ứng dụng mà có thể thực hiện khi message
đế n.

2.6. Phát triển các thành phần: Developing Beans The Enterprise Bean class:


Đặ c tả EJB định nghĩa vài giao tiếp chuẩn mà lớp bean có thể thực hiện. Sức
mạnh giao tiếp của lớp bean là trình bày các phương thức đảm bảo mà tất cả các beans phải cung cấp, như đã định nghĩa bởi mơ hình thành phần EJB. Trình chứa
gọi những phương thức đã yêu cầu để quản lý các bean và thay đổi bean đến các sự kiện quan trọng.
Hầu hết các giao tiếp cơ bản của các lớp bean cả session và entity bean phải thực hiện là:
public interface javax.ejb.EnterpriseBean extends java.io.Serializable {
} Source 3.1 javax.ejb.EnterpriseBean interface
The EJB object: Khi một máy khách muốn dùng một thể hiện của một lớp enterprise bean, máy
khách đó khơng bao giờ triệu gọi phương thức đó một cách trực tiếp. Nói đúng hơn là sự viện cầu bị ngăn chặn bởi trình chứa EJB và rồi chuyển giao cho thể
hiện của bean. Trình chứa EJB đang hoạt động như một tầng gián tiếp giữa mã khách và bean. Tầng gián tiếp này biểu hiện như một đối tượng đơn nhận biết
Trang 34 mạng, được gọi là EJB object. EJB object là một đối tượng đại diện mà nhận biết
về mạng, giao tác, an ninh …Nó là một đối tượng thông minh biết làm thế nào để thực hiện logic trung gian các yêu cầu tới trình chứa EJB trước khi một lời gọi
phương thức được phục vụ bởi một thể hiện của lớp bean. Một EJB object hoạt độ
ng hàn gắn giữa máy khách và thành phần bean, và nó trình bày mỗi phương thức nghiệp vụ mà chính bean đó biểu hiện. EJB object chuyển giao tất cả các
yêu cầu máy khách đến bean. EJB object là một thành phần vật lý của trình chứa container.
The Remote Interface:
Để định nghĩa các phương thức nghiệp vụ. Các thành phần máy khách triệu
gọi phương thức trên EJB object, đúng hơn là chính các bean đó. Để thực hiện đ
iều này, EJB object phải định nghĩa từng phương thức nghiệp vụ mà các lớp bean biểu hiện. Nhưng làm thế nào các công cụ tự động tạo ra EJB object biết
phương thức nào để định nghĩa? Câu trả lời là một giao tiếp đặc biệt mà nhà cung cấp bean viết. Giao tiếp này sao lại tất cả các phương thức nghiệp vụ mà lớp
bean tương ứng biểu hiện. Giao tiếp này được gọi là remote interface. Remote interface phải phù hợp với các luật mà đặc tả EJB định nghĩa.
Xem mã nguồn 3.2Source 3.2
Hình 2.11: sơ đồ gọi phương thức từ Client đến EJB objects public interface javax.ejb.EJBObject extends java.rmi.Remote
{ public abstract java.ejb.EJBHome getEJBHome throws
java.rmi.RemoteException; public abstract java.lang.object getPrimaryKey throws
java.rmi.RemoteException; public abstract void remove throws
java.rmi.RemoteException,javax.ejb.RemoveException; public abstract java.ejb.Handle getHandle throws
java.rmi.RemoteException;
Trang 35 public abstract boolean isIdenticaljavax.ejb.EJBObject throws
java.rmi.RemoteException; }
Source 3.2 the javax.ejb.EJBObject interface Mã khách muốn làm việc với các bean gọi các phương thức trong
javax.ejb.EJBObject. Mã khách có thể là ứng dụng stand-alone, applets, servlet thậm chí cả các bean khác. Thêm vào đó, remote interface sao lại các phương
thức nghiệp vụ của bean. Khi một trình khách của bean triệu gọi bất kỳ phương thức nghiệp vụ nào, EJB object sẽ chuyển giao phương thức đó tới sự thực hiện
tương ứng, sự thực hiện này cư trú bên trong các bean đó.
The Home Object:
Như chúng ta đã biết, mã client xử lý với EJB object và không bao giờ làm việc trực tiếp với bean. Câu hỏi là làm thế nào trình khách đạt được tham chiếu
tới EJB object. Máy khách không thể thuyết minh EJB object một cách trực tiếp tại vì EJB object có thể tồn tại trên một máy khác chứ không cùng trên máy client.
Dường như sự định vị EJB object là trong suốt, vì vậy máy khách sẽ khơng bao giờ nhận ra chính xác EJB object cư trú nơi nào.
Để đạt được tham chiếu tới một EJB object, mã client yêu cầu một EJB object
từ một xí nghiệp EJB object EJB object factory. Xí nghiệp này chịu trách nhiệm cho sự thuyết minh EJB object. Đặc tả EJB gọi xí nghiệp này là một home object.
Trách nhiệm của home object là làm các việc sau: + Tạo EJB objects
+ Tìm các EJB object đang tồn tại + Hủy bỏ các EJB object.
Home object là một phần vật lý của trình chứa và được tự động tạo ra bởi công cụ của nhà cung cấp trình chứacontainer provider.
The Home Interface: Chúng ta đã thấy home object là các xí nghiệp cho EJB object. Nhưng bạn
phải cung cấp thơng tin cho trình chứa bằng đặc tả một home interface. Home interface định nghĩa các phương thức đơn giản cho việc tạo, huỷ, tìm kiếm EJB
object. Home object của trình chứa thực hiện home interface cho chúng ta. Vài phương thức mà đặc tả EJB yêu cầu các home interface phải hỗ trợ.
Những phương thức đã yêu cầu này được định nghĩa trong javax.ejb. EJBHome interface- một home interface mà home interface của chúng ta phải thừa kế.
Javax.ejb. EJBHome được trình bày như sau:
Public interface javax.ejb.EJBHome extendx java.rmi.Remote {
public abstract EJBMetaData getEJBMeTaData throws
java.rmi.RemoteException; public abstract void removeHandle handle throws
java.rmi.RemoteException, javax.ejb.RemoveException;
Trang 36 public abstract void removeObject primaryKey throws
java.rmi.RemoteException, javax.ejb.RemoveException; }
Source 3.3 The javax.ejb.EJBHome interface
Hình 2.12:sơ đồ yêu cầu tạo một EJB object từ Home objects Giải thích q trình làm việc của hình 2.11 và 2.12:
Khi phương thức tạo được gọi trên home interface từ trình khách thì EJB home tạo một thể hiện của EJB object mà tham chiếu tới thể hiện bean có kiểu
tương ứng. Khi thể hiện bean được kết hợp với EJB object thì phương thức ejbCreate tương ứng của thể hiện đó sẽ được gọi. Khi hồn thành phương thức
ejbCeate, EJB home trả lại tham chiếu remote tới client cho EJB object, hình 2.12 . Sau đó client có thể làm việc trực tiếp với EJB object bằng các phương
thức nghiệp vụ, hình 2.11 .
Trang 37

PHẦN II PHÁT TRIỂN ỨNG DỤNG


Tài liệu bạn tìm kiếm đã sẵn sàng tải về

GIỚI THIỆU CÔNG NGHỆ 2 GIỚI THIỆU VỀ J2EE

Tải bản đầy đủ ngay(72 tr)

×