Master of Software Engineering Portfoliopeople.cis.ksu.edu/~jramos/MSEPortfolio.pdfDesign Patterns ___111 3.6.2.1.1. Architectural Patterns _111 3.6.2.1.2. Design Patterns ___114

Master of Software Engineering Portfolio

by

JAVIER RAMOS RODRÍGUEZ

B.S., Universidad de Vigo, 2005 MSE, Kansas State University, 2006

A PORTFOLIO

submitted in partial fulfillment of the requirements for the degree

MASTER OF SOFTWARE ENGIEERING

Department of Computing and Information Sciences College of Engineering

KANSAS STATE UNIVERSITY Manhattan, Kansas

2006

Approved by:

Major Professor Dr. William J. Hankley

ii

Abstract The KSU Student Portal is a Web application that enables users to easily communicate

through Internet. The application allows students to register and receive personalize

information from other users such as events or articles. Registered users may upload

articles, send news or manage their blogs.

iii

Table of contents

1. Vision Document ___________________________________________ 1

1.1. Introduction _________________________________________________ 1 1.1.1. Motivation _______________________________________________ 1 1.1.2. KSU Student Portal _______________________________________ 1

1.2. Project Overview _____________________________________________ 2 1.2.1. Introduction _____________________________________________ 3 1.2.2. Goal ____________________________________________________ 3 1.2.3. Purpose_________________________________________________ 3

1.3. Requirements Specification ____________________________________ 4 1.3.1. Data Model ______________________________________________ 4

1.3.1.1. Description ____________________________________________ 4 1.3.1.2. E-R Diagram ___________________________________________ 5 1.3.1.3. UML Data Model ________________________________________ 7 1.3.1.4. Tables ________________________________________________ 8

1.3.2. Use Cases ______________________________________________ 10 1.3.2.1. Main Use Case Diagram_________________________________ 10 1.3.2.2. Unregistered User _____________________________________ 11 1.3.2.3. Registered User _______________________________________ 12 1.3.2.4. Administrator _________________________________________ 13

1.3.3. Use Case Specification _____________________________________ 14 1.3.3.1. Actor: User ___________________________________________ 14 1.3.3.2. Actor: Unregistered User________________________________ 16 1.3.3.3. Actor: Registered User _________________________________ 18

1.3.3.3.1. Manage Events _____________________________________ 19 1.3.3.3.2. Manage Blog _______________________________________ 22

iv

2. Architecture Design ________________________________________ 23

2.1. Dynamic View_______________________________________________ 23 2.1.1. Use Case Specification ___________________________________ 23

2.1.1.1. User Module __________________________________________ 23 2.1.1.1.1. Use Case: Register__________________________________ 23 2.1.1.2. Use Case: Sign In ____________________________________ 28

2.1.2. Administration Module _________________________________ 32 2.1.2.1. Use Case: Get Users _________________________________ 32 2.1.2.2. Use Case: Remove User ______________________________ 34

2.1.3. Unregistered User Module_______________________________ 36 2.1.3.1. Use Case: Browse Users ______________________________ 36 2.1.3.2. Use Case: View User Profile ___________________________ 38 2.1.3.3. Use Case: Search Users ______________________________ 40 2.1.3.4. Use Case: Browse Public Events _______________________ 42 2.1.3.5. Use Case: View Public Event __________________________ 44 2.1.3.6. Use Case: Search Public Items_________________________ 46

2.1.4. Registered User Module ________________________________ 47 2.1.4.1. Use Case: Edit Profile ________________________________ 47 2.1.4.2. Use Case: Create Event _______________________________ 49 2.1.4.3. Use Case: Browse Events _____________________________ 51 2.1.4.4. Use Case: View Event ________________________________ 54 2.1.4.5. Use Case: Delete Event _______________________________ 55

2.2. Static View _________________________________________________ 57 2.2.1. Class Diagram __________________________________________ 57

2.2.1.1. User Module __________________________________________ 57 2.2.1.2. Unregistered User Module_______________________________ 58 2.2.1.3. Registered User Module ________________________________ 59 2.2.1.4. Model Classes ________________________________________ 60

v

3. Component Design_________________________________________ 61

3.1. Introduction ________________________________________________ 61

3.2. Model Driven Architecture ____________________________________ 62

3.3. System Architecture _________________________________________ 64

3.4. Technologies _______________________________________________ 67 3.4.1. Data Layer______________________________________________ 67 3.4.2. Model Layer ____________________________________________ 67

3.4.2.1. EJB 3.0 ______________________________________________ 67 3.4.2.2. Java 5 _______________________________________________ 73 3.4.2.3. JNDI _________________________________________________ 73

3.4.3. View Layer _____________________________________________ 74 3.4.3.1. Overview _____________________________________________ 74 3.4.3.2. Servlets ______________________________________________ 75 3.4.3.3. JSP Pages____________________________________________ 76 3.4.3.4. Java Server Faces _____________________________________ 78

3.4.3.4.1. MVC Pattern _______________________________________ 78 3.4.3.4.2. Struts _____________________________________________ 79 3.4.3.4.3. JSF_______________________________________________ 81

3.4.3.5. ADF _________________________________________________ 85 3.4.3.6. JavaScript ____________________________________________ 85 3.4.3.7. Cascading Style Sheets (CSS) ___________________________ 85

3.5. Component Design __________________________________________ 86 3.5.1. Overview _______________________________________________ 86

3.5.1.1. Package Overview _____________________________________ 86 3.5.1.2. Process Overview _____________________________________ 87

3.5.2. Packages_______________________________________________ 91 3.5.2.1. Model Layer __________________________________________ 91

3.5.2.1.1. Model Façade ______________________________________ 92 3.5.2.1.2. Entity Beans _______________________________________ 95 3.5.2.1.3. Implementation Classes _____________________________ 96

3.5.2.2. View Layer___________________________________________ 100 3.5.2.3. Dynamic Behavior ____________________________________ 104

3.5.2.3.1. Register User _____________________________________ 104 3.5.2.3.2. Add Article _______________________________________ 107

vi

3.6. Implementation Design ______________________________________ 110 3.6.1. Folder Structure ________________________________________ 110 3.6.2. Model Layer ___________________________________________ 111

3.6.2.1. Design Patterns ______________________________________ 111 3.6.2.1.1. Architectural Patterns ______________________________ 111 3.6.2.1.2. Design Patterns ___________________________________ 114

3.6.2.2. Algorithms __________________________________________ 115 3.6.2.2.1. Search Algorithm __________________________________ 115 3.6.2.2.2. Filter Algorithm____________________________________ 116

3.6.3. View Layer ____________________________________________ 120 3.6.3.1. Internationalization ___________________________________ 120 3.6.3.2. Input Validation ______________________________________ 122 3.6.3.3. JavaScript ___________________________________________ 122 3.6.3.4. CSS ________________________________________________ 122

3.6.4. Tools _________________________________________________ 123

4. Project Plan______________________________________________ 124

4.1. Task Breakdown ___________________________________________ 124 4.1.1. Inception Phase ________________________________________ 124

4.1.1.1. Vision Document _____________________________________ 124 4.1.1.2. Project Plan__________________________________________ 124 4.1.1.3. Software Quality Assurance Plan________________________ 124 4.1.1.4. Simple Prototype _____________________________________ 124

4.1.2. Elaboration Phase _____________________________________ 125 4.1.2.1. Architecture Design Plan ________________________________ 125 4.1.2.2. Revisions of Project Plan and Vision Document_____________ 125

4.1.2.3. Formal Specification __________________________________ 125 4.1.2.4. Test Plan ____________________________________________ 125 4.1.2.5. Architecture Inspections _______________________________ 125

4.1.3. Production Phase_______________________________________ 126 4.1.3.1. Formal Specification __________________________________ 126 4.1.3.2. Project Coding _______________________________________ 126 4.1.3.3. Project Documentation ________________________________ 126

4.2. Gantt Chart ________________________________________________ 127

4.3. Cost Estimate ______________________________________________ 128

vii

4.4. Architecture Elaboration Plan Completion Criteria _______________ 131 4.4.1. Revision of Vision Document _____________________________ 131 4.4.2. Revision of Project Plan _________________________________ 131 4.4.3. Architecture Design _____________________________________ 131 4.4.4. Development of Prototype _______________________________ 131 4.4.5. Test Plan ______________________________________________ 131 4.4.6. Formal Technical Inspections_____________________________ 132 4.4.7. Formal Requirements Specification________________________ 132

5. Software Quality Assurance Plan ____________________________ 133

5.1. Purpose___________________________________________________ 133

5.2. References ________________________________________________ 133

5.3. Management _______________________________________________ 133 5.3.1. Organization ___________________________________________ 133 5.3.2. Formal Technical Inspectors _____________________________ 134

5.3.2.1. Responsibilities ______________________________________ 134 5.3.2.2. Tasks _______________________________________________ 134

5.4. Documentation_____________________________________________ 135

5.5. Standards, practices conventions and metrics __________________ 135

5.6. Reviews and audits _________________________________________ 135

5.7. Test and problem reporting __________________________________ 136

5.8. Tools, techniques and methodologies__________________________ 136

5.9. Media Control ______________________________________________ 136

5.10. Deliverables _____________________________________________ 137

viii

6. Test Plan ________________________________________________ 138

6.1. Test plan identifier __________________________________________ 138

6.2. Introduction _______________________________________________ 138

6.3. Test items _________________________________________________ 138

6.4. Features to be tested________________________________________ 138

6.5. Approach _________________________________________________ 139

6.6. Item pass/fail criteria ________________________________________ 139

6.7. Suspension criteria and resumption requirements _______________ 140 6.7.1. Suspension criteria _____________________________________ 140 6.7.2. Resumption requirements________________________________ 140

6.8. Test deliverables ___________________________________________ 140

6.9. Environmental needs________________________________________ 140 6.9.1. Physical Characteristics _________________________________ 140

7. Formal Specification ______________________________________ 141

7.1. Introduction _______________________________________________ 141 7.1.1. Alloy _________________________________________________ 141 7.1.2. USE __________________________________________________ 142

7.2. Alloy Model________________________________________________ 142 7.2.1. Description ____________________________________________ 142 7.2.2. Model_________________________________________________ 143

7.3. Use Model _________________________________________________ 147 7.3.1. Description ____________________________________________ 147 7.3.2. Model_________________________________________________ 147 7.3.3. Class Diagram _________________________________________ 149 7.3.4. Object Diagram_________________________________________ 150

8. Formal Inspection Checklist (Design) ________________________ 151

8.1. Introduction _______________________________________________ 151

8.2. Items to be Inspected _______________________________________ 151

8.3. Formal Technical Inspectors _________________________________ 151

8.4. Formal Technical Inspection Checklist _________________________ 152

ix

9. Formal Inspection Checklist (Implementation) _________________ 153

9.1. Introduction _______________________________________________ 153

9.2. Items to be Inspected _______________________________________ 153

9.3. Formal Technical Inspectors _________________________________ 154

9.4. Formal Technical Inspection Checklist _________________________ 155

10. User Manual _____________________________________________ 163

10.1. Installation ______________________________________________ 163 10.1.1. Overview ______________________________________________ 163 10.1.2. Database ______________________________________________ 164 10.1.3. Application ____________________________________________ 164

10.2. Operation _______________________________________________ 165 10.2.1. Overview ______________________________________________ 165 10.2.2. Index Page ____________________________________________ 166 10.2.3. Registration Page_______________________________________ 167 10.2.4. Main Page _____________________________________________ 168

10.2.4.1. Guess User ________________________________________ 168 10.2.4.2. Registered User ____________________________________ 168

10.2.5. Edit Profile ____________________________________________ 169 10.2.6. Change Password ______________________________________ 170 10.2.7. Browse Items __________________________________________ 170 10.2.8. Add Item ______________________________________________ 171 10.2.9. Edit Item ______________________________________________ 172 10.2.10. Search Information____________________________________ 172

x

11. Project Evaluation ________________________________________ 173

11.1. Introduction _____________________________________________ 173

11.2. Process _________________________________________________ 173 11.2.1. Introduction ___________________________________________ 173 11.2.2. Evaluation _____________________________________________ 175

11.3. Technologies ____________________________________________ 178 11.3.1. Model_________________________________________________ 178 11.3.2. View __________________________________________________ 181

11.4. Tools ___________________________________________________ 182

11.5. Schedule ________________________________________________ 183

11.6. Project Metrics ___________________________________________ 185

11.7. Problems Encountered ____________________________________ 186

11.8. Future Work _____________________________________________ 187

11.9. Conclusions _____________________________________________ 188

12. References ______________________________________________ 189

CIS 895 - KSU Student Portal MSE Portfolio

Javier Ramos Rodríguez KSU Student Portal 1

1. Vision Document

1.1. Introduction

1.1.1. Motivation

The motivation of this project comes from the fact that, at this moment, in K-State

international students don’t have an efficient way to communicate with each other to be

able to get help for their courses. At this point, the only resource available is the

international students e-mail list, but this method is inefficient. So, it is clear that is a

need to create a Portal that allows students to share information. The KSU Student

Portal allows students to register and receive news about the different activities and

events going on in town, send messages and different information between users and

the possibility to browse the users to get to know the people.

1.1.2. KSU Student Portal

The KSU Student Portal is a tool designed with the following goals in mind:

− Help International to quickly adapt to the University.

− Provide a tool that students can use for their studies.

− Communicate American students with international students.

The system will be used by three different users:

- Administrator: This is a special user that will be allowed to delete information

and other users but he will have very restricted functions since registered users

are the main actors in the system and they will use most of the functionalities.

- Unregistered Users: This kind of users will only see the public information and

they will also have the possibility to browse the different users and see their

profile.

- Registered Users: The will use the main functionalities of the application. They

will have all the functionalities that the unregistered user have plus other

functionalities like:



o Create and modify information such news and events.

o View private information only available for registered users.

o Possibility to create and modified a profile that will content the user’s

information. There will be a filter module that will provide the users the

possibility to receive only the information that they want according to the

user’s profile.

o The application will provide a forum and a message system to

communicate the different users.

1.2. Project Overview

APPLICATION TIER

PRESENTATION TIER

JSF WEB BROWSER

Administrator

Controller

View

EJB

ORACLE

DB

Registered User

Unregistered User

CLIENT TIER

Session Bean

Entity Bean

DATA TIER



1.2.1. Introduction

The figure above shows the basic system architecture that we will be used to develop

the application. The clients will use a Web browser to connect to the application server

that will be divided in three tiers that can be implemented in different machines. The

presentation tier is in charge of accepting requests from the client, ask the application

for the appropriate answer and generate the view with the results for the client. We will

use Java Server Faces (JSF) to implement the controller and generate the view. The

application tier is in charge of implementing the business model. We will use Enterprise

Java Beans (EJB) in this tier. Finally, we have the data tier where we will use an Oracle

database to manage the information used by the application.

The idea of the project is to use robust methodologies and design patterns to create a

high quality application trying to achieve the basic properties such Reusability,

Flexibility, Functionality, Extendibility or Effectiveness.

1.2.2. Goal

To create an application that will allow users to create and share information in the

most efficient way.

1.2.3. Purpose

Provide a tool to solve the initial disorientation and miscommunication of international

students.



1.3. Requirements Specification

1.3.1. Data Model

1.3.1.1. Description

The main entity that we are interested is the application user. We want to store

information such the name, address, courses, mayor, home university, country…

A registered user will be able to publish articles, events and links. We want to store

some information about those entities like, the header, the actual text, the date or the

user that publish such item.

A user will also have a blog where he/she can publish new blog entries. Also, user

will have the chance to send messages to each other.

With this information we will create an Entity-Relation diagram to model the data and its

relations.



1.3.1.2. E-R Diagram



In the diagram I only show the relevant attributes to make it easier to read. The

relations without names mean the usual “belongs to” or “has” relationship. A user will

have associated a blog; the blog entity will have several entries. As we mention before

a user have the possibility to publish links, event and articles. The problem that we face

here is that some user will be interested in some articles or events according to their

profiles. So I decided to create a separate entity call Profile were we keep the

attributes that we will use to filter the information to allow users to receive only the

information that they are interested according to the profile. The attributes that we are

going to filter with will be the home university, language, country, mayor or courses.

The articles and events will also have some information associated just like the user

but it will not be exactly the same, so I have created another entity called Filter.

User and Message entities have to relations: one that relates the messages and their

authors (From field) and another relation that associates the message and its possible

destinations.



1.3.1.3. UML Data Model

Blog<<PK>> b_idvisibility<<FK>> login

Blog Entry<<PK>> be_idpicturetextbe_date<<FK>> b_id

0..n

1

Message<<PK>> m_idsubjectm_textm_date<<FK>> m_author

Profile<<PK>> p_idh_univmayorcountry

Course<<PK>> c_numc_name

0..n

0..n

Link<<PK>> l_idlinkl_date<<FK>> l_author

User<<PK>> loginpasswordf_namel_nameemailstreetcitystateaboutvisbilityname<<FK>> p_id

1

1

0..1

1

1..n

1..n

1

1

1

0..n

Article<<PK>> a_ida_headera_texta_datea_url<<FK>> a_author<<FK>> f_id

1

0..1

Event<<PK>> e_ide_headere_texte_date<<FK>> e_author<<FK>> f_id

1

0..n

Filter<<PK>> f_idcountrylanguageh_univmayor<<FK>> c_num

0..1 0..1

1

1

1

1

1

11

1

1

0..n

AuthorDest

1..n

1..n

1

0..1

1

1

1

1

1

0..n

1

1

0..1 0..n

0..n

0..n

0..1 0..1



1.3.1.4. Tables

Next, I’ll show the transformation of the E-R diagram to tables applying the E-R

transformation rules.

USER: login, password, f_name, l_name, email, street, city, state, visibility,

about, p_id

PROFILE: p_id, h_univ, mayor, co_code

BLOG: b_id, visibility, p_id, u_id

BLOG_ENTRY: be_id, picture, text, be_date, b_id

MESSAGE: m_id, subject. m_text, m_date, m_author

MESSAGE_DEST: m_id, login

COURSE: c_num, c_name

ARTICLE: a_id, a_header, a_text, a_url, a_date, a_author, f_id

EVENT: e_id, e_header, e_text, e_date, e_author, f_id

LINK: l_id, link, l_date, l_author

FILTER: f_id, h_univ, mayor, co_code, lan_code, c_num

PROFILE_COURSE: p_id, c_num

PROFILE_LANGUAGE: p_id, lan_code

COUNTRY: co_code, country

LANGUAGE: lan_code, language

Basically I did the next transformations:

- For each entity I created a table.

- For many-to-many relations I created a new table with the primary keys of the

entities involved.

- For one-to-many relations I put the primary key of the one side as foreign key in

the many side.

- I have created two new tables Country and Language that were originally

attributes but since they will be shared by Filter and Profile is better to have a

fixed list of countries or languages



The visibility attribute in the user marks whether the blog or the user info. can be seen

by unregistered users or just registered users. A special value of the p_id will be used

to mark events and articles that are sent to everyone including unregistered users. The

country attribute in the User entity means the country that the user is from and the

country attribute in the Profile means the countries that he is interested in.



1.3.2. Use Cases

1.3.2.1. Main Use Case Diagram In the next figure, we show the main use case diagram that contents the main

functionalities.

Unregistered User

Register

Sign In

User

Registered Users

Registered User Package

Unregistered User Package



In the figure the relation between the different actors is shown. We have two actions

that a user can do if he has not logged in yet. Which are sign in as a guess user or

registered user if he/she is already a registered user or register in the application. Once

signed in, depending if the user is a registered or unregistered will have different

functionalities that are described next.

1.3.2.2. Unregistered User

View Users Profile

View Public Event

Browse Users

<<extend>>

Search Users<<extend>>

Browse Public Events

<<extend>>

Search Public Items

Unregistered User

(from Use Case View)

<<extend>>

View Blog

<<include>>

As we can see in the figure the Unregistered User has very limited functionalities. He

can only see the public news/events and browse the different users to see their profile

but only the public information of the profile.



1.3.2.3. Registered User

Manage Links

Manage Blog

Browse Forum

Edit Profile

<<extend>>

Sign Out

Manage EventsManage Articles

