10 Universidad de Java Desde Cero 10 JSP

CURSO DE SERVLETS Y JSPS
Hola, te saluda Ubaldo Acosta. Bienvenida o bienvenido nuevamente. Espero que estés listo para
comenzar con esta lección.
Vamos a estudiar los elementos de un JSP.
¿Estás listo? Ok, ¡Vamos!
© Todos los Derechos Reservados Global Mentoring Experiencia y Conocimiento para tu Vida 2
Vamos a revisar los elementos básicos de un JSP. Un JSP se va compone de Expresiones, Scriptlets, Declaraciones y también existe una
característica en la cual vamos a manejar una sintaxis equivalente en XML.
Una Expresión tiene la siguiente sintaxis: Sintaxis <%=expresión%> Lo que vamos a hacer es utilizar la sintaxis <%= para abrir nuestra expresión,
posteriormente agregamos una expresión que puede ser cualquier expresión valida que a final de cuentas va a ser equivalente a poner la sintaxis
out.println y lo que tengamos en nuestra expresión lo va a mandar al cliente. Finalmente cerramos la expresión con %> Este tipo de sintaxis <%=
expresión %> se conoce como un tag o etiqueta de expresión. La expresión puede ser un valor como puede ser una cadena, una expresión
matemática, una suma, una resta etc. o también puede ser el resultado de una llamada a una función, pero si mandamos a llamar una función el
resultado de esta función no puede ser de tipo void, debe de regresar algún valor ya que como podemos observar el resultado de evaluar esta
expresión se va a mandar a nuestro cliente entonces por ello esta expresión debe de regresar algún resultado.
Otro elemento de los JSPs son los Scriptlets. Un Scriptlet contiene código Java a diferencia de una expresión que únicamente la utilizamos para
imprimir información a nuestro cliente, un Scriptlets puede contener código Java que no necesariamente va a visualizar nuestro cliente debido a
que si este código Java no manda imprimir nada al cliente, entonces nuestro cliente no va a visualizar la información que este procesando. Este
código Java puede ser bastante robusto y por ello hay que tener cuidado respecto al código que manejemos con los Scriptlets, ya que aunque nos
permiten agregar mucho código y puede ser muy poderoso para agregar código Java eso también puede ser contraproducente sobre todo para el
mantenimiento de un JSPs, por lo que demasiado código en un scriptlet se considera una mala práctica.
La sintaxis de un Scriptlet es <% codigoJava %> a diferencia de una expresión no tiene un signo de igual. Inicia de igual manera con <% y el cierre
para el tag de un Scriptlets es el mismo, entonces la sintaxis es: <% codigoJava %> Es importante mencionar que el código generado dentro de un
Scriptlets se inserta dentro del método service() del servlet generado a partir del JSP que se haya compilado, posteriormente vamos a ver algunos
ejemplos para observar y poder entender este párrafo. Los Scriptlets pueden contener cualquier código Java válido, es decir, puede tener
declaraciones de variables, llamadas a funciones y en general puede tener cualquier lógica siempre y cuando respetemos que este código está
dentro de otro método, en este caso del método service().
En los JSPs también vamos a manejar los tags de declaraciones y la sintaxis es: <%! codigoJava %> . En las declaraciones también es código Java,
pero este código lo vamos a utilizar para declarar ya sea variables o métodos que pertenezcan a la clase del servlet generado, y a diferencia del
código Java que está en un Scriptlets en el cual todas las variables que declaremos son locales al método service(), en el caso de las declaraciones
el código que agreguemos, si es que declaramos una variable, se vuelve una variable de instancia debido a que se está agregando como una
variable de la clase del servlet generado y no únicamente como una variable local a cierto método. También los métodos que agreguemos se
vuelven métodos que son parte de la clase del servlet generado aunque no es muy utilizado este concepto de declaraciones ya que lo más común
es que desde un Scriptlets mandemos a llamar funciones o utilicemos variables que están definidas en otras clases y no dentro de nuestro JSP,
entonces en el caso de las declaraciones lo vamos a utilizar siempre y cuando necesitemos agregar ya sea variables o métodos que pertenezcan a
nuestro servlet generado a partir del JSP.
Por último, cada uno de nuestros componentes, como expresiones, Scriptlets y las declaraciones tienen su equivalente en sintaxis XML. Esto
vamos a ver que tiene varias aplicaciones en el sentido de que vamos a tener mayor compatibilidad si es que nuestros JSPs los generamos con
sintaxis XML y no con la sintaxis estándar. Cuando revisemos el tema de las sintaxis XML vamos a ver las equivalencias para cada uno de estos
elementos.
Vamos a revisar a continuación el tema de las variables implícitas en un JSP dentro del uso de los Scriptlets.
Dentro de un JSP podemos utilizar objetos que ya están instanciados para que podamos usarlos de manera
inmediata. Por ejemplo tenemos los objetos request, response, out, el objeto sesión, application entre otros. El
objeto request es el mismo objeto que hemos trabajado por ejemplo en los Servlets cuando sobreescribimos el
método doGet o doPost recibimos tanto el objeto request como el objeto response como parámetros. Entonces
estos objetos ya los tenemos disponibles en un JSP y no tenemos que instanciarlos, simplemente ponemos el
nombre de nuestra variable y por medio del operador punto (.) podemos acceder a los atributos y métodos del
objeto del tipo HTTPServletRequest. Lo mismo sucede con el método response, simplemente con este nombre de
variable podemos acceder a los atributos y métodos de este objeto HTTPServletResponse.
La variable out es equivalente al objeto PrintWriter que hemos instanciado dentro de los Servlets, en este caso
existe una pequeña variante ya que esta variable out es de tipo JspWriter.
La variable session es una variable de tipo HttpSession y con esta variable podemos obtener información que ya
hemos agregado a nuestra sesión, por ejemplo por medio de un Servlet. Vamos a ver más adelante por medio de
un concepto llamado directivas que podemos deshabilitar el acceso a la sesión en caso de que no queramos que
los JSPs manipulen directamente los atributos de una sesión o simplemente que no queramos que un JSP acceda
a los atributos o modifique los elementos de una sesión.
Tenemos también la variable llamada application, esta es equivalente al objeto ServletContext, que en un servlet
podemos obtener a partir del método getServletContext(). Este concepto lo vamos a ver posteriormente a más
detalle.
En resumen, existen variables ya instanciadas que podemos acceder directamente en un JSP. Vamos a revisar a
continuación algunos ejercicios para revisar estos conceptos básicos de los JSP’s.
En Global Mentoring promovemos la Pasión por la Tecnología Java. Te invitamos a visitar nuestro
sitio Web donde encontrarás cursos Java Online desde Niveles Básicos, Intermedios y Avanzados,
y así te conviertas en un experto programador Java.
Además agregamos nuevos cursos para que continúes con tu preparación como programador Java
profesional. A continuación te presentamos nuestro listado de cursos:
Lógica de Programación Hibernate Framework

Fundamentos de Java Spring Framework
Programación con Java JavaServer Faces
Java con JDBC Java EE (EJB, JPA y Web Services)
HTML, CSS y JavaScript JBoss Administration
Servlets y JSP’s Android con Java
Struts Framework HTML5 y CSS3
Datos de Contacto:
Sitio Web: www.globalmentoring.com.mx

Email: informes@globalmentoring.com.mx
www.gl obal mentoring.com .mx
Crear un programa para el manejo básico de elementos de un
JSP. Al finalizar deberemos observar lo siguiente:

Vamos a crear el proyecto:


Vamos a crear un nuevo JSP:

( )


( )

Archivo index.html: Dar click para ir al código
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>Ejemplo de Elementos JSPs</title>
</head>
<body>
<h1>Ejemplo de Expresiones</h1>
<br>
<a href="expresiones.jsp">Link al JSP de Expresiones</a>
<br>

<h4>Formulario HTML</h4>
<form name="forma1" action="procesaFormulario.jsp">
Usuario: <input type="text" name="usuario">

<br>
Password: <input type="password" name="password">
<br>
<input type="submit" value="Enviar">
</form>
</body>
</html>
Archivo expresiones.jsp: Dar click para ir al código
<%@page contentType="text/html" pageEncoding="UTF-8"%>
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>JSP de Expresiones</title>
</head>
<body>
<h1>JSP de Expresiones</h1>
Concatenación: <%= "Saludos" + "JSP" %>
<br>
Operación Matemática: <%= 2 * 3 / 2 %>
<br>
Session id: <%= session.getId() %>
<br>
<br>
<a href="index.html">Regresar al inicio </a>
</body>
</html>
Archivo procesaFormulario.jsp: Dar click para ir al código
<!DOCTYPE html>
<html>
<head>
<title>Procesa Formulario</title>
</head>
<body>
<h1>Resultado de Procesar Formulario</h1>
Usuario: <%= request.getParameter("usuario") %>
<br>
Password: <%= request.getParameter("password") %>
<br>
<br>
<a href="index.html">Regresar al inicio </a>
</body>
</html>

El resultado es como sigue:

( )

( )

• Con este ejercicio hemos puesto en práctica algunos
elementos utilizando JSPs.
• Conforme vayamos avanzando en el uso de JSPs veremos

más elementos, pero en este ejercicio pusimos en práctica
algunas expresiones y el procesamiento de parámetros
enviados desde un formulario HTML.

’
Por: Ing. Ubaldo Acosta

Crear un programa para el manejo básico de Scriptlets en un




( )


( )

<!DOCTYPE html>
<html>
<head>
<title>Ejemplo Scriptlets JSP</title>
</head>
<body>
<h1>Ejemplo de Scriplets con JSPs</h1>
<br>
<br>
<a href="scriptlets.jsp">Ejemplos de Scriplets</a>
<br>
<br>

<form action="fondoColor.jsp">
Proporciona el color de fondo (ej. red, blue, etc)
<input type="text" name="colorFondo">
<br>
</form>
</body>
</html>
Archivo scriptlets.jsp: Dar click para ir al código
<!DOCTYPE html>
<html>
<head>
<title>JSP con ScripletsPage</title>
</head>
<body>
<h1>JSP con Scriplets</h1>
<br>

<%
out.println("Saludos desde un scriplet");
%>
<br>

Archivo scriptlets.jsp: Dar click para ir al código

<%
String nombreAplicacion = request.getContextPath();
out.println("nombreAplicacion:" + nombreAplicacion);
%>
<br>

<%
if (session != null && session.isNew()) {
%>
la sesion SI es nueva
<%
} else if (session != null) {
%>
la sesion NO es nueva
<%
}
%>
</body>
</html>
Archivo fondoColor.jsp: Dar click para ir al código
<!DOCTYPE html>
<%
String fondo = request.getParameter("colorFondo");
//Si no se envio un color, ponemos un color por default
if (fondo == null || fondo.trim().equals("")) {
fondo = "white";
}
%>
<html>
<head>
<title>JSP Cambio de Color de Fondo</title>
</head>
<body bgcolor="<%=fondo%>">
<h1>Fondo de color aplicado: <%= fondo%></h1>
<br>
<a href="index.html">Regresar al Index</a>
</body>
</html>

( )

( )

• Con este ejercicio hemos puesto en práctica el concepto de Scriptlets
utilizando JSPs.
• Con esto pudimos observar cómo podemos agregar código Java a

nuestros JSPs con ayuda de los Scriptlets. Sin embargo debemos utilizar
con mucha precaución esta características ya que rápidamente podemos
terminar en páginas JSP poco mantenibles y difíciles de entender y
probar.
• Sin embargo conforme avancemos estudiaremos las mejores prácticas en

el uso de Servlets y JSPs, incluyendo el uso de Scriptlets.

’

Crear un programa para el manejo básico de declaraciones de
un JSP. Al finalizar deberemos observar lo siguiente:



Borramos el archivo index.html


( )

Archivo index.jsp: Dar click para ir al código
<%-- Agregamos una declaracion --%>
<%!
//Declaramos una variable con su metodo get
private String usuario = "Alberto";
public String getUsuario() {

return this.usuario;
}
//Declaramos un contador de visitas
private int contadorVisitas = 1;
%>
<!DOCTYPE html>
<html>
<head>
<title>Uso de Declaraciones</title>
</head>
<body>
<h1>Uso de Declaraciones</h1>
Usuario por medio del atributo: <%= this.usuario%>
<br>
Usuario por medio del metodo: <%= this.getUsuario()%>
<br>
Contador de Visitas desde que se reinicio el servidor:

<%= this.contadorVisitas++%>
</body>
</html>

( )
Si refrescamos la página se incrementa el contador:

• Con este ejercicio hemos puesto en práctica el concepto de
declaraciones utilizando JSPs.
• Con esto aprendimos a declarar variables y métodos Java

dentro de una página JSP. Vamos a continuar revisando otros
conceptos.

’

Crear un programa para el manejo básico de documentos JSP
(jspx). Al finalizar deberemos observar lo siguiente:




( )
Si el IDE no tiene la opción
de crear documentos JSP,
simplemente pueden crear
un archivo JSP y cambiar
la extensión a .jspx

<!DOCTYPE html>
<html>
<head>
<title>Ejemplos de Documentos JSPs</title>
</head>
<body>
<h1>Ejemplo de Documentos JSPs</h1>
<br>
<a href="documentoJsp.jspx">Link al JSPX</a>
</body>
</html>

Archivo documentoJsp.jspx: Dar click para ir al código
<?xml version="1.0" encoding="UTF-8"?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0">
<jsp:directive.page contentType="text/html" pageEncoding="UTF-8"/>


<jsp:declaration>
private int contadorVisitas = 1;
</jsp:declaration>
<html>
<body bgcolor="yellow">
<h1>Ejemplo de un Documento JSPx</h1>


<jsp:text>Saludos desde un documento JSP</jsp:text>
<br/>


Expresión Matemática:
<jsp:expression> 2 * 3</jsp:expression>
( )
Archivo documentoJsp.jspx: Dar click para ir al código
<br/>

<jsp:scriptlet>
String nombreAplicacion = request.getContextPath();
</jsp:scriptlet>
Nombre Aplicación:
<jsp:expression> nombreAplicacion</jsp:expression>
<br/>
Contador de Visitas:
<jsp:expression> this.contadorVisitas++</jsp:expression>
</body>
</html>
</jsp:root>


( )

• Con este ejercicio hemos puesto en práctica el concepto de documentos
JSP, y aplicamos varios elementos utilizando este tipo de documentos.
• Vimos cómo los mismos elementos que hemos aplicado a los archivos
.jsp, también los podemos utilizar pero aplicando xml en los documentos
.jspx
• Esto nos permite formalizar nuestro archivo con validaciones XML,

aunque es opcional aplicarlo a nuestros proyectos Java Web.

’

Hola, te saluda nuevamente Ubaldo Acosta. Espero que estés listo para comenzar con esta
lección..
Vamos a estudiar el tema de directivas en JSP’s.
¿Estás listo? ¡Vamos!
Vamos a revisar a continuación el tema de las directivas en los JSP’s.
Las directivas nos permiten controlar el comportamiento de un JSP, por ejemplo las clases que
vamos a utilizar dentro de un JSP y hacer el import de clases Java, especificar el tipo MIME con el
que vamos a responder a nuestro cliente.
También con estas directivas podemos especificar si un JSP va a participar en el concepto de

sesiones, o podemos especificar el tamaño del buffer de salida, especificar el JSP de error en caso
de que tengamos alguna excepción dentro de nuestro JSP, o indicar si nuestro JSP va a manejar el
concepto de multihilos, entre varias características más.
Veamos a continuación a más detalle varias de las directivas que podemos utilizar en nuestros
JSP’s.
En esta lección vamos a revisar la directiva de page. Algunos de los atributos que podemos indicar en la
directiva page son:
Import: El atributo de import dentro de la directiva page nos va a permitir especificar cuáles son las clases que
vamos a importar dentro de nuestro JSP e indirectamente a nuestro servlet generado a partir de la solicitud a
nuestro JSP. Aunque el import lo podemos declarar en cualquier parte de nuestro JSP lo recomendable es
ponerlo al principio como una buena práctica. Para especificar las clases que queremos importar en nuestro JSP
podemos utilizar la sintaxis <%@ page import=”paquete.Clase1, paquete.ClaseN” %>. Podemos detectar que
es una directiva debido a que estamos utilizando ahora el símbolo de @ y posteriormente el nombre page.
Posteriormente utilizamos el atributo import e indicar el nombre completamente calificado de nuestras clases,
es decir, incluimos el paquete y el nombre de nuestra clase y si queremos especificar más de una clase a utilizar
vamos a separarlas por coma.
Posteriormente tenemos el atributo contentType <%@page contentType=”MIME-Type” %> . Este atributo nos
permite especificar el tipo de respuesta a nuestro cliente web.
Session: <% @page session=”true” %> También vamos a poder indicar por medio de esta directiva page si el
JSP va poder acceder al objeto sesión que se haya creado anteriormente por ejemplo desde un JSP o desde
otro servlet. Por default un JSP está configurado para que podamos acceder al objeto session, si queremos
indicar lo contrario tendremos que especificar false en esta directiva y si especificamos false en esta directiva lo
que sucede es que dentro de nuestras clases implícitas de un JSP ya no vamos a tener acceso a nuestra variable.
Atributo isELIgnored: <%@ page isELIgnored=”false” %> También tenemos otro atributo llamado isELIgnored
esto lo que significa es que si queremos deshabilitar el manejo de expression language que posteriormente
vamos a revisar, tendríamos que indicarlo por medio de esta directiva page indicando en el atributo isELIgnored
el valor de true, por default un JSP a partir de la versión 2.4 puede utilizar de manera automática el concepto de
Expression Language pero anterior a la versión 2.3 de los servlets los JSPs por default no pueden acceder al
lenguaje conocido como Expression Language.
Atributo buffer: <%@ page buffer=”tamañoEnKb” %> dentro de esta misma directiva page tenemos acceso al
atributo buffer. Con este atributo buffer podemos especificar el tamaño en Kb que puede contener nuestro
buffer del JSP y si llegamos al tamaño especificado en este JSP entonces se hace un flush o vaciado de manera
automática de todo el flujo que hayamos agregado a nuestro printWriter o a nuestro output servlet
dependiendo el caso.
También tenemos los atributos errorPage con la siguiente sintaxis:

