domingo, 21 de junio de 2015

Tarea 3 Frameworks: "Struts"

Framework Struts

¿Qué es Struts?

Es un framework que implementa el patrón de arquitectura MVC en Java
Un framework es la extensión de un lenguaje mediante una o más jerarquías de clases que implementan una funcionalidad y que (opcionalmente) pueden ser extendidas. El framework puede involucrar TagLibraries.
El patrón de arquitectura MVC (Model-View-Controller) es un patrón que define la organización independiente del Model (Objetos de Negocio), la View (interfaz con el usuario u otro sistema) y el Controller (controlador del workflow de la aplicación: "si estoy aquí y me piden esto entonces hacer tal cosa, si sale bien mostrar esto y sino lo aquello otro").


 


¿Cómo funciona esto en aplicaciones Web?




El navegador genera una solicitud que es atendida por el Controller (un Servlet especializado). El mismo se encarga de analizar la solicitud, seguir la configuración que se le ha programado en su XML y llamar al Action correspondiente pasándole los parámetros enviados. El Action instanciará y/o utilizará los objetos de negocio para concretar la tarea. Según el resultado que retorne el Action, el Controller derivará la generación de interfaz a una o más JSPs, las cuales podrán consultar los objetos del Model a fines de realizar su tarea.

 ¿Para qué sirve?

Evidentemente, como todo framework intenta, simplifica notablemente la implementación de una arquitectura según el patrón MVC. El mismo separa muy bien lo que es la gestión del workflow de la aplicación, del modelo de objetos de negocio y de la generación de interfaz.
El controlador ya se encuentra implementado por Struts, aunque si fuera necesario se puede heredar y ampliar o modificar, y el workflow de la aplicación se puede programar desde un archivo XML Las acciones que se ejecutarán sobre el modelo de objetos de negocio se implementan basándose en clases predefinidas por el framework y siguiendo el patrón Facade. Y la generación de interfaz se soporta mediante un conjunto de Tags predefinidos por Struts cuyo objetivo es evitar el uso de Scriplets (los trozos de código Java entre "<%" y "%>"), lo cual genera ventajas de mantenibilidad y de perfomance (pooling de Tags, caching, etc).
Logísticamente, separa claramente el desarrollo de interfaz del workflow y lógica de negocio permitiendo desarrollar ambas en paralelo o con personal especializado.
También es evidente que potencia la reutilización, soporte de múltiples interfaces de usuario (Html, sHtml, Wml, Desktop applications, etc.) y de múltiples idiomas, localismos, etc.

 ¿Licencia?

