Xây dựng ứng dụng J2EE với Rational Rose và UML

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 kỳ phát triển mạnh của mạng toàn cầu – Internet, các ứng dụng phân tán phát triển rất mạnh và mang tính cấp thiết.

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

kỳ phát triển mạnh của mạng toàn cầu – Internet, các ứng dụng phân tán phát triển rất

mạnh và mang tính cấp thiết Nó đem lại lợi ích vô cùng to lớn cho con người Nhằm tìm

hiểu theo hướng phát triển này, đồ án của em tiếp cận một công nghệ xây dựng ứng dụng

phân tán, đa tầng có tính bảo mật cao Đó là công nghệ J2EE- Java 2 Platform, Enterprise

Edition, nó tương đối mới Cùng với công nghệ này, ngôn ngữ mô hình thuần nhất(UML-

Unified Modeling Language) là ngừời bạn đồng hành để mô hình hóa, hiện thực hoá ứng

dụng trong quá trình phân tích và thiết kế hướng đối tượng

Trong đồ án tốt nghiệp em phát triển ứng dụng J2EE với UML (Unified Modeling

Language) và Rational Rose Trong thời gian ngắn cũng như khả năng, trong đồ án còn

nhiều sai sót, rất mong sự chỉnh sửa của thầy hướng dẫn và sự góp ý từ phía người đọc

Một lần nữa em xin cảm ơn thầy Nguyễn Thanh Tùng đã tận tình hướng dẫn cho em hoàn

thành đồ án này

Nha Trang tháng 07/ 2003

Sinh viên thực hiện:

Lê Quang Dung

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 hoá

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 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

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

 Đối tượng (Object)

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 hoá

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

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

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ó để

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

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 toán các thông số và dự đoá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 hoá vấn đề cơ bản

Phạm vi (domain ) là thế giới thực mà vấn đề đó mang đến

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

Hình 1.1: sự hợp nhất 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

a)Cá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

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 : Các lược đồ của UML

 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 đồ 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

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

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ở

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à toà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 quát hoá 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

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

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

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)

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

<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

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

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

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

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

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

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

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 ngoà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 hoà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

đoán ở phòng mạch Có hai thộng diệp không đồng bộ từ Nurse :

Hình 1.19 : lược đồ tuần tự với thông điệp không đồng bộ

1) yê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 :

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

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

Hình 1.22: lược đồ hoạt động

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 Process(JCP) 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

Applets: cũng là một hình thức của application client nhưng được thiết kế để được

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

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

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 yê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)

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 yê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 (quá 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ư quá trình đưa một service mới

vào hệ thống JNDI thành công

Service Item có bản chất là một container và nó chứa một số các Object khác, trong đó

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

server/component 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à server/component

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

server/component 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 Application/Component

tạo ra một Reference object Reference này chứa tất cả các thông tin mà application

server/component 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 name>/<logical 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, 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 ODBC(Open 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à hoàn toà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

 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 TCP/IP 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

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:port/remoteObjectName” 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 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 JavaBean(là 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 soá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

(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 hoà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ụ

Để 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ó luôn luôn sử

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 toá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

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

CMP(Container – 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

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 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

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.Handle getHandle() throws java.rmi.RemoteException;

public abstract boolean isIdentical(javax.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:

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ứa(container 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