Análisis y Diseño de Sistemas II - Teoría sobre el Análisis Orientado a Objetos

Anlisis y Diseo de Sistemas II Teora
Computacin e Informtica
CARRERAS PROFESIONALES
CIBERTEC
ANLISIS Y DISEO DE SISTEMAS II - TEORA
NDICE
Presentacin Red de contenidos
5 6
UNIDAD 1 : Anlisis Orientado a Objetos Tema 1 : Anlisis orientado a objetos 1.1. Flujo de trabajo del AOO 1.2. Artefactos del anlisis 1.3. Modelo de anlisis Tema 2 : Anlisis de la arquitectura 2.1. Pasos en el anlisis de la arquitectura Tema 3 : Anlisis de casos de uso 3.1. Pasos en el anlisis de casos de uso 3.2. Caso prctico Tema 4 : Anlisis de clases 4.1. Pasos a realizar 4.2. Tarjetas CRC 4.3. Caso prctico UNIDAD 2 : Modelo de Datos Tema 1 : Modelo de datos 1.1. Modelo conceptual 1.2. Modelo lgico 1.3. Modelo fsico UNIDAD 3 : Diseo Orientado a Objetos Tema 1 : Diseo orientado a objetos 1. Flujo de trabajo 2. Artefactos del diseo 3. Modelo de anlisis Vs. Modelo de diseo Tema 2 : Arquitectura de software
7 8 9 10 11 14 14 20 20 26 34 34 35 37 45 45 46 59 62 69 70 70 70 73 75
CIBERTEC
1. Por qu es importante la arquitectura 2. Fases de la arquitectura 3. Estilos arquitectnicos Tema 3 : Diseo de casos de uso 1. Patrones de diseo 2. Extensiones de UML para aplicaciones web (WAE) 3. Realizacin de diseo de casos de uso con patrn arquitectnico MVC 4. Realizacin de diseo de casos de uso con patrn arquitectnico MVC y patrn de diseo DAO
76 77 79 86 86 91 95
101
ANEXOS Anexo I Anexo II Reporte de Especificacin de Software (RES) Reporte de Diseo de Software (RDS) 109 123
CIBERTEC
PRESENTACIN
Anlisis y Diseo de Sistemas II pertenece a la lnea formativa y se dicta en la carrera de Computacin e Informtica. El curso imparte conocimientos relacionados con la disciplina de anlisis y diseo, y el modelo de datos. El manual para el curso ha sido diseado bajo la modalidad de unidades de aprendizaje, las que se desarrollan durante semanas determinadas. En cada una de ellas, hallar los logros, que debe alcanzar al final de la unidad; el tema tratado, el cual ser ampliamente desarrollado; y los contenidos, que debe desarrollar, es decir, los subtemas. Por ltimo, encontrar las actividades que deber desarrollar en cada sesin, que le permitirn reforzar lo aprendido en la clase. El curso es terico - prctico: consiste en un taller de desarrollo de proyectos de software. En primer lugar, se describe el flujo de trabajo del anlisis orientado a objetos. A continuacin, se explica el modelo de datos. Por ltimo, se presenta el flujo de trabajo del diseo orientado a objetos.
CIBERTEC
RED DE CONTENIDOS
Anlisis y Diseo de Sistemas II
Anlisis Orientado a Objetos
Modelo de datos
Diseo Orientado a Objetos
Anlisis OO
Modelo Conceptual
Diseo OO
Anlisis de la Arquitectura
Modelo Lgico
Arquitectura de Software
Anlisis de casos de uso
Modelo Fsico
Diseo de casos de uso
Anlisis de clases
CIBERTEC
UNIDAD DE APRENDIZAJE
1
ANLISIS ORIENTADO A OBJETOS
LOGRO DE LA UNIDAD DE APRENDIZAJE
Al finalizar la primera unidad, el alumno modula la arquitectura de anlisis que da soporte a los procesos del negocio, diagrama la estructura y el comportamiento de sus funcionalidades mediante diagramas de clases y diagramas de comunicacin respectivamente. Los artefactos sern creados utilizando la herramienta CASE IBM Rational Software Architect (RSA).
TEMARIO
Tema 1: Anlisis orientado a objetos 1.1. Flujo de trabajo del AOO 1.2. Artefactos del anlisis 1.3. Modelo de anlisis Tema 2: Anlisis de la arquitectura 2.1. Pasos en el anlisis de la arquitectura 2.2. Caso prctico Tema 3: Anlisis de casos de uso 3.1. Pasos en el anlisis de casos de uso 3.2. Caso prctico Tema 4: Anlisis de clases 4.1. Anlisis de clases 4.2. Tarjetas CRC 4.3. Caso prctico
ACTIVIDADES PROPUESTAS
1. Los alumnos crean la arquitectura de anlisis a partir de un diagrama de casos de uso estructurado. 2. Los alumnos crean la realizacin de anlisis de un caso de uso a partir de una ECU. 3. Los alumnos confeccionan las tarjetas CRC de las clases que se identifican a partir de una ECU.
CIBERTEC
1. ANLISIS ORIENTADO A OBJETOS

El Anlisis Orientado a Objetos (AOO) es parte de la disciplina Anlisis y Diseo de RUP; esta disciplina tiene como propsito: Transformar los requisitos en un diseo del sistema a crear. Definir una arquitectura robusta para el sistema. Adaptar el diseo para que funcione en el ambiente de implementacin, disendolo para un desempeo esperado.
El flujo de trabajo de Anlisis y Diseo toma los casos de uso documentados del flujo de trabajo de la Captura de Requisitos y los traslada a elementos de diseo que sern usados para construir el sistema. Por medio de varias actividades y modelos, el flujo de trabajo de Anlisis y Diseo busca transformar la informacin obtenida de los stakeholders en informacin que los programadores podrn usar. El flujo de trabajo de esta disciplina se muestra en la figura No. 1.1.
Figura 1.1. Flujo de Trabajo de la disciplina Anlisis y Diseo. En la fase de Inicio, la disciplina de Anlisis y Diseo se preocupa por establecer si la visin del sistema es factible, y en determinar las tecnologas potenciales para la solucin de software (dentro de la actividad Perform Architectural Synthesis). Si se considera que pocos riesgos se asocian al desarrollo (porque el dominio se entiende muy bien, el sistema no es novedoso o cualquier otra razn parecida) entonces este aspecto se omite del flujo de trabajo.
CIBERTEC
En la parte inicial de la fase de Elaboracin se enfoca el esfuerzo en crear una arquitectura inicial del sistema (en la actividad Define a Candidate Architecture) la cual proporcionar un punto inicial para todo el trabajo de anlisis. Si la arquitectura ya existe (porque fue creada en iteraciones anteriores o en proyectos anteriores) el trabajo se enfoca en cambios para refinar la arquitectura (actividad Refine the Architecture) y en analizar el comportamiento y crear un conjunto inicial de elementos los cuales proporcionarn un comportamiento apropiado (en la actividad Analyze Behavior). Despus de que los elementos iniciales son identificados, se refinan en iteraciones futuras. La actividad Design Components produce un conjunto de componentes los cuales proveen un comportamiento adecuado para satisfacer los requisitos del sistema. Si el sistema incluye una base de datos, entonces la actividad de Design the Database se ejecuta en paralelo. El resultado es un conjunto inicial de componentes los cuales en un futuro son refinados dentro de la Implementacin. Con el fin de entender el flujo de trabajo realizado en esta disciplina en forma ms detallada se ha dividido su descripcin en dos partes: Anlisis Orientado a Objetos (AOO) y Diseo Orientado a Objetos (DOO). A continuacin, se empezar a estudiar el AOO.
1.1. Flujo de trabajo del AOO

El objetivo del anlisis es comprender el problema y comenzar a desarrollar un modelo visual de lo que se est tratando de construir, independiente de la tecnologa a utilizar en la aplicacin, como el lenguaje de programacin. El anlisis se centra en la traduccin de los requisitos funcionales en conceptos de software. La idea es identificar los objetos que conforman el sistema, centrndose en el comportamiento. En la siguiente figura se resalta las actividades que se llevan a cabo en el AOO.
ANLISIS
Figura 1.2. Flujo de trabajo del AOO.
CIBERTEC
10
1.2. Artefactos del Anlisis

Son muchos los artefactos que se elaboran en el flujo de trabajo del AOO. En el curso consideraremos los siguientes artefactos: Modelo de Anlisis. Elementos del modelo de anlisis: paquetes de anlisis, clases de anlisis y realizaciones de anlisis de casos de uso. Diagramas de realizaciones de anlisis de casos de uso: diagrama de clases y diagramas de comunicacin.
Artefacto
Descripcin
Representa la vista interna del sistema. Define un modelo de objetos que describe la realizacin de casos de uso, y que sirve como una abstraccin del modelo de diseo. Los paquetes del anlisis proporcionan un medio para organizar los artefactos del modelo de anlisis en piezas manejables. Un paquete contiene clases y realizaciones de casos de uso a nivel de anlisis. Es una clase utilizada para modelar la interaccin entre el entorno del sistema y su funcionamiento interno. Modela las partes del sistema que dependen de su entorno. Representa la lgica de negocio de la aplicacin, es decir, el control, la coordinacin y la secuencia entre objetos. Encapsula el comportamiento de uno o ms casos de uso. La entidad es una clase utilizada para modelar la informacin y comportamiento asociado que deben ser almacenados. Modela las partes del sistema que son independientes de su entorno. La realizacin de anlisis de un caso de uso es una colaboracin que describe cmo se realiza el caso de uso en trminos de clases de anlisis y sus interacciones.
Modelo de Anlisis
Paquete de Anlisis
Clase de Interfaz
Clase Control
Clase Entidad
Realizacin de Caso de Uso
El diagrama de clases describe la estructura de un caso de uso.

Diagrama de Clases
Tabla 1.1. Artefactos del Anlisis.
CIBERTEC
11
Diagrama de interaccin que describe el comportamiento del caso de uso centrado en las responsabilidades y colaboraciones entre los objetos.
Diagrama de Comunicacin
Tabla 1.1. Artefactos del Anlisis (Continuacin).
1.3. Modelo de Anlisis

El anlisis orientado a objetos se traduce en el modelo de anlisis, el cual es usado para representar la estructura global del sistema, describe la realizacin de casos de uso y sirve como una abstraccin del modelo de diseo. Durante el anlisis, se identifica de manera continua nuevos paquetes del anlisis, clases y requisitos comunes a medida que el modelo de anlisis evoluciona, y los paquetes de anlisis concretos continuamente se refinan y mantienen. Las actividades que se realizan para elaborar el modelo de anlisis son: Anlisis de la Arquitectura Anlisis de Casos de Uso Anlisis de Clases Anlisis de Paquetes
Segn Ivar Jacobson El modelo de anlisis es un nivel de diseo intermedio entre las etapas de captura de requisitos y la de diseo. Este modelo de anlisis no es un diagrama final que describe todos los posibles conceptos y sus relaciones, es un primer intento por definir los conceptos claves que describen el sistema. Este artefacto es opcional, pero tambin tiene a su vez la propiedad de ser temporal en el caso en que se planea su desarrollo. Su utilidad radica en que permite una apreciacin global conceptual del sistema. El modelo de anlisis puede contener: las clases y paquetes de anlisis, las realizaciones de los casos de uso, las relaciones y los diagramas. Es opcional detallar aqu las realizaciones de los casos de uso ya que stas pueden estar en el modelo de diseo donde se recomienda que se encuentren. A diferencia del modelo de casos de uso que captura la funcionalidad del sistema, el modelo de anlisis da forma a la arquitectura para soportar las funcionalidades que en el anterior modelo se expresan.
CIBERTEC
12
1.3.1. Caractersticas principales Proporciona un diseo preliminar, pues contiene paquetes que se usan para organizar el modelo de anlisis en piezas ms manejables, que representan abstracciones o subsistemas y una primera vista del diseo. Puede ayudar a descubrir la necesidad de clases adicionales. Proporciona una prueba de completitud a los casos de uso, antes de pasar al diseo. Proporciona un diseo preliminar de la arquitectura del sistema, denotando los paquetes de anlisis de alto nivel.
1.3.2. Modelo de Casos de Uso Vs. Modelo de Anlisis El siguiente cuadro muestra una comparacin entre el Modelo de Casos de Uso y el Modelo de Anlisis: Modelo de Casos de Uso
Descrito con el lenguaje del cliente. Vista externa del sistema. Estructurado por los casos de uso. Utilizado como contrato entre el cliente y los desarrolladores sobre que debera y que NO debera hacer el sistema. Puede contener redundancias, inconsistencias, entre los requisitos. Captura la funcionalidad del sistema, incluida la funcionalidad significativa para la arquitectura. Define los casos de uso que se analizarn con ms profundidad en el modelo de anlisis.
Modelo de Anlisis
Descrita en el lenguaje de los desarrolladores. Vista interna del sistema. Estructurado por clases y paquetes estereotipados. Utilizado por los desarrolladores para comprender como debera darse forma al sistema, es decir, cmo debe estar diseado e implementado. No debera contener redundancias, inconsistencias, entre los requisitos. Esboza como llevar a cabo la funcionalidad dentro del sistema, incluida la funcionalidad significativa para la arquitectura. Define las realizaciones de casos de uso, y cada una de ellas representa el anlisis de un caso de uso del modelo de casos de uso.
Cuadro 1.1. Comparacin del MCU Vs. MA
CIBERTEC
13
Resumen
La disciplina Anlisis y Diseo de RUP tiene como propsito: Transformar los requisitos en un diseo del sistema a crear. Definir una arquitectura robusta para el sistema. Adaptar el diseo para que funcione en el ambiente de implementacin, disendolo para un desempeo esperado.
El objetivo del anlisis es comprender el problema y comenzar a desarrollar un modelo visual de lo que se est tratando de construir, independiente de la tecnologa a utilizar en la aplicacin, como el lenguaje de programacin. El anlisis se centra en la traduccin de los requisitos funcionales en conceptos de software. La idea es identificar los objetos que conforman el sistema, centrndose en el comportamiento. El modelo de anlisis, es usado para representar la estructura global del sistema, describe la realizacin de casos de uso, sirve como una abstraccin del modelo de diseo.
CIBERTEC
14
2. ANLISIS DE LA ARQUITECTURA
El rol responsable de esta tarea es el Arquitecto de software. Esta tarea permite definir una arquitectura candidata basada en la experiencia obtenida de sistemas similares o en dominios del problema similares, y restringir las tcnicas arquitectnicas a ser usadas en el sistema. Se definen los diagramas de las vistas arquitectnicas, mecanismos claves y los modelos para el sistema. Cabe destacar que analizar la arquitectura resulta beneficioso en el caso donde se desarrollen sistemas que no se hayan hecho antes. El propsito del anlisis de la arquitectura es esbozar el modelo de anlisis y la arquitectura mediante la identificacin de paquetes del anlisis, clases de anlisis de entidad evidentes y requisitos especiales comunes.
2.1. Pasos en el Anlisis de la arquitectura

El Anlisis de la Arquitectura se realiza como sigue: Identificacin de los paquetes de anlisis Definicin de las dependencias entre los paquetes de anlisis Identificacin de clases de entidad obvias por cada paquete de anlisis Identificacin de mecanismos de anlisis Identificacin de las caractersticas fundamentales de un requisito especial.
2.1.1. Identificacin de paquetes de anlisis Los paquetes de anlisis constituyen una divisin del sistema de software que tiene sentido desde el punto de vista de los expertos en el dominio. La descomposicin del software en paquetes se establece cuando uno tiene una idea que considera suficientemente fiable de la cantidad de trabajo y del nmero y la complejidad de los diagramas, situacin a la cual se puede haber llegado tanto al principio de la etapa de anlisis como un tiempo despus. Una identificacin inicial de los paquetes del anlisis se hace de manera natural basndonos en los requisitos funcionales y en el dominio del problema, es decir, en la aplicacin o negocio que estamos considerando. Debido a que los requisitos funcionales se capturan en la forma de casos de uso, una forma directa de identificar paquetes del anlisis es asignar la mayor parte de un cierto nmero de casos de uso a un paquete concreto. Entre las asignaciones adecuadas de casos de uso a un paquete en concreto se tiene: 1. Los casos de uso requeridos para dar soporte a un determinado proceso de negocio. 2. Los casos de uso requeridos para dar soporte a un determinado actor del sistema. Para identificar los paquetes se basa en lo siguiente: 1. Tener un diagrama de casos de uso con los roles bien definidos.
CIBERTEC
15
2. Los casos de uso que estn bajo la responsabilidad de un actor deben tener contenidos estrechamente relacionados. 3. Los casos de uso que estn vinculados mediante relaciones de generalizacin deben pertenecer al mismo paquete.
Figura 1.3. Casos de Uso con relacin de generalizacin. 4. Los casos de uso vinculados mediante relaciones de extensin y slo se extienden a partir de un caso de uso base, que deben pertenecer al mismo paquete del caso de uso base.
Figura 1.4. Casos de Uso con relacin extend. 5. Los casos de uso incluidos tienden a generar su propio paquete la mayor parte de veces. Si los casos de uso base que incluyen al caso de uso son funcionalidades con distintos contenidos, entonces se debe crear un paquete para el caso de uso incluido.
<<include>>
Figura 1.5. Casos de uso con relacin incluye.
CIBERTEC
16
2.1.2. Definicin de dependencias entre paquetes de anlisis El objetivo es conseguir paquetes que sean relativamente independientes y dbilmente acoplados pero que posean una cohesin interna alta. Es inteligente intentar reducir el nmero de relaciones entre clases en paquetes diferentes debido a que ello reduce las dependencias entre paquetes.
Figura 1.6. Caractersticas de los paquetes de anlisis. Los paquetes identificados se organizarn en la Capa de Aplicacin, la cual se subdivide en dos capas internas: a) Capa Especfica: Aqu se ubican los paquetes identificados con excepcin de los reutilizables (Nivel Superior). b) Capa General: Aqu se ubican los paquetes reutilizables y los paquetes de servicio (Nivel Inferior). Para identificar las dependencias entre paquetes es conveniente revisar el diagrama de casos de uso estructurado segn anlisis, esto con el fin de ubicar las relaciones que existen entre los casos de uso. Las dependencias se crean a partir de los paquetes de anlisis que contienen los casos de uso base. A continuacin se muestra un ejemplo de distribucin de paquetes en las capas de la aplicacin y sus dependencias para definir la arquitectura de anlisis.
Figura 1.7. Capas y dependencias entre paquetes de anlisis.
CIBERTEC
17
2.1.3. Identificacin de clases de entidad obvias Solo se debe concentrar en identificar las clases del tipo entity por cada caso de uso. La mayora de las clases se identificarn al crear las realizaciones de caso de uso (en la actividad del anlisis de caso de uso). Se debe tener cuidado de no identificar demasiadas clases en esta etapa y quedar atrapados en demasiados detalles, pues ese trabajo es para el anlisis de casos de uso. Ejemplo: Reserva, Habitacion DetalleReserva Clases del dominio del problema Clase de la asociacin entre Reserva y Habitacion
2.1.4. Identificacin de mecanismos de anlisis El arquitecto es el responsable de identificar los mecanismos de anlisis comunes de forma que los desarrolladores puedan referirse a ellos como requisitos especiales sobre realizaciones de CU y clases del anlisis determinadas. Los mecanismos de anlisis a considerar son sobre: Persistencia Comunicacin Distribucin y concurrencia Gestin de transacciones Sincronizacin y control de procesos Intercambio de informacin Formato de conversin Caracterstica de seguridad Tolerancia de fallos Redundancia 2.1.5. Identificacin de caractersticas fundamentales de mecanismos de anlisis En esta etapa se debe indicar las caractersticas de cada mecanismo de anlisis. Por ejemplo, las caractersticas de un requisito de persistencia son: Granularidad: Rango de tamao de objetos persistentes. Volumen: Nmero de objetos persistentes. Duracin: Periodo de persistencia. Mecanismo de acceso: Cmo identificar a un objeto. Frecuencia de acceso: Identificar qu objetos son ms o menos constantes y qu objetos son actualizados frecuentemente. Confiabilidad De la misma manera se trabaja con los otros requisitos especiales identificados en el paso anterior.
CIBERTEC
18
Identifique los paquetes de anlisis y sus dependencias para realizar la Arquitectura de Anlisis a partir del siguiente Diagrama de Caso de Uso Estructurado:
Caso: Cotizacin
CIBERTEC
19
Resumen
El propsito del anlisis de la arquitectura es esbozar el modelo de anlisis y la arquitectura mediante la identificacin de paquetes del anlisis, clases anlisis del tipo entidad evidentes y requisitos especiales comunes. Las actividades del Anlisis de la Arquitectura son como sigue: Identificacin de paquetes de anlisis. Definicin de las dependencias entre los paquetes de anlisis. Identificacin de clases de entidad obvias por cada paquete de anlisis. Identificacin de los requisitos especiales comunes. Identificacin de las caractersticas fundamentales de un requisito especial.
Los paquetes se usan para organizar el modelo de anlisis en piezas ms manejables, que representan abstracciones o subsistemas y una primera vista del diseo. Un paquete de anlisis debe ser dbilmente acoplado y altamente cohesivo. Los paquetes de anlisis identificados se organizarn en la Capa de Aplicacin, la cual se subdivide en dos capas internas: Capa Especfica: Aqu se ubican los paquetes identificados con excepcin de los reutilizables (Nivel Superior). Capa General: Aqu se ubican los paquetes reutilizables y los paquetes de servicio (Nivel Inferior).
CIBERTEC
20
3. ANLISIS DE CASOS DE USO

El Anlisis de Caso de Uso, es el proceso de examinar los casos de uso para descubrir los objetos y clases de anlisis del sistema a desarrollar. Las clases identificadas deben agruparse en los paquetes segn criterios de Arquitectura de Software. El rol responsable de esta tarea es el Diseador. Esta tarea describe cmo desarrollar las Realizaciones de los Casos de Uso del nivel de anlisis de un caso particular. Tiene los siguientes propsitos:

Identificar las clases que llevan a cabo el flujo de eventos de un caso de uso. Distribuir el comportamiento de casos de uso a las clases identificadas, usando realizaciones de casos de uso a nivel de anlisis. Identificar atributos, responsabilidades y relaciones entre las clases. Observar los mecanismos arquitectnicos.
Anlisis de Casos de Uso
Figura 1.8. Anlisis de Casos de Uso.
3.1. Pasos en el Anlisis de casos de uso