Search Items

Change Password

Registered User


In the figure we show the main functionalities of the Registered User. As we mention

before, the registered user must sign in to access to this functionalities, additionally he

can sign out at any moment. He will be able to manage (create and remove) the

different information such articles, blog entries, events or Web links. He can edit his/her

profile to make the appropriate changes also to his/her blog.



1.3.2.4. Administrator

Remove User

Remove Language

Remove Course

Get Users

<<extend>>

Add Language

Add Course

Get Languages

Get Courses

Administrator


<<extend>>

<<extend>>

The administrator can get the users and delete them. Also, he/she can add and remove

languages and courses.



1.3.3. Use Case Specification

In this section, we describe the critical use cases of the system that will be refined

in the architectural phase.

1.3.3.1. Actor: User Name Register Objective Register a new user in the application, so he/she can access to

the main features. Priority High Extends Includes Actors User Pre-conditions Post-conditions User will get registered in the application. Main Scenario 1. The user selects “Register” from the user interface.

2. The system receives the request. 3. The system shows the user the register form. 4. User fills the form. 5. System validates the form. 6. The system receives the information and saves it.

Secondary Scenario Exceptional Scenario

If there’s an error in the register form the system will tell the user to correct it.

Function Register User Non functional requirements

Execution Frequency Medium Annotations



Name Sign In Objective Register a new user in the application, so he/she can access to

the main features. Priority High Extends Includes Actors User Pre-conditions Post-conditions User will Sign in the application Main Scenario 1. The user introduces his/her Login and Password.

2. The system receives the request. 3. The system checks if the information is correct

according with the information stored in the system. 4. The system sends an error message if the log in was

incorrect or forward the user to the main page. Secondary Scenario 1. The user selects “Guess” to enter as an unregistered

user. 2. The system receives the request and forwards

him/her to the main page. Exceptional Scenario

If there’s an error logging in the system will tell the user to correct it.

Function Sign In User Non functional requirements

Execution Frequency High Annotations



1.3.3.2. Actor: Unregistered User Name Browse Public Event Objective Browse the different public events that are available in the

application Priority Medium Extends Includes Actors Unregistered User Pre-conditions Sign into the system Post-conditions User will receive the list of events Main Scenario 1. The user selects “browse news/events” from the

main menu. 2. The system receives the request and retrieves the

list with all the items requested, in this case, only the public ones.

3. The system shows the user the list of news/events. Secondary Scenario Exceptional Scenario

Function Browse the public information Non functional requirements

Execution Frequency Medium Annotations Name View Public Event Objective View the information of a specific event Priority Medium Extends Browse Public Information Includes Actors Unregistered User Pre-conditions Sign into the system, browse public information Post-conditions User will receive the information about one event. Main Scenario 1. The user may want to see a particular event by

clicking in the header. 2. The system receives the request and finds the

particular item. 3. The system returns the item information to the user.


Function View a public event Non functional requirements




Name Browse Users Objective Browse the different user registered in the application Priority Medium Extends Includes Actors Unregistered User Pre-conditions Sign into the system Post-conditions User will receive a list of different users Main Scenario 1. The user selects “browse users” from the main

menu. 2. The system receives the request and retrieves the

list with all the users, 3. The system shows the user the list of registered

users. Secondary Scenario Exceptional Scenario

Function Browse registered users. Non functional requirements

Execution Frequency High Annotations Name View User Profile Objective Browse the different user registered in the application Priority Medium Extends Browse users Includes Actors Unregistered User Pre-conditions Sign into the system, browse users Post-conditions User views a registered user profile Main Scenario 1. The user selects a user from the user list.

2. The system receives the request and finds the appropriate user profile.

3. The system returns the selected user profile. Secondary Scenario Exceptional Scenario

Function View a specific user profile Non functional requirements




1.3.3.3. Actor: Registered User Name Sign Out Objective Sign out a user from the application Priority High Extends Includes Actors Registered User Pre-conditions Sign In Post-conditions User will be no longer log in the application Main Scenario 1. The user selects “log out”

2. The system receives the request. 3. The system closes the session. 4. The system forwards the user to the welcome page.


Function Sign Out User Non functional requirements

Execution Frequency High Annotations Name Edit Profile Objective Allow user to modify his/her profile Priority Medium Extends Includes Actors Registered User Pre-conditions Sign In Post-conditions Information will be added or changed in the user’s profile Main Scenario 1. The user selects “Edit profile” from the UI.

2. The system receives the request. 3. The system shows the profile modification form. 4. The user performs the appropriate changes. 5. The system receives the form and makes the

changes in the database. Secondary Scenario Exceptional Scenario

Function Edit user’s profile Non functional requirements

Execution Frequency Low Annotations



The next Use Cases need to be divided into more specific functionalities. Manage

means create, delete, browse and view the different item. Since the functionality will be

the same for all the “Manage XXXXX” use cases (only the data changes), we are going

to specify only one, and the rest will be the same.

1.3.3.3.1. Manage Events

Delete Event

View Event

Create Event

Browse Events

<<extend>>

<<extend>>

Registered User


Create Profile

<<include>>

Edit Event<<extend>>

As we can see in the figure, a registered user can publish an event at anytime. He/She

can also browse the different events. Selecting one event will allow the user to view all

the information about it (View Event). The events that were created by the user will

have the possibility to be deleted or modified. When an event is created a profile will be

associated to it.



Name Create Event Objective Provide a functionality that allows a registered user to create an

event and publish it. Priority Medium Extends Includes Actors Registered User Pre-conditions Sign In Post-conditions An new event will be published in the system Main Scenario 1. The user selects “Create Event” from the UI.

2. The system receives the request. 3. The system shows the corresponding form to the

user. 4. The user fills up the form and click on “Submit”. 5. The system receives the information and stores it in

the database. Secondary Scenario Exceptional Scenario

Function Create Event Non functional requirements

Execution Frequency Medium Annotations Name Browse Events Objective Browse the different events Priority Medium Extends Includes Actors Registered User Pre-conditions Sign into the system Post-conditions User will receive a list of the different events that he/she is

interested. Main Scenario 1. The user selects “browse events” from the main

menu. 2. The system receives the request and looks the user’s

profile information. 3. The filtering module selects the events that the user

is interested. 4. The system shows the user the list of the events

adding a “delete” link to the events that the user published.


There will be a possibility to browse user by different fields. Or to browse the user created events.

Function Browse events. Non functional requirements




Name View Event Objective View the information of a specific event Priority Medium Extends Browse Events Includes Actors Registered User Pre-conditions Sign into the system Post-conditions User will receive the information about one event. Main Scenario 1. The user may want to see a particular event by





Execution Frequency Medium Annotations Name Delete Event Objective Delete one event from the database Priority Medium Extends Includes Actors Registered User Pre-conditions Sign into the system Post-conditions An Event will be removed from the database Main Scenario 1. The user selects one particular that he/she has

created. 2. The system receives the request and looks for the

specific item in the database. 3. The system removes the event. 4. The system shows the results of the operation


If there’s an error while deleting the event the user will be notified

Function Delete event Non functional requirements




1.3.3.3.2. Manage Blog

Add Entry

Delete Entry

Modify Entry

Registered User


Edit Blog

<<extend>>

<<extend>>

<<extend>>

Change Profile

<<extend>>

Create Profile

<<include>>

The user will have the chance to edit his/her blog and add, remove or modify an

entry. He/She can change the profile associated to the blog.



2. Architecture Design In this section, we will take the requirements specification and refine it to get the

domain classes of the system. At this point, we don’t have information about the

architecture used so, the design model presented provides a high level of detail but at

the same time is platform independent.

Section 2.1, describes the system behavior based on the uses cases specification from

the vision document. Section 2.2, shows the system classes and their relations.

2.1. Dynamic View

2.1.1. Use Case Specification In this section, we provide a full description of the use cases functionality showing

the sequence and collaboration diagrams for each scenario. Only critical use cases

are shown.

2.1.1.1. User Module

2.1.1.1.1. Use Case: Register

Name Register Objective Register a new user in the application, so he/she can access to

the main features. Priority High Extends Includes Actors User Pre-conditions Post-conditions User will get registered in the application. Main Scenario 1. The user selects “Register” from the user interface.

2. The system receives the request. 3. The system shows the user the register form. 4. User fills the form. 5. System validates the form. 6. The system receives the information and saves it.


If there’s an error in the register form the system will tell the user to correct it.

Function Register User Non functional requirements




The scenario will be explained in detail using collaboration and sequence diagrams that

show the dynamic behavior of the use case. At this point we don’t have information of

the architecture that will be used, so we create an abstract model that can be

implemented in any platform or architecture. We will divide the system are three layers:

View, Model and Data.

The goal of this phase is to create a very robust and accurate specification but at the

same time maintain an independence of the language or platform used. The next

phase will have more details and will be platform dependent, for example if I decide to

implement in the J2EE platform, the classes used in this model will have one or more

corresponding Java classes. The goal is that the analysis, design and implementation

are coherent with each other having each one different level of abstraction.

Three different types (stereotypes) of classes are used in the diagrams depending on

the usage of the class.

Entity Control Boundary

1. Entity Classes: These types of classes are used to represent entities that

contain data. Usually they will match to tables in the relational model or entity

beans when using the J2EE platform.

2. Control Classes: These types of classes are used to represent classes that

perform some kind of logic: business logic or controllers. In the view layer

theses classes will represent the controllers in the MVC pattern; in the model

these classes will represent the business logic. For example, in the J2EE

platform these classes probably will be session beans.



3. Boundary Classes: These classes in the view are used to represent the

classes that the user interacts with. These classes will contain all the forms and

all the other UI components. So, these classes are the boundary between users

and the application. For example, in a J2EE web application these classes will

be JSP pages. In the model, this stereotype is used to represent the boundary

between the view and the model, so it will be used in the class that implements

the facade design pattern.

To follow better the sequence diagrams, check at the same time the static class model

in the next section.



Sequence Diagram

: User : MainUI : MainUIController : RegisterUI : RegisterUIController : ModelFacade : UserControl user : AppUser

registerregister() showRegForm()

fill formsubmit()

validateFields()

[NO fields properly filled]showRegForm(String error)

correct form

-------------------------------------------------------------------[fields properly filled]

registerUser()registerUser()

<<create>>

persist(user)showResults(String results)

showResults(String results)


The scenario begins in the main window. The user chooses “Register” in the menu and

the request in handled by the controller who shows the form in the RegisterUI. The

user fills out the form and submits the information. The controller validates the fields

and in case of an error asks the user to fill the form again. If the information is correct

the controller requests the model to perform the operation. The request in handled by

the model facade which asks as a boundary between the view and the business logic.

The model facade asks the control class to perform the operation, this class creates

the entity and performs the persistence, and then it returns the results.



Collaboration Diagram

: User : MainUI

: RegisterUI

: ModelFacade

: UserControluser : AppUser

12: persist(user)

: MainUIController

: RegisterUIController

6: validateFields()

1: register

4: fill form8: correct form 2: register()

3: showRegForm()

5: submit()

7: showRegForm(String error)15: showResults(String results)

9: registerUser()

14: showResults(String results)

10: registerUser()


11: <<create>>



2.1.1.2. Use Case: Sign In Name Sign In Objective Register a new user in the application, so he/she can access to

the main features. Priority High Extends Includes Actors User Pre-conditions Post-conditions User will Sign in the application Main Scenario 1. The user introduces his/her Login and Password.

2. The system receives the request. 3. The system checks if the information is correct

according with the information stored in the system. 4. The system sends an error message if the log in was

incorrect or forward the user to the main page. Secondary Scenario 1. The user selects “Guess” to enter as an unregistered

user. 2. The system receives the request and forwards

him/her to the main page. Exceptional Scenario

If there’s an error logging in the system will tell the user to correct it.

Function Sign In User Non functional requirements




Scenario 1

Sequence Diagram

: User : MainUI : MainUIController : ModelFacade : UserControl : AppUser : WelcomeUI

fill form

showLoginForm( )

checkLogin( )

validateInput( )

showLoginForm( String error)[NO fields properly filled]

correct form -------------------------------------------------------------------[fields properly filled]

checkLogin(String name, String passwd)

checkLogin(String login, String Passwd)

<<use>>

showResults(String results)showResults(String results)

checkResults(String results)

login fail

show( )

[results == false]

[results == true]




: User : MainUI

: MainUIController

: ModelFacade : UserControl : AppUser

: WelcomeUI

1: showLoginForm( )

2: fill form

3: checkLogin( )

4: validateInput( )

5: showLoginForm( String error)

6: correct form

7: checkLogin(String name, String passwd)

8: checkLogin(String login, String Passwd) 9: <<use>>



12: checkResults(String results)

13: login fail

14: show( )



Scenario 2

Sequence Diagram

: User : MainUI : MainUIController : WelcomeUI

showLoginForm( )

click guessshowWelcome( )

show( )


: MainUIController

: User : MainUI

: WelcomeUI

1: showLoginForm( )

2: click guess

3: showWelcome( )

4: show( )



2.1.2. Administration Module

2.1.2.1. Use Case: Get Users Name Get Users Objective Get the different users registered in the application Priority Medium Extends Includes Actors Administrator Pre-conditions Sign into the system Post-conditions User will receive a list of different users Main Scenario 1. The user selects “Get users” from the main menu.

2. The system receives the request and retrieves the list with all the users,

3. The system shows the user the list of registered users. Secondary Scenario Exceptional Scenario

Function Get registered users. Non functional requirements


Sequence Diagram

: Administrator : WelcomeUIController : WelcomeUIController : ModelFacade user : AppUser : UserListUI : UserControl users : List

[repeat]

[while ResultSet.isEmpty == true]

Get UsersgetUsers( )

getUserList( )

showUserList( users)

getUserList( )

<<create>>

returnResults( users)returnResults( )

<<create>>

add( user )



The UserControl class creates an object List that has generic list of abject then it

queries the database and gets the list of users. In a loop, the UserControl class creates

an AppUser object and stores it in the generic list that is returned to view for

visualization.


: Administrator : WelcomeUIController

: WelcomeUIController : ModelFacade

user : AppUser

: UserListUI

: UserControl users : List

1: Get Users

2: getUsers( )

3: getUserList( )

4: getUserList( )

5: <<create>>

6: <<create>>

7: add( user )

8: returnResults( users)

9: returnResults( ) 10: showUserList( users)



2.1.2.2. Use Case: Remove User Name Remove User Objective Delete one user from the database Priority Medium Extends Includes Actors Administrator Pre-conditions Sign into the system Post-conditions An User will be removed from the database Main Scenario 1. The Administrator selects one particular user from

the user list. 2. The Administrator confirms the operation. 3. The system receives the request and looks for the

specific user in the database. 4. The system removes the user. 5. The system shows the results of the operation


If there’s an error while deleting the user, the administrator will be notified



Sequence Diagram

: Administrator : UserListUI : UserListUIController : ModelFacade : UserControl : AppUser

delete user

deleteUser( )deleteUser(login )

deleteUser( login )<<remove>>

showResults( )showResults( )

showResults( )

showConfirmation( )confirm




: AppUser

: Administrator : UserListUI

: UserListUIController : ModelFacade

: UserControl

1: delete user

2: showConfirmation( )

3: confirm

4: deleteUser( )

5: deleteUser(login )

6: deleteUser( login )

7: <<remove>>

8: showResults( )

9: showResults( )

10: showResults( )



2.1.3. Unregistered User Module

2.1.3.1. Use Case: Browse Users Name Browse Users Objective Browse the different user registered in the application Priority Medium Extends Includes Actors Unregistered User Pre-conditions Sign into the system Post-conditions User will receive a list of different users Main Scenario 1. The user selects “browse users” from the main


list with all the users. 3. The system shows the user the list of registered

users. Secondary Scenario Exceptional Scenario

There will be a possibility to browse user by name, country, major…

Function Browse registered users. Non functional requirements


Sequence Diagram

: Unregistered User : WelcomeUI : WelcomeUIController : ModelFacade user : AppUser : UserListUI : UserControl users : List

Browse UsersgetUsers( )

getUserList( )

[repeat]


getUserList( )<<create>>

<<create>>

add( user )

returnResults( users)returnResults( )

showUserList( users)

The whole list of users will be shown but the Unregistered User will only be allow to click in the ones who have public visibility to see their profile




: UserListUI : Unregistered User

: WelcomeUIController : WelcomeUIController

: ModelFacadeuser : AppUser

users : List

: UserControl

1: Browse Users 2: getUsers( )

3: getUserList( )

4: getUserList( ) 5: <<create>>6: <<create>>7: add( user )

8: returnResults( users)

9: returnResults( )

10: showUserList( users)



2.1.3.2. Use Case: View User Profile Name View User Profile Objective Browse the different user registered in the application Priority Medium Extends Browse users Includes Actors Unregistered User Pre-conditions Sign into the system, browse users Post-conditions User views a registered user profile Main Scenario 1. The user selects a user from the user list.

2. The system receives the request and finds the appropriate user profile.

3. The system also gets the blog entries. 4. The system returns the selected user profile.


Function View a specific user profile Non functional requirements


Sequence Diagram

: Unregistered User

: UserListUI : UserListUIController : ModelFacade : UserControl user : AppUser : UserProfileUI blogs : List blog : Blog

view user profilegetUserProfile( )

getUserProfile( login)getUserProfile( login)

<<create>>

showResults( user, blogs )

showResults( user, blogs )

showProfile( user, blogs )

getBlogEntries( )

<<create>>

[repeat] <<create>>

add( blog )

[while blongEntries.isEmprty == true]




: Unregistered User

: UserListUI : UserListUIController

: ModelFacade : UserControluser : AppUser

: UserProfileUI

blogs : List blog : Blog

1: view user profile 2: getUserProfile( )

3: getUserProfile( login)

4: getUserProfile( login)5: <<create>>

6: getBlogEntries( )

7: <<create>>

8: <<create>>

9: add( blog )

10: showResults( user, blogs )

11: showResults( user, blogs )

12: showProfile( user, blogs )



2.1.3.3. Use Case: Search Users Name Search Users Objective Search for users registered in the application Priority Medium Extends Includes Actors Unregistered User Pre-conditions Sign into the system Post-conditions User will receive a list with the results of the search Main Scenario 1. The user selects “search users” from the main menu.

2. The systems show a form where the user introduces the search criteria.

3. The user sends the search request. 4. The system receives the request and retrieves the

list of users corresponding to the search criteria. 5. The system shows the user the results.


Function Search registered users. Non functional requirements


Sequence Diagram

: Unregistered User

: WelcomeUI : WelcomeUIController : ModelFacade : UserControl users : List user : AppUser

: SearchUsersUI

search usersshowSearchForm( )

showSearchForm( )

fill form

searchUsers( )

searchUsers( criteria )

name, home university, country....

[repeat]

[while Resultset.isEmpty == true]

searchUsers( criteria )<<create>>

<<create>>

add(user )

DB query

showResults( users)showResults( users )

showSearchResults( )




: Unregistered User

: WelcomeUI : WelcomeUIController

: ModelFacade

: SearchUsersUI

: UserControl

users : List user : AppUser

1: search users

2: showSearchForm( )

3: showSearchForm( )

4: fill form

5: searchUsers( )

6: searchUsers( criteria )

7: searchUsers( criteria )

8: <<create>>

9: <<create>>

10: add(user )

11: showResults( users)

12: showResults( users )

13: showSearchResults( )



2.1.3.4. Use Case: Browse Public Events Name Browse Public Events Objective Browse the different public events that are available in the

application Priority Medium Extends Includes Actors Unregistered User Pre-conditions Sign into the system Post-conditions User will receive the list of events Main Scenario 1. The user selects “browse events” from the main


list with all the items requested, in this case, only the public ones.

3. The system shows the user the list of events. Secondary Scenario Exceptional Scenario

Function Browse the public events Non functional requirements


Sequence Diagram

: Unregistered User

: WelcomeUI : WelcomeUIController : ModelFacade : EventControl event : Event : EventListUIevents : List

browse public eventsgetPublicEvents( )

getPublicEvents( )getPublicEvents( )

<<create>>

[repeat]


<<create>>

add( event)

showResults( events )showResults( events )

shoeEventList( events)




: Unregistered User


