Evaluating a Reference Enterprise Application as a Teaching Tool in a Distributed. Enterprise Computing Class THESIS

Transcription

1 Evaluating a Reference Enterprise Application as a Teaching Tool in a Distributed Enterprise Computing Class THESIS Presented in Partial Fulfillment of the Requirements for the Degree Master of Science in the Graduate School of The Ohio State University By Niranjan Konda Graduate Program in Computer Science and Engineering The Ohio State University 2013 Master's Examination Committee: Dr. Rajiv Ramnath, Advisor Dr. Jay Ramanathan

2 Copyright by Niranjan Konda 2013

3 Abstract The difference between academic projects in colleges and enterprise projects in industry is quite significant. Students working on academic projects are not accustomed to enterprise applications: their challenging technology stacks and complex architectures and, do not follow most of the industry best practices and techniques that accompany typical enterprise applications. When they transition to industry they face a steep learning curve which could be quite challenging. The idea is to build a reference enterprise application that could demonstrate to students complex technology stacks and architectures, industry best practices like supporting documentation and code commenting along with techniques like logging. To effectively demonstrate the above mentioned goals, firstly, a reference enterprise application, the Buckeye Job Portal, was created. Later, a course lecture was created demonstrating all the various technologies in use in the application. Learning outcomes were determined based on the Bloom s taxonomy classification and an experimental protocol was created, that contained specific, hands-on tasks related to the application keeping in mind these learning outcomes. A sample student group was provided with the course lecture and made to work on the experimental protocol. Observations were made during the process and feedback collected. Results showed that, in general, the student group was successful in creating a new development environment along with importing and running the existing ii

4 reference Buckeye Job Portal enterprise application. They were also able to modify and add new functionality to the application thereby demonstrating a good grasp of all the enterprise application concepts. iii

5 Dedication This document is dedicated to my Mother and to my Father. iv

6 Acknowledgments I would like to thank my Professor Dr. Rajiv Ramnath for all the guidance and help he provided throughout my work on this Thesis. I would also like to thank my other thesis committee member Dr. Jay Ramanathan for the discussions and insights provided. v

7 Vita B.Tech. IT, NITK, Surathkal 2011 to present...graduate Teaching Associate, Department of Computer Science and Engineering, The Ohio State University Fields of Study Major Field: Computer Science and Engineering vi

8 Table of Contents Abstract... ii Dedication... iv Acknowledgments... v Vita... vi Fields of Study... vi Table of Contents... vii List of Tables... xi List of Figures... xii Chapter 1: Introduction Related Work: Bloom s Taxonomy: Thesis Statement:... 5 Chapter 2: Contributions... 7 Chapter 3: Buckeye Job Portal Application Buckeye Job Portal Application Environment vii

9 3.2.1 JavaServer Faces (JSF): JSF Lifecycle: AJAX: (Partial Processing and Partial Rendering) Enterprise JavaBeans: Job Portal Architecture: Rendering on a client or web browser: The Lifecycle of a Facelets Application: Non-functional requirements (NFR) demonstrated: Usability: Buckeye Job Portal Project Structure: Example-EJB-Session-Entity: JobPortal: Class Model: Database Schema: Buckeye Job Portal Use Cases: Employee Use Cases: Employer Use Cases: Buckeye Job Portal Screens: The Register Screen: viii

10 3.9.2 The Login Screen: The Employee Welcome Screen: The Search Results Screen: The Jobs Applied Screen: The Employer Welcome Screen: The Employer Profile Screen: The Search Candidates Screen: The Candidates Found Screen: Chapter 4: Course Lecture Chapter 5: Buckeye Job Portal Experimental Protocol Bloom s Taxonomy Applied to the Experimental Protocol: Survey Monkey Questionnaire: Profile Information Retrieval: Retrieval of Feedback for Each of the Individual Tasks Retrieval of Final Feedback for the Entire Exercise: Chapter 6: Results Observations: Conclusion: Chapter 7: Future Work ix

11 References Appendix A: Survey Monkey Responses Appendix B: Course Lecture x

12 List of Tables Table 1: Learning outcomes vs Application features Table 2: Iteration 1, Student Table 3: Iteration 1, Student Table 4: Iteration 2, Student Table 5: Iteration 2, Student xi

13 List of Figures Figure 1: JSF Lifecycle Figure 2: Job Portal Architecture Figure 3: Use of radio buttons to enhance usability Figure 4: Use of drop down menus to enhance usability Figure 5: Log File Output Figure 6: Code comments (text in green) in the application code Figure 7: Buckeye Job Portal Components Figure 8: Example-EJB-Session-Entity Structure Figure 9: XHTML Pages or Screens Figure 10: Page Backing Beans Figure 11: faces-config.xml Figure 12: JSF Templates Figure 13: Linkage between the Front and Back End Figure 14: Class Model Figure 15: DB Schema Figure 16: The Register Screen Figure 17: The Login Screen Figure 18: The Employee Welcome Screen xii

14 Figure 19: The Search Results Screen Figure 20: The Jobs Applied Screen Figure 21: The Employer Welcome Screen Figure 22: The Employer Profile Screen Figure 23: The Search Candidates Screen Figure 24: The Candidates Found Screen Figure 25: Basic information about Session Beans Figure 26: Code Level Example for Entity Beans Figure 27: Communication between Backing and Session Bean Figure 28: Survey Monkey Profile Collection Figure 29: Survey Monkey Profile Collection Figure 30: Survey Monkey Task Feedback Figure 31: Survey Monkey Task Feedback Figure 32: Survey Monkey Tasks Completion Feedback Figure 33: Survey Monkey Tasks Completion Feedback xiii