Para llevar a cabo el anlisis de casos de uso se realiza lo siguiente: Crear la realizacin de anlisis de casos de uso. Encontrar clases de anlisis del comportamiento de casos de uso. Crear el diagrama de clases (estructura del caso de uso). Crear el diagrama de comunicacin (comportamiento del caso de uso).
CIBERTEC
21
3.1.1. Crear la realizacin de anlisis de casos de uso Una realizacin de caso de uso describe cmo un caso de uso en particular es modelado, primero en el modelo de anlisis y despus en el modelo del diseo, en trminos de objetos colaboradores. En una realizacin de caso de uso se especifica qu clases deben ser construidas para implementar cada caso de uso. En UML, las realizaciones de caso de uso se representan con colaboraciones estereotipadas. El icono para una colaboracin es una elipse con lneas punteadas que se sita al lado izquierdo del nombre de la colaboracin, tal como se ilustra en la siguiente figura.
Figura 1.9. Colaboracin. 3.1.2. Encontrar clases de anlisis Este paso se realiza por cada caso de uso. Para ello, se analizan los escenarios de Caso de Uso para identificar las clases que participan en ellos.
Especificacin de Caso de Uso
Figura 1.10. Un flujo completo de un caso de uso debe distribuirse en clases de anlisis. Tal como se muestra en la figura 2.3, a partir de una Especificacin de Caso de Uso (ECU) se pueden obtener las clases de anlisis. Existen tres tipos de clases de anlisis: boundary, control y entity. A continuacin se describe a cada una de ellas: Boundary. Describe una interaccin entre el sistema con los usuarios y con otros sistemas. Pueden representar abstracciones de formularios, de protocolos de comunicaciones con otros sistemas o interfaces de dispositivos. Las caractersticas importantes de este tipo de clase cuando modela un API con otro sistema son: a. Las funciones que provee el otro sistema.
CIBERTEC
22
b. La informacin a ser pasada al otro sistema. c. El protocolo de comunicacin usado para hablar con el otro sistema. Por regla general, al menos una clase boundary sirve como medio de comunicacin entre un actor y el correspondiente caso de uso. Ejemplo: En el caso de uso Procesar Facturacin hay informacin que debe ser enviada a un Sistema de Facturacin externo. Se puede crear una clase de interfaz llamada CI_SistemaFacturacion para representar la interfaz al sistema externo. Entity. Se emplean para modelar aquella informacin o comportamiento que posee una vida larga en el sistema. Normalmente estn asociadas a algn fenmeno o concepto, como una persona, un objeto del mundo real, o un suceso del mundo real. El nmero de clases entidad variar dependiendo de los conceptos que requieren almacenamiento persistente dentro del caso de uso. Estas clases sufren un proceso de refinamiento a medida que se ubica a la misma clase entidad dentro de distintas realizaciones de caso de uso. Ejemplo: En el caso de uso Mantener empleados en el cual se puede registrar, modificar o desactivar empleados es evidente que la informacin que debe ser manipulada es del empleado. Para ello se crea una clase entidad Empleado. Control. Se utilizan para modelar la coordinacin, secuencia, transacciones y control de otros objetos. Tambin para representar derivaciones y clculos complejos, cmo la lgica de negocio, que no pueden asociarse a ninguna informacin concreta de larga duracin almacenada por el sistema. Por regla general se trata de encapsular la lgica de control de un caso de uso dentro de una clase Control. Suele ser un buen hbito de diseo utilizar nicamente una clase control por cada caso de uso, y as encapsular en un slo elemento la lgica del caso de uso correspondiente. Por otro lado, todos los casos de uso ubicados en un mismo paquete de anlisis comparten la misma clase control. Ejemplo: En un paquete de anlisis denominado Evaluacin se ubica los casos de uso Evaluar empleado, Procesar evaluacin de desempeo y Consultar estadsticas de Evaluaciones. Para los tres casos de uso se crea una clase control CC_Evaluacion que coordina el trabajo de los tres casos de uso.
CIBERTEC
23
Segn la metodologa OOSE de Ivan Jacobson, las clases de anlisis son clases estereotipadas para crear modelos ideales de objetos. Esta metodologa se basa en el patrn MVC (Model-View-Controller / Modelo Vista Controlador), que define clases enfocadas a la separacin de responsabilidades para conseguir componentes extensibles y reutilizables. En la siguiente figura se muestran los tipos de clases enfocados a los elementos del patrn MVC.
Figura 1.11. Clases de anlisis enfocadas al patrn MVC. Cada clase de anlisis debe tener un estereotipo1, como mecanismo que el UML provee para extender la notacin. Los estereotipos se muestran en el compartimiento del nombre de la clase encerrado entre <<>> (guillemets) o con un icono; tambin se pueden representar con la forma de la imagen del icono en lugar de una clase. Estas representaciones se muestran a continuacin:
Figura 1.12. Clases de interfaz (boundary).
Figura 1.13. Clases de control (control).

1
Un estereotipo (Stereotype en ingls), es un nuevo tipo de elemento de modelado que extiende la semntica del meta modelo, basados en tipos existentes o clases del meta modelo.
CIBERTEC
24
Figura 1.14. Clases de entidad (entity).
3.1.3. Crear el diagrama de clases Este paso permite representar las clases participantes y sus relaciones para un determinado caso de uso.
Figura 1.15. Diagrama de clases de anlisis.
3.1.4. Crear diagramas de comunicacin El diagrama de comunicacin es un tipo de diagrama de interaccin; en esta etapa no se usa diagramas de secuencia porque no es importante la cronologa de las interacciones. Un diagrama de comunicacin muestra la colaboracin dinmica entre los objetos, es decir, describe el comportamiento de un caso de uso mostrando explcitamente las relaciones de los objetos participantes. La realizacin de un caso de uso puede tener uno o ms diagramas de comunicacin, esto es debido a que se representa el flujo bsico, subflujos y flujos alternativos. Por ejemplo, a continuacin se muestra el diagrama de comunicacin para describir el comportamiento del caso de uso Mantener Competencias.
CIBERTEC
25
Figura 1.16. Diagrama de comunicacin.
CIBERTEC
26
3.2. Caso prctico

A continuacin se presenta un caso prctico para identificar clases de anlisis a partir de un escenario de caso de uso.
Registrar Inscripcin en Cursos
1. Escenario : Registrar inscripcin en cursos Crear horario
2. Encontrando objetos entidad Los objetos de Entidad se identifican examinando los sustantivos y frases de stos en los escenarios Los sustantivos encontrados pueden ser : Objetos especficos genricos Descripciones del estado de un objeto Entidades externas y/o actores 3. Filtrando sustantivos Cuando se identifican sustantivos tengan presente que: Varios trminos pueden referirse al mismo objeto Un trmino puede referirse a ms de un objeto El lenguaje natural es muy ambiguo. De esta manera se pueden identificar muchos objetos sin importancia.
CIBERTEC
27
La lista de sustantivos se debe filtrar. Advertencia: Cualquier sustantivo puede ser convertido en verbo; cualquier verbo puede ser convertido en sustantivo. Los resultados dependen en gran parte de la capacidad de redaccin del o los autores. 4. Sustantivos del Escenario
5. Filtrando el escenario
CIBERTEC
28
6. Anlisis de los objetos filtrados en escenario
7. Creando Clases Entidad Los objetos de entidad encontrados se agrupan en clases: - Los objetos genricos representan clases. - Las instancias de objetos con estructura y/o comportamiento similar se agrupan en clases. Este es solo un intento inicial: - Las clases pueden cambiar a medida que se examinan ms escenarios. 8. Clases entidad identificadas en el escenario del caso de uso Una materia ofrecida por la universidad que es parte de un Plan de Estudios
Cursos a ensear en un semestre
Secciones de cursos escogidas para un semestre por un estudiante Estudiantes inscritos en una seccin de curso ofrecido
Un curso ofrecido en un lugar y horarios especficos
CIBERTEC
29
9. Encontrando Clases Boundary (limite) Para cada par de actor fsico y escenario cree una clase boundary. - Durante el diseo, esta clase se transformar dependiendo de los mecanismos de interfase escogidos. Aada ms clases boundary para modelar navegacin entre interfaces (por ejemplo pantallas) en el mismo caso de uso. Ejemplo : - Al estudiante se le presentan diferentes opciones en el caso de uso Registrar Inscripcin en Cursos. Se crea una clase boundary llamada CI_Inscripcion para permitirle al estudiante seleccionar la opcin deseada. El estudiante debe ingresar las secciones de los cursos escogidos al sistema en el escenario Crear Horario Se crea una clase boundary llamada CI_Horario para recibir y procesar la informacin ingresada por el estudiante.
10. Candidatos a Clase Boundary en el escenario del CU
11. Bosquejo de pantalla Se pueden crear storyboards, prototipos y bosquejos de pantallas para comunicar el look & feel de la clase boundary al usuario. Por ejemplo a continuacin se muestra la interfaz CI_Horario.
CIBERTEC
30
12. Encontrando Clases Control Las clases de control contienen informacin de secuencia para coordinar los casos de uso. En este nivel de anlisis, tpicamente se aade una clase control para cada caso de uso. Es responsable del flujo de eventos en el caso de uso. Las clases de control NO deben ejecutar funciones cuya responsabilidad pertenece a clases de entidad o de lmite. Esto es solo un corte inicial. A medida que se desarrollan ms casos de uso y escenarios, las clases de control pueden eliminarse, dividirse o combinarse.
13. Clases Control en el CU Se aade una clase de control llamada CC_Inscripcion.
Recibe informacin de la clase boundary CI_Horario Para cada opcin ingresada o Valida que la seccin este abierta o Valida que no existan conflictos de horario o Valida que el curso este en el plan de estudio del estudiante o Valida que los prerrequisitos se cumplan o Asigna al estudiante a la Seccin
14. Diagramas de Vistas de Clases Participantes (VOPC) Un diagrama de clases muestra una o ms clases en un mismo plano, usando la nomenclatura que se ha presentado antes. Cada Realizacin de Caso de Uso tiene uno o ms diagramas de clases que muestran las clases participantes en el CU y sus relaciones. Tales diagramas son llamados Vista de Clases Participantes (View of Participating Classes) lo que se resume como VOPC.
15. En el siguiente grfico se muestra las clases participantes en el caso de uso Registrar Inscripcin en Cursos
CIBERTEC
31
1. A partir de la Especificacin de Caso de Uso realice los siguientes diagramas: a) Diagrama de clases de anlisis b) Diagrama de comunicacin del flujo bsico c) Diagrama de comunicacin de los subflujos d) Diagrama de comunicacin de los flujos alternativos
ESPECIFICACIN DE CASO DE USO: Mantener Competencias

1. Descripcin El caso de uso permite mantener actualizado el registro de las Competencias que se utilizan como criterios de evaluacin de un empleado. De acuerdo a su necesidad el Gerente RRHH puede agregar, actualizar y desactivar una competencia. 2. Actor(es) Gerente RRHH 3. Flujo de Eventos El caso de uso se inicia cuando el Gerente RRHH selecciona la opcin Competencias en la interfaz del men principal. 3.1. Flujo Bsico 1. El sistema muestra la interfaz MANTENER COMPETENCIA con la lista de competencias con los campos: cdigo, tipo, nombre y descripcin. Adems muestra las opciones: Agregar Competencia, Actualizar Competencia y Desactivar Competencia. 2. Si el Gerente RRHH elige una competencia: a. Si elige Actualizar ver el Subflujo Actualizar Competencia. b. Si elige Desactivar ver el Subflujo Desactivar Competencia. 3. Si el Gerente RRHH NO elige una competencia: a. Si elige Agregar ver el Subflujo Agregar Competencia. 4. El sistema finaliza el caso de uso. 3.2. Subflujos 3.2.1. Agregar Competencia 1. El sistema muestra la interfaz COMPETENCIA con los siguientes campos: cdigo de la competencia (slo lectura), tipo, nombre y descripcin. Adems muestra las opciones: Aceptar y Cancelar. 2. El Gerente RRHH ingresa los datos de la Competencia. 3. El Gerente RRHH selecciona la opcin Aceptar. 4. El sistema valida los datos ingresados. 5. El sistema genera un nuevo cdigo de Competencia. 6. El sistema graba un nuevo registro de Competencia y muestra el MSG Competencia creada con cdigo Nro. 999999. 7. El Gerente RRHH cierra la interfaz COMPETENCIA y regresa a la interfaz MANTENER COMPETENCIAS con la lista de Competencias actualizada y el subflujo finaliza. 3.2.2. Actualizar Competencia 1. El sistema muestra los datos de la Competencia seleccionada en la interfaz COMPETENCIA: cdigo de la competencia (slo lectura), tipo,
CIBERTEC
32
2. 3. 4. 5. 6.
nombre y descripcin. Adems muestra las opciones: Aceptar y Cancelar. El Gerente RRHH actualiza los datos de la Competencia. El Gerente RRHH selecciona la opcin Aceptar. El sistema valida los datos ingresados de la Competencia. El sistema actualiza el registro de Competencia y muestra el MSG Competencia actualizada satisfactoriamente. El Gerente RRHH cierra la interfaz COMPETENCIA y regresa a la interfaz MANTENER COMPETENCIAS con la lista de Competencias actualizada y el subflujo finaliza.
3.2.3. Desactivar Competencia 1. El sistema muestra el MSG: Est seguro que desea desactivar la(s) Competencia(s) seleccionada(s)?. 2. El gerente RRHH selecciona la opcin YES para confirmar la desactivacin. 3. El sistema actualiza el registro de la(s) Competencia(s) en estado Desactivada. 4. El sistema muestra la interfaz MANTENER COMPETENCIA con la lista de Competencias actualizada y termina el subflujo. 3.3. Flujos Alternativos 1. Datos de la Competencia Invlidos En el paso 4 de los subflujos, Agregar y Actualizar Competencia, si los datos ingresados son nulos o invlidos el sistema muestra el MSG: Se han encontrado datos invlidos y los subflujos continan en el paso 2. 2. Competencias ya existe En el paso 4 de los subflujos, Agregar Competencia, si el sistema detecta que la competencia ya existe muestra el MSG: Competencia ya existe y el subflujo finaliza. 3. No confirma Desactivacin En el paso 2 de los subflujos, Desactivar Competencia, si el Gerente RRHH selecciona NO, finaliza el subflujo. 4. Precondiciones 1. El Gerente RRHH est identificado en el sistema. 2. Lista disponible de Competencias. 5. Poscondiciones 1. En el sistema quedar registrada la nueva Competencia. 2. En el sistema quedar actualizado el registro de la Competencia. 3. En el sistema quedar desactivada la Competencia. 6. Puntos de Extensin Ninguno. 7. Requisitos Especiales Ninguno. 8. Prototipos -
CIBERTEC
33
Resumen
Para llevar a cabo el anlisis de casos de uso se realiza lo siguiente: Crear la realizacin de anlisis de casos de uso. Encontrar clases de anlisis del comportamiento de casos de uso. Crear el diagrama de clases (estructura del caso de uso). Crear el diagrama de comunicacin (comportamiento del caso de uso). Una realizacin de casos de uso describe cmo un caso de uso en particular es modelado dentro del modelo de anlisis primero y despus dentro del modelo de diseo, en trminos de objetos colaboradores. Existen tres tipos de clases de anlisis: Interfaz (boundary), Control (control) y Entidad (entity).
Si desea saber ms acerca de estos temas, puede consultar el siguiente libro. VISUAL MODELING WITH IBM RATIONAL ARCHITECT SOFTWARE ARCHITECT AND UML por Terry Quatrani y Jim Palistrant En el captulo 6 de este libro se describe cmo crear un modelo de anlisis.
CIBERTEC
34
4. ANLISIS DE CLASES
El objetivo de esta actividad es describir cada una de las clases que se ha encontrado en el anlisis de casos de uso, identificando las responsabilidades que tienen asociadas, sus atributos, y las relaciones entre ellas.
4.1. Pasos a realizar

Los pasos que se realizan en esta actividad son:
Identificacin de responsabilidades y atributos Identificacin de asociaciones y agregaciones Identificacin de generalizaciones
4.1.1. Identificacin de responsabilidades y atributos El objetivo de esta tarea es identificar las responsabilidades y atributos relevantes de una clase. Las responsabilidades de una clase definen la funcionalidad de esa clase, y estn basadas en el estudio de los papeles que desempean sus objetos dentro de los distintos casos de uso. A partir de estas responsabilidades, se puede comenzar a encontrar las operaciones que van a pertenecer a la clase. stas deben ser relevantes, simples, y participar en la descripcin de la responsabilidad. Los atributos de una clase especifican propiedades de la clase, y se identifican por estar implicados en sus responsabilidades. Los tipos de estos atributos deberan ser conceptuales y conocidos en el dominio. De manera opcional, se elabora una especificacin para cada clase, que incluye: la lista de sus operaciones y las clases que colaboran para cubrir esas operaciones y una descripcin de las responsabilidades, atributos y operaciones de esa clase. Para aquellas clases cuyo comportamiento dependa del estado en el que se encuentren se realiza, tambin de manera opcional, un diagrama de transicin de estados. 4.1.2. Identificacin de asociaciones y agregaciones En esta tarea se estudian los mensajes establecidos entre los objetos del diagrama de interaccin para determinar qu asociaciones existen entre las clases correspondientes. Estas asociaciones suelen corresponderse con expresiones verbales incluidas en las especificaciones. Las relaciones surgen como respuesta a las demandas en los distintos casos de uso, y para ello puede existir la necesidad de definir agregaciones y herencia entre objetos. Una asociacin esta caracterizada por: Los papeles que desempea. Su direccionalidad, que representa el sentido en el que se debe interpretar.
CIBERTEC
35
Su cardinalidad, que representa el nmero de instancias implicadas en la asociacin. Dichas caractersticas pueden obtenerse a partir de la especificacin de los casos de uso. 4.1.3. Identificacin de generalizaciones El objetivo de esta tarea es representar una organizacin de las clases que permita una implementacin sencilla de la herencia y una agrupacin semntica de las diferentes clases.
4.2. Tarjetas Clase Responsabilidad Colaboracin (CRC)

A fines de la dcada de 1980, uno de los centros ms grandes de tecnologa de objetos era el laboratorio de investigacin de Tektronix, en Portland, Oregn, Estados Unidos. Este laboratorio tena algunos de los principales usuarios de Smalltalk y muchas de las ideas clave de la tecnologa de objetos se desarrollaron all. Dos de sus programadores renombrados de Smalltalk eran Ward Cunningham y Kent Beck. Tanto Cunningham como Beck estaban y siguen preocupados por cmo ensear los profundos conocimientos de Smalltalk que haban logrado. De esta pregunta sobre cmo ensear objetos surgi la sencilla tcnica de las tarjetas de Clase-Responsabilidad-Colaboracin (CRC). En lugar de utilizar diagramas para desarrollar modelos, como lo hacan la mayora de los metodlogos, Cunningham y Beck representaron las clases en tarjetas 4 x 6 [pulgadas]. Y en lugar de indicar atributos y mtodos en las tarjetas, escribieron responsabilidades y colaboradores. 4.2.1. Descripcin de las tarjetas CRC La tarjeta se divide en tres compartimientos, tal como se muestra en la figura 4.1. En el compartimiento superior izquierdo se escribe el nombre de la clase candidata; en el compartimiento inferior izquierdo, las responsabilidades; y en el derecho, los colaboradores.
Figura 1.17. Tarjeta de Clase-Responsabilidad-Colaboracin (CRC). Las responsabilidades de una clase pueden recopilarse combinando todos los roles que cumple en las diferentes realizaciones de caso de uso. Identificar las realizaciones de caso de uso en las cuales participa mediante el estudio de sus diagramas de clases e interaccin.
CIBERTEC
36
En el diagrama de comunicacin cuando se tiene que describir los flujos bsico y alternativos, un mensaje debera reflejar el propsito del objeto invocante en la interaccin con el objeto invocado. Este propsito es el origen de una responsabilidad del objeto receptor y podra llegar hacer el nombre de una responsabilidad. Los colaboradores son otras clases que pueden ayudar con esta clase para realizar una parte de la funcionalidad del sistema. El compartimiento de colabores proporciona una forma de grabar reacciones entre clases. Uno de los principales beneficios de las tarjetas de CRC es que alientan la disertacin animada entre los desarrolladores. Son especialmente eficaces cuando se est en medio de un caso de uso para ver cmo lo van a implementar las clases. Los desarrolladores escogen tarjetas a medida que cada clase colabora en el caso de uso. Conforme se van formando ideas sobre las responsabilidades, se pueden escribir en las tarjetas. Es importante pensar en las responsabilidades, ya que evita pensar en las clases como simples repositorios de datos, y ayuda a que el equipo se centre en comprender el comportamiento de alto nivel de cada clase. 4.2.2. Limitaciones de las tarjetas CRC Aunque las tarjetas CRC pueden ser una herramienta poderosa para empezar el diseo, tienen limitaciones inherentes. El primer problema es que no tienen un escalamiento exitoso. En un proyecto muy complejo, puede agobiarse con las tarjetas CRC; el simple hecho de mantener un registro de todas ellas puede ser difcil. El problema se torna ms difcil an al tratar de mantener sincronizados entre s, a las tarjetas y los modelos de UML de las clases. Por otro lado, las tarjetas CRC tampoco capturan la interrelacin entre clases. Aunque es cierto que todas las colaboraciones se toman en cuenta, la naturaleza de la colaboracin no se modela bien. Al ver las tarjetas CRC no se puede saber quin crea a quin, si las clases se agregan unas a otras, o si una responsabilidad corresponde a una o ms clases colaboradoras. En resumen, las tarjetas CRC son un buen inicio por mantener documentadas las clases de anlisis, pues a partir de ellas se tendr una visin general del comportamiento de una clase con respecto de otras, pero una vez que se tenga conocimiento de las clases y lleguen a su etapa de diseo, estas tarjetas ya no les sern tiles y quiz ya no necesitarn actualizarlas.
CIBERTEC
37
4.3. Caso prctico

A continuacin se explicar cmo confeccionar las tarjetas CRC para las clases participantes del caso de uso Pagar Prstamos de Terceros. PASO 1: Revisar la Especificacin del caso de uso
Especificacin de Caso de uso: Pagar Prstamos de Terceros

1. Breve descripcin El caso de uso permite a un Cliente del Banco efectuar el pago de prstamos de terceros con cargo en su cuenta de ahorros. Adems, actualiza el saldo contable en el Sistema Contable. 2. Actores Cliente. 3. Flujo de Eventos 3.1. Flujo Bsico 1. El caso de uso comienza cuando el Cliente selecciona la opcin Pago de Prstamos y la sub opcin Prstamos de Terceros en la interfaz del men principal. 2. El sistema muestra la interfaz Pago de Prstamos de Terceros con los campos nmero de cuenta de prstamo, monto y moneda. Adems, muestra una lista con las cuentas de cargo (cuenta de ahorros). 3. El Cliente ingresa cuenta de prstamo, monto y selecciona moneda. 4. El Cliente selecciona una cuenta de cargo. 5. El Cliente selecciona continuar. 6. El sistema verifica saldo de cuenta. 7. El sistema muestra la interfaz Confirmacin de Pago con los datos: cuenta del prstamo, cuenta de cargo, monto y moneda del prstamo. Adems muestra el mensaje Ingresar su clave para confirmar. 8. El cliente ingresa su clave de acceso. 9. El cliente confirma la operacin. 10. El sistema registra la transaccin con el Nmero de Operacin, cuenta de prstamo, cuenta de cargo, monto, moneda del prstamo y fecha y hora de la transaccin. 11. El sistema actualiza el saldo contable en el Sistema Contable y actualiza el saldo de la cuenta de cargo. 12. El sistema muestra el nmero de la operacin y el MSG:Pago de prstamo efectuado correctamente. 13. El cliente selecciona Salir, se cierra la interfaz y el caso de uso finaliza. 3.2. Flujos Alternativos 3.2.1. Pago no efectuado Si el sistema detecta que el saldo de la cuenta de cargo es insuficiente para realizar el pago, el sistema muestra el MSG Saldo insuficiente para efectuar pago y el caso de uso contina en el paso 2. 4. Pre Condiciones 1. El cliente logeado al sistema con su nmero de tarjeta y clave. 2. Disponible las cuentas de ahorro (cuentas de cargo).
CIBERTEC
38
5. Post Condiciones 1. En el sistema quedar registrado la transaccin. 2. En el sistema quedar actualizado el saldo de la cuenta de ahorros. 3. Se actualizar el saldo contable en el Sistema Contable. 6. Puntos de extensin 1. En el paso 9, si la moneda de la cuenta de cargo es diferente a la del prstamo, el sistema extiende al caso de uso Convertir moneda a una cuenta de ahorros del cliente.
7. Requisitos Especiales 1. Alta seguridad en el manejo de las claves y cuentas. 8. Prototipos -
PASO 2: Realizar el diagrama de clases
CIBERTEC
PASO 3: Realizar el diagrama de comunicacin del flujo bsico y del flujo alternativo Flujo Bsico
ANLISIS Y DISEO DE SISTEMAS I - TEORA
40
PASO 4: Confeccionar las tarjetas CRC por cada clase de anlisis Se empezar a realizar las tarjetas CRC en orden alfabtico por tipo de clase. Primero empezaremos con los boundary, luego con la clase control y al final con los entity.
Nombre de Clase: CI_ConfirmacionPago 1. 2. 3. 4. 5. 6. Responsabilidad Solicitar clave de acceso Solicitar la confirmacin de operacin Mostrar interfaz con datos del pago Mostrar mensaje Ingresar clave Mostrar nro. de transaccin Mostrar mensaje Pago efectuado correctamente Colaboradores CC_Prestamo
Nombre de Clase: CI_MenuPrincipal Responsabilidad 1. Solicitar la seleccin de Pago de Prstamos/Prstamos Personales Colaboradores CC_Prestamo
Nombre de Clase: CI_PagoPrestamoTerceros 1. 2. 3. 4. 5. 6. 7. 8. Responsabilidad Solicitar la seleccin de Continuar Solicitar la seleccin de moneda Solicitar la seleccin de cuenta de cargo Solicitar cuenta de prstamos Solicitar monto Mostrar lista de monedas Mostrar cuentas de ahorros Mostrar mensaje Saldo insuficiente Colaboradores CC_Prestamo
CIBERTEC CIBERTEC
ANLISIS Y DISEO DE SISTEMAS II TEORA
41
Nombre de Clase: CI_SistContable Responsabilidad 1. Actualizar saldo contable Colaboradores CC_Prestamo
Nombre de Clase: CC_Prestamo 1. 2. 3. 4. 5. 6. Responsabilidad Cargar monedas Cargar cuentas de ahorros Verificar saldo de cuenta de ahorro Verificar clave de acceso Registrar transaccin Actualizar saldos de cuentas Colaboradores CI_MenuPrincipal CI_PagoPrestamoTerceros CI_ConfirmacionPago CI_SistemaContable TarjetaXCliente Moneda CtaAhorros Transaccin
Nombre de Clase: CtaAhorros Responsabilidad 1. Obtener cuentas de ahorros 2. Obtener saldos 3. Disminuir saldos Colaboradores CC_Prestamo
Nombre de Clase: Moneda Responsabilidad 1. Obtener monedas Colaboradores CC_Prestamo
Nombre de Clase: TarjetaXCliente Responsabilidad 1. Obtener clave de acceso Colaboradores CC_Prestamo
Nombre de Clase: Transaccion Responsabilidad 1. Obtener mximo nmero de transaccin 2. Guardar datos Colaboradores CC_Prestamo
CIBERTEC
42
A partir de la Especificacin de Caso de Uso realice los siguientes artefactos: 1. Diagrama de clases de anlisis 2. Diagrama de comunicacin del flujo bsico 3. Diagrama de comunicacin de los flujos alternativos 4. Tarjeta CRC de las clases
Especificacin de caso de uso: Reservar pistas de juego

