Ejemplo de casos de usos

Un caso de uso es una descripción de los pasos o las actividades que deberán realizarse para llevar a cabo algún proceso. los personajes o entidades.

Fuente: http://jcpenneypromocode.biz/haircut/diagrama-de-casos-de-uso-para-el-sistema-de-venta

Casos de usos

Ejemplo Caso de Uso:

Como ejemplo esta el caso de una Máquina Recicladora:

Sistema que controla una máquina de reciclamiento de botellas, tarros y jabas. El sistema debe controlar y/o aceptar:

• Registrar el número de ítemes ingresados.
• Imprimir un recibo cuando el usuario lo solicita:
  1. Describe lo depositado
  2. El valor de cada item
  3. Total
• El usuario/cliente presiona el botón de comienzo
• Existe un operador que desea saber lo siguiente:
  1. Cuantos ítemes han sido retornados en el día.
  2. Al final de cada día el operador solicita un resumen de todo lo depositado en el día.
• El operador debe además poder cambiar:
1. Información asociada a ítemes.
2. Dar una alarma en el caso de que:
1. Item se atora.
2. No hay más papel.

Diseño:

Domain Driven Design (DDD)

Presentacion DDD (Domain Driven Design)

Integrantes: David Silva, Alvaro Parra

Informe : 

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?

• http://jakarta.apache.org/struts
• http://jakarta.apache.org/struts/userGuide
• http://jakarta.apache.org/struts/api/index.html
• http://jguru.com/faq/Struts
• http://jguru.com/forums/Struts
• http://jakarta.apache.org/struts/#Involved

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 aplicaciones Java EE. JSF 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:

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

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,