<%@ page errorPage=”url_relativo_al_JSP_de_error” %> con el atributo erroPage vamos a especificar cual va
a ser el JSP que va a manejar las excepciones en caso de que el JSP provoque un error, y para configurar el JSP
que va a manejar los errores tenemos que indicar la directiva isErrorPage con la siguiente sintaxis:
<%@ page isErrorPage=”true” %> indicando que ese JSP si es el JSP que va a manejar los errores, por default
los JSPs tienen el valor de esta directiva igual a false debido a que los JSPs no van a manejar las excepciones de
manera automática sino hay que configurarlos para que puedan acceder a la pila de errores.
También podemos observar el atributo isThreadSafe con sintaxis <%@ page isThreadSafe=”true” %> Por
default el contenedor de servlets, considera a un JSP como seguro para ser accedido por múltiples hilos, es
decir, el valor por default es true. Si se desea que el contenido del JSP no sea accedido por distintos hilos
entonces se debe especificar este valor como false.
Por ultimo vamos a mencionar el atributo extends <%@ page extends=”paquete.NombreClase” %> nos va a
permitir heredar de una clase según especifiquemos en ese atributo y por lo tanto nuestro JSP va a heredar las
características de la clase que especifiquemos normalmente ese atributo únicamente se utiliza si es que
queremos agregar comportamiento de terceros aunque este concepto rara vez lo configuramos y únicamente
se van a utilizar si es que algún software en particular alguna solución que compremos nos solicite hacer un
extends de clases ya creadas por este vendedor.
Vamos a poner a continuación en práctica alguno de estos atributos utilizando el concepto de directivas de un
JSP.

Datos de Contacto:

’

Crear un programa para practicar las directivas de JSPs. Al
finalizar deberemos observar lo siguiente:



Vamos a crear un JSP:

Vamos a crear la clase Conversiones.java:

( )
Vamos a crear la clase Conversiones.java:

<!DOCTYPE html>
<html>
<head>
<title>Generacion de un Excel</title>
</head>
<body>
<h1>Generación de un Archivo de Excel</h1>
<br>
<a href="reporteExcel.jsp">Link al reporte de Excel</a>
</body>
</html>

Archivo reporteExcel.jsp: Dar click para
<%@page import="utilerias.Conversiones, java.util.Date" %>
<%@page contentType="application/vnd.ms-excel" %>
<%
String nombreArchivo="reporte.xls";
ir al código
response.setHeader("Content-Disposition", "inline; filename=" +
nombreArchivo );
%>
<html>
<head>
<title>Reporte de Excel</title>
</head>
<body>
<h1>Reporte de Excel</h1>
<br>
<table border="1">
<tr>
<th>Curso</th>
<th>Descripción</th>
<th>Fecha Inicio</th>
</tr>
<tr>
<td>1. Fudamentos de Java</td>
<td>Aprenderemos la sintaxis básica de Java</td>
<td><%= Conversiones.format( new Date() ) %></td>
</tr>
<tr>
<td>2. Programación con Java</td>
<td>Pondremos en práctica conceptos de
la Programación Orientada a Objetos
</td>
</tr>
</table>
</body>
</html>
Archivo Conversiones.java: Dar click para
package utilerias;
import java.text.SimpleDateFormat;
ir al código
import java.util.Date;
/**
*
* @author Ubaldo
*/
public class Conversiones {
private static final String FORMATO_FECHA = "dd-MM-yyyy";
/**
* Método que permite convertir una fecha en una cadena
* con el formato especificado
* @param fecha
* @return
*/
public static String format(Date fecha){
SimpleDateFormat formateador =
new SimpleDateFormat(FORMATO_FECHA);
return formateador.format( fecha );
}
}


• Probar con distintos valores y verificar el resultado de cada
caso.

• Con este ejercicio hemos puesto en práctica el concepto de
directivas utilizando JSPs.
• Esta es una manera muy simple, pero que ejemplifica muy

bien lo que podemos hacer con el uso de directivas en JSPs.
Continuemos con otro ejercicio.

’

’

Crear un programa para practicar las directivas de JSPs. Al
finalizar deberemos observar lo siguiente:

Copiamos el proyecto anterior para crear el nuevo proyecto:


Vamos a crear un JSP:

Vamos a crear un archivo de JavaScript:

Vamos a crear un archivo de JavaScript:

Archivo reporteExcel.jsp: Dar click para ir al código
<%@page errorPage="/WEB-INF/manejoErrores.jsp"%>
<%@page import="utilerias.Conversiones, java.util.Date" %>
<%@page contentType="application/vnd.ms-excel" %>
<%
String nombreArchivo="reporte.xls";
response.setHeader("Content-Disposition", "inline; filename=" +
nombreArchivo );
%>
<html>
<head>
<title>Reporte de Excel</title>
</head>
<body>
<h1>Reporte de Excel</h1>
<br>
<table border="1">
<tr>
<th>Curso</th>
<th>Descripción</th>
<th>Fecha Inicio</th>
</tr> www.gl obal mentoring.com .mx
( )
Archivo reporteExcel.jsp: Dar click para ir al código
<tr>
<td>1. Fudamentos de Java</td>
<td>Aprenderemos la sintaxis básica de Java</td>
<td><%= Conversiones.format( "500" ) %></td>
</tr>
<tr>
<td>2. Programación con Java</td>
<td>Pondremos en práctica conceptos de
la Programación Orientada a Objetos
</td>
</tr>
</table>
</body>
</html>

Archivo manejoErrores.jsp: Dar click para
<%@page isErrorPage="true" %>
<%@ page import="java.io.*" %>
ir al código
<html>
<head>
<title>Manejo Errores</title>
<script type="text/javascript" src="<%=request.getContextPath()%>/recursos/funciones.js">
</script>
</head>
<body>
<h1>Manejo de Errores</h1>
<br>
<br>
Ocurrió un error:
<%= exception.getMessage()%>
<br>
<br>
<a href="<%=request.getContextPath()%>/index.html">Regresar al Inicio</a>
<br>
<br>
<a href="#" onclick="cambio('mensaje1')">
Ver detalles
</a>
<div id="mensaje1" style="position:relative;visibility: hidden">
<PRE>
<% exception.printStackTrace(new PrintWriter(out));%>
</PRE>
</div>
</body>
</html> www.gl obal mentoring.com .mx
Archivo funciones.js: Dar click para
var capa;
function cambio(idCapa){
ir al código
//Recuperamos la capa segun el elemento disponible
if (document.layers)
capa = eval("document." + idCapa);
if (document.all)
capa = eval(idCapa + ".style");
if (document.getElementById)
capa = eval('document.getElementById("' + idCapa + '").style');
//Si esta visible la capa la ocultamo, o viceversa

if ((capa.visibility == "hidden") || (capa.visibility == "hide")){
capa.visibility = (document.layers) ? "show" : "visible" ;
}else{
capa.visibility = (document.layers) ? "hide" : "hidden" ;
}
}

Archivo Conversiones.java: Dar click para
package utilerias;
import java.text.SimpleDateFormat;
ir al código
import java.util.Date;
public class Conversiones {
private static final String FORMATO_FECHA = "dd-MM-yyyy";
public static String format(Date fecha) {

SimpleDateFormat formateador = new SimpleDateFormat(FORMATO_FECHA);
return formateador.format(fecha);
}
public static String format(String fecha) {

SimpleDateFormat formateador = new SimpleDateFormat(FORMATO_FECHA);
return formateador.format(fecha);
}
}



• Con este ejercicio hemos puesto en práctica el manejo de un
JSP de error.
• Con esto podemos procesar la excepción que suceda en

nuestra aplicación y decidir que información mostrar al
usuario una vez ocurrido algún error.

’

Vamos a estudiar el tema inclusión de archivos con JSP’s.
En esta lección vamos a revisar el tema de la inclusión de archivos utilizando JSPs.
En términos simples la inclusión de archivos, como su nombre lo dice, es agregar un JSP dentro de
otro, sin embargo existen dos formas de realizar esta acción cuando utilizamos JSPs.
En primer lugar tenemos la inclusión estática también conocida como inclusión en tiempo de
traducción (translation time), por otro lado tenemos la inclusión dinámica también conocida
como inclusión en tiempo de ejecución (request time). Vamos a revisar las diferencias entre cada
tipo de inclusión de archivos.
Comencemos con la inclusión estática. Este concepto lo podemos aplicar utilizando la directiva
include y según vimos anteriormente en el tema de directivas podemos reconocer a esta directiva
por medio del símbolo @. Posteriormente lo que hacemos es especificar por medio del atributo
file el nombre del JSP que vamos a incluir en el JSP principal.
En el caso de la inclusión dinámica lo que sucede es que vamos a utilizar, en lugar de una
directiva, el concepto de una acción, posteriormente vamos a revisar más acciones, sobre todo
para acceder a los JavaBeans, pero en este caso una acción también nos va a permitir hacer un
include de manera dinámica de otro JSP. Posterior al nombre de la acción, especificamos el
atributo page y como valor del atributo el JSP que queremos incluir en nuestro JSP principal.
Podemos observar que parte de las diferencias es que en nuestra directiva <%@ include
file=”paginaRelativa.jsp” %> estamos manejando el atributo de file y en la inclusión dinámica
<jsp:include page=”paginaRelativa.jsp” /> estamos utilizando el atributo de page, estas son
simplemente algunas de las diferencias y vamos a ir revisando estos dos conceptos a más detalle.
En la inclusión estática, según hemos visto, tenemos la siguiente sintaxis:

<%@ include file=”paginaRelativa.jsp” %> vamos a utilizar una directiva, por lo tanto abrimos un
picoparéntesis (<), seguido de un signo de porcentaje (%) y utilizamos el símbolo de arroba (@),
posteriormente usamos la directiva include y finalmente especificamos el nombre del archivo que
vamos a incluir en el JSP principal.
El objetivo de utilizar esta inclusión estática es reutilizar código que puede provenir de un texto
plano de un HTML o de otro JSP. En el caso de la inclusión estática, el JSP que estamos incluyendo
dentro del JSP principal puede afectar o compartir información con el JSP principal. En la inclusión
estática no se delega el control al JSP que vamos a incluir, si no que se va a generar un único JSP
que va a ser la combinación del JSP principal y del JSP que estamos incluyendo. Recordemos que
un JSP se compila finalmente en un Servlet, ya que es necesario la clase Java para poder ejecutar
el JSP asociado. Posteriormente veremos un ejemplo para tener más claro este concepto.
Una vez que tenemos ya un JSP o más bien un Servlet de manera única y que contiene a ambos
JSPs, entonces podemos compartir variables y métodos entre los diferentes JSPs que estamos
utilizando. Uno de los detalles es que, con la inclusión estática, para tener la versión más reciente
del JSP que estamos incluyendo se recomienda compilar y reconstruir nuevamente el proyecto
debido a que esta inclusión estática no garantiza que tengamos la última versión del JSP incluido.
Esto se debe a que el contenido del JSP incluido se va a vaciar en el JSP principal; esto lo vamos a
detallar más adelante.
Vamos a revisar un diagrama de una inclusión estática. Supongamos que tenemos

un JSP principal llamado a.jsp y un JSP que vamos a incluir llamado b.jsp. En el
primer bloque del diagrama estamos mencionando los archivos jsp con los que
vamos a trabajar, en el segundo bloque estamos trabajando ya en tiempo de
traducción del JSP, es decir, cuando se genera un servlet y en el tercer bloque
estamos especificando el tiempo de ejecución, es decir, cuando mandamos a llamar
a nuestro JSP. Veamos a más detalle cada uno de los pasos.
El JSP principal (a.jsp) debe agregar la directiva según hemos visto en la sintaxis de
la inclusión estática y va agregar el contenido del JSP incluido (b.jsp). Una vez que
solicitamos nuestro recurso se hace una traducción del JSP, aquí la gran diferencia
de la inclusión estática es que únicamente se va a generar un solo Servlet, y este
Servlet contendrá el código de los dos JSPs (a.jsp y de b.jsp) y el código HTML
generado por cada uno de los JSPs los va a mezclar en un solo Servlet utilizando el
método out.write() .Este html ya incluye el resultado de los dos JSPs.
Más adelante vamos a ver un ejemplo de este tipo de inclusión.
Vamos a revisar ahora la inclusión dinámica.

La sintaxis según hemos comentado es una acción de los JSPs, una acción tiene la siguiente sintaxis:
<jsp:include page=”paginaRelativa.jsp” /> abrir el picoparéntesis (<) posteriormente ponemos el prefijo
jsp y utilizamos dos puntos (:) seguido del nombre include, esta es la acción que estamos utilizando la
acción de include y posteriormente especificamos por medio del atributo page la página jsp que vamos a
incluir en nuestro jsp principal.
El objetivo de esta inclusión dinámica es la misma que la inclusión estática, lo que queremos conseguir es
reutilizar código ya sea que provenga de texto plano de HTML o de alguna otra fuente como puede ser un
JSP.
La ventaja de utilizar la inclusión dinámica es que nos va a permitir actualizar el contenido del JSP principal
sin alterar al mismo. El JSP principal en lugar de incluir al otro JSP lo que va hacer es delegar el control al
JSP incluido y la salida que es el resultado de ejecutar al JSP incluido se va agregar al JSP principal.
Debido a esta situación se generan 2 servlets, uno por cada JSP, ya que cada JSP se va a ejecutar de
manera independiente. Esto implica que no vamos a poder compartir variables o métodos entre los JSPs
sin embargo esto nos permite garantizar que siempre vamos a tener la versión más reciente del JSP que
estamos incluyendo, ya que cada vez que mandemos llamar una inclusión dinámica se va a ejecutar el JSP
incluido de manera independiente debido a que se delega el control al JSP incluido. Una vez que termine
de ejecutarse ese JSP incluido regresa el control al JSP principal.
Al igual que la inclusión estática debemos de manejar una inclusión relativa a nuestra aplicación web, por
ello será importante el uso de una diagonal (/) y posteriormente vamos a indicar el recurso web que vamos
a utilizar.
Otra ventaja de la inclusión dinámica es que vamos a poder incluir también archivos privados, es decir,
archivos o JSPs que estén dentro de la carpeta de WEB-INF. Por lo tanto podremos acceder tanto a
recursos públicos que estén fuera de la carpeta WEB-INF o a recursos privados, es decir a JSPs o recursos
que estén dentro de la carpeta de WEB-INF.
Más adelante realizaremos un ejercicio de este tipo de inclusión.
Vamos a observar ahora un diagrama de inclusión dinámica. Podemos observar que ahora tenemos los
mismos bloques pero estamos separando ya a más detalle los archivos a.jsp y b.jsp.
También de igual manera observamos los archivos que vamos a utilizar (a.jsp y b.jsp), el tiempo de
traducción y observamos bloque de tiempo de ejecución.
El JSP principal va a utilizar una acción de los JSPs para incluir el archivo b.jsp dentro del archivo a.jsp,
posteriormente lo que sucede en tiempo de traducción es que se van a generar dos servlets, uno
correspondiente al JSP principal (a.jsp) y el otro correspondiente al JSP a incluir (b.jsp).
Entonces podemos observar que se genera un JSP con el contenido del archivo a.jsp y se genera otro
servlet con el contenido del archivo b.jsp, pero aquí viene lo interesante cuando ejecutamos este JSP. Lo
que sucede si utilizamos una inclusión dinámica es que estamos solicitando el recurso de a.jsp y en cuanto
este JSP detecta la inclusión del archivo que queremos agregar entonces delega el control al otro servlet
en este caso es el servlet asociado con el jsp de b.jsp y en cuanto termina de ejecutarse este JSP va a
regresar el control al jsp principal y finalmente lo que va hacer es generar una salida, esta salida del servlet
incluido se va agregar dentro del JSP principal, por ello es que podemos estar seguros que este JSP que se
está incluyendo siempre va a contener la última versión.
Finalmente la salida que se manda al cliente va a tener tanto la salida del JSP principal como la salida del
JSP que se incluyo.
Por último vamos a revisar una comparación entre los diferentes tipos de inclusión.
La inclusión estática en la cual utilizamos una directiva y la inclusión dinámica en la cual utilizamos una
acción de los JSPs, podemos observar cuando ocurre la inclusión, en el caso de una inclusión estática
ocurre en tiempo de traducción y en una inclusión dinámica ocurre en tiempo de ejecución.
También podemos responder a la pregunta de ¿Qué se incluye en el JSP principal? En el caso de la
inclusión estática se va a incluir directamente el contenido del archivo y en el caso de la inclusión dinámica
se va a incluir la salida de la página JSP.
El número de Servlets generados en una inclusión estática únicamente es 1 y en el caso de una inclusión
dinámica se generan dos Servlets, uno por cada JSP, el principal y el que se va a incluir.
También podemos responder a la pregunta ¿podemos incluir cabeceros que afecten al JSP principal? En el
caso de la inclusión estática únicamente se genera un Servlet, por lo que sí podemos modificar al JSP
principal por medio de cabeceros desde el JSP que estamos incluyendo. En el caso de la inclusión dinámica
esto no puede suceder debido a que los JSPs se ejecutan de manera independiente, por lo que no se
comparte información entre ellos, y tampoco cabeceros.
Respecto a la pregunta ¿Podemos incluir atributos o métodos en común? En el caso de la inclusión estática
es cierto y es debido a que se genera un único servlet por lo tanto vamos a poder compartir atributos o
métodos que estén definidos en un Servlet o en otro y en el caso de la inclusión dinámica esto no es
posible debido a que los JSPs nunca se mezclan simplemente se delega el control y por eso es falso.
Respecto a la pregunta ¿Debemos actualizar la página principal si se actualiza la página incluida? En el
caso de la inclusión estática esto es cierto para garantizar que tenemos la última versión del JSP incluido.
En el caso de la inclusión dinámica esto no es necesario debido a que como delegamos el control siempre
se está ejecutando la última versión del JSP incluido y en el caso del JSP principal delega el control al JSP
incluido.
A continuación vamos a revisar algunos ejercicios para poner en práctica el uso de las inclusiones estática y
dinámica utilizando JSPs.