1. Descripcin: El caso de uso permite al encargado de reservas de un club de deportes, registrar una reserva de pista para un socio. El sistema se comunica con el Sistema de Cuentas por Cobrar (SCC), para registrar las reservas pendientes de pago del socio. 2. Actores Encargado de reservas. 3. Flujo de Eventos 3.1. Flujo Bsico 1. El caso de uso comienza cuando el Encargado de reservas selecciona la subopcin Reservar pistas de la opcin Reservas de la interfaz del men principal. 2. El sistema muestra la interfaz RESERVAS PISTAS con una Lista de todas las reservas de pistas del da, ordenadas por hora prevista, y campos para realizar una reserva. Datos de la lista son: nmero de reserva, nombre completo del socio que reserv, nmero de pista, hora de entrada y nmero de horas que estar ocupada la pista. Datos de la Reserva son: cdigo de socio, fecha y hora de reserva, nmero de pista y nmero de horas que estar ocupada la pista. Adems presenta las opciones: Grabar reserva, Buscar socio y Consultar disponibilidad de pistas. 3. El Encargado de reservas ingresa el cdigo del socio. 4. El Encargado de reservas selecciona Consultar disponibilidad de pistas. 5. El sistema incluye el caso de uso Consultar disponibilidad de pistas. 6. El sistema muestra la fecha y hora de reserva, nro. de pista y nro. de horas que estar ocupada la pista. 7. El Encargado de reservas selecciona Grabar reserva. 8. El sistema valida los datos ingresados. 9. El sistema genera el nmero de reserva y registra la reserva de pista, registra el estado de la pista como reservada en la fecha y horas indicadas. 10. El sistema se comunica con el SCC, para registrar la reserva pendiente de pago del socio con los siguientes datos: nmero de reserva, fecha de registro, cdigo de socio, nmero de pista, horas de uso y monto a pagar. 11. El sistema muestra el MSG Reserva generada y el caso de uso termina.
CIBERTEC
43
3.2. Flujos Alternativos 3.2.1. Cdigo de Socio no Vlido Si el sistema detecta que el cdigo del socio no es vlido, muestra el MSG Cdigo de Socio incorrecto y el sistema ofrecer la posibilidad de buscar al socio y el caso de uso contina en el punto 7. 4. Pre Condiciones 1. El Encargado de reservas logeado al sistema. 2. Comunicacin activa con el SCC. 3. Lista de Socios registrados. 4. Lista de pistas de juego disponibles. 5. Post Condiciones 1. En el sistema quedar registrado la reserva de pista de juego. 2. La disponibilidad de la pista de juego quedar registrada como reservada en la fecha y horas especificadas. 3. En el SCC quedar registrado la reserva del socio pendiente de pago. 6. Puntos de Extensin 1. En el punto 3, si el socio no muestra su carn en el cual se indica su cdigo, el Sistema extiende al Caso de Uso Buscar socio. 7. Requisitos Especiales 1. Comunicacin con SCC. 8. Prototipos (Disee el prototipo)
CIBERTEC
44
Resumen
Para llevar a cabo el anlisis de clases se realiza lo siguiente: Identificacin de responsabilidades y atributos Identificacin de Asociaciones y Agregaciones Identificacin de Generalizaciones La tarjeta CRC es una tcnica para identificar responsabilidades y colaboradores de una clase. Su objetivo es facilitar la comunicacin y documentar los resultados del anlisis de clases. La tarjeta se divide en tres compartimientos. En el compartimiento superior izquierdo se escribe el nombre de la clase candidata; en el compartimiento inferior izquierdo, las responsabilidades; y en el derecho, los colaboradores.
Si desea saber ms acerca de estos temas, puede consultar el siguiente enlace. http://c2.com/doc/oopsla89/paper.html En este link muestra un paper sobre las Tarjetas CRC.
CIBERTEC
45
MODELO DE DATOS
Al finalizar la segunda unidad, el alumno crea el modelo de datos de un software el cual incluye: el modelo conceptual, el modelo lgico y el modelo fsico de la base de datos. Los artefactos sern creados utilizando la herramienta CASE IBM Rational Software Architect (RSA) e IBM Rational InfoSphere Data Architect (IDA).
TEMARIO
Tema 1: Modelo de Datos 1.1. Modelo Conceptual 1.2. Modelo Lgico 1.3. Modelo fsico
1. Los alumnos desarrollan el modelo conceptual de un caso propuesto. 2. Los alumnos desarrollan el modelo fsico de un caso propuesto.
CIBERTEC
46
1. MODELO CONCEPTUAL
Las clases del modelo conceptual se obtienen a partir de los objetos de informacin que fluyen entre las actividades. Una caracterstica importante que resaltar es que el modelado de los casos de uso del sistema y el modelado conceptual se realizan en paralelo, esto es crucial para obtener casos de uso correctos, puesto que es necesario entender bien el dominio para poder escribir casos de uso que sean realmente tiles.
Modelo Conceptual Modelo Lgico Modelo Fsico
Figura 2.1. El Modelo Conceptual en el Flujo de Trabajo de Anlisis y Diseo.
1.1. Importancia del Modelo Conceptual

El Modelo Conceptual Orientado a Objetos beneficiar a dos equipos de trabajo: Equipo de Desarrolladores En esta etapa del desarrollo, merece la pena detenerse en la identificacin de los conceptos y no tanto en las relaciones entre ellos. Este modelo incluir los conceptos y sus relaciones y se describir mediante un diagrama de clases UML, en el que los conceptos se representan mediante clases (del dominio). Equipo de Base de Datos En esta etapa luego del modelo conceptual, se obtiene el proceso del modelo lgico al diseo fsico donde se podr identificar las tablas relacionales del proyecto de Base de Datos como componente RUP.
CIBERTEC
47
1.2. Construccin del Modelo Conceptual

A continuacin se describe los pasos que se realizan para la construccin del modelo conceptual, los cuales son: Identificar clases persistentes con sus atributos. Asociar clases. Identificar agregaciones. Definir jerarquas de clases.
1.2.1. Identificar clases persistentes con sus atributos La Clase es la unidad bsica que encapsula toda la informacin de un objeto (un objeto es una instancia de una clase). A travs de ella podemos modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.). Los Atributos representan las propiedades de la clase que se encuentran en todas las instancias de la clase. Definen la estructura de una clase y de sus objetos. Los atributos corresponden a sustantivos y sus valores pueden ser sustantivos o adjetivos. Dentro de una clase, los nombres de los atributos deben ser nicos (aunque puede aparecer el mismo nombre de atributo en diferentes clases). Los atributos pueden representarse slo mostrando su nombre, su tipo e incluso su valor por defecto. Public: Indica que el atributo ser visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados. Prvate: Indica que el atributo slo ser accesible desde dentro de la clase (slo sus mtodos lo pueden acceder). Protected: Indica que el atributo no ser accesible desde fuera de la clase, pero si podr estar disponible para mtodos de la clase adems de las subclases que se deriven.
Figura 2.2. Miembros de una clase. Para los Identificadores, en el momento de incluir atributos en la descripcin de una clase se debe distinguir entre los atributos que reflejan las caractersticas de los objetos en el mundo real, y los identificadores que son utilizados por razones de implementacin.
CIBERTEC
48
Figura 2.3. Clase con identificador Vs. clase sin identificador. Guas prcticas para la definicin de Clases y Atributos - Las clases poseen informaciones descriptivas; los atributos no. - Los atributos multivaluados deben ser clasificados como clases. - Convertir en una clase a un atributo que tenga una relacin muchos-a-uno con otra clase. - Asociar atributos a las clases que ellos describen ms directamente. Los atributos deben ser inherentes a la clase. - Evitar los identificadores compuestos en la medida que sea posible. Existen algunas categoras de clases que podramos utilizar para identificarlas correctamente. Categora Tangibles o fsicos Especificaciones o descripciones Lugares Transacciones Lneas o detalle de transaccin Registros de finanzas, expedientes Roles de personas Organizaciones Historiales Registros de cambios de estados Ejemplo Edificio, Producto EspecificacionProducto, DescripcionVuelo Tienda, Aula, Laboratorio Venta, Pago, Reserva LineaVenta, DetalleReserva CDP, Factura, Ticket, HistoriaClinica Cajero, Piloto Departamento, Sucursal PrecioProducto, PrecioDolar, AtencionCitas DisponibilidadHabitacion, DisponibilidadButaca Conceptos abstractos Relaciones RangoHora, UnidadAprendizaje Amistad, Parentesco
Tabla 2.1. Categora de clases del dominio del problema.
CIBERTEC
49
1.2.2. Asociar Clases La asociacin es una relacin entre clases que indica una conexin significativa e interesante. Est representada como una lnea entre clases con nombre. La asociacin es inherentemente bidireccional. Es convencional leer la asociacin de izquierda a derecha o de arriba hacia abajo. Criterios para identificar asociaciones o Enfocarse en aquellas asociaciones para las cuales el conocimiento de la relacin necesita ser conservado en el tiempo. (Asociaciones que se necesitan saber). Demasiadas asociaciones tienden a confundir. Evitar mostrar asociaciones redundantes o derivables. Pueden existir mltiples asociaciones entre dos clases.
o o o
a) Tipos de Asociaciones Asociacin Binaria: Asociacin entre dos clases.
Recepcionista
registra Cliente genera Orden Servicio
Figura 2.4. Asociacin Binaria. Asociacin de clase: Asociacin entre dos clases que contiene otra entidad. Generalmente este tipo de asociacin se utiliza para representar una relacin de muchos a muchos entre dos clases.
+juega en
+est conformado por
Figura 2.5. Asociacin de clase.
CIBERTEC
50
Asociacin Reflexiva: Se da en la misma clase.
Figura 2.6. Asociacin Reflexiva. b) Clase Asociativa Se da cuando uno o ms atributos estn relacionados con la asociacin. Las instancias de la clase asociativa dependen del tiempo de vida de la asociacin. Se da en una asociacin de muchos a muchos entre dos clases y existe informacin asociada con la propia relacin de asociacin.
Figura 2.7. Clase asociativa. c) Roles Dada una asociacin entre dos entidades, decimos que cada entidad representa un rol en dicha asociacin. Muchas veces, segn el punto de vista de cada entidad, es posible nombrar a la asociacin de manera diferente.
d) Multiplicidad Restringe el nmero de objetos de una clase que se pueden implicar en una relacin determinada en cualquier momento en el tiempo. La frase en cualquier momento en el tiempo es vital para entender las multiplicidades. Define cuantas instancias de la clase A pueden estar asociadas con una instancia de la clase B. La multiplicidad presenta las relaciones con valores de datos de acuerdo al detalle siguiente :
CIBERTEC
51
Item
*
Muchos Uno o muchos Cero o muchos Cero o uno 1 a 40
Item
1..*
Item
0..*
Item
0..1
Item
1..40
Item
5
Exactamente 5
Item
3,5,8
Exactamente 3,5 u 8
Figura 2.8. Multiplicidad. Ejemplo: En el siguiente ejemplo, se representa las siguientes relaciones: Un jugador juega en muchos equipos Un equipo est conformado por varios jugadores. Cada jugador, dependiendo del equipo en que se encuentre tendr un rol diferente.
+juega en +est conformado por
Figura 2.9. Asociaciones y multiplicidades.
CIBERTEC
52
1.2.3. Identificar Agregaciones La Agregacin indica una relacin de un todo conformado por partes Existen 2 tipos de agregaciones: o Agregacin Dbil o Compartida o Agregacin Fuerte o Compuesta La agregacin representa una relacin parte de entre objetos. En UML se proporciona una escasa caracterizacin de la agregacin. Puede ser caracterizada con precisin determinando las relaciones de comportamiento y estructura que existen entre el objeto agregado y cada uno de sus objetos componentes.
Figura 2.10. Agregaciones entre clases.
a) Agregacin Compartida Es un tipo de relacin utilizada para modelar la relacin todo-parte entre objetos. La parte puede estar simultneamente en varias instancias del todo. La agregacin existe de preferencia entre conceptos no fsicos. Ejemplo:
Figura 2.11. Agregacin compartida.
CIBERTEC
53
b) Agregacin Compuesta Es un tipo de relacin utilizada para modelar la relacin todo-parte entre objetos. Significa que la parte es miembro de solamente un objeto todo, es decir la existencia de la parte depende del todo. La composicin se representa con un diamante relleno. El objeto todo es el nico dueo del objeto parte. Ejemplo:
Figura 2.12. Agregacin compuesta. 1.2.4. Definir Jerarquas de clases Permiten gestionar la complejidad mediante un ordenamiento lgico. Se obtiene usando los mecanismos de abstraccin de Generalizacin y/o Especializacin. Generalizacin y Especializacin son conceptos fundamentales en el Modelo Conceptual que permiten la reduccin de la expresin. Las jerarquas de clases son a menudo las bases de inspiracin para las jerarquas de las clases de software que exploten la herencia y reduzcan la duplicacin de cdigo.
Figura 2.13. Jerarqua de clases.
CIBERTEC
54
a) La Generalizacin Consiste en factorizar las propiedades comunes de un conjunto de clases en una clase ms general. Nombres usados: clase padre - clase hija, superclase - subclase, clase base - clase derivada Las subclases heredan caractersticas de sus superclases, es decir, los atributos y operaciones (y asociaciones) de la superclase estn disponibles en sus subclases.
Ejemplo:
Figura 2.14. Generalizacin. b) La Especializacin Es el resultado de tomar un subconjunto de entidades de alto nivel para formar un conjunto de entidades de ms bajo nivel. Las entidades de bajo nivel presentan atributos adicionales diferencindolos de las otras entidades que se han creado producto de la especializacin.
Ejemplo:
Figura 2.15. Especializacin.
CIBERTEC
55
1.3. Caso prctico

A continuacin se mostrar el modelo conceptual obtenido a partir de la ECU Generar reserva.
Especificacin de Caso de Uso: Generar Reserva

1. Descripcin El caso de uso permite a la Recepcionista de un Hotel generar reserva de habitacin(es). 2. Actor(es) Recepcionista. 3. Flujo de Eventos 3.1. Flujo Bsico 1. El Caso de uso se inicia cuando la Recepcionista selecciona la opcin Generar Reserva en la interfaz del men principal. 2. El sistema muestra la interfaz RESERVA con los siguientes datos: Datos del cliente: Cdigo, Nombres y Apellidos. Datos de la Reserva: fecha de llegada, fecha de salida y cantidad de das a hospedarse. Datos de las habitaciones: Nmero de habitacin, Tipo, Costo por da, Nombre del husped de la Habitacin y una opcin para Agregar Habitacin. Adems incluye una cuadricula que contiene la lista de todas las habitaciones seleccionadas y las opciones: Buscar Cliente, Agregar Cliente, Consultar disponibilidad de Habitacin, Eliminar Habitacin, Grabar Reserva y Salir. 3. La Recepcionista selecciona Buscar Cliente. 4. El sistema Incluye el Caso de Uso Buscar Cliente. 5. El sistema muestra los datos del cliente. 6. La Recepcionista ingresa la fecha de llegada y la fecha de salida. 7. El sistema calcula la cantidad de das. 8. La recepcionista solicita Consultar disponibilidad de habitacin. 9. El sistema Incluye el Caso de Uso Consultar disponibilidad de Habitacin. 10. El sistema muestra la habitacin seleccionada. 11. La Recepcionista ingresa el nombre de la persona para la habitacin seleccionada. 12. La Recepcionista selecciona agregar Habitacin 13. El sistema calcula el pago de la habitacin, el subtotal, el monto total y lo agrega a la cuadricula del detalle de la reserva. 14. Si la Recepcionista quiere seleccionar otra habitacin, se repite del paso 7 al 12. 15. La Recepcionista selecciona Grabar Reserva. 16. El sistema autogenera un nmero de reserva. 17. El sistema graba la reserva con su detalle y registra la(s) disponibilidad(es) de la(s) habitacin(es) en estado Reservado. 18. El sistema muestra el nmero de reserva y el MSG Reserva generada con el Nro. 99999. 19. La Recepcionista cierra la interfaz RESERVA y regresa a la interfaz del men principal del sistema y finaliza el caso de uso.
CIBERTEC
56
3.2. Subflujos Ninguno. 3.3. Flujos Alternativos 1. Cliente no existe En el paso 4, si el sistema detecta que el cliente no existe muestra el MSG: Cliente no existe y ofrecer la posibilidad de registrar al nuevo cliente. 2. Habitaciones no disponibles En el paso 9, si el sistema detecta que no hay habitaciones disponibles muestra el MSG: No hay habitaciones disponibles y finaliza el caso de uso. 3. Eliminar Habitacin de Cuadricula La recepcionista selecciona una habitacin de la cuadricula y selecciona eliminar, el sistema elimina de la cuadricula la habitacin seleccionada y el caso de uso continua. 4. Precondiciones 4.1. El Recepcionista est logeado en el sistema. 4.2. Lista de Clientes disponibles. 4.3. Lista de habitaciones disponibles. 5. Post Condiciones 5.1. En el sistema quedar registrada la reserva con su detalle. 5.2. Las disponibilidades de las habitaciones seleccionadas se registraran en estado Reservadas. 6. Puntos de Extensin En el paso 5, el sistema extiende al caso de uso Mantener Clientes subflujo Agregar Cliente. 7. Requerimientos Especiales Ninguno. 8. Prototipos Interfaz RESERVA
CIBERTEC
57
Solucin: El modelo conceptual nos muestra las siguientes relaciones: Asociacin de clase: Reserva-Habitacin Asociaciones unidireccionales (con navegabilidad): o Reserva-Cliente o Habitacion-Categoria o DisponibilidadXHab- Habitacion
CIBERTEC
58
1. A partir de la Especificacin del Caso de Uso Reservar pistas de juego, de la sesin anterior, confeccione el Modelo Conceptual.
CIBERTEC
59
2. MODELO LGICO
Un modelo lgico de datos es un modelo que no es especfico de una base de datos que describe aspectos relacionados con las necesidades de una organizacin para recopilar datos y las relaciones entre estos aspectos. El modelo lgico de datos es el refinamiento del modelo conceptual. En este modelo no es necesario especificar las llaves primarias y forneas de las entidades, pues es trabajo que se recomienda realizar en el modelo fsico.
2.1. Tipos de datos

Existen muchas herramientas que permiten realizar transformaciones de un modelo lgico a partir de un modelo conceptual (con notacin UML). La transformacin UML a modelo lgico de datos genera tipos de datos de este modelo a partir de los tipos primitivos de UML. En la siguiente tabla se muestra la correspondencia entre tipos primitivos de UML y tipos de datos de modelo lgico de datos que se obtienen al utilizar la herramienta InfoSphere Data Architect (IDA) de IBM:
Tipos de datos de modelo lgico de datos que la transformacin genera BOOLEAN CHAR DATE DOUBLE FLOAT INTEGER LONG SHORT VARCHAR(32672)
Tipos primitivos de UML Boolean, boolean Byte, byte o char Date Double, double float Integer, int Long, long short Cadena de caracteres
Tabla 2.2. Correlaciones entre tipos de datos de modelo lgico de datos y UML en IDA.
CIBERTEC
60
2.2. Tipos de relaciones

Los tipos de relaciones que se pueden crear para un modelo lgico son: 2.1.1. Relacin Identificada Las relaciones identificadas migran la llave primaria de la entidad padre a la llave primaria de la entidad hija. Su representacin es una lnea ntida, tal como se ilustra en la siguiente figura.
Entidad Padre
Entidad Hija
Figura 2.16. Relacin Identificada.
2.1.2. Relacin No identificada En una relacin no identificada la llave primaria de la entidad padre es migrada como un atributo ms de la entidad hija, es decir, no formar parte de su llave primaria. Adems, en este tipo de relacin se representa otra caracterstica: la existencia. sta describe la relacin entre un par de entidades desde la perspectiva de la entidad hija. Fundamentalmente, haciendo la pregunta, Es el valor de una llave fornea siempre requerida en la entidad hija? Las posibles respuestas son: a) Opcional. Cuando el valor de una llave fornea no es siempre requerido en la entidad hija. Sin embargo, si un valor existe, el valor de la llave fornea debe encontrarse en la llave primaria de la entidad padre. La representacin de la relacin No identificada Opcional es una lnea entrecortada y en el extremo de la entidad padre aparece una lnea con un crculo. As: Entidad Hija
Entidad Padre
Figura 2.17. Relacin No Identificada Opcional.
CIBERTEC
61
b)
Obligatoria. Cuando el valor de una llave fornea debe existir en la entidad hija y el valor de la llave fornea debe encontrarse en la llave primaria de la entidad padre. La representacin de la relacin No identificada Obligatoria es una lnea entrecortada y en el extremo de la entidad padre aparece una lnea. As:
Entidad Padre
Entidad Hija
Figura 2.18. Relacin No Identificada Obligatoria.
Un proceso de transformacin del modelo conceptual (con notacin UML) a modelo lgico de datos, genera tipos de relacin, existencia y cardinalidad para el modelo lgico de datos de acuerdo a los tipos de asociacin y multiplicidad de rol UML. En la siguiente tabla se muestran las correlaciones entre un tipo de asociacin o multiplicidad de rol UML y el tipo de relacin, existencia y cardinalidad de un modelo lgico de datos, que se crean en un proceso de transformacin en el entorno de IDA.
UML Tipo de asociacin Simple o agregacin Simple o agregacin Multiplicidad de rol padre Multiplicidad de rol hijo (0..1) /1/*/(1..*) (0..1) /1/*/(1..*) Modelo lgico de datos Tipo de relacin No identificada No identificada
Existencia
Cardinalidad
(0..1)
Opcional
(0..1) /1/*/(1..*) (0..1) /1/*/(1..*)
Obligatoria
Composicin
(0..1) /1
(0..1) /1/*/(1..*)
Identificada
Siempre son (0..1) Obligatorias /1/*/(1..*)
Tabla 2.3. Correlaciones entre asociaciones UML y relaciones de modelo lgico de datos en IDA.
CIBERTEC
62
3. MODELO FSICO
El modelo fsico es un modelo de datos de bajo nivel. Proporcionan conceptos que describen los detalles de cmo se almacenan los datos en el ordenador. El paso de un modelo lgico a uno fsico requiere un profundo entendimiento del manejador de bases de datos que se desea emplear, incluyendo caractersticas como: Conocimiento a fondo de los tipos de objetos (elementos) soportados. Detalles acerca del indexamiento, integridad referencial, restricciones, tipos de datos, etc. Detalles y variaciones de las versiones. Parmetros de configuracin. Data Definition Language (DDL). El paso de convertir el modelo lgico de datos a tablas hace que las entidades pasen a ser tablas (ms las derivadas de las relaciones) y los atributos se convierten en las columnas de dichas tablas.
Las relaciones entre las tablas del modelo fsico son las mismas que se describieron en el modelo lgico: Relacin Identificada Relacin No Identificada Opcional Relacin No Identificada Obligatoria
3.1. Campos
3.1.1. Tipos de Datos Los tipos de datos son segn los disponibles en el Sistema Manteador de Base de Datos (SMBD). En la mayora de casos se considera lo siguiente:

