Đề tài Tiếp cận và xây dựng ứng dụng J2EE với Rational Rose và UML

istrer() 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 đó 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. Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 28 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 / đượ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. Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 29 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.  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. Kiến trúc 3 lớp của RMI được thể hiện như hình vẽ sau: Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 30 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 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. Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 31 EJB server cung cấp các dịch vụ hệ thống và quản lý Container(hì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ụ. Để 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ử 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 Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 32 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. 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 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 Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 33 với nhiều bảng cùng một lúc(có 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 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.2(Source 3.2) Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 34 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; 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: + Tạo EJB objects Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 35 + 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ứ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 { public abstract EJBMetaData getEJBMeTaData() throws java.rmi.RemoteException; public abstract void remove(Handle handle) throws java.rmi.RemoteException, javax.ejb.RemoveException; public abstract void remove(Object 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 Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 36 Giải thích quá 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) . PHẦN II PHÁT TRIỂN ỨNG DỤNG Trong phần này sẽ xây dựng ứng dụng E-store để mô tả những kỹ thuật, công nghệ trong việc phát triển ứng dụng theo công nghệ J2EE. Ứng dụng được mô tả phân tích với use case và miền phân tích theo UML. Sau đó được thiết kế theo kiến trúc MVC – Model- View-Controller. Cuối cùng sẽ cài đặt theo các tầng như sau:  Tầng giao diện Web (Web tier):công nghệ JSP, JavaBean, Servlet  Tầng nghiệp vụ (Business tier): công nghệ EJB (Enterprise Java Bean) phiên bản 1.x  Tầng EIS (Enterprise Information System tier) Mục đích của phát triển ứng dụng này là:  Tìm hiểu việc sử dụng UML để phân tích thiết kế ứng dụng theo hướng đối tượng.  Minh họa cách sử dụng Rational Rose  Tìm hiểu công nghệ EJB, JSP, Servlet ... của đặc tả J2EE. Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 37 CHƯƠNG 3 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 3.1. Mô tả kịch bản của ứng dụng Ứng dụng này là một phần của hệ thống thương mại điện tử. Ứng dụng này đảm trách chức năng chính trong cả hệ thống, cho phép khách hàng tìm chọn và đặt mua hàng thông qua mạng. Vì khả năng và thời gian nên em chỉ tập trung vào phần ứng dụng này. Kịch bản mua hàng được mô tả theo trình tự sau: 1. Khách hàng truy cập vào trang chủ Web site của ứng dụng này. Nó cho phép tìm sản phẩm thông qua giao diện tìm kiếm. 2. Bất cứ khi nào khách hàng cũng có thể đăng nhập vào hệ thống bằng cách cung cấp một account và password. Nếu khách hàng chưa có account thì hệ thống yêu cầu tạo mới account bất cứ khi nào. 3. Khách hàng duyệt qua danh mục hàng, khách hàng chọn loại hàng để hiển thị danh sách tất cả các sản phẩm trong loại hàng đó. 4. Khách hàng chọn một sản phẩm cụ thể trong danh sách. Hệ thống hiển thị thông tin về sản phẩm đã chọn như: sự mô tả về sản phẩm, hình ảnh, thông tin giá cả. Mỗi sản phẩm có nhiều mục hàng, mỗi mục hàng được trình bày riêng biệt. 5. Khách hàng quyết định mua một mục hàng cụ thể 6. Khách hàng chọn mục hàng cần mua vào trong giỏ hàng. Nếu khách hàng chưa đăng nhập vào hệ thống thì được hệ thống yêu cầu đăng nhập. Nếu khách hàng chưa có tài khoản thì có thể tạo mới. 7. Khi khách hàng yêu cầu ghi tên trước khi rời hệ thống thì hệ thống sẽ hiển thị các mục hàng đã chọn cùng với thông tin giá cả. 8. Khách hàng xác nhận hố đơn, hệ thống thu thập thông tin về vận chuyển, thanh tốn cho hóa đơn. 9. Cuối cùng khách hàng xác nhận đơn đặt hàng và hệ thống chấp nhận việc phát chuyển hóa đơn đi. 3.2. Phân tích yêu cầu trường hợp người dùng Bước đầu tiên trong quá trình phân tích là ta định nghĩa các use case - những chức năng yêu cầu hệ thống. Việc phân tích use case liên quan đến việc phân tích những đặc tả của người sử dụng để phát hiện ra các use case, actor. 3.2.1. Xác định các Actor Từ mô tả kịch bản của ứng dụng ta có được Actor là khách hàng (customer)  Khách hàng là người cần tìm món hàng và đặt mua hàng trên mạng thông qua hệ thống này. Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 38 3.2.2. Xác định các Use case Qua quá trình khảo sát đặc tả ứng dụng có được các use case của phần ứng dụng này như sau:  Tạo tài khoản (create account)  Cập nhật tài khoản (update account)  Đăng nhập vào và thốt khỏi hệ thống (signin and off )  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à xố 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)  Gửi đơn mua hàng đến trung tâm xử lý đơn hàng (Send Purchase Order to Order Fulfillment Center) Hình 3.1: lược đồ các Use case của cả ứng dụng Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 39 3.2.3. Mô tả các use case 3.2.3.1 Use case tạo tài khoản (create account)  Tóm tắt 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. Một khi account đã được tạo và đã được kích hoạt, người dùng đó được xem như đã được đăng nhập.  Các luồng sự kiện Luồng các sự kiện chính 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. 1. Hệ thống hiển thị thông tin mà người dùng phải nhập vào. 2. Người dùng nhập thông tin được yêu cầu và hệ thống lưu những giá trị đó. 3. Người dùng submit những thông tin vừa nhập. Một account mới được tạo. 4. Hệ thống thông báo account được tạo thành công 5. Account được tạo thành công, xem như đã đăng nhập vào hệ thống. 6. Use case kết thúc. Luồng sự kiện phụ 1. Người dùng nhập thông tin của account không hợp lệ. Nếu hệ thống xác định thông tin mà người dùng nhập vào không hợp lệ thì xảy ra các điều sau: - 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 đó. - Nếu nhập vào thông tin hợp lệ thì sẽ được lưu vào hệ thống. - Nếu không hợp lệ thì hệ thống yêu cầu nhập lại cho đến khi hợp lệ. ● Pre – Condition (điều kiện trước):không có. ● Post –Condition (điều kiện sau): 1. Account người dùng được tạo. 2. 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ệ. 3.2.3.2 Use case cập nhật tài khoản (update account)  Tóm tắt Use case này cho phép người dùng cập nhật lại account chứa thông tin người dùng. Một account được cập nhật khi nó đã có và đã được kích hoạt trong hệ thống, thông tin mới của account được cập nhật.  Các luồng sự kiện Luồng các sự kiện chính Use case này bắt đầu khi người dùng muốn cập nhật một account, account đó đã có trong hệ thống, với điều kiện người dùng đã đăng nhập vào rồi. 1. Hệ thống hiển thị thông tin account của người dùng. 2. Người dùng nhập, chỉnh sửa thông tin cần cập nhật. Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 40 3. Người dùng submit những thông tin vừa cập nhật. Account được cập nhật. 4. Hệ thống thông báo account được cập nhật thành công 5. Use case kết thúc. Luồng sự kiện phụ 1. Người dùng nhập thông tin của account không hợp lệ. Nếu hệ thống xác định thông tin mà người dùng nhập vào không hợp lệ thì xảy ra các điều sau: - 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 đó. - Nếu nhập vào thông tin hợp lệ thì sẽ được lưu vào hệ thống. - Nếu không hợp lệ thì hệ thống yêu cầu nhập lại cho đến khi hợp lệ. ● 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 ● Post –Condition (điều kiện sau): 1. Account người dùng được cập nhật. 2. 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ệ. 3.2.3.3 Use case đăng nhập vào và thốt khỏi hệ thống (Signin and off). a) Use case đăng nhập (signin)  Tóm tắt Use case này là nơi mà người sử dụng được nhận diện trong hệ thống. Nếu người dùng đã có một account trong hệ thống, người dùng cung cấp một user name và password để xác nhận. Nếu người dùng chưa được xác nhận thì chưa đăng nhập vào hệ thống được. Nếu người dùng không có một account trong hệ thống thì có thể tạo mới. Khi account được tạo mới thì người dùng đó được đăng nhập.  Các luồng sự kiện Luồng các sự kiện chính Use case này bắt đầu khi người dùng muốn đăng nhập hệ thống. 1. Hệ thống đưa dấu nhắc đến nơi nhập user name và password. 2. Người dùng nhập thông tin user name và password vào. Hệ thống xác nhận thông tin nhập vào có hợp lệ hay không. 3. Hệ thống thông báo đăng nhập thành công. 4. Use case kết thúc. Luồng sự kiện phụ 1. New User: Người dùng không có một account, hệ thống cho phép tạo account. Một khi account được tạo, người dùng được xem như đã đăng nhập. 2. Lỗi xác nhận người sử dụng: người dùng nhập user name và password bị sai, sự đăng nhập không thành công, hệ thống báo lỗi yêu cầu trở lại đăng nhập tiếp. ● Pre – Condition (điều kiện trước): không có. Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 41 ● Post –Condition (điều kiện sau): nếu đăng nhập thành công, người dùng được xác nhận vào hệ thống. b) Use case thốt khỏi hệ thống (sign off)  Tóm tắt Use case này cho phép người dùng thốt khỏi hệ thống sau khi đã đăng nhập vào rồi(signed in).  Các luồng sự kiện Luồng các sự kiện chính Use case này bắt đầu khi người dùng muốn thốt khỏi hệ thống khi đã đăng nhập rồi. 1. Hệ thống kết thúc mọi hoạt động, kết thúc một phiên đăng nhập chọn mua hàng... 2. Người dùng trở về trạng thái chưa đăng nhập 3. Hệ thống thông báo thông điệp kết thúc. 4. Use case kết thúc. Luồng sự kiện phụ Không có ● Pre – Condition (điều kiện trước): người dùng phải đăng nhập rồi ● Post –Condition (điều kiện sau): người dùng thốt khỏi hệ thống. 3.2.3.4 Use case duyệt xem danh mục hàng (browse catalog)  Tóm tắt Use case này cho phép người dùng duyệt xem danh mục hàng trong hệ thống. Người dùng có thể tìm kiếm mục hàng cụ thể hoặc các mục hàng xếp sẵn thành loại (category). Hệ thống hiển thị thông tin mục hàng đã yêu cầu, một khi mục hàng đã hiển thị, người dùng có thể chọn vào giỏ hàng  Các luồng sự kiện Luồng các sự kiện chính 1. Use case này bắt đầu khi người dùng muốn tìm các mục hàng có trong hệ thống. 2. Hệ thống hiển thị mục hàng cho người dùng, người dùng cũng có thể nhập từ khố để tìm kiếm. Công việc này có thể lặp đi lặp lại nhiều lần. Tìm kiếm có nhiều cách: - Search catalog: người dùng nhập từ khố vào để tìm loại hàng, hoặc mục hàng cụ thể. Người dùng có thể chọn mục hàng vào giỏ hàng. - Browse category: người dùng có thể chọn loại hàng trực tiếp có sẳn trong danh mục hàng (catalog). Hệ thống hiển thị các sản phẩm (product) của loại hàng đó. - Browse product detail: người dùng sau khi duyệt qua loại hàng(category), các sản phẩm của loại hàng đó được hiển thị. Người dùng có thể duyệt qua từng loại sản phẩm. Mỗi loại sản phẩm có các mục hàng (Item) cụ thể, mỗi mục hàng gồm các thông tin: mã số mục hàng (ItemID), tên mục hàng, và giá cả của mục hàng. - Browse Item detail: khi người dùng duyệt đến các mục hàng cụ thể, người dùng muốn xem chi tiết một mục hàng cụ thể nào đó thì hệ thống hiển thị thông tin: tên mục hàng, hình ảnh, mô tả, giá cả, số lượng có sẳn trong kho hàng. 3. Use case kết thúc. Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 42 Luồng sự kiện phụ 1. Từ khố nhập vào để tìm kiếm không tìm thấy trong hệ thống. ● Pre – Condition (điều kiện trước):không có. ● Post –Condition (điều kiện sau): không có. 3.2.3.5 Use case chọn mua hàng vào giỏ (shopping cart)  Tóm tắt Use case này cho phép người dùng chọn mục hàng và đặt vào giỏ hàng. Khi người dùng chọn xong những món hàng mình cần mua thì xác nhận đồng ý mua. Hệ thống yêu cầu người mua nhập thông tin về thẻ tín dụng, địa chỉ hố đơn, địa chỉ vận chuyển. Hệ thống sẽ xác nhận tính hợp lệ của thẻ tín dụng và những thông tin khác. Sau đó người dùng submit hố đơn đến hệ thống. Hệ thống gửi thông điệp xác nhận thông qua emai. Nếu người dùng chưa đăng nhập thì hệ thống bắt buộc phải đăng nhập.  Các luồng sự kiện Luồng các sự kiện chính 1. Use case này bắt đầu khi người dùng muốn mua các mục hàng trong hệ thống. Người dùng tìm các mục hàng mình cần mua và đặt các mục hàng đó vào giỏ, quá trình chọn hàng lặp đi lặp lại cho đến khi người dùng chọn hàng xong. Trong quá trình chọn mua hàng người dùng có thể: Thêm hoặc xố mục hàng. Thay đổi số lượng của một mục hàng trong giỏ hàng. Đồng ý mua mục hàng đó. 2. Khi chọn xong giỏ hàng, hệ thống yêu cầu xác nhận đồng ý mua các mục hàng đó. 3. Nếu người mua chưa đăng nhập thì hệ thống bắt buộc phải đăng nhập. Khi đã đăng nhập rồi thì hệ thống yêu cầu nhập thông tin về thẻ tín dụng, địa chỉ hố đơn, địa chỉ vận chuyển và các thông tin khác. 4. Hệ thống yêu cầu người dùng xác nhận lại những thông tin trên, đồng thời hệ thống thẩm định thông tin đó có hợp lệ hay không. 5. Hệ thống hiển thị một hố đơn cho người mua. 6. Hệ thống gửi một thông điệp xác nhận thông qua email 7. Use case kết thúc. Luồng sự kiện phụ 1. Người dùng mua một mục hàng nào đó với số lượng vượt quá số lượng có trong kho. 2. Thông tin về thẻ tín dụng, địa chỉ hố đơn, email… người dùng nhập vào không hợp lệ. ● Pre – Condition (điều kiện trước):không có. ● Post –Condition (điều kiện sau): một đơn hàng được tạo cho người mua (khách hàng), đơn hàng được gửi đến hệ thống xử lý đơn hàng, hệ thống này xác nhận và thực hiện các bước tiếp theo. Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 43 3.3. Phân tích miền ứng dụng. 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. 3.3.1. Mô hình đối tượng: 3.3.1.1. Tìm các lớp giao diện(interface class) Bước đầu hình thành ý niệm về giao diện, là cửa sổ tương tác giữa hệ thống với người dùng. Chuyển các yêu cầu người dùng vào hệ thống, hệ thống đáp ứng lại thông tin cần thiết mà người dùng mong muốn. Giao diện có thể là các form... 3.3.1.2. Tìm các lớp miền ứng dụng(hay các lớp nghiệp vụ) Các thể hiện của các lớp này là các đối tượng có thể lưu trữ dữ liệu, xử lý các tính tốn nghiệp vụ, xử lý các thông điệp. Đối tượng được tìm như là thực thể tồn tại một cách tự nhiên trong miền ứng dụng. Để tìm đối tượng chúng ta cần rà sốt lại đặc tả yêu cầu từ mô hình use case, để nắm bắt những danh từ chứa khái niệm chủ chốt của ứng dụng. Đồng thời đưa ra những chức năng mà hệ thống cần hỗ trợ. Để tìm đối tượng miền nghiệp vụ (hay miền ứng dụng) ta làm như sau: ● Dùng các luồng sự kiện của Use case như là đầu vào. ● Các trừu tượng hố then chốt của use case. ● 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 giữa các lớp bị loại ra: nếu một trong các lớp của kết hợp đã bị loại bỏ, thì kết hợp phải được loại bỏ, hoặc phát biểu lại bằng các lớp khác. Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 44 - 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à ở ngồ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. 3.4. 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: 3.4.1. 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 Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 45 Address getStreetName1() getStreetName2() getCity () getState() getZipCode() getCountry() (from Uti l i ty) MainForm signin() browsecat al og() updateac count() displaycat al og() displayshop pingc art () search() signout() creat eaccount () ContactInformation telephone email address getEMail() getAddress() getTelephone() (f rom Ut il ity) SignInForm signin() c reate account() enter user name and password() display() display user information() display message() 0..10..1 Account userId password sta tus Contac tInformation create() update() get user info() get email addres s() find account () (from account) Signon username password getPassW ord() updatePassW ord() create() remove() add signin() SigninHandler s ign in user() check password() validate entered username and password() (from P etsto reEJB) 1..* 1 0..1 0..* retrieves userId 1 0..* Hình 3.2 : lược đồ lớp sign in Lược đồ tuần tự của sign in Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 46 : customer : MainForm : SignInForm : SigninHandler : Signon : Account 1://sign in() 2://display() 3://enter user name and password( ) 4://sign in user( ) 5://validate entered username and password( ) 6://find account( ) 7://getPassWord( ) 8://check password( ) 9://add signin( ) 10://display user information( ) Hình 3.3: lược đồ tuần tự của sign in b) Các lược đồ trong sign off Lược đồ lớp của sign off Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 47 Hình 3.4: lược đồ lớp của sign off lược đồ tuần tự của sign off Hình 3.5: lược đồ tuần tự của sign off 3.4.2. các lược đồ trong gói shopping cart Lược đồ lớp shopping cart Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 48 Hình 3.6: lược đồ lớp của shopping cart Lược đồ tuần tự shopping cart Hình 3.7: lược đồ tuần tự của shopping cart như dưới đây Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 49 Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 50 3.4.3. các lược đồ trong gói customer Lược đồ lớp của create account Hình 3.8: lược đồ lớp của create account Lược đồ tuần tự của create account Hình 3.9: lược đồ tuần tự của create account Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 51 Lược đồ lớp của update account Hình 3.10: lược đồ lớp của update account Lược đồ tuần tự của update account Hình 3.11: Lược đồ tuần tự của update account Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 52 CHƯƠNG 4 THIẾT KẾ THÀNH PHẦN Thiết kế là quá trình mở rộng của pha phân tích bằng việc ta thêm vào đó những khía cạnh kỹ thuật. Mục đích của thiết kế là xác định một giải pháp để dễ dàng cho việc mã hố, cũng như những yêu cầu kỹ thuật, công nghệ đặc trưng cho ứng dụng. Vì ở đây ứng dụng được xây dựng theo hướng thành phần (Component), theo đặc tả J2EE. Trước tiên từ pha phân tích ta xây dựng nên các thành phần thuộc tầng nghiệp vụ (business tier). Các thành phần này có chức năng lưu trữ dữ liệu, tính tốn, xử lý nghiệp vụ. Trong tầng này của ứng dụng này ta xây dựng các Entity Bean, Session Bean. Với EJB phiên bản 1.x chưa đưa loại Message Driver Bean vào. 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 tốn, xử lý, không liên quan đến việc lưu trữ dữ liệu. Trước khi đi vào thiết kế chi tiết thành phần, ta phải thiết kế kiến trúc, đây là giai đoạn thiết kế ở mức cao. Thiết kế kiến trúc ta sẽ chọn kiến trúc MVC- Model-View-Controller. Kiến trúc tổng quát này được trình bày như hình dưới đây. Hình 4.1: kiến trúc tổng quát của hệ thống - kiến trúc MVC. Đây là kiến trúc được chọn lựa để xây dựng ứng dụng, đối với các ứng dụng Web, kiến trúc này là lựa chọn tối ưu vì nó giảm tính phức tạp và dễ quản lý hơn. Kiến trúc này tăng cường mức độ bảo trì và mở rộng. Bằng cách tách biệt logic nghiệp vụ và logic điều khiển với sự trình diễn dữ liệu, kiến trúc này cung cấp tính linh động để giải quyết các ứng dụng phức tạp. Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 53 4.1. Thiết kế các thành phần Trong ứng dụng này các Bean thực thể (Entity Bean) đều thuộc loại BMP(Bean Managed Persistent), Bean thực thể tự quản lý. Ở tầng nghiệp vụ (business tier) các Entity Bean thao tác với dữ liệu thông qua lớp DAO (Data Access Object), đây là một chiến lược thiết kế tối ưu. Nó độc lập với các hệ quản trị cơ sở dữ liệu. 4.1.1. Thành phần sign in Sign in là thành phần kiểu Entity Bean (BMP), được thể hiện như sau: Hình 4.2: mô hình EJB của signin. Sự giao tiếp giữa EJB với lớp DAO như sau Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 54 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 4.1.2. Thành phần shopping cart a) Thành phần catalog Catalog là thành phần thuộc kiểu Session Bean- SB (là Stateless Session Bean), là Bean thao tác phi trạng thái. Sơ đồ của nó được trình bày như sau: Hình 4.4. sơ đồ thành phần EJB của catalog Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 55 Sự giao tiếp giữa catalogEJB với các lớp liên quan. Hình 4.5: quan hệ giữa thành phần catalogEJB với các lớp ngiệp vụ liên quan Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 56 b) Thành phần shopping cart Là thành phần thuộc kiểu Stateful Session Bean, là Bean lưu vết trạng thái, được trình bày như sau: Hình 4.6: sơ đồ EJB của shopping cart Quan hệ giữa shoppingcartEJB với các lớp nghiệp vụ khác được trình bày như sau: Hình 4.7: quan hệ giữa shoppingcartEJB với các lớp nghiệp vụ liên quan 4.1.3. Thành phần inventory Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 57 Là thành phần thuộc loại Entity Bean, Bean thực thể. Sơ đồ của nó được thể hiện như sau: Hình 4.8: sơ đồ EJB của thành phần Inventory Quan hệ giữa inventoryEJB với lớp DAO được thể hiện như sau: Hình 4.9: quan hệ giữa inventoryEJB với lớp inventoryDAO, inventoryModel 4.1.4. Thành phần customer Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 58 a) Thành phần order: là thành phần thuộc loại Bean thực thể (Entity Bean). Nó được trình bày như sau: Hình 4.10: sơ đồ EJB của thành phần order Quan hệ giữa orderEJB với các lớp DAO và các lớp nghiệp vụ như sau: Hình 4.11: quan hệ giữa orderEJB với lớp DAO, Model và các lớp nghiệp vụ khác b) Thành phần customer Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 59 Là thành phần thuộc loại Stateless Session Bean, Bean thao tác phi trạng thái. Được trình bày như sau: Hình 4.12: sơ đồ EJB của thành phần customer b) Thành phần account Là thành phần thuộc loại Entity Bean, Bean thực thể này được trình bày như sau: Hình 4.13: sơ đồ EJB của thành phần account Quan hệ giữa accountEJB với các lớp DAO và các lớp khác được trình bày như sau: Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 60 Hình 4.14: quan hệ giữa accountEJB với các lớp DAO, Model 4.2. Biểu đồ thành phần của các thành phần nghiệp vụ ở tầng business tier Hình 4.15: biểu đồ thành phần của các thành phần nghiệp vụ Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 61 CHƯƠNG 5 THIẾT KẾ HIỆN THỰC HÓA CÁC USE CASE Chương này chúng ta đi vào thiết kế tồn diện để hiện thực hóa các use case. Trong phần thiết kế này chúng ta tuân theo giải pháp đã chọn ở chương 4, tức theo kiến trúc MVC- Model-View-Controller. Trong đó Model là các thành phần (các Enterprise Java Bean) thuộc tầng nghiệp vụ (business tier). View là các trang JSP và các lớp JavaBean, cái này thuộc tầng Web (Web tier). Controller là các lớp điều khiển và các EJB mà hoạt động như thành phần điều khiển. Nó tách giữa Web tier và EJB tier và đứng giữa để làm cầu nối cho hai tầng này. Theo kiến trúc MVC như hình 4.1 ở chương bốn, ta đi vào thiết kế cho các use case của ứng dụng. 5.1. Thiết kế hiện thực hóa các use case 5.1.1. Thiết kế hiện thực hóa use case sign in Hình 5.1: lược đồ lớp của Sign in Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 62 Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 63 Hình 5.2: lược đồ tuần tự của sign in (phần 1) : MainForm : customer : Template : ScreenDefinitions : ScreenFlowManager : SignInForm : SignInSuccessForm 1://signin( ) 2://forward(req,resp) 3://include 4:// getSigninScreen( ) 5://display( ) 6://display Hình 5.3: lược đồ tuần tự của sign in (phần 2). 5.1.2. Thiết kế hiện thực hóa use case create account Hình 5.4: lược đồ lớp của create account Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 65 Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 66 Hình 5.5: lược đồ tuần tự của create account (phần 1) Hình 5.6: lược đồ tuần tự của create account (phần 2) Các lược đồ còn lại của các use case khác được trình bày ở phần phụ lục. Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 67 CHƯƠNG 6 THỰC HIỆN CÀI ĐẶT VÀ TRIỂN KHAI ỨNG DỤNG 6.1.Thực hiện cài đặt Ở pha này ta tiến hành mã hố hệ thống. Trong hệ thống e-store này ta dùng ngôn ngữ Java, với công nghệ EJB 1.x ở tầng nghiệp vụ (business tier) để mã hố. Ở tầng Web (Web tier) ta dùng công nghệ JSP, Servlet, JavaBean để mã hố. Ở tầng cơ sở dữ liệu EIS (Enterprise Information System tier) ta dùng hệ quản trị cơ sở dữ liệu Cloudscape tích hợp trong J2EE Server. Lược đồ thành phần của cả hệ thống trình bày dưới đây: H ình 6.1: lược đồ thành phần của hệ thống. 6.2. Một vài giao diện của ứng dụng Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 68 Hình 6.2: form đăng nhập vào hệ thống Hình 6.3: Form hiển thị các sản phẩm Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 69 Hình 6.4: form hiển thị thông tin mục hàng Hình 6.5: hiển thị giỏ hàng Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 70 Hình 6.6: hiển thị đơn hàng vừa đặt 6.3. Triển khai hệ thống Hình 6.7: lược đồ triển khai hệ thống E-store Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 71 KẾT LUẬN Đồ án tốt nghiệp này em đi vào tiếp cận công nghệ J2EE, công cụ UML, Rational Rose. Các công nghệ, công cụ này tương đối mới nhưng em đã cố gắng tìm hiểu. Trong đồ án này, em xây dựng một ứng dụng J2EE cùng với Rational Rose và UML. Ứng dụng này mang tính demo, chưa thành một hệ thống hồn chỉnh vì đây chỉ là một phần của hệ thống thương mại điện tử. Mặc dù đã cố gắng nhưng em chỉ mới giới thiệu về công nghệ J2EE, UML.... Những kiến thức này hết sức tổng quát, với số lượng công nghệ mới khá nhiều nên không thể nắm bắt một cách chi tiết hết được. Trong thời gian ngắn em đã tiếp cận các công nghệ trên, khó tránh những sai sót, rất mong thầy hướng dẫn tận tình chỉ bảo, cũng như đánh giá, nhận xét. Em chân thành cảm thầy Nguyễn Thanh Tùng đã hướng dẫn và giúp em hồn thành đồ án này. Em xin cảm ơn thầy cô khoa Công nghệ thông tin trường Đại Học Bách Khoa Hà Nội, trường Đại Học Thủy Sản Nha Trang đã giúp em trong quá trình làm đồ án. Đồ án tốt nghiệp - Xây dựng ứng dụng J2EE với Rational Rose và UML Trang 72