15 Chapter 1: Introduction The differences between academic and industrial projects are quite immense. In the existing Computer Science (CS) curricula examined in this thesis, attempts to educate students on various technologies and software techniques do not provide concrete methodologies where by the concepts of Enterprise Computing are effectively demonstrated to students. By concepts, in this thesis, the emphasis is on end-to-end technology stacks currently in use in most industries and enterprise computing standards like logging, code readability and use of supporting technical documentation. When a student joins industry, he or she would, more often than not, begin working on existing code bases and technology stacks, and would rarely be required to define a new architecture, or develop the application from scratch. On joining a team or project in industry, coming up to speed with the application s current underlying architecture and general project setup is a daunting task. In addition, the extreme difficulty in mapping the tasks assigned on the job to specific software modifications/additions, in the current repository of software, due to unfamiliarity with domain-specific knowledge and proper documentation, frequently leads new programmers/employees to become disheartened. In order to mitigate the above concerns, this thesis proposes the creation of a Reference Enterprise Application, with specific attention to the use of state-of-the-art and 1

16 end-to-end technology stacks and industry best practices, which mimic the complex realworld enterprise applications in industry. These industry best practices will include incorporation of software development life-cycle (SDLC) techniques with emphasis on logging, code readability and ample use of supporting technical documentation. In addition, a course lecture, of all the technologies used in the application, with concrete examples from the application itself, will be created to help students get introduced to these technologies. Emphasis will be placed on the importance of individual technology components and how the various components of the stack fit together. Along with the Reference Enterprise Application and course lecture, an experimental protocol will be created that contains certain tasks involving modifications to the existing application. A sample student group who will be provided with the course lecture and introduced to the reference application will be assigned to complete the protocol. After working on these tasks, the group will then be surveyed to collect information related to their experiences from start to finish. The survey will begin by evaluating the lecture slides and continue through the whole process of working on the tasks. An analysis of these survey responses in combination with personal observations made while they are working on their tasks will be used to evaluate the utility of the course lecture slides and the Reference Enterprise Application. 2

17 1.1 Related Work: A course consisting of a software engineering project is often part of the curriculum for computer science students in colleges. Data analyses show that academic projects are found to be strongly dominated by programming activities [1]. The emphasis on standard industry best practices like testing, documentation, review and code commenting is very low. Modern businesses do not exist without distributed enterprise applications [2]. When a student joins industry they will surely end up being in an enterprise application project. These projects are of very complex nature with a wide range of technologies constituting the technology stack of the application. The lack of experience in working with these technologies, the complexity in the nature and characteristics of enterprise applications along with the need to come up to speed with all the standard industry best practices in a short period of time can be quite a challenge for students. Martin Fowler describes some of the characteristics that are typical for enterprise applications: [3] 1. A lot of Persistent data 2. High volume of concurrent data access 3. Large number of user interface screens 4. Integration with other systems 3

18 If a reference enterprise application is created incorporating these characteristics it can serve to be a useful tool for demonstration to the students. Learning tools and experiments have been developed in the past to demonstrate software concepts to students. If the experiment can be made to involve certain specific tasks that enable the students to get a hands-on experience on the application it can prove to be a very useful medium, to demonstrate thoroughly, enterprise concepts. For experiments involving creation of learning tools, the learning outcomes can be defined and then be evaluated using classifications such as Bloom s Taxonomy [4]. 1.2 Bloom s Taxonomy: For students in the education process, Bloom s Taxonomy is a classification of learning objectives. The objectives are divided into the three following domains. 1) Cognitive - knowing 2) Affective - feeling 3) Psychomotor - doing The higher level domains depend on the knowledge and skills acquired at the lower levels. Ideally, the learning outcomes from all three domains need to be adopted to make the approach toward education complete. The Cognitive domain has the following 6 levels: 1. Knowledge: Recalling of facts, terms and answers from previous learning. 4

19 2. Comprehension: Interpreting, comparing and stating ideas showing understanding of ideas and facts. 3. Application: Solving of problems by applying facts, knowledge and techniques learnt previously. 4. Analysis: Ability to make inferences; Capacity to break information into parts by identifying motives. 5. Synthesis: Providing alternative solutions; Combining information in new and different ways. 6. Evaluation: Judging quality of work; Validation of ideas; Using information to present opinions. Once the experiment is created, based on Bloom s classification, it has to be evaluated to check if it is indeed able to meet the desired learning outcomes. Conclusions are drawn based on observations made on test subjects, and later changes made based on these observations [5]. The experiments performed could have multiple iterations and better themselves by applying results and observations from the previous iteration, in the current iteration, thereby highly streamlining the whole experimental process. 1.3 Thesis Statement: To build and evaluate a Reference Enterprise Application as a Teaching Tool in the Distributed Enterprise Computing class which will enable students to come up to speed, 5

20 with ease, on various technologies, tools, methodologies and techniques that are a norm in standard Enterprise Applications Worldwide. 6

21 Chapter 2: Contributions J2EE Technologies Lecture Slides: Course lecture slides detail the technologies in use in the Buckeye Job Portal application with emphasis on code level examples of the individual technologies along with examples of how the various technologies communicate with each other. Buckeye Job Portal Installation Document: The installation document consists of step by step instructions for setting up the development environment for the application along with instructions to import and run the existing application. It also has explanations about the project structure of the application and other related project settings and configurations. Buckeye Job Portal Experimental Protocol Document: The experimental protocol document contains specific tasks for the students to work on, designed to add functionality to the existing Buckeye Job Portal application. These tasks ensure that the students get their hands on all the underlying technologies in the application. Buckeye Job Portal Technical Handbook Document: The technical handbook consists of various code level examples related to the various technologies, especially in the context of the Buckeye Job Portal application. It is more 7