Nmero de dgitos en nmeros enteros La precisin de los flotantes Cadenas de caracteres de longitud fija. Ejemplo: CHAR(5) Cadenas de caracteres de longitud variable. Ejemplo: VARCHAR(50) Para archivos binarios (imgenes) se utiliza el tipo BLOB (Binary Large Objects) Para cadenas de longitudes grandes se utiliza el tipo CLOB (Character Large Objects)
3.1.2. Llaves primarias Representa el identificador de una tabla y est formada por uno o ms campos de la tabla. Algunos SMBD poseen la capacidad de "autoincrement" o "identity property" con la cual pueden automticamente manipular algn atributo para generar llaves primarias de forma incremental. Pero es importante verificar:

Cmo se manejan internamente. Si se pueden reiniciar. Si se permite especificar algn valor inicial.
CIBERTEC
63
3.1.3. Orden de los campos o columnas Por lo general la secuencia es:

Columnas de longitud fija que no se actualizan frecuentemente. Aquellas que nunca se actualizan, que por lo general tendrn longitud variable. Las que se actualizan frecuentemente.
3.1.4. Integridad Referencial

En la medida de lo posible indicar qu columnas brindan o sirven de vnculo entre 2 tablas. El administrador de base de datos puede hacerse cargo de esto pero es mejor que el SMBD lo haga. No se recomienda en ambientes de desarrollo.
3.2. ndices
Un ndice es un atajo desde un campo llave hacia la localizacin real de los datos. Es el punto clave de la optimizacin de velocidad de toda base de datos. Si se busca alguna tupla en base a un atributo que no tiene un ndice, entonces se realiza un escaneo de la tabla completa lo cual es demasiado costoso, por eso es recomendable usar ndices en:

Llaves primarias Llaves forneas ndices de acceso Ordenamiento
No olvidar que el uso de un ndice implica:

Overhead debido a la actualizacin de los mismos Espacio adicional en disco Procesos batch de muchos datos pueden volverse demasiado lentos Manipulacin de archivos adicionales por el sistema operativo
3.3. Sistemas manejadores de bases de datos (SMBD) ms populares

Logo Nombre Sybase URL www.sybase.com Productos Adaptive Server Oracle8, Oracle8i, Oracle8iEE, Oracle9i, Oracle 10g
Oracle
www.oracle.com
PostgreSQL www.postgresql.org PostgreSQL
Tabla 2.4. SMBD ms populares.
CIBERTEC
64
Logo
Nombre
URL
Productos
Microsoft
www.microsoft.com
Access, MSSQL Server
MySQL
www.mysql.com
MySQL
Informix
www.informix.com
Illustra, Universal Server, Dynamic Server DB2
IBM
www.ibm.com
Apache
http://db.apache.org/derby
Derby
SQLite
http://www.sqlite.org
SQLite
Firebird http://firebird.sourceforge.net
Firebird
Tabla 2.4. SMBD ms populares (Continuacin).
CIBERTEC
65
3.4. Caso prctico

A continuacin se mostrar el modelo conceptual obtenido a partir de la ECU Generar reserva.
Especificacin de Caso de Uso: Generar Reserva

1. Descripcin El caso de uso permite a la Recepcionista de un Hotel generar reserva de habitacin(es). 2. Actor(es) Recepcionista. 3. Flujo de Eventos 3.1. Flujo Bsico 1. El Caso de uso se inicia cuando la Recepcionista selecciona la opcin Generar Reserva en la interfaz del men principal. 2. El sistema muestra la interfaz RESERVA con los siguientes datos: Datos del cliente: Cdigo, Nombres y Apellidos. Datos de la Reserva: fecha de llegada, fecha de salida y cantidad de das a hospedarse. Datos de las habitaciones: Nmero de habitacin, Tipo, Costo por da, Nombre del husped de la Habitacin y una opcin para Agregar Habitacin. Adems incluye una cuadricula que contiene la lista de todas las habitaciones seleccionadas y las opciones: Buscar Cliente, Agregar Cliente, Consultar disponibilidad de Habitacin, Eliminar Habitacin, Grabar Reserva y Salir. 3. La Recepcionista selecciona Buscar Cliente. 4. El sistema Incluye el Caso de Uso Buscar Cliente. 5. El sistema muestra los datos del cliente. 6. La Recepcionista ingresa la fecha de llegada y la fecha de salida. 7. El sistema calcula la cantidad de das. 8. La recepcionista solicita Consultar disponibilidad de habitacin. 9. El sistema Incluye el Caso de Uso Consultar disponibilidad de Habitacin. 10. El sistema muestra la habitacin seleccionada. 11. La Recepcionista ingresa el nombre de la persona para la habitacin seleccionada. 12. La Recepcionista selecciona agregar Habitacin 13. El sistema calcula el pago de la habitacin, el subtotal, el monto total y lo agrega a la cuadricula del detalle de la reserva. 14. Si la Recepcionista quiere seleccionar otra habitacin, se repite del paso 7 al 12. 15. La Recepcionista selecciona Grabar Reserva. 16. El sistema autogenera un nmero de reserva. 17. El sistema graba la reserva con su detalle y registra la(s) disponibilidad(es) de la(s) habitacin(es) en estado Reservado. 18. El sistema muestra el nmero de reserva y el MSG Reserva generada con el Nro. 99999. 19. La Recepcionista cierra la interfaz RESERVA y regresa a la interfaz del men principal del sistema y finaliza el caso de uso. 3.2. Subflujos Ninguno.
CIBERTEC
66
3.3. Flujos Alternativos 1. Cliente no existe En el paso 4, si el sistema detecta que el cliente no existe muestra el MSG: Cliente no existe y ofrecer la posibilidad de registrar al nuevo cliente. 2. Habitaciones no disponibles En el paso 9, si el sistema detecta que no hay habitaciones disponibles muestra el MSG: No hay habitaciones disponibles y finaliza el caso de uso. 3. Eliminar Habitacin de Cuadricula La recepcionista selecciona una habitacin de la cuadricula y selecciona eliminar, el sistema elimina de la cuadricula la habitacin seleccionada y el caso de uso continua. 4. Precondiciones 4.4. El Recepcionista est logeado en el sistema. 4.5. Lista de Clientes disponibles. 4.6. Lista de habitaciones disponibles. 5. Post Condiciones 5.3. En el sistema quedar registrada la reserva con su detalle. 5.4. Las disponibilidades de las habitaciones seleccionadas se registrarn en estado Reservadas. 6. Puntos de Extensin En el paso 5, el sistema extiende al caso de uso Mantener Clientes subflujo Agregar Cliente. 7. Requerimientos Especiales Ninguno. 8. Prototipos Interfaz RESERVA
CIBERTEC
67
Solucin: A continuacin se muestra el modelo fsico del caso.
1. A partir de la Especificacin del Caso de Uso Reservar pistas de juego, de la sesin anterior, confeccione el Modelo Fsico.
CIBERTEC
68
Resumen
El modelo conceptual es un modelo de datos de alto nivel en el que disponen de conceptos muy cercanos al modo en que la mayora de los usuarios percibe los datos. En el modelo conceptual, las clases se obtienen a partir de los objetos de informacin que fluyen entre las actividades. El modelado de los casos de uso del sistema y el modelado conceptual se realizan en paralelo, esto es crucial para obtener casos de uso correctos, puesto que es necesario entender bien el dominio para poder escribir casos de uso que sean realmente tiles. El modelo conceptual orientado a objetos beneficiar a dos equipos de trabajo : Equipo de Desarrolladores En esta etapa del desarrollo, merece la pena detenerse en la identificacin de los conceptos y no tanto en las relaciones entre ellos. Este modelo incluir los conceptos y sus relaciones y se describir mediante un diagrama de clases UML, en el que los conceptos se representan mediante clases (del dominio). Equipo de Base de Datos En esta etapa luego del modelo conceptual, se obtiene el proceso del modelo lgico al diseo fsico donde se podr identificar las tablas relacionales del proyecto de Base de Datos como componente RUP.
Un modelo lgico de datos es aquel que no es especfico de una base de datos que describe aspectos relacionados con las necesidades de una organizacin para recopilar datos y las relaciones entre estos aspectos. Es el refinamiento del modelo conceptual; no es necesario especificar las llaves primarias y forneas de las entidades, pues es trabajo que se recomienda realizar en el modelo fsico. El modelo fsico es un modelo de datos de bajo nivel. Proporcionan conceptos que describen los detalles de cmo se almacenan los datos en el ordenador.
CIBERTEC
69
DISEO ORIENTADO A OBJETOS

Al finalizar la tercera unidad, el alumno disea la arquitectura del software identificando las capas, subsistemas y componentes de la aplicacin. Los artefactos sern creados utilizando la herramienta CASE IBM Rational Software Architect (RSA).
Tema 1: Diseo orientado a objetos 1.1. Flujo de trabajo del DOO 1.2. Artefactos del diseo 1.3. Modelo de anlisis Vs. Modelo de diseo Tema 2: Arquitectura de software 2.1. Por qu es importante la arquitectura 2.2. Fases de la arquitectura 2.3. Estilos arquitectnicos Tema 3: Diseo de casos de uso 3.1. Patrones de diseo 3.2. Extensiones de UML para aplicaciones web (WAE) 3.3. Realizacin de diseo de casos de uso con patrn arquitectnico MVC 3.4. Realizacin de diseo de casos de uso con patrn arquitectnico MVC y patrn de diseo DAO
1. Los alumnos desarrollan la realizacin de diseo de un caso de uso a partir de su especificacin aplicando el patrn arquitectnico MVC. 2. Los alumnos desarrollan la realizacin de diseo de un caso de uso a partir de su especificacin aplicando el patrn arquitectnico MVC.
CIBERTEC
70
1. DISEO ORIENTADO A OBJETOS

1.1. Flujo de trabajo del DOO
El objetivo del diseo es entender la solucin refinando el modelo de anlisis con la intencin de desarrollar un modelo de diseo que permita una transicin sin problemas a la fase de construccin. En el diseo, nos adaptamos al entorno de implementacin y despliegue. En la siguiente figura se resalta las actividades que se llevan a cabo en el DOO.
DISEO
Figura 3.1. Flujo de trabajo del DOO.
1.2. Artefactos del Diseo

Son muchos los artefactos que se elaboran en el flujo de trabajo del DOO. En el curso consideraremos los siguientes artefactos: Modelo de Diseo. Elementos del modelo de diseo: capas, subsistemas con clases de diseo (como servlets, beans y otras) e interfaces, libreras con clases utilitarias, y realizaciones de diseo de casos de uso. Diagramas de realizaciones de diseo de casos de uso: diagrama de clases y diagramas de secuencia. Diagrama de componentes, cuyos elementos son los componentes de la aplicacin. Modelo de Despliegue. Diagrama de despliegue, cuyos elementos son artefactos y nodos.
CIBERTEC
71
Artefacto
Descripcin
Representa la vista interna del sistema. Conjunto formado por las clases de diseo y las realizaciones de casos de uso. El modelo de diseo se convertir en la materia prima que nuestra disciplina de implementacin transformar en cdigo ejecutable. Representan un medio artefactos del modelo de del estilo arquitectnico, conjunto de subsistemas de diseo. para organizar los diseo. Dependiendo una capa agrupa un junto con sus clases
Modelo de Diseo
Capa
Un subsistema contiene las clases de diseo de un grupo de casos de uso. Tiene correspondencia directa con los paquetes de anlisis.
Subsistema
Librera
Una librera contiene clases utilitarias, adicionales a las del API del lenguaje de programacin, implementadas por el equipo de desarrollo. Son abstracciones de clase directamente utilizadas en la implementacin, es decir, estas clases junto con sus atributos y operaciones se mapean directamente en el lenguaje de programacin. Describe cmo un caso de uso se lleva a cabo en trminos de clases de diseo y sus objetos. Hay una correspondencia directa entre Realizacin de Diseo de Casos de Uso y Realizacin de Anlisis de Casos de Uso. El diagrama de clases describe la estructura de un caso de uso. Contiene las clases que participan en el caso de uso, aunque algunas de ellas puedan participar en varios. Muestra una secuencia detallada de interaccin entre los objetos de diseo. Visualizan el intercambio de mensajes entre objetos. Se crea un diagrama de secuencia por cada flujo de trabajo del caso de uso: flujo bsico, subflujos y flujos alternativos.
Clases de diseo
Realizacin de Diseo de Caso de Uso
Diagrama de Clases
Diagramas de Secuencia
Tabla 3.1. Artefactos del Diseo.
CIBERTEC
72
Artefacto
Descripcin
Un componente representa una pieza del software reutilizable. Por ejemplo, si se est desarrollando una aplicacin web estas piezas pueden ser recursos estticos (pginas HTML) y recursos dinmicos (JSP y servlets) representados como componentes. Un diagrama de componentes muestra la estructura de un sistema software, el cual describe los componentes software, sus interfaces y sus dependencias.
Componente
Diagrama de componentes
Modelo de Despliegue
Describe la distribucin fsica del sistema en trminos de cmo las funcionalidades se distribuyen entre los nodos de computacin sobre los que se va a instalar el sistema.
Un diagrama de despliegue se puede utilizar para visualizar la topologa actual del sistema y la distribucin de componentes. Diagrama de Despliegue Los artefactos son elementos que representan las entidades fsicas de un sistema software. Los artefactos representan unidades de implementacin fsica como archivos ejecutables, libreras, componentes de software, documentos, y bases de datos. Representa un recurso de computacin. Los nodos tienen relaciones entre ellos que representan los medios de comunicacin que hay entre stos como una Intranet o Internet. La funcionalidad de un nodo viene representada por los componentes que se ejecutan en l.
Artefacto
Nodo
Tabla 3.1. Artefactos del Diseo. (Continuacin)
CIBERTEC
73
1.3. Modelo de anlisis Vs. Modelo de diseo

El siguiente cuadro muestra una comparacin entre el Modelo de anlisis y el Modelo de diseo: Modelo de Anlisis
Es un modelo conceptual y genrico, es una abstraccin del sistema. Es menos formal. Es un bosquejo del diseo del sistema. Puede no mantenerse durante todo el ciclo de vida del software. Define una estructura para modelar el sistema.
Modelo de Diseo
Es un modelo fsico y concreto, es un plano de la implementacin. Es ms formal. Es una realizacin del diseo del sistema. Debe ser mantenido durante todo el ciclo de vida del software. Da forma al sistema.
Cuadro 3.1. Comparacin del MA Vs. MD.
CIBERTEC
74
Resumen
El objetivo del diseo es entender la solucin refinando el modelo de anlisis con la intencin de desarrollar un modelo de diseo que permita una transicin sin problemas a la fase de construccin. En el diseo, nos adaptamos al entorno de implementacin y despliegue. Son muchos los artefactos que se elaboran en el flujo de trabajo del DOO. En el curso consideraremos los siguientes artefactos: Modelo de Diseo. Elementos del modelo de diseo: capas, subsistemas con clases de diseo (como servlets, beans y otras) e interfaces, libreras con clases utilitarias, y realizaciones de diseo de casos de uso. Diagramas de realizaciones de diseo de casos de uso: diagrama de clases y diagramas de secuencia. Diagrama de componentes, cuyos elementos son los componentes de la aplicacin. Modelo de Despliegue. Diagrama de despliegue, cuyos elementos son nodos.
Si desea saber ms acerca de estos temas, puede consultar los siguientes libros. OBJECT-ORIENTED ANALYSIS AND DESIGN WITH APPLICATIONS. de Grady Booch, Jim Conallen y otros, 3era edicin. En el captulo 12 encontrar la solucin de una aplicacin web, explicando cmo se construyen los modelos de las disciplinas de RUP para alcanzar los objetivos de cada fase.
CIBERTEC
75
2. ARQUITECTURA DEL SOFTWARE

La Arquitectura del Software AS es la parte de la ingeniera del software que se ocupa de la descripcin y el tratamiento de un sistema como un conjunto de componentes, que facilita su organizacin en los diferentes subsistemas que lo forman. Esto es til, entre otras cosas, para poder asignarlos a equipos de trabajo y que puedan llevar a cabo el desarrollo del sistema de una manera organizada y eficiente. Este campo surge ante la necesidad de describir sistemas software complejos, descomponerlos en un conjunto de componentes y ver qu relaciones existen entre ellos. Por lo tanto, la AS aporta una visin abstracta de alto nivel, posponiendo el detalle de cada uno de los mdulos definidos a pasos posteriores del diseo. Aunque intuitivamente el concepto de AS es bastante claro, no se ha dado hasta el momento una definicin que satisfaga por completo a todos aquellos que trabajan en este campo. Quizs, para obtener una visin de conjunto, lo ms adecuado sea considerar varias definiciones a la vez. A continuacin se mencionan varias de ellas ordenadas cronolgicamente: Posiblemente la primera definicin fue la dada en 1993 por David Garlan y Mary Shaw en la que exponen objetivos y aspectos a tener en cuenta en la AS: Ms all de los algoritmos y estructuras de datos de la computacin, el diseo y especificacin de la estructura global del sistema emerge como un nuevo tipo de problema. Los detalles estructurales incluyen: la organizacin general y la estructura de control global; los protocolos de comunicacin, sincronizacin y acceso a datos; la asignacin de funcionalidad a los elementos de diseo; la distribucin fsica; la composicin de los elementos de diseo; su escalabilidad y los aspectos de rendimiento; y la seleccin entre alternativas de diseo. Se puede considerar una segunda definicin, quizs la ms breve y sencilla, y a la vez la ms aceptada, dada por David Garlan y Dewayne Perry en 1995: La arquitectura del software est compuesta por la estructura de los componentes de un programa o sistema, sus interrelaciones, y los principios y reglas que gobiernan su diseo y evolucin a lo largo del tiempo. A continuacin se presenta la definicin dada por Clements en 1996 que puede considerarse como una definicin general, amplia y flexible, aunque por ello pueda parecer incompleta y algo ambigua. Sin embargo, es vlida tanto para aquellos que desean una visin descriptiva de la AS (punto de vista representado por Garlan) como para los que utilizan una visin de proceso (representada por Perry): La arquitectura del software es, a grandes rasgos, una vista del sistema que incluye los componentes principales del mismo, la conducta de esos componentes segn se percibe desde el resto del sistema, y las formas en que los componentes interactan y se coordinan para alcanzar el objetivo del sistema. La vista arquitectnica es una vista abstracta de un sistema, aportando el ms alto nivel de compresin y la supresin del detalle inherente a la mayor parte de abstracciones.
CIBERTEC
76
Otra definicin que ha sido utilizada por la comunidad de ingeniera de software es la de RUP, citada por Phillipe Kruchten en 1995, que define lo siguiente: La arquitectura de software abarca un conjunto de decisiones significativas sobre la organizacin del sistema de software. Estas decisiones abarcan: la seleccin de los elementos estructurales y sus interfaces, con los que se compone el sistema, junto con su comportamiento tal como se especifica en las colaboraciones entre esos elementos, la composicin de esos elementos estructurales y de comportamiento en subsistemas progresivamente ms grandes, y el estilo arquitectnico que gua esta organizacin.
En el ao 2000 se acord definir oficialmente la AS segn figura en el documento IEEE Std 1471-2000: La arquitectura del software es la organizacin fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos y el entorno, y los principios que dirigen su diseo y evolucin.
En el nmero de marzo/abril de 2006 de IEEE Software, en el artculo de Kruchten, Obbink y Stafford figura la siguiente definicin, ms elaborada: La arquitectura del software captura y preserva las intenciones de los diseadores sobre la estructura y el comportamiento de los sistemas, proporcionando un mecanismo de defensa contra el deterioro de los sistemas antiguos. Esta es la clave para lograr el control intelectual sobre la creciente complejidad de los sistemas. Paradjicamente an no hay un consenso sobre cul es la respuesta a la pregunta de qu es la arquitectura del software y que sea ampliamente aceptada Llegar a un acuerdo sobre la definicin ms adecuada para esta disciplina fue uno de los objetivos de definir el estndar IEEE. Sin embargo, esta falta de acuerdo no ha sido impedimento para que la arquitectura del software progrese.
A partir de todas las definiciones que se han dado sobre AS, se ha llegado a una especie de consenso por el que esta disciplina se refiere a la estructura de un sistema a grandes rasgos, formada por componentes y relaciones entre ellos. Estas cuestiones se tienen en cuenta durante el diseo, puesto que la AS se refiere al diseo del software que se realiza en fases tempranas del desarrollo software y a alto nivel de abstraccin.
Por qu es importante la arquitectura