Datos de Contacto:

’

Crear un programa para practicar la inclusión estática
utilizando JSP’s. Al finalizar deberemos observar lo siguiente:


( )


Agregamos un archivo funciones.js al proyecto:

Agregamos un archivo funciones.js al proyecto:

Agregamos el archivo estilos.css al proyecto:

Agregamos el archivo estilos.css al proyecto:

Agregamos el archivo noticia1.html al proyecto:






Agregamos el archivo video1.html al proyecto:



Agregamos el archivo index.jsp al proyecto:


Archivo index.jsp:
<html>
<head>
<title>Ejemplo Inclusion Estatica</title>
<script type='text/JavaScript' src="recursos/funciones.js"></script>
<link href="recursos/estilos.css" type="text/css" rel="stylesheet">
</head>
<body>
<h1>Inclusión de Archivos Estáticos</h1>


<br>

<span class="noticias" align="left">
<a href="javascript:desplegar ('noticias');">
<img border="0" src="http://icursos.net/cursos/ServletsJSPs/Leccion14/noticias.gif">
</a>
</span>
<span id="noticias" class="ocultar_menu">

<ul>
<li><%@include file="pages/noticia1.html" %></li>
<li><%@include file="pages/noticia2.html" %></li>
</ul>
</span> www.gl obal mentoring.com .mx
Archivo index.jsp:

<br>

<span class="videos" align="left">
<a href="javascript:desplegar ('videos');">
<img border="0" src="http://icursos.net/cursos/ServletsJSPs/Leccion14/videos.gif">
</a>
</span>
<span id="videos" class="ocultar_menu">

<ul>
<li><%@include file="pages/video1.html" %></li>
</ul>
</span>
</body>
</html>

Archivo noticia1.html:

<B>Universida Java</B>
<A HREF="http://universidadjava.com" target="_blank">
para más detalles...</A>

Archivo noticia2.html:

<B>Cursos de Java</B> para desarrolladores profesionales en Global Mentoring

<A HREF="http://globalmentoring.com.mx" target="_blank">
para más detalles...</A>

Archivo video1.html:
<B>Video</B> Global Mentoring: <br/><br>
<iframe src="https://player.vimeo.com/video/200744227" width="640" height="360"

frameborder="0" webkitallowfullscreen mozallowfullscreen
allowfullscreen></iframe>

Archivo estilos.css:
.ver_menu {
display: block;
}
.ocultar_menu {
display: none;
}

Archivo funciones.js:
function desplegar(categoria){
var menu = document.getElementById(categoria);
if(menu.className == "ver_menu"){
menu.className = "ocultar_menu";
}
else{
menu.className = "ver_menu";
}
}

Como este ejercicio hemos visto poner en práctica el concepto
de Inclusión Estática utilizando JSPs.
En el siguiente ejercicio veremos como manejar la inclusión

dinámica usando JSPs.


’

Crear un programa para practicar la inclusión dinámica
utilizando JSP’s. Al finalizar deberemos observar lo siguiente:


( )


Eliminamos el archivo index.html:



Agregamos un archivo recursoPublico.jsp al proyecto:

Agregamos un archivo recursoPublico.jsp al proyecto:

Agregamos un archivo recursoPrivado.jsp al proyecto:

Agregamos un archivo recursoPrivado.jsp al proyecto:

Archivo index.jsp:
<html>
<head>
<title>Ejemplo de Inclusión Dinámica</title>
</head>
<body>
<br>
<jsp:include page="WEB-INF/recursoPrivado.jsp">
<jsp:param name="colorFondo" value="yellow" />
</jsp:include>
<br>
<jsp:include page="recursoPublico.jsp" />
</body>
</html>

Archivo recursoPrivado.jsp:
<%
String colorFondo = request.getParameter("colorFondo");
if ( colorFondo == null || colorFondo.trim().equals("")){
colorFondo = "white"; //valor por default
}
%>
<body bgcolor="<%=colorFondo%>" >

Despliegue del contenido desde un JSP privado en WEB-INF
</body>

Archivo recursoPublico.jsp:
<br>
Inclusión de Contenido Dinámico

desde un JSP Público
<br>
Nombre de la aplicación: <%= request.getContextPath() %>

Como este ejercicio hemos visto como poner en práctica el
concepto de Inclusión Dinámica utilizando JSPs.
Vimos como a diferencia de la inclusión estática, cada JSP

(servlet compilado) se ejecuta de manera independiente, por lo
que es posible incluso enviar parámetros a los JSPs incluidos en
el JSP principal.


lección..
Vamos a estudiar el tema de Manejo de JavaBeans con JSPs.
Vamos a estudiar a continuación el tema de manejo de JavaBeans utilizando nuestros JSPs.
Los JSP’s nos van a permitir acceder a los JavaBeans que tengamos declarados en nuestra
aplicación web. Un JavaBean simplemente es una clase pura de Java que sigue ciertas reglas. Una
de las reglas es que debe de tener un constructor vacío y esa restricción es por lo siguiente, si
tenemos una clase que no tiene un constructor vacío entonces deberemos tener algún
constructor con cierto número de parámetros, por lo que cuando el JSP trate de acceder a este
JavaBean debe saber cuántos parámetros se le deben de especificar para poder crear una
estancia de objeto JavaBean, y esto implica mayor complejidad al momento de instanciar un
objeto Java.
Por ello, los JavaBeans requieren de un constructor vacío, para que no haya necesidad de indicar
cuales son los argumentos que se necesitan para poder instanciar una clase de un JavaBean.
Además de tener un constructor vacío, los JavaBeans deben tener atributos privados y por cada
uno de los atributos declarados debemos agregar su método get y set para cada atributo. Vamos
a ver más adelante que existen ciertas excepciones, por ejemplo, si únicamente queremos
acceder a la propiedad pero no tenemos intenciones de modificar la propiedad, entonces
podríamos tener únicamente su método get y viceversa, en dado caso que únicamente queramos
modificar la propiedad agregamos el método set respectivo y podemos omitir su método get.
Un JSP debe de utilizar el nombre de la propiedad del JavaBean. Indirectamente el JSP al colocar
el nombre de la propiedad se manda llamar el método get o set respectivo según indiquemos en
la acción que utilicemos en nuestro JSP. Vamos revisar más adelante como realizar este código.
Podemos observar los siguientes ejemplos, tenemos el nombre de la propiedad, el nombre de los métodos asociados get y set y el
código que estamos utilizando dentro del JSP.
Por ejemplo, si tenemos una propiedad llamada nombreUsuario podemos observar que su método get se debe de escribir como
sigue getNombreUsuario. Vamos a utilizar la notación de altas y bajas, o notación de camello, es decir la n se convierte en
mayúscula y la letra u también ser convierte a mayúscula, debido a que estamos separando cada palabra del nombre del método.
Esta es la notación de Java que debemos utilizar cuando creemos el método get y set respectivo de una propiedad.
Una vez que tenemos los métodos get y set dentro de la clase del JavaBean, dentro del JSP lo que tenemos que hacer es utilizar la
siguiente acción de los JSPs, escribiremos jsp: y dependiendo de la acción que queramos hacer será getProperty o setProperty.
Posteriormente indicamos el nombre de la propiedad a utilizar, (Ej. nombreUsuario) e indirectamente se ejecutará el nombre del
método asociado a la acción respectiva, ej. getNombreUsuario() y si estamos haciendo uso de la acción setProperty se manda a
llamar el método setNombreUsuario(). Por ello es que decimos que en el JSP vamos a utilizar el nombre de la propiedad e
indirectamente se va a mandar a llamar el método asociado dependiendo de la acción que estemos especificando.
Vamos a revisar algunos otros ejemplos. La propiedad eliminado es de tipo booleano y para las propiedades de tipo booleano en
lugar de tener un método get vamos a convertirlo por un método is, (isEliminado). El método set no cambia debido a que para
modificarlo se sigue utilizando la misma anotación (setEliminado) y en el código del JSP de igual manera no cambia, vamos a
utilizar su método get que indirectamente va a mandar a llamar el método is que es el de lectura, o el action de setProperty e
indicamos la propiedad y se manda llamar indirectamente el método setEliminado. De igual manera hay que notar que la
propiedad está en minúsculas y el método que se manda a llamar es setEliminado y la E comienza con mayúscula.
Ahora vamos a ver un caso interesante en el cual muchas veces podemos aprovecharlo para hacer nombres de métodos que no
necesariamente van a mapear a una propiedad de un JavaBean, ya que respetando la nomenclatura podemos mandar a llamar
métodos como podemos observar. La propiedad noTelefono, podemos crear métodos llamados getTelefono y setTelefono y las
acciones del JSP deben corresponder no al nombre de la propiedad, la puede incluso no existir, sino al nombre de los métodos
eliminando la palabra get o set y convirtiendo la primera letra en minúscula, con esto podrá acceder a métodos que incluso no
tengan mapeada una propiedad, sino posiblemente métodos que realicen cálculos dentro del JavaBean.
Y por ultimo, vemos otra anotación de una propiedad de un JavaBean, en este caso estamos utilizando la anotación que no es muy
común incluso no es recomendable, pero en ocasiones ya existe código creado de esta manera getCodigo_postal. Lo que tenemos
que hacer entonces es poner el nombre de la propiedad e indirectamente se va a mandar a llamar el método getCodigo_postal en
este orden si tenemos guion bajo ( _ ). Entonces no tenemos que hacer nada al respeto si no simplemente el único que se debe de
convertir en mayúsculas es la primera letra, por lo tanto el método que se manda a ejecutar es getCodigo_postal y la p sigue
siendo minúscula.
Vamos a revisar a continuación el tema de alcance de las variables en los JSPs.

Básicamente el alcance de una variable es la duración o tiempo de uso de una variable en una aplicación web.
Podemos observar que tenemos cuatro alcances o en inglés scope. Según hemos revisado anteriormente, hemos
utilizado el objeto request para agregar cierta información y también hemos utilizado el objeto session para
compartir información que puede durar más que un request, es decir, una sesión puede administrar varias peticiones
(request) y por lo tanto la información que almacenemos en una sesión dura más que el tiempo que si la
almacenáramos a nivel del objeto request.
Observamos en la figura que tenemos dos alcances más y estos son todos los alcances que tenemos para compartir
información entre los diferentes componentes ya sean Servlets o un JSPs.
Como podemos observar el alcance de page es el inferior. Este alcance únicamente va a durar durante el tiempo de
traducción de los JSPs pero ni siquiera va a durar durante el tiempo de la petición (request) de nuestra petición, por
lo tanto la información que esté almacenada en este alcance de page únicamente va a poder ser accedida en el JSP
que está haciendo la traducción respectiva en ese momento.
El siguiente alcance es request. Como podemos observar el alcance de request tiene mayor duración que el alcance
de page. Con el alcance de request la información que almacenemos va a existir durante todo el tiempo de nuestra
petición web, esto significa desde que el cliente inicia la petición hasta que el servidor regresa la respuesta a nuestro
cliente va a estar disponible en la aplicación web. Por lo tanto, el alcance de request tiene mayor duración que el
alcance de page.
El siguiente alcance que tenemos es el de session, podemos observar que la sesión va a durar más que request y
page. La información que almacenemos en una sesión nos va a permitir guardar datos entre diferentes peticiones y
así compartir información entre diferentes componentes web como pueden ser diferentes JSPs y distintos Servlets. El
alcance de request también nos va a permitir compartir información entre diferentes componentes JSPs y Servlets
pero únicamente durante el tiempo en que dura una petición, en cambio la sesión nos permite hacer algo similar
pero el tiempo que dura la información almacenada en una sesión es mayor y por lo tanto más componentes van a
poder hacer uso de la información que se almacene en una sesión.
Por último, tenemos el alcance de aplicación, esto es equivalente a manejar el contexto de ServletContext, este
concepto se maneja en el tema de Servlets, entonces lo que es para un servlet el alcance de ServletContext en un JSP
se llama application. Cada una de estas variables son variables implícitas que tenemos en un JSP, el alcance de la
aplicación es el mayor alcance que podemos tener y la información que almacenemos en ese alcance, por ejemplo
con el método setAtribute, va a durar durante todo el tiempo en que este nuestra aplicación esté arriba. Por ejemplo,
si estamos utilizando un servidor de aplicaciones y agregamos información a este alcance va a durar todo el tiempo
que el servidor este arriba y hasta que detengamos el servidor o que bajemos nuestra aplicación es cuando se va a
destruir la información que tengamos almacenada en el alcance application.
Por último, vamos a revisar el uso básico de los Java Beans desde los JSPs. Podemos utilizar las
siguientes acciones en los JSPs:
- Tenemos la acción de useBean, esto nos va a permitir acceder a un bean en un alcance
especificado. Podemos o no especificar el alcance, si no la especificamos dentro de nuestra
sintaxis del jsp:useBean, el alcance por default es de tipo page. En cambio si queremos indicar
alguno otro alcance tenemos que poner scope=request, session o application. La sintaxis que
vamos a utilizar es similar a esta <jsp:useBean id=”nombre” class=”paquete.NombreClase”/>.
Con esta sintaxis en pocas palabras es como si creáramos una nueva instancia y el nombreBean
es el nombre de nuestra variable y el paquete.NombreClase es el tipo de la clase que estamos
indicando para generar este nuevo objeto nombreBean.
- Posteriormente tenemos la acción de setProperty. Esta acción nos permite modificar una o
varias propiedades de un bean especificado. Para esta acción especificamos el nombre del bean
previamente definido con la acción jsp:useBean, posteriormente especificamos la propiedad a
modificar, seguido del valor del mismo. Ej. property=”nombreUsuario”, esto indirectamente va a
mandar a llamar el método setNombreUsuario del JavaBean respectivo.
- Por último tenemos la acción de getProperty. Esta acción nos permite acceder a una propiedad
del bean especificado. Utilizamos la acción jsp:getProperty, posteriormente indicamos el nombre
del bean nombreBean que vamos a utilizar, es decir, el nombre de la instancia declarada
previamente con la acción jsp:useBean. Posteriormente indicamos una propiedad a acceder, ej.
property=”nombreUsuario”, indirectamente se va a mandar a llamar el método
getNombreUsuario().
Estas son las acciones básicas que vamos a utilizar con los JavaBeans, existen varias
combinaciones que podemos utilizar al crear y utilizar los JavaBeans, por lo que vamos a ver a
continuación algunos ejemplos para ir detallando el uso básico de los JavaBeans en los JSPs.
Programación con Java Hibernate Framework