22 like a help file, with various frequently asked questions, regarding the technologies or their use at the code level, and their corresponding solutions. Buckeye Job Portal Showstoppers Document: The showstoppers document consists of various common pitfalls, that a developer might come across, when working on the specific technologies that are in use in the Buckeye Job Portal application. These pitfalls have been arrived upon, through observation and feedback from student volunteers who worked on specific tasks related to these technologies. The purpose of this document is to enable future users to avoid/overcome the hassles faced by their predecessors, by documenting/providing solutions to commonly occurring problems. Buckeye Job Portal Survey: The Buckeye Job Portal survey was created using the online tool Survey Monkey and used to collect profile information and feedback of student volunteers who worked on the tasks in the Job Portal experimental protocol. The survey utilized key features like check boxes, radio buttons, rating scales, and description boxes to ensure the survey was user friendly and also to enable specific and accurate retrieval of information from the students. Bundled Buckeye Job Portal Application and Enterprise Application Skeletal Framework Zip Files: The Buckeye Job Portal Reference Application zip file is basically the entire application in zip format, that can be easily imported once the development environment is set up, and comes ready to run. The Enterprise Application Skeletal Framework zip file 8

23 is a basic, working and end to end application structure consisting of JSF, AJAX and EJB technologies that can be used as a platform by developers to build any type of application. It is meant to act as a springboard for developers to ease their transition into the new technology stack. 9

24 Chapter 3: Buckeye Job Portal Application The Buckeye Job Portal application provides the basic functionality that one would expect from a job search application. It enables users to register and login as either an Employee or an Employer. Users with Employee privileges can search for Jobs of their choice based on criteria like job location, job title, technology, etc. Users can also apply for jobs they find suitable and check on jobs they have applied for in the past. Furthermore, they could update their profile page to include their interests in terms of location, title, and technology to make them more visible to Employers looking for suitable candidates. The Employers, on the other hand, can post new jobs on the application, and look at various jobs that they might have posted in the past. In addition, the Employer could search for suitable candidates based on certain criteria. Over all, the Buckeye Job Portal application provides the basic functionality that one would expect from a job search engine including options to add new functionality, if need be, in the future. 10

25 3.1 Buckeye Job Portal Application Environment The platform used for development of the Buckeye Job Portal application is the Java 2 Enterprise Edition Platform (J2EE) which is meant for developing enterprise applications and offers various features like high performance, scalability, security and flexibility. J2EE is also multi-platform and provides support for both Language and Web Services [6]. The Integrated development environment (IDE) used for coding, testing and debugging of the application is Eclipse Kepler which though is a multi-language IDE is more suitable for developing Java applications. It has extensible plug-ins with good support for server and web tools platforms. The application server used for this project is JavaBeans Open Source Software Application Server (JBOSS) It is a crossplatform server that implements the J2EE platform and provides various features like distributed deployment, clustering and load balancing. The database server used in this project is the H2 (version ) server which is a very fast and open source Java SQL database which can run in both Embedded and Server modes. 3.2 Buckeye Job Portal Technologies: The Buckeye Job Portal project consists of the following primary technologies: an Enterprise JavaBeans (EJB) backend and a JavaServer Faces(JSF) frontend. The JSF component consists of: XHTML Pages/Facelets which comprise the View, page backing beans that comprise the model and a FacesServlet which acts as the controller, thereby 11

26 forming a Model-View-Controller (MVC) pattern. The EJB backend consists mainly of Session and Entity beans. The session beans support all the business logic whereas the entity beans model the business objects JavaServer Faces (JSF): JavaServer Faces is a server-side UI component framework technology for Javabased web applications and is part of the Java Platform, Enterprise Edition [7]. It provides a neat separation between the presentation and behavior components that is normally a feature of architectures on the client side [8]. Facelets is the default view handler technology for JSF and is responsible for building the JSF UI component tree with built in support for all the JSF UI components. Earlier JSP was the default view handler technology in JSF 1.0. JSP is a Java program that generates web content for the user by use of a servlet. On the other hand Facelets provide a way to add Java modules into XML code which greatly simplifies the creation of the view in JSF. The fact that the life cycle of the JSF components is independent of the life cycle of the JSP servlet gives rise to complications. Facelets, through the use of UI component trees, allows for greater reuse as components can be composed out of a composition of other components. Facelets is a templating language that was built keeping in mind the JSF component life cycle and was made the official view technology for JSF 2.0 [9]. 12

27 JSF managed beans that are associated with the UI components used in a particular page are called page backing beans and form the Model in a JSF application. The request processing lifecycle of the JSF application is managed by a servlet called the FacesServlet and forms the controller component. The FacesServlet utilizes the facesconfig.xml file to determine all the page navigation rules and also to take care of the state management of the page backing beans JSF Lifecycle: The lifecycle of a JSF application starts with the client making a HTTP call for a page and finishes when the server responds with the translated HTML page. The lifecycle consists of two main parts, execute and render. A JSF page consists of a component tree which constitutes the view and in the lifecycle JSF must construct this view using previously saved page states. Tasks such as data validations and conversions are performed on the UI components during the life cycle. The execute phase can be further broken down as: (figure 1 [10]) Restore View Phase - builds the view of the page Apply Request Values Phase - each tree component extracts its new value from the request parameters 13

28 Process Validations Phase - performs all the validations that are set on the user interface components Update Model Values Phase - updates the backing bean (model) values based on the user interface component values in the tree Invoke Application Phase - handles all the events at the application level like form submissions and page navigations Render Response Phase - builds the view and transfers control to facelets to render view 14

29 Figure 1: JSF Lifecycle 15