Para empezar, de una u otra forma, muchos stakeholders estn interesados en la arquitectura: El analista de sistemas, que lo utiliza para organizar y articular los requisitos y comprender las limitaciones tecnolgicas y riesgos. Los usuarios finales o clientes, que lo utilizan para visualizar en un alto nivel lo que estn comprando. El gerente de proyecto de software, que lo utiliza para organizar el equipo y el plan de desarrollo. Los diseadores, que la utilizan para comprender los principios subyacentes y localizar los lmites de su propio diseo.
CIBERTEC
77
Otras organizaciones de desarrollo (si el sistema es abierto), que lo utilizan para comprender cmo interactuar con l. Arquitectos, que la usan para razonar acerca de la evolucin o la reutilizacin.
Al respecto, Bass y sus colegas (2003), en un libro dedicado a la arquitectura de software, identifican tres razones claves por las cuales la arquitectura del software es importante: Las representaciones de la arquitectura del software permiten la comunicacin entre los diferentes stakeholders. La arquitectura resalta las decisiones iniciales relacionadas con el diseo que tendrn un impacto en todo el proceso de desarrollo posterior. La arquitectura encarna un modelo relativamente pequeo, intelectualmente tratable, de la forma en que un sistema se estructura y sus componentes se entienden entre s; este modelo es transferible a travs de sistemas; en particular, se puede aplicar a otros sistemas que exhiben requisitos parecidos y puede promover reutilizacin en gran escala.
Fases de la arquitectura
Un ingeniero de software define la arquitectura del sistema en tres etapas, tal como se muestra en la figura 3.2.
1. Eleccin del estilo arquitectnico
2. Seleccin de patrones de diseo
3. Diseo de componentes Figura 3.2. Fases de la arquitectura del sistema Eleccin de estilos arquitectnicos Una vez que el equipo de desarrollo define los requisitos funcionales y no funcionales del sistema que habr de construirse, podr elegirse un estilo arquitectnico o la combinacin de estilos que mejor combinen con los requisitos del sistema. Un estilo arquitectnico es un patrn de organizacin de un sistema. El objetivo es establecer una estructura para todos los componentes del sistema. Existe un nmero relativamente pequeo de estilos arquitectnicos. La primera taxonoma la propusieron Shaw y Garlan, en 1993, considerando los siguientes tipos:
CIBERTEC
78
Tuberas-filtros. Organizacin de abstraccin de datos y orientacin a objetos. Invocacin implcita, basada en eventos. Sistemas en capas. Repositorios. Procesos distribuidos, ya sea en funcin de la topologa (anillo, estrella, etc.) o de los protocolos entre procesos. Una forma particular de proceso distribuido es, por ejemplo, la arquitectura cliente-servidor. Organizaciones programa principal / subrutina. Arquitecturas software especficas de dominio. Sistemas de transicin de estados. Sistemas de procesos de control. Estilos heterogneos.
Ms adelante, el grupo de Buschmann en 1996, quines denominaron a los estilos como patrones arquitectnicos, los enumeraron agrupndolos en: Sistemas estructurales. Sistemas distribuidos. Sistemas interactivos Sistemas adaptables.
Posteriormente, Bass, Clements y Kazman en el ao 2003, definieron un conjunto de clases de estilo en los siguientes grupos: Flujo de datos. Llamada y retorno. Componentes independientes centrados en datos. Mquina virtual.
En los ltimos aos la relacin de estilos se ha hecho ms detallada y exhaustiva. Considerando solamente los estilos que contemplan alguna forma de distribucin o topologa de red, tal como la taxonoma propuesta por Roy Fielding en el ao 2000: Estilos de flujo de datos. Estilos de replicacin. Estilos jerrquicos. Estilos de cdigo mvil. Estilo peer-to-peer. Estilos de transferencia de estado de representacin (REST).
Seleccin de patrones de diseo Un patrn es una solucin de diseo de software a un problema, aceptada como correcta, a la que se ha dado un nombre y que puede ser aplicada en otros contextos. Se debe seleccionar uno o ms patrones de diseo para aplicarlos en el diseo de los componentes. Actualmente existen varias categoras de patrones, pero en el curso describiremos los patrones GOF y el catlogo de patrones de J2EE.
CIBERTEC
79
Diseo de componentes Consiste en el diseo de los mdulos del sistema utilizando una notacin grfica (como UML) para expresar lo que se va a implementar. El diseo de componentes tiene como artefacto principal la colaboracin de casos de uso, la cual contiene un diagrama de clases y diagramas de interaccin para representar la estructura y comportamiento del caso de uso respectivamente.
Estilos arquitectnicos
Los estilos que se describirn a continuacin son los ms representativos y vigentes, los que contemplan alguna forma de distribucin de componentes o topologa de red. Estilos de flujos de datos Es apropiada para sistemas que implementan transformaciones de datos frecuentemente. Ejemplares de la misma seran las arquitecturas de tubera-filtros y las de proceso secuencial en lote. a) Tuberas y filtros Este estilo consiste en una tubera (pipeline) que conecta componentes computacionales (filtros) a travs de conectores (pipes), de modo que los procesos se ejecutan a la manera de un flujo. Los datos se transportan a travs de las tuberas entre los filtros, transformando gradualmente las entradas en salidas. El sistema tubera-filtros se percibe como una serie de transformaciones sobre sucesivas piezas de los datos de entrada. Los datos entran al sistema y fluyen a travs de los componentes. b) Proceso secuencial en lote En el estilo secuencial por lotes (batch sequential) los componentes son programas independientes; el supuesto es que cada paso se ejecuta hasta completarse antes que se inicie el paso siguiente. Estilos centrados en datos Esta familia de estilos es apropiada para sistemas que se fundan en acceso y actualizacin de datos en estructuras de almacenamiento. Sub-estilos caractersticos de la familia seran los repositorios, las bases de datos, las arquitecturas basadas en hipertextos y las arquitecturas de pizarra. a) Arquitecturas de Pizarra o Repositorio En esta arquitectura hay dos componentes principales: una estructura de datos que representa el estado actual y una coleccin de componentes independientes que operan sobre l. En base a esta distincin se han definido dos subcategoras principales del estilo: Si los tipos de transacciones en el flujo de entrada definen los procesos a ejecutar, el repositorio puede ser
CIBERTEC
80
una base de datos tradicional (implcitamente no clienteservidor). Si el estado actual de la estructura de datos dispara los procesos a ejecutar, el repositorio es lo que se llama una pizarra pura o un tablero de control.
Estilos de llamada y retorno Son los estilos ms generalizados en sistemas en gran escala. Miembros de la familia son las arquitecturas de programa principal y subrutina, los sistemas basados en llamadas a procedimientos remotos, los sistemas orientados a objeto y los sistemas jerrquicos en capas. a) Model-View-Controller (MVC) Algunos lo definen como patrn de diseo, pero otros autores precisan que debe ser tratado como estilo arquitectnico debido a que est referido a la estructura global del software.
Figura 3.3. Capas del MVC. El estilo o patrn arquitectnico MVC separa el modelado del dominio, la presentacin y las acciones basadas en datos ingresados por el usuario en tres capas: Modelo. El modelo administra el comportamiento y los datos del dominio de aplicacin, responde a requerimientos de informacin sobre su estado (usualmente formulados desde la vista) y responde a instrucciones de cambiar el estado (habitualmente desde el controlador). Vista. Maneja la visualizacin de la informacin. Controlador. Interpreta las acciones del ratn y el teclado, informando al modelo y/o a la vista para que cambien segn resulte apropiado.
Entre las ventajas de este estilo se encuentran: Soporte de vistas mltiples. Dado que la vista se halla separada del modelo y no hay dependencia directa del modelo con respecto a la vista, la interfaz de usuario puede mostrar mltiples vistas de los mismos datos simultneamente. Por ejemplo, mltiples pginas de una
CIBERTEC
81
aplicacin de Web pueden utilizar el mismo modelo de objetos, mostrado de maneras diferentes. Adaptacin al cambio. Los requerimientos de interfaz de usuario tienden a cambiar con mayor rapidez que las reglas de negocios. Los usuarios pueden preferir distintas opciones de representacin, o requerir soporte para nuevos dispositivos como telfonos celulares o PDAs. Dado que el modelo no depende de las vistas, agregar nuevas opciones de presentacin generalmente no afecta al modelo. Este patrn sent las bases para especializaciones posteriores, tales como Page Controller y Front Controller.
b)
Arquitectura en capas Los sistemas o arquitecturas en capas constituyen uno de los estilos que aparecen con mayor frecuencia en las estructuras de sistemas. Consiste en una organizacin jerrquica de capas, de modo tal que cada una proporciona servicios a la capa inmediatamente superior y se sirve de las prestaciones que le brinda la inmediatamente inferior. En algunos ejemplares, las capas internas estn ocultas a todas las dems, menos para las capas externas adyacentes, y excepto para funciones puntuales de exportacin; en estos sistemas, los componentes implementan mquinas virtuales en alguna de las capas de la jerarqua. En la prctica, las capas suelen ser entidades complejas, compuestas de varios paquetes o subsistemas. Casos representativos de este estilo son muchos de los protocolos de comunicacin en capas. En ellos cada capa proporciona un sustrato para la comunicacin a algn nivel de abstraccin, y los niveles ms bajos suelen estar asociados con conexiones de hardware. El ejemplo ms caracterstico es el modelo OSI con siete niveles: nivel fsico, vnculo de datos, red, transporte, sesin, presentacin y aplicacin. El estilo tambin se encuentra en forma ms o menos pura en arquitecturas de bases de datos y sistemas operativos, as como en las especificaciones relacionadas con XML. El nmero mnimo de capas es obviamente dos, y en ese umbral la literatura arquitectnica sita a veces al sub-estilo clienteservidor como el modelo arquetpico del estilo de capas y el que se encuentra con mayor frecuencia en las aplicaciones en red. Un componente servidor, que ofrece ciertos servicios, escucha que algn otro componente requiera uno; un componente cliente solicita ese servicio al servidor a travs de un conector. El servidor ejecuta el requerimiento (o lo rechaza) y devuelve una respuesta.
c)
Arquitectura orientada a objetos Nombres alternativos para este estilo han sido Arquitecturas Basadas en Objetos, Abstraccin de Datos y Organizacin Orientada a Objetos. Los componentes de este estilo son los objetos, o ms bien instancias de los tipos de dato abstractos.
CIBERTEC
82
Los componentes del estilo se basan en principios OO: encapsulamiento, herencia y polimorfismo. Son asimismo las unidades de modelado, diseo e implementacin, y los objetos y sus interacciones son el centro de las incumbencias en el diseo de la arquitectura y en la estructura de la aplicacin. d) Arquitectura basada en componentes En este estilo arquitectnico los componentes son las unidades de modelado, diseo e implementacin. Las interfaces estn separadas de las implementaciones, y las interfaces y sus interacciones son el centro de incumbencias en el diseo arquitectnico. Estilos de cdigo mvil Esta familia de estilos enfatiza la portabilidad. Ejemplos de la misma son los intrpretes, los sistemas basados en reglas y los procesadores de lenguaje de comando. Fuera de las mquinas virtuales y los intrpretes, los otros miembros del conjunto han sido rara vez estudiados desde el punto de vista estilstico. a) Arquitectura de mquinas virtuales La arquitectura de mquinas virtuales se ha llamado tambin intrpretes basados en tablas. De hecho, todo intrprete involucra una mquina virtual implementada en software. Se puede decir que un intrprete incluye un seudo-programa a interpretar y una mquina de interpretacin. El seudo-programa a su vez incluye el programa mismo y el anlogo que hace el intrprete de su estado de ejecucin (o registro de activacin). La mquina de interpretacin incluye tanto la definicin del intrprete como el estado actual de su ejecucin. De este modo, un intrprete posee por lo general cuatro componentes: Una mquina de interpretacin que lleva a cabo la tarea. Una memoria que contiene el seudo-cdigo a interpretar. Una representacin del estado de control de la mquina de interpretacin. Una representacin del estado actual del programa que se simula.
Las mquinas virtuales no son una invencin reciente ligada a Java, sino que existen desde la dcada de 1950. En esa dcada, los precursores de los ingenieros de software sugirieron una mquina virtual basada en un lenguaje de mquina universal de bytecodes (un ejemplo fue UNCOL), de manera que las aplicaciones podan escribirse en las capas ms altas y ejecutarse donde fuere sin tener que recompilarse, siempre que hubiera una mquina virtual entre el programa por un lado y el sistema operativo y la mquina real por el otro. En 1968 Alan Kay implement una mquina virtual vinculada a un sistema orientado a objetos y luego particip con Dan Ingalls en el desarrollo de la mquina virtual de Smalltalk hacia 1972. Numerosos lenguajes y ambientes de scripting utilizan mquinas virtuales: Perl, Javascript, Windows Script Host (WSH), Python, PHP, Pascal.
CIBERTEC
83
Estilos heterogneos En esta categora de estilos se encuentran los sistemas de control de procesos industriales, sistemas de transicin de estados, arquitecturas especficas de dominios o estilos derivados de otros estilos, como GenVoca, C2 o REST. a) Sistemas de control de procesos Desde el punto de vista arquitectnico, mientras casi todos los dems estilos se pueden definir en funcin de componentes y conectores, los sistemas de control de procesos se caracterizan no slo por los tipos de componentes, sino por las relaciones que mantienen entre ellos. El objetivo de un sistema de esta clase es mantener ciertos valores dentro de ciertos rangos especificados, llamados puntos fijos o valores de calibracin; el caso ms clsico es el de los termostatos. Existen mecanismos tanto de retroalimentacin (feedback) como de prealimentacin (feedforward), y tanto reductores de oscilacin como amplificadores; pero el tipo de retroalimentacin negativa es el ms comn. La ventaja sealada para este estilo radica en su elasticidad ante perturbaciones externas. b) Arquitectura basada en atributos En este contexto, los estilos arquitectnicos definen las condiciones en que han de ser usados. Adems de especificar los habituales componentes y conectores, los estilos basados en atributos incluyen atributos de calidad especficos que declaran el comportamiento de los componentes en interaccin. Estilos Peer-to-Peer Esta familia, tambin llamada de componentes independientes, consiste por lo general en procesos independientes o entidades que se comunican a travs de mensajes. Cada entidad puede enviar mensajes a otras entidades, pero no controlarlas directamente. Los mensajes pueden ser enviados a componentes nominados o propalados mediante broadcast. Miembros de la familia son los estilos basados en eventos, en mensajes (Chiron-2), en servicios y en recursos. a) Arquitectura basada en eventos Las arquitecturas basadas en eventos se vinculan histricamente con sistemas basados en actores, daemons y redes de conmutacin de paquetes (publicacin-suscripcin). Los conectores de estos sistemas incluyen procedimientos de llamada tradicionales y vnculos entre anuncios de eventos e invocacin de procedimientos. La idea dominante en la invocacin implcita es que, en lugar de invocar un procedimiento en forma directa (como se hara en un estilo orientado a objetos) un componente puede anunciar mediante difusin uno o ms eventos. Un componente de un sistema puede anunciar su inters en un evento determinado asociando un procedimiento con la manifestacin de dicho evento. Un caso clsico en ambientes Microsoft sera el Servicio de Notificacin de SQL Server. Cuando el evento se
CIBERTEC
84
anuncia, el sistema invoca todos los procedimientos que se han registrado para l. De este modo, el anuncio de un evento implcitamente ocasiona la invocacin de determinados procedimientos en otros mdulos. Los ejemplos de sistemas que utilizan esta arquitectura son numerosos. El estilo se utiliza en ambientes de integracin de herramientas, en sistemas de gestin de base de datos para asegurar las restricciones de consistencia (bajo la forma de disparadores, por ejemplo), en interfaces de usuario para separar la presentacin de los datos de los procedimientos que gestionan stos, y en editores sintcticamente orientados para proporcionar verificacin semntica incremental. b) Arquitectura orientada a servicios Slo recientemente estas arquitecturas que los conocedores llaman SOA han recibido tratamiento intensivo en el campo de exploracin de los estilos. Al mismo tiempo se percibe una tendencia a promoverlas de un sub-estilo propio de las configuraciones distribuidas que antes eran a un estilo en plenitud. Esta promocin ocurre al comps de las predicciones convergentes de Giga o de Gartner que (despus de un par de aos de titubeo y consolidacin) las visualizan en sus pronsticos y cuadrantes mgicos como la tendencia que habr de ser dominante en la primera dcada del nuevo milenio. Ahora bien, este predominio no se funda en la idea de servicios en general, comunicados de cualquier manera, sino que ms especficamente va de la mano de la expansin de los Web services basados en XML, en los cuales los formatos de intercambio se basan en XML 1.0 Namespaces y el protocolo de eleccin es SOAP. SOAP significa un formato de mensajes que es XML, comunicado sobre un transporte que por defecto es HTTP, pero que puede ser tambin HTTPs, SMTP, FTP, IIOP, MQ o casi cualquier otro, o puede incluir prestaciones sofisticadas de ltima generacin como WS-Routing, WSAttachment, WS-Referral, etctera. c) Arquitecturas Basadas en Recursos Roy Fielding considera que REST resulta de la composicin de varios estilos ms bsicos, incluyendo repositorio replicado, cache, cliente-servidor, sistema en capas, sistema sin estado, mquina virtual, cdigo a demanda e interfaz uniforme. Fielding no solamente expande ms all de lo habitual y quiz ms de lo prudente el catlogo de estilos existentes, sino que su tratamiento estilstico se basa en Perry y Wolf antes que en Garlan y Shaw, debido a que la literatura sobre estilos que se deriva de este ltimo texto slo considera elementos, conectores y restricciones, sin tomar en consideracin los datos, que para el caso de REST al menos constituyen una dimensin esencial.
CIBERTEC
85
Resumen
Una de las definiciones que ha sido utilizada por la comunidad de ingeniera de software es la de RUP, citada por Phillipe Kruchten en 1995, que define lo siguiente: La arquitectura de software abarca un conjunto de decisiones significativas sobre la organizacin del sistema de software. Estas decisiones abarcan: la seleccin de los elementos estructurales y sus interfaces, con los que se compone el sistema, junto con su comportamiento tal como se especifica en las colaboraciones entre esos elementos, la composicin de esos elementos estructurales y de comportamiento en subsistemas progresivamente ms grandes, y el estilo arquitectnico que gua esta organizacin. Un ingeniero de software define la arquitectura del sistema en tres etapas: Eleccin del estilo arquitectnico, seleccin de patrones de diseo y diseo de componentes. Si desea saber ms acerca de estos temas, puede consultar los siguientes libros. SOFTWARE ARCHITECTURE IN PRACTICE de Len Bass, Paul Clements y Rick Kazman, 2 edicin. Aqu encontrar la descripcin completa de estilos arquitectnicos y patrones de diseo. INGENIERA DEL SOFTWARE. UN ENFOQUE PRCTICO de Roger Pressman, 6 edicin. En el captulo 10 de este libro se describe el diseo arquitectnico de un sistema. Adems, puede consultar las siguientes pginas. http://sophia.javeriana.edu.co/~javila/pregrado/arquitectura/estilosArquitectonicos.pdf Aqu se presenta un documento que describe los estilos arquitectnicos clasificados por Shaw y Garlan. http://www.ibm.com/developerworks/rational/library/feb06/eeles/ En este enlace, Peter Eales (Seor IT Architect de IBM) explica lo que es una arquitectura de software.
CIBERTEC
86
3. DISEO DE CASOS DE USO

El diseo de los casos de uso es la actividad del diseo orientado a objetos que consiste en: Identificar las clases de diseo y/o subsistemas necesarios para la realizacin del caso de uso. Distribuir el comportamiento del caso de uso entre las clases y/o subsistemas de diseo. Debido a que la clave para la reutilizacin es anticiparse a los nuevos requisitos y cambios, de modo que los sistemas evolucionen de forma adecuada, es conveniente que para realizar los pasos del diseo de casos de uso, se seleccione el patrn o una combinacin de patrones a aplicar en la implementacin. Cada patrn permite que algunos aspectos de la estructura del sistema puedan cambiar independientemente de otros aspectos. Facilitan la reutilizacin, extensibilidad y mantenimiento.
Patrones de diseo
Como analistas y programadores vamos desarrollando a diario nuestras habilidades para resolver problemas usuales que se presentan en el desarrollo del software. Por cada problema que se nos presenta pensamos distintas formas de resolverlo, incluyendo soluciones exitosas que ya hemos usado anteriormente en problemas similares. Es as que a mayor experiencia que tengamos, nuestro abanico de posibilidades para resolver un problema crece, pero al final siempre habr una sola solucin que mejor se adapte a nuestra aplicacin. Si documentamos esta solucin, podemos reutilizarla y compartir esa informacin que hemos aprendido para resolver de la mejor manera un problema especfico. Los patrones del diseo tratan los problemas que se repiten y que se presentan en situaciones particulares del diseo, con el fin de proponer soluciones a ellas. Por lo tanto, los patrones de diseo son soluciones exitosas a problemas comunes. Asimismo, son descripciones de clases cuyas instancias colaboran entre s. Cada patrn es adecuado para ser adaptado a un cierto tipo de problema. Para describir un caso debemos especificar: Nombre Propsito o finalidad Sinnimos (otros nombres por los que puede ser conocido) Problema al que es aplicable Estructura (diagrama de clases) Participantes (responsabilidad de cada clase) Colaboraciones (diagrama de interacciones) Implementacin (consejos, notas y ejemplos) Otros patrones con los que est relacionado
3.1.1. Patrones GOF El catlogo ms famoso de patrones se encuentra en Design Patterns: Elements of Reusable Object-Oriented Software, de Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides, 1995, Addison-Wesley, tambin conocido como el libro GOF (Gang-OfFour).
CIBERTEC
87
Los autores de este patrn recopilaron 23 patrones que son utilizados por muchos diseadores de software orientado a objetos.
Figura 3.4. Patrones de diseo segn GOF. En la figura 3.4 se muestra la clasificacin de los patrones GOF considerando dos aspectos: el propsito para el que han sido definidos y el mbito. Segn el propsito para el que han sido definidos existen 3 tipos: Creacionales: Solucionan problemas de creacin de instancias. Nos ayudan a encapsular y abstraer dicha creacin. Estructurales: Solucionan problemas de composicin (agregacin) de clases y objetos. De Comportamiento: Dan soluciones respecto a la interaccin y responsabilidades entre clases y objetos, as como los algoritmos que encapsulan.
Segn el mbito se clasifica en patrones de clase y de objeto, es as que se cuenta con 6 tipos: Creacionales
Creacional de la Clase Los patrones creacionales de Clases usan la herencia como un mecanismo para lograr la instanciacin de la Clase. Por ejemplo el mtodo Factora. Creacional del objeto Los patrones creacionales de objetos son ms escalables y dinmicos comparados de los patrones creacionales de Clases. Por ejemplo la Factora abstracta y el patrn Singleton.
CIBERTEC
88
Estructurales
Estructural de la Clase Los patrones estructurales de Clases usan la herencia para proporcionar interfaces ms tiles combinando la funcionalidad de mltiples Clases. Por ejemplo el patrn Adaptador (Clase). Estructural de Objetos Los patrones estructurales de objetos crean objetos complejos agregando objetos individuales para construir grandes estructuras. La composicin de l patrn estructural del objeto puede ser cambiado en tiempo de ejecucin, el cual nos da flexibilidad adicional sobre los patrones estructurales de Clases. Por ejemplo el Adaptador (Objeto), Facade, Bridge, Composite.
Comportamiento
Comportamiento de Clase Los patrones de comportamiento de Clases usan la herencia para distribuir el comportamiento entre Clases. Por ejemplo Interpreter. Comportamiento de Objeto Los patrones de comportamiento de objetos nos permiten analizar los patrones de comunicacin entre objetos interconectados, como objetos incluidos en un objeto complejo. Ejemplo Iterator, Observer, Visitor.
La figura 3.5 muestra la plantilla que utilizan los autores de patrones GOF para describir un patrn.
Figura 3.5. Plantilla de Patrones GOF. 3.1.2. Patrones J2EE Con la aparicin del J2EE, todo un nuevo catlogo de patrones de diseo apareci. Desde que J2EE es una arquitectura por si misma que involucra otras arquitecturas, incluyendo servlets, JavaServer Pages, Enterprise JavaBeans, y ms, merece su propio conjunto de patrones especficos para diferentes aplicaciones empresariales.
CIBERTEC
89
De acuerdo al libro "J2EE PATTERNS Best Practices and Design Strategies", existen 5 capas en la arquitectura J2EE: Cliente: Esta capa corresponde a lo que se encuentra en el computador del cliente. Es la interfaz grfica del sistema y se encarga de interactuar con el usuario. J2EE tiene soporte para diferentes tipos de clientes incluyendo clientes HTML, applets Java y aplicaciones Java. Presentacin: La capa de presentacin es la que ve el usuario, comunica y captura la informacin proveniente de l. Negocio: Es donde reside el ncleo del sistema. Se comunica con la capa de presentacin para recibir y enviar los datos al usuario. Integracin: La capa de integracin es donde residen los datos y es la encargada de acceder a los mismos. Contiene uno o ms gestores de base de datos. Recibe solicitudes de almacenamiento o recuperacin de informacin desde la capa de negocio. Recurso: Es la capa donde reside la base de datos y sistemas legados.
Nombre Capa Cliente Capa de Presentacin Capa de Negocios Capa de Integracin Capa de Recursos
Quines la componen
Dnde se ubica
Aplicaciones cliente, applets, aplicaciones PC Cliente y otras GUIs JSP, Servlet y otras UIs EJBs y otros objetos de negocios JMS, JDBC Bases de Datos, Sistemas Legados Servidor J2EE Servidor J2EE Servidor J2EE Servidor BD
Tabla 3.1. Capas de la Arquitectura J2EE.
Existen 15 patrones J2EE que estn divididos en 3 de las capas descritas: presentacin, negocio e integracin. Cabe sealar que todos estos patrones poseen tanto caractersticas de diseo como de arquitectura. Capa de Presentacin Patrn Descripcin
Un objeto que est entre el cliente y los Decorating Filter / Intercepting componentes Web. Este procesa las Filter peticiones y las respuestas.
CIBERTEC
90
Front Controller/ Front Component
Un objeto que acepta todos los requerimientos de un cliente y los direcciona a manejadores apropiados. El patrn Front Controller podra dividir la funcionalidad en 2 diferentes objetos: el Front Controller y el Dispatcher. En ese caso, El Front Controller acepta todos los requerimientos de un cliente y realiza la autenticacin, y el Dispatcher direcciona los requerimientos a manejadores apropiados. Un objeto helper que encapsula la lgica de acceso a datos en beneficio de los componentes de la presentacin. Por ejemplo, los JavaBeans pueden ser usados como patrn View Helper para las pginas JSP. Un objeto vista que est compuesto de otros objetos vista. Por ejemplo, una pgina JSP que incluye otras pginas JSP y HTML usando la directiva include o el action include es un patrn Composite View. El Controlador acta como Front Controller pero con una cosa importante: aqu el Dispatcher (el cual es parte del Front Controller) usa View Helpers a gran escala y ayuda en el manejo de la vista. Es con el controlador actuando como Front Controller pero con un asunto importante: aqu el Dispatcher (el cual es parte del Front Controller) no usa View Helpers y realiza muy poco trabajo en el manejo de la vista. El manejo de la vista es maniobrado por los mismos componentes de la Vista.
View Helper
Composite view
Service To Worker
Dispatcher View
Capa de Negocio Patrn Descripcin Un objeto que reside en la capa de presentacin y en beneficio de los otros componentes de esta capa llama a mtodos remotos en los objetos de la capa de negocios. Un objeto serializable para la transferencia de datos sobre la red.
Business Delegate
Value Object/ Data Transfer Object/ Replicate Object
El uso de un bean de sesion como una fachada (facade) para encapsular la Session Faade/ Session Entity complejidad de las interacciones entre los Faade/ Distributed Faade objetos de negocio y participantes en un flujo de trabajo. El Session Faade maneja
CIBERTEC
91
los objetos de negocio y proporciona un servicio de acceso uniforme a los clientes. Aggregate Entity Value Object Assembler Un bean entidad que es construido o es agregado a otros beans de entidad. Un objeto que reside en la capa de negocios y crea Value Objets cuando es requerido. Es un objeto que maneja la ejecucin de consultas SQL, cach y procesamiento del resultado. Usualmente implementado como beans de sesin. Consiste en utilizar un objeto Service Locutor para abstraer toda la utilizacin JNDI y para ocultar las complejidades de la creacin del contexto inicial, de bsqueda de objetos home EJB y recreacin de objetos EJB. Varios clientes pueden reutilizar el objeto Service Locutor para reducir la complejidad del cdigo, proporcionando un punto de control.
Value List Handler/ Page-byPage Iterator/ Paged List
Service Locator
Capa de Integracin Patrn Descripcin Consiste en utilizar un objeto de acceso a datos para abstraer y encapsular todos los accesos a la fuente de datos. El DAO maneja la conexin con la fuente de datos para obtener y almacenar datos. Se utiliza para recibir peticiones y mensajes asncronos de los clientes. Cuando se recibe un mensaje, el Service Activator localiza e invoca a los mtodos de los componentes de negocio necesarios para cumplir la peticin de forma asncrona.
Data Access Object
Service Activator
Extensiones de UML para aplicaciones web (WAE)