: ModelFacade : EventControl

event : Eventevents : List

: EventListUI

1: browse public events 2: getPublicEvents( )

3: getPublicEvents( )

4: getPublicEvents( )

5: <<create>>

6: <<create>>

7: add( event)

8: showResults( events )


10: shoeEventList( events)



2.1.3.5. Use Case: View Public Event Name View Public Event Objective View the information of a specific event Priority Medium Extends Browse Public Events Includes Actors Unregistered User Pre-conditions Sign into the system, browse public information Post-conditions User will receive the information about one event. Main Scenario 1. The user may want to see a particular event by






Sequence Diagram

: Unregistered User

: EventListUI : EventListUIController : ModelFacade event : Event : EventUI : EventControl

view public eventviewPublicEvent()

viewPublicEvent( e_id)

showResults( event )

showEvent( event )

viewPublicEvent( e_id)

<<create>>




: Unregistered User

: EventListUI : EventListUIController

: ModelFacade

event : Event

: EventUI

: EventControl

1: view public event 2: viewPublicEvent()

3: viewPublicEvent( e_id)

4: viewPublicEvent( e_id)

5: <<create>>

6: showResults( event )

7: showEvent( event )



2.1.3.6. Use Case: Search Public Items Name Search Public Items Objective Search to look for public events that are available in the

application Priority Medium Extends Includes Actors Unregistered User Pre-conditions Sign into the system Post-conditions User will receive the list of events Main Scenario 1. The user selects “search” from the main menu.

2. The Systems shows the search form. 3. The user fills the forms and introduces the search

criteria. 4. The system receives the request and retrieves the

list with the items that much the search criteria from only the public ones.

5. The system shows the user the list of events. Secondary Scenario Exceptional Scenario

Function Browse the public events Non functional requirements




2.1.4. Registered User Module

2.1.4.1. Use Case: Edit Profile Name Edit Profile Objective Allow user to modify his/her profile Priority Medium Extends Includes Actors Registered User Pre-conditions Sign In Post-conditions Information will be added or changed in the user’s profile Main Scenario 1. The user selects “Edit profile” from the UI.

2. The system receives the request. 3. The system shows the profile modification form. 4. The user performs the appropriate changes. 5. The system receives the form and makes the

changes in the database. Secondary Scenario Exceptional Scenario

Function Edit user’s profile Non functional requirements

Execution Frequency Low Annotations

Sequence Diagram

: Registered User : WelcomeUI : WelcomeUIController : ModelFacade : AppUser : UserProfile : UserControl : ProfileUIController : ProfileUI

edit profileeditUserProfile( )

showProfileForm( )

fill formcheckFields( )

[NO fields properly filled]showProfileForm( )

correct form

[fields properly filled]

updateProfile( )updateProfile( )

<<update>>

showResults( )


The parameters will be the form fields

<<update>>




: Registered User


: ModelFacade : ProfileUI : ProfileUIController

: AppUser : UserControl : UserProfile

1: edit profile

4: fill form7: correct form

2: editUserProfile( )

3: showProfileForm( )

9: updateProfile( )

12: showResults( )

5: checkFields( )

6: showProfileForm( )14: showResults( )

8: updateProfile( )

13: showResults( )

10: <<update>>

11: <<update>>



2.1.4.2. Use Case: Create Event Name Create Event Objective Provide a functionality that allows a registered user to create an

event and publish it. Priority Medium Extends Includes Actors Registered User Pre-conditions Sign In Post-conditions An new event will be published in the system Main Scenario 1. The user selects “Create Event” from the UI.

2. The system receives the request. 3. The system shows the corresponding form to the

user. 4. The user fills up the form and click on “Submit”. 5. The system receives the information and stores it in

the database. Secondary Scenario Exceptional Scenario

Function Create Event Non functional requirements


Sequence Diagram

: Registered User : WelcomeUI : WelcomeUIController : CreateEventUI : CreateEventUIController : ModelFacade : EventControl event : Event item : ItemProfile

create EventcreateEvent( ) showCreateEventForm( )

validateFields( )

[NO fields properly filled]showCreateEventForm( )

correct form

[fields properly filled]

createEvent( )createEvent( )

<<create>>

persist( event)showResults( )


<<create>>

add( item )




: Registered User


: CreateEventUI : CreateEventUIController

: ModelFacade : EventControlevent : Event

12: persist( event)

item : ItemProfile

1: create Event

6: correct form

2: createEvent( )

3: showCreateEventForm( )

4: validateFields( )

5: showCreateEventForm( )15: showResults( )

7: createEvent( )

14: showResults( )

8: createEvent( )

13: showResults( )

10: <<create>>11: add( item )

9: <<create>>



2.1.4.3. Use Case: Browse Events Name Browse Events Objective Browse the different events Priority Medium Extends Includes Actors Registered User Pre-conditions Sign into the system Post-conditions User will receive a list of the different events that he/she is

interested. Main Scenario 1. The user selects “browse events” from the main

menu. 2. The system receives the request and looks the user’s

profile information. 3. The filtering module selects the events that the user

is interested. 4. The system shows the user the list of the events

adding a “delete” link to the events that the user published.


There will be a possibility to browse user by different fields. Or to browse the user created events.

Function Browse events. Non functional requirements


Sequence Diagram

profile : UserProfile : Registered User

: WelcomeUI : WelcomeUIController : ModelFacade : EventControl event : Event : EventListUIevents : List : UserControl

browse eventsbrowseEvents( )

getEvents(login )getUserProfile( login)

<<create>>

returnResults( profile)

getEvents( profile)<<create>>

[repeat]<<create>>

add( event )


query the DB only getting the event according to the profile

showResults( events )showResults(events )

shoeEventList(events )



In this case, first we find the user profile object to get the information that the system

will use to filter the list of events so the user only gets the ones that is interested. After

getting the profile object the model facade calls the EventControl class to get the

events according to the profile.




: Registered User : WelcomeUI : WelcomeUIController : ModelFacade

: EventControl

event : Event

: UserControl

profile : UserProfile

events : List

: EventListUI

1: browse events 2: browseEvents( ) 3: getEvents(login )

8: <<create>>10: add( event )

9: <<create>>

5: <<create>>

12: showResults(events )

13: shoeEventList(events )

4: getUserProfile( login)

6: returnResults( profile)

7: getEvents( profile)




2.1.4.4. Use Case: View Event Name View Event Objective View the information of a specific event Priority Medium Extends Browse Events Includes Actors Registered User Pre-conditions Sign into the system Post-conditions User will receive the information about one event. Main Scenario 1. The user may want to see a particular event by








2.1.4.5. Use Case: Delete Event Name Delete Event Objective Delete one event from the database Priority Medium Extends Includes Actors Registered User Pre-conditions Sign into the system Post-conditions An Event will be removed from the database Main Scenario 1. The user selects one particular that he/she has

created. 2. The system receives the request and looks for the

specific item in the database. 3. The system removes the event. 4. The system shows the results of the operation


If there’s an error while deleting the event the user will be notified



Sequence Diagram

: Registered User

: EventListUI : EventListUIController : ModelFacade : Event : EventControl

delete event

deleteEvent( )deleteEvent( e_id)

deleteEvent(e_id )<<remove>>


showResults( )

showConfirmation( )

confirm




: Registered User : EventListUI

: EventListUIController : ModelFacade

: Event : EventControl

1: delete event

2: showConfirmation( )

3: confirm

4: deleteEvent( )

5: deleteEvent( e_id)

6: deleteEvent(e_id )

7: <<remove>>

8: showResults( )

9: showResults( )

10: showResults( )



2.2. Static View

2.2.1. Class Diagram

2.2.1.1. User Module

AppUser

UserControl

checkLogin()registerUser()

persist()getUserList()

getUserProfile()getBlogEntries()searchUsers()deleteUser()

updateProfile()

Model

View

ModelFacade

checkLogin()showResults()registerUser()getUserList()

returnResults()getUserProfile()searchUsers()

getPublicEvents()viewPublicEvent()

deleteUser()updateProfile()createEvent()getEvents()

deleteEvent()

MainUIController

checkLogin()validateInput()showResults()checkResults()

register()showWelcome()

RegisterUIController

submit()validateFields()showResults()

MainUI

showLoginForm()

RegisterUI

showRegForm()showResults()

User



2.2.1.2. Unregistered User Module

WelcomeUI

show()

UserListUI

showUserList()showResults()

showConfirmation()

UserProfileUI

showProfile()

SearchUsersUI

showSearchForm()showSearchResults()

Unregistered User


EventListUI

shoeEventList()showResults()

showConfirmation()

EventUI

showEvent()

AppUser


WelcomeUIController

getUsers()returnResults()

getPublicItems()showSearchForm()

searchUsers()showResults()

getPublicEvents()editUserProfile()

createEvent()browseEvents()

UserListUIController

getUserProfile()showResults()deleteUser()

EventListUIController

viewPublicEvent()showResults()deleteEvent()

ModelFacade





deleteEvent()

Event EventControl

getPublicEvents()createEvent()

persist()getEvents()

viewPublicEvent()deleteEvent()

List

add()

UserControl




updateProfile()


Blog

View(from Use Case View)

Model(from Use Case View)



2.2.1.3. Registered User Module

EventListUI

shoeEventList()showResults()

showConfirmation()

WelcomeUI

show()

ProfileUI

showProfileForm()showResults()

CreateEventUI

showCreateEventForm()showResults()

Registered User


Event

add()

WelcomeUIController

getUsers()returnResults()

getPublicItems()showSearchForm()

searchUsers()showResults()

getPublicEvents()editUserProfile()

createEvent()browseEvents()

EventListUIController

viewPublicEvent()showResults()deleteEvent()

ProfileUIController

checkFields()showResults()

CreateEventUIController

validateFields()showResults()

ModelFacade





deleteEvent()

List

add()

(from Unregistered User Package)

UserProfile

UserControl




updateProfile()

AppUser

View(from Use Case View)

Model(from Use Case View)

EventControl

getPublicEvents()createEvent()

persist()getEvents()

viewPublicEvent()deleteEvent()

ItemProfile



2.2.1.4. Model Classes

AppUser<<entity>>

UserProfile<<entity>>

Blog<<entity>>

UserControl

checkLogin()registerUser()persist()getUserList()getUserProfile()getBlogEntries()searchUsers()deleteUser()updateProfile()

<<control>>

Filter<<entity>>

ModelFacade

checkLogin()showResults()registerUser()getUserList()returnResults()getUserProfile()searchUsers()getPublicEvents()viewPublicEvent()deleteUser()updateProfile()createEvent()getEvents()deleteEvent()

<<boundary>>

EventControl

getPublicEvents()createEvent()persist()getEvents()viewPublicEvent()deleteEvent()

<<control>>

Event

add()

<<entity>>



3. Component Design

3.1. Introduction

The purpose of this document is to provide a component design for the KSU Student

Portal. The design will outline the internal design of each component.

This document describes the technical issues of this project. For details about the

functionality of the system check the Vision and Architecture Design documents. This

document complements the other two by providing implementations details of the

system.

We first describe the target architecture of the system and the technology used. Then,

we described the components, packages and classes. Finally, we discuss some

implementation issues.

As a reminder, this project is an enterprise Web application that uses rigorous design

methods and new technologies. The system is divided in three layers: data, model and

view. The model is implemented using EJB 3.0 and the view with JSF 1.2.



3.2. Model Driven Architecture

One of the goals of this project is to follow a model driven approach where we build

models of the system with different levels of details depending on the information that

we have at a given time. This way, we can make general models that can fit in any

platform allowing this to reuse models. This can be very useful to test designs and to

build prototypes. For example, we can build a platform independent model and then

built prototypes to test several architectures. We can implement directly from this high

level model and get accurate results. But when it comes to the final product we need to

create a more refine model that match the implementation.

In phase one, we gathered the requirements and we started to work on the solution.

Phase 2 was a critical phase where we created a platform independent model. This

model was not only platform/language independent but also architecture independent.

Note that it didn’t require that the system was a Web application.

In this last phase we created the implementation and the component design which

includes all the details needed to understand the system. It is important to take a look

again to the vision document and the architecture design document to be able to

understand this document and see how we followed the same structure just adding

more details.

Basically, we took that model and implemented it into the J2EE platform as a Web

application. We added all the technology and architecture (client-server) details needed

to understand the final product.

Some functionality was added in this last phase. This is discussed in section 3.5.2.



Next figure shows the model driven architecture approach:

In this last phase, we tool the platform independent model and create a J2EE Web

Application model. We skipped one possible model that could include Java/J2EE

details but exclude web technologies details. Since, from the beginning it was clear that

this was going to be a web application we skipped this step.

In this document we describe the last model that includes all the details including

technology and architecture details. To properly understand this model we begin by

giving a little introduction of the architecture and technology used.

REQUIREMENTS

PLATFORM INDEPENDENT MODEL

IMPLEMENTATION INDEP. MODEL J2EE PLATFORM

IMPL. MODEL IMPL. MODEL IMPL. MODEL J2EE Web App

Phase 1

Phase 2

Phase 3



3.3. System Architecture The system is a Web application built using the J2EE platform. It is OS and DBMS

independent; although it was built with Oracle in mind it may support other DBMS.

The application supports a distributed environment using EJBs as distributed

components. The EJB 3.0 describes the middleware needed to implement all the

security and networking functionality that the EJBs components need. There are many

application servers that implement the EJB 3.0 specification and provide the

middleware necessary to run this application. The system was tested and implemented

using Oracle OC4J application server.

The system business logic will be handled by the EJBs components that will

communicate with the database and perform different operations. The load can be

balanced and these components can be distributed in several servers. There will be

one main server that runs the application and controls the other servers that execute

the EJBs. There will be also a database server that executes the DBMS.

The clients can connect from the internet or within the network. The key is that the

server farm is secured and reliable, using high speed connections of at least 100Mbps

to send and receive data. The application server and the EJBs components need to

query the database server very often requesting data that need to be transmitted as

fast as possible to achieve an acceptable level of performance.

In the figure below the target architecture is shown, some aspects can be changed

since this application was built trying to be as flexible and portable as possible. But

some issues such as high speed connection between the EJBs and database are very

important and must be kept.



Database ServerORACLE

XP Pro OS

Firewall Router

Linux OS

XP OS

Ethernet Switch

10 Mbit/s Ethernet

10 Mbit/s Ethernet

10M

bit/s Ethernet

INTERNET

Fast Ethernet Switch

100M

b it/s Ethe rnet

100M

bit/s Ethernet

10M

bit/s

Eth

erne

t

10 Mbit/s

Ethernet

ORACLEDB

100 Mbit/s Ethernet 100 Mbit/s Ethernet

Application ServerOC4J

Bean Container

Bean Container

Bean Container

10 Mbit/s Ethernet

XP Pro OS

Linux OS

XP OS

Mac OS

XP Home OS

As we can see in the picture, clients can connect from the Internet or from the same

network. There will be a firewall to protect the server farm from be attacked. Since this

is a Web application clients can run any OS.

Since the application was built with a distribute environment in mind, some of the logic

that could be done by the database server has been moved to the business logic layer

and is performed by the session beans. This decision was made to avoid overloading

the database server and distribute the load between different CPUs. So, to take full

advantage of the application we will require at least four processors to execute the

EJBs, one to execute the user’s logic (registration, get users, edit profile…), another

one to execute the news/events logic, another one for the articles and another one for

the rest of EJBs.

The events, news and articles need a considerable amount of computational

capabilities since they execute complex search and filtering algorithms.



In the next figure, another view of the system is shown dividing the components in

logical layer to see the architecture and technology from another point of view.

WEB BROWSERJavaScript

Users

Admin

ORACLEDB

CLIENT TIER PRESENTATION TIER APPLICATION TIER DATA TIER

Web ServerOC4J

HTTP/JSP page

HTTP/JSP page

generates

HTTP/JSP request

HTTP/JSP request

Application ServerOC4J

response

response

SessionBean

SessionBean

SessionBean

EntityBean

EntityBean

EntityBean

Database ServerORACLE

Bean Container

Bean Container

Bean Container

gene

rate

s

ADF

JSF

uses

uses

includes

includes

The clients send request using a Web browser that supports JavaScript. The Web

server will manage the request and query application server to perform some action.

The Web server will request the application server to look-up to find the corresponding

EJB that will perform the action since the EJBs can be in different computer. Then, the

EJBs will query the database to fetch data. After that the information is formatted and

sends back to the Web server that will incorporate JSF/ADF UI components and

generate the view that will be shown in the client browser. Usually, the application and

Web server will be in the same machine.



3.4. Technologies In this section we will describe the technology used to develop the application. The

goal is not to explain the technology; this is just a small overview that helps to explain

why this technology was chosen. I focus on the main two technologies Java Server

Faces and Enterprise JavaBeans 3.0. For more information about the J2EE platform

check [14].

3.4.1. Data Layer

The goal of this project is to build an application that is database independent. We will

use the EJB 3.0 technology that implements an O-R mapping approach to achieve this

independency. We just require that the DBMS supports sequences to generate IDs.

3.4.2. Model Layer In this section we describe the technology used to implement the business logic

focusing mainly in the new EJB 3.0 technology.

3.4.2.1. EJB 3.0 Enterprise Java Beans is an architecture that defines the way of building distributed

components on the server side. This technology guarantees that the programmed

components are scalable, effective and safe. EJB technology uses other Java APIs

such as RMI to provide all the middleware needed to develop enterprise applications. It

provides physical situation transparency and helps modulating programming by having

the components distributes in different machines transparently to the programmer. This

helps to improve performance and scalability.



There are three types of EJBs:

1. Session Beans (SB): The session EJB is in charge of solving the business logic

of the application. We can say that each method contained in a SB solves a use

case (function) of the application, for example: User Control, Prices Agent or

Processes Control.

There are two types of SB:

1) Stateless Session Beans (SLSB): The SLSB is component without state,

this means, they don't keep any relationship between different calls from

a client. Even more, between two calls to the same type of SLSB is

possible that the container addresses the client to different instances of

the component. Another fact of how they behave this type of

components it is their relationship with the number of users. For N users

there are M instances being M < N in most of the cases. The maximum

value and minimum of M is configurable in most of the servers. With

these two values is defined the size of the object pool.

2) Statefull Session Beans (SFSB): The SFSB is the opposite of the SLSB,

they maintain the state, this means, they have a conversation one to

one with each client that invokes them.

2. Entity Beans (SB): The entity EJB is directly related with the application data,

are objects that maintain in memory the data that the application manages like

News, Forums, Users.

The Entity Beans usually map the relational database tables, although it is also

possible that they maintain the data persistence in files, for example a XML, or

in LDAP. In any of the cases the objective of an Entity Bean is to search the

data in memory from a persistent source and to maintain a total synchronization

between the state of the data in memory and the source of the data.

For this reason it is said that the Entity Bean are the EJB that survive to the

system falls, in the case of a system failure, the data in memory is kept in a

persistent device, with this, when the server is restarted they recovered without

any problem.



There are two forms of managing persistence: one lets the programmer to

manually take care of the persistence, in the other the container takes care of

everything.

1) Bean Managed Persistence: The BMP is the Entity Bean that support

persistence thanks to the programmer's explicit instructions. More and

more often this type of Entity Beans is used less, but there are still some

operations that can only be carried out thanks to the programmer

abilities.

2) Container Managed Persistence: The CMP supports the persistence in

a declarative or implicit way thanks to the container.

3. Message-Driven Beans: They are very similar to the session beans but they

receive messages without responding to the client, in other words, they are

asynchronous.

EJB 2.x

EJB 2.x is the previous version of the EJB specification and the most used one. It is

crucial to understand this version before moving to the new EJB 3.0 specification. An

EJB 2.x has the next parts:

EJB class that implements the business methods and life cycle methods; uses

other helper classes and libraries to implement.

Client-view API: consists of EJB home interface and remote interface.

o Home interface: controls life cycle: create, remove, and find methods.

There should be one Home interface for each local or remote interface.

o Remote interface: to invoke the EJB object methods (if the EJB is

declared as remote).

o Local Interface: Idem for local EJB.



Deployment Descriptor: XML document for bean assembler and deployed on

the container.

o A declaration about EJB environment needed for customizing the bean

