UNIVERSIDAD DE LIMA

Facultad de Ingeniera de Sistemas

TAREA 9 GRUPO 02

BELLIDO ALVARADO FRANK CSPEDES JIMNEZ NOREN GALLARDO HUERTAS RENZO TALAVERA BARCLAY MAURICIO

20041552 20051607 20050481 20071216

INGENIERA DE SOFTWARE II BERROCAL PEREZ ALBELA JORGE

Lima, 2010

UNIVERSIDAD DE LIMA

ESCUELA DE INGENIERA

FACULTAD DE INGENIERA DE SISTEMAS

I.

TAREA SEMANA IX

Mtodo: Para el caso prctico mostrar los resultados de la Integracin del sistema: 1. Mostrar el diagrama de casos de uso del sistema de software

____________________________________________________________________________________________________________________________ INGENIERIA DE SOFTWARE II 1

UNIVERSIDAD DE LIMA

ESCUELA DE INGENIERA

FACULTAD DE INGENIERA DE SISTEMAS

____________________________________________________________________________________________________________________________ INGENIERIA DE SOFTWARE II 2

UNIVERSIDAD DE LIMA

ESCUELA DE INGENIERA

FACULTAD DE INGENIERA DE SISTEMAS

2. Mostrar el diagrama de subsistemas (que pueden ajustarse debido al diagrama de casos de uso del sistema de software).

____________________________________________________________________________________________________________________________ INGENIERIA DE SOFTWARE II 3

UNIVERSIDAD DE LIMA

ESCUELA DE INGENIERA

FACULTAD DE INGENIERA DE SISTEMAS

3. Establecer las versiones requeridas para la implementacin de todo el sistema de software.

VERSIN 1:

VERSIN 2:

____________________________________________________________________________________________________________________________ INGENIERIA DE SOFTWARE II 4

UNIVERSIDAD DE LIMA

ESCUELA DE INGENIERA

FACULTAD DE INGENIERA DE SISTEMAS

4. Para la primera versin establecer los componentes o subsistemas cuya construccin deben iniciarse.

Subsistema Web JPA Login JPA Crear Pregunta JPA Eliminar Pregunta JPA Crear Encuesta JPA Eliminar Encuesta

Subsistema de Servicio Acceso DAO Pregunta DAO Bean.Pregunta Encuesta DAO Bean.Encuesta

Subsistema de Datos Crear Tabla Pregunta Insertar Pregunta Eliminar Tabla Pregunta Crear Tabla Encuesta Insertar Encuesta Eliminar Tabla Encuesta Mostrar Tabla Encuesta Mostrar Tabla Pregunta

Patrones 1. Documentar (como el EJEMPLO DE DESCRIPCIN DE UN PATRN DE DISEO mostrado anteriormente) e Implementar un ejemplo aplicado a un sistema que muestre el funcionamiento del patrn ITERATOR. Nombre: Iterador (Iterator) Clasificacin: Diseo Por su complejidad y usabilidad: Comportamiento Por su propsito: Comportamiento de Objeto Propsito: Un iterador es un patrn de diseo de software que abstrae el proceso de recorrer una coleccin de elementos sin revelar su representacin interna. Este patrn est formado por una secuencia de elementos, una posicin actual en la secuencia y una forma de avanzar al siguiente elemento de la secuencia convirtindolo en el elemento actual. Tambin conocido como: Cursor. Motivacin: Un objeto coleccin, tal como una lista o vector, debera proveer un modo de brindar acceso a sus elementos sin exponer su estructura interna. Quizs, se desea recorrer la lista en diferentes formas, dependiendo de sus necesidades o, tal vez, se necesita tener ms de un recorrido sobre la misma lista. Consideraciones: 1. Acceder al contenido de un objeto agregado sin revelar su representacin interna. 2. Permitir mltiples tipos de recorridos sobre objetos agregados. 3. Proporcionar una interfaz uniforme para recorrer diferentes estructuras de agregacin (Iteracin polimrfica).

____________________________________________________________________________________________________________________________ INGENIERIA DE SOFTWARE II 5

UNIVERSIDAD DE LIMA

ESCUELA DE INGENIERA

FACULTAD DE INGENIERA DE SISTEMAS

Solucin: Una clase que accede a una coleccin nicamente a travs de una interfaz, se mantiene independiente de la clase que implementa la interfaz. Basado en este anlisis, el patrn define una interfaz que declara mtodos para el acceso secuencial a los objetos en la coleccin y crea una clase que implemente esta interfaz para mantener la posicin actual del recorrido. De igual manera, el patrn define una interfaz que permite la creacin del objeto iterador y crea una clase que implemente esta interfaz para permitir devolver una instancia apropiada de la clase que implement el iterador. Estructura:

Participantes:

Iterator: Interfaz que permite el acceso y recorrido de los elementos en una coleccin. ConcreteIterator: Implementa la interfaz del Iterator y mantiene la posicin actual del recorrido. Aggregate: Interfaz que permite crear un objeto Iterator. ConcreteAggregate: Implementa la interfaz Aggregate y devuelve la instancia apropiada de ConcreteAggregate.