En 1998, Jim Conallen (empleado de Rational Software Corporation) defini una extensin de UML para representar aplicaciones Web, a la que denomin WAE (Web Application Extension). Esta extensin es la convencin ms difundida y aceptada hasta nuestros das y podramos decir que define el estndar de facto. Lo primero que se plante Jim es que las aplicaciones Web presentan elementos que UML no contemplaba para su representacin. UML no facilitaba la tarea de diferenciar cdigo cliente (scripts) de cdigo servidor. As fue que a partir de UML extendi una nueva semntica: estereotipos, listados de etiquetas (tags) y restricciones (constraints).
CIBERTEC
92
Estereotipos: Define una nueva semntica al modelo. Lista de etiquetas: Consiste en una lista de campo-valor. Restricciones: Definen las reglas para trabajar con determinados estereotipos.
En los siguientes puntos se describir cmo representar los elementos de una aplicacin web en diagramas de clases, diagrama de componentes y diagrama de secuencia. 1.1.1. Diagramas de clases
a) Estereotipos en clases
Estereotipos en clases define los siguientes estereotipos: <<Server Page>> Son las pginas que contienen scripts o cdigo ejecutable por el servidor. (.php , .asp , .jsp) <<Client Page>> Son las pginas que estn en el lado del cliente, normalmente pginas HTML y scripts (jsvascript). <<Form>> Es la representacin de un formulario. Es cdigo HTML que contiene etiquetas de formulario como: <input>, <textarea>, <select>, etc.
Estos estereotipos se pueden seguir ampliando a partir de una clase, la cual es un elemento que ya existe en UML. Otros ejemplos de estereotipo pueden ser: <<Javascript>>, <<Applet>> o <<Flash>>.
b) Estereotipos en relaciones
Define los siguientes estereotipos para las relaciones de asociacin unidireccionales: <<build>> Es una asociacin unidireccional entre una pgina servidor y una pgina cliente. La pgina servidor "construye" a la pgina cliente. <<link>> Es una asociacin unidireccional entre una pgina y otra pgina del sistema (pgina servidor o pgina cliente). <<submit>> Es una asociacin unidireccional entre un formulario y una pgina servidor. <<redirect>> Es tambin una asociacin unidireccional que indica que una pgina Web redirige hacia otra. En caso de que la pgina origen sea una client page esta asociacin corresponder con la etiqueta META y valor HTTP-EQUIV de Refresh. <<forward>> Es una asociacin unidireccional entre una pgina servidor y otra pgina servidor o una pgina cliente. Esta asociacin representa la delegacin de procesamiento de la solicitud de un cliente para un recurso a otra pgina del lado del servidor. <<object>> Es una relacin entre una pgina cliente y una clase, normalmente uno que representa a un applet, el control ActiveX u otro componente.
CIBERTEC
93
<<include>> Se da entre una pgina servidor y otra similar o pgina cliente. Durante la ejecucin de la pgina esta asociacin indica que la pgina incluida es procesada.
En las siguientes figuras se muestra dos diagramas de clases que utilizan los diferentes estereotipos descritos para clases y relaciones.
Figura 3.6. Diagrama de clases con pginas y relaciones <<build>> y <<submit>>.
Figura 3.7. Diagrama de clases con pginas y relaciones <<build>> y <<redirect>>.
CIBERTEC
94
1.1.2.
Diagrama de Componentes
Ilustran las piezas del software que conformarn un sistema. Un

componente puede ser un ejecutable, una librera esttica o dinmica, clases de Java, etc. Un componente abstrae un conjunto de clases para que pueda el componente ser utilizado como una unidad, esto es el API que todo componente debe proveer. Su funcionamiento es igual que con UML 2.0. En WAE se construye un diagrama de componentes tanto para mostrar el flujo de navegacin de la aplicacin como para representar los componentes que contiene el servidor.
Componente: Pgina esttica Componente: Pgina dinmica Las dependencias en este diagrama representan hipervnculos.
Figura 3.8. Flujo de navegacin. En la siguiente figura se ilustra un componente para abstraer el hecho de que una pgina servidor genera una pgina de cliente, por ello <<server page>> y <<client page>> se modela agrupndolos como un componente. Asimismo, se define el estereotipo <<virtual root>> en un paquete para representar el contenedor de los componentes de la aplicacin web.
Componente que representa el recurso solicitado a travs del URL. Ejemplo: updateProfile.jsp
El paquete <<virtual root>> representa el paquete que contiene los componentes de la aplicacin web.
Figura 3.9. Diagrama de componentes de una aplicacin web.
CIBERTEC
95
1.1.3.
Diagrama de secuencia Describe el comportamiento de los casos de uso en funcin del tiempo. Su uso respecto a UML no cambia. En este diagrama se escriben las lneas de tiempo de los actores y componentes implicados. Estos ltimos se envan mensajes entre ellos describiendo el comportamiento del sistema. Las pginas del cliente pueden enviarse mensajes as mismo (funciones javascript donde el servidor no interviene) pero si vemos fechas asncronas que van desde el cliente hasta el servidor, que solo pueden ser interpretadas por el programador como el uso de AJAX, ya que la tecnologa web es sncrona.
Realizacin de diseo de casos de uso con patrn arquitectnico MVC

La realizacin de casos de uso es una coleccin de varios diagramas UML que validan que nosotros tenemos las clases, responsabilidades e interacciones de los objetos necesarios para dictaminar el comportamiento que debe tener el proceso de nuestro caso de uso. En el anlisis, nuestra realizacin de casos de uso contiene slo el anlisis de clases y objetos, los cuales pueden contar con varios diagramas UML, como pueden ser los diagramas de clases y los de interaccin. En nuestro diseo, la realizacin contendr informacin que explica cmo los pasos dentro de un caso de uso se llevarn a cabo colaborando con el diseo de objetos. Los diagramas de clase, de interaccin y descripcin derivados de los requisitos detallarn nuestras realizaciones. Antes de indicar cmo se desarrollan las realizaciones de diseo de un caso de uso, primero se mostrar la organizacin de las clases de diseo en capas, subsistemas y libreras que utilizaremos en el curso, aplicando patrn arquitectnico MVC: Capa Subsistema/Libreras Elementos de diseo Clases estereotipadas: Pginas HTML: <<Client Page>> Pginas JSP: <<Server Page>>, <<Client Page>> y <<HTML Form>> Clase estereotipada para servlets: <<Http Servlet>>
Clases de diseo: beans.
Clases de diseo: clases utilitarias. Tabla 3.2. Capas, subsistemas, libreras y elementos de diseo.
CIBERTEC
96
A partir de la Especificacin del Caso de Uso Mantener Cajeros crearemos los diagramas de la realizacin de diseo del caso de uso.
ESPECIFICACIN DE CASO DE USO: Mantener cajeros

1. Descripcin El caso de uso permite mantener actualizado el registro de los cajeros de la clnica. De acuerdo a su necesidad el administrador de la clnica puede agregar, actualizar y desactivar un cajero. 2. Actor(es) Administrador. 3. Flujo de Eventos 3.1. Flujo Bsico 1. El caso de uso se inicia cuando el Administrador selecciona la opcin Cajeros en la interfaz del men principal. 2. El sistema muestra la interfaz MANTENER CAJERO con la lista de cajeros con los campos: cdigo, nombres, apellido paterno, apellido materno, telfono, correo, direccin, fecha de registro, fecha de actualizacin y estado. Adems muestra las opciones: Agregar Cajero, Actualizar Cajero y Desactivar Cajero. 3. Si el Administrador elige un cajero a. Si elige Actualizar ver el Subflujo Actualizar Cajero. b. Si elige Desactivar ver el Subflujo Desactivar Cajero. 4. Si el Administrador NO elige un cajero a. Si elige Agregar ver el Subflujo Agregar Cajero. 5. El Administrador selecciona Salir y el caso de uso finaliza. 3.2. Subflujos 3.2.1. Agregar Cajero 1. El sistema muestra la interfaz CAJERO con los siguientes campos: cdigo (slo lectura), nombres, apellido paterno, apellido materno, telfono, correo, direccin, fecha de registro (slo lectura) y fecha de actualizacin (slo lectura). Adems muestra las opciones: Aceptar y Cancelar. 2. El Administrador ingresa los datos del Cajero. 3. El Administrador selecciona la opcin Aceptar. 4. El sistema valida los datos ingresados. 5. El sistema genera un nuevo cdigo de cajero y obtiene la fecha del sistema para la fecha de registro y la fecha de actualizacin 6. El sistema graba un nuevo registro de cajero y muestra el MSG Cajero creado con cdigo Nro. 999999. 7. El Administrador cierra la interfaz CAJERO y regresa a la interfaz MANTENER CAJERO con la lista de cajeros actualizada y el subflujo finaliza. 3.2.2. Actualizar Cajero 1. El sistema muestra los datos del cajero seleccionada en la interfaz CAJERO: cdigo (slo lectura), nombres, apellido paterno, apellido materno, telfono, correo, direccin, fecha de registro (slo lectura) y fecha de actualizacin (slo lectura). Adems muestra las opciones: Aceptar y Cancelar. 2. El Administrador actualiza los datos del cajero. 3. El Administrador selecciona la opcin Aceptar.
CIBERTEC
97
4. El sistema valida los datos ingresados del cajero. 5. El sistema obtiene la fecha del sistema para la fecha de actualizacin, actualiza el registro de cajero, y muestra el MSG Cajero actualizado satisfactoriamente. 6. El Administrador cierra la interfaz CAJERO y regresa a la interfaz MANTENER CAJERO con la lista de cajeros actualizada y el subflujo finaliza. 3.2.3. Desactivar Cajero 1. El sistema muestra el MSG: Est seguro que desea desactivar el(los) cajero(s) seleccionado(s)?. 2. El Administrador selecciona la opcin YES para confirmar la desactivacin. 3. El sistema actualiza el registro del(los) cajero(s) en estado Desactivado. 4. El sistema muestra la interfaz MANTENER CAJERO con la lista de cajeros actualizada y termina el subflujo. 3.3. Flujos Alternativos 1. Datos del Cajero Invlidos Si los datos ingresados son nulos o invlidos, tanto en los subflujos Agregar como en Actualizar Cajero, el sistema muestra el MSG: Se han encontrado datos invlidos y los subflujos continan en el paso 2. 2. Cajero ya existe Si el sistema detecta que el cajero ya existe en el paso 4 del subflujo Agregar Cajero, muestra el MSG: Cajero ya existe y el subflujo finaliza. 3. No confirma Desactivacin Si el Administrador selecciona NO en el paso 2 del subflujo Desactivar Cajero, finaliza el subflujo. 4. Precondiciones 1. El Administrador est identificado en el sistema. 2. Lista disponible de Cajeros. 5. Post Condiciones 1. En el sistema quedar registrado el nuevo Cajero. 2. En el sistema quedar actualizado el registro del Cajero. 3. En el sistema quedar desactivado el Cajero. 6. Puntos de Extensin Ninguno. 7. Requisitos Especiales Ninguno.
CIBERTEC
98
A continuacin se muestra los diagramas de la realizacin de diseo de caso de uso. 1) Realizacin de diseo
2)
Diagrama de Clases de Diseo
CIBERTEC
99
3)
Diagramas de Secuencia
CIBERTEC CIBERTEC
100
Elabore el diagrama de secuencia para los subflujos agregar, actualizar y desactivar cajeros del caso de uso Mantener Cajeros.
CIBERTEC CIBERTEC
101
Realizacin de diseo de casos de uso con patrn arquitectnico MVC y patrn de diseo DAO
En la siguiente tabla se muestra la organizacin de las clases de diseo e interfaces en capas, subsistemas y libreras que utilizaremos en el curso, aplicando patrn arquitectnico MVC y patrn de diseo DAO: Capa Subsistema/Libreras Elementos de diseo Clases estereotipadas: Pginas HTML: <<Client Page>> Pginas JSP: <<Server Page>>, <<Client Page>> y <<HTML Form>> Clase estereotipada para servlets: <<Http Servlet>> Clases de diseo: servicios, beans y clases DAO. Interfaces que presentan las operaciones de acceso a una tabla.
Clases de diseo: clase abstracta DAOFactory y sus clases hijas. Clases de diseo: clases utilitarias. Tabla 3.3. Capas, subsistemas, libreras y elementos de diseo. A partir de la Especificacin del Caso de Uso Mantener Cajeros crearemos los diagramas de la realizacin de diseo del caso de uso.
ESPECIFICACIN DE CASO DE USO: Mantener cajeros

1. Descripcin El caso de uso permite mantener actualizado el registro de los cajeros de la clnica. De acuerdo a su necesidad el administrador de la clnica puede agregar, actualizar y desactivar un cajero. 2. Actor(es) Administrador 3. Flujo de Eventos 3.1. Flujo Bsico 1. El caso de uso se inicia cuando el Administrador selecciona la opcin Cajeros en la interfaz del men principal.
CIBERTEC
102
2. El sistema muestra la interfaz MANTENER CAJERO con la lista de cajeros con los campos: cdigo, nombres, apellido paterno, apellido materno, telfono, correo, direccin, fecha de registro, fecha de actualizacin y estado. Adems muestra las opciones: Agregar Cajero, Actualizar Cajero y Desactivar Cajero. 3. Si el Administrador elige un cajero a. Si elige Actualizar ver el Subflujo Actualizar Cajero. b. Si elige Desactivar ver el Subflujo Desactivar Cajero. 4. Si el Administrador NO elige un cajero a. Si elige Agregar ver el Subflujo Agregar Cajero. 5. El Administrador selecciona Salir y el caso de uso finaliza. 3.2. Subflujos 3.2.1. Agregar Cajero 1. El sistema muestra la interfaz CAJERO con los siguientes campos: cdigo (slo lectura), nombres, apellido paterno, apellido materno, telfono, correo, direccin, fecha de registro (slo lectura) y fecha de actualizacin (slo lectura). Adems muestra las opciones: Aceptar y Cancelar. 2. El Administrador ingresa los datos del Cajero. 3. El Administrador selecciona la opcin Aceptar. 4. El sistema valida los datos ingresados. 5. El sistema genera un nuevo cdigo de cajero y obtiene la fecha del sistema para la fecha de registro y la fecha de actualizacin 6. El sistema graba un nuevo registro de cajero y muestra el MSG Cajero creado con cdigo Nro. 999999. 7. El Administrador cierra la interfaz CAJERO y regresa a la interfaz MANTENER CAJERO con la lista de cajeros actualizada y el subflujo finaliza. 3.2.2. Actualizar Cajero 1. El sistema muestra los datos del cajero seleccionada en la interfaz CAJERO: cdigo (slo lectura), nombres, apellido paterno, apellido materno, telfono, correo, direccin, fecha de registro (slo lectura) y fecha de actualizacin (slo lectura). Adems muestra las opciones: Aceptar y Cancelar. 2. El Administrador actualiza los datos del cajero. 3. El Administrador selecciona la opcin Aceptar. 4. El sistema valida los datos ingresados del cajero. 5. El sistema obtiene la fecha del sistema para la fecha de actualizacin, actualiza el registro de cajero, y muestra el MSG Cajero actualizado satisfactoriamente. 6. El Administrador cierra la interfaz CAJERO y regresa a la interfaz MANTENER CAJERO con la lista de cajeros actualizada y el subflujo finaliza. 3.2.3. Desactivar Cajero 1. El sistema muestra el MSG: Est seguro que desea desactivar el(los) cajero(s) seleccionado(s)?. 2. El Administrador selecciona la opcin YES para confirmar la desactivacin. 3. El sistema actualiza el registro del(los) cajero(s) en estado Desactivado. 4. El sistema muestra la interfaz MANTENER CAJERO con la lista de cajeros actualizada y termina el subflujo.
CIBERTEC
103
3.3. Flujos Alternativos 1. Datos del Cajero Invlidos Si los datos ingresados son nulos o invlidos, tanto en los subflujos Agregar como en Actualizar Cajero, el sistema muestra el MSG: Se han encontrado datos invlidos y los subflujos continan en el paso 2. 2. Cajero ya existe Si el sistema detecta que el cajero ya existe en el paso 4 del subflujo Agregar Cajero, muestra el MSG: Cajero ya existe y el subflujo finaliza. 3. No confirma Desactivacin Si el Administrador selecciona NO en el paso 2 del subflujo Desactivar Cajero, finaliza el subflujo. 4. Precondiciones 1. El Administrador est identificado en el sistema. 2. Lista disponible de Cajeros. 5. Post Condiciones 1. En el sistema quedar registrado el nuevo Cajero. 2. En el sistema quedar actualizado el registro del Cajero. 3. En el sistema quedar desactivado el Cajero. 6. Puntos de Extensin Ninguno. 7. Requisitos Especiales Ninguno.
A continuacin se muestra los siguientes artefactos de la realizacin de diseo de caso de uso:

1. Realizacin de diseo 2. Diagrama de clases de diseo 3. Diagramas de secuencia
a. Flujo bsico b. Flujo del mtodo listar c. Subflujo agregar d. Flujo del mtodo autogenerado e. Flujo del mtodo agregar 1. Realizacin de diseo
CIBERTEC
104
2. Diagrama de clases de diseo
CIBERTEC CIBERTEC
105
3. Diagrama de secuencia
CIBERTEC
106
Elabore el diagrama de secuencia para los subflujos agregar, actualizar y desactivar cajeros y de los mtodos del DAO del caso de uso Mantener Cajeros.
CIBERTEC CIBERTEC
107
Resumen
El modelado de aplicaciones web es muy similar al de cualquier otro sistema, solo es cuestin de realizar algunas extensiones a UML, para representar ciertas caractersticas propias de estas aplicaciones, para lo cual debemos de centrarnos en los detalles de la funcionalidad, a la hora de desarrollar aplicaciones web y no tanto en la presentacin, ya que si se considera el caso opuesto se pueden crear sitios que pudieran ser muy atractivos en un principio, pero con el tiempo dejen de ser funcionales. Los patrones de diseo son soluciones recurrentes a problemas dentro de un contexto. Describen con algn nivel de abstraccin, soluciones expertas a un problema. Los patrones de diseo son tiles porque: Contribuyen a reutilizar el diseo, permitiendo ser aplicado en una gran cantidad de situaciones. Mejoran la flexibilidad, modularidad y extensibilidad. Aumentan la escalabilidad del sistema.
Los patrones de diseo GOF son utilizados en aplicaciones orientadas a objetos. Los autores de este patrn recopilaron 23 patrones que son utilizados por muchos diseadores de software. Los patrones de diseo J2EE consisten en soluciones recurrentes y documentadas de problemas comunes de diseo de aplicaciones J2EE. Muchas de estas soluciones se basan en los patrones GOF. Adems, puede consultar las siguientes pginas. http://www.drdobbs.com/article/printableArticle.jhtml?articleID=184414696&de pt_url=/architect/ En esta direccin se describe los elementos de una aplicacin web utilizando WAE. http://www.ingenierosoftware.com/analisisydiseno/patrones-diseno.php Aqu se presenta una descripcin breve sobre patrones de diseo GOF. http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html En este enlace encontrar la descripcin completa de los patrones J2EE. http://www.programacion.com/java/tutorial/patrones2/8/ En este enlace encontrar un ejemplo de aplicacin del patrn DAO del patrn J2EE con la estrategia Factory del patrn GOF.
CIBERTEC
108
CIBERTEC
109
ANEXO
PLANTILLAS REQUISITOS
CONTENIDO

DE
DOCUMENTOS
DE LA
GESTIN
DE
Reporte de Especificacin de Software (RES) Reporte de Diseo de Software (RDS)
CIBERTEC
110
Reporte de Especificacin de Software (RES)

[Nombre de Gerencia Sponsor del proyecto]
[Nombre del proyecto]
[Mes y Ao Inicio del Proyecto]