to the operating environment.

Container Runtime services include: transactions, security, distribution, load

balancing, multithreading, persistence, failure recovery, resource pooling, state

management, clustering…



A graphical representation of a session bean and an entity bean is how below:

Session Facade Impl

Session Facade

SessionEJBEJB_Context : SessionContext = null

SessionEJB()<<EJBCreateMethod>> ejbCreate()ejbRemove()ejbActivate()ejbPassivate()setSessionContext()

S

SessionLocal

Local

Local Home

SessionLocalHome

<<EJBCreateMethod>> create()

SessionRemote

Remote

Home

SessionRemoteHome

<<EJBCreateMethod>> create()

EntityEJBEJB_Context : EntityContext

entityEJB()<<EJBCreateMethod>> ejbCreate()<<EJBCreateMethod>> ejbPostCreate()ejbActivate()ejbPassivate()ejbLoad()ejbStore()ejbRemove()setEntityContext()unsetEntityContext()

E

EntityLocal

Local

Local Home

EntityLocalHome

<<EJBFinderMethod>> findByPrimaryKey()<<EJBCreateMethod>> create()

entityPK

hashCode()equals()toString()

<<EJBPrimaryKey>>

Home

EntityRemoteHome

EntityRemote

Remote

entityPK

hashCode()equals()toString()

<<EJBPrimaryKey>>

<<EJBRealizeLocal>>

<<references>>

<<EJBRealizeLocalHo...

<<instantiate>><<EJBRealizeRemote>>

<<references>>

<<instantiate>>

<<EJBRealizeRemotelHo...

<<EJBRealizeLocal>>

<<references>>

<<EJBRealizeLocalHo...

<<instantiate>>

<<EJBPrimaryKey>>

<<EJBRealizeRemoteHo...

<<EJBRealizeRemote>>

<<instantiate>>

<<references>>

<<EJBPrimaryKey>>



As we can see, the problem of the EJB 2.x specification was its complexity. It did take

care of a big part of the middleware but it required lot of effort to understand and

develop these components for the following reasons:

1. Too many interfaces and methods to override because of the client-view API.

2. Too many deployment descriptors (XML files) which are really difficult to

maintain.

The new EJB 3.0 was introduced to overcome these problems and make the

development more easily. It has the following features:

1. Eliminates the home interfaces. Now EJBs are POJO.

2. Abstracts the use of local and remote interfaces make it easier to use. We just

create the Bean as a POJO.

3. It uses an “Entity Manager” API that implements and Object-Relational Mapping

(ORM) approach like Hibernate.

4. It uses the new Java 5 annotation to eliminate the use of XML files

encapsulating the object with its configuration helping to maintain the system

and to hide the information. It also reduces the number of files.

5. It includes many other minor improvements.

Summarizing, the two big changes are: the elimination of the interfaces, making

development easier and the introduction of an ORM approach. Object-Relational

mapping is a programming technique that links databases to object-oriented language

concepts, creating the effect of a "virtual object database". Basically, EJB 3.0 takes the

idea from Hibernate or Top-Link and adds another level of abstraction defining an API

that uses Java 5 annotations instead of XML files to configure the mapping between

objects and tables. This API can be implemented using Hibernate or Top-Link. For

more information about ORM visit http://en.wikipedia.org/wiki/Object-

relational_mapping

For these reasons and because it is an open standard supported by many

organizations such as IBM or Oracle I have chosen this technology. For more

information check [14, 15].

http://en.wikipedia.org/wiki/Object-relational_mapping

http://en.wikipedia.org/wiki/Object-relational_mapping



3.4.2.2. Java 5 Java 5 is the name of new Java API. It includes new interesting features. In the

application the more important ones are used, which are:

1. Metadata (Java annotation): This feature provides the ability to associate

additional data alongside Java classes, interfaces, methods, and fields. This

additional data, or annotation, can be read by the javac compiler or other tools,

and depending on configuration can also be stored in the class file and can be

discovered at runtime using the Java reflection API.

2. Generic Types and Enhanced Loops to support generic object lists.

It also includes other features, for more information visit [16].

3.4.2.3. JNDI JNDI is a Java technology used in distributed environment base on Java applications.

JNDI is a Java implementation of Naming and directory services that play a vital role in

intranets and the Internet by providing network-wide sharing of a variety of information

about users, machines, networks, services, and applications. A naming service

maintains a set of bindings. Bindings relate names to objects. All objects in a naming

system are named in the same way. Clients use the naming service to locate objects

by name.

This technology is used to locate the EJBs and achieve a physical location

transparency.



3.4.3. View Layer

3.4.3.1. Overview In this section we will describe the technology used in the ViewController module. The

technologies are organized in a hierarchy where some technologies rely on others. The

next figure shows the relation between the technologies used:

JAVA

SERVLETS

JSP

JSF

ADF

uses

compile to

BYTECODE

compile to

compile to

In the first level we have the native Java code and its corresponding portable byte

code. To generate the view, two traditional view generation techniques are used in the

second level: JSP pages and Servlets. Servlets are special Java classes that can

generate HTML code to generate the view. JSP pages live in a JSP container that can

dynamically compile the JSP pages to Servlets to generate dynamic web content. Two

new technologies, JSF and ADF, are used within the JSP enriching the view by adding

UI components.

Check [14] form more information about level two technologies.



3.4.3.2. Servlets A Servlet is a software application written in Java that is executed in the server.

The Java Servlet API allows a software developer to add dynamic content to a web

server using the Java platform. The generated content is commonly HTML, but may be

other data such as XML.

A Servlet is an object that receives requests and generates a response based on the

request. The API defines HTTP subclasses of the generic Servlet requests and

responses as well as an HTTP session object that tracks multiple requests and

responses between the web server and a client. Servlets may be packaged as a Web

application. The main packages are javax.servlet and

javax.servlet.http.



The programmer in order to create a Servlet only needs to write a class which extends

from HttpServlet and implement the method doGet or doPost.

Before the JSP pages appear, the main use of the Servlets was to generate the view of

an application web:

1. Receive petition HTTP associated to a URL

2. Read parameters

3. Invoke operation on the business model

4. Generate HTML

Nowadays, the JSP pages are use to generate the view (HTML) because as we’ll see

later on Servlets have many limitations. JSP pages provide better mechanisms to

generate dynamically Web content. But still, the Servlets are really important and are

usually used as application controllers.

3.4.3.3. JSP Pages The main problem with Servlets is that the text generate for the view is mix with Java

code and this has some disadvantages:

• It is not possible to use tools for generation of HTML, WML, etc. directly.

• The text generation needs to be written by a person with knowledge of Java,

which is economically very expensive.

• Changes in the aspect of the graphic interface require recompilation, creation of

a new .war file and re-start the server. In an application web, especially in

Internet, changes in the graphic interface are very common.



We want to be in a situation were there is a complete job separation:

People that work on the graphic aspect with knowledge of graphic design and

tools for generation of HTML and WML.

People that implement the controller and the model like computer engineering

with design and implementation knowledge.

JSP pages were created to overcome this Servlets limitation on the generation of the

view. Servlets are still use as application controllers but JSP pages have substituted

them in the view generation.

JavaServer Pages (JSP) it is a group of technologies that allow the dynamic

generation of web pages using a mark-up language like HTML or XML, to generate the

content of the web pages.

To be able to use this technology it is necessary a web server that support HTML

pages, and code that implements a JSP container where we can execute the JSP tags.

It’s important to realize that the JSP specification doesn’t require that JSP are

implemented using Servlets (Java language). The main packages are

javax.servlet.jsp y javax.servlet.jsp.tagext.



3.4.3.4. Java Server Faces Java Server Faces (JSF) is the new standard from Sun Microsystems that pretends to

facilities web development by adding UI components to the JSP pages plus a MVC

framework. We will begin by taking a look to the MVC pattern and the JSF rival Struts.

Then, we will discuss more deeply the JSF.

3.4.3.4.1. MVC Pattern

The MVC architecture pattern (Model-View-Controller) is a pattern that defines the

independent organization of the Model (Objects of Business), the View (interface with

the user or another system) and the Controller (controller of the workflow of the

application). It is used regularly in many areas especially in web applications.



3.4.3.4.2. Struts

Struts is a tool for the development of applications Web under the MVC patron using

the J2EE platform. It is a framework that implements the MVC architecture pattern in

Java. It works on any application server that implements the APIs Servlets and JSP

A framework is the extension of a language by means of one or more classes

hierarchies that implement a functionality and (optionally) they can be extended. The

framework can involve TagLibraries.

The browser generates a request that is handled by the Controller (a specialized

Servlet). The Servlet is in charge of analyzing the request, follow the configuration that

has been programmed in the XML and call the corresponding Action (A java class that

is used to access to the model) passing the corresponding parameters. The Action will

instance or use the business objects (EJB) and they will do the task. Depending on the

result of Action, the Controller will redirect to one or more JSP pages, which will be

able to access the objects of the Model in order to carry out its task.

1. Request

3. Results

5. Uses 6. Result

4. Redirect

2. Action

WEB

BROWSER

VIEW (JSP/TagLibs)

CONTROLLER

(Servlet)

MODEL (EJBs)

STRUTS



The Servlet Front Controller pattern is the key of Struts implementation providing the

basic structure of the MVC pattern, the structure is how below:

Let’s take a look to each class of the Struts MVC implementation:

• ActionServlet.

o It’s the Servlet Front Controller.

o In web.xml file is specified that all the URLs that imply process (GET or

POST) are redirect to this servlet.

E.g.: URLs that finishes in .do

• ActionForm Classes.

o If the programmer wants it, can access to the request parameters

through a JavaBean that extends from ActionForm.

Specially useful in forms.



• Action Classes (method execute).

o It access to the request parameters, directly or via the corresponding

ActionForm. It carries out the operation invoking a method from the

model. Usually the Session Facade of the model. The Session Facade

is a design pattern that will discuss later on.

o It leaves the result returned by the method in the request or in the

session.

o It returns an ActionForward object that represents the URL that is

necessary to visualize next (sendRedirect or forward).

As we can see, using Struts is quite complex, we need to write lots of classes and

manage too many XML files. JSF has many similarities but it was introduced to

overcome the difficulty of using Struts and make Web development easier.

3.4.3.4.3. JSF JavaServer Faces (JSF) is a Java-based Web application framework that simplifies the

development of user interfaces for Java EE applications. It has some similarities with

Struts such as Tag libraries or state management. But it improves some of the

techniques used in Struts and includes new technologies. For example, it includes UI

components to enrich the view and make the development easier by using a drag &

drop component design like Java Swing in Web applications. Also, it replaces the

action classes and action forms with Managed Beans that take care of the UI

components. Summarizing, JSF includes:

A set of APIs for representing user interface (UI) components and managing

their state, handling events and input validation, defining page navigation, and

supporting internationalization and accessibility

A default set of UI components

Two JavaServer Pages (JSP) custom tag libraries for expressing a JavaServer

Faces interface within a JSP page.

A server-side event model

State management

Managed Beans (JavaBeans created with dependency injection)



JSF implements the Servlet Front Controller pattern too. The main controller is the

javax.faces.webapp.FacesServlet class that must be implemented by the application

server. Every time the user does something, such as clicking a button or submitting a

form, an event occurs. Event notification is then sent via HTTP to the server. On the

server is a web container that employs this special Servlet.

We also have a main configuration XML file where we include:

- Page Navigation Specification

- Internationalization Options

- Managed Beans

- Lifecycle configurations

- Message Bundle Configuration

Java Server Faces Technology relies on other technologies as shows in the picture

below:

Basically, the JSF components are “injected” in the JSP pages and managed by its

corresponding Bean. IDEs like JDeveloper support component drag & drop and

automatic generation of components in the Java Bean with their corresponding getters

and setters methods.



The main features are:

Page navigation specification: In the main descriptor we specify the navigation

flow of the pages. When clicking on a link or pressing a button the action will

call a method (action) of the managed bean that will perform the action which

usually is call the model. Then, the method returns a string that forwards to

another page, this string is specified in the main descriptor and the main

controller will be in charge of finding this string in the descriptor and look-up for

the next page.

Sometimes when pressing a link we don’t perform any action, in this case, the

action just return the string that will be use to find the next page. This way, we

don’t depend on JSP pages names been easer to maintain. IDEs such as

JDeveloper can read the main descriptor and build a graphic page flow diagram

that makes navigation specification very easy.

Standard user interface components: JSF specification is a standard that

specifies Java UI components such buttons, links and inputs that can be drag &

drop in the JSP pages to enrich the view.

User input validation: JSF incorporates a tag library that includes standard

validation tags to check the type or length of the inputs and send standard

messages. Developers can create their on validation tags and change the error

messages.

Easy error handling: JSF provides mechanisms as JSF messages that make

really easy show error messages to the users.

Java bean management: JSF provides Java Beans to manage the JSP pages

and it JSF components. They perform different actions in the view such

validation or input conversion and are also in charge to call the model to

perform the business logic.

The managed beans include all the UI components of the JSP page that they

manage with the getter and setters methods.



Event handling: JSF provide a Event handling mechanism that will call the

Faces Servlets every time the user perform an action. This main server is in

charge of controlling the navigation. It is the main controller; the managed

beans are “sub controllers” that only control their corresponding JSP page.

Internationalization support: JSF faces were built to support pages with several

languages. It uses the java.util.locale and the main configuration file is used to

configure the available languages. A message bundle can be used with several

message.properties where we write all the messages, each file will be written in

one of the supported languages.

IDE Integration: JSF were created to help developers to build web interfaces

like building desktop application. IDEs are been build to support this feature.

No Logic in JSP pages: JSF help to separate roles and let the Web designer

perform his/her job without Java language knowledge. Further some, no logic is

used in the JSF tags. This improves the Struts or JSTL libraries where,

although they provide a good set of tags, they still use loops and conditions.

JSF doesn’t use conditions or loops inside the JSP pages.



3.4.3.5. ADF Oracle Application Development Framework, usually called Oracle ADF, is a

commercial framework for quickly creating enterprise applications. In this project we

will use the ADF UI components provided by Oracle. Those are just a small part of the

whole ADF framework focus on complementing the JSF components adding more

features such as better tables, file upload menus and so on. These components work

like the JSF components.

3.4.3.6. JavaScript Java Script is client side code that is executed in the Web browser. This technology is

useful to perform basic functions on the client side avoiding overload the network and

the server.

3.4.3.7. Cascading Style Sheets (CSS) CSS is a standard language created to help designing Web applications. This language

allows authors and users to attach style (e.g., fonts, spacing, and aural cues) to

structured documents (e.g., HTML documents and XML applications). By separating

the presentation style of documents from the content of documents, CSS simplifies

Web authoring and site maintenance.

For more information check [18].



3.5. Component Design

3.5.1. Overview

3.5.1.1. Package Overview In this section, we will describe the system design. First of all, we are going to view the

last version of the use case model describing the new functionalities that were added at

the end of the process.

Then, we will see the packages and their classes. The system has to main modules:

the model and the ViewController. The model implements the business logic using

EJBs. The ViewController implements the view and the controllers of the MVC pattern.

Model ViewController

test.model

view.backing

Web Contentmodel

JSP Pages

Managed Beans (ADF/JSF UI Components)

Session Facade + EJBs

Junit Test Cases

The Model module contents two packages; one is the Junit test cases that execute the

critical functions of the system. The other package contents the EJBs, session beans

and entity beans that perform all business logic. It also contents a class that

implements the session façade pattern and is in charges of look-up the EJBs.



The ViewController module depends on the model since it uses the session façade to

interact with it. It also has two parts: the web content that includes the JSP pages, the

JavaScript files, images, configuration files and all the tag libraries. Basically it has

everything that the web server needs. The view.backing package has all the managed

beans that the JSF needs to take care of the UI components. For each JSP page, there

will be a managed bean that contents all the UI components used in the page and all

the logic needed to manage them. That class is also in charge of calling the model and

returning the string that will be used for page navigation.

3.5.1.2. Process Overview We are going to describe the general process of the system that begins when the user

sends a request by performing an action and ends when the user receives the result

HTML page in the browser.



Recall the graph from the high level analysis model from the vision document:

Now we are going to refine this model adding implementation details. The control

classes from the view will change to Java Classes and Servlets, users will be JSP

pages. Control classes from model will be Session Beans and Entity classes Entity

Beans. Also, more details will be added.

AppUser

UserControl




updateProfile()

Model

View

ModelFacade





deleteEvent()

MainUIController

checkLogin()validateInput()showResults()checkResults()

register()showWelcome()

RegisterUIController

submit()validateFields()showResults()

MainUI

showLoginForm()

RegisterUI

showRegForm()showResults()

User



Next figure shows the refined process:

Request Form

Result JSP Page

Session Facade

Session Facade Impl

S

SessionBean

E

EntityBean

<<references>>

<<references>>

Result Servlet <<generates>>

JSFADF

<<includes>>

<<includes>>

Model

ViewController

view.backing

Result JSF Controller

<<references>>

<<include>><<include>>

G S

Faces Servlet

request

<<action>>

<<forward>>

<<return>>

The process is started by the user by clicking a link or filling a form and pressing the

submit button. As we mention before, every time that the user perform an action the

request is handled by the Faces Servlets that uses the main descriptor where we write

all the navigation information. In case of link, we just want to change from page to page

and we don’t need to call the model, further some, sometimes we don’t even have to

perform any action in the managed bean, in this case the link will just have a string in

the action field that will be used by the Faces Servlet to find the next page by looking

the page navigation specification.



Then, the main Servlet will call the JSP page Servlet to dynamically generate the

HTML page that is send to the user. Remember that every JSP page has a Servlet that

is automatically compiled by the JSP container and the developer doesn’t need to care

about it.

There are certain occasions that we don’t need to call the model but we won’t to

perform an operation in the view that is done by the managed bean by performing an

action just like using Struts. The method in the managed bean will return a string that

will be used by the Faces Servlet to forward to the corresponding Servlet that will

generate the HTML code. Recall that the managed bean contents all the JSF/ADF UI

components that will be rendered (<<include>>) when the Servlet generates the view.

Finally, in some cases, usually when submitting form info, the whole process takes

place:

1) User enters data and submits the form by clicking the submit button.

2) The Command Action calls a method of the managed bean of that

particular page.

3) The method instantiates the model façade and calls a method from this

class.

4) The method in the model façade looks up for the session bean that will

perform the functionality.

5) The model façade instantiate the session bean and calls the

corresponding method.

6) The session bean performs the business logic. Usually if the user

request data, the session bean will create a entity bean or a generic list

of entity beans using the entity manager. The entity manager follows an

Object-Relational Mapping approach to map tables to objects (entity

beans).

7) The results are returned to model façade and them back to the

managed bean.

8) The managed bean returns a string that will be used by the Faces

Servlet to look-up and forward to the next page.

9) The corresponding page Servlet is executed and it will include all the UI

components from this new JSP page.

10) The Servlets generates dynamically the HTML code and the page is

sent to the user.



3.5.2. Packages

3.5.2.1. Model Layer A simplified version of the model is shown in the next figure:

Session Facade

Session Facade Impl

E

CountryCode

E

Course

E

Language

E

LinkE

State

S

AppUserSessionBeanEJB

S

ArticleSessionBeanEJB

S

EventSessionBeanEJB

S

BlogessionBeanEJB

S

UtilessionBeanEJB

S

LinkessionBeanEJB

1..1

0..n

<<references>>

1..1

0..n

<<references>>

1..1

0..n

<<references>>

1..1

0..n

<<references>>

1..1

0..n

<<references>>

1..1

0..n

<<references>>

1..1

1..1

<<create>>

1..1

1..1

<<create>>

1..1

1..1

<<create>>

1..1

1..1

<<create>>

1..1

1..1

<<create>>

All Session Beans wil l return either a Java List or a single Enity Bean. this is only shown on this bean to keep the diagram small.

E

BlogEntry

1..1

1..1

<<create>>

E

Blog

1..1

1..1

<<create>>

0..n 10..n 1

E

AppUser

1..1

1..1

<<create>>

java.uti l.List

1..11..1

<<create>>

0..n

1

0..n

1

E

Profi le

E

Article

E

Event

1..1

1..1

<<create>>

E

