Xây dựng ứng dụng J2EE với sự hỗ trợ của Rational Rose và UML

MỤC LỤC

Sequence diagrams (Lược đồ tuần tự)

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

Collaboration diagrams (Lược đồ cộng tác)

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

Statechart diagrams (Lược đồ trạng thái)

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

Hình 1.18: lược đồ trạng thái
Hình 1.18: lược đồ trạng thái

GIỚI THIỆU VỀ J2EE

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

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

         Hình 2.7: sơ đồ client truy xuất đốI tượng thông qua tên
Hình 2.7: sơ đồ client truy xuất đốI tượng thông qua tên

Giới thiệu về JDBC (Java Database Connectivity)

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

Hình 2.8: gọi thực thi phương thức thông qua RMI
Hình 2.8: gọi thực thi phương thức thông qua RMI

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

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

Hình 2.11: sơ đồ gọi phương thức từ Client đến  EJB objects
Hình 2.11: sơ đồ gọi phương thức từ Client đến EJB objects

Mô tả kịch bản của ứng dụng

PHÂN TÍCH MÔ TẢ YÊU CẦU TRƯỜNG HỢP NGƯỜI DÙNG VÀ KỊCH BẢN ỨNG DỤNG.

Phân tích yêu cầu trường hợp người dùng

  • Xác định các Use case

     Duyệt xem danh mục hàng (browse catalog): tìm kiếm danh mục(search catalog), duyệt xem loại hàng (browse category), duyệt xem chi tiết sản phẩm (browse product details), duyệt xem chi tiết mục hàng (browse Item details).  Chọn mua hàng vào giỏ (shopping cart): thêm và xoá mục hàng(add and remove Item), cập nhật số lượng của mục hàng (update quantity item), đặt mua mục hàng (order item).

    Account người dùng được tạo

    Một khi account đã được tạo và đã được kích hoạt, người dùng đó được xem như đã được đăng nhập. Use case này bắt đầu khi người dùng muốn tạo một account mới, người chưa có account trong hệ thống.

    Account không được tạo: điều này xảy ra khi người dùng nhập thông tin không hợp lệ

      Use case này cho phép người dùng tạo và kích hoạt một account chứa thông tin người dùng. ● Pre – Condition (điều kiện trước): người dùng phải đăng nhập vào hệ thống trước khi muốn cập nhật account của mình.

      Account người dùng được cập nhật

      - Hệ thống thông báo những dữ liệu nhập vào không hiệu lực, yêu cầu nhập lại. - Người dùng nhập lại thông tin và hệ thống xác nhận lại những thông tin đó.

      Account không được cập nhật: điều này xảy ra khi người dùng nhập thông tin không hợp lệ

      • Phân tích miền ứng dụng
        • Các lược đồ trong các gói
          • Thiết kế các thành phần
            • Thiết kế hiện thực hóa các use case 1. Thiết kế hiện thực hóa use case sign in

              Sau khi xây dựng xong mô hình yêu cầu trường hợp người dùng: use case, mô hình được người dùng tán thành, ta phát triển mô hình phân tích, phân tích miền ứng dụng đã được nắm bắt. ● Nhìn vào những khái niệm chủ chốt (những khái niệm mà hệ thống phải hỗ trợ) để rút ra những danh từ. ● Giữ lại các lớp đúng đắn: ta loại bỏ các lớp không cần thiết và không chính xác theo các tiêu chuẩn sau:. - Các lớp dư thừa: nếu hai lớp cùng biểu diễn một thông tin, giữ lại tên diễn tả đúng đắn nhất. - Các lớp không thích hợp: nếu một lớp có ít hoặc không có gì thực hiện vấn đề, nó phải được loại bỏ. - Cỏc lớp mơ hồ: một lớp phải xỏc định, một số lớp thử cú thể cú biờn giới khụng rừ ràng hoặc là quá rộng, cần được loại bỏ. - Các thuộc tính: các tên mô tả các đối tượng riêng lẻ. Các thao tác:. - Các vai trò: tên các lớp, phải phản ánh bản chất tự nhiên của nó, không phải là vai trò mà nó đóng trong kết hợp. - Các cấu trúc cài đặt: các cấu trúc bắt nguồn từ thế giới thực, phảI được loại bỏ, chúng sẽ được cần đến trong khi thiết kế. Nhận diện các kết hợp. Để xác định các kết hợp, thông thường là ta dựa vào tài liệu đặc tả ứng dụng và đặc biệt là từ mô tả use case để rút ra các động từ hay nhóm động từ. Sau đó ta tiến hành lọc bỏ để giữ lại các kết hợp tốt. Ta loại bỏ các kết hợp không cần thiết và không chính xác theo các tiêu chuẩn sau:. - Các kết hợp không thích hợp hoặc cài đặt: loại bỏ bất cứ kết hợp nào mà ở ngoài lĩnh vực vấn đề hoặc có quan hệ với cấu trúc cài đặt. - Các tác động: kết hợp phải mô tả một đặc tính về cấu trúc của lĩnh vực ứng dụng. - Các kết hợp ba nhánh: các kết hợp ba nhánh nên được tách ra thành các kết hợp hai nhánh. - Các kết hợp dẫn xuất: các kết hợp được định nghĩa bằng các kết hợp khác. Nhận diện các thao tác. Để nhận diện các thao tác, một công cụ thuận lợi là ta nhìn vào các hành vi của các use case - luồng các sự kiện, sau đó phân bổ các hành vi này vào các lớp được sử dụng bởi use case đó. Nhận diện các thuộc tính. Các thuộc tính là đặc tính của đối tượng riêng lẻ. Thuộc tính thường tương ứng với danh từ theo sau là nhóm từ sở hữu. Thuộc tính kém thích hợp để mô tả đầy đủ một vấn đề. Thuộc tính ít ảnh hưởng đến cấu trúc cơ sở của vấn đề. Đầu tiên ta ghi nhận các thuộc tính quan trọng trước, sau đó thêm dần các chi tiết vào sau. Các lược đồ trong các gói. Sau khi tìm ra các lớp miền nghiệp vụ ta nhóm các lớp có quan hệ gần gũi vào trong các gói. Trong mỗi gói có thể chứa gói con trong đó. Ta có các gói sau:. + sign in and off package: gói đăng nhập. + shopping cart package: gói mua chọn hàng, có các gói con là: cart package và catalog package. + inventory package: gói thống kê số lượng hàng. + customer package: gói khách hàng, có các gói con là: account package, customer package, order package. Lược đồ quan hệ giữa các lớp nghiệp vụ và lớp giao diện:. các lược đồ trong gói sign in and off. Ở mô hình quan niệm phân tích, mô tả yêu cầu ứng dụng ta chỉ mô tả sơ lược về các chức năng mà hệ thống sẽ làm. Đây là mô hình giao tiếp giữa nhà phát triển với người dùng, nó là bản mẫu cho sự giao tiếp, chưa can thiệp vào cách thực hiện như thế nào. Cái đó thuộc về pha thiết kế. a) Các lược đồ trong sign in. Dựa vào pha phân tích ta xác định thành phần nào là Entity Bean, thực hiện việc lưu trữ dữ liệu, thành phần nào là Session Bean, thực hiện các thao tác tính toán, xử lý, không liên quan đến việc lưu trữ dữ liệu.

              Sign in là thành phần kiểu Entity Bean (BMP), được thể hiện như sau:. Sự giao tiếp giữa EJB với lớp DAO như sau. Hình 4.3: quan hệ giữa thành phần EJB với các lớp truy cập dữ liệu. Thành phần shopping cart a) Thành phần catalog.

              Hình 3.5: lược đồ tuần tự của sign off
              Hình 3.5: lược đồ tuần tự của sign off