[Este documento es la plantilla base para elaborar el documento Reporte de Especificacin de Software. Los textos que aparecen entre corchetes son explicaciones de qu debe contener cada seccin. Dichos textos se deben seleccionar y sustituir por el contenido que corresponda. En caso que alguna de las secciones del presente documento no aplique a su proyecto pueden usarse las frases No hay cambios, No hay impacto en esta seccin, La solucin que se est implementando no tiene impacto en esta seccin, No aplican para el proyecto (No borrar secciones del documento)]
Elaborado por:
Revisado por:
Aprobado por:
Fecha:
Fecha:
Fecha:
CIBERTEC CIBERTEC
111
HISTORIAL DE REVISIONES
Versin Autor Descripcin Fecha de Elaboracin Fecha de Revisin Revisado por <Persona(s) que revisa(n) el documento>
<x.x>
<Persona que elabora <Detalles> el documento>
<Fecha de <Fecha de Elaboracin> Revisin>
CIBERTEC
112
Contenido
1. 2. 3. Error! No se encuentra el origen de la referencia. .... Error! Marcador no definido. Error! No se encuentra el origen de la referencia. ............................................ 113 Error! No se encuentra el origen de la referencia. ...... Error! Marcador no definido. 3.1. Dentro del Alcance........................................................................ 113 3.2. Fuera del Alcance ......................................................................... 113 3.3. Restricciones................................................................................ 113 4. Procesos de Negocio ........................................................................... 113 4.1. 4.2. 4.3. 4.4. 5. 6. 7. Error! No se encuentra el origen de la referencia.Error! Error! No se encuentra el origen de la referencia.Error! Error! No se encuentra el origen de la referencia.Error! Error! No se encuentra el origen de la referencia.Error! Marcador Marcador Marcador Marcador no no no no definido. definido. definido. definido.
Error! No se encuentra el origen de la referencia. .... Error! Marcador no definido. Error! No se encuentra el origen de la referencia. .... Error! Marcador no definido. Error! No se encuentra el origen de la referencia. .... Error! Marcador no definido. 7.1. 7.2. 7.3. 7.4. 7.5. 7.6. 7.7. 7.8. Lista de Actores de Sistema ................... Error! Marcador no definido. Diagrama de Actores del Sistema ........... Error! Marcador no definido. Arquitectura del Sistema Diagrama de PaquetesError! Marcador no definido. Lista de Casos de Uso del Sistema por PaqueteError! Marcador no definido. Diagrama de Casos de Uso por Paquete... Error! Marcador no definido. Priorizacin de los Casos de Uso del SistemaError! Marcador no definido. Matriz de Modelo de Negocio y Modelo de SistemaError! Marcador no definido. Especificacin de los Casos de Uso del SistemaError! Marcador no definido. CUS01 - Nombre del CUS ...................... Error! Marcador no definido.
8. 9.
Flujo General de Navegacin........................ Error! Marcador no definido. Esquema de Seguridad ............................... Error! Marcador no definido.
CIBERTEC
113
1.
Antecedentes
[Describa la situacin actual y las necesidades o problemas que se pretende atender. Recuerde que debe tomar como informacin base lo registrado en el documento Planificacin del Proyecto (PP).]
2.
Objetivos
[Es la explicacin resumida, pero clara, de lo que se pretende con el requerimiento, es decir la visin de ste. Recuerde que debe tomar como informacin base los Objetivos del Negocio especificados en el documento Situacin del Negocio.]
3.
Alcance 3.1. Dentro del Alcance

[En esta seccin deber incluir el alcance definido en el PP. Es posible detallar el alcance siempre y cuando no vare en cuanto al original definido en el PP.]
3.2.
Fuera del Alcance

[En esta seccin deber incluir lo que no es parte del alcance del proyecto definido en el PP. Es posible detallar lo que queda fuera del alcance siempre y cuando no vare en cuanto al original definido en el PP.]
3.3.
Restricciones
[En esta seccin deber incluir las restricciones del proyecto definidas en el PP. Es posible detallar ms restricciones relacionadas con los requisitos siempre y cuando no varen las que se definieron originalmente en el PP.]
3.4.
Supuestos
[En esta seccin deber incluir los supuestos del proyecto definidos en el PP. Es posible detallar ms supuestos relacionados con los requisitos siempre y cuando no varen las que se definieron originalmente en el PP.]
4.
Procesos de Negocio 4.1. Lista de Casos de Uso de Negocio

[En esta seccin deber listar los casos de uso de negocio que se obtuvieron a partir de los procesos de negocio identificados dentro del mbito de la solucin y a los cuales se les dar el soporte con el producto software. Cada Caso de Uso de Negocio deber ser identificado con un cdigo nico y correlativo. Ejemplo CUN01. De ser necesario deber incorporar un diagrama de casos de uso de negocio.]
Caso de uso del negocio

CUN01 [Nombre del CUN01] CUN02 [Nombre del CUN02]
Descripcin
[Descripcin del flujo de trabajo del CUN01.] [Descripcin del flujo de trabajo del CUN02.]
CIBERTEC
114
4.2.
Realizacin de los Casos de Uso de Negocio

[En esta seccin deber desarrollar los diagramas de actividades y diagrama de clases de negocio por cada Caso de Uso de Negocio identificado en la seccin 4.1. Por cada juego de diagramas deber identificar cules sern las actividades que sern automatizadas.]
4.3.
Lista de Trabajadores de Negocio

[En esta seccin deber listar a los trabajadores de negocio incluyendo una descripcin por cada uno.]
Trabajador del Negocio
Descripcin
4.4.
Reglas de Negocio
[En esta seccin deber identificar las reglas que regulan la estructura del negocio y cmo ellos operan afectando el funcionamiento de los procesos de negocio. Dichas reglas de negocio son las que se considerarn para el diseo del sistema. Cada Regla de Negocio deber ser identificada con un cdigo nico y correlativo. Ejemplo: RN01. Para identificar las reglas de negocio puede considerar la siguiente clasificacin: Reglas de Estructura: Ejemplo (Todo pedido debe ser realizado por un cliente, y que el mismo debe estar dado de alta. Adems una vez que el cliente haya hecho algn pedido, se deber garantizar que no es posible eliminarlo, al menos que previamente se eliminen todos sus pedidos) Reglas de Derivacin: Ejemplo (El total de un pedido se puede calcular a partir de distintas lneas que lo componen, mientras que el total de cada lnea se puede calcular a partir del nmero de unidades vendidas y el precio por unidad) Reglas de Interfaz o de Modelo de Datos: Ejemplo (No hay precio de artculos negativos, el sexo de una persona slo puede ser masculino o femenino, una fecha tiene que ser siempre una fecha vlida - no existe 30 de febrero) Reglas de Operacin o Reglas de Flujo: Ejemplo (Un cliente puede hacer una peticin de anlisis al laboratorio que anota un encargado: hecho esto, se genera un parte para uno o ms analistas, estos realizan las mediciones correspondientes y devuelven los partes con la informacin pertinente, a partir de la cual se genera un informe de anlisis, que ser vlido solo cuando sea firmado por los responsables de garantizar su correccin)
5.
Requisitos Funcionales
[De acuerdo a lo solicitado explcitamente por el rea usuaria, listar todos los requisitos funcionales del producto software. Considere que los requisitos funcionales que liste debern ser asociados posteriormente a los casos de uso
CIBERTEC
115
(funciones de software). Cada Requisito Funcional deber ser identificado con un cdigo nico y correlativo. Ejemplo: RF01.]
Cdigo
[Cdigo del requisito funcional] RF-001 RF-002 ... RF-00n
Descripcin
[Descripcin detallada del requisito funcional.] [Descripcin detallada del requisito funcional 1.] [Descripcin detallada del requisito funcional 2.] .... [Descripcin detallada del requisito funcional n.]
Proceso de Negocio
[Identificador del proceso de negocio asociado] [CUN01]
6.
Requisitos No Funcionales
[Listar los requisitos no funcionales los mismos que debern ser considerados para el modelo de calidad de producto. Cada Requisito No Funcional deber ser identificado con un cdigo nico y correlativo. Ejemplo: RNF01.]
Tipo de Requisito
[Nombre del tipo de requisito no funcional] Restricciones del Diseo
Cdigo
[Cdigo del requisito no funcional]
Descripcin
[Descripcin detallada del requisito no funcional.]
[Definir cualquier tipo de restriccin de diseo, tales como: proceso de desarrollo de software, sistemas RNF-001 operativos, lenguajes de programacin, administrador de base de datos, conexin a la BD, generador de reportes, manejo de informacin, etc.] RNF-002 Componentes a Adquirir [Identificar los componentes que se deben adquirir o tener en cuenta, para llevar acabo RNF-003 el desarrollo y ejecucin del sistema. Ejemplo: lenguajes de programacin, servidores, estaciones de trabajo, etc.] RNF-004
[Descripcin detallada del requisito no funcional 1.]
CIBERTEC
116
Tipo de Requisito
Interfaces de Usuario
Cdigo
Descripcin
[Describir las interfaces de usuario que sern implementadas en el software. Esto incluye por RNF-005 ejemplo: formatos de la pantalla, pgina o esquemas de las ventanas, reportes, mens, etc.] RNF-006 Interfaces de Hardware [Definir cualquier interfase de hardware que ser soportado RNF-007 por el software, incluyendo estructura lgica, direcciones fsicas, etc.] RNF-008 Interfaces de Software [Especificar el uso de otros productos software requeridos RNF-009 e interfaces con otros sistemas de la aplicacin.] RNF-010 Interfaces Comunicaciones de
[Describir las interfaces de comunicacin para otros RNF-011 sistemas dispositivos, tales como: redes de rea local, dispositivos de serie remota.] RNF-012 Requerimientos Licenciamiento de
[Descripcin detallada del requisito no funcional 12.] [Descripcin detallada del requisito no funcional 13.] [Descripcin detallada del requisito no funcional 14.]
[Identificar las licencias que se RNF-013 requieran para el desarrollo del sistema.] RNF-014
CIBERTEC
117
Tipo de Requisito
Seguridad
Cdigo
Descripcin
[Descripcin detallada del requisito no funcional 15.] [Descripcin detallada del requisito no funcional 16.] [Descripcin detallada del requisito no funcional 17.] [Descripcin detallada del requisito no funcional 18.] [Descripcin detallada del requisito no funcional 19.] [Descripcin detallada del requisito no funcional 20.]
[Describir como ser RNF-015 controlada la seguridad del sistema.] RNF-016 Estndares aplicables [Especificar estndares sistema.] con trabaja qu RNF-017 el
RNF-018 Requisitos del Sistema [Especificar los requerimientos de plataforma tecnolgica RNF-019 necesarios para el diseo y el desarrollo del sistema.] RNF-020 Requisitos de Desempeo [Listar y especificar los requisitos de desempeo con los que debe trabajar el RNF-021 sistema. Ejemplo: Tiempo de respuesta en alguna consulta del sistema.] RNF-022
7.
Modelo de Casos de Uso del Sistema

[En esta seccin deber desarrollar el modelo de sistema o modelo de requisitos. Para ello deber indicar los actores de sistemas, la arquitectura de sistema (organizada en paquetes) y la relacin de casos de uso por cada paquete. Cada Caso de Uso deber ser identificado con un cdigo nico y correlativo. Ejemplo: CUS01.]
7.1.
Lista de Actores de Sistema

[Listar a los actores de sistema.]
Actor del sistema
Descripcin
CIBERTEC
118
7.2.
Diagrama de Actores del Sistema

[Incorpore el diagrama de actores del sistema.]
7.3.
Arquitectura del Sistema Diagrama de Paquetes

[Incorpore el diagrama de paquetes que representa la arquitectura modular del sistema. Cada Paquete deber ser identificado con un cdigo nico y correlativo. Ejemplo: P01.]
7.4.
Lista de Casos de Uso del Sistema por Paquete

[En esta seccin deber listar todos los casos de uso del sistema que se han identificado. Para hacerlo deber tomar como referencia la organizacin del sistema de acuerdo al diagrama de paquetes del punto 7.3.]
Paquete: P01 Nombre del Paquete Caso de uso del sistema Descripcin
CUS01 [Nombre del Caso [Descripcin del caso de uso. En la de Uso] descripcin deber indicar las acciones que permitir el caso de uso.] CUS02 [Nombre del Caso [Descripcin del caso de uso. En la de Uso] descripcin deber indicar las acciones que permitir el caso de uso.]
7.5.
Diagrama de Casos de Uso por Paquete

[Incorpore el diagrama de casos del uso del sistema de acuerdo a los paquetes y la lista trabajada en el punto 7.4.]
Paquete: P01 Nombre del Paquete 7.6. Priorizacin de los Casos de Uso del Sistema
7.6.1. Clasificacin de los Casos de Uso del Sistema [En esta seccin deber clasificar los casos de uso del sistema indicando si son principales, secundarios u opcionales.] Clasificacin Primario Secundario Opcional
Nombre del caso de uso

CUS01 Nombre del caso de uso CUS02 Nombre del caso de uso CUS03 Nombre del caso de uso
7.6.2.
Ciclos de Desarrollo de los Casos de Uso del Sistema [En esta seccin deber indicar en qu ciclo de desarrollo se trabajarn cada uno de los casos de uso del sistema.]
CIBERTEC
119
Ciclo de desarrollo
Ciclo 0 Ciclo 1
Nombre del caso de uso
Clasificacin Primario Secundario Opcional
Ncleo central o CUS01 Nombre del caso de uso CUS02 Nombre del caso de uso CUS03 Nombre del caso de uso
7.7.
Matriz de Modelo de Negocio y Modelo de Sistema

[En esta seccin deber incluir una matriz en la que se pueda evidenciar la trazabilidad entre los procesos de negocio y las funciones del producto software.]
Caso del Actividad a automatizar Requerimiento Caso de uso del uso del funcional sistema negocio N Nombre N Nombre Trabajador N Nombre N Nombre Actor
1 Caso de Uso de Negocio (CUN01) 1 Actividad a ser automatizada Actividad a ser automatizada Actividad a ser automatizada Trabajador de Negocio Trabajador de Negocio Trabajador de Negocio 1 Requisito Funcional (RF01) 1 Casos de Uso de Sistema (CUS01) Actor de Sistema
7.8.
Especificacin de los Casos de Uso del Sistema

7.8.1. Especificacin de Alto Nivel [En esta seccin deber incluir la especificacin de alto nivel de los casos de uso del sistema. Asimismo deber indicar que requisitos funcionales estn asociados a cada caso de uso, tomando como referencia lo indicado en la matriz del punto 7.7.]
Caso de uso:
Actor(es): Propsito: Caso de asociado: Resumen:
CUS01 Nombre del Caso de Uso

Nombre del actor Indicar el propsito del caso de uso
uso Indicar si existe algn caso de uso asociado. De no haber indicar No Aplica. Describir brevemente el caso de uso. Para ello deber indicar como empieza el caso de uso, que actividades desarrolla y como termina. Indicar la clasificacin del caso de uso Indicar el(los) asociados. cdigos de requisitos funcionales
Clasificacin Requerimientos
CIBERTEC
120
7.8.2.
Especificacin Expandida [Por cada caso de uso de sistema especificado deber incluir la especificacin expandida de casos de uso. Para ello deber indicar el flujo bsico y los flujos alternos e incorporar el prototipo con la inclusin de los controles. Deber usar la plantilla que a continuacin se detalla:
CUS01 Nombre del caso de Uso 1. Actores Indicar la lista de actores 2. Propsito Indicar el propsito 3. Breve Descripcin Reutilizar el resumen del punto 7.4 4. Flujo Bsico de Eventos 1. Indicar el flujo bsico de eventos 2. Es posible hacer referencia a las reglas de negocio. 5. Subflujos Indicar los subflujos del flujo bsico. 6. Flujos Alternativos 6.1. Nombre del subflujo 1. Detalle del flujo alterno. 2. Se pueden incluir reglas de negocio. 7. Precondiciones 8.1. Nombre de la precondicin Descripcin de la precondicin 8.2. Perfil de usuario Indicar el perfil de usuario que interacta con el caso de uso 9. Poscondiciones 9.1. Nombre de la poscondicin Descripcin de la poscondicin 10. Puntos de Extensin Indicar si existen puntos de extensin. 11. Requerimientos Especiales Indicar si existen requerimientos especiales. 12. Prototipos Incluir los prototipos asociados al caso de uso.
CIBERTEC
121
8.
Flujo General de Navegacin

[Incluir un rbol de navegacin que permita entender el flujo que se seguir en la navegacin por el aplicativo. El siguiente ejemplo muestra un rbol de navegacin:Aplicacin/mdulo/opcin/subopcin]
Ver Agenda
Encargar Accin
Agenda
Ver Acciones
Ver Alarmas
Accin Propia
APLICACION
Clientes
Consultar Parmetros
Tablas
Resultados
Razones Mantenimiento Matriz CAP Relaciones Matriz GAF
Acciones Enviadas
Avances Reportes Resultados Histricos Resultado de Acciones Seguimiento Semanal
9.
Esquema de Seguridad
[En esta se documenta los esquemas de seguridad en base a perfiles y su acceso a su informacin. Para ello se utiliza una matriz de perfiles de usuario y accesos por Aplicativo/Mdulo/Funcin.]
Aplicativo Funciones por Mdulo Mdulo A Caso de uso del sistema
Perfil 1 x
Perfil 2 x
...
Perfil N x
CIBERTEC
122
CIBERTEC CIBERTEC
123
Reporte de Diseo de Software (RDS)

[Nombre de Gerencia Sponsor del proyecto]
[Nombre del proyecto]
[Mes y Ao Inicio del Proyecto]
[Este documento es la plantilla base para elaborar el documento Reporte de Diseo de Software. Los textos que aparecen entre corchetes son explicaciones de qu debe contener cada seccin. Dichos textos se deben seleccionar y sustituir por el contenido que corresponda. En caso que alguna de las secciones del presente documento no aplique a su proyecto pueden usarse las frases No hay cambios, No hay impacto en esta seccin, La solucin que se est implementando no tiene impacto en esta seccin, No aplican para el proyecto (No borrar secciones del documento)]
Elaborado por:
Revisado por:
Aprobado por:
Fecha:
Fecha:
Fecha:
CIBERTEC
124
HISTORIAL DE REVISIONES
Versin
Autor
Descripcin
Fecha de Elaboracin
Fecha de Revisin
<x.x>
<Persona que elabora <Detalles> el documento>
<Fecha de <Fecha de Elaboracin> Revisin>
Revisado por <Persona(s) que revisa(n) el documento>
CIBERTEC
125
Contenido
1. Introduccin .............................................................................................................................126 1.1. Propsito ...........................................................................................................................126 1.2. Alcance...............................................................................................................................126 1.3. Definiciones, Acrnimos y Abreviaturas................................................................126 1.3.1. Definiciones ....................................................................................................126 1.3.2. Acrnimos ........................................................................................................126 1.3.3. Abreviaturas ...................................................................................................126 1.4. Referencias.......................................................................................................................127 2. 3. 4. 5. Vista General de la Arquitectura ......................................................................................127 Metas y Restricciones de la Arquitectura......................................................................128 Vista de Casos de Uso..........................................................................................................128 Vista Lgica ..............................................................................................................................128 5.1. Realizacin de Casos de Uso Modelo de Anlisis ...........................................129 5.1.1. Cdigo del CUS Nombre del CUS.....................................................129 5.1.2. Diagrama de Clases de Anlisis ..........................................................129 5.2. Modelo Conceptual ........................................................................................................129 5.3. Modelo Lgico..................................................................................................................129 5.4. Modelo de Diseo...........................................................................................................130 5.4.1. Vista de Capas y Subsistemas..............................................................130 5.4.1.1. Capa de Presentacin .......................................................................................130 5.4.1.2. Capa de Negocio.................................................................................................130 5.4.1.3. Capa de Integracin..........................................................................................130 5.4.1.4. Capa de Datos ....................................................... Error! Marcador no definido. 5.4.1.5. Capa de Entidad ................................................... Error! Marcador no definido. 5.4.1.6. Capa de Interfaces o Elementos Comunes Error! Marcador no definido. 5.4.2. Realizacin de Casos de Uso Modelo de Diseo ....................130 5.4.2.1. Cdigo del CUS Nombre del CUS .............................................................130 5.4.2.2. Diagrama de Clases de Diseo .....................................................................130 6. 7. 8. 9. Vista de Procesos ...................................................................................................................131 Vista de Despliegue...............................................................................................................131 Vista de Implementacin ....................................................................................................131 Vista de Integracin del Software ...................................................................................131 9.1. Criterios de Integracin de Software .....................................................................133 9.2. Secuencia de Integracin ...........................................................................................133 9.3. Entorno Necesario para la Integracin ..................................................................134 10. 11. Vista de Datos .....................................................................................................................135 Tamao y Desempeo .....................................................................................................135
CIBERTEC
126
1. Introduccin
[Describa de manera breve el contenido del documento orientando descripcin hacia la utilidad que la misma busca. Recuerde que para elaboracin del documento debe considerar lo desarrollado en el Reporte Especificacin de Software (RES) y que es posible que en esta seccin pueda complementar la informacin del documento base RES.] la la de se
1.1.
Propsito
[En esta seccin se debe proporcionar una visin general de la arquitectura del sistema haciendo referencia a las diferentes vistas que implementarn los diferentes aspectos.]
1.2.
Alcance
[Indicar cul es el alcance del documento. Considere que en el RES se ha desarrollado la Vista de Sistema (funcional) y que para completar la visin total es necesario incluir la vista de arquitectura, vista lgica, vista de implementacin, vista de despliegue y vista de datos. A menudo es necesario incluir una representacin de la arquitectura con consideraciones de infraestructura tecnolgica, relacin con otros sistemas y una vista de procesos en donde se describe la descomposicin del sistema en procesos y los mtodos de comunicacin del sistema.]
1.3.
Definiciones, Acrnimos y Abreviaturas

[Proporcione las definiciones, acrnimos utilizarn en el desarrollo del documento.] 1.3.1. y abreviaturas que se
Definiciones [Indique cada una de las definiciones que son relevantes para el entendimiento del presente documento. Cada definicin deber ir acompaada de una breve descripcin.]
Definicin Asistente de Gestin
Descripcin Trabajador encargado de procesar las rectificaciones de los ciudadanos que lo solicitan. Tambin coordina las entregas de hologramas.
1.3.2.
Acrnimos [Indique cada uno de los acrnimos que son relevantes para el entendimiento del presente documento, para el entendimiento de la arquitectura propuesta y para el diseo detallado. Cada acrnimo deber ir acompaado de una breve descripcin.]
Acrnimo RUP
1.3.3.
Descripcin Rational Unified Process
Abreviaturas [Indique cada una de las abreviaturas que son relevantes para el entendimiento del presente documento, para el entendimiento de la arquitectura propuesta y para el diseo
CIBERTEC
127
detallado. Cada abreviatura deber ir acompaada de una breve descripcin.]
Acrnimo SIGA
Descripcin Sistema Integrado de Gestin Administrativa
1.4.
Referencias [Mencione los documentos que sirven como entrada, o salida, y herramientas que se usarn para el desarrollo del presente documento.]
2. Vista General de la Arquitectura

[En esta seccin describa la arquitectura de software para el sistema actual, y cmo este ser representada. De las vistas de casos de uso, lgica, procesos, despliegue e implementacin; se enumerarn las vistas necesarias, y por cada vista, se deber explicar qu tipo de elementos del modelo contienen.] Ejemplo: A continuacin se muestra la Arquitectura del Sistema ABC, sta est dividida en tres capas lgicas: Capa de Presentacin Capa Controladora Capa de Negocio Asimismo la aplicacin por un criterio de funcionalidad se ha dividido en seis mdulos: Mdulo de Administracin del Negocio Mdulo de Empaquetamiento Mdulo de Mensajera Mdulo de Administracin de Datos Servicios Web X12 Componentes EDI
Web SGSS
Capa de Presentacin
Capa Cliente
Servicios Web X12 Mdulo de Administracin del Negocio Mdulo de Empaquetam.
Componentes EDI Mdulo de Mensajera
Capa de Aplicacin y Lgica de Negocio
Aplicativo Externo 1 Aplicativo Externo N
Capa de Aplicacin
Mdulo de Administracin de Datos

Capa de Base de Datos
Base de Datos del Sistema
Base de Datos 1
Base de Datos 2
Base de Datos N
Capa de Acceso a Datos
La figura anterior muestra la distribucin de los mdulos del software que tendr el sistema, adems de brindar una visin general de ste. Asimismo, se observa la distribucin en tres capas fsicas, las cuales se describen a continuacin:
CIBERTEC
128
Capa de Presentacin En esta capa se despliega la aplicacin Web dedicada a la administracin y configuracin DEL SISTEMA ABC, la cual estar conformada por las pantallas de presentacin al usuario. Estas aplicaciones Web sern pginas ASP.NET. Capa de Negocio Esta capa provee todo lo que es la lgica del negocio, es decir la funcionalidad del sistema, ya sean los procesos administrativos, y los procesos referidos a la elegibilidad, crdito hospitalario (cartas de garanta) y crdito ambulatorio (pedidos de reembolso). Adems, en esta capa se encuentran los servicios publicados, como los Web Services y los Servicios EDI sobre TCP/IP. Capa de Datos Esta capa proporciona los servicios de base datos. El manejador de base de datos utilizado para este sistema ser Microsoft SQL Server 2000.
3.
Metas y Restricciones de la Arquitectura

[En sta seccin se describen los requerimientos de software y objetivos que tienen algn significativo impacto sobre la arquitectura; por ejemplo: seguridad, privacidad de uso del producto, portabilidad, distribucin y reutilizacin. Esto tambin captura las restricciones especiales que quizs apliquen en la: Estrategia de diseo e implementacin, herramientas de desarrollo, estructura del equipo, cronograma, leyes y regulaciones legales y otros. Las restricciones que aqu se recogen pueden complementar a las identificadas en el RES a excepcin de aquellas funcionales.]
4.
Vista de Casos de Uso

[En sta seccin se muestran los actores, paquetes y casos de uso por paquete del modelo de casos de uso. Debe tomar como referencia lo desarrollado en el RES en los puntos 7.2, 7.3 y 7.5. Recuerde que debe respetar la codificacin indicada en el RES para los paquetes y para los casos de uso. Si fuese necesario ampliar en esta seccin, recuerde que es necesario se actualice el RES.]
4.1.
Diagrama de Actores del Sistema [Incorpore el diagrama de actores del sistema.] Arquitectura del Sistema Diagrama de Paquetes [Incorpore el diagrama de paquetes que representa la arquitectura modular del sistema.] Diagrama de Casos de Uso por Paquete [Incorpore el diagrama de casos del uso del sistema de acuerdo a los paquetes mostrados en el punto 4.2.]
4.2.
4.3.
5.
Vista Lgica
[La vista lgica est representada por los diagramas de clases del sistema donde se muestran sus relaciones estructurales y de herencia. La definicin de clase incluye definiciones para atributos y operaciones.]
CIBERTEC
129
5.1.
Realizacin de Casos de Uso Modelo de Anlisis

[Esta seccin ilustra cmo el software trabaja a partir de los casos de uso o escenarios seleccionados, y explica cmo varios elementos del modelo de anlisis contribuyen con ellos funcionalmente. Por cada caso de uso deber desarrollar diagramas de comunicacin y de clases de anlisis. Para ello deber usar el patrn MVC. Para la realizacin deber identificar los escenarios. Dichos escenarios se obtienen del flujo principal y flujos alternativos de la especificacin expandida de casos de uso (ver punto 7.8.2 del RES).] 5.1.1. Cdigo del CUS Nombre del CUS a) Diagrama de Clases de Anlisis [Incluya el diagrama de clases de anlisis.] b) Diagramas de Comunicacin de Anlisis por escenario Cdigo del Escenario - Nombre del Escenario [Identifica el escenario a ser realizado y una breve descripcin. Se recomienda identificar con un cdigo nico a cada escenario (flujo bsico, subflujos, flujos alternativos). Por ejemplo ESC01 para referirse al flujo bsico] Diagrama de Comunicacin del Escenario [Incluya el diagrama de comunicacin en el cual se observe el uso del patrn MVC que se implementa por escenario identificado.]
5.2.
Modelo Conceptual
[Esta seccin ilustra cmo a partir de las clases del tipo entidad se puede identificar una primera propuesta de modelo de persistencia. Para ello se utiliza un diagrama clases por cada paquete que forma parte de la arquitectura del sistema. Se puede hacer referencia a las tarjetas CRC las cuales documentan las responsabilidades y colaboraciones de cada clase de persistencia identificada.]
5.3.
Modelo Lgico
[El modelo lgico es el refinamiento del Modelo Conceptual. Aqu se reducen y/o aumentan clases y slo quedan aquellas que van a ser diseadas como tablas de la Base de Datos. El modelo lgico debe representarse con un diagrama de clases de acuerdo a la arquitectura propuesta. Se sugiere que por cada clase se tenga un diccionario que incluya el nombre, el tipo, la descripcin, atributos, tipo de dato, visibilidad y valor inicial] Nombre Tipo Descripcin Atributo Nombre atributo del Nombre de la Clase Tipo de Clase (Ejemplo Entidad) Descripcin de la clase identificando que representa Tipo de Dato Integer / String / Boolean Visibilidad Pblico Privado / Valor inicial
CIBERTEC
130
5.4.
Modelo de Diseo
[En esta seccin debe representar el refinamiento del modelo de anlisis considerando los requisitos no funcionales identificados en el RES.]
5.4.1. Vista de Capas y Subsistemas