30 3.2.3 AJAX: (Partial Processing and Partial Rendering) AJAX is an acronym for Asynchronous JavaScript and XML and is a set of clientside web development techniques used to make asynchronous(though synchronous requests are possible too) web applications. This means that applications can send and receive data from the server asynchronously (in the background) while ensuring that the display of the page is not affected. JSF 2 comes with a tag called f:ajax that provides Ajax functionality. Specific UI components can be processed and rendered during the JSF life cycle thereby enabling asynchronous behavior Enterprise JavaBeans: Enterprise JavaBeans (EJB) is a server side architecture for construction of enterprise applications in a modular fashion and contains the business logic of an application. EJB handles challenges such as transaction management, persistence and security thereby helping developers to focus more on the business logic part. EJBs could be of Session, Entity or Message Driven Bean type. The session beans support all of the backend business logic whereas the entity beans model the real world business objects. Message driven beans are similar to session beans but are executed by messages and not method calls and thereby supports asynchronous execution. 16

31 3.3 Job Portal Architecture: The Buckeye Job Portal application is based on a model-view-controller (MVC) architecture (Figure 2). The JobPortal component of the project is a JSF based project which in turn is a MVC framework with the FacesServlet being the Controller and the XHTML pages along with the JSF tag libraries constituting the View. The FacesServlet with the help of the faces-config file handles all the HTTP request and HTTP response work. Facelets is the default view handler technology for JavaServer Faces 2.0 and takes care of building the UI component tree and rendering of the view. The Java page backing bean classes along with the Session and Entity beans (EJB component of the project) constitute the Model. The H2 database forms the data source for the application and runs on a separate database server as compared to the application which runs on the JBoss application server. 17

32 Figure 2: Job Portal Architecture Rendering on a client or web browser: Facelets is responsible for the rendering of the view on the client browser but in order for JSF to use Facelets as its view handler the following change has to be made to the faces-config.xml. <faces-config> <application> 18

33 <view-handler> com.sun.facelets.faceletviewhandler </view-handler> </application> </faces-config> The Lifecycle of a Facelets Application: Facelets is the default view handling technology for JSF. Below is how Facelets interacts with the JSF life cycle to enable rendering of the view on the client browser [11]: New UI tree constructed and placed in FacesServlet controller when client makes request. This UI tree now applied to Facelets which in turn populates view with components. Actual rendering of constructed view onto client State of UI components stored for next request Saved view restored based on client interaction New view created or current view re-rendered based on result of applying restored view again onto JSF lifecycle Stored view re-rendered if the same view is re-requested 19

34 For a new view request, step 2 is performed New view rendered back as response to browser. 3.4 Non-functional requirements (NFR) demonstrated: NFRs form an integral part of enterprise applications and constitute the nonbehavioral or quality goals of the application. They include requirements such as availability, maintainability, modifiability, usability etc. For the Buckeye Job Portal reference enterprise application the following NFRs were tackled and demonstrated to the students: Usability: Usability is the ease with which an end user can use a software application. The Buckeye Job Portal application demonstrates usability by use of UI components such as radio buttons (Figure 3) and drop down menus (Figure 4), that are both, intuitive to the user and also enhance user experience. 20

35 Figure 3: Use of radio buttons to enhance usability Figure 4: Use of drop down menus to enhance usability Maintainability: Maintainability is the ease of maintaining a software product. The Buckeye Job Portal application demonstrates maintainability by use of Logging (Figure 5) - which can be used to determine and fix software bugs or defects, supporting documentation (Installation, Technical Handbook and Showstoppers documents) - that help with 21

36 environment setup, installation, modification, maintenance and running of the application and code comments (Figure 6) that greatly enhance code readability. Figure 5: Log File Output 22

37 Figure 6: Code comments (text in green) in the application code 3.5 Buckeye Job Portal Project Structure: The Buckeye Job Portal project is organized into two main components: The Example-EJB-Session-Entity, Enterprise JavaBeans backend, and the JobPortal, JavaServer Faces frontend (Figure 7). The backend hosts the Session Beans and the Entity Beans. The Session Beans are where most of the business logic resides. The Entity Beans represent the business objects for persistent storage. The front end consists of various XHTML screens/pages along with the page backing beans and navigation rules 23

38 for screen navigation. The two components are linked by exporting the Example-EJB- Session-Entity component as a jar file and adding it to the WebContent/WEB-INF/lib folder of the JobPortal component. Figure 7: Buckeye Job Portal Components Example-EJB-Session-Entity: The Example-EJB-Session-Entity component contains the Enterprise JavaBeans and constitutes the back end of the Buckeye Job Portal application. Under the EJB Module source folder there are two packages: examples.cse769.ejb.entity and examples.cse769.ejb.service. The former package contains all the entity beans required for the application, and the latter package holds all the session beans used in the application (Figure 8). 24

39 Figure 8: Example-EJB-Session-Entity Structure JobPortal: The Job Portal component consists of a JSF project and constitutes the front end of the application. The primary parts of this component are the XHTML screens/pages, the page backing beans, and the faces-config.xml file. The faces-config.xml file assists the FacesServlet controller in making page navigation decisions and in managing the 25

40 page backing bean life cycles. The XHTML screens structure is shown in Figure 9, the page backing beans structure in Figure 10, and the faces-config.xml file location in Figure 11. Figure 9: XHTML Pages or Screens 26

41 Figure 10: Page Backing Beans Figure 11: faces-config.xml 27

42 The ui:composition tag in the XHTML pages defines where the FacesServlet has to look to generate the page structure/layout while constructing the UI component tree for all the screens/pages. <ui:composition template="/web-inf/templates/basictemplate.xhtml"> Furthermore, the BasicTemplate itself makes use of the header and footer templates while defining its own page construction. These templates are placed under the WEB-INF/templates folder (Figure 12). Figure 12: JSF Templates The EJB back end and the JSF front end are linked together by placing the exported Example-EJB-Session-Entity jar file in the lib folder of the JSF JobPortal component (Figure 13). 28

43 Figure 13: Linkage between the Front and Back End 3.6 Class Model: The class model diagram in Figure 14 shows the relationship among the various classes in the Buckeye Job Portal application, along with their corresponding member variables, and methods to interact with the other classes in the application. 29