Struts Framework Datos de Contacto:HTML5 y CSS3

Crear un proyecto para poner en práctica el manejo de
JavaBeans con JSPs. Al finalizar deberemos observar lo
siguiente:

Creamos el proyecto:

Creamos el proyecto:

Borramos el archivo index.html:

Creamos un archivo jsp:










Creamos un archivo java:

Creamos un archivo java:

<html>
<head>
<title>Ejemplo JavaBeans</title>
</head>
<body>
<h1>Ejemplo de JavaBeans</h1>

<a href="setterJsp.jsp">Modificar valores del JavaBean</a>
<br>

<a href="getterJsp.jsp">Leer valores del JavaBean</a>
<br>
<br>



Formulario 1:
<br>
<form name="form1" action="setterParamJsp.jsp">
Base:<input type="text" name="baseParam">

<br>
Altura: <input type="text" name="alturaParam">
<input type="submit" value="Enviar" >
</form>
<br>
Formulario 2:
<br>
<form name="form2" action="setterAllParamsJsp.jsp">
Base: <input type="text" name="base" >
<br>
Altura: <input type="text" name="altura" >
</form>
</body>
</html>

Archivo getterJsp.jsp: Dar click para ir al código
<html>
<head>
<title>JSP que lee valores del JavaBean</title>
</head>
<body>
<h1>JSP que lee valores del JavaBean</h1>

<jsp:useBean id="rectangulo"
class="beans.Rectangulo" scope="session" />


<br>
Valor base: <jsp:getProperty name="rectangulo" property="base" />
<br>
Valor altura: <jsp:getProperty name="rectangulo" property="altura" />
<br>

Valor área: <jsp:getProperty name="rectangulo" property="area" />
<br>
<br>
<a href="index.jsp">Regresar al Inicio</a>
</body>
</html>
Archivo setterJsp.jsp: Dar click para ir al código
<html>
<head>
<title>JSP que modifica a un JavaBean</title>
</head>
<body>
<h1>JSP que modifica a un JavaBean</h1>



<jsp:useBean id="rectangulo"
class="beans.Rectangulo" scope="session" />
Modificamos los atributos:

<br>
<br>
<%
//Valores en codigo duro
int baseValor = 5;
int alturaValor = 10;
%>
<jsp:setProperty name="rectangulo" property="base"
value="<%=baseValor%>" />
Archivo setterJsp.jsp: Dar click para ir al código
Nuevo valor base: <%=baseValor%>
<br>
<jsp:setProperty name="rectangulo" property="altura"

value="<%= alturaValor%>" />
Nuevo valor altura: <%= alturaValor%>
<br>
<br>
</body>
</html>

Archivo setterParamJsp.jsp: Dar click para ir al código
<html>
<head>
<title>JSP que modifica a un JavaBean por parámetros</title>
</head>
<body>
<h1>JSP que modifica a un JavaBean por parámetros</h1>


<jsp:useBean id="rectangulo" class="beans.Rectangulo"
scope="session" />
Modificación de los atributos:

<br>
<br>
<jsp:setProperty name="rectangulo"
property="base" param="baseParam" />

Archivo setterParamJsp.jsp: Dar click para ir al código
Nuevo valor base: <%= request.getParameter("baseParam")%>
<br>
<jsp:setProperty name="rectangulo"
property="altura" param="alturaParam" />
Nuevo valor altura:<%= request.getParameter("alturaParam")%>
<br>
<br>
</body>
</html>

Archivo setterAllParamsJsp.jsp: Dar click para ir al código
<html>
<head>
<title>JSP que modifica a un JavaBean por Parámetros</title>
</head>
<body>
<h1>JSP que modifica a un JavaBean por Parámetros</h1>


<jsp:useBean id="rectangulo" class="beans.Rectangulo"
scope="session" />

<jsp:setProperty name="rectangulo" property="*" />
Se modificaron todos los atributos:

<br>
<br>
Nuevo valor base: <%= request.getParameter("base")%>

<br>
Nuevo valor altura: <%= request.getParameter("altura")%>
<br>
<br>
</body>
</html>
Archivo Rectangulo.java: Dar click para ir al código
package beans;
public class Rectangulo {
private int base;
private int altura;
public int getAltura() {

return altura;
}
public void setAltura(int altura) {
this.altura = altura;
}
public int getBase() {

return base;
}
public void setBase(int base) {

this.base = base;
}
/**
* Agregamos un metodo que no mapea con ninguna propiedad sino que es el
* resultado de un calculo
*
* @return int valor del area
*/
public int getArea() {
return this.base * this.altura;
}
}
• Probar con cada una de las opciones del proyecto.
• Verificar paso a paso (modo debug) cada una de las opciones para que
aclarar cualquier flujo o detalle que hiciera falta.

• Con este ejercicio hemos visto el uso de los JavaBeans y su integración
con los JSPs.
• Este concepto aunque parece simple, será uno de los más utilizados a lo
largo de nuestras aplicaciones Web, no solamente con la tecnología de
Servlets y JSPs, sino prácticamente con cualquier framework Web.

’

CURSO DE SERVLETS Y JSP'S
Hola, te saluda nuevamente Ubaldo Acosta. Espero que estés listo para
comenzar con esta lección..
Vamos a estudiar el tema de Expression Language con JSP’s.
A continuación vamos a revisar el concepto de Expression Language (EL).
El objetivo de este lenguaje es que nos permita simplificar la información que estamos desplegando en los JSPs.
Normalmente este tipo de despliegue de información nos apoyaremos de los JavaBeans, según ya hemos visto, para
desplegar información almacenada en una aplicación Web.
En la lamina podemos revisar una comparativa entre la sintaxis utilizando las acciones de los JavaBeans y la sintaxis de
Expression Language.
Como podemos observar la sintaxis de los JavaBeans según hemos visto tenemos que declarar el nombre del bean que
vamos a utilizar dentro del JSP y posteriormente acceder a la propiedad, esta sintaxis puede ser muy extensa si es que
estamos haciendo mucho código para despliegue de propiedades ejemplo:
<jsp:useBean id=”nombreBean” class=”ClaseBean”/>

<jsp:getProperty name=”nombreBean” propiedad=”nombre Propiedad”/>
En cambio, con la sintaxis de Expression Language únicamente debemos de especificar el nombre del bean que vamos
a utilizar y el nombre de la propiedad a la cual queremos acceder, la forma más común de hacerlo es:
${nombreBean.nombrePropiedad}, pero también tenemos otra forma ${nombreBean[“nombrePropiedad”]}.
Internamente el lenguaje de expresión (EL) lo que hace es almacenar sus atributos o beans como si fuera un mapa,
entonces por ello podemos especificar el nombre de la propiedad o también podemos especificarlo entre corchetes,
ya que puede funcionar como un índice para acceder al mapa y posteriormente recuperar el valor respectivo de la
propiedad.
Cualquiera de estas dos anotaciones nos va a permitir acceder a los JavaBean y a las propiedades de los JavaBean
utilizando Expression Language y cómo podemos observar se simplifica bastante la sintaxis si es que la comparamos
con el concepto de las acciones de los JavaBeans.
Vamos a revisar a continuación algunas de las características del lenguaje de expresión de los JSPs.
Un detalle importante para hacer uso de este lenguaje es que los objetos JavaBeans a utilizar ya deben
de estar agregados previamente en algún alcance, por ejemplo, utilizando el método setAttribute() en
un Servlet. Si recordamos los alcances que tenemos en una aplicación web tenemos los alcances de
page, resquest, session y application.
Entonces, para que este lenguaje de Expression Language pueda acceder a un atributo que hayamos
agregado a nuestra aplicación web debe de estar previamente ya almacenado en cualquiera de estos
alcances.
Otra característica de este lenguaje es que la notación es muy simplificada según vimos en la lámina
anterior, se simplifica a una sola línea de código, perso solo nos permite leer información más no
modificarla en nuestros Java Beans.
El Expression Language nos va a permitir acceder a las propiedades de un JavaBean de manera anidada,
por ejemplo, supongamos que tenemos una clase Alumno y a su vez tiene una propiedad que es otra
clase llamada Dirección y esta clase Dirección tiene como atributo “calle”. Entonces, podemos observar
que ya no tenemos que instanciar cada uno de estos objetos para ir recuperando la información, si no
que de manera anidada y por medio de la notación de punto, podemos acceder a nuestro JavaBean
llamado alumno, posteriormente con este atributo se manda a llamar el método getDireccion(), el cual
regresa un objeto de tipo Dirección y finalmente se manda llamar el método getCalle(). Vamos a revisar
más adelante algunos ejercicios para poder entender a más detalle esta notación anidada.
Continuando con las características de este lenguaje, podemos acceder a propiedades que están en una colección
o en un arreglo. Según hemos comentado, simplemente con el nombre del bean que queremos acceder
${listaPersonas[índice/llave ]} y entre llaves especificamos el índice de la colección a la cual queremos acceder o
la llave.
Por ejemplo, si es que el atributo es un mapa, esta notación nos va a permitir acceder de manera muy simple a
los elementos que tengamos en una colección. Sin embargo no es posible iterar los elementos. Si queremos iterar
cada uno de los elementos que tengamos en una colección debemos que utilizar JSTL (JSP Standard Tag Library) el
cual estudiaremos más adelante.
Otra característica que tenemos respecto al Expression Languaje es que el despliegue de la información se hace
una conversión al tipo especificado de manera automática. 55 4573 8370
Otra característica es que se maneja de manera automática los valores nulos o vacíos convirtiéndolos
simplemente en cadena vacía. Esto nos permite de alguna manera simplificar el manejo de excepciones utilizando
EL, el detalle con esto es que si existe alguna excepción por ejemplo por un nullPointerExcepcion el JSP no nos va
a mostrar esta excepción en nuestra pantalla, si no que ese mensaje únicamente se va a mandar a la salida
estándar y no se desplegará en el navegador web. Entonces esta característica puede facilitar el despliegue de
información pero también podría ocultar detalles importantes respecto al manejo de excepciones.
Otra característica es que este mismo lenguaje tiene un conjunto de operadores básicos para hacer operaciones
simples directamente. Por ejemplo la sintaxis ${3+2-1} internamente se realiza la evaluación de la expresión y nos
da un resultado que es finalmente lo que se despliega. Esto a final de cuentas es equivalente a tener un
out.println y va a desplegar la información contenida dentro de esta expresión evaluada. También algunas
conversiones ocurren de manera automática, por ejemplo ${ “x”>”y” } el valor que tenga X y el valor que tengas
Y se convierten a tipos enteros y se hace una comparación utilizando los elementos X y Y. Otro ejemplo es ${ 3>=
10/2 } de igual manera esta expresión se evalúa y es equivalente a tener la sintaxis del método out.print.
El lenguaje de Expression Language nos permite acceder a algunos objetos implícitos, por ejemplo uno de ellos es el objeto cookie ${
cookie.nombreCookie.value } de manera automática ya tenemos disponible este objeto y podemos acceder directamente al objeto para
empezar a solicitar cookies u objetos cookies, simplificando bastante la sintaxis.
Uno de los objetos más importantes en JSPs es el objeto de pageContext. Este objeto contiene toda la información necesaria que requiere
un JSP. Este objeto pageContext contiene la mayoría de los objetos implícitos que utiliza un JSP, en solo mostramos como ejemplo
${pageContext.session.id} para acceder al objeto http session y cómo podemos obtener el identificador de nuestra sesión (JSession), pero
existen muchas más variables que se pueden acceder al revisar el API de los JSPs.
También vamos a poder acceder a los parámetros que recibamos desde un formulario o desde una petición get o post. Para poder acceder
a los parámetros de una petición HTTP podemos utilizar la variable implícita param o utilizar la variable paramValues, por ejemplo la
sintaxis ${param.nombre}.
También podemos acceder a los cabeceros HTTP por medio de las variables implícitas header o headerValues. Como ejemplo podemos
usar la sintaxis ${header[“user-agent“]}. Y según hemos comentado también tenemos el objeto cookie ${cookie.nombreCookie.value}
con el cual vamos a poder acceder directamente a las cookies que tengamos almacenadas en nuestro navegador web y simplemente
poniendo el nombre de la cookie podemos acceder posteriormente al valor de la cookie respectiva.
Por último observamos que podemos acceder a los atributos que tengamos almacenados en nuestra aplicación web por medio de los
objetos pageScope, requestScope, sessionScope o applicationScope. Según hemos comentado anteriormente a diferencia del uso de
pageContext.session nos va a regresar es el objeto http session, por medio del cual podemos acceder a los atributos pero del objeto
session y no a los atributos que hemos agregado en el alcance de session. Para poder acceder a los atributos que hemos agregado en el
alcance de sesión podemos utilizar el objeto sessionScope, por ejemplo si hemos agregado a la sesión un objeto llamado rectángulo
podemos utilizar dos sintaxis una es especificando ${sessionScope.rectangulo.area} que estamos buscando este objeto en el alcance de
sessionScope y posteriormente podemos acceder a la propiedad respectiva de este JavaBean, pero también podemos utilizar la siguiente
notación ${rectangulo.area}, en esta notación especificamos únicamente el nombre del JavaBean y posteriormente accedemos a la
propiedad respectiva. Si no especificamos el alcance lo que va hacer es primero revisar si es que ya existe una variable llamada rectángulo
en el alcance de pageScope, si no la encuentra aquí se sigue con los siguientes alcances, resquestScope, sessionScope y applicationScope
en ese orden. Si no se encuentra en ninguno de ellos el objeto sería nulo, pero según hemos comentado en Expression Language nos va a
permitir manejar el concepto de nulos y nos va a desplegar simplemente una cadena vacía.
¿Qué sucede si este objeto se encuentra en dos alcances, por ejemplo pageScope y en resquestScope? Lo que sucede es que va a tomar el
primero de ellos según el orden mencionado. El primer objeto en orden de los alcances mencionados que encuentre es el objeto que se va
a utilizar. A continuación vamos a revisar algunos ejercicios para poner en práctica el concepto de Expression Language utilizando JSPs.
A continuación te presentamos nuestro listado de cursos:

Datos de Contacto:

’
Por el experto: Ing. Ubaldo Acosta
’
Crear un proyecto Web para poner en práctica el concepto de
Expression Language. Al finalizar deberemos observar lo
siguiente:
’
Creamos un nuevo proyecto Web, como sigue:
’
( )
Creamos un nuevo proyecto Web, como sigue:
’

Creamos el archivo index.jsp:

’
Creamos el archivo accesoJavaBeans.jsp:

Creamos el archivo accesoJavaBeans.jsp:
’
Creamos el archivo variablesImplicitas.jsp:

Creamos el archivo variablesImplicitas.jsp:
’
Creamos el archivo Rectangulo.java:
’
’
<html>
<head>
<title>Ejemplo Expression Language</title>
</head>
<body>
<h1>Ejemplo de Expression Language</h1>
<br>
<a href="variablesImplicitas.jsp?usuario=juan">Objetos implícitos con EL</a>
<br>
<br>


Formulario HTML:
<br>
<form name="form1" action="accesoJavaBeans.jsp">
Base:<input type="text" name="base" />
<br>
Altura:<input type="text" name="altura" />
<input type="submit" value="Enviar" />
</form>
</body>
</html>
Archivo accesoJavaBeans.jsp: Dar click para ir al código
<html>
<head>
<title>Acceso a JavaBeans</title>
</head>
<body>
<h1>Acceso a JavaBeans</h1>
<jsp:useBean id="rectangulo" class="beans.Rectangulo" />


<jsp:setProperty name="rectangulo" property="*" />
<br>
Valor base: ${rectangulo.base}
<br>
Valor altura: ${rectangulo.altura}
<br>
Valor Area: ${rectangulo.area}
<br>
Calculo del Area: ${rectangulo.base*rectangulo.altura}
<br>
<br>
</body>
</html>
Archivo variablesImplicitas.jsp: Dar click para ir al código
<html>
<head>
<title>El y Variables Implicitas</title>
</head>
<body>
<h1>EL y Variables Implicitas</h1>
<ul>
<li>Nombre Aplicación: ${pageContext.request.contextPath}</li>
<li>Navegador del Cliente: ${ header["User-Agent"] }
<li>Id Session: ${cookie.JSESSIONID.value}</li>
<li>Web Server: ${pageContext.servletContext.serverInfo}
<li>Valor Parámetro Usuario: ${param["usuario"]}</li>
</ul>
<br>
<br>
</body>
</html>
package beans;

private int base = 5;
private int altura = 10;

return altura;
}

}

return base;
}

this.base = base;
}
/**
* Agregamos un metodo que no mapea con ninguna propiedad
* sino que es el resultado de un calculo
*/
public int getArea(){
}