[Incluir el diagrama en el que se represente la arquitectura de diseo. Para ello puede usar un patrn en el cual se usen capas y subsistemas. Adems deber identificar subsistemas requeridos por el uso de algn patrn de diseo como el DAO Factory, Singleton, Front Controller, entre otros. Por cada capa y subsistema deber identificar las clases de diseo que se implementarn]
a) Capa de Presentacin
[Identifique las clases de diseo de la capa de presentacin. Ordene dicha identificacin utilizando los paquetes al interior de las capas denominadas subsistemas.]
b) Capa Controladora
[Identifique las clases de diseo de la capa controladora. Ordene dicha identificacin utilizando los paquetes al interior de las capas denominadas subsistemas.]
c) Capa de Negocio
[Identifique las clases de diseo de la capa de negocio. Ordene dicha identificacin utilizando los paquetes al interior de las capas denominadas subsistemas.]
5.4.2. Realizacin de Casos de Uso Modelo de Diseo

[Esta seccin deber desarrollar los diagramas de secuencia y de clases de diseo a partir de los requisitos no funcionales identificados en el RES y considerando los escenarios identificados en el punto 5.1 del presente documento.]
a) Cdigo del CUS Nombre del CUS Diagrama de Clases de Diseo

[Incluya el diagrama de clases de diseo del caso de uso.]
Cdigo del Escenario - Nombre del Escenario

[Identifica el escenario a ser realizado y una breve descripcin. Se recomienda identificar con un cdigo nico a cada escenario. Por ejemplo ESC01. Deber reutilizar los escenarios identificados en el modelo de anlisis]
Diagrama de Secuencia del Escenario

[Incluya el diagrama de secuencia de diseo en el cual se observe el uso de patrones de diseo para las clases que implementarn cada una de las clases lgicas.]
CIBERTEC
131
6.
Vista de Procesos
[Esta seccin describe la descomposicin del sistema en procesos de primer nivel (un solo hilo de control) y los procesos de ltimo nivel (grupos de procesos de primer nivel). Tambin describe la ubicacin de objetos y clases. Organizar la seccin por los grupos de los procesos que se comunican u obran recprocamente. Describir los modos principales de la comunicacin entre los procesos, tales como el paso de mensajes, interrupciones y qu pasa, las interrupciones, y puntos de encuentro entre procesos.]
7.
Vista de Despliegue
[En esta seccin se describen unas o ms configuraciones fsicas de la red (hardware) que se usarn para el despliegue de los componentes de software que forman parte de la solucin. Para ello puede usar un Diagrama de Despliegue indicando como mnimo, para cada configuracin, en qu nodos fsicos (computadoras, CPU) se ejecuta el software y sus interconexiones (bus, LAN, punto a punto, y as sucesivamente). De ser posible se debe incluir un mapeo de los procesos de la vista de procesos sobre los nodos fsicos. Adems deber especificar los detalles tcnicos de cada nodo en la vista de despliegue.]
Sistema Operativo Windows 2000/XP/2003 Professsional Internet Explorer 6.0 o superior PC Cliente Interno PC Cliente Interno
Intranet Sistema Operativo Windows 2003 Server IIS (Internet Information Server) Net Framework 2.0
Sistema Operativo Windows 2003 Server COM+ (Component Services) Net Framewok 2.0
Sistema Operativo Windows 2003 Server SQL Server 2000
Servidor Intranet Inmuebles Adjudicados Presupuesto Archivo Excel
Servidor COM+
Servidor BD
Servidor BD Otros Sistemas
Sistema Operativo Windows 2003 Server SQL Server 2000 Sistemas: Spring (Macro) Contabilidad MC Adelantos (Macro) Provisiones (Macro) Inmuebles Propios
Internet Web Service Interface Spring PagoActivo HOST Mainframe IBM ZSeries Comprobantes Contabilidad
8.
Vista de Implementacin
[En esta seccin se describe la estructura total del modelo de implementacin, utilizando la descomposicin del software en capas y subsistemas y cmo ste se pondr en prctica. Deber identificar cualquier componente arquitectnico significativo. Debe nombrar y definir las capas y contenidos de las mismas, las reglas que gobiernan la inclusin de una u otra capa, y las caractersticas entre capas. Incluya el diagrama de componentes que muestra las relaciones entre capas. Para cada capa, incluya una sub-seccin con el nombre de la capa, una enumeracin de los subsistemas localizados dentro de la capa y un diagrama de componentes.]
9.
Vista de Integracin del Software

[De requerirlo en esta seccin pude incluir un diagrama integracin del software desarrollado y su interaccin con las diferentes interfaces identificadas en el modelo de diseo. Esta vista se realiza en caso el sistema necesite comunicarse con otros. Ejemplo:]
CIBERTEC
132
INTERFAZ INT1
DESCRIPCION BREVE La interfaz 1 apoya la integracin del Paquete 1 y el Paquete 2, incluye las clases C1, C2, etc. La interfaz 1 apoya la integracin del Paquete 1 y el Paquete 2, incluye las clases C1, C2, etc.
TIPO DE INTERFAZ Interfaz Interna
REFERENCIA La Especificacin de esta interfaz se encuentra en el documento de Especificacin de Componentes La Especificacin de esta interfaz se encuentra en el documento de Especificacin de Componentes La Especificacin de esta interfaz se encuentra en el documento de Especificacin de Componentes La Especificacin de esta interfaz se encuentra en el documento de Especificacin de Componentes La Especificacin de esta interfaz se encuentra en el documento de Especificacin de Componentes
INT2
Interfaz Interna
INT3
Interfaz Interna
INT4
Interfaz Externa
INT5
Interfaz Externa
CIBERTEC
133
9.1.
Criterios de Integracin de Software

[Identifique los criterios que se debern considerar para la integracin de los componentes de software y sus interfaces. Ejemplo: Para la ptima integracin del Software se debern tener que cumplir, considerar y evaluar los siguientes criterios: Antes de realizar la integracin todos los componentes debern haber pasado por pruebas unitarias. Antes de realizar la integracin, todas las incidencias, errores u otras no conformidades encontradas durante las pruebas unitarias debern estar cerradas. Se deber tener preparado los ambientes y entornos para la integracin (Entorno de Desarrollo o Entorno de Integracin). Deber haberse inicializado y migrado data consistente previa a la integracin. Otros Criterios que apoyen a que la integracin resulte un xito.]
9.2.
Secuencia de Integracin
[Defina la secuencia de integracin que se aplicar a los componentes de software y sus interfaces. Ejemplo: Para que el Software se integre totalmente se seguir la siguiente secuencia de integracin: Realizar las pruebas unitarias a todos los componentes
desarrollados (De todos los mdulos). Levantar todos los errores e incidencias encontradas en las pruebas unitarias (De todos los mdulos). Realizar revisin de pares al cdigo fuente y levantar las no conformidades. Asegurarse que todos los componentes del Sistema estn
completamente corregidos (Realizacin de nuevas pruebas sobre los errores encontrados). Validar que el entorno de integracin este listo. Validar que la data haya sido migrada satisfactoriamente. Iniciar la integracin o Integrar Modulo 1 y Modulo 2 integracin entre ambos mdulos. o Integrar Modulo 1 y Modulo 2 y Modulo3 pruebas de integracin entre mdulos. o Integrar Modulo 1 y Modulo 2 y Modulo n pruebas de integracin entre mdulos. Finalizada la Integracin entre mdulos, realizar la integracin con aplicativos externos al sistema en desarrollo. o Integrar Sistema en desarrollo con Sistema Externo1 Realizar Realizar Realizar pruebas de
CIBERTEC
134
(Aplicativo Externo) y Realizar Pruebas. o Integrar Sistema en desarrollo con Sistema Externo2 (Aplicativo Externo) y Realizar Pruebas. Finalmente realizar las pruebas del Sistema y luego de ellas las Pruebas de Aceptacin con los Usuarios Finales.]
9.3.
Entorno Necesario para la Integracin

[En esta seccin se debern identificar y especificar los diversos entornos que se usarn o que estn involucrados en la integracin del Software.]
NOMBRE DEL SERVIDOR IP
Serv_Desa 1.1.15.50
DESCRIPCION Y OBJETIVO DEL SERVIDOR En este servidor se almacenar el cdigo fuente, en este entorno trabajaran los desarrolladores. Aqu se realizarn las pruebas unitarias. SERVICIOS NOMBRE DE APLICACIN FUNCIN INICIO USUARIO SERVICIO Por Ejemplo: Por ejemplo: Por ejemplo: Asynchronous AJAX Presentacin JavaScript + basada en Automtico Adminservice XML estndares usando XHTML y CSS <Servicio 1> <Aplicacin <Funcin 1> Local System Automtico 1> Account <Servicio 2> <Aplicacin <Funcin 2> Local System Automtico 2> Account <Servicio N> <Aplicacin <Funcin 1> Local System Automtico N> Account
CONFIGURACIN DE HARDWARE Y SOFTWARE
Nombre del Sistema Operativo Version Proveedor del Sistema Operativo Nombre del Sistema Proveedor del Sistema Modelo del Sistema Tipo del Sistema Procesador BIOS Version/Date
Microsoft ( R) Windows (R ) Server 200.Enterprise Edition 2.2.3790 Service Pack 2 Build 3790 Microsoft Corporation DEIPSBATCH IBM -[865811Y]X86 based PC x86 Family 6 Model 8 Stepping 3 Genuineintel - 664 IBM ILKT44AUS, 20/09/2001
CIBERTEC
135
SMBIOS Version Total de Memoria Fsica Promedio de Memoria Fsica Total de Memoria Virtual Promedio de Memoria Virtual Tipo de Adaptador Tipo de Producto Nombre del Servicio Direccin IP Mscara de Sub Red IP Gateway IP DHCP Enabled DHCP Server MAC Address Memory Address
SOFTWARE ADICIONAL USARIOS CON PERMISOS AL SERVIDOR RELACION CON OTROS SERVIDORES
2.1 2,047.49 MB 1.37 GB 3.86 GB 3.47 GB Ethernet 802.3 IBM Netfinity Fault Tolerante PCI Adapter PCNet5 10.203.32.9 255.255.255.0 10.203.32.254 No Not Available 00:06:29:D5:38:0F 0XFEB7FC00-0XFEB7FC1F
10. Vista de Datos

[Se debe describir la perspectiva persistente del almacenaje de datos del sistema. Deber incluir el Modelo de Datos Lgico y Fsico, as como el diccionario de datos.]
11. Tamao y Desempeo

[En esta seccin se pueden incluir descripciones de las principales caractersticas del dimensionamiento del software que afectan la arquitectura, as como las restricciones de desempeo. Si trabaj estas caractersticas en el RES haga referencia a dicho documento.]
CIBERTEC
136
Glosario
Abstraccin Caractersticas esenciales de una entidad que la distingue de otros tipos de entidades. Define una frontera desde la perspectiva del observador. API Una API representa una interfaz de comunicacin entre componentes de software. Se trata del conjunto de llamadas a ciertas bibliotecas que ofrecen acceso a ciertos servicios desde los procesos y representa un mtodo para conseguir abstraccin en la programacin, generalmente (aunque no necesariamente) entre los niveles o capas inferiores y los superiores del software. Blueprints En el contexto de arquitectura de sistemas de software, este trmino se refiere al conjunto de diagramas que tienen como objetivos representar las diferentes vistas del sistema. Artefacto Pieza discreta de informacin que es utilizada o producida por un proceso de desarrollo de software. Elemento Constituyente atmico de un modelo. Especificacin Descripcin textual de la sintaxis y la semntica de un bloque de construccin especfico; descripcin declarativa de lo que algo es o hace. Estereotipo Extensin del vocabulario de UML que permite crear nuevos bloques de construccin derivados a partir de los existentes pero especficos a un problema concreto. Estilo arquitectnico Los estilos arquitectnicos son una generalizacin y abstraccin de los patrones de diseo. Tambin puede definirse como la descripcin de los tipos componente y de los patrones de interaccin entre ellos. Framework En el desarrollo de software es una estructura de soporte definida en la cual otro proyecto de software puede ser organizado y desarrollado. Tpicamente, puede incluir soporte de programas, bibliotecas y un lenguaje interpretado entre otros softwares para ayudar a desarrollar y unir los diferentes componentes de un proyecto. Representa una arquitectura de software que modela las relaciones generales de las entidades del dominio. Provee una estructura y una metodologa de trabajo la cual extiende o utiliza las aplicaciones del dominio.
CIBERTEC
137
Heurstica Capacidad de un sistema para realizar de forma inmediata innovaciones positivas para sus fines. La capacidad heurstica es un rasgo caracterstico de los humanos, desde cuyo punto de vista puede describirse como el arte y la ciencia del descubrimiento y de la invencin o de resolver problemas mediante la creatividad y el pensamiento lateral o pensamiento divergente. Ingeniera de Software Rama de la ingeniera que aplica los principios de la ciencia de la computacin y las matemticas para lograr soluciones costo-efectivas a los proyectos de desarrollo o mantenimiento de software de calidad. Notacin Sistema de signos convencionales que se adoptan para expresar un conjunto de conceptos sobre el sistema de software por desarrollar. OMG Object Management Group Consorcio del cual forman parte las empresas ms importantes que se dedican al desarrollo de software. Refinamiento Relacin que representa una especificacin ms completa de algo que ya ha sido especificado a cierto nivel de detalle. Requisito Caracterstica, propiedad o comportamiento deseado de un sistema. RUP Rational Unified Process Proceso Unificado de Rational, metodologa del proceso de ingeniera de software que proporciona un enfoque disciplinado para asignar tareas y responsabilidades dentro de una organizacin del desarrollo. Sistema legado Aquel que es utilizado en un contexto distinto del que en principio fue concebido. La mayora de sistemas de informacin distribuidos se convierten en sistemas legados o heredados. En ingls es conocido como Legacy System. Stakeholder Persona, grupo u organizacin que tenga directa o indirecta participacin en una organizacin, ya que puede afectar o ser afectados por la organizacin de acciones, objetivos y polticas. Actores claves en una organizacin de negocios, incluyen los acreedores, clientes, directores, empleados, gobierno (y sus organismos), los propietarios (accionistas), los proveedores, los sindicatos y la comunidad en la que se basa el negocio de sus recursos. UML Unified Modeling Language Lenguaje Unificado de Modelado, notacin estndar para el modelado de sistemas Software. Vista Proyeccin de un modelo, que se ve desde una perspectiva o un punto de vista dado, y que omite entidades que no son relevantes desde esa perspectiva.
CIBERTEC

Análisis y Diseño de Sistemas II - Teoría sobre el Análisis Orientado a Objetos

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Análisis y Diseño de Sistemas II - Teoría sobre el Análisis Orientado a Objetos

Transféré par

Droits d'auteur :

Formats disponibles

Anlisis y Diseo de Sistemas II Teora

ANLISIS Y DISEO DE SISTEMAS II - TEORA

ANLISIS Y DISEO DE SISTEMAS II - TEORA

Anlisis y Diseo de Sistemas II

Anlisis Orientado a Objetos

Diseo Orientado a Objetos

Anlisis de casos de uso

Diseo de casos de uso

ANLISIS Y DISEO DE SISTEMAS II - TEORA

1. ANLISIS ORIENTADO A OBJETOS

ANLISIS Y DISEO DE SISTEMAS II - TEORA

1.1. Flujo de trabajo del AOO

Figura 1.2. Flujo de trabajo del AOO.

1.2. Artefactos del Anlisis

Realizacin de Caso de Uso

El diagrama de clases describe la estructura de un caso de uso.

Tabla 1.1. Artefactos del Anlisis.

ANLISIS Y DISEO DE SISTEMAS II - TEORA

Tabla 1.1. Artefactos del Anlisis (Continuacin).

1.3. Modelo de Anlisis

Cuadro 1.1. Comparacin del MCU Vs. MA

ANLISIS Y DISEO DE SISTEMAS II - TEORA

2.1. Pasos en el Anlisis de la arquitectura

ANLISIS Y DISEO DE SISTEMAS II - TEORA

Figura 1.5. Casos de uso con relacin incluye.

Figura 1.7. Capas y dependencias entre paquetes de anlisis.

ANLISIS Y DISEO DE SISTEMAS II - TEORA

ANLISIS Y DISEO DE SISTEMAS II - TEORA

3. ANLISIS DE CASOS DE USO

Anlisis de Casos de Uso

Figura 1.8. Anlisis de Casos de Uso.

3.1. Pasos en el Anlisis de casos de uso

ANLISIS Y DISEO DE SISTEMAS II - TEORA

Especificacin de Caso de Uso

ANLISIS Y DISEO DE SISTEMAS II - TEORA

Figura 1.12. Clases de interfaz (boundary).

Figura 1.13. Clases de control (control).

Figura 1.14. Clases de entidad (entity).

Figura 1.15. Diagrama de clases de anlisis.

ANLISIS Y DISEO DE SISTEMAS II - TEORA

Figura 1.16. Diagrama de comunicacin.

3.2. Caso prctico

Registrar Inscripcin en Cursos

1. Escenario : Registrar inscripcin en cursos Crear horario

ANLISIS Y DISEO DE SISTEMAS II - TEORA

6. Anlisis de los objetos filtrados en escenario

Cursos a ensear en un semestre

Un curso ofrecido en un lugar y horarios especficos

ANLISIS Y DISEO DE SISTEMAS II - TEORA

10. Candidatos a Clase Boundary en el escenario del CU

13. Clases Control en el CU Se aade una clase de control llamada CC_Inscripcion.

ANLISIS Y DISEO DE SISTEMAS II - TEORA

ESPECIFICACIN DE CASO DE USO: Mantener Competencias

ANLISIS Y DISEO DE SISTEMAS II - TEORA

4.1. Pasos a realizar

Identificacin de responsabilidades y atributos Identificacin de asociaciones y agregaciones Identificacin de generalizaciones

ANLISIS Y DISEO DE SISTEMAS II - TEORA

4.2. Tarjetas Clase Responsabilidad Colaboracin (CRC)

ANLISIS Y DISEO DE SISTEMAS II - TEORA

4.3. Caso prctico

Especificacin de Caso de uso: Pagar Prstamos de Terceros

7. Requisitos Especiales 1. Alta seguridad en el manejo de las claves y cuentas. 8. Prototipos -

(0..1) /1//(1..) (0..1) /1//(1..)

Siempre son (0..1) Obligatorias /1//(1..)