44 Figure 14: Class Model 3.7 Database Schema: The Buckeye Job Portal database consists of four tables: User, Job Listing, Job Apply and User Profile (Figure 15). All the fields in the tables are of type String except for the ID fields, which are of type Long and autogenerated. 30

45 Figure 15: DB Schema 3.8 Buckeye Job Portal Use Cases: A use case is a single task, performed by the end user of a system that has some useful outcome. [12] The goals of creating use cases are: to get a better understanding of the problem or task at hand, to make sure that the program or application is actually doing something useful for the user and to provide a road map for the software development process. A formal use case consists of several components: name, description, actors - list of the actors who communicate with the use case, priority - how 31

46 important the use case is to the project (measured on a scale of 5 in this application, progressing from lowest to low to moderate to high to highest importance), status - stage of development of the use case, pre-conditions - list of conditions that must be true before the use case starts, post-conditions - list of conditions that must be true when the use case ends [13]. The use cases for the Buckeye Job Portal application have been divided into two categories: the Employee use cases and the Employer use cases Employee Use Cases: 1) Name: Employee Registers on the Buckeye Job Portal. Description: A new employee registers himself on the Buckeye Job Portal by providing a username, password and user type. Actors: Employee, Buckeye Job Portal Priority: 3/5 Status: Complete Pre-Conditions: 32

47 Buckeye Job Portal up and running; H2 Database Server up and running; Employee not registered on the Buckeye Job Portal. Post-Conditions: Employee is successfully registered on the Buckeye Job Portal. 2) Name: Employee Logs On to the Buckeye Job Portal Description: The employee logs on to the Buckeye Job Portal by providing his username, password and user type credentials. Actors: Employee, Buckeye Job Portal Priority: 3/5 Status: Complete Pre-Conditions: Buckeye Job Portal up and running; H2 Database Server up and running; Employee is not logged in Post-Conditions: Employee successfully logs in to the Buckeye Job Portal 33

48 3) Name: Employee Logs Out of the Buckeye Job Portal Description: The employee logs out of the Buckeye Job Portal Actors: Employee, Buckeye Job Portal Priority: 3/5 Status: Complete Pre-Conditions: Buckeye Job Portal up and running; H2 Database Server up and running; Employee is logged in. Post-Conditions: Employee successfully logs out of the Buckeye Job Portal. 4) Name: Employee searches for a Job Description: The employee searches for a job on the Buckeye Job Portal. 34

49 Actors: Employee, Buckeye Job Portal Priority: 5/5 Status: Complete Pre-Conditions: Buckeye Job Portal up and running; H2 Database Server up and running; Employee is logged in; Jobs posted by Employers on the Portal. Post-Conditions: Employee is able to view relevant jobs on the Buckeye Job Portal. 5) Name: Employee Applies for a Job Description: The employee applies for a job on the Buckeye Job Portal. Actors: Employee, Buckeye Job Portal Priority: 5/5 Status: 35

50 Complete Pre-Conditions: Buckeye Job Portal up and running; H2 Database Server up and running; Employee is logged in; Job Listings present in search results. Post-Conditions: Employee successfully applies for said job on the Buckeye Job Portal. 6) Name: Employee Updates Profile Description: The employee successfully updates his profile information on the Buckeye Job Portal. Actors: Employee, Buckeye Job Portal Priority: 4/5 Status: Complete Pre-Conditions: Buckeye Job Portal up and running; H2 Database Server up and running; Employee is logged in. Post-Conditions: 36

51 Employee successfully updates his profile on the Buckeye Job Portal Employer Use Cases: 1) Name: Employer Registers on the Buckeye Job Portal Description: A new employer registers himself on the Buckeye Job Portal by providing a username, password and user type. Actors: Employer, Buckeye Job Portal Priority: 3/5 Status: Complete Pre-Conditions: Buckeye Job Portal up and running; H2 Database Server up and running; Employer not registered on the Buckeye Job Portal. Post-Conditions: Employer is successfully registered on the Buckeye Job Portal. 37

52 2) Name: Employer Logs On to the Buckeye Job Portal Description: The employer logs on to the Buckeye Job Portal by providing his username, password and user type credentials. Actors: Employer, Buckeye Job Portal Priority: 3/5 Status: Complete Pre-Conditions: Buckeye Job Portal up and running; H2 Database Server up and running; Employer is not logged in. Post-Conditions: Employer successfully logs in to the Buckeye Job Portal. 3) Name: Employer Logs Out of the Buckeye Job Portal Description: 38

53 The employer logs out of the Buckeye Job Portal. Actors: Employer, Buckeye Job Portal Priority: 3/5 Status: Complete Pre-Conditions: Buckeye Job Portal up and running; H2 Database Server up and running; Employer is logged in. Post-Conditions: Employer successfully logs out of the Buckeye Job Portal. 4) Name: Employer Posts a Job on the Buckeye Job Portal Description: The employer successfully posts a new job listing on the Buckeye Job Portal. Actors: Employer, Buckeye Job Portal Priority: 5/5 39

54 Status: Complete Pre-Conditions: Buckeye Job Portal up and running; H2 Database Server up and running; Employer is logged in. Post-Conditions: Employer successfully posts a job on the Buckeye Job Portal. 5) Name: Employer Searches for Potential Candidates. Description: The employer is able to successfully search for potential candidates on the Buckeye Job Portal. Actors: Employer, Buckeye Job Portal Priority: 5/5 Status: Complete Pre-Conditions: 40

55 Buckeye Job Portal up and running; H2 Database Server up and running; Employer is logged in; Employees have updated their profile information. Post-Conditions: Employer is successful in finding suitable candidates on the Buckeye Job Portal. 6) Name: Employer Updates profile. Description: The employer successfully updates his profile information on the Buckeye Job Portal. Actors: Employer, Buckeye Job Portal Priority: 4/5 Status: Complete Pre-Conditions: Buckeye Job Portal up and running; H2 Database Server up and running; Employer is logged in. Post-Conditions: Employer successfully updates his profile on the Buckeye Job Portal. 41