Filter

The relations of the Entity Beans are omited

1..1

1..1

<<create>>

1..1

1..1

<<create>>

1..1

1..1

<<create>>

1..1

1..1

<<create>>

To simplified the diagram some details were omitted and will be shown later one. The

methods and attributes are omitted; the relations between Entity Beans are also

omitted and object List is only shown once.

If we take a look at the figure, we can see that we have a class which is the entry point

to the model and implements two design patterns: Session Façade and Business

Delegate.



The Session Façade will instantiate the session beans that may be in a different CPU.

The session beans will perform the desire operation often times returning an entity

bean or a list of entity beans as shown in the figure. The session beans use the entity

manager API to perform the database access.

3.5.2.1.1. Model Façade As we mention before, this is a crucial element of the system. It is composed of a

public interface where we publish all the methods available for the client and its

corresponding implementation. This class implements the session façade and business

delegate patterns. The idea of the Session Façade pattern is to have one single entry

point in the system helping to maintainability allowing changes on the model without

affecting the client (view).

It also reduces the amount of remote calls since this class will be the one that is going

to make the remote calls and look up for the EJBs. So, the Session Façade will be local

to the clients and should reside in the Web server, this way the network traffic will

decrease considerably. For more information about design patterns check section 5.

This class also implements the business delegate pattern. This pattern is used to hide

the underlying technology used in the model and separate it from the view allowing

changing the technology used in the model without affecting the view. For example, if

we decide not to use EJBs and use other framework such Spring the clients won’t be

affected by this change making the system easier to maintain.



The methods available to the client from the Interface are shown below:

boolean addCourse(String code, String cName);

boolean addLanguage(String lanCode, String language);

void changePassword(String login, String password);

public boolean checkLogin(String login, String password);

public boolean checkPK(String login);

public AppUser createAppUser(String login, String password, String

fName, String lName, String about, String city, String email, String

pPicture, String quotes String state, String street, String telf,

String visibility, String country, String[] courseList, String hUniv,

String[] languageList, String mayor);

Article createArticle(AppUser aAuthor, String aHeader, String aText,

String aUrl, String country, String course, String hUniv, String

language, String mayor);

Blog createBlog(AppUser appUser, String visibility);

BlogEntry createBlogEntry(String bId, String picture, String text,

String header);

Event createEvent(AppUser eAuthor, String eHeader, String eText,

String visibility, String country, String course, String hUniv, String

language, String mayor);

Link createLink(AppUser lAuthor, String lLink);

public void removeAppUser(String uId);

void removeArticle(String article);

void removeBlog(String bId);

void removeBlogEntry(String beId);

void removeCourse(String course);

void removeEvent(String event);

void removeLanguage(String lanCode);

void removeLink(String link);

List<Article> searchArticles(String param);

List<Event> searchEvents(String param);

List<Event> searchPublicEvents(String param);

List<AppUser> searchPublicUsers(String param);

List<AppUser> searchUsers(String param);

void updateAppUser(String login, String fName, String lName,

String about, String city, String email, String pPicture, String

quotes, String state, String street, String telf, String visibility,

String blogVis, String country, String[] courseList, String hUniv,

String[] languageList, String mayor);



void updateArticle(String aId, String aHeader, String aText, String

aUrl, String country, String course, String hUniv, String language,

String mayor);

void updateBlogEntry(Long bId, String picture, String text, String

header);

void updateEvent(String eId, String eHeader, String eText,

String visibility, String country, String course,

String hUniv, String language, String mayor);

public AppUser getAppUser(String uId);

public List<AppUser> getAppUsers();

Article getArticle(String aId);

List<Article> getArticles();

List<Article> getArticles(Profile profile);

Blog getBlog(String bId);

BlogEntry getBlogEntry(String beId);

List<Blog> getBlogs();

List<CountryCode> getCountries();

List<Course> getCourses();

Event getEvent(String eId);

List<Event> getEvents();

List<Event> getEvents(Profile profile);

List<Language> getLanguages();

List<AppUser> getPublicAppUsers();

List<Blog> getPublicBlogs();

List<Event> getPublicEvents();

List<State> getStates();

Blog getUserBlog(String uId);

Profile getUserProfile(String login);

List<BlogEntry> getUserBlogEntries(String uId);



3.5.2.1.2. Entity Beans The entity beans and their relations represent the data model of the system and will

maintain the same relations than tables in the relational database. The entity manager

will manage the mapping.

Next figure shows the main relations between the entity beans:

E

BlogEntry

E

Course

E

Language

E

CountryCodeE

Filter

0..1

1

0..1

1

0..1

1

0..1

1

0..1

1

0..1

1

E

StateE

Link

E

Blog

1 0..n1 0..n

E

Profile

0..n

1

0..n

1

0..n

1

0..n

1

0..1

1

0..1

1

E

Event

1

1

1

1

E

Article

1

1

1

1

E

AppUser

1

1

1

1

0..n

1

0..n

1

<<create>>

1

1

1

1

11 11

0..n

1

0..n

1

<<create>>0..n

1

0..n

1

<<create>>

The User is the center of the application. He/She may manage links, articles, events or

the blog. The user has one profile associated that may have one country and several

languages/courses. The filter is associated to events/articles and may only have one

course/language



3.5.2.1.3. Implementation Classes In this section we are going to take a closer look to the classes in the model package.

The test.model package just has one class that contents the unit test cases to test the

façade methods. First, we are going to take a closer look on the EJBs structure and

then show the most critical implementation classes.

In the next figure we show the structure that all the EJBs follow. To simplify the

diagram we only show one session bean, but note that the rest of them have the same

relations.

Session Facade

Session Facade Impl

ArticleSessionBeanLocal ArticleSessionBeanRemote

javax.persistence.EntityManagerS

ArticleSessionBeanEJB

1..1 0..n<<references>>

<<implement>>

<<implement>>

11 11

java.util.List

0..n

1

E

Article

1..1

1..1

<<create>>

0..n

1

0..n

1

1

0..n

OR Mapping

In the figure we can see the example of the article session bean. The session façade

will look up the session bean and call one of the methods. To get the reference the

session façade can call the remote or local interface. The session bean will use the

Entity Manager to fetch the data from the relational database and use the list to store

the results that will be returned.



Now we are going to show the actual implementation classes. Since there are many of

them we will divide and show the classes in groups omitting some details.

AppUser:



Event/Articles:



User Blog:



3.5.2.2. View Layer The ViewController Module consists in the Web content and the managed beans from

the view.backing package. Each JSP page will have one managed bean that will

perform operations on it UI components and will also be in charge of calling the model.

Summarizing, a JSP page will use the JSF Tag Library and will have several JSF UI

components included in the page as part of the view. The corresponding managed

bean will have these components with their getters and setters methods. Every time

that the page is compiled the managed bean is instantiated and the constructor and the

setter methods are called. The developer can implement logic in the constructor to

perform operations such page control access. He/She can also add logic to the setter

methods to select whether or not render a specific component or to set a default value

(e.g. when editing an item). When submitting information, the command button will

execute an action from the managed bean that can use the getters to extract the

information from the form to call the model.

Finally, there is another class which is not a managed bean. This class implements the

transfer object design pattern and is used to transform the generic list that the model

returns to the specific list that the view uses. Note, that we want to achieve

independence between the model and the view, so the model has to use generic types

because the view may be changed. This class will adapt the generic lists to the lists

used in the JSF components such menus. The menus in the JSF use lists of

SelectItems objects, the ModelConvert class transform the generic lists to SelectItem

lists. This is the implementation of the transfer object pattern.



This is show in the figure below:

JSP Page

Session Facade Impl

Session Facade

JSP Page Managed Bean

1

1

1

1

1..1

1..1

<<references>>

Model Convert

0..n

1..1<<references>>

SelectItem

Collection

1

1

1

1

E

EntityEJB

1

1

1

1

There are some objects such data tables that support generic types so it will be no

necessary to use the model convert. Looking at the figure we can see that each JSP

page has a managed bean that is in charge of calling the model. When the model

returns the results they may be converted to SelectItem list if necessary using the

model convert.



Session Check

As we mentioned before, every JSP page has a backing bean that contents the UI

components. Another function of this bean is to check the access to the page and

control the session. All managed beans will extend from the SessionCheck class that

implements a method called checkSession() that checks two things:

- The user session did not expire: If so, the user will be redirected to a page that

will inform him/her about it and will allow the user to log in again.

- The user has access to the page: If the session is valid, this method will check

the user session information to see if the user has access to the page.

This method will be called before submitting any information or clicking to a link to

verify the session didn’t expired. This method is also called in the constructor to check

the access before the page is rendered.

The class will also have two attributes and the corresponding getters and setters. It will

store the session and also the resourceBoundle variable that contents the current

language file and is used to get the messages to show to the user.

There exists a hierarchy in the SessionCheck class. There are two classes that extend

the SessionCheck class and redefine the checkSession() method to verify that the user

has access to the JSP page.

- AdminSessionCheck redefines the checkSession() method to verify that the

user is the administrator. Administration beans will extend this class.

- RegisteredUserSessionCheck redefines the method to verify that the user is a

registered user. Registered user backing beans will extend this class.

The managed beans that are for guest user will extend the SessionCheck class. This

hierarchy is shown in the figure below:



SessionChecksessionresourceBoundle

checkSession()

AdminSessionCheck

RegisteredUserSessionCheck

Admin View Registered User ViewUser View

view.backing.Del_users view.backing.Main view.backing.Add_article

In the diagram we included just one backing bean to keep it small. But all the beans

used in registered user pages will extend the RegisteredUserSessionCheck class.

Managed beans used by the administrator will extend AdminSessionCheck and

managed beans shared by guest and registered users will extend SessionCheck.

Remember, that the registered user actor extends the user actor.



3.5.2.3. Dynamic Behavior In this section we will show the dynamic behavior of the application by showing two

sequence diagrams of two of the critical use cases. Again, this sequence diagrams

refine the ones shown in phase two adding more detail. We will show the uses case

“Register” and “Add Article” as examples, the behavior of the other uses cases will be

very similar and will be omitted. In section 5, we will describe the algorithms used in the

application and their behavior; for that purpose activity/state diagrams will be used

instead of sequence diagrams.

3.5.2.3.1. Register User

Recall the sequence diagram for this use case from the architecture design:

: User : MainUI : MainUIController : RegisterUI : RegisterUIController : ModelFacade : UserControl user : AppUser

registerregister() showRegForm()

fill formsubmit()

validateFields()

[NO fields properly filled]showRegForm(String error)

correct form

-------------------------------------------------------------------[fields properly filled]

registerUser()registerUser()

<<create>>

persist(user)showResults(String results)



Next, we show the same functionality implemented in the J2EE platform as a Web

application with all implementation details.

: User : index.jsp

G S

: Faces Servlet

: Register Servlet : view.backing.Register : UI Components : UI Components : register.jsp : Register Form :

FacesContext.message : Session

Facade Impl

S

: AppUserSes...

E

user : AppUser

: javax.persistence.EntityManager

E

: Profile : Confirm Register : view.backing.Confirm_...

: UI Components

: confirm_register.jsp

register

regsiterregister

<<create><<instantiate>>

<<include>>

<<include>>

<<build>><<include>>

<<submit>>

fill form

<<action>>

validateInputs( )

Input Check == False

failure

register

add(message)

<<build>><<uses>>

<<include>>

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Input Check == True

correct form

<<create>>

register( )

ejbLookUp( )

<<create>>

<<create>>

persist(user )

createUser( )

createProfile( )

<<create>>

<<create>>

persist( )

register_results

confirm_register

<<create>>

<<instantiate>>

<<include>>

<<include>>

<<build>>

add()



In the figure the whole process is explained. The user click the link in the index page,

since no action is performed the backing bean is not use and the request is handled by

the front controller that redirect the request to the registration page. The Register

Servlet is called and it will be in charge of generating the view. To do this task, first

instantiates the managed bean of the register JSP page and this one will instantiate the

UI components (JSF/ADF).

Then the Servlet is ready to generate the view and create the dynamic web content.

The stereotype <<build>> represent the action performed by the Servlet when

generation the HTML code. The page will include a HTML form where the user will

introduce the data and click “submit”.

The action method of the managed bean will be called and it will check that all the

information is valid before calling the model. In case that the input is wrong it will create

a message using the message system provided by JSF and tell the Faces Servlet that

there was an error by returning the string “failure”. The Faces Context will reload the

page and the error message will be shown.

If the input is correct, the managed bean will gather all the information from the UI

components and call the model by instantiating the model façade and calling the

method register(). The model façade will perform the look-up of the

AppUserSessionBean and instantiate the Session Bean. Then, it will call the

registerUser() method that will create the AppUser Entity Bean and user the Entity

Manager to perform the persistence in the relational database.

The model façade will then create the user’s profile by using the same procedure. Take

the data that was gathered from the UI components and passed to the façade, call the

model and let the session bean perform the operation using the Entity Manager. Note

that in the previous diagram (architecture design) this was planned to be performed just

once and have just one entity AppUser. But in the database design the user’s profile

was separated from the entity user to increase the performance when implemented the

filtering algorithm.

Finally, the results are sent to the managed bean. The managed bean will create a

message to inform the user about the operation and return a string that will be used to

forward to the next page.



The request is handled by the Faces Servlet that will find the next page and call the

corresponding Servlet. The Servlet will instantiate the managed bean and UI

components and create the view. The message will be shown on the next page.

As we can see, the diagram got too big comparing to the platform independent one; but

this is due to the complex technology used. If you take a closer look to the problem

domain and forget about implementation details, the functionality is the same as in the

architecture design sequence diagram.

In the next sequence diagram we will try not to repeat the same process and omit

technology dependent details such page generation that are always performed the

same way. This way the diagram will be smaller.

3.5.2.3.2. Add Article

: view.backing.Add_article

: Registered User : browse_articles.jsp

G S

: Faces Servlet : Add Article : ModelConvert :

FacesContext.message : add_article.jsp

: Add Article Form

: Session Facade Impl

S

: ArticleSessionBeanEJB

E

: Article

E

: Fil ter :

javax.persistence.EntityManager : Confirm Add

Article : view.backing.Confirm_addArticle

: confirm_add_article.jsp

add articleadd article add article

<<create>>

<<build>><<include>>

fil l form

<<submit>>

<<action>>

validateInputs( ) In case of an error a error message is shown. Check Regitser sequence diagram for more info.Input Check == True

<<create>>

addArticle( )ejbLookUp( )

<<create>>

createArticle( )<<create>>

<<create>>

persist( article, fi lter)

i f (inputFi le != null)

<<instantiate>>

uploadFile( )

add(message)confirm_addArticle

confirm_addArticle<<create>>

<<build>>



In this case we have omitted some details such as the UI components generation or the

functionality that takes place when the user input is invalid. This is exactly the same than

the previous diagram.

The Registered User clicks on the link “add article”, the request is handled by the Faces

Servlet that redirects the user to the add_article.jsp page. The page generation logic takes

place, the managed bean and the UI components are created and rendered by the Servlet

that generates the dynamic content.

The user will fill the form and submit the information. The input will be validated by the

managed bean and in case of error a message will be shown to the user. Note that some

validations such input type or length is automatically perform by the JSF using validation

tags.

If the inputs are correct, the managed bean calls the method uploadFile() from the

ModelConvert class. As we mentioned before, this class implemented the transfer object

pattern but it is also used to execute the method that uploads the file to the web server. To

perform this operation the ADF input file component is used.

Then, the managed bean calls the model and creates the article and its corresponding

filter information. The result is sent back to the managed bean that will create a message

to inform the user about the result of the operation and then return a string that will be

used by the Faces Servlet to redirect the user to a new page.

The rest of the system functions follow the same pattern than this two sequence diagrams.

The behavior is described in the architecture design document. This document excludes

the tedious implementation details to make it easier to read. Understanding these last two

sequences it will be easy to understand the rest of the code.



3.6. Implementation Design In this section we will discuss some implementation issues that were not discussed in the

previous sections such as design patterns or the algorithms used.

3.6.1. Folder Structure

The figure below shows how the system is organized in folders:

As we know by now, the system has two modules: Model and ViewController.

In the model we have the source code in the “src” folder that contents the two packages

used in this module with their corresponding java classes. The model sub folder content

the diagrams used in this document. The JavaDoc is also included, where we describe all

the methods used in the model. Finally we have the compiled source code under

“classes”.



In the ViewController module we have the source code in the “src” folder where we have

the managed beans of the JSP pages. Under “classes” we have all compiled java files

including the managed beans and the Servlets from the JSP pages. In the “public_html”

folder we have the entire web content, this includes:

- JSP pages

- Java Script Files

- CSS Files

- Tag Libraries

- Images

- Configuration Files

- Properties Files (Language Files)

3.6.2. Model Layer

3.6.2.1. Design Patterns

In this section we will describe the design patterns used in the project. The intention is not

to give a completely description of the patterns, the idea is to show the patterns used and

why they were implemented. For more information check [11, 12, 19].

3.6.2.1.1. Architectural Patterns

Two architectural patterns are used in the application. We already talked about them.



Layers Pattern: This pattern represents the main architecture of the system.

Basically, it tells us that we need to divide the system in logical layers that must be

independent one of the others. This design pattern is essential in order to build

scalable and reusable application. Each layer will have a different function.

• The presentation layer is the part of the application where all the code

written for the UI resides. This layer represents the client tier in the 3-tier

architecture, if the client is standalone this layer will represent all the

classes used to create the interface. If the client is Web based this layer

represent the pages or classes use to create the web pages that the user

sees in the Web browser. In the case of the J2EE, the JSP pages are

commonly used to generate dynamic Web pages, and are the main

component in the presentation layer.

PRESENTATION

LOGIC

DATABASE



• The logic layer represent the business model and is in charge of implement

the main functions of the system. It fetch the information from the

presentation layer and process the information, if its necessary it will ask

the data layer to get some information. Here we will have the main classes

of our application. This layer corresponds to the business tier in the 3-layer

architecture; the middle server will have the code corresponding to this

layer.

• The data layer will have the code necessary to connect to the database

and create the objects used in the second layer. It represents the database

layer in the 3-tier architecture.

The main issue here is how the layers communicate with each other. The idea is

that one layer only communicate with the lower layer sending request, no

bidirectional communication takes place. The upper layer sends a request to the

lower layer and gets a response, but the upper layer doesn’t know how this

operation was done, it only knows the public interface. So, the communication

takes place only from the upper layers to the lower layers, is not allowed to send a

request from one lower layer to an upper layer. This approach provides a high level

of abstraction and encapsulation allowing the developers to build scalable and

reusable applications because we can change the data layer and the logic layer

won’t be affected as long as the public interfaces are kept the same. This approach

allows us to build reusable software been able to change different modules without

affecting the others. For example, we can change the database and the logic layer

will not be affected.



1. Model-View-Controller (MVC): This pattern tell us how the three layers

communicate with each other:

• The model handles application and business logic.

• The view handles presentation logic showing the data to the user.

• The controller accepts and interprets keyboard and mouse input.

This pattern is implemented by the Java Server Faces.

3.6.2.1.2. Design Patterns Several design patterns were used during the development of this application; we already

mentioned them and on this section we are going to summarize them. For more

information visit [19].

The Model Façade class implements the session façade and business delegate patterns

to help reusability and maintainability of the system by having one entry point to the model

that hides the technology used. It also implements the service locator pattern that is used

to find resources in the system; in this case the resources are the EJBs.

The Model Convert class implements the transfer object pattern to transform the list of

entity beans that are returned from the model to lists of SelectItem used by the JSF in the

view, adapting the object to the client.



Other pattern could have been used such the page-by-page iterator or the fast-lane

reader. The page-by-page iterator was not used because we don’t expect to have so large

amount of data. The fast lane reader is not necessary since EJB 3.0 solves the problems

of EJB 2.x that make reasonable use this pattern.

3.6.2.2. Algorithms

3.6.2.2.1. Search Algorithm The search algorithm is quite simple; it just takes all the items from the database and

compares their fields to the search string. If on of the field match the item is added to the

result and the other fields are not checked.

The search could be performed in the database but this option was not chosen for two

reasons:

We don’t want to overload the database since is executed in one server whereas

