master of software engineering portfoliopeople.cis.ksu.edu/~jramos/mseportfolio.pdfdesign patterns...
TRANSCRIPT
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:
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 2
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
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 3
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 4
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 5
1.3.1.2. E-R Diagram
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 6
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 7
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
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 8
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
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 9
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 10
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
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 11
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 12
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
(from Use Case View)
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 13
1.3.2.4. Administrator
Remove User
Remove Language
Remove Course
Get Users
<<extend>>
Add Language
Add Course
Get Languages
Get Courses
Administrator
(from Use Case View)
<<extend>>
<<extend>>
The administrator can get the users and delete them. Also, he/she can add and remove
languages and courses.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 14
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
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 15
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
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 16
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.
Secondary Scenario Exceptional Scenario
Function View a public event Non functional requirements
Execution Frequency Medium Annotations
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 17
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
Execution Frequency Medium Annotations
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 18
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.
Secondary Scenario Exceptional Scenario
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
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 19
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
(from Use Case View)
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 20
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.
Secondary Scenario Exceptional Scenario
There will be a possibility to browse user by different fields. Or to browse the user created events.
Function Browse events. Non functional requirements
Execution Frequency High Annotations
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 21
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
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.
Secondary Scenario Exceptional Scenario
Function View a public event Non functional requirements
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
Secondary Scenario Exceptional Scenario
If there’s an error while deleting the event the user will be notified
Function Delete event Non functional requirements
Execution Frequency Medium Annotations
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 22
1.3.3.3.2. Manage Blog
Add Entry
Delete Entry
Modify Entry
Registered User
(from Use Case View)
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 23
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.
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
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 24
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 25
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 26
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)
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 27
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()
13: showResults(String results)
11: <<create>>
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 28
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
Execution Frequency High Annotations
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 29
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]
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 30
Collaboration Diagram
: 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>>
10: showResults(String results)
11: showResults(String results)
12: checkResults(String results)
13: login fail
14: show( )
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 31
Scenario 2
Sequence Diagram
: User : MainUI : MainUIController : WelcomeUI
showLoginForm( )
click guessshowWelcome( )
show( )
Collaboration Diagram
: MainUIController
: User : MainUI
: WelcomeUI
1: showLoginForm( )
2: click guess
3: showWelcome( )
4: show( )
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 32
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
Execution Frequency High Annotations
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 )
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 33
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.
Collaboration Diagram
: 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)
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 34
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
Secondary Scenario Exceptional Scenario
If there’s an error while deleting the user, the administrator will be notified
Function Delete event Non functional requirements
Execution Frequency Medium Annotations
Sequence Diagram
: Administrator : UserListUI : UserListUIController : ModelFacade : UserControl : AppUser
delete user
deleteUser( )deleteUser(login )
deleteUser( login )<<remove>>
showResults( )showResults( )
showResults( )
showConfirmation( )confirm
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 35
Collaboration Diagram
: 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( )
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 36
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
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
There will be a possibility to browse user by name, country, major…
Function Browse registered users. Non functional requirements
Execution Frequency High Annotations
Sequence Diagram
: Unregistered User : WelcomeUI : WelcomeUIController : ModelFacade user : AppUser : UserListUI : UserControl users : List
Browse UsersgetUsers( )
getUserList( )
[repeat]
[while ResultSet.isEmpty == true]
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
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 37
Collaboration Diagram
: 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)
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 38
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.
Secondary Scenario Exceptional Scenario
Function View a specific user profile Non functional requirements
Execution Frequency Medium Annotations
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]
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 39
Collaboration Diagram
: 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 )
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 40
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.
Secondary Scenario Exceptional Scenario
Function Search registered users. Non functional requirements
Execution Frequency High Annotations
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( )
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 41
Collaboration Diagram
: 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( )
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 42
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
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 events. Secondary Scenario Exceptional Scenario
Function Browse the public events Non functional requirements
Execution Frequency Medium Annotations
Sequence Diagram
: Unregistered User
: WelcomeUI : WelcomeUIController : ModelFacade : EventControl event : Event : EventListUIevents : List
browse public eventsgetPublicEvents( )
getPublicEvents( )getPublicEvents( )
<<create>>
[repeat]
[while ResultSet.isEmpty == true]
<<create>>
add( event)
showResults( events )showResults( events )
shoeEventList( events)
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 43
Collaboration Diagram
: Unregistered User
: WelcomeUI : WelcomeUIController
: 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 )
9: showResults( events )
10: shoeEventList( events)
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 44
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
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.
Secondary Scenario Exceptional Scenario
Function View a public event Non functional requirements
Execution Frequency Medium Annotations
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>>
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 45
Collaboration Diagram
: 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 )
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 46
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
Execution Frequency Medium Annotations
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 47
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( )
showResults( )showResults( )
The parameters will be the form fields
<<update>>
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 48
Collaboration Diagram
: Registered User
: WelcomeUI : WelcomeUIController
: 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>>
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 49
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
Execution Frequency Medium Annotations
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( )
showResults( )showResults( )
<<create>>
add( item )
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 50
Collaboration Diagram
: Registered User
: WelcomeUI : WelcomeUIController
: 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>>
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 51
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.
Secondary Scenario Exceptional Scenario
There will be a possibility to browse user by different fields. Or to browse the user created events.
Function Browse events. Non functional requirements
Execution Frequency High Annotations
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 )
[while ResultSet.isEmpty == true]
query the DB only getting the event according to the profile
showResults( events )showResults(events )
shoeEventList(events )
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 52
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 53
Collaboration Diagram
: 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)
11: showResults( events )
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 54
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
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.
Secondary Scenario Exceptional Scenario
Function View a public event Non functional requirements
Execution Frequency Medium Annotations
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 55
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
Secondary Scenario Exceptional Scenario
If there’s an error while deleting the event the user will be notified
Function Delete event Non functional requirements
Execution Frequency Medium Annotations
Sequence Diagram
: Registered User
: EventListUI : EventListUIController : ModelFacade : Event : EventControl
delete event
deleteEvent( )deleteEvent( e_id)
deleteEvent(e_id )<<remove>>
showResults( )showResults( )
showResults( )
showConfirmation( )
confirm
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 56
Collaboration Diagram
: 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( )
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 57
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
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 58
2.2.1.2. Unregistered User Module
WelcomeUI
show()
UserListUI
showUserList()showResults()
showConfirmation()
UserProfileUI
showProfile()
SearchUsersUI
showSearchForm()showSearchResults()
Unregistered User
(from Use Case View)
EventListUI
shoeEventList()showResults()
showConfirmation()
EventUI
showEvent()
AppUser
(from Use Case View)
WelcomeUIController
getUsers()returnResults()
getPublicItems()showSearchForm()
searchUsers()showResults()
getPublicEvents()editUserProfile()
createEvent()browseEvents()
UserListUIController
getUserProfile()showResults()deleteUser()
EventListUIController
viewPublicEvent()showResults()deleteEvent()
ModelFacade
checkLogin()showResults()registerUser()getUserList()
returnResults()getUserProfile()searchUsers()
getPublicEvents()viewPublicEvent()
deleteUser()updateProfile()createEvent()getEvents()
deleteEvent()
Event EventControl
getPublicEvents()createEvent()
persist()getEvents()
viewPublicEvent()deleteEvent()
List
add()
UserControl
checkLogin()registerUser()
persist()getUserList()
getUserProfile()getBlogEntries()searchUsers()deleteUser()
updateProfile()
(from Use Case View)
Blog
View(from Use Case View)
Model(from Use Case View)
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 59
2.2.1.3. Registered User Module
EventListUI
shoeEventList()showResults()
showConfirmation()
WelcomeUI
show()
ProfileUI
showProfileForm()showResults()
CreateEventUI
showCreateEventForm()showResults()
Registered User
(from Use Case View)
Event
add()
WelcomeUIController
getUsers()returnResults()
getPublicItems()showSearchForm()
searchUsers()showResults()
getPublicEvents()editUserProfile()
createEvent()browseEvents()
EventListUIController
viewPublicEvent()showResults()deleteEvent()
ProfileUIController
checkFields()showResults()
CreateEventUIController
validateFields()showResults()
ModelFacade
checkLogin()showResults()registerUser()getUserList()
returnResults()getUserProfile()searchUsers()
getPublicEvents()viewPublicEvent()
deleteUser()updateProfile()createEvent()getEvents()
deleteEvent()
List
add()
(from Unregistered User Package)
UserProfile
UserControl
checkLogin()registerUser()
persist()getUserList()
getUserProfile()getBlogEntries()searchUsers()deleteUser()
updateProfile()
AppUser
View(from Use Case View)
Model(from Use Case View)
EventControl
getPublicEvents()createEvent()
persist()getEvents()
viewPublicEvent()deleteEvent()
ItemProfile
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 60
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>>
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 61
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 62
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 63
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
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 64
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 65
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 66
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 67
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 68
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 69
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 70
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…
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 71
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>>
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 72
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].
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 73
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 74
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 75
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 76
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 77
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 78
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 79
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
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 80
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 81
• 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)
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 82
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 83
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 84
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 85
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].
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 86
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 87
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 88
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
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
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 89
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 90
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 91
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 92
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 93
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);
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 94
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);
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 95
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
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 96
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 97
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:
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 98
Event/Articles:
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 99
User Blog:
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 100
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 101
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 102
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:
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 103
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 104
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)
showResults(String results)
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()
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 106
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 107
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>>
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 109
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 110
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”.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 111
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 112
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
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 113
• 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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 114
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 115
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 116
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 117
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 118
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 119
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
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 120
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 121
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
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 122
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 123
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 124
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 125
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 126
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 127
4.2. Gantt Chart
In the next figure the Gantt diagram shows the initial planning of all the phases and its
different tasks.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 128
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 129
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
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 130
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 131
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 132
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 133
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
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 134
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 135
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 136
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 137
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
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 138
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
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 139
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 140
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 141
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 142
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 143
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
belong to many filters
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 144
filter_country(~country_filter): Filter! -> Country?
//8) A Filter will have associated one language and one language can
belong to many filters
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?
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 145
//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
}
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 146
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
}
}
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 147
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
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 148
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
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 149
7.3.3. Class Diagram
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 150
7.3.4. Object Diagram
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 151
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
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 152
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 153
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 154
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
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 155
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 156
Log in the Application
Fail:
Inspection Item Pass/Fail/Partial Comments 1. User leaves all the inputs
blank and clicks “submit”.
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:
Inspection Item Pass/Fail/Partial Comments
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:
Inspection Item Pass/Fail/Partial Comments
1. User only enters a search string.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 157
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:
Inspection Item Pass/Fail/Partial Comments 1. User leaves all the inputs
blank and clicks “submit”.
2. The items created by the user should have two links: edit and remove
Pass:
Inspection Item Pass/Fail/Partial Comments
1. User only enters the required fields.
2. User enters the required fields and the filtering information.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 158
Delete Event
Pass:
Inspection Item Pass/Fail/Partial Comments 1. User clicks on the link to
delete the event from system.
Create Article Fail:
Inspection Item Pass/Fail/Partial Comments
1. User leaves all the inputs blank and clicks “submit”.
Pass:
Inspection Item Pass/Fail/Partial Comments
1. User only enters the required fields.
2. User enters the required fields and uploads a file.
3. User enters the required fields and the filtering information.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 159
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:
Inspection Item Pass/Fail/Partial Comments
1. User leaves all the inputs blank and clicks “submit”.
2. User only enters the required fields.
3. User changes the picture. 4. User changes all the fields.
Add Blog Entry
Fail:
Inspection Item Pass/Fail/Partial Comments 1. User leaves all the inputs
blank and clicks “submit”.
Pass:
Inspection Item Pass/Fail/Partial Comments
1. User only enters the required fields.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 160
Change Password
Fail:
Inspection Item Pass/Fail/Partial Comments 1. User leaves all the inputs
blank and clicks “submit”.
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:
Inspection Item Pass/Fail/Partial Comments
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 161
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:
Inspection Item Pass/Fail/Partial Comments
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:
Inspection Item Pass/Fail/Partial Comments
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 162
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:
Inspection Item Pass/Fail/Partial Comments
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:
Inspection Item Pass/Fail/Partial Comments
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 163
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 164
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 165
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 166
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 167
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 168
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 169
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 170
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 171
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 172
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 173
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 174
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
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 175
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 176
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 177
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 178
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 179
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 180
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 181
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 182
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 183
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:
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 184
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 185
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 186
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 187
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 188
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 189
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.
CIS 895 - KSU Student Portal MSE Portfolio
Javier Ramos Rodríguez KSU Student Portal 190
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/