56 3.9 Buckeye Job Portal Screens: The Buckeye Job Portal application contains various screens to provide an interface to end users, like the employer and the employee, to interact with the application. The screens consist of several JSF UI components such as input text boxes, output text boxes, radio buttons, drop down menus and command buttons to facilitate interaction with the user. The screens have a pre-defined template and include a header and a footer, each of which in turn have their own templates, defined in the WEB- INF/templates folder of the JobPortal component of the Buckeye Job Portal project The Register Screen: The Register screen (Figure 16) is the home screen and used to register the user to the Buckeye Job Portal. The Register screen has two output text fields (Name and Password) and two corresponding input text fields. Two buttons, Register and Go to Login, clearly correspond to register and go to the login page, respectively. An Is Name Valid? button verifies if the selected username is a valid username through an Asynchronous JavaScript and XML (AJAX) call. Two radio buttons, Employer and Employee, designate the user type. 42

57 Figure 16: The Register Screen The Login Screen: The Login screen (Figure 17) provides the users of the Buckeye Job Portal a place to login to the application by providing their username, password, and user type (Employee or Employer) credentials. The Login screen has two output text fields (i.e., Name and Password), and two corresponding input text fields. The buttons, Login and Go to Register, allow the user to login and to go to the register page, respectively. Figure 17: The Login Screen 43

58 3.9.3 The Employee Welcome Screen: The Employee Welcome screen (Figure 18) is the home screen for the Employee once he logs into the Buckeye Job Portal application. The Employee Welcome screen has two output text fields (Title and Location), a corresponding input text field for Title, and a corresponding drop-down menu for Location. Three additional buttons (i.e., Search, Logout, and View Profile ) are available to search for matching jobs, log out of the application, and view the profile of the employee, respectively. Figure 18: The Employee Welcome Screen The Search Results Screen: The Search Results screen (Figure 19) is displayed to the employee once the Search button is selected in the Welcome screen. The Search Results screen displays the list of jobs matching the search criteria provided by the employee. The Search Results screen has six hard-coded output text fields (i.e., Job, Title, Location, Pay, Technology, 44

59 and Employer) and five corresponding, result-based output text fields. Each of the jobs displayed has an Apply Here button to enable the employee to apply to the specific job. Two additional buttons (Back and Logout) take the employee back to the welcome screen and log out of the application, respectively. Figure 19: The Search Results Screen The Jobs Applied Screen: The Jobs Applied screen (Figure 20) is displayed to the employee when the Check button is selected on the Employee Profile screen. The Jobs Applied screen displays the list of jobs to which the employee has applied. The Jobs Applied screen has six hard-coded output text fields (i.e., Job, Title, Location, Pay, Technology and Employer) and five corresponding, result-based output text fields. Two additional buttons 45

60 ( Back and Logout ) take the employee back to the profile screen and log out of the application, respectively. Figure 20: The Jobs Applied Screen The Employer Welcome Screen: The Employer Welcome screen (Figure 21) is the home screen for the Employer upon logging into the Buckeye Job Portal application. The Employer Welcome screen has one hard-coded output text field (Welcome), and a corresponding employer-name- 46

61 based output text field. Four additional buttons (i.e., View Employer Profile, Add Job, Search for Candidates, and Logout ) are available to view the profile of the employer, add a new job, search for suitable candidates, and log out of the application, respectively. Figure 21: The Employer Welcome Screen The Employer Profile Screen: The Employer Profile screen (Figure 22) is displayed to the employer upon selecting the View Employer Profile button on the Employer Welcome screen. The Employer Profile screen has five output text fields (i.e., Company, Location, Technology, Domain and User), and five corresponding input text fields. The input text field corresponding to the User output text field is greyed out to prevent further changes by the Employer. Four additional buttons (i.e., Check, Update, Back, and Logout ) are available to view the jobs added by the employer, update the profile of the employer with the new values, go back to the employer welcome screen, and log out of the application, respectively. 47

62 Figure 22: The Employer Profile Screen The Search Candidates Screen: The Search Candidate screen (Figure 23) is displayed to the employer upon selecting the Search for Candidates button on the Employer Welcome screen. The Search Candidate screen has four output text fields (i.e., Title, Location, Pay, and Technology), and four corresponding input text fields. Two additional buttons ( Find and Back ) provide capabilities to search for suitable candidates based on the criteria supplied in the input text fields, and go back to the employer welcome screen, respectively. 48

63 Figure 23: The Search Candidates Screen The Candidates Found Screen: The Candidates Found screen (Figure 24) is displayed to the employer upon selecting the Find button on the Search Candidates screen. The Candidates Found screen displays a list of suitable candidates based on the search criteria provided in the Search Candidates screen. The Candidates Found screen has six hard-coded output text fields (i.e., Candidate, Title, Location, Pay, Technology, and Name), and five corresponding result-based output text fields. A Back button takes the employer back to the Search Candidates screen. 49

64 Figure 24: The Candidates Found Screen 50

65 Chapter 4: Course Lecture The course lecture was focused mainly around the Enterprise JavaBeans (EJB) and JavaServer Faces (JSF) technologies that were used in the Buckeye Job Portal Application. Under EJB the main entities under discussion were Session Beans and Entity Beans; and for JSF the main focus was on the XHTML screens/pages, page backing beans, and the faces-config.xml file. The learning outcomes intended from this lecture and the reference application included: demonstrating an enterprise application, introduction of the EJB, JSF and related technologies, demonstrating techniques like logging and practices like code commenting. The idea was to also introduce to students various enterprise system challenges like: distributed nature, transaction management, integration and state management and, enterprise system features like: loose coupling, high number of user interface screens and multi-tier architecture, through features in the reference Buckeye Job Portal enterprise application. Discussion for EJB technologies included session beans - stateful versus stateless beans, use of annotations, entity manager, container versus bean managed persistence etc and entity beans - representation of business objects as entity beans, mapping of member variables to database table columns and operation on rows through use of entity objects. 51