the EJBs are in different machines. So, we move the logic from the database to the

model to increase performance and take advantage of the distribute system.

When searching the database there are always problems with some symbols and

also it doesn’t differentiate upper case from lower case.

Note that the search can be used to find information that is not available when browsing

the items due to the filter algorithm. Usually, the user will not be interested in some themes

but if for any reason the user is looking for a particular item that doesn’t match his/her

profile, the search function can be used to find it.

The Access Control System will also check that a guest doesn’t receive private data using

the search function.



3.6.2.2.2. Filter Algorithm This is one of the key components of the system. One of the critical goals of the system

besides support many languages or follow rigorous design principles was to offer

personalized information. User will see what they are interested in seeing. Some attributes

will be use to filter information and show the user only a subset of the items.

Some changes were made in the implementation that makes the filtering algorithm less

restrictive. Basically, the user who publishes an item (event/article) will decide the target

users.

The filter attributes are:

- Country

- Courses

- Languages

- Home University

- Mayor

As a reminder the user has associated a profile and the events/articles a filer. Profile and

filter have the same attributes but the profile can have several languages and courses and

the filter only one. This means, that as an user I may want to receive information in several

languages but when I publish something it will be only in one language.

When a user registers in the application a profile is created and it may have:

- Zero or more languages

- Zero or more courses

- Zero or one country

- Zero or one mayor

- Zero or one Mayor

This is saved in the database and will be used when browsing events or articles to get

personalized information.



When the user publish and item a filter is created that may have:

- Zero or one language

- Zero or one course

- Zero or one country

- Zero or one mayor

- Zero or one Mayor

Check the Data Model document for more information.

The filter is lead by the items which means that the profile is not restrictive. When the user

publish an item it can leave the filtering information blank, in this case all the users will

receive the information no matter what is in the profile.

If filter information is used in the item, that information will be compare to the user profile.

For example, if we say that the article is in Spanish, when a user clicks on “browse

articles” the system will compare that article to the user profile. If the user has Spanish in

his/her profile the article will be shown, in any other case the article will not be shown. The

same behavior is followed by the other attributes.

So, if the item has one attribute null we don’t even compare to the profile to increase

performance. Because this will mean that the author doesn’t care about that attribute and

doesn’t want to filter using that particular attribute.

The filter information is only used for registered users. Guest can only see public items

and no filtering is done. The user should not fill the filter information if he/she set public

visibility making it available to everyone.



When the user click on browse items (events/articles) the algorithm is executed:

1. The system receives the method call with the user’s profile as parameter.

2. The system fetches the list of items from the database using the entity manager.

3. The System creates an empty result list.

4. For each Item:

4.1. If it is a event and is public the item is added to the list and the loop changes to the

next item and no more attributes are checked

4.2. If the author is the current user the item is added to the list and the loop changes

to the next item and no more attributes are checked. Note that, the user’s item will

have two links: edit and remove.

4.3. If not, a variable check is initialized to zero and for each filter attribute:

4.3.1. Compare profile attribute to filter attribute

4.3.1.1. If filter attribute null check++ (no comparison is performed)

4.3.1.2. If matches (ignoring case) check++

4.4. If check equals 5 (all attributes match to the profile or are null) then we add the

item to the result.



Next figure shows this process:

Get User Profile

Get Item List

Create Empty List

Select Item

Is User the Author?

Add To Result List

YES

Check = 0

NO

Select Attribute

Null?

Check ++

YES

Equals to Profile?

YES

NO

Check == 5?

More Attributes?

YES / NO

YES

NO

More Items?

YES

NO

Is Event? Is Public?YES

YESNO NO

YES

YES / NO



3.6.3. View Layer This section discusses some issues related to the view, especially the JSF. Note, that this

project focused more on the model and not so much on the view. The goal is to show how

to build an enterprise web application using the J2EE platform and not to how to design

web sites. The important aspect is the architecture and not so much the presentation.

However, the application was developed separating the view and the model, so a web

designer can take the JSP pages and change the layout without affecting the Java code.

But there are some aspects that are not so related to web design that are very important.

The most important one is the internationalization and input validation mechanisms that

the JSF provides.

3.6.3.1. Internationalization The application was built to support different languages taking full advantage of the JSF.

The languages are stored in the databases and the administrator can add them. To do

this, the administrator first needs to add the language to the list of supported languages in

the faces configuration file (faces-config.xml).

<locale-config>

<default-locale>en</default-locale>

<supported-locale>es</supported-locale>

</locale-config>

The locate-config command is used to select the supported languages. In this case we

have English as default and Spanish as one of the supported languages.

Once, we added the language we have to log in the application as administrator and add

the language to the database. And finally, we need to add the language file

(message_es.properties) to the /public_html/lib/classes directory.



The application behavior is described next:

1. The user enters the application URL in the browser.

2. The application checks the Web browser default language.

3. If supported the page is shown in that language.

4. If not supported the application looks the next supported language by the Web

browser.

5. If none of the Web browser languages is supported by the application the default

language (English) is shown.

Get Web Browser Supported Languages List

Get Language

Supported?

Show Page

More Languages?

NO

YES

Set Default Language

NO

Set LanguageYES



In the main page the user can manually change the language. This can be useful when a

user uses another computer that doesn’t have his/her native language.

3.6.3.2. Input Validation JSF validation features are used in the application. JSF provides a tag library called JSF

Core that provides tags to convert and validate inputs which are typical operations

performed in web applications. It also lets the developer create new validation tags.

We just used the standard libraries to check the length of the fields or the type of input. For

example, we use validation tags to check that the password is no less than 4 characters

long or than the phone number contents numbers and no letters. We also check that all

the required fields are filled before submitting the form.

Standard error messages are shown to the user in any of the supported languages.

Also, access to pages is controlled by implementing mechanisms to check if a particular

user has permission to access a given page.

3.6.3.3. JavaScript JavaScript is used to implement an encryption algorithm to send the password encrypted

throughout the network. A public encryption library is used.

JSF validation tags are used instead of JavaScript to be able to personalize the error

message supporting several languages.

3.6.3.4. CSS Cascade Sheets were used to change the style of the web page.



3.6.4. Tools The following tools were used to develop the application:

1. Rational Rose 2003: UML modeling and documentation.

2. Smart Draw 7: Diagrams for documentation.

3. JDeveloper 10g: Main IDE. Used for development (coding, testing, deployment)

and also to create class diagrams.

4. Microsoft Word 2003: Documentation.



4. Project Plan

4.1. Task Breakdown

4.1.1. Inception Phase

The inception phase will concentrate on the project’s overview and its requirements. This

phase will include the production of a Vision Document, a Project Plan, a Software Quality

Assurance Plan, and a simple prototype of the application. Each of the four works will be

approved by the committee before continuing with the project.

4.1.1.1. Vision Document

This document will include the overall project description and the critical requirements. It

includes its goals and purpose. Also it has graphical models that are used to describe the

system, and use cases to illustrate the main functionality.

4.1.1.2. Project Plan

This document will include a timeline for the project and an estimation of the cost for

completing the project. Cost estimates will be calculated using the COCOMO estimating

methodology. The process will include the following phases: Inception Phase, Elaboration

Phase, Production Phase, and the Transition Phase.

4.1.1.3. Software Quality Assurance Plan

This document will describe an outline of the documents required to ensure software

quality. This document will outline project reviews and the responsibilities of those

associated with the application validation.

4.1.1.4. Simple Prototype

A simple prototype will be developed to show at least some aspect of the software. This

way we can find the errors before implementing the actual project.



4.1.2. Elaboration Phase

The elaboration phase is focused on the design of the application. This phase will include

the production of an Architecture Design Plan, revisions to the Project Plan and the Vision

Document, a formal specification, Test Plan, and two architecture inspections.

4.1.2.1. Architecture Design Plan

The Architecture Design plan will include appropriate UML diagrams such as class

diagrams, use-case diagrams, and sequence diagrams necessary to describe the system.

4.1.2.2. Revisions of Project Plan and Vision Document

Appropriate changes suggested by the committee at the end of the first phase will be

made to the Project Plan and Vision Document.

4.1.2.3. Formal Specification

A formal requirements specification will be developed for this project, using the Alloy

Constraint Language.

4.1.2.4. Test Plan

In the test plan we will specify a complete testing procedure for the project. This will

include test suites and appropriate procedures for reporting and correcting failed test.

4.1.2.5. Architecture Inspections

Two architecture inspections will be performed by MSE students at Kansas State

University.



4.1.3. Production Phase

The production phase includes project implementation and testing.

4.1.3.1. Formal Specification

A formal requirements specification will be developed for this project, using the USE

Language.

4.1.3.2. Project Coding

Project coding will consist of all committee approved and designated tasks to be coded

and developed. Both unit testing and integration testing will be performed throughout

coding. Test cases will be developed according to the project requirements outlined in the

project’s Vision Document.

4.1.3.3. Project Documentation

All aspects of this project will be well documented. Probably the next items will be

provided:

- JavaDoc documentation to explain the source code

- Post test document with all results of the test plan. Including the solutions or

corrections to the case of test failure.

- User manual that will include description of project installation, software usage

requirements, and software usage.



4.2. Gantt Chart

In the next figure the Gantt diagram shows the initial planning of all the phases and its

different tasks.



4.3. Cost Estimate

COCOMO

The COCOMO model is a software estimation model developed by Barry Boehm. It will be

used to estimate project effort and time. The COCOMO model describes three different

types of applications: Embedded, Semi-Detached and Organic. Since, the KSU Student

Portal is a normal enterprise application with no special requirements it fits into the organic

model. The COCOMO model provides the following equations to calculate effort and time:

Effort = 3.2*EAF (Size)^1.05 Time (in months) = 2.5(Effort)^0.38

To calculate effort one needs to estimate the Size and EAF values. The Size is measured

in KLOC. The EAF value stands for effort adjustment factor and is the product of 15

adjustment factors. Each adjustment factor is classified as very low, low, normal, high, or

very high. The value of each adjustment factor lies within a range and the classification will

determine where on the range the value will falls.



The table below lists all the adjustment factors and their corresponding ranges.

IDENTIFIER EFFORT ADJUSTMENT FACTOR RANGE

RELY Required reliability 0.75 - 1.40

DATA Database size 0.94 – 1.16

CPLX Product complexity 0.70 – 1.65

TIME Execution time constraint 1.00 – 1.66

STOR Main storage constraint 1.00 – 1.56

VIRT Virtual machine volatility 0.87 – 1.30

TURN Computer turnaround time 0.87 – 1.15

ACAP Analyst capability 1.46 – 0.71

AEXP Applications experience 1.29 – 0.82

PCAP Programmer capability 1.42 – 0.70

VEXP Virtual machine experience 1.21 – 0.90

LEXP Language experience 1.14 – 0.95

MODP Use of modern practices 1.24 – 0.82

TOOL Use of software tools 1.24 – 0.83

SCED Required development schedule 1.23 – 1.10



According to the characteristics of my project I choose the following values:

RELY as normal and a value of 1.10

DATA as normal and a value of 1.05

CPLX as normal and a value of 1.4

TIME as normal and a value of 1.28

STOR as low and a value of 1.1

VIRT as low and a value of 0.95

TURN as low and a value of 0.9

ACAO as high and a value of 0.8

AEXP as low and a value of 0.9

PCAP as normal and a value of 1.1

VEXP as normal and a value of 1.0

LEXP as high and a value of 1.0

MODP as high and a value of 0.88

TOOL as high and a value of 0.9

SCED as high and a value of 1.16

Using the factors described above the EAF value will be 1.416. I estimated the size to be

3500 LOC based on the current prototype and similar examples. The effort evaluates to:

Effort = 3.2*(1.416*3.5)^1.05 = 17.1 staff months

The time can now be calculated as:

Time = 2.5*17.1^0.38 = 7.3 months

The 17.1 months for effort seems a little high for a MSE project, but this is due to the fact

that COCOMO is focus on big and “real” projects where the are more security and

reliability constrains plus there are more people involved. This project will only have one

developer and will not rely on any other applications to function, so I would guess that 8-9

staff months for Effort would be a more realistic value.



4.4. Architecture Elaboration Plan Completion Criteria

The following items must be completed before the second presentation.

4.4.1. Revision of Vision Document

Changes will be made in the original Vision document and will be compiled in the

Vision Document 2.0 as suggested by the committee.

4.4.2. Revision of Project Plan

Project Plan 1.0 will be revised and compiled into Project Plan 2.0. The time and cost

estimates will be revised using a bottom-up approach based on project progress. The

revisions will contain a complete listing of project requirements and contain changes

suggested by the committee members following presentation one.

4.4.3. Architecture Design

This is a critical phase in the project where the design of the application will take place.

UML diagrams will be used to describe the system architecture in the most accurate

way, documenting all the models.

4.4.4. Development of Prototype

Prototype 1.0 will be enhanced to Prototype 2.0. The prototype will demonstrate the

critical requirements (defined in the Vision document) to demonstrate they can be

implemented. It will include all the improvement suggested by the committee.

4.4.5. Test Plan

A test plan will document the tests that are to be performed to ensure the requirements

are meet.



4.4.6. Formal Technical Inspections

Two MSE students, Patrick Gallagher and Jacek Brydak, will provide input into the

testing of this project by completing a formal technical inspection. It will include a

function testing checklist so that the requirements outlined in the Vision Document may

be evaluated. The formal technical inspection list will be prepared and will be approved

by the major professor.

4.4.7. Formal Requirements Specification

At least one part of the project will be formally specified using a methodology such as

Alloy.



5. Software Quality Assurance Plan

5.1. Purpose

This document is intended to define a plan describing what measures will be taken

throughout the project lifecycle to achieve an acceptable level of quality in the final

product.

5.2. References

Vision Document

Project Plan

IEEE Guide for Software Quality Assurance Planning

IEEE Standard for Software Quality Assurance Planning

5.3. Management

5.3.1. Organization

Supervisory Committee

Dr. Torben Amtoft

Dr. Daniel Andresen

Dr. William J. Hankley

Major Professor

Dr. William J. Hankley

Developer

Javier Ramos Rodríguez



5.3.2. Formal Technical Inspectors

5.3.2.1. Responsibilities Supervisory committee The members of the supervisory committee will be responsible for attending all three

presentations given by the developer at the end of each project phase. Also, all

members will provide feedback and suggestions to the student after the presentations.

Major Professor The major professor will be responsible for meeting with the developer on a weekly

basis to evaluate progress and give suggestions.

Developer

The developer will be responsible for all project documentation and implementation

tasks as detailed in the project plan. He will be responsible for presenting his work to

the committee at the end of each phase. He will meet with the major professor on a

weekly basis for reporting progress.

Formal Technical Inspectors

The technical inspectors will review the project architecture artifacts and submit a

formal report.

5.3.2.2. Tasks

All tasks to be carried out throughout the project lifecycle are documented in the

Project Plan. The project plan includes a chart detailing the schedule of each task and

activity.



5.4. Documentation All required documentation for MSE students is defined at

http://www.cis.ksu.edu/~sdeloach/mse/portfolio.htm describing the complete software

portfolio to be built. The documentation will include a vision document, a project plan, a

software quality assurance plan, test plan, architecture design and a user manual. All

documentation will be reviewed and evaluated by the supervisory committee.

The software portfolio for the developer will be found at

http://www.cis.ksu.edu/~jramos/MSEProject.html

5.5. Standards, practices conventions and metrics Documentation standards: Wherever applicable IEEE standards will be used as a

guideline to prepare all documentation. Object oriented analysis and design methods

will be used.

Coding standards: Java naming conventions will be used throughout the project.

Javadoc will be used to generate API documentation.

Metrics: COCOMO will be used for effort estimation

5.6. Reviews and audits The supervisory committee will review and evaluate each document prepared by the

developer.

They will provide feedback and suggestions after each presentation. The committee

members will comment on the demonstrated prototypes providing suggestions and

improvements to the project. Two technical inspectors will review the architecture

artifacts and report their findings.

http://www.cis.ksu.edu/~sdeloach/mse/portfolio.htm




5.7. Test and problem reporting

A test report will consist of the test matrix detailing all tests that were conducted and

their outcome. Unresolved issues will be specifically documented and reported to the

major professor.

5.8. Tools, techniques and methodologies The following tools will be used for coding, testing, and documentation:

JDeveloper IDE – for development

Java JDK 1.5 – for coding

JSF and EJB – for implementation

Alloy – for formal specification

MS Word – for documentation

Microsoft Project – for project schedule

5.9. Media Control

The software tool will be made available on a CD for installation. A user manual soft

copy will also be available on the CD to aid with the installation process and use of the

software. Complete project documentation from the developer’s website

http://www.cis.ksu.edu/~jramos/MSEProject.html will also be made available on the

CD.




5.10. Deliverables Phase I:

Vision Document

Project Plan

Initial Prototype

Software Quality Assurance Plan

Phase II:

Vision Document

Project Plan

Formal Requirements Specification

Architecture Design

Test Plan

Technical Inspection Checklist

Executable Prototype

Phase III:

User Manual

Component Design

Source Code

Project Evaluation

Formal Technical Inspection Letters

Executable Project



6. Test Plan

6.1. Test plan identifier

KSUPORTALMSE-V2.0

6.2. Introduction The purpose of this document is to describe the plan for testing the main functionalities

of KSU Student Portal application. The document will also describe the activities

related to testing the software and the environment and tools that will be used to test

the software.

6.3. Test items

The critical Use Cases of the application software will be tested. The test will be

performed after the committee chair signs off the first version of the software. The

critical use cases will be the ones chosen to be tested since they reflect the main

functionalities of the system, it doesn’t mean that the other use cases are less

important but their functionality is very similar to the others and the developer will have

to implement the same way to assure the desired quality.

6.4. Features to be tested The next use cases will be tested:

1.1. Register in the application

1.2. Log in the Application

1.3. Delete User

1.4. Search Public Items

1.5. Browse Events

1.6. View Event

1.7. Create Event

1.8. Delete Event

1.9. Create Article

1.10. Edit Profile



1.11. Add Blog Entry

1.12. Change Password

1.13. Change Language

1.14. Check Visibility

Access control will be tested to check that an unknown user doesn’t access to private

information.

6.5. Approach

The tester will fill out the different forms in the application and analyze the system

outputs. The application will check that all the fields are properly filled and will perform

the desire operation.

Black Box testing will be the approach used by the tester. To help the tested the

developer will write equivalence classes that will be use to denote what values are

expected in the corresponding fields and what values should not be accepted. The

equivalence classes will be use by the tested to perform the black box testing. So, the

tester doesn’t have to know how the functions are implemented, He/She only cares

about the input and output of the different use cases.

For example in the Register use case the system should check that all the required

fields are filled, that the login doesn’t already exist and that the proper values are

introduced in the corresponding fields (i.e. numbers are introduced in the telephone

number field). If all the fields are correct a new user should be added to the application.

Unit test will be applied to the code to check the different methods and functions. Also,

we will check the class interfaces to make sure that the different modules are

integrated correctly.

6.6. Item pass/fail criteria The software must be able to pass the tests for all the critical uses cases described in

the Architecture Design document. Each feature will be considered to be passed if it

satisfies the corresponding requirement in the document and failed if any or none of the

behavioral expectations are met as described.



6.7. Suspension criteria and resumption requirements

6.7.1. Suspension criteria

If a test case fails, testing will be suspended for all dependent features. The failed

test case will be logged into a test log along with a description of the failure.

6.7.2. Resumption requirements Testing for the failed test case will resume after the bug has been identified and

resolved. Independent test cases will continue to be executed in parallel to bug

fixing.

6.8. Test deliverables

The following artifacts will be produced after the tests are conducted on the application:

• Test Plan

• Formal Inspection Checklist

• Assessment Evaluation

6.9. Environmental needs This section will outline the necessary and desired properties needed for the test

environment.

6.9.1. Physical Characteristics

The application should work fine in both Linux and Windows platforms and should

be Database Independent.



7. Formal Specification

7.1. Introduction The goal of this document is to formally specify the application in order to find possible

errors in early stages of development. The application of formal methods in the

development of the system will help to assure a good quality level in the final product

verifying that all possible system states are reached and the desirable behavior is

executed.

7.1.1. Alloy