’
’
Con este ejercicio hemos puesto en práctica el uso de
Expression Language, y vimos además como podemos
combinar el concepto de JavaBeans y EL para acceder más
fácilmente a las propiedades de nuestros JavaBeans desde los
JSPs. Esto nos simplificará mucho la sintaxis de los JSPs.
’
’
’
lección.
Vamos a estudiar una el tema de JSP Standard Tag Library, también conocido como JSTL.
En esta lección vamos a revisar el concepto de JSTL.
JSTL significa JavaServer Pages Standard Tag Library, esta es una librería de los JSPs
que extiende la funcionalidad básica de los mismos, agregando principalmente las
siguientes librerías: core, xml, sql y fmt.
La librería de core nos va a permitir leer y manipular datos así como iterar y agregar
condiciones y otras funcionalidades básicas.
La librería de xml permite la manipulación y transformación de documentos xml.
La librería de sql tiene tags que nos van a permitir tanto ejecutar consultas a una
base de datos así como crear conexiones a las mismas.
Finalmente la librería fmt nos va a permitir dar formato a las cadenas que estemos
manipulando para convertirlas por ejemplo de cadena a número o fecha. Incluso
esta librería nos permite apoyarnos de los conceptos como es internacionalización
o en inglés locale.
En esta lección estudiaremos algunos de estos tags para tener mayor conocimiento
de cómo podemos extender la funcionalidad básica de los JSP utilizando JSTL.
Para poder utilizar las librerías de JSTL en nuestra aplicación web en caso que usemos un servidor
como Glassfish ya cuenta con las librerías JSTL, si por alguna razón no estuvieran en el servidor
debemos agregar el .jar de estándar.jar y jstl.jar al classpath, sin embargo con Glassfish este paso
no es necesario.
Posteriormente para poder utilizar las librerías dentro de un JSP debemos agregar la siguiente
directiva: <%@ taglib uri=”http://java.sun.com/jstl/core”prefix=”c”%>
Como podemos observar estamos utilizando la sintaxis de las directivas en los JSPs según vimos
anteriormente. En este caso el atributo uri=”http://java.sun.com/jstl/core” es un uri que se
resuelve de manera local en nuestro servidor web al agregar los jars (estándar.jar, jstl.jar), por lo
que al solicitar desde un JSP un taglib, lo que hace el web server es buscar dentro de estos jars
cualquier archivo con terminación .tld (tag library definition), por lo que esta uri no es algo que se
tenga que buscar o resolver en internet, sino que simplemente se va a buscar un uri idéntica
dentro de los jars que tenemos en nuestra aplicación web.
Si utilizamos archivos jspx, es decir un documento JSP, lo que tenemos que hacer es lo siguiente
dentro de nuestro elemento root, por ejemplo en este caso dentro del tag de html lo que
hacemos es especificar el namespace de nuestro tag library con elprefijo core y posteriormente el
uri que es exactamente el mismo que especificamos anteriormente <%@ taglib
uri=”http://java.sun.com/jstl/core”prefix=”c”%> y de igual manera el prefijo es el mismo que
estamos utilizando para nuestro namespace. Hay que recordar que nuestro namespace
únicamente es un prefijo de igual manera como lo estamos especificando en la notación clasica
”prefix=”c”.
Existen más detalles respecto a la configuración de JSTL pero de manera básica y para empezar a
utilizar esta tecnología con esto es suficiente.
Vamos a estudiar la librería de core de JSTL. Una vez que hayamos puesto en práctica la librería de core es más sencillo utilizar las demás librerías
que hemos comentado anteriormente.
Dentro de la librería de core de jstl tenemos varios tags que nos van a permitir desplegar información, veamos como podemos hacer esto:
Tenemos un prefijo llamado c para el tag de core, según especificamos en el JSP. Posteriormente especificamos el nombre del tag que vamos a
utilizar, en este caso es como si utilizáramos una función pero debido a que estamos utilizando JSPs en lugar de una función se le conoce como un
tag o etiqueta y posteriormente utilizamos ciertos atributos y valores para terminar de configurar estos tags, por ejemplo: <c:out
value=”${persona.nombre}”>.
Hay que recordar que el objetivo de un JSP es únicamente manipular tags o etiquetas y no manipular código de Java (aunque pueda realizar esta
tarea) por ello la combinación de Expression Language con JSTL es muy práctica y son de las mejores prácticas de las que vamos a estar hablando
en los siguientes ejercicios.
Para desplegar el valor de un JavaBean, por ejemplo la clase Persona,y queremos accedemos a la propiedad de nombre simplemente basta con
utilizar el tag de out y especificamos el valor que queremos desplegar a nuestro cliente, ej. ”${persona.nombre}”. Podríamos poner aquí una
variable estática o una variable en código duro, pero en este caso podemos observar que al combinar JSTL con Expression Language podemos
acceder al JavaBean que se encuentran en algún alcance que puede ser page, request, session o application según hemos comentado
anteriormente.
También tenemos etiquetas para crear y manipula variables, debido a que el Expression Language tiene esa limitante respecto a modificar valores
de los JavaBeans o crear JavaBeans. JSTL nos va a permitir crear ese tipo de variables con el tag de set. Podemos declarar una nueva variable y
especificar el valor de dicha variable con<c:set var=”nombre” value… y una vez que hemos creado la variable opcionalmente podemos declarar el
alcance de esta variable, en este caso estamos especificando el alcance de manera explícita scope=”page” pero si omitiéramos este atributo
scope=”page”/> sucedería que esta variable nombre se agrega de manera automática al alcance de page. Entonces con este tag vamos a cubrir la
limitante de expression Language para crear variables y también por ello es que vamos a poder omitir el uso de scriptles, utilizando código mucho
más fácil de mantener y de entender en un JSP.
Posteriormente también tenemos tags para manejar elementos condicionales, por ejemplo el tag de if si es que necesitamos manejar algún código
condicional, ej. <c:if test=”${ i > 0 }> o también el tag de choose, este es un tag muy similar al switch de java, y los casos del switch se pueden
poner con <c:when test=”a”>.
También tenemos etiquetas de iteración <c:forEach var=”persona” ítems=”{personas}>… para poder procesar los elementos de una lista. Cada
uno de estos elementos se van a ir iterando y almacenando en el objeto persona. Esto va a ser un nuevo complemento respecto al Expression
Language debido a que en un Expression Language no podemos iterar los elementos pero si podemos ir accediendo a cada uno de ellos de
manera individual, entonces combinaremos JSTL con Expression Language para poder acceder a los elementos de una colección.
Existen muchos más tags dentro del core de JSTL pero vamos a mencionar unos cuantos más.
Uno de los tags bastante útiles respecto a JSTL es el tag de import <c:import url=”recursoInternoExterno”>
en este caso la diferencia con un include que hemos comentado anteriormente con los JSPs es que los
includes únicamente están restringidos a elementos que están dentro de nuestra aplicación web, en
cambio este tag de import nos va a permitir incluir recursos internos o externos a nuestra aplicación web.
Por lo que podemos incluir formularios de otras aplicaciones web o incluso páginas completas de otras
aplicaciones. Esto nos va a permitir manipular nuestra aplicación de tal manera que el usuario no tenga
que cambiarse de aplicación para estar navegando en diferentes aplicaciones web.
También tenemos el tag de redirect <c:redirect url=”${nuevaUrl}”/> este caso es algo similar al send
redirect que hemos utilizado en los Servlets, pero en este caso es un tag que nos va a permitir hacer una
manipulación más sencilla del redirect. Únicamente lo que vamos a especificar es la nueva URL, que puede
estar también de igual manera dentro de nuestra aplicación o en una aplicación externa a la nuestra.
Y finalmente tenemos el tag de manejo de parámetros, debido a que podemos incluir recursos de manera
dinámica podríamos necesitar de enviar cierta información a estos recursos externos y debido a que no
podemos proporcionar parámetros de manera dinámica en este url, vamos a poder combinar el manejo
del tag de import y enviar la información de los parámetros por medio del tag de param, ej. <c:param
name=”nombre” value = ”${param.select}”/> especificando el nombre del parámetro y el valor del
mismo, incluso podemos observar cómo podemos combinar de nueva cuenta Expression Language para
poder acceder a otros parámetros que estemos recibiendo y posteriormente propagarlos a otro
componente JSP.
Estos son simplemente alguno de los ejemplos de tags que podemos utilizar con JSTL. A continuación
vamos a crear algunos ejemplos para poner en práctica el uso de JSTL combinándolos con nuestros JSPs.
Programación con Java Hibernate Framework

Datos de Contacto:

Crear un ejercicio para poner en práctica el uso de JSTL con
JSPs. Al finalizar deberemos observar lo siguiente:


( )

( )

( )



Creamos el archivo jstlCore.jsp:

Creamos el archivo beansJSTL.jspx:



Creamos el archivo ListaRectangulos.java:

Archivo index.jsp:
<html>
<head>
<title>Ejemplo de JSTL</title>
</head>
<body>
<h1>Ejemplo de JSTL</h1>
<br>

<a href="jstlCore.jsp?opcion=1">Ir al JSP de JSTL Core</a>
<br>
<br>

<a href="beansJSTL.jspx">Link al JSP de JavaBeans y JSTL</a>
</body>
</html>

Archivo jstlCore.jsp:

<%@taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<html>
<head>
<title>JSTL Core</title>
</head>
<body>
<h1>JSTL Core</h1>


<c:set var="nombre" value="Ernesto" />
Variable nombre: <c:out value="${nombre}" />
<br>
<br>
Variable con código html:

<c:out value="<h1>Hola</h1>" escapeXml="true" />
<br>
<br>


<c:set var="bandera" value="true" />
<c:if test="${bandera}" >

La bandera es verdadera
</c:if>
<br>

<c:if test="${param.opcion != null}">
<c:choose>
<c:when test="${param.opcion == 1}">
<br>
Opcion 1 proporcionada
<br>
</c:when>
<c:when test="${param.opcion == 2}">
<br>
Opcion 2 proporcionada
<br>
</c:when>
<c:otherwise>
<br>
Opcion proporcionada desconocida: ${param.opcion}
<br>
</c:otherwise>
</c:choose>
</c:if>

<%
//Uso de Scriptlet
//Craemos el arreglo con un scriplet (aunque no es buena practica)
String[] nombres = {"Claudia", "Pedro", "Carlos", "Ana"};
//Compartimos el arreglo de nombres
//en el alcance (scope) de request
request.setAttribute("nombres", nombres);
%>
<br>
Lista de Nombres en el arreglo:
<br>
<ul>
<c:forEach varStatus="status" var="persona" items="${nombres}">
<li>${status.count} - Nombre: ${persona}</li>
</c:forEach>
</ul>
<br>
</body>
</html>

Archivo beansJSTL.jspx:
<?xml version="1.0" encoding="UTF-8"?>
<jsp:root
xmlns:c="http://java.sun.com/jsp/jstl/core"
xmlns:jsp="http://java.sun.com/JSP/Page"
version="2.1">
<jsp:directive.page contentType="text/html" pageEncoding="UTF-8"/>

<head>
<title>JavaBeans y JSTL</title>
</head>
<body>
<h1>Iterando una lista de JavaBeans de tipo Rectangulo</h1>


<jsp:useBean id="rec1" class="beans.Rectangulo" >
<c:set target="${rec1}" property="base" value="2" />
<c:set target="${rec1}" property="altura" value="4" />
</jsp:useBean>
<jsp:useBean id="rec2" class="beans.Rectangulo" >

<c:set target="${rec2}" property="base" value="3" />
<c:set target="${rec2}" property="altura" value="5" />
</jsp:useBean>

Archivo beansJSTL.jspx:

<jsp:useBean id="rectangulos" class="beans.ListaRectangulos">
<c:set target="${rectangulos}" property="rectangulo"
value="${rec1}" />
<c:set target="${rectangulos}" property="rectangulo"

value="${rec2}" />
</jsp:useBean>


<ul>
<c:forEach varStatus="status" var="rectangulo"
items="${rectangulos.lista}" >
<li>
Rectangulo ${status.count} -
Base: ${rectangulo.base}
Altura: ${rectangulo.altura}
</li>
</c:forEach>
</ul>
<br/>
</body>
</jsp:root>

Archivo Rectangulo.java:
package beans;
private int base;
private int altura;

return altura;
}

}

return base;
}

this.base = base;
}
public int getArea(){

}
} www.gl obal mentoring.com .mx