Colaboraciones: Un ConcreteIterator conoce cul es el objeto actual dentro de la coleccin y permite obtener el siguiente objeto en el recorrido. Cmo funciona: La idea de acceder a los objetos mediante la interfaz se ve claramente expresada en el diagrama anterior. El cliente (Client), quien accede a los elementos de la lista, lo hace siempre mediante los mecanismos que implementan la interfaz de la coleccin (Aggregate) y el iterador (Iterator), manteniendo su independencia de las clases que los implementan.
____________________________________________________________________________________________________________________________ INGENIERIA DE SOFTWARE II 6

UNIVERSIDAD DE LIMA

ESCUELA DE INGENIERA

FACULTAD DE INGENIERA DE SISTEMAS

Como la estructura de la coleccin es privada, es imposible crear una instancia del iterador mediante ella. Para esto, la interfaz provee su propio mecanismo (CreateIterator), el cual retorna el iterador necesario al cliente. Una funcionalidad importante del patrn es la implementacin de recorridos sobre la coleccin. Su funcionalidad, dentro del iterador, nos permite tener mltiples recorridos sobre la misma coleccin. Por ltimo, la iteracin polimrfica del patrn est dada por su implementacin uniforme sobre las colecciones, lo que permite que un iterador pueda recorrer mltiples estructuras de agregacin.

Cundo emplearlo: 1. Cuando se necesite acceder al contenido de una coleccin sin saber su representacin interna. 2. Cuando se necesite implementar varios recorridos sobre una misma coleccin. Colaboraciones o dinmica:

____________________________________________________________________________________________________________________________ INGENIERIA DE SOFTWARE II 7

UNIVERSIDAD DE LIMA

ESCUELA DE INGENIERA

FACULTAD DE INGENIERA DE SISTEMAS

Anti-patrones: 1. Investigar, documentar (como el Ejemplo de antipatrn de arquitectura mostrado anteriormente) y explicar detalladamente: 1.1 Los grupos 1 y 2 el antipatrn: Project Missmanagement

Project Mismanagement Nombre: Project Mismanagement. Tambin conocido como: La mala gestin del proyecto. Escala: En la empresa. Solucin: Mejor gestin de Riesgos Tipo de solucin: Aplicable en los procesos y funciones. Causas bsicas: La causa universal es la responsabilidad. Forma General: Se refiere a la vigilancia y al control de proyectos de software. El plazo para que esto ocurra despus de las actividades de planificacin y durante el anlisis, diseo, construccin y pruebas del software del sistema. La mala gestin del proyecto implica errores cometidos en el da a da asumiendo los errores de planificacin. En particular, los errores fundamentales son: Insuficiencia en la definicin de arquitectura. La falta de revisin de cdigo (software de control). La insuficiente cobertura de la prueba.

Sntomas y consecuencias El diseo es difcil de aplicar debido a la falta de una estrategia de arquitectura. Se evala e inspecciona el cdigo con poca frecuencia. Las pruebas requieren de un esfuerzo adicional, porque el comportamiento del sistema no est suficientemente definido. En las fases de prueba existe un gran nmero de defectos que deberan haber sido eliminados en las fases anteriores como la arquitectura, el diseo, inspeccin, ensayo y unidad. Defectos en informes hacia el final del desarrollo y la entrega o aceptacin de las fases.

____________________________________________________________________________________________________________________________ INGENIERIA DE SOFTWARE II 8

UNIVERSIDAD DE LIMA

ESCUELA DE INGENIERA

FACULTAD DE INGENIERA DE SISTEMAS

Causas tpicas: Una inadecuada arquitectura al no definir los criterios tcnicos para la inspeccin, pruebas, integracin y la interoperabilidad. La evaluacin del cdigo de software y las inspecciones no evalan los defectos de diseo que luego deben ser abordados en las fases ms costosas como la de aceptacin. Insuficiente prueba de las necesidades bsicas de integracin tampoco abordan las necesidades de la plena interoperabilidad de la aplicacin. Todos los anteriores factores indican la ineficacia en la gestin de riesgos que pueden atribuirse a las prcticas profesionales de los arquitectos, diseadores, y la gestin.

Solucin: La correcta gestin de los riesgos es un medio eficaz para resolver los sntomas y las consecuencias previsibles de este anti-patrn. Podemos clasificar los Riesgos en: o Riesgos de direccin y/o gestin o Riesgos de fracaso en los puntos comunes del proyecto o Riesgos de la calidad. Debemos comprender estas categoras con el fin de calificar mejor los riesgos.

Herramienta: 1. Haciendo uso de VB.NET, usando la plataforma de desarrollo de la mquina virtual instalada en los computadores de la Universidad, programar el caso de uso del sistema de software Publicar Encuesta, ejecutado por el Profesor del curso, hacer uso de todos los patrones de diseo visto hasta la semana seis, mostrar claramente en el diagrama de clases.

____________________________________________________________________________________________________________________________ INGENIERIA DE SOFTWARE II 9