The Alloy Constraint Language will be used in phase two to formal specify the overall

system without given much details about how is going to be implemented. Alloy is a

non-deterministic language giving the possibility to find unstable states that we may

forget about using a deterministic approach. Alloy only works with Sets and its

relations. First, we write the Alloy model and the tool will generate instances of it

checking all possible invariants.

We define the following Items:

Domains: Here we define the possible values that the sets can take.

Sets: Unordered collections of objects that take values from the domains.

Relations: Relationships between sets

Multiplicities: Constrains on the number of objects that participate in a given

relation.

Invariants: Constrains that the model should hold.

Assertions: Are useful to check if a specific invariant holds. If the Alloy Constraint

Analyzer finds a counterexample means that the invariant is incorrect.

Operations: Functions that the system can execute. We define pre, post and frame

conditions.



7.1.2. USE

USE will be used to formally check the UML diagrams. Concretely the class diagrams.

We will use the OCL language to specify constraints in the UML classes and its

relations.

USE uses a deterministic approach and it’s used in later stages of development

because we need to have the complete UML model and then check it with USE. So, in

this phase since we have little information about the system and the UML

documentation is not done, only a small part of the system will be checked using USE.

7.2. Alloy Model

7.2.1. Description We are going to model the main functionalities of the system and its relations.

We will model the User, Blog, Blog Entries, Messages, Events, Articles, Links, Profile

and other attributes.

The user will be the main item and we are going to model a couple of his/her

operations to check for possible unstable states.



7.2.2. Model model MSEProject {

domain { User, fixed Blog, BlogEntry, Profile,

Message, Link, Article, Event, Filter,

fixed Country, fixed Language, fixed Course }

state {

//1) Users can have only one Blog and a Blog correspons to exactly one

user

user_blog(~blog_user): static User! -> static Blog!

//2) A blog can have several entries and one entry belongs to one blog

blog_entries(~entry_blog): static Blog! -> BlogEntry

//3) A User will have associated a profile and a profile belong to one

user

user_profile (~profile_user): static User! -> Profile!

//4) A Article will have associated a filter and a filer belong to one

Article

article_filter (~filter_article): static Article! -> static Filter!

//5) A Event will have associated a filter and a filter belong to one

Event

event_filter (~filter_event): static Event! -> static Filter!

//6) A Filter will have associated one course and one course can

belong to many filters

filter_course(~course_filter): Filter! -> Course?

//7) A Filter will have associated one country and one country can




filter_country(~country_filter): Filter! -> Country?

//8) A Filter will have associated one language and one language can


filter_language(~language_filter): Filter! -> Language?

//9) A Profile will have several Courses associated and a Course can

be associated to many Profiles

profile_course(~course_profile): Profile! -> Course

//10) A Profile will have one Country associated and a Country can be

associated to many Profiles

profile_country(~country_profile): Profile -> Country!

//11) A Profile will have several Languages associated and a Language

can be associated to many Profiles

profile_language(~language_profile): Profile -> Language

//12) An User can send a message to many users and one message belongs

to one user

author_message(~message_author): User! -> Message

//13) An User can receive several messages and one message can be sent

to many users

message_to(~message_dest): Message! -> User

//14) An User can publish many events and one event is published by

one User

publish_event(~event_published): User! -> Event?

//15) An User can publish many articles and one article is published

by one User

publish_article(~article_published): User! -> Article?



//16) An User can publish many links and one link is published by one

User

publish_link(~link_published): User! -> Link?

}

inv message {

all u1:User, u2:User | u1.author_message.message_to=u2 -> u1 in

u2.message_dest.message_author

}

assert message_a {

all u1:User, u2:User | u1.author_message.message_to=u2 -> u1 in

u2.message_dest.message_author

}

inv realism {

some u : User | some (User - u)

some p : Profile | some (Profile - p)

}

op addBEntry(be:BlogEntry'!,b:Blog!){

be !in BlogEntry

BlogEntry'=BlogEntry+be

b.blog_entries'=b.blog_entries+be

Message'=Message

User'=User

Event'=Event

Article'=Article

Link'=Link

Profile'=Profile

Filter'=Filter

}



op sendMessage(m:Message'!,to:User!, from:User!){

m !in Message

Message'=Message+m

m.message_author'= m.message_author+from

m.message_to'= m.message_to+to

BlogEntry'=BlogEntry

User'=User

Event'=Event

Article'=Article

Link'=Link

Profile'=Profile

Filter'=Filter

}

op createEvent(e:Event'!, author:User!, f:Filter'!){

e !in Event

f !in Filter

Filter'=Filter+f

Event'=Event+e

e.event_filter' = f

e.event_published'= author

Message'=Message

User'=User

Profile'=Profile

}

}



7.3. Use Model

7.3.1. Description In the USE model we only check the user and his/her relations with the blog and the

messages. We’ll check also the relation between the user and the events.

7.3.2. Model

model MSEProject class User attributes login:String end class Profile attributes p_id:Integer end class Blog attributes b_id: Integer end class BlogEntry attributes be_id: Integer end class Message attributes m_id: Integer end class Event attributes e_id: Integer end class Filter attributes f_id: Integer end



association UserBlog between User[1] role blogUser Blog[1] role userBlog end association UserProfile between User[1] role profileUser Profile[1] role userProfile end association BlogEntry between Blog[1] role entryBlog BlogEntry[*] role blogEntry end association MessageAuthor between User[1] role writtenby Message[*] role writes end association MessageDest between Message[1] role message User[*] role dest end association PublishEvent between User[1] role eventPublished Event[*] role publishEvent end association EventFilter between Event[1] role filterEvent Filter[1] role eventFilter End



7.3.3. Class Diagram



7.3.4. Object Diagram



8. Formal Inspection Checklist (Design)

8.1. Introduction

In this document I will show an inspection checklist for the technical inspectors of my

MSE Project. The checklist will be used to document the items are going to be

inspected. The purpose of the technical inspection is to help the developer in checking

for correctness and consistency with the architectural design and formal specification

documents giving the appropriate feedback to achieve a high quality level in the

application.

8.2. Items to be Inspected

1. UML Diagrams

o Class Diagrams

o Sequence Diagrams

o Collaboration Diagrams

o Class descriptions

2. Formal Specification

o Alloy Model

o Use Model

Data Model

o E-R Diagram

o Tables

8.3. Formal Technical Inspectors

Patrick Gallagher

Jacek Brydak



8.4. Formal Technical Inspection Checklist

Inspection Item Pass/Fail/Partial Comments 1. The symbols used in the use

case diagrams conform to the UML standards

2. The symbols used in the class diagrams conform to the UML standards

3. The symbols used in the sequence diagrams conform to the UML standards

4. The symbols used in the collaboration diagrams conform to the UML standards

5. The class diagrams have a corresponding description provide in the architectural design document

6. The descriptions of all class diagrams are clear

7. The messages passed between objects in the sequence diagrams can be found in the corresponding class diagram as public methods

8. The main classes in the UML model are found in the Alloy model

9. The relationships and multiplicities in the Alloy model are correct and match the behavior described in the Architecture Design Document.

10. The Operations described in the Alloy Model match the behavior described in the Architecture Design Document.

11. The USE model behavior matches the Alloy model behavior and the description of the Architecture Design Document.

12. The Data Model suites the behavior described in the other documents (Alloy Model, USE Model and UML Model)

13. The relational schema corresponds to the ER diagram.



9. Formal Inspection Checklist (Implementation)

9.1. Introduction

In this document I will show an inspection checklist for the technical inspectors of my

MSE Project. The checklist will be used to document the items that are going to be

inspected. The purpose of the technical inspection is to help the developer in checking

for correctness and consistency of the system giving the appropriate feedback to

achieve a high quality level in the application.

9.2. Items to be Inspected

Black Box testing will be performed for each use case. The tester will introduce

unexpected inputs in the forms to check that the system responds correctly to input

errors. The tester should:

Check the input size ranges: Entering larger or smaller inputs than expected.

The system should check the bounds. For example, the username must be at

least 4 characters long.

Check input formats: Tester should check if the system detects errors when

entering inputs that differ from what is expected, for example, entering letters in

the telephone number.

Check null values: The application should check that all required fields are

filled.

Check Access Control: Only Registered Users should have access to private

information. Also, only the Administrator can have access to user management

pages.

Check Control Flow: All links should work properly and all pages should have

links to go back and navigate.

Check Visibility: Check that user, blog and news/event visibility holds.



1. Use Case Testing

o Register in the Application

o Log in the Application

o Delete User

o Search Public Items

o Browse Events

o View Event

o Create Event

o Delete Event

o Edit Profile

o Add Blog Entry

2. Security Testing

o Access to Admin Pages

o Access to Registered User Pages

o Session Check

3. Page Flow Testing

4. Visibility Testing

9.3. Formal Technical Inspectors

Patrick Gallagher

Jacek Brydak



9.4. Formal Technical Inspection Checklist The tester will have two set of test cases:

1. Fail: These Test Cases check if the system performs input checking and

detects wrong inputs in the forms. The result of the test case should be an error

message from the system. If, not the test failed.

2. Pass: In this case, correct inputs are introduced and the test will pass if the

desired function is performed.

Register in the Application

Fail:

Inspection Item Pass/Fail/Partial Comments 14. User leaves all the inputs

blank and clicks “submit”.

15. User introduces a username with less than 4 characters.

16. User introduces a password with less than 4 characters.

17. User enters a different password on “repeat password”.

18. User introduces a wrong e-mail address (i.e. without “@”).

19. User enters letters in the telephone field.

20. User tries to register with a login that already exists.

Pass:

Inspection Item Pass/Fail/Partial Comments

1. User only enters the required fields.

2. User enters all the fields without picture.

3. User enters all the fields.



Log in the Application

Fail:



2. User introduces a username with less than 4 characters.

3. User introduces a password with less than 4 characters.

4. User enters a wrong username

5. User enters a correct username and wrong password

6. User enters username but no password

Pass:


1. User only enters the required fields with the correct user name and password.

Delete User

Pass:

Inspection Item Pass/Fail/Partial Comments 1. Admin clicks on the username

to delete the user from system.

Search Public Items

Fail:

Inspection Item Pass/Fail/Partial Comments 1. User leaves the input blank

and clicks “submit”.

Pass:


1. User only enters a search string.



Browse Events

Pass:

Inspection Item Pass/Fail/Partial Comments 1. User clicks on “browse

news/events” from main menu. Only the items that match user profile should appear on the next page.

View Event

Pass:

Inspection Item Pass/Fail/Partial Comments 1. User clicks on “view event”

from menu.

Create Event

Fail:



2. The items created by the user should have two links: edit and remove

Pass:



2. User enters the required fields and the filtering information.



Delete Event

Pass:

Inspection Item Pass/Fail/Partial Comments 1. User clicks on the link to

delete the event from system.

Create Article Fail:


1. User leaves all the inputs blank and clicks “submit”.

Pass:



2. User enters the required fields and uploads a file.

3. User enters the required fields and the filtering information.



Edit Profile

Fail:

Inspection Item Pass/Fail/Partial Comments 1. User changes the username

for one with less than 4 characters.

2. User changes the password for one with less than 4 characters.

3. User enters a different password on “repeat password”.

4. User introduces a wrong e-mail address (i.e. without “@”).

5. User enters letters in the telephone field.

6. User changes the login with one that already exists.

Pass:


1. User leaves all the inputs blank and clicks “submit”.


3. User changes the picture. 4. User changes all the fields.

Add Blog Entry

Fail:



Pass:





Change Password

Fail:



2. User enters wrong current password.

3. User enters new passwords that don’t match.

4. User password is less than 4 characters long.

Pass:


1. User enters the required fields and the passwords match.

Change Language

Pass:

Inspection Item Pass/Fail/Partial Comments 1. Enter the main URL in your

browser. The application should detect your browser language and display the page in that language. If the language is not supported it will look the second language in your browser and so on. If the application doesn’t have any of the languages that your browser supports it will show the page in the default language (English).

2. User selects a new language and clicks on the button.



Access to Admin Pages

Fail:

Inspection Item Pass/Fail/Partial Comments 1. User logs in as guess and

tries to enter a admin URL (i.e. /add_language.jsp)

2. User logs in as a registered user and tries to enter a admin URL (i.e. /add_language.jsp)

Pass:


1. User logs into the system with administrator privileges and tries to enter a admin URL (i.e. /add_language.jsp)

Access to Registered User Pages

Fail:

Inspection Item Pass/Fail/Partial Comments 1. User logs in as guess and

tries to enter a registered user URL (i.e. /add_event.jsp)

Pass:


1. User logs in as registered user and tries to enter a registered user URL (i.e. /add_event.jsp)

2. User logs in as guess and browses the news/events and articles. Items with private visibility should not be shown.



Session Check

Fail:

Inspection Item Pass/Fail/Partial Comments 1. User logs in as registered

user and then logs out. Then tries to go back on the browser and make some changes.

2. User log in and doesn’t perform any action, after 7 minutes (3 min admin) tries to access the system. (Session expired)

Page Flow Check Pass:


1. User browses the application following the links without using the back and forward buttons of the browser. There will be always links to navigate throughout the application.

Visibility Check Pass:


1. User creates a new private event and then logs as guess. That event should not appear when clicking on “browse events” or when searching items.

2. User creates a new private blog entry and then logs as guess. That entry should not appear when viewing the user profile.

3. Set user visibility to private and the log as guess. User should not appear when browsing or searching users.



10. User Manual

10.1. Installation

10.1.1. Overview This project consists in a Web application that was built to run on any Operation

System or application server. It uses the JSF and EJB 3.0 standards. So, any

Web/Application server that implements these specifications can be used to run this

application.

This application is also database independent. So, any DBMS can be used to run this

application.

Since there is no client for this project, this document will give a general guideline on

how to install the application that can be useful independently on the tools used.

Deploy a web application is not an easy task. Knowledge of the application server and

database is required. There are many documents and manuals available for the

application servers. The goal of this document is not to be a tutorial of these tools.

Some of the applications servers that currently support the EJB 3.0 specification are:

- Oracle OC4J.

- JBoss 4.x

- Sun Application Server.

This project was tested using Oracle as DBMS and OC4J as application server.



10.1.2. Database The user needs to create the database schema using the DBMS. There is a script SQL

file in the scripts folder with the SQL code necessary to create the tables in a relational

database.

The database must support sequences that will be used for automatic ID generation.

The sequences are also included in the scripts folder:

- schema.sql: Database Schema.

- sequences.sql: Sequences.

The user will execute the schema file first and then the sequences. The SQL code is

written for Oracle databases, SQL is a standard but sometimes some DBMS differ from

others, especially with the sequences. In this case, the user should take a look at the

data model document and implement the schema in the corresponding database

making the appropriate changes in the SQL code.

10.1.3. Application After creating the tables in the database we need to deploy the application is the

application server. An application server includes:

- A JSP container that implements the JSP/Servlet API

- A EJB container that implements the EJB 3.0 Specification

- A Web Server

- JSF 1.2 API

First of all, we need to establish the database connection. Usually the application

servers have a data source configuration file that implements a connection pool. This

file should be configured including the database username and password.

Once the connection is configured, the application must be deployed inside the

application server. Check the application server manual for more information.



10.2. Operation

10.2.1. Overview The system uses a Web browser to interact with the user. We assume that users know

how to use the web browsers and how to navigate on the Internet (use menus, buttons,

checkboxes…)

The interface was built to make the iteration with the user very easy. The operation will

be very straight forward even for amateur users. If some fields seem to be unclear

there will be text that explains the user the goal of the particular field.

This section will explain the basic usage of the interface focus on the parts that may be

not so clear such as registration of the filter information.



10.2.2. Index Page

The user can register in the application by entering the user name and password and

clicking “submit”. At any time, he/she can change the language using the language

menu selecting another language and clicking “change”.

There are two links in the page, one to enter as guess to view only public information

(“Guess”) and another link “Register” to sign in the application.



10.2.3. Registration Page

In this page there are several fields that may be filled by the user. Only the ones that

are in bold and marked with asterisk are mandatory. The user can select a state and a

country using the menus or live it black by leaving the “select…” tag. The user can

select one or more languages and course. To use the multiple selection list the user

must press control and select the courses that he/she is taking. The user can deselect

the courses also pressing control.



10.2.4. Main Page 10.2.4.1. Guess User

The functionalities available for the guess user will be shown in the page using web

links. The guess user can only see the public information.

10.2.4.2. Registered User

The registered user will have more features than the guess user such as edit his/her

profile, manage the blog and manage news, events or articles. He/she will have access

to private information.



10.2.5. Edit Profile

The edit profile page is just like the registration page but with the current information in

the corresponding fields. The picture will be also shown. The user will make the

appropriate changes and click “submit”. The user can select/deselect courses pressing

control and the clicking on the menu.



10.2.6. Change Password

The user must enter the current password and the new one. To confirm that the user

enters the right password he/she has to rewrite it.

10.2.7. Browse Items

When clicking on “news/events” or “articles” the system will gather the information and

show it to the user in a table. In the case of a registered user the filter algorithm will be

executed to get personalized information.

The items created by the user will have two links to edit and remove the item.

There will be a link to add the item.



10.2.8. Add Item

In this page the item form is displayed. The user has to enter the title and choose the

visibility. In the case of private items, the filter information may be introduced to choose

which users should see that information. For example if a language is selected only

users that have that language in their profile will see the item. If leaved blank all users

will see the article independently of the language selected in the profile. The same

method is used in the other fields.



10.2.9. Edit Item

The form will be displayed with the fields properly filled with the current information.

The user may change any fields and submit the information by clicking “submit”.

10.2.10. Search Information

The user will enter the search string and the system will perform the search. The

results will be displayed in a table.



11. Project Evaluation

11.1. Introduction In this document I will summarize my experiences while developing the KSU Student

Portal Web Application. Since this project used many new technologies and tool many

problems were encountered and not so much documentation was available to solve it.

Many decisions had to be made to be able to finish this application.

I will explain my option about the development process that I choose the technologies

and tools, the schedule and the effort. Then, I will explicate the main problems

encountered during the development and the future work.

11.2. Process

11.2.1. Introduction The underlying process used to develop this project was the Rational Unified Process

(RUP). The RUP is an iterative software development process created by the Rational

Software Corporation. Also, the RUP is not a single concrete prescriptive process, but

rather an adaptable process framework.

The KSU Student Portal used a version of the RUP; some changes were made in the

process due to different reasons. First of all, the process was not real iterative like

many of the software process available today. It follows the classic waterfall model. It

uses rigorous methods to create complex models to correctly specify the application to

save time and avoid risk in the last phase of development.

It does have some iteration, and some tasks were performed before some previous

activity was done. It also included many other techniques used in modern approach

such as prototypes or been architecture first approach.

The project was done in three different phases that provided different artifacts. UML

was used to model the system. One key factor of this project is that it used a model-driven architecture. The process was driven by the models created using UML. As

mentioned in the documentation, in each phase the UML were changing adding more

details as the project advanced.



In the requirements phase the idea was to create a use case model to capture the

requirements of the system, a prototype was also build to help this task. In phase 2, the

idea was to create the main architecture, so an extended use case model was built

including all the system behavior. At his phase, the platform was still yet to decide, the

objective was to create a detailed model without adding any implementation detail and

focusing only on the problem domain. This way, I created a platform independent

model that can be implemented in any existing platform without much effort.

Next, I explain what was done in each phase:

1. Phase 1: Requirements

a. Requirements Analysis

b. Project Description

c. Prototype

d. Use Case Diagram

e. Use Case Specification

f. Initial E-R Diagram

g. Initial Project Plan

h. SQA Plan

2. Phase 2: Architecture

a. Use Case Diagram Revision

b. Sequence & Collaboration Diagrams

c. Class Diagram

d. E-R Revision

e. UML Data Model

f. Relational Schema

g. UML Design Revision

h. Formal Specification

i. Alloy Model

ii. User Model

i. Test Plan

j. Formal Inspection Checklist



3. Phase 3: Implementation

a. Implement Relational Schema in Database

b. Create Entity Beans From Tables

c. Implement Relations Between the Entity Beans

d. Write initial EJB-QL Queries

e. Create Session Beans

f. Create Model Facade