Archivo ListaRectangulos.java:
package beans;
import java.util.ArrayList;
import java.util.List;
/**
* Clase para generar un JavaBean de la lista de rectangulos
* y que se pueda usar con jsp:useBean desde un JSP
* @author Ubaldo
*/
public class ListaRectangulos {
//Atributo que almacenará los objetos rectangulos
private List<Rectangulo> lista = new ArrayList<>();
/**
* Este método nos permite simular una propuedad llamada
* "rectangulo" desde la accion jsp:setProperty en un JSP
* @param r
*/
public void setRectangulo(Rectangulo r){
this.lista.add( r );
}
public List<Rectangulo> getLista() {

return lista;
}
public void setLista(List<Rectangulo> lista) {

this.lista = lista;
}



Ahora pasamos un parámetro y vemos el resultado:

• Con este ejercicio hemos puesto en práctica el uso de JSTL,
tanto en archivos jsp como jspx.
• Observamos como debemos configurar nuestros JSPs para

hacer uso de esta librería.
• Y finalmente vimos cómo combinando JSTL con EL tenemos

un código más limpio y más fácil de mantener en nuestros
JSPs.

’

Vamos a estudiar el tema de patrón de diseño Model View Controller, también conocido como
MVC.
En esta lección vamos a revisar los conceptos del patrón de diseño en Modelo-Vista-
Controlador, también conocido como MVC.
Un patrón de diseño permiten solucionar problemas comunes que se presentan al

momento de crear aplicaciones, y en particular en aplicaciones Web nos interesa separar
la vista de los datos (modelo) y unirlos por medio de un componente que hace la vez de
controlador.
Según hemos estudiado hasta el momento los Servlets están enfocados en controlar el
flujo de la aplicación y en este caso procesan las peticiones HTTP, así como utilizar los
JavaBean para almacenar información y finalmente redireccionar al JSP respectivo.
Los JSP’s están enfocados en desplegar la información de la aplicación Web, en este caso
la información es proveída por medio de los Servlets y la información que se comparte
entre esos componentes, es decir, entre los Servlets y JSPs suele manejarse con
JavaBeans.
En resumen el patrón de diseño MVC modelo-vista-controlador nos permite integrar a

los JSPs, Servlets y a los JavaBean en un solo modelo para poder interactuar y así crear
aplicaciones web cada vez más robustas y más fáciles de mantener.
Vamos a comentar algunos Frameworks que utilizan el patrón de diseño MVC.
El patrón de diseño MVC lo podemos implementar de manera manual utilizando JSPs y Servlets y con la ayuda del objeto
RequestDispatcher vamos a poder controlar el flujo de nuestra aplicación.
Existe varios Frameworks que implementan ya este patrón, un patrón de diseño es simplemente una guía, por lo tanto cada
uno de estos Frameworks tanto Struts, JavaServer Faces, Spring MVC, entre otros, únicamente siguen esta guía o
recomendaciones pero realmente no es una especificación que nos indique paso a paso como implementar este patrón, sino
simplemente es una serie de pasos genéricos con los cuales cada uno de estos Frameworks implementa según las mejores
prácticas desde el punto de vista de cada uno de estos Frameworks.
Por ejemplo en el caso del Framework de Struts es un framework de Apache, el cual utiliza JSPs como la Vista utilizando
también a su vez tags de Struts, posteriormente utiliza el concepto llamado ActionForm que de alguna manera sustituye a
los JavaBeans, siendo el modelo de nuestra aplicación y finalmente tenemos el concepto de Action, el cual cubre el rol del
controlador. Estos son simplemente algunos componentes de los que se manejan dentro del Frameworks de Struts.
JavaServer Faces es una tecnología definida por Sun Microsystems, en el cual se utilizan conceptos como son los mismos JSPs
pero utilizando tags de JSF, también vamos a utilizar el concepto de ManagedBean los cuales cubren el rol del controlador y
finalmente tenemos el concepto de JavaBeans para manejar el concepto de modelo aunque también cabe resaltar que los
ManagedBean pueden jugar el rol tanto de controlador como de modelo, entonces todo podría mezclarse en un solo bean y
se podría omitir el uso de los JavaBeans.
Por último mencionaremos el framework de Spring MVC. Este framework es una extensión de Spring, en el cual se utilizan
JSPs como parte la vista y se pueden utilizar los tags de Spring para robustecer estos JSPs. Posteriormente se utilizan clases
de Java, también conocidas como POJOs (Plain Old Java Objects) o clases puras de Java y se utilizan como controladores y
también se utilizan JavaBeans como parte del modelo.
Existen muchos frameworks más que implementan el patrón MVC utilizando el lenguaje Java, esto son tan solo algunos de
los más representativos y como hemos comentado únicamente el patrón de diseño es una guía general y cada framework
define la especificación según las mejores prácticas desde el punto de vista de cada framework.
Vamos a comentar ahora la arquitectura MVC utilizando JSPs y Servlets.
Como podemos observar, el flujo inicia con un formulario HTML, esta información está almacenada en nuestro cliente y del lado derecho
vamos a tener el servidor. Una vez que nuestro cliente envía la petición del formulario hacia el servidor web, quien va a procesar esta
petición es un Servlet (controlador) y a pesar que en ejercicios anteriores hemos colocado a un JSP para manejar directamente
formularios, según hemos comentado, esta no es buena práctica. Por lo tanto, las peticiones las debe de procesar un Servlet controlador,
incluso podemos observar los números con los cuales vamos a ir siguiendo nuestro flujo (1 al 5).
Una vez que el Servlet controlador ha recibido la petición, una de sus tareas puede ser procesar los parámetros del formulario HTML si es
que aplica y una vez que ya tenemos procesado los parámetros del formulario, normalmente lo que hacemos es apoyarnos de JavaBeans
para almacenar o procesar la información de lógica de negocio o lógica de presentación de nuestra aplicación Web.
Ya que hemos creado y almacenado la información en nuestros JavaBeans, regresamos el control al Servlet y este Servlet controlador
puede colocar estos JavaBean en algún alcance para compartir información hacia un JSP. Los alcances pueden ser request, session o
application. Los Servlets no conocen el alcance de page, ya que eso pertenece sólo a los JSPs, por ello únicamente podemos manejar los 3
alcances mencionados.
Una vez que el Servlet Controlador ya ha colocado los JavaBeans en algún alcance, hace un redireccionamiento por medio del objeto
RequestDispatcher que vamos a ver más adelante. En este punto también cabe mencionar que el Servlet Controlador toma la decisión de
cual JSP se va a utilizar, por ejemplo podríamos tener un JSP1 un JSP2 un JSP3 etc. todo va a depender del flujo de la aplicación Web, pero
en este caso el Servlet Controlador es quien va a decidir cuál es Vista o JSP es el que se va a utilizar.
Finalmente, una vez que ya estamos dentro del JSP seleccionado, lo que va a hacer el JSP es jugar el rol de la Vista, esto implica que
únicamente va a mostrar la información que le compartió el Servlet. Los JSP’s en teoría no deberían de crear nuevos objetos Java, para ello
toda la información que va a utilizar el JSP ya debió de haber sido proporcionada por el Servlet controlador.
Una vez que el JSP genera el HTML utilizando la información de los JavaBeans que el Servlets le proporcionó, lo que hace es regresar el
contenido al cliente y en este momento es cuando se genera el Render de nuestra aplicación según el Content Type que hayamos
utilizado. Por ejemplo, puede ser una salida en HTML, PDF, Video, un archivo de Excel, etc. según hemos visto anteriormente.
El punto es que el JSP únicamente va a desplegar la información que recibió del Servlet y enviará esta información al cliente. Con esto
termina el flujo y si el cliente necesitara de realizar una nueva petición el proceso se repite nuevamente.
Por último, vamos a comentar el código necesario a grandes rasgos que utiliza un Servlet controlador.
Según revisamos en la teoría de los Servlets, para procesar un parámetro podemos utilizar la siguiente notación:
request.getParameter(“nombreParametro”); podemos hacer uso del objeto request y del método getParameter indicando el nombre del
parámetro que queremos procesar.
Posteriormente, podemos validar los parámetros para saber si la información que estamos recibiendo es correcta. Una vez que ya hemos
procesado los parámetros podemos realizar la lógica de presentación respectiva o la lógica de negocio utilizando JavaBeans. El resultado
de procesar esta información la vamos a almacenar en objetos de tipo JavaBean, en este caso simplemente estamos creando un nuevo
objeto de tipo Rectangulo Rectangulo rec = new Rectangulo(). Únicamente estamos creando un nuevo JavaBean para tratar de
ejemplificar que estos JavaBeans van a tener la información de nuestra aplicación Web.
Posteriormente, antes de redireccionar y seleccionar el JSP que vamos a utilizar, debemos de compartir el objeto que estamos creando en
algún alcance, en este caso estamos seleccionado el alcance de request, pero podemos usar los alcances de session o el de servlet context.
En este caso usaremos el método setAttribute del objeto request e indicamos el nombre del bean que se va a recuperar por parte del JSP.
Finalmente seleccionaremos el JSP que desplegará la información al cliente, por medio del código:
RequestDispatcher dispatcher = request.getRequestDispatcher(“resultado.jsp”); lo que hacemos es seleccionar el JSP apoyándonos del
objeto request y del método getRequestDispatcher, aquí lo que vamos hacer es proporcionar el JSP que estamos seleccionando como la
Vista que va a desplegar la información que estamos compartiendo por medio del objeto request y una vez que hemos seleccionado el JSP
que vamos a utilizar, lo asignamos a un objeto llamado RequestDispatcher. Este es el objeto que hemos venido comentando y que nos va
a permitir redireccionar hacia el JSP respectivo.
Finalmente usamos el método dispatcher.forward(request, response); lo que hacemos es utilizar el objeto dispatcher para ejecutar el
método forward. Aquí lo importante es que podemos observar que tenemos 2 argumentos, el argumento de request y el argumento de
response. Si recordamos, una vez que estamos procesando un método de un Servlet Controlador, por ejemplo si tenemos el método
doGet o el método doPost, estamos recibiendo como argumentos el objeto request y el objeto response, en pocas palabras lo que
estamos haciendo aquí es únicamente proporcionar los mismos objetos que ya hemos recibido en este Servlet, con la intención de que la
información que hemos compartido en nuestros objetos de request, session o application se sigan compartiendo con los demás elementos
que vamos a seguir utilizando. En este caso, por medio del método forward estamos proporcionando y enviando toda la información
necesaria al JSP para que no tenga ningún problema y pueda acceder a la información que hemos compartido previamente por medio del
Servlet. A continuación vamos hacer un ejercicio para poner en práctica el concepto del patrón de diseño MVC.

Datos de Contacto:

www.globalmentoring.com.mx
Crear un programa para el manejo del patrón de diseño MVC.
Al finalizar deberemos observar lo siguiente:
Diagrama que tomaremos como base para desarrollar el ejercicio:
Vamos a borrar el archivo index.html:
( )
( )
Vamos a crear la clase ServletControlador.java:
( )
Vamos a crear la clase ServletControlador.java:
Vamos a crear la clase Rectangulo.java:
( )
Vamos a crear la clase Rectangulo.java:
<html>
<head>
<title>Ejemplo MVC</title>
</head>
<body>
<h1>Ejemplo MVC</h1>
<br>
<a href="${pageContext.request.contextPath}/ServletControlador">
Link al servlet controlador que despliega las variables
</a>
</body>
</html>
Archivo desplegarVariables.jsp: Dar click para ir al código
<html>
<head>
<title>Despliegue de Variables</title>
</head>
<body>
<h1>Despliegue de Variables</h1>
Variable en alcance request:

${mensaje}
<br>
<br>
Variable en alcance session:

<br>
Rectangulo:
Base: ${rectangulo.base}
Altura: ${rectangulo.altura}
Area: ${rectangulo.area}
<br>
<br>
<a href="${pageContext.request.contextPath}/index.jsp">
Regresar al Inicio
</a>
</body>
</html>
Archivo ServletControlador.java: Dar click para ir al código
package controller;
import java.io.IOException;
import javax.servlet.*;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.*;
import model.Rectangulo;
@WebServlet(name = "ServletControlador", urlPatterns = {"/ServletControlador"})

public class ServletControlador extends HttpServlet {
@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
//1. En este caso no hay necesidad de procesar parametros
//2. Creamos los JavaBeans

Rectangulo rec = new Rectangulo(3, 6);
//3. Agregamos las variables en cierto alcance
request.setAttribute("mensaje", "Saludos desde el servlet");
HttpSession session = request.getSession();

session.setAttribute("rectangulo", rec);
//4. Redireccionamos
RequestDispatcher rd = request.getRequestDispatcher("vista/desplegarVariables.jsp");
//Se propagan los objetos request y response
//para que puedan ser utilizados por el JSP seleccionado
rd.forward(request, response);
//Ya no se necesita hacer nada mas despues del
//redireccionamiento, ya que el flujo continua
//con el JSP
}
} www.globalmentoring.com.mx
package model;

private int base;
private int altura;
public Rectangulo(){}
public Rectangulo(int base, int altura){
this.base = base;
}

return altura;
}

}

return base;
}

this.base = base;
}

}
} www.globalmentoring.com.mx
( )
• Con este ejercicio hemos puesto en práctica lo básico del
patrón de diseño MVC.
• Vimos como crear cada una de las clases y componentes que

forman parte del patrón, tanto el controlador (Servlet), el
modelo (JavaBean) y la vista (JSP). A continuación
crearemos otro ejercicio para ampliar más este concepto.
’
Crear un programa para el manejo básico de elementos de un

Este es el diagrama que tomaremos como base para desarrollar
el ejercicio:

Vamos a clonar el proyecto:

Vamos a clonar el proyecto:


( )

<html>
<head>
<title>Ejemplo MVC 2</title>
</head>
<body>
<h1>Ejemplo MVC 2</h1>
<div style="color:red"> ${mensaje} </div>
<br>
<a href="${pageContext.request.contextPath}/ServletControlador">
Link al servlet controlador sin parametros
</a>
<br><br>
<a href="${pageContext.request.contextPath}/ServletControlador?accion=agregaVariables">
Link al servlet controlador para agregar las variables
</a>
<br><br>
<a href="${pageContext.request.contextPath}/ServletControlador?accion=listarVariables">
Link al servlet controlador para listar las variables
</a>
</body>
</html>
Archivo alcanceVariables.jsp: Dar click para ir al código
<html>
<head>
<title>Alcance de Variables</title>
</head>
<body>
<h1>Alcance de Variables</h1>
<br>
Variable request:
Base: ${rectanguloRequest.base}
Altura: ${rectanguloRequest.altura}
Area: ${rectanguloRequest.area}
<br><br>
Variable session:
Base: ${rectanguloSession.base}
Altura: ${rectanguloSession.altura}
Area: ${rectanguloSession.area}
<br><br>
Variable application:
Base: ${rectanguloApplication.base}
Altura: ${rectanguloApplication.altura}
Area: ${rectanguloApplication.area}
<br><br>
<a href="${pageContext.request.contextPath}/index.jsp">
Regresar al inicio
</a>
</body>
</html>
package controller;
import java.io.IOException;
import javax.servlet.*;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.*;
import model.Rectangulo;
@WebServlet(name = "ServletControlador", urlPatterns = {"/ServletControlador"})

public class ServletControlador extends HttpServlet {
@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
//Procesamos la peticion
//1. Procesamos los parametros
String accion = request.getParameter("accion");
//2. Creamos los JavaBeans a compartir

Rectangulo recRequest = new Rectangulo(1, 2);
Rectangulo recSession = new Rectangulo(3, 4);
Rectangulo recApplication = new Rectangulo(5, 6);
if ("agregaVariables".equals(accion)) {
//3. Compartimos las variables en el alcance
//seleccionado
//Alcance request
request.setAttribute("rectanguloRequest", recRequest);

//Alcance session
HttpSession session = request.getSession();
session.setAttribute("rectanguloSession", recSession);
//Alcance application
ServletContext application = this.getServletContext();
application.setAttribute("rectanguloApplication", recApplication);
//Agregamos un mensaje
request.setAttribute("mensaje", "Las variables fueron agregadas");
//4. Redireccionamos al JSP seleccionado

request.getRequestDispatcher("index.jsp").forward(request, response);
} else if ("listarVariables".equals(accion)) {
//4. Unicamente redireccionamos, ya no agregamos variables
//y se desplegaran solamente las que sigan disponibles
//segun el alcance de cada variable
request.getRequestDispatcher("/WEB-INF/alcanceVariables.jsp").forward(request, response);
} else {
//4. Redireccionamos a la pagina de inicio
//agregamos un mensaje
request.setAttribute("mensaje", "Accion no proporcionada o desconocida");
request.getRequestDispatcher("index.jsp").forward(request, response);
//Esta linea no agregaria envia la informacion al JSP

//sino es una petición al navegador Web
//response.sendRedirect("index.jsp");
}
}
package model;

private int base;
private int altura;
public Rectangulo(){}
public Rectangulo(int base, int altura){
this.base = base;
}

return altura;
}

}

return base;
}

this.base = base;
}

}



• Con este ejercicio hemos puesto en combinado más temas
aplicando lo visto de alcance de variables y el patrón de
diseño MVC.
• Con esto concluimos este tema.

’

Proyecto: SGA – Sistema de Gestión de Alumnos
Documento de Especificación de Requerimientos
Del Sistema “SRS”
Global Mentoring
Sistema de Gestión de Alumnos (SGA)
Especificación de Requerimientos del Sistema

“SRS”
Realizado por
Ing. Ubaldo Acosta Soto
Versión 1.0
Historial de Revisión
Versión Autor Descripción
1.0 Ing. Ubaldo Acosta Soto Visión Inicial del Proyecto
Revisión del Documento

Versión Nombre de quien revisa Información de Contacto
1.0 Ing. Ubaldo Acosta Soto uacosta@globalmentoring.com.mx
Aprobación del Documento

Versión Nombre de quien aprueba Información de Contacto
Confidencial:
Ing. Ubaldo Acosta Soto – Global Mentoring Página 1 de 16 www.globalmentoring.com.mx
Tabla de Contenido
1. INTRODUCCIÓN 4
1.1 PROPÓSITO 4
1.2 ALCANCE 4
1.3 CONTEXTO DEL SISTEMA 4
1.4 ACTORES PRINCIPALES DEL PROCESO DE NEGOCIO 4
1.5 CÓMO ESTÁ ORGANIZADO ESTE DOCUMENTO 4
1.6 REGISTRO DE LOS CAMBIOS AL SGA 5
1.7 REFERENCIAS 5
2. RESTRICCIONES Y SUPOSICIONES 5
2.1 RESTRICCIONES EN EL PROCESO DE DESARROLLO Y DEL EQUIPO DE TRABAJO 5

2.2 RESTRICCIONES TECNOLÓGICAS 5
2.3 RESTRICCIONES EN LA LIBERACIÓN Y DESPLIEGUE DEL SISTEMA 6
3. MITIGACIÓN DE LOS RIESGOS 6
3.1 RIESGOS DE TECNOLOGÍA 6

3.2 RIESGOS DE HABILIDADES TÉCNICAS Y RECURSOS DE INFORMÁTICA 6
3.3 RIESGOS DE REQUERIMIENTO 7
3.4 RIESGOS POLÍTICOS 7
4. REQUERIMIENTOS FUNCIONALES 7
4.1 CARACTERÍSTICAS PRINCIPALES 7

4.1.1 CARACTERÍSTICAS ESENCIALES 7
4.1.2 CARACTERÍSTICAS DE ALTO VALOR 7
4.1.3 CARACTERÍSTICAS FUTURAS 7
4.2 ACTORES 8
4.2.1 ACTOR: CAPTURISTA 8
4.2.2 ACTOR: COORDINADOR 8
4.2.3 ACTOR: GENERADOR DE OFICIOS 8
4.2.4 ACTOR: ENCARGADO DEL SEGUIMIENTO 8
4.2.5 ACTOR: ADMINISTRADOR DEL SISTEMA 8
4.3 CASOS DE USO 8
4.4 APLICACIONES DE APOYO PARA EL SISTEMA 9
4.5 REQUERIMIENTOS EN CASOS DE USO DETALLADOS 10
5. REQUERIMIENTOS NO-FUNCIONALES 12
5.1.1 RENDIMIENTO 12
5.1.2 ESCALABILIDAD 12
Confidencial:
5.2 DISPONIBILIDAD 13
5.3 SEGURIDAD 13
5.4 USABILIDAD 13
5.5 ACCESIBILIDAD 14
5.6 REUSABILIDAD 14
5.7 MANTENIMIENTO 14
6. GLOSARIO DEL PROYECTO 14
6.1 ACRÓNIMOS Y ABREVIACIONES 14
Confidencial:
1. Introducción
1.1 Propósito
El propósito de este documento es definir los requerimientos específicos del Sistema de Gestión
de Alumnos (por sus siglas SGA), y detallar las especificaciones respecto a las características,
capacidades y atributos principales del sistema. Este documento debe ser leído por el equipo de
desarrollo del Sistema, para evaluar los beneficios y la viabilidad del proyecto, así como proveer
una estimación básica del tiempo y esfuerzo necesario para la construcción, pruebas, puesta en
marcha y mantenimiento del SGA. Este documento no describe como, cuando, o donde se
realizarán las actividades o quién las llevará a cabo, ya que se detallará en otros documentos.
1.2 Alcance
El SGA será una aplicación Web que permita gestionar los alumnos que participan en cursos en
Global Mentoring, a su vez tiene como uno de los principales objetivos ofrecer un seguimiento
claro y puntual de cada uno de los pendientes con cada uno de los alumnos, tales como venta de
cursos, pagos, envío de boletines, envío de mensajes SMS para noticias, entre otros.
Otra de las responsabilidades del SGA será permitir al usuario realizar búsquedas de alumnos,
cursos, pendientes con alumnos, agregar al sistema fotos y/o documentos digitalizados asociados
al alumno.
La seguridad de la información es un tema inherente, por lo que se restringirá a los usuarios
respecto a qué es lo que pueden consultar y/o modificar en el sistema.
1.3 Contexto del Sistema
El sistema inicialmente se utilizará en la intranet de Global Mentoring, y posteriormente se
publicará en internet, pudiendo ser accedida por varios tipos de usuarios, como pueden ser:
Administrador, Instructor, Alumno, Asistente, entre otros.
1.4 Actores principales del proceso de negocio
A continuación se muestra una lista de los principales actores que interactuarán en el proceso de
negocio del SGA. Cada rol puede tener varias personas que realicen la misma labor, y que
podrían proporcionar más detalle para la recolección de los requerimientos. Cada rol tiene un
actor principal, quien es el encargado de resolver las diferencias y es quien aprueba el
requerimiento final para este rol.
Rol Actor Principal Actores de Referencia
Coordinador Ubaldo Acosta N/A
Instructor Por definir N/A

Asistente Por definir N/A
Alumno Por definir N/A
1.5 Cómo está organizado este documento

Las siguientes secciones proveen todos los requerimientos del sistema, incluyendo los
requerimientos funcionales y no-funcionales. Este documento está completo, excepto cuando se
hace alguna anotación hacia un documento externo. No es necesario leer cada sección en orden
secuencial, pero es deseable para su pleno entendimiento.
Confidencial:
La sección 2 describe las restricciones y suposiciones del sistema. La sección 3 describe los
riesgos del proyecto y cómo pueden ser estos mitigados. La sección 4 describe los
requerimientos funcionales (FRs) del sistema. La mayoría de estos requerimientos existen por
que directamente soportan el proceso de negocio, otros existen debido a que soportan la correcta
operación del sistema, aunque no sean parte esencial del negocio. Todos los requerimientos
funcionales están descritos en términos de casos de uso. La sección 5 describe los requerimientos
no funcionales (NFRs) del sistema. La sección 6 provee un glosario del proyecto, que incluye
términos del negocio, como propios del sistema.
1.6 Registro de los cambios al SGA
Estos cambios se irán registrando dentro de los requerimientos ya sean funcionales o no
funcionales según se vayan solicitando cambios.
 No existen cambios
1.7 Referencias
 Documento de Visión del Proyecto para el SGA.
 Object-Oriented Analysis and Design Using UML, sun educational services, S00-226-V030
2. Restricciones y Suposiciones
La siguiente sección provee el detalle de lo que se explicó brevemente en el Documento de
Visión del Proyecto.
2.1 Restricciones en el Proceso de Desarrollo y del Equipo de Trabajo
 El tiempo asignado al desarrollo del proyecto, es definitivamente una de las mayores
restricciones, debido a que se depende del tiempo que los alumnos aporten al proyecto, se
establecerán planes de trabajo acorde a los tiempos de aporte de cada alumno.
 El equipo de trabajo está conformado por 1 Líder de Proyecto y varios programadores
(alumnos), los cuales no están asignados de tiempo completo a este proyecto, por lo que
existe el riesgo de atrasos en el desarrollo del sistema debido a las demás actividades y/o
prioridades de los alumnos en Global Mentoring.
2.2 Restricciones Tecnológicas
2.2.1 Restricciones de Software
El equipo de desarrollo de Global Mentoring ha decidido construir el SGA usando la tecnología
Java (Java SE JDK) debido a la portabilidad, flexibilidad y el costo de entre varios productos.
http://www.oracle.com/technetwork/es/java/javase/downloads/index.html
Inicialmente el sistema utilizará la tecnología más básica posible, utilizando solo JSP’s y
Servlets, y posteriormente se podrá utilizar la siguiente tecnología para el sistema.
El servidor Web será Glassfish. La seguridad en la aplicación será proporcionada por el
framework Spring Security. En la capa de presentación se utilizará JSF con primeFaces y AJAX
para Java. Los servicios de negocio se desarrollaran utilizando clases puras de java (POJOs) con
apoyo del framework de Spring. La capa de persistencia se utilizará el framework de JPA
implementado por Hibernate. La base de datos será MySql. El motor de reportes para la
aplicación será JasperReports y el IDE para el desarrollo del prototipo y el software final será
NetBeans. El sistema operativo del servidor Web será Windows, mismo que almacenará la base
de datos. Cabe mencionar que todo el software utilizado en el proyecto es software libre, a
excepción del sistema operativo.
 Glassfish – https://glassfish.java.net/download.html
 primeFaces – http://www.primefaces.org/
 Spring – https://spring.io/
Confidencial:
 Hibernate – http://www.hibernate.org/
 Netbeans - http://www.netbeans.org/
2.2.2 Restricciones de Hardware
El SGA es una aplicación Web con una base de datos centralizada, por lo que los equipos cliente
deberán estar conectados a la intranet de Global Mentoring. Posteriormente se liberará el sistema
en la plataforma de Google GAE en Internet.
El SGA ofrecerá la característica para subir archivos digitalizados, por lo que los usuarios
requerirán de un scanner para realizar esta labor.
El servidor donde será alojado el servidor Web y el servidor de base de datos, tendrá las
siguientes características:
 Procesador Intel i7
 8 Gb Ram
 1 Tb de espacio en disco duro
Por parte de los usuarios del sistema puede tener las siguientes características como mínimo:
 Procesador Intel i5 (o similar)
 4 Gb Ram
 Disco duro de 500 Gb, con mínimo el 50% libre
 Resolución del monitor 1024x768 píxeles
 Internet Explorer 10 o superior (o similar).
 Sistema Operativo Windows 7 o superior
 Acrobar Reader
 Microsoft Office o Open Office para el manejo de hojas de cálculo (version compatible
2007)
2.3 Restricciones en la Liberación y Despliegue del Sistema
Se utilizarán los servidores de la intranet de Global Mentoring (no dedicados) para albergar
inicialmente la aplicación, compartiendo los recursos con otras aplicaciones y con las otras bases
de datos en el mismo servidor.
El lenguaje de programación del SGA será Java, permitiendo con ello que el software sea
independiente de plataforma, robusto, y fácilmente mantenible.
3. Mitigación de los riesgos

3.1 Riesgos de Tecnología
 Debido a que el sistema utiliza una base de datos centralizada, la única manera de accederlo es
por la Intranet de Global Mentoring. Por lo que si no se tiene acceso a la red por algún motivo o
causa, no se podrá acceder a la información. Para mitigar este riesgo, se está planeando que la
aplicación se pueda subir a internet apoyándonos de la infraestructura de Google (GAE).
3.2 Riesgos de Habilidades Técnicas y Recursos de Informática
 Para mitigar el riesgo debido a que los módulos se realizan por los alumnos que asisten a clases,
se establecerán planes de trabajo, que independiente del programador, se puedan ir avanzando en
los módulos, con ayuda del control de versiones de Sub version.
Confidencial:
 El equipo de trabajo está conformado por 1 Líder de Proyecto y varios programadores

(alumnos), los cuales no están asignados de tiempo completo a este proyecto, por lo que existe el
riesgo de atrasos en el desarrollo del sistema debido a las demás actividades y/o prioridades de
los alumnos en Global Mentoring.
 En este proyecto es la primera vez que el equipo de trabajo hará una automatización de pruebas
de unidad del sistema. Esta práctica, al día de hoy es un estándar en el desarrollo de software, ya
que se puede ahorrar más de un 60% de los recursos humando asignados a probar el sistema y la
calidad del sistema a liberar puede incrementarse en un 70%. Para mitigar este riesgo será
necesario incrementar el tiempo de pruebas del sistema y tomar cursos y/o auto-capacitarse en
este rubro para reducir los tiempos lo más posible. Las tecnologías a utilizar son JUnit, Ant y
Maven, apoyándonos de Subversion.
3.3 Riesgos de Requerimiento
Para mitigar el riesgo de requerimientos, se debe restringir el tiempo de recolección de
requerimientos en la etapa de elaboración del proyecto. Si se recibieran más requerimientos, se
revisará en si entran en la versión actual, o en una versión posterior a la primera liberación, ya
que de lo contrario no se tendría una versión estable para liberar a producción.
3.4 Riesgos Políticos
No existen riesgos políticos para este proyecto.
4. Requerimientos Funcionales
Esta sección define los actores que utilizan el sistema que a su vez se relacionan con los procesos
de negocio principales, así como los casos de uso que el sistema provee para los actores
mencionados.
4.1 Características Principales
En esta sección, clasificaremos las características principales del SGA en tres tipos de categorías.
Características esenciales, de alto valor y futuras. En todos los casos la lista no es exhaustiva,
pero si incluye los procesos de negocio más importantes.
4.1.1 Características Esenciales
 El SGA será una aplicación Web con una base de datos centralizada capaz de mostrar la
información a los usuarios en cuanto sea capturada o modificada, es decir, en línea.
 El sistema deberá permitir la captura, modificación y asociación de todos los alumnos.
 El sistema deberá proporcionar mecanismos para dar un seguimiento claro y oportuno de cada
uno de los pendientes con los alumnos.
 El SGA deberá ofrecer reportes para explotar la información almacenada en la base de datos.
4.1.2 Características de Alto Valor
 El sistema permitirá agregar archivos digitalizados de los alumnos y sus anexos, tales como
Currículo Vitae, para tener disponible la información en el sistema.
 Uso de cámara web para tomar una foto de los alumnos y tenerla en sus registros.
4.1.3 Características futuras
 El sistema permitirá realizar consultas para encontrar la información de manera precisa y rápida.
En un principio con consultas esenciales, para posteriormente, en otra versión, agregar filtros de
búsqueda avanzados.
 El sistema deberá permitir administrar los usuarios del sistema.
 El sistema deberá administrar todos los catálogos del sistema.
 El sistema deberá simplificar su interfaz para manejar el concepto de web 2.0, incluyendo
AJAX.
Confidencial:
4.2 Actores
La lista que se muestra a continuación es una lista de los roles y/o sistemas que interactuarán con
el SGA.
Nombre del Actor Descripción

Administrador del Sistema Este es el rol equivalente de súper usuario.
Coordinador Persona encargada de administrar la información del sistema
Instructor Encargado de dar seguimiento a los pendientes con los alumnos en
relación a los cursos impartidos o por impartir.
Asistente Encargado de capturar la mayoría de la información relacionada con
los alumnos.
Alumno Consulta los cursos actuales y puede consultar el estatus de sus
pendientes en línea.
4.2.1 Actor: Administrador del Sistema

Este rol se encarga de administrar a los usuarios del sistema, y el rol que tendrán en el mismo.
Además este rol se encarga de todo lo relaciona con la administración de los catálogo e
información almacenada en el sistema.
Este rol tiene acceso a las bitácoras, reportes del sistema, entre otros.
4.2.2 Actor: Coordinador
Persona encargada de administrar la información del sistema.
Genera reportes del sistema.
Revisa pendientes o tareas y capturar información en el sistema.
Es SGA tendrá un sistema de bloqueo, es decir, se terminará la sesión del usuario al transcurrir
30 minutos de inactividad.
4.2.3 Actor: Instructor
Este rol se encarga de dar solución a los pendientes con los alumnos en la cuestión de cursos a
impartir o cursos impartidos.
Distribuye avisos y comunicados a los alumnos.
4.2.4 Actor: Asistente
Encargado de capturar la mayoría de la información relacionada con el alumno
Verificar que la información capturada es correcta
Captura los pendientes que se tenga para con los alumnos e indica el responsable para resolver
cada uno de los pendientes.
Distribuye avisos y comunicados de índole administrativa con los involucrados en el sistema y/o
alumnos.
4.2.5 Actor: Alumno
Consulta los cursos actuales y puede consultar el estatus de sus pendientes en línea.
4.3 Casos de Uso
La siguiente lista contiene los casos de uso del sistema. La prioridad se clasifica de la siguiente
manera:
 Esencial: E
Confidencial:
 Alto Valor: A
 Futuro: F
Nombre Caso Uso Prioridad Número Descripción

Gestiona Usuarios E 1 Módulo que permite administrar los usuarios
del sistema y el tipo de rol que tendrán.
Gestiona Alumnos E 2 Captura, modificación y asociación de todos
los alumnos registrados en Global Mentoring.
Incluyendo los cursos, e instructor que tiene
asignado por curso.
Gestiona Catálogos F 3 Captura, modificación de los catálogos tales
como Cursos, Localidades, entre otros.
Gestiona Pendientes F 4 Captura, modifica y respuesta de los
pendientes para con los alumnos o usuarios
internos del sistema.
Gestiona Seguimiento de Pendientes F 5 Consulta, modificación y asociación de todos
los pendientes. Sobre todo, cambio de estatus
y/o observaciones en los seguimientos a los
pendientes. Esto incluye al sistema de alertas,
ya sea por el mismo sistema o vía email.
Genera Reportes F 6 Módulo que permite hacer consultas en
pantalla y en algunos casos genera
impresiones de las mismas.
Nota: No se incluyen todos los casos de uso futuros, ya que el objetivo es solamente ejemplificar la metodología.
A continuación se muestra el Diagrama de Caso de Uso inicial para el SGA.
Confidencial:
Figura 1. Diagrama Inicial de Casos de Uso
4.4 Aplicaciones de Apoyo para el Sistema

No existen aplicaciones de apoyo en el sistema SGA.
4.5 Requerimientos en Casos de Uso Detallados
Cada requerimiento tiene un identificador único en la forma CU#-Req#. Un caso de uso puede
tener varios requerimientos asociados.
Código Req. Descripción del Requerimiento

E1-1 El sistema deberá permitir agregar o modificar los usuarios registrados en el sistema. La
eliminación está restringida, ya que en lugar de eliminar un registro, se cambiará un campo
que maneje el estatus (Campo “deleted”)
E1-2 El sistema deberá permitir asociar roles a cada uno de los usuarios. Ya que el manejo de la
seguridad en el sistema se manejará con roles.
E1-3 Los campos que deberá recolectar al registrar un nuevo usuario son:
 Nombre de la Persona:
 username (Este es el dato que se solicitará para iniciar sesión al sistema)
 password (Este es el dato que se solicitará para iniciar sesión al sistema)
 rol (Se deberá seleccionar de un menú de opciones)
 Fecha del sistema (solo es informativo, y solo se visualiza en la consulta y/o
modificación)
 Hora del Sistema (solo es informativo)
E1-5 Los campos que deberá recolectar al crear un nuevo rol son:
 Nombre rol
 Módulos asociados
Confidencial:

E1-6 Los campos que deberá recolectar para un nuevo modulo son:
 Nombre módulo
 Módulo padre (aplica solo si es un submenú)
 Visible (Se utiliza para saber si la opción del menú la visualiza el usuario)
E2-1 El sistema deberá permitir agregar o modificar los alumnos registrados en el sistema. La
eliminación está restringida, ya que en lugar de eliminar un registro, se cambiará un campo
que maneje el estatus (Campo “deleted”)
E2-2 El sistema deberá permitir asociar uno o varios cursos a un alumno
E2-3 Los datos que se deben capturar del alumno son:
 Nombre
 Apellido Paterno
 Apellido Materno
 Dirección (Calle, No. Exterior, No. Interior, Colonia, C.P., Municipio/Delegación,
Estado)
 Teléfonos
 Particular
 Oficina
 Celular
 E-mail (Debe permitir capturar varios e-mails)
 Cursos asignados
 Fecha del sistema (solo es informativo, y solo se visualiza en la consulta y/o
modificación, ya que en el alta se registran estos datos hasta que se guardan en la
BD)
 Hora del Sistema (solo es informativo)
E2-4 Los datos que se deben capturar por cada curso son:
 Nombre del curso
 Instructor
 Fecha de Inicio
 Fecha Término (si es que aplica)
 Ubicación
 Horario
 Precio
E2-5 Los datos que se deben capturar por instructor son:
 Nombre
 Apellido Paterno
 Apellido Materno
 Dirección (Calle, No. Exterior, No. Interior, Colonia, C.P., Municipio/Delegación,
Estado)
 Teléfonos
 Particular
 Oficina
 Celular
 E-mail (Debe permitir capturar varios e-mails)
F3-1 Caso de uso por definir

Confidencial:
E5-1 Caso de uso por definir
5. Requerimientos No-Funcionales
Los Requerimientos No Funcionales (por sus siglas en inglés, NFRs) se diferencian de los
Requerimientos Funcionales (por sus siglas en inglés, FRs) debido a que comienzan con el
número 100. Por lo tanto, el primer NFR para el caso de uso E1, tendrá el Código de
Requerimiento E1-101.
5.1.1 Rendimiento
Versión Actual
Código Req. Descripción Requerimiento
E1-101 Debido a que el SGA es una aplicación Web, los tiempos de respuesta deberán ser muy
reducidos (menor a 3 segundos en las consultas), ya que la velocidad de captura es esencial.
E1-102 Se tiene contemplado un acceso de 50 usuarios al día, y un volumen de 100 transacciones
diarias, esperando un incremento del 10% mensual
E1-103 El sistema deberá soportar como mínimo un total de 10 usuarios concurrentes en el sistema
(10 conexiones a base de datos activas)
E1-104 Para completar el registro un alumno, el rol de asistente no debe tardar más de 3 minutos en
hacer un registro completo de un registro
Versión Futura
E1-105 Inicialmente el sistema se usará únicamente en la Intranet de Global Mentoring.
Posteriormente se liberará una versión para internet con el soporte de la infraestructura de
Google GAE.
E1-106 El SGA en un futuro podría crecer a más de 100 usuarios al día, dependiendo del número de
alumnos y maestros que utilicen el sistema.
5.1.2 Escalabilidad
Versión Actual
E1-107 La capacidad de los registros de los oficios podría crecer a 150 registros por día,
dependiendo del uso y exactitud que el usuario almacene en el sistema, por ejemplo, si se
genera un registro de seguimiento por cada copia que se observa en los oficios.
Versión Futura
Confidencial:

E1-108 El sistema podría crecer a tener más de 50 usuarios concurrentes, dependiendo de las
dependencias que lo utilicen.
5.2 Disponibilidad
Versión Actual
E1-109 Debido a que es un sistema Web, por naturaleza debe tener una disponibilidad de 7 por 24
los 365 días del año, excepto por una hora de baja del servicio (para mantenimiento del
software, respaldo de datos, etc.), siendo aceptable una vez a la semana en horarios que no
afecte la operación, excepto en ocasiones de emergencia o extraordinarias, como puede ser
la falta de servicio de luz, falta de conexión a Internet o a la Intranet, entre otros.
Versión Futura
No existen requerimientos futuros para este rubro
5.3 Seguridad
Versión Actual
E1-110 El SGA deberá tener un mecanismo de autenticación basado en nombre de usuario y
contraseña para acceder a cualquier información del sistema
E1.111 El SGA deberá solicitar nuevamente el nombre de usuario y contraseña después de 30
minutos de inactividad
E1-112 El sistema tendrá un mecanismo de autorización a los datos del sistema, basado en roles,
además de asignación de permisos de acceso de cada uno de los módulos del sistema.
Además el menú del sistema se generará de manera dinámica, dependiendo de los permisos
que se hayan asignado a cierto rol por cada módulo.
E1-113 El sistema registrará cada una de las acciones que cada usuario del sistema ejecute, teniendo
una bitácora que permita auditorias en caso de problemas o aclaraciones
E1-114 El sistema manejará una auditoria de las tablas de base de datos más importantes, para tener
la historia de los registros, y saber cuando, qué y quién modificó los registros en caso de
problemas o aclaraciones
E1-115 Los principales roles de seguridad del sistema serán: Administrador del sistema,
Coordinador, Instructor, Asistente y Alumno.
Versión Futura
5.4 Usabilidad
Versión Actual
E1-116 El sistema deberá tener una interfaz de fácil uso e intuitiva.
Confidencial:
Versión Futura
E1-117 Se utilizarán frameworks como iceFaces para tener una interfaz con características web 2.0
5.5 Accesibilidad
Versión Actual
E1-118 El SGA deberá poder accederse desde cualquier computadora conectada a la Intranet de
Global Mentoring
Versión Futura
E1-119 El SGA deberá poder accederse desde cualquier computadora conectada a Internet
5.6 Reusabilidad
Versión Actual
E1-120 El sistema deberá utilizar todos los componentes generados y/o utilizados en proyectos
anteriores desarrollados por los participantes en el proyecto
Versión Futura
5.7 Mantenimiento
Las categorías de un problema de sistemas típicamente se dividen como se muestra a
continuación.
 Severidad 1, Fatal – El sistema complete no funciona y no puede ser utilizado para nada.
 Severidad 2, Error – Una parte crítica del sistema no funciona, y no se acepta otra
alternativa
 Severidad 3, Media – Un problema en el sistema requiere revisarse lo antes posible, para
evitar problemas. No es posible aplazar por mucho tiempo este punto.
 Severidad 4, Menor – El funcionamiento del sistema no afecta significativamente al
Usuario, y éste puede vivir con el problema por ahora.
 Severidad 5, Mejora – Es deseable agregar un cambio o algún agregado al sistema para
evitar problemas de deficiencia.
Esta clasificación nos permitirá asignar la prioridad a los problemas que surjan durante la
operación del sistema.
6. Glosario del Proyecto

6.1 Acrónimos y Abreviaciones
Acrónimo / Abreviación Nombre Completo Descripción
Confidencial:

AJAX Asynchronous JavaScript And Técnica de desarrollo web para crear
XML aplicaciones Web interactivas,
basadas en el concepto de web 2.0
API Application Programmers Conjunto de especificaciones de
Interface comunicación entre componentes de
software
DAOs Database Objects Objetos de base de datos. Es un
atrón de diseño de modelado de
software, que permite la interacción
entre la capa de servicios con la capa
de datos de una aplicación.
DBMS Database Management System Motor de base de datos
FR Functional requirement Requerimiento Funcional, es una
parte del negocio del Usuario. No es
como tal parte del sistema.
GUI Graphical User Interface Interfaz que el Usuario visualize
IDE Integrated Development Entorno de desarrollo integrado, es
Enviroment un programa compuesto por un
conjunto de herramientas para
programadores.
JDBC Java Database Connectivity Permite la ejecución de operaciones
sobre bases de datos, desde el
lenguaje de programación Java
JSF JavaServer Faces Extensión de un framework de Java,
diseñado para agilizar la creación de
interfaces Web, basado en
reutilización de componentes
primeFaces primeFaces Extensión del framework de JSF, con
inclusión de AJAX.
JVM Java Virtual Machine Maquina Virtual de Java, que permite
la ejecución de programas Java, que
son traducidos en byte-codes e
interpretados por la JVM
LAN / Intranet Local-Area Network Red de area local, conjunto de PCs
interconectadas para compartir
recursos
NFR Non-functional requirement Requerimientos No-Funcionales. Son
utilizados en sí para que un sistema
funcione, pero no son parte del
negocio del usuario, ej. Número de
transacciones que debe soportar un
sistema.
SRS System Requirements Documento de Especificación de
Specification Requerimientos del Sistema
Confidencial:

ORM Object Relational Mapping Herramientas que nos permiten
iteractuar más fácilmente con la base
de datos, al permitir mapear los
objetos de la BD y permitir explorar
los mismos
WAN Wide-Area Network Red de area Amplia, en comparación
de una Lan, una Wan permite
compartir los recursos de una intranet
a través de Internet, y así tener
conectividad en cualquier parte del
mundo que tenga acceso a Internet.
WUI Web-based User Interface Interfaz Web visualizada por el
usuario
Confidencial:
Hola, te saluda nuevamente Ubaldo Acosta.
Revisemos ahora los diagramas de diseño de nuestros sistema SGA.
Vamos a revisar ahora la etapa de diseño de esta aplicación web.
Como podemos observar estamos mostrando el diagrama de caso de uso inicial de nuestro sistema de
gestión de alumnos SGA. Tenemos como actores el Administrador del Sistema, el Coordinador de los
cursos, el Instructor, el Asistente y el Alumno, cada uno de estos actores va a estar interactuando con
alguno de los módulos de nuestro sistema y por medio de un análisis previo obtuvimos los siguientes
casos de uso.
Obtuvimos el caso de uso para la Gestión de Usuarios, para la Gestión de Alumnos, para la Gestión de
Catálogos, para la gestión de Pendientes, el seguimiento de Pendientes y el caso de uso de Reportes.
Cada uno de estos casos de usos se debería ir detallando conforme se avanzara en el desarrollo y
documentación de nuestra aplicación. En este caso únicamente estamos mostrando el diagrama de caso
de uso inicial para que tengamos una idea de que es lo que va hacer nuestro sistema, y por ejemplo en
el caso de uso de Gestión de Alumnos debe incluir por ejemplo el Alta, el Cambio y la Baja de los
Alumnos y en concreto entonces cada uno de estos caso de uso se debería ir detallando conforme se
vaya avanzando en el desarrollo del sistema.
En este segundo diagrama que incluimos dentro de la documentación, podemos observar un diagrama
de iteraciones.
Aquí lo que estamos mostrando es que en la primera etapa vamos a tener una primera iteración, en la
cual vamos a tener una duración aproximada de 2 meses. Posteriormente, una segunda iteración para el
caso de uso de Gestión de Alumnos, el cual se debería concluir en aproximadamente 3 meses.
Cabe resaltar que como hemos comentado estos caso de uso son muy genéricos, entonces engloban
mucha más información. Conforme se va avanzando se debería ir detallando cada uno de los casos de
uso y de igual manera se muestran los actores que van a interactuar con estos casos de uso.
A su vez, mostramos un cuadro en el cual estamos indicando la duración de cada una de las etapas
conforme se va realizando cada una de estas iteraciones. Por ejemplo, para esta iteración 1, el caso de
uso de Gestión de Usuarios va a tardar en la etapa de inicio 10 días, en la etapa de elaboración 15 días,
en la etapa de construcción 1 mes y en la etapa de transición 5 días, dando un total de 2 meses.
Posteriormente en la siguiente iteración tenemos la siguiente información: En la etapa de inicio tardaría

10 días, en la etapa de elaboración 15 días, en la construcción 2 meses y en la transición 5 días. Así que
esto es sólo un ejemplo de como podríamos ir avanzando y documentando nuestro sistema incluyendo
un diagrama de iteraciones.
Los diagramas de caso de uso se pueden validar, por lo tanto se incluyen las imágenes de los diagramas
para poder visualizar estos diagramas.
Estamos mostrando un diagrama que es la validación del caso de uso de gestión de usuarios, entonces
si se requiere más detalle se deja como ejercicio revisar el diagrama que representa a esta validación.
De igual manera se incluye otra validación que es la validación de gestión de alumnos, también se deja
como tarea revisar a más detalle este diagrama.
Finalmente tenemos un diagrama que es el diagrama de clases.
En este caso además de las clases que tenemos en nuestro sistema, estamos agregando los paquetes del mismo.
Si revisamos el código fuente es únicamente a grandes rasgos, debido a que en el sistema tenemos más paquetes
de Java que organizan la información de manera adecuada y con las mejores prácticas.
Para esta aplicación estamos considerando, según hemos comentado, 3 capas. Tenemos la Capa de Datos, la Capa
de Negocio y la Capa de Presentación en este caso la Capa Web.
En la Capa de Datos tenemos clases como pueden ser nuestros DTOs, tenemos clases como son nuestros DAOs y
tenemos también nuestras clases que son las fabricas (los Factory) de los DAO. A su vez, agregamos un manejo de
excepciones y la clase que nos permite hacer una conexión hacia la base de datos.
En la Capa de Negocio tenemos clases como pueden ser las de servicio para el usuario y para el catálogo de
persona.
Y finalmente en la Capa Web tenemos un Servlet controlador y tenemos distintas páginas que nos van a permitir
mostrar la información hacia el cliente y finalmente tenemos un usuario que es el que va a estar procesando la
información en nuestro sistema.
Existen más diagramas que se pueden agregar a esta documentación, como pueden ser diagramas de secuencia,
aunque para ello se requiere más documentación y más tiempo al respecto, por ello en este caso únicamente
estamos incluyendo los diagramas esenciales para documentar nuestro sistema.
A continuación vamos a revisar ya la etapa de construcción en la cual vamos a poder estudiar el código de
nuestro sistema y el mismo ya ejecutándose.
• Diagramas del proyecto en JPG.
• Diagrama 1: Diagrama de Caso de Uso:

• http://icursos.net/cursos/ServletsJSPs/Leccion19/SGA/1.Documentacion/1.CasoUsoInicial.jpg
• Diagrama 2: Diagrama de Iteración:

• http://icursos.net/cursos/ServletsJSPs/Leccion19/SGA/1.Documentacion/2.DiagramaIteracion.jpg
• Diagrama 3: Diagrama Gestión Usuario:

• http://icursos.net/cursos/ServletsJSPs/Leccion19/SGA/1.Documentacion/3.ValidaE1_GestionUsuarios.jpg

• http://icursos.net/cursos/ServletsJSPs/Leccion19/SGA/1.Documentacion/4.ValidaE2_GestionaAlumnos.jpg

• http://icursos.net/cursos/ServletsJSPs/Leccion19/SGA/1.Documentacion/5.DiagramaClases.jpg

Datos de Contacto:

Hola, te saluda nuevamente Ubaldo Acosta.
Ya que hemos desplegado el sistema de SGA, se solicita ahora al alumno

crear el caso de uso de Usuarios, veamos lo que se solicita.
Ya hemos concluido con el despliegue de la aplicación SGA.
Ahora queda como ejercicio final para el alumno, agregar el caso de uso de Gestión de Usuarios al
sistema SGA.
El alumno puede basarse en el catalogo de personas que ya se encuentra desarrollado en el proyecto de

SGA, sin embargo se debe agregar tanto la opción del catalogo de usuarios al menú de la aplicación, así
como las acciones de listado, alta, modificación y baja de usuarios, con el objetivo de que se puedan
crear usuarios directamente desde la aplicación SGA y no usando la tabla de base de datos.
Se debe agregar la opción de catálogo de Usuarios y también validarse por medio del login de la
aplicación.
Se debe agregar las acciones de Listado, Agregar, Editar y Eliminar usuarios. Se pueden apoyar del caso
de uso de personas el cual ya está desarrollado para la realización de este caso de uso.

Datos de Contacto:

10 Universidad de Java Desde Cero 10 JSP

Cargado por

Copyright:

Formatos disponibles

10 Universidad de Java Desde Cero 10 JSP

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

10 Universidad de Java Desde Cero 10 JSP

Cargado por

Copyright:

Formatos disponibles

CURSO DE SERVLETS Y JSPS

Vamos a estudiar los elementos de un JSP.

¿Estás listo? Ok, ¡Vamos!

Lógica de Programación Hibernate Framework

Sitio Web: www.globalmentoring.com.mx

www.gl obal mentoring.com .mx

www.gl obal mentoring.com .mx

www.gl obal mentoring.com .mx

www.gl obal mentoring.com .mx

www.gl obal mentoring.com .mx

www.gl obal mentoring.com .mx

www.gl obal mentoring.com .mx

<form name="forma1" action="procesaFormulario.jsp">

Usuario: <input type="text" name="usuario">

www.gl obal mentoring.com .mx

www.gl obal mentoring.com .mx

www.gl obal mentoring.com .mx

www.gl obal mentoring.com .mx

• Conforme vayamos avanzando en el uso de JSPs veremos

www.gl obal mentoring.com .mx

www.gl obal mentoring.com .mx

www.gl obal mentoring.com .mx

www.gl obal mentoring.com .mx

www.gl obal mentoring.com .mx

www.gl obal mentoring.com .mx

www.gl obal mentoring.com .mx

www.gl obal mentoring.com .mx

www.gl obal mentoring.com .mx

www.gl obal mentoring.com .mx

www.gl obal mentoring.com .mx

www.gl obal mentoring.com .mx

www.gl obal mentoring.com .mx

• Con esto pudimos observar cómo podemos agregar código Java a

• Sin embargo conforme avancemos estudiaremos las mejores prácticas en

www.gl obal mentoring.com .mx

www.gl obal mentoring.com .mx

www.gl obal mentoring.com .mx

www.gl obal mentoring.com .mx

www.gl obal mentoring.com .mx

www.gl obal mentoring.com .mx

www.gl obal mentoring.com .mx

www.gl obal mentoring.com .mx

public String getUsuario() {

Contador de Visitas desde que se reinicio el servidor:

www.gl obal mentoring.com .mx

www.gl obal mentoring.com .mx

• Con esto aprendimos a declarar variables y métodos Java

www.gl obal mentoring.com .mx

www.gl obal mentoring.com .mx

www.gl obal mentoring.com .mx

www.gl obal mentoring.com .mx

www.gl obal mentoring.com .mx

www.gl obal mentoring.com .mx

www.gl obal mentoring.com .mx

www.gl obal mentoring.com .mx

<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0">

<jsp:directive.page contentType="text/html" pageEncoding="UTF-8"/>