Struts está disponible bajo la licencia "free-to-use-license" de la Apache Software Foundation (verhttp://www.apache.org/LICENSE-1.1)


 ¿Dónde encuentro más info?


Tarea 3 Frameworks: "JSF"



Framework: JSF

JavaServer Faces (JSF) es una tecnología y framework para aplicaciones Java basadas en web que simplifica el desarrollo de interfaces de usuario en aplicacioneJava EEJSF usa JavaServer Pages (JSP) como la tecnología que permite hacer el despliegue de las páginas, pero también se puede acomodar a otras tecnologías como XUL (acrónimo de XML-based User-interface Language, lenguaje basado en XML para la interfaz de usuario)

JSF incluye:
  • Un conjunto de APIs para representar componentes de una interfaz de usuario y administrar su estado, manejar eventos, validar entrada, definir un esquema de navegación de las páginas y dar soporte para internacionalización y accesibilidad.
  • Un conjunto por defecto de componentes para la interfaz de usuario.
  • Dos bibliotecas de etiquetas personalizadas para JavaServer Pages que permiten expresar una interfaz JavaServer Faces dentro de una página JSP.
  • Un modelo de eventos en el lado del servidor.
  • Administración de estados.
  • Beans administrados.
La especificación de JSF fue desarrollada por la Java Community Process como JSR 127, que definía JSF 1.0 y 1.1, JSR 252que define JSF 1.2 y JSR 314 para JSF 2.0

Objetivos:

Estos objetivos de diseño representan el foco de desarrollo de JSF:
  1. Definir un conjunto simple de clases base de Java para componentes de la interfaz de usuario, estado de los componentes y eventos de entrada. Estas clases tratarán los aspectos del ciclo de vida de la interfaz de usuario, controlando el estado de un componente durante el ciclo de vida de su página.
  2. Proporcionar un conjunto de componentes para la interfaz de usuario, incluyendo los elementos estándares de HTML para representar un formulario. Estos componentes se obtendrán de un conjunto básico de clases base que se pueden utilizar para definir componentes nuevos.
  3. Proporcionar un modelo de JavaBeans para enviar eventos desde los controles de la interfaz de usuario del lado del cliente a la aplicación del servidor.
  4. Definir APIs para la validación de entrada, incluyendo soporte para la validación en el lado del cliente.
  5. Especificar un modelo para la internacionalización y localización de la interfaz de usuario.
  6. Automatizar la generación de salidas apropiadas para el objetivo del cliente, teniendo en cuenta todos los datos de configuración disponibles del cliente, como versión del navegador.

Tarea 3 Frameworks: "Spring Framework"

¿Qué es un Frameworks?

La palabra inglesa "framework" (marco de trabajo) define, en términos generales, un conjunto estandarizado de conceptos, prácticas y criterios para enfocar un tipo de problemática particular que sirve como referencia, para enfrentar y resolver nuevos problemas de índole similar.




















Spring es un framework para el desarrollo de aplicaciones y contenedor de inversión de control, de código abierto para la plataforma Java.


1. Spring Framework


Spring Framework es una plataforma que nos proporciona una infrastuctura que actúa de soporte para desarrollar aplicaciones Java. Spring maneja toda la infrastructura y así te puedes centrar en tu aplicación. Diciendolo mas coloquialmente, Spring es el “pegamento” que une todos los componentes de la aplicación, maneja su ciclo de vida y la interacción entre ellos.
Spring Framework es un contenedor ligero (“lightweight container”) en contraposición a un un servidor de aplicaciones J2EE. En el caso de una aplicación web, te basta con un contenedor de servlets como Tomcat o Jetty. Pero Spring no solo se puede usar para crear aplicaciones web, se podría usar para cualquier aplicacion java, aunque su uso habitual sea en entornos web, nada te impide utilizarlo para cualquier tipo de aplicación.

¿Porque surgió Spring Framework?

En los inicios de las aplicaciones J2EE, EJB era muy complejo y tedioso, tanto la version 1 como la 2. Yo tengo la suerte de haber trabajado con EJB a partir de la versión 3, pero otros no corrieron la misma suerte, y trabajaron con versiones anteriores. No puedo profundizar mucho, por mi desconocimiento de esas versiones, pero todos los que han trabajado con ellas, comentan que era un infierno. Pero para eso estaba el amigo Rod, para venir al rescate…
La primera versión de Spring se lanzó en junio de 2003, aunque el gran lanzamiento se hizo en Marzo de 2004, con la versión 1.0. Meses mas tarde, en concreto el 21 de Junio de 2004, Rod Johnson, creador de Spring, publicó el libro: “J2EE development without EJB“. Recomiendo encarecidamente su lectura, te hace comprender los motivos por los que diseñar Spring. Lo que mas me gustó del libro, es comprobar como algo complicado lo implementa de manera tan sencilla y elegante.
Yo llevo trabajando con Spring desde septiembre de 2005 y ya no puedo vivir sin él. Hoy en día Spring ha crecido mucho, si hacéis una busqueda en cualquier portal de empleo, vereis que tiene mucha demanda. Incluso ya no es exclusivo de Java, pues ya hay versión para .NET, bautizada comoSpring.NET.

Inversión de control e inyeccción de dependencias

Abreviado del ingles IoC y DI respectivamente. Hoy en día ya no se usa practicamente el primer término, sino el segundo. Cuando tu diseñas una aplicación en Java dispones de muchos objetos que se relacionan entre sí mediante composición. Para enlazar dos objetos tendrías que inyectarle a uno de ellos una instancia del otro. Esto lo realiza Spring por tí, por eso se llama Inversión de control, porque es spring quien se encarga de estas dependencias, instancia los objectos y los inyecta por reflexión. A grandes rasgos, declaras en un XML los componentes de tu aplicación y sus dependencias. Spring lee este XML, llamado Application Context, crea los componentes y sus relaciones entre ellos. Las últimas versiones de Spring, ya permiten anotaciones, y se puede anotar una propiedad en una clase mediante @Autowired para que Spring busque la clase correspondiente, la instancie y la inyecte, ahorrandonos bastante código XML.
La “Dependency injection”, ya no es un concepto propio de Spring, otros frameworks lo copiaron. Desde la version 6 de J2EE existe la anotacion @Inject para hacer exactamente lo mismo. Otro menos conocido, como Guice, de Google, tambien lo he utilizado en un proyecto.

Módulos

Spring es bastante grande, por ello el proyecto esta dividido en módulos. No siempre se utiliza en un proyecto todo lo que tiene spring. Por poner un ejemplo, podrías utilizar Struts para la parte web, en vez de Spring MVC. Si utilizas un framework de persistencia, como Hibernate o iBatis, tendrías que incluir spring-orm en tu classpath.
Spring tiene unos 20 módulos:
springmodules

Referencias : http://www.genbetadev.com/java-j2ee/spring-framework-introduccion


sábado, 20 de junio de 2015

Tarea 4 Especificación de Requisitos de Software según el estándar de IEEE 830

Resumen

Según IEEE, un buen Documento de Requisitos, pese a no ser obligatorio que siga estrictamente la organización y el formato dados en el estándar 830, sí deberá incluir, de una forma o de otra, toda la información presentada en dicho estándar. El estándar de IEEE 830 no está libre de defectos ni de prejuicios, y por ello ha sido justamente criticado por múltiples autores y desde múltiples puntos de vista, llegándose a cuestionar incluso si es realmente un estándar en el sentido habitual que tiene el término en otras ingenierías

Características 

 No se describen los requisitos, sino su contexto. Esto permitirá definir con detalle los requisitos específicos, haciendo que sean más fáciles de entender. Normalmente, esta sección consta de las siguientes subsecciones: Perspectiva del producto, funciones del producto, características de los usuarios, restricciones, factores que se asumen y futuros requisitos. 

Esquema


Conclusión


Para poder asegurar el éxito de cualquier proyecto es absolutamente necesario realizar una buena toma de requerimiento, lo que se expresa en el estándar de IEE 830.

Teniendo en cuenta que la toma de requerimientos es la etapa más importante(independiente del proyecto realizado) es de suma importancia tener bien en claro como realizar esta misma, lo que comprende saber bien de que se trata y como realizar bien la toma de requerimiento,

viernes, 19 de junio de 2015

Tarea 5 Patrones de diseño

Template Method


Define una estructura algorítmica cuya lógica quedará a cargo de las subclases. Para ello, escribe una clase abstracta que contiene parte de la lógica necesaria para realizar su finalidad. En ella se define una estructura de herencia que sirve de plantilla ("Template" significa plantilla) de los métodos en las subclases.

Dicho de otra forma, define un esqueleto de un algoritmo, delegando algunos pasos a las subclases. Permite redefinir parte de dicho algoritmo sin cambiar su estructura.

Se debe utilizar este patrón cuando.
Se quiera factorizar el comportamiento común de varias subclases.
Se necesite implementar las partes fijas de un algoritmo una sola vez y dejar que las subclases implementen las partes variables.
Se busque controlar las ampliaciones de las subclases, convirtiendo en métodos plantillas aquéllos métodos que pueden ser redefinidos.
Este patrón se vuelve de especial utilidad cuando es necesario realizar un algoritmo que sea común para muchas clases, pero con pequeñas variaciones entre una y otras. En este caso, se deja en las subclases cambiar una parte del algoritmo.
AbstractTemplate o AbstractClass: implementa un método plantilla que 
define el esqueleto de un algoritmo y define métodos abstractos que deben implementar las subclases concretas
TemplateConcreto o ConcreteClass: implementa los métodos abstractos para realizar los pasos del algoritmo que son específicos de la subclase.


Command

Encapsula un mensaje como un objeto. Especifica una forma simple de separar la ejecución de un comando, del entorno que generó dicho comando. Permite solicitar una operación a un objeto sin conocer el contenido ni el receptor real de la misma. Si bien estas definiciones parecen un tanto ambigüas, sería oportuno volver a leerlas luego de entender el ejemplo.

Este patrón suele establecer en escenarios donde se necesite encapsular una petición dentro de un objeto, permitiendo parametrizar a los clientes con distintas peticiones, encolarlas, guardarlas en un registro de sucesos o implementar un mecanismo de deshacer/repetir.

Se debe usar cuando:
Se necesiten colas o registros de mensajes.
Se deba tener la posibilidad de deshacer las operaciones realizadas.
Se necesite uniformidad al invocar las acciones.
Se quiera facilitar la parametrización de las acciones a realizar.
Se quiera independizar el momento de petición del de ejecución.
El parámetro de una orden puede ser otra orden a ejecutar.
Se busque desarrollar sistemas utilizando órdenes de alto nivel que se construyen con operaciones sencillas (primitivas).
Se necesite sencillez al extender el sistema con nuevas acciones.
Lo que permite el patrón Command es desacoplar al objeto que invoca a una operación de aquél que tiene el conocimiento necesario para realizarla. Esto nos otorga muchísima flexibilidad: podemos hacer, por ejemplo, que una aplicación ejecute tanto un elemento de menú como un botón para hacer una determinada acción. Además, podemos cambiar dinámicamente los objetos Command. 
Command: declara una interfaz para ejecutar una operación.
CommandConcreto: define un enlace entre un objeto “Receiver” y una acción. Implementa el método execute invocando la(s) correspondiente(s) operación(es) del “Receiver”.
Cliente: crea un objeto “CommandConcreto” y establece su receptor.
Invoker: le pide a la orden que ejecute la petición.
Receiver: sabe como llevar a cabo las operaciones asociadas a una petición. Cualquier clase puede hacer actuar como receptor.


Visitor

Busca separar un algoritmo de la estructura de un objeto. La operación se implementa de forma que no se modifique el código de las clases sobre las que opera.
Si un objeto es el responsable de mantener un cierto tipo de información, entonces es lógico asignarle también la responsabilidad de realizar todas las operaciones necesarias sobre esa información. La operación se define en cada una de las clases que representan los posibles tipos sobre los que se aplica dicha operación, y por medio del polimorfismo y la vinculación dinámica se elige en tiempo de ejecución qué versión de la operación se debe ejecutar. De esta forma se evita un análisis de casos sobre el tipo del parámetro.

Este patrón debe utilizarse cuando.
Una estructura de objetos contiene muchas clases de objetos con distintas interfaces y se desea llevar a cabo operaciones sobre estos objetos que son distintas en cada clase concreta.
Se quieren llevar a cabo muchas operaciones dispares sobre objetos de una estructura de objetos sin tener que incluir dichas operaciones en las clases.
Las clases que definen la estructura de objetos no cambian, pero las operaciones que se llevan a cabo sobre ellas.
Dado que este patrón separa un algoritmo de la estructura de un objeto, es ampliamente utilizado en intérpretes, compiladores y procesadores de lenguajes, en general.
Se debe utilizar este patrón si se quiere realizar un cierto número de operaciones, que no están relacionadas entre sí, sobre instancias de un conjunto de clases, y no se quiere “contaminar” a dichas clases.



Visitor: declara una operación de visita para cada uno de los elementos concretos de la estructura de objetos. Esto es, el método visit().
VisitorConcreto : implementa cada una de las operaciones declaradas por Visitor. 
Element: define la operación que le permite aceptar la visita de un Visitor.
ConcreteElement: implementa el método accept() que se limita a invocar su correspondiente método del Visitor.
ObjectStructure: gestiona la estructura de objetos y puede ofrecer una interfaz de alto nivel para permitir a los Visitor visitar a sus elementos.

jueves, 18 de junio de 2015

Tarea 5

Patrón Diseño Strategy


Este patrón facilita la implementación de distintas estrategias o comportamientos específicos en clases hijas a través de una clase común. Así, en tiempo de ejecución y en función de algún parámetro como el tipo de instancia, se ejecutará la estrategia concreta para esa situación.
Se recomendará usar este patrón cuando en un mismo programa debamos proporcionar distintas alternativas de comportamiento, permitiendo a través de clases independientes, encapsular las distintas estrategias.
Los distintos componentes de este patrón son:
o    Interfaz Strategy: será aquella interfaz que define el nombre del método o métodos que conformarán la estrategia.
o    Clases Strategy concretas: todas aquellas clases que implementen la interfaz Strategy dando forma al algoritmo.
o    Contexto: elemento donde se desarrollará la estrategia.

El diagrama UML de la implementación de este patrón será:
Como podemos observar, la interfaz iArea será la estrategia genérica. En este caso, además, se ha añadido una clase abstracta AbstractArea que implementará dicha interfaz y definirá algunas propiedades que serán comunes o necesarias en las implementaciones concretas (en este caso, el nombre de la figura).
o    iArea: Interfaz en la que definimos un método que nos ayudará a calcular el área de cualquier cuerpo geométrico.
o    AbstractArea: Clase abstracta que implementará la interfaz IArea y donde definimos un constructor y alguna propiedad básica o común al resto de estrategias.
A continuación desarrollaremos 3 clases para implementar la forma de calcular el área de un polígono regular, un círculo y un triángulo. Estas serán las estrategias existentes en nuestra aplicación de ejemplo.
o    AreaCircular: Estrategia que define que el cálculo del área de un circulo se lleva a cabo multiplicando el valor del radio al cuadrado por el número PI.

o    AreaTriangulo: Estrategia que define que el cálculo del área de un triángulo se lleva a cabo multiplicando el valor de la base por la altura dividiéndolo entre 2.


o    AreaPoligonoRegular: Estrategia que define que el cálculo del área de un polígono regular de n lados conocido el radio de la circunferencia que lo contiene se lleva a cabo multiplicando el número de lados, por el radio al cuadrado, por el seno de 2PI dividido entre n y todo ello dividido entre 2.


Para completar el ejemplo, se han creado un par de excepciones específicas de forma que si se pasa un valor incorrecto al constructor de un objeto nuestra aplicación nos comunique cual es el error:



Patrón de Diseño State

Un patrón de diseño es una solución a un problema de diseño. Para que una solución sea considerada un patrón debe poseer ciertas características. Una de ellas es que resuelva problemas similares de manera efectiva. Otra característica es que debe ser reutilizable.
Uno de los Patrones de Diseño muy importantes es el patrón de diseño State conocido como State (Estado, Objects for States), es un patrón de Comportamiento.
El patrón de diseño State es capaz de permitir que un objeto cambie su comportamiento de forma dinámica.Dentro de las características de su paradigma dentro de la programación orientada a objetos utiliza el polimorfismo, en este patrón tenemos la ventaja de que reducimos la duplicación al eliminar el código innecesario.
El Patrón de Diseño State es un patrón de comportamiento para objetos. Se debe usar si el comportamiento de un objeto depende de su estado, y se ve modificado en tiempo de ejecución. Permite que un objeto cambie su comportamiento cuando cambia su estado interno, tal y como si el objeto cambiase de clase.

Funciones:

Encapsula un comportamiento dependiente del estado (State) en que nos encontremos se va a comportar de una manera o de otra. 
Se podría aplicar en el monopoly para los jugadores, si estas en el estado bancarrota harás una cosa y si estas en juego otra. La diferencia que esto puede cambiar en tiempo de ejecución.

• Crea un objeto por cada estado posible del objeto que lo llama para que tenga diferentes comportamientos
• Varia su comportamiento ante los diferentes mensajes.
• Hace los cambios de estado explícitos.
• Localiza fácilmente las responsabilidades de los estados específicos
Por ejemplo: una alarma puede tener diferentes estados, como desactivada, activada, en configuración. Definimos una interfaz Estado, Alarma, y luego definimos los diferentes estados
Conclusiones:

El patrón STATE está pensado para que un programa sea escalable y fácil de manejar.
El diseño se puede aplicar en diferentes situaciones.
Mucha gente lo ha usado y han logrado tener éxito de él.
El patrón ha sido utilizado para la implementación y diseño de software de juegos.

Ejemplo Codigo
Imaginemos que vamos a un banco y cuando llegamos nos colocamos en la fila de mostrador: si la misma esta abierta, seguiremos en la fila. En cambio, si esta cerrada nos colocaremos en otra fila o tomaremos alguna decisión acorde. Por otro lado, si vemos un cartel que dice "enseguida vuelvo" quizás tenemos que contemplar el tiempo disponible que tenemos. Es decir, para nosotros, el comportamiento de un banco cambia radicalmente según el estado en el que se encuentre. Para estas ocasiones, es ideal el uso de un patrón de estados.



El banco publica un método llamado atende() pero en realidad la atención la realiza la ventanilla.



La ventanilla cambia su comportamiento según el estado en que se encuentre. Por ejemplo, si esta cerrada, no hay atención directamente. Por eso mismo, delega el método de atención a su estado y es este mismo estado quién toma la decisión de atender o no.