g. Publish Methods

h. Test Methods

i. Create JSP pages and backing beans

j. Create additional classes

k. Improve the view

l. Create Test Cases

m. Fix Bugs.

n. User Manual

o. Component Design

p. Test Plan 2.0

q. Formal Inspection Checklist 2.0

r. References

11.2.2. Evaluation

The waterfall model was very useful to learn the basics of software development, it is

clearer than the most modern approaches and, in my opinion, a student should start

learning this process before going into more modern approaches. But I also faced the

problems of this approach. I found some requirements in the implementation phase

that I couldn’t find earlier in the process and I had to go back to make the appropriate

changes.



Also, when implementing the system I decided to implement most of the model before

implementing the view. I took this decision because I wasn’t sure what technology use

to create the view. I was doubting between JSF, Struts or Spring. The problem is that I

implemented and publish in the model façade many methods that ended up not been

used. Sometimes the problem was that the method parameters were not correct.

Further some, functionalities such the messaging system were implemented in the

model but not in the view due to time restrictions. This decision was positive because it

allow me to start implementing without knowing about the view, achieving a completely

separation between the model and the view. In case that the technology to generate

the view is known before starting the implementation, I would suggest create first the

entity beans from tables and then, instead of start creating the session beans, begin

creating the view and create the session beans as needed.

The approach that I used can be good choice when you have different team members

working on the model and on the view. The server side developers working on the

model can publish the methods in the façade that the members that work on the view

request. My problem was that I didn’t have any client in the view so I had to “guest” the

methods needed and this caused the creating of methods that were not used,

increasing the effort and LOC. Once, the implementation was done these methods

were removed except for the messaging system that were kept to be able to add the

functionality later on.

The model driven approach, in my opinion, was very useful. It has many advantages. It

proves that we can reuse models saving a lot of time and money.

Also, having several layers of abstractions helps clients and developers to understand

the system.

The use case model specifies the system explaining “what” the system must do without

specifying how it should do it. These requirements specification is very useful in the

early stages of development to set the requirements. In phase 2, we included the

behavior (“how”) of the system and we introduced a platform independent model that

can be implemented using any technology. This approach can be very useful to directly

implement prototypes to test different architectures and technologies. It also helps to

understand the problem domain without including implementation details that is useful

for developers and customers.



The last phase includes an implementation dependent specification where the

complete system behavior is explained. This model is helpful for developers, in case

that the software is delivered to other developers, this model will be used to understand

the technology behavior. The only drawback is that it requires more documentation but

the benefits are well worth it, especially for a long term use.

Another issue is that formal specification was not very useful for this project. The

application is quite standard in the requirements. The key of this project sis the

process, development and technology used and not so much “what” I’m building. This

project could be any other web application. The goal was develop a web application

using the RUP and the J2EE platform to test new technologies such EJB 3.0 and JSF.

So, since I proposed the requirements and they were really standard, formal

specification didn’t provide much information. Formal specification is quite useful in

many other context were the requirements are more difficult to get and there are more

relations between entities.

Building the prototype was useful to help get the requirements and to test the

technology. JSF uses a new approach and without the prototype the implementation

would have taken too much time. Also, it helped to find more requirements and face

problems before the final implementation. Ironically, the message system was

implemented in the prototype and not in the final product.

The prototype helped to realize that the original message system design was incorrect

and the data model needed to change. It also showed that the implementation was not

too easy. Since it was not a critical use case I decided not to implement it.

Finally, not having a client it was a drawback since I had to figure out the requirements

and I missed some use case such change password or delete language/course that

were added late in the process.



11.3. Technologies This project was implemented using really immature technologies. One of the goals of

the project was to test these technologies. In this section I’ll give my opinion about

these technologies.

11.3.1. Model To implement the model I used Java 5 as programming language and EJB 3.0 as the

main technology of the J2EE platform.

I’m very happy with the new Java 5 language. I tried to use the new features as much

as possible to increase performance and reduce the LOC. Java annotations help to

improve maintainability by adding Meta data to the java code that can be interpreted

really quickly by the compiler. This way the Meta data related to a class in included

within the class and not in a separated file like it used to be. Annotations are used in

the EJB 3.0 often times, for example, the OR Mapping information is included within

the entity bean and is interpreted by the entity manager, this is faster and easier to

maintain than having a separate XML file like other OR Mapping tools such Hibernate

use.

I also used generic list and collections to pass data between modules this way we keep

the representation independent. I pass generic list between modules that can be

reused very easily. The model will fetch the objects from the relational database using

OR Mapping and save the result in a generic list that is returned to the view. Many

components in the view such data tables support generic list and the binding is done

automatically from the list to a table. In the cases where generic lists are not supported

by the UI components a transformation is done to adapt the list to the client (transfer

object pattern). Enhanced loops that support generic types are also used by the

algorithms to take full advantage of this new language. For more information check

[16].

I have nothing to complain about the EJB 3.0 technology. People that worked with EJB

2.x will find this specification a lot easier to use and with several new interested

features. The key feature besides simplifying EJB 2.x is the OR Mapping approach that

allows the developer to work in terms of objects simulating a virtual OO database.



The only problem was the immaturity; at the time I started the project the specification

was still a draft and there was only one early implementation developed by Oracle.

There wasn’t that much information or documentation, and the only reliable document

to look for help was the specification itself. But this situation also helped me to realize

that the best place to look for information are the professional documentation such as

specifications and JavaDocs instead of internet tutorials that often times are incorrect.

Since the Oracle implementation of the specification was too immature I had to face

several problems. The main one was that the lazy fetching did not work properly and I

had to implement it myself by calling the model to fetch the lazy collections. The EJB

container should take care of the lazy fetching but it didn’t. JDeveloper provides a

function that automatically creates the CMP Beans from the relational tables adding the

corresponding annotations. It also checks the database relations and set the attributes

in the object to maintain the database relations. For example, the blog has a collection

of entries (0 or more), this is reflected in the OO world by having an object Blog that

has a generic collection on entries as an attributes. By default, the entity manager

performs lazy fetching on collections to avoid getting so much data with the object.

With single objects it performs eager fetching by default. When I created the entity

beans from tables and I had to make several changes. Sometimes I was interested in

eager fetching and other times on lazy fetching. For example, when getting the user

information I get also the blog information (eager fetching) since the blog contains only

one attribute that is very coupled to the user. But I don’t get the blog entries, so when

getting the user information the attribute blog will have the corresponding value, but in

the blog the attribute entries (a list) will be null.

In theory, when referencing the list the entity manager will automatically fetch the data

and return the corresponding collection. The problem is that this is only true in the

persistence context inside the EJB container, once we leave this module this feature

doesn’t work. In this project I implemented the layers pattern to separate the view from

the model, acting the view as a client for the model. Therefore, the view is not in the

EJB container. It wouldn’t make sense to have it in the same context. So, the lazy

fetching doesn’t work outside the container, and in my opinion this is not very useful

since most of the times we will have clients requesting data to the session beans and

using it outside the persistence context. It took me a while to realize about this problem

and found out that the null pointer exceptions were not my fault. To solve I had to

implement methods to get the collections from the model when the view needed them.



Another problem that I faced was updating and deleting objects. I had to set the

persistence manager configuration to configure the deletion of items. For example,

when deleting an event I also delete the filter but when deleting the filter I don’t delete

the country, state, course or language. All this configuration parameters, including the

fetch type, are done with Java 5 annotations and are interpreted by the persistence

manager; check the entity beans source code to see this configuration.

Finally, I had also problems with the EJB-QL language, the problem is that different

implementations differ in some aspects from other ones just like happen with standard

SQL. Some string functions were not supported by Oracle implementation but this

didn’t suppose a big problem.



11.3.2. View The main technology used to implement the view was the Java Server Faces (JSF)

along with JSP. Just like EJB 3.0, this technology is really immature and it was too

risky to use it in the project.

A prototype was built to test these new technologies. Building it I found many troubles

using the JSF that made wait until the last moment to decide which technology use for

the view. This is why I delayed implemented the view and I did most of the model

before starting the view.

After looking to many tutorials on the internet and I realized that the problem was that

JSF were too complex to start using them from scratch, so I decided to read the

specification to clearly understand the technology. This way, when I implemented the

real project I didn’t have much trouble. It was really easy to validate inputs or use

internationalization using this technology. Functions that were getting too complex in

the prototype ended up been easier once I understood the technology.

This doesn’t mean that JSF is perfect. Some developers will complain about some

decisions made in the specification. Some UI components such data tables work with

generic types which is really good because it helps to reuse the items. But other

components use their own types such the menus, so I had to implement the transfer

object pattern to adapt the lists to the view.

Using backing beans is very useful to add logic to the view without affecting the JSP

pages. Although, we should let the model perform the logic in some cases is necessary

to perform operations in the view. For example, when editing information we show the

current value in the menu and then the rest of the list; we ask the model which is the

current value and to get the rest of values. But the view is in charge to check the list

and remove the current value from the view to avoid that value appear twice in the list.

The approach that I use is overriding the set method of the component in the bean and

set the proper value, and then the view will be affected.



11.4. Tools The application was built using standard libraries been JDeveloper as the main IDE. In

general terms I’m really happy with this tool. IDEs have improved considerably in the

last years. My first project was done using just a standard text editor and I had to code

everything by hand. On my second project I used Eclipse as a main IDE; the

productivity increased considerably comparing to my first project. The second project

was larger but it took me the same development time to implement it.

JDeveloper adds several new features comparing to the Eclipse version I was using in

2004. JDeveloper allowed me to graphically manage the configuration files instead of

doing it by hand. It also configures the application server and takes care of the

deployment.

It generates lots of code such creating the entity beans from tables or creating the

backing beans. The nicer feature was developing a web application graphically

dragging & dropping the UI components into the JSP pages and having JDeveloper

taking care of everything.

I wouldn’t recommend JSF without using a graphic interface since it will take a long

time to develop the view. At the moment I started implementing the project JDeveloper

was the only IDE that supported this feature.

The goal of this paper is not to show all the JDeveloper features. For more information

check [2].

The main problem with JDeveloper was that it has some bugs since is still an early

version. It crashed many times during the development and I had to reinstall it many

times. It also consumes many resources (around 300MB of RAM) and some times it

gets too slow. When the number of web pages got too big the page flow editor crashed

and I had to configure JSF manually.

Summarizing, I very glad with JDeveloper. I think is the best IDE available right now,

but at this moment I wouldn’t recommend using it since is not reliable yet.



11.5. Schedule The project started November 2nd 2005 and finished August 11th 2006. It took around

10 months to develop the application. The initial plan is shown in the next figure:

We can see in the Gantt chart my initial planning. Phase 1 was supposed to be the key

phase of development where I was supposed to define all the requirements. This

phase was indeed really important and it took me a lot of effort. It is really hard to start

a project from scratch and be the only one that put the requirements. Actually, this

phase got delayed around 10 days. We can also see how idealistic this plan was. It

assumed that the requirements were going to be correct and the architecture (phase 2)

and implementation (phase 3) were going to be trivial.

A correction of this initial planning is shown below:



This plan is more realistic. The project in this case was planned to end in the middle-

end of July. Basically, I realized that using new technologies and tools was too risky

and implementation was going to be harder. I also don’t have enough experience to

develop software correctly. So, the implementation time almost doubled. It actually took

a little bit longer because of the usual final adjustments.

Summarizing, the first plan was too unrealistic because I didn’t take into account the

fact of suing new technologies and tools. But the planning shows that if you take

enough time analyzing the requirements you can avoid many errors in the other

phases. You can see how it didn’t take me that long to develop the architecture design

from the requirements.

The implementation phase would have been easier if I had more experience and if I

had used other technologies. For example, if I had used Struts instead of JSF it would

have taken less time since I already know that technology. But one of the goals of this

project was to test these new technologies.



11.6. Project Metrics I used the open source program SourceMonitor to get the software metric of this

project. In the next table I summarized the results:

Model View Backing View JSP Total View Total Java TOTAL

LOC 5,681 9,268 1,517 10,785 14,949 16,466

Files 40 47 43 90 87 130

Statements 2,545 4,970 30 5,000 7,515 7,545

Check the appendix for the whole results explanation.

The model is composed of 40 Java classes that correspond to the model façade and

the EJBs. There are 5,681 LOC in this module.

The view.backing package contents the backing beans and the supported classes such

ModelConvert; all of them are java classes. There are 43 backing beans (same number

than JSP pages) and 4 standard Java classes (ModelConvert and the three

SessionCheck classes). There are 9,268 LOC in this package. This large amount of

LOC where mostly automated generated by JDeveloper, and they are mostly the UI

components and their corresponding getters and setters. I just added the necessary

logic to the getters/setters and added few other methods to each bean.

The View JSP column shows the JSP pages. It doesn’t count the configuration files or

libraries. The program shows that it has 30 statements but actually it doesn’t have any,

JSP pages just use tags, all the logic is in the backing beans.

The Total View column represents the JSP pages plus the backing beans together.

The Total Java column represents the backing beans plus the model, which are all the

java classes. Finally, the Total column includes all the LOC including the Java classes

and the JSP pages of the whole project.



11.7. Problems Encountered In this section I’ll summarize the problems encountered during the development of the

KSU Student Portal that were explained in the previous sections:

1. Phase 1: Requirements

a. Several difficulties building prototype. Especially with the JSF.

b. Difficulties setting the requirements. Some of them were missing and

discovered during implementation.

c. Use case model was changed many times due to the problems with the

requirements.

2. Phase 2: Architecture

a. Use case model was wrong and had to be changed.

b. Building the sequence diagram became a tedious job.

c. Initial data model was wrong. I had to make several changes to get the

final design. The data relations were not trivial and the creation of the

relational schema was a difficult task.

3. Phase 3: Implementation

a. Problems with the EJB configuration, especially setting the relations and

its types (fetch mode, cascade type…).

b. Filter algorithm.

c. Controlling the session. I had to create the structure explaining in the

component design to solve this problem.

d. JDeveloper bugs.



11.8. Future Work There are several improvements that can be performed in the application that, due to

time restrictions, they were not implemented. First of all, a nice feature will be show the

results of lists only 10 or 20 at a time letting the user choose how many result he/she

wants per page. To perform these ADF table UI components could be used along with

the implementation of the page by page iterator pattern.

Another feature that will be easy to implement is the improvement of the password

functionalities. It will be good if the system only lets the user try the password 3 or 5

times to avoid hackers use tools to get the user’s password. Also, a security question

should be asked in the user’s profile that will be used to get the password in case the

user forgets it.

Of course, implementing the messaging system will be next feature. Also, more

features can be easily added to the system since it is lousy coupled. For example some

attributes could be added to some entities such adding a title to the user blog (not only

the entry) or adding a comment to a link. These changes will be really easy to perform.

The design could be improved a little bit. I could have taken more advantage of an

Object Oriented approach and create more hierarchies to reuse code. We also have

the trade-off between code reuse and complexity. For example, we could have a

general entity class with the attribute ID that can be used to find object by ID

independently is those are events or articles. This will create a more complex

architecture and since I don’t perform many searches by ID’s I decided not to use this

architecture.

We could also improve the security by adding a stronger encryption algorithm on the

server side

Finally, the view can be improved by a Web designer. Flash elements can be added

along with more images. AJAX can be used in some occasions such forms or to reload

only parts of the Web page.



11.9. Conclusions

In my opinion, I think I’ve learned more than I expected doing this project. I applied a

whole software process and I tested new technologies that made me put a lot effort to

get the final results.

It is obvious, that the final product is not perfect; although it works fine I would like to

achieve a “perfect” design that has all quality attributes. But looking at the final project I

realized about all my mistakes and I’m sure my next design will be better and I will

continue improving until the day that hopefully I will become a software architect which

is my final goal. I think experience is the key to become a successful developer, I know

my first design will have flaws but I hope I have time to analyze them and learn from

them. I guess is very common that due to time restrictions the design will not be as

expected since clients just want the application “working”. But I hope I don’t commit the

mistake of leaving the application as “it is” and have the same mistakes again.

The next step is to enter to work in a company where I can learn the real business

processes. I still have many things to learn that I will only learn working in a real project

with more experienced workers. I’m eager to learn everything that takes to become a

good developer and hopefully one day start my own business.



12. References

1. UML™ Resource Page , www.uml.org

2. Oracle JDeveloper 10g,

http://www.oracle.com/technology/products/jdev/index.html

3. Unified Modeling Language (UML), version 2.0 Specification,

http://www.omg.org/technology/documents/formal/uml.htm

4. JSR-000220 Enterprise JavaBeans 3.0 Specification (Final Release),

http://jcp.org/aboutJava/communityprocess/final/jsr220/index.html

5. JSR-000127 JavaServer™ Faces 1.2 Specification (Final Release),

http://jcp.org/aboutJava/communityprocess/final/jsr127/

6. The J2EE 1.4 Tutorial, Sun Microsystems,

http://java.sun.com/j2ee/1.4/docs/tutorial/doc/

7. Wikipedia, the free dictionary.

http://www.wikipedia.com

8. Deepti Gupta, “MSE Project Portfolio: AgentToolIII (Static)”,

http://mse.cis.ksu.edu/deepti/

9. Craig Larman. “Applying UML and Patterns - An Introduction to Object-Oriented

Analysis and Design and the Unified Process”. Prentice Hall PTR; 2 edition

(July 13, 2001)

10. Philippe Kruchten. “The Rational Unified Process: An Introduction (2nd

Edition)”. Addison-Wesley Professional, March 14, 2000.

11. Deepak Alur, John Crupi, Dan Malks. “Core J2EE Patterns, Best Practices and

Design Strategies”. 2003.

12. Floyd Marinescu, “EJB Design Patterns”. John Wiley and Sons, 2002.

http://www.uml.org/

http://www.oracle.com/technology/products/jdev/index.html

http://www.omg.org/technology/documents/formal/uml.htm

http://jcp.org/aboutJava/communityprocess/final/jsr220/index.html

http://jcp.org/aboutJava/communityprocess/final/jsr127/

http://java.sun.com/j2ee/1.4/docs/tutorial/doc/

http://www.wikipedia.com/

http://mse.cis.ksu.edu/deepti/



13. Hans Bergsten. “Java Server Faces”. O'Reilly, 2004.

14. Javier Ramos Rodríguez. “J2EE Internet Store: An Example of Building an

Enterprise Web Application”. Bachelor’s Thesis, Information Technology. May

2005.

http://www.cis.ksu.edu/~jramos/DIPLOMA WORK.pdf

15. Anil Sharma, “EJB 3.0 in a nutshell”, 2004

www.javaworld.com/javaworld/jw-08-2004/jw-0809-ejb.html

16. Calvin Austin, “J2SE 5.0 in a Nutshell”, May 2004

http://java.sun.com/developer/technicalArticles/releases/j2se15/

17. Budi Kurniawan, “Introducing JavaServer Faces” July 2003

http://www.onjava.com/pub/a/onjava/2003/07/30/jsf_intro.html

18. W3 Org, “Cascading Style Sheets, level 2 CSS2 Specification”, 1998

http://www.w3.org/TR/REC-CSS2/Overview.html

19. Sun Microsystems BluePrints, “Core J2EE Patterns”

http://java.sun.com/blueprints/corej2eepatterns/Patterns/

http://www.cis.ksu.edu/~jramos/DIPLOMA WORK.pdf

http://www.javaworld.com/javaworld/jw-08-2004/jw-0809-ejb.html

http://java.sun.com/developer/technicalArticles/releases/j2se15/

http://www.onjava.com/pub/a/onjava/2003/07/30/jsf_intro.html

http://www.w3.org/TR/REC-CSS2/Overview.html

http://java.sun.com/blueprints/corej2eepatterns/Patterns/

Documents

Master of Software Engineering Portfoliopeople.cis.ksu.edu/~jramos/MSEPortfolio.pdfDesign Patterns _____111 3.6.2.1.1. Architectural Patterns _____111 3.6.2.1.2. Design Patterns _____114

Master of Software Engineering Portfoliopeople.cis.ksu.edu/~jramos/MSEPortfolio.pdfDesign Patterns ___111 3.6.2.1.1. Architectural Patterns _111 3.6.2.1.2. Design Patterns ___114