66 table below: The learning outcomes mapped to the features in the application as shown in the Learning Outcome Loose Coupling Integration Compatibility State Management Transaction Management Distributed Nature Multi-tier architecture Buckeye Job Portal Application Feature Session Beans segregated based on functionality in application Integration of JSF Dynamic Web project with EJB project FacesServlet controller in the JSF Project EJB Container in the EJB Project Separate H2 Database server, JBoss application Server and Client JSF presentation, EJB domain and H2 data source layers Large number of UI Screens Table 1: Learning outcomes vs Application features Buckeye Job Portal application consists of 25 UI Screens Firstly, to demonstrate the concept of loose coupling, related functionality in the Buckeye Job Portal application was bunched together into separate session beans ensuring the session beans were loosely coupled to each other. This way, future changes to one of the session beans would not affect the working of the other beans. Secondly, integration compatibility was demonstrated by the deliberate use of 2 separate components in the application: the JSF front-end which is a Dynamic Web project and the EJB back-end which is an EJB project. The two components were integrated by placement of the exported jar file of the EJB project in the WEB-INF/lib folder of JSF project after ensuring compatibility. Thirdly, with the help of the FacesServlet in the JSF 52

67 project, which played the role of controller and was responsible for managing the complete life cycle of the page backing beans, concepts about state management were demonstrated. Working on the faces-config file to register the managed beans (page backing beans) would give an understanding of the various scopes of the beans along with an understanding of how the bean states are managed by the controller. Finally, the EJB project - which runs in an EJB container, involved the use of session and entity beans. The use of annotations, to access these session beans and entity beans together with the use of the entity manager for CRUD (Create, Read, Update and Delete) operations on the database provided understanding of how the EJB container manages transactions. The course lecture had the following approach: 1) Back to Basics The technologies are explained in informal, basic and simple terms (Figure 25). The idea was to mention basic points about the technologies in an informal manner so that the students could construct in their minds an idea about the technologies before they could proceed to understand more about their theoretical, practical (code level) and integration (placement with respect to other technologies) aspects. 53

68 Figure 25: Basic information about Session Beans 2) Practical Approach Specific and detailed code-level examples are provided (Figure 26). The idea was to provide simple and succinct code snippets to go hand in hand with corresponding theoretical concepts to paint a clearer picture and generate a more wholesome understanding of the technologies at hand. The line of thought behind this approach is that one could know theory about some concept but might be unable to figure out the techniques to apply these concepts to solve real problems. Conversely, one who is able to 54

69 apply code snippets without understanding their inner workings would not be able to overcome bugs without knowing the theoretical background behind the code. With an interlaced approach, the concepts are drilled down more effectively. Figure 26: Code Level Example for Entity Beans 55

70 3) Complete Picture Demonstrated how the various technology components interact and communicate at the code level (Figure 27). Along with knowing about the individual technologies that form an application, understanding their communication with each other at the code level is important too. Examples were provided to show how the page backing beans communicate with the session beans and also how the UI components on the XHTML pages communicate with the page backing beans through the use of expression language. 56

71 Figure 27: Communication between Backing and Session Bean 57

72 Chapter 5: Buckeye Job Portal Experimental Protocol To test the learning outcomes (discussed in chapter 4) experimentally, an experimental protocol was created consisting of several tasks that had to be performed by the students. A sample student group of five was provided instruction using the course lecture slides, reference application and other supporting documentation. (as mentioned in the Contributions section) Varying levels of programming and Java 2 Platform Enterprise Edition (J2EE) experience were represented within the group. Following was the profile of the 5 students: Student 1: Current educational qualification: Masters Experience in software industry: None Programming experience: C and C++ programming Programming ability: Good Proficiency in J2EE technologies: Low 58

73 J2EE technologies worked on: None Student 2: Current educational qualification: Masters Experience in software industry: 2 Years Programming experience: C++ and Java programming Programming ability: Good Proficiency in J2EE technologies: Moderate J2EE technologies worked on: JSP, JDBC Student 3: Current educational qualification: Masters Experience in software industry: 1 Year Programming experience: Java programming 59

74 Programming ability: Moderate Proficiency in J2EE technologies: Low J2EE technologies worked on: JDBC Student 4: Current educational qualification: Masters Experience in software industry: 2 Years Programming experience: Java programming Programming ability: Moderate Proficiency in J2EE technologies: Moderate J2EE technologies worked on: Servlets, JSP 60

75 Student 5: Current educational qualification: Masters Experience in software industry: 3 Years Programming experience: C and C++ and Java programming Programming ability: Moderate Proficiency in J2EE technologies: Good J2EE technologies worked on: JSP, Servlets, JDBC Following instruction, specific tasks related to the Job Portal application were assigned to the students. The objective was to assign tasks to the students, analyze their approach in performing these tasks, and evaluate the level of success in completing the assigned tasks. To better analyze their approach, the students were asked to document their thought process throughout the tasks. In addition, the students were actively monitored, and observations recorded during their assignment. This provided the identification of common barriers that students face who are new to a particular technology, and how the approach can be modified in teaching them these new technologies. 61

76 Prior to the assigned tasks, the students were provided with a document (Job Portal Installation.doc), which detailed how to setup the environment for the Job Portal project from start to finish (i.e., getting the existing Job Portal Application up and running in their newly setup environment). This document not only provided a summary of the application at a high level, but details on the application at the lower levels (e.g., the architecture and project set up) including some code level examples of the various technologies in use. They were also provided with a common pitfalls handbook, Job Portal Showstoppers.doc, which they could reference for problem solving. 5.1 Bloom s Taxonomy Applied to the Experimental Protocol: Each of the three domains in Bloom s taxonomy: Cognitive, Affective and Psychomotor have different levels of learning outcomes within themselves, starting from the lower order and progressing towards higher order objectives. During creation of the tasks in the Buckeye Job Portal experimental protocol, the focus was to cover as many of the learning objectives in Bloom s taxonomy (refer section 1.1) as possible, especially within the Cognitive domain. The tasks created, covered the following learning objectives: 62

77 Task 1: Add a New Screen to the Buckeye Job Portal Application. The new screen should be named New. This new screen must be accessible from the home screen via a button named New. The new screen must have a heading reading Welcome on top of the page and a single button, namely Back. On clicking the Back button the Home screen should be displayed again. Evaluation for Task 1: 1. Was the user able to create a new screen named New? Learning Objectives - Knowledge, Comprehension, Application 2. Was the user able to add a heading to the new screen? Learning Objectives - Comprehension, Application 3. Was the user able to add the Back button to the new screen? Learning Objectives - Comprehension, Application 4. Was the user able to add the New button to the Home screen? Learning Objectives - Knowledge 5. Was the user able to navigate from the Home screen to the new screen and vice versa? 63

78 Learning Objectives - Knowledge, Comprehension, Application and Analysis Task 2: Add 2 Output and Input Text Fields for the Attributes Technology and Location to the Screen New Created in Task 1 (above). The output text fields should have the labels Technology and Location, respectively. Add a new button named Search to the screen. Evaluation for Task 2: 1. Was the user able to add both the Output Text fields? Learning Objectives - Comprehension, Application 2. Was the user able to add both the Input Text fields? Learning Objectives - Knowledge 3. Was the user able to add the Search button? Learning Objectives - Knowledge 64

79 Task 3: Create a New Page Backing Bean named NewBean for the Screen New. This Backing Bean should have two member variables, namely Location and Technology. Make sure to add getter and setter methods for the same. This Backing Bean must also have a method named Search, which accepts no parameters and returns a String. Bind the input text fields in the new screen with these two member variables and the Search button with the search method. Evaluation for Task 3: 1. Was the user able to create a new Backing Bean? Learning Objectives - Knowledge, Comprehension, Application 2. Was the user able to add both the member variables to the Backing Bean? Learning Objectives - Comprehension, Application 3. Was the user able to add the setters and getters for both the member variables? Learning Objectives - Knowledge, Application 4. Was the user able to add a method named search which returns a String? Learning Objectives - Knowledge, Application 65

80 5. Was the user able to bind the Backing Bean with it s corresponding screen? Learning Objectives - Knowledge, Comprehension, Application, Analysis 6. Was the user able to register this Bean with the controller? (FacesServlet) Learning Objectives - Knowledge, Application Task 4: Create a Table in the H2 Database Named NEW which Has Only Two String fields: LOCATION and TECHNOLOGY. Evaluation for Task 4: 1. Was the user able to create the Table named NEW? Learning Objectives - Knowledge, Application 2. Does the table have the required columns? Learning Objectives - Comprehension 3. Was the table created in the right schema? Learning Objectives - Analysis Task 5: 66

81 Create a New Session Bean Named New and a New Entity Bean named NewEntity. The session bean must have a method named Search which accepts two String parameters (Location and Technology) and return a String. This method has two primary responsibilities: First, to make an entry of the search parameters (Location and Technology) into the Table NEW as one record; secondly, to search the JOBLISTING table and match any jobs to the Location and Technology parameters supplied. If there are jobs present, then return true from this method; else return false. Evaluation for Task 5: 1. Did the Entity Bean have two columns (LOCATION and TECHNOLOGY) wired/linked to the NEW table? Learning Objectives - Knowledge, Comprehension, Application 2. Was the user able to create the Session Bean? Learning Objectives - Knowledge, Application 3. Was the user able to create the Entity Bean? Learning Objectives - Knowledge, Application 4. Was the user able to create the search method as per requirements? Learning Objectives - Application 67

82 5. Was the user able to incorporate the right kind of Business Logic? Learning Objectives - Knowledge, Application 6. Was the Entity Bean mapped correctly to the NEW table? Learning Objectives - Application Task 6: Make a Call from the Search Method of the Backing Bean to the Search Method of the Session Bean. If the method returns true, then display the text Hurray! Jobs Available! in a new screen; otherwise if the method returns false, display in another new screen the text No Vacancies!. Basically, in the final scenario, the user must be able to supply the Location and Technology arguments in the new page and click on the Search button, and the result should be either of the two screens above based on if there were matching jobs in the database. Evaluation for Task 6: 1. Was the user able to link the Backing Bean to the session bean with a method call? Learning Objectives - Knowledge, Application, Comprehension, Analysis 2. Was the user able to collect the return String from the method and display one of the appropriate new screens as mentioned above? 68

83 Learning Objectives - Knowledge, Application 5.2 Survey Monkey Questionnaire: The online survey tool, Survey Monkey, was utilized to collect information and feedback from the students after they worked on the tasks in the experimental protocol. The survey utilized key features like check boxes, radio buttons, rating scales, and description boxes to ensure the survey was user friendly and also to enable specific and accurate retrieval of information from the students. The survey was broken down into three sections: 1) Profile information retrieval. 2) Retrieval of feedback for each of the individual tasks. 3) Retrieval of final feedback for the entire exercise. 69

84 5.2.1 Profile Information Retrieval: In the Profile Information Retrieval section of the survey, information about the student s background (e.g., his educational qualification, previous programming experience, industry experience, and experience of working on J2EE technology stacks) was obtained (Figures 28 and 29). Figure 28: Survey Monkey Profile Collection