Prototype 1.0 Specification

Transcription

1 Prototype 1.0 Specification Javier Ramos Rodríguez Use Case View The prototype 1.0 will implement some basic functionality of the system to check if the technology used is the appropriate one to implement the final version. Also, the prototype will allow us to discover errors in early stages of the development. The prototype implements a small administration module and some functionalities of the registered user which are: send and read messages, create and view events and also the login and logout. Administration Module <<include>> Create User Check Fields Administrator View Users <<extend>> Delete Users The administration part is quite simple. The administrator can register users in the application, view the different user that are registered and delete them. The system will check that the administrator introduces the correct data checking for example that the user login is not already in use or that the address is valid. Note that in the actual system implementation the user will register himself in the application and not the administrator. 1

2 User Module <<include>> Check Form Fields Login User <<extend>> Registered User Package Log out The user can log in or log out the application. In the log in the system will check that the appropriate fields are filled and then check that the login and password are correct according with information stored in the system. If so, the user will change his/her role to Registered User and he/she will be able to access the functionalities available in the Registered User Package 2

3 Registered User Package View Events <<extend>> View Event <<include>> Create Event <<include>> Registered User Check Form Fields Send Message Read Messages <<extend>> Read Message The Registered User has the possibility to view and create the different events or news. In the prototype the events will only have to visibilities: public and private. Public information will be available for all the users including the Guess users. Private information can be accessed only view Registered Users. In the final implementation the private information will be accessed in many different ways allowing users to receive the news from subgroups of Registered Users. For example, the user can specify that he only want to get the news only from people of his/her class or news in a certain language. Registered Users can also send and read messages. 3

4 Architecture CLIENT TIER PRESENTATION TIER APPLICATION TIER DATA TIER WEB BROWSER JSF EJB Administrator Registered User Controller Session Bean ORACLE DB Unregistered User View Entity Bean This is the architecture used in the application which is explained in the vision document. In the prototype JDeveloper is used as IDE. 4

5 The next figure shows the adaptation of this general architecture to the prototype: View Model / Logic JSP Page Registered User (from Use Case View) Page_Controller Model Facade / Business Delegate Event Session Bean App_User Session Bean Message Session Bean Event Entity Bean App_User Entity Bean Message Entity Bean The user will interact with the system using a Web browser. JSP pages will be used to dynamically generate the view. Each JSP page has a Java class associated that will perform some logic related to the view and it will be also the page controller. Note that the JSF is an implementation of the MVC pattern. In the Web container configuration file (web.xml) we specified that all request should be handled by the JSF configuration file (faces-config.xml) which implements the front controller pattern acting as the main controller. So, the user interacts with the JSP pages and sends a request that is handled by the controller that can perform an initial check on the data. The controller will call the model. 5

6 A Java class that implements the facade and business delegate design patterns will handle all the request from the view and will be in charge of controlling the different request but it will no perform any business logic, it will delegate the logic to the session beans that will implement the remote interface allowing this to distribute the beans in different machines to increase the performance and scalability. The session beans will implement the Data Access Object (DAO) pattern and will be the ones who will manage the Entity Beans which implement the Value Object (VO) pattern. We use CMP entity beans, so there will be no custom VO in the prototype allowing this to use reverse engineering to create the Entity Beans from the tables in the database. The persistence will be handled by the persistence manager as defined in the EJB 3.0 specification. The EJB 3.0 specification uses an Object-Relational mapping approach just like Top-Link or Hibernate does. JDeveloper implements the persistence manager using Top- Link. I used named queries in the Entity Beans, so there s no SQL code in the Session Beans. The Session Beans will use the persistence manager object to save the VO. 6

7 The page flow diagram (faces-config.xml) is show in the next figure: 7

8 Database Tables 1. Application User Table (APP_USER): 2. Event Table (EVENT): 3. Message Table (MESSAGE): 8

9 Prototype Design In the next figure we show a more specific example of how the prototype works: 9

10 Let s look at the situation where the user fills out a form to publish a new event. The form is shown in a JSP page using standard JSF tags and no Java code to separate the view from the model allowing this to have designer with no knowledge of programming design the view independently from the model which is a programmer s jobs. This will help to increase the reusability, scalability and role separation. When the user submit the information the request is handled by the corresponding controller which implement the corresponding submit method. This is somehow similar to the Struts framework when using Action classes. So, in the method we call the model to perform the desire operation but first we check that the fields were filled properly, if not, we will inform the user. If all the fields are correct, the controller will extract the information from them and call the method createevent() from the model facade. The model facade will receive the request with all the information in the parameters. To avoid overloading this class, we don t implement any business logic here, so this class will be in charge to find the remote Session Beans using JDNI and call the Session Beans to perform the desire operation. In this case, the model facade will perform a look up in the name service to find the EventSessionBean and then call the method createevent() in the EventSessionBean. The EventSessionBean will create an Event object (Entity Bean) and then using the parameters from send in the method call it will set the different attributes of the Entity Bean using the java.util.date package to generate the current date. Once the object is set, the Session Bean will use the EntityManager object to save the information in the database by calling EntityManager.persist(Event); 10