Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Manual de Teoria
Manual de Teoria
Computacin e Informtica
CARRERAS PROFESIONALES
CIBERTEC
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
CARRERAS PROFESIONALES
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
CARRERAS PROFESIONALES
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.
CARRERAS PROFESIONALES
CIBERTEC
RED DE CONTENIDOS
Modelo de datos
Anlisis OO
Modelo Conceptual
Diseo OO
Anlisis de la Arquitectura
Modelo Lgico
Arquitectura de Software
Modelo Fsico
Anlisis de clases
CARRERAS PROFESIONALES
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.
CARRERAS PROFESIONALES
CIBERTEC
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.
CARRERAS PROFESIONALES
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.
ANLISIS
CARRERAS PROFESIONALES
CIBERTEC
10
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
CARRERAS PROFESIONALES
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
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.
CARRERAS PROFESIONALES
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.
CARRERAS PROFESIONALES
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.
CARRERAS PROFESIONALES
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.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.
CARRERAS PROFESIONALES
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>>
CARRERAS PROFESIONALES
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.
CARRERAS PROFESIONALES
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.
CARRERAS PROFESIONALES
CIBERTEC
18
ACTIVIDADES PROPUESTAS
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
CARRERAS PROFESIONALES
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).
CARRERAS PROFESIONALES
CIBERTEC
20
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.
CARRERAS PROFESIONALES
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.
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.
CARRERAS PROFESIONALES
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.
CARRERAS PROFESIONALES
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:
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.
CARRERAS PROFESIONALES
CIBERTEC
24
3.1.3. Crear el diagrama de clases Este paso permite representar las clases participantes y sus relaciones para un determinado caso de uso.
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.
CARRERAS PROFESIONALES
CIBERTEC
25
CARRERAS PROFESIONALES
CIBERTEC
26
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.
CARRERAS PROFESIONALES
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
CARRERAS PROFESIONALES
CIBERTEC
28
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
Secciones de cursos escogidas para un semestre por un estudiante Estudiantes inscritos en una seccin de curso ofrecido
CARRERAS PROFESIONALES
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.
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.
CARRERAS PROFESIONALES
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.
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
CARRERAS PROFESIONALES
CIBERTEC
31
ACTIVIDADES PROPUESTAS
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
CARRERAS PROFESIONALES
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 -
CARRERAS PROFESIONALES
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.
CARRERAS PROFESIONALES
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.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.
CARRERAS PROFESIONALES
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.
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.
CARRERAS PROFESIONALES
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.
CARRERAS PROFESIONALES
CIBERTEC
37
CARRERAS PROFESIONALES
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.
CARRERAS PROFESIONALES
CIBERTEC
PASO 3: Realizar el diagrama de comunicacin del flujo bsico y del flujo alternativo Flujo Bsico
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
CARRERAS PROFESIONALES
41
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: Transaccion Responsabilidad 1. Obtener mximo nmero de transaccin 2. Guardar datos Colaboradores CC_Prestamo
CIBERTEC
CARRERAS PROFESIONALES
42
ACTIVIDADES PROPUESTAS
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
CIBERTEC
CARRERAS PROFESIONALES
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
CARRERAS PROFESIONALES
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
CARRERAS PROFESIONALES
45
UNIDAD DE APRENDIZAJE
MODELO DE DATOS
LOGRO DE LA UNIDAD DE APRENDIZAJE
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
ACTIVIDADES PROPUESTAS
1. Los alumnos desarrollan el modelo conceptual de un caso propuesto. 2. Los alumnos desarrollan el modelo fsico de un caso propuesto.
CIBERTEC
CARRERAS PROFESIONALES
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.
CIBERTEC
CARRERAS PROFESIONALES
47
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
CARRERAS PROFESIONALES
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
CIBERTEC
CARRERAS PROFESIONALES
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
Recepcionista
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
CIBERTEC
CARRERAS PROFESIONALES
50
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
CARRERAS PROFESIONALES
51
Item
*
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
CIBERTEC
CARRERAS PROFESIONALES
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.
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:
CIBERTEC
CARRERAS PROFESIONALES
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.
CIBERTEC
CARRERAS PROFESIONALES
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:
CIBERTEC
CARRERAS PROFESIONALES
55
CIBERTEC
CARRERAS PROFESIONALES
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
CARRERAS PROFESIONALES
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
CARRERAS PROFESIONALES
58
ACTIVIDADES PROPUESTAS
1. A partir de la Especificacin del Caso de Uso Reservar pistas de juego, de la sesin anterior, confeccione el Modelo Conceptual.
CIBERTEC
CARRERAS PROFESIONALES
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.
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
CARRERAS PROFESIONALES
60
Entidad Padre
Entidad Hija
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
CIBERTEC
CARRERAS PROFESIONALES
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
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
Obligatoria
Composicin
(0..1) /1
(0..1) /1/*/(1..*)
Identificada
Tabla 2.3. Correlaciones entre asociaciones UML y relaciones de modelo lgico de datos en IDA.
CIBERTEC
CARRERAS PROFESIONALES
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
CARRERAS PROFESIONALES
63
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.
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:
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
Oracle
www.oracle.com
CIBERTEC
CARRERAS PROFESIONALES
64
Logo
Nombre
URL
Productos
Microsoft
www.microsoft.com
MySQL
www.mysql.com
MySQL
Informix
www.informix.com
IBM
www.ibm.com
Apache
http://db.apache.org/derby
Derby
SQLite
http://www.sqlite.org
SQLite
Firebird http://firebird.sourceforge.net
Firebird
CIBERTEC
CARRERAS PROFESIONALES
65
CIBERTEC
CARRERAS PROFESIONALES
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
CARRERAS PROFESIONALES
67
ACTIVIDADES PROPUESTAS
1. A partir de la Especificacin del Caso de Uso Reservar pistas de juego, de la sesin anterior, confeccione el Modelo Fsico.
CIBERTEC
CARRERAS PROFESIONALES
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
CARRERAS PROFESIONALES
69
UNIDAD DE APRENDIZAJE
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
ACTIVIDADES PROPUESTAS
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
CARRERAS PROFESIONALES
70
DISEO
CIBERTEC
CARRERAS PROFESIONALES
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
Diagrama de Clases
Diagramas de Secuencia
CIBERTEC
CARRERAS PROFESIONALES
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
CIBERTEC
CARRERAS PROFESIONALES
73
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.
CIBERTEC
CARRERAS PROFESIONALES
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
CARRERAS PROFESIONALES
75
CIBERTEC
CARRERAS PROFESIONALES
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.
CIBERTEC
CARRERAS PROFESIONALES
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.
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
CARRERAS PROFESIONALES
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
CARRERAS PROFESIONALES
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
CARRERAS PROFESIONALES
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
CARRERAS PROFESIONALES
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
CARRERAS PROFESIONALES
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
CARRERAS PROFESIONALES
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
CARRERAS PROFESIONALES
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
CARRERAS PROFESIONALES
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
CARRERAS PROFESIONALES
86
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
CARRERAS PROFESIONALES
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
CARRERAS PROFESIONALES
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
CARRERAS PROFESIONALES
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
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
CARRERAS PROFESIONALES
90
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
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
CARRERAS PROFESIONALES
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.
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.
Service Activator
CIBERTEC
CARRERAS PROFESIONALES
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
CARRERAS PROFESIONALES
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.
CIBERTEC
CARRERAS PROFESIONALES
94
1.1.2.
Diagrama de Componentes
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.
CIBERTEC
CARRERAS PROFESIONALES
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.
Clases de diseo: clases utilitarias. Tabla 3.2. Capas, subsistemas, libreras y elementos de diseo.
CIBERTEC
CARRERAS PROFESIONALES
96
A partir de la Especificacin del Caso de Uso Mantener Cajeros crearemos los diagramas de la realizacin de diseo del caso de uso.
CIBERTEC
CARRERAS PROFESIONALES
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
CARRERAS PROFESIONALES
98
A continuacin se muestra los diagramas de la realizacin de diseo de caso de uso. 1) Realizacin de diseo
2)
CIBERTEC
CARRERAS PROFESIONALES
99
3)
Diagramas de Secuencia
CIBERTEC CIBERTEC
CARRERAS PROFESIONALES
100
ACTIVIDADES PROPUESTAS
Elabore el diagrama de secuencia para los subflujos agregar, actualizar y desactivar cajeros del caso de uso Mantener Cajeros.
CIBERTEC CIBERTEC
CARRERAS PROFESIONALES
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.
CIBERTEC
CARRERAS PROFESIONALES
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
CARRERAS PROFESIONALES
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. 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
CARRERAS PROFESIONALES
104
CIBERTEC CIBERTEC
CARRERAS PROFESIONALES
105
3. Diagrama de secuencia
CIBERTEC
CARRERAS PROFESIONALES
106
ACTIVIDADES PROPUESTAS
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
CARRERAS PROFESIONALES
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
CARRERAS PROFESIONALES
108
CIBERTEC
CARRERAS PROFESIONALES
109
ANEXO
PLANTILLAS REQUISITOS
CONTENIDO
DE
DOCUMENTOS
DE LA
GESTIN
DE
CIBERTEC
CARRERAS PROFESIONALES
110
Elaborado por:
Revisado por:
Aprobado por:
Fecha:
Fecha:
Fecha:
CIBERTEC CIBERTEC
CARRERAS PROFESIONALES
111
HISTORIAL DE REVISIONES
Versin Autor Descripcin Fecha de Elaboracin Fecha de Revisin Revisado por <Persona(s) que revisa(n) el documento>
<x.x>
CIBERTEC
CARRERAS PROFESIONALES
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
CARRERAS PROFESIONALES
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.
3.2.
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.
Descripcin
[Descripcin del flujo de trabajo del CUN01.] [Descripcin del flujo de trabajo del CUN02.]
CIBERTEC
CARRERAS PROFESIONALES
114
4.2.
4.3.
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
CARRERAS PROFESIONALES
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
CIBERTEC
CARRERAS PROFESIONALES
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
CARRERAS PROFESIONALES
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.
7.1.
Descripcin
CIBERTEC
CARRERAS PROFESIONALES
118
7.2.
7.3.
7.4.
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.
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
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
CARRERAS PROFESIONALES
119
Ciclo de desarrollo
Ciclo 0 Ciclo 1
Ncleo central o CUS01 Nombre del caso de uso CUS02 Nombre del caso de uso CUS03 Nombre del caso de uso
7.7.
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.
Caso de uso:
Actor(es): Propsito: Caso de asociado: Resumen:
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
CARRERAS PROFESIONALES
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
CARRERAS PROFESIONALES
121
8.
Ver Agenda
Encargar Accin
Agenda
Ver Acciones
Ver Alarmas
Accin Propia
APLICACION
Clientes
Consultar Parmetros
Tablas
Resultados
Acciones Enviadas
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.]
Perfil 1 x
Perfil 2 x
...
Perfil N x
CIBERTEC
CARRERAS PROFESIONALES
122
CIBERTEC CIBERTEC
CARRERAS PROFESIONALES
123
[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
CARRERAS PROFESIONALES
124
HISTORIAL DE REVISIONES
Versin
Autor
Descripcin
Fecha de Elaboracin
Fecha de Revisin
<x.x>
CIBERTEC
CARRERAS PROFESIONALES
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
CARRERAS PROFESIONALES
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 [Indique cada una de las definiciones que son relevantes para el entendimiento del presente documento. Cada definicin deber ir acompaada de una breve descripcin.]
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.
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
CARRERAS PROFESIONALES
127
Acrnimo SIGA
1.4.
Referencias [Mencione los documentos que sirven como entrada, o salida, y herramientas que se usarn para el desarrollo del presente documento.]
Web SGSS
Capa de Presentacin
Capa Cliente
Capa de Aplicacin
Base de Datos 1
Base de Datos 2
Base de Datos N
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
CARRERAS PROFESIONALES
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.
4.
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
CARRERAS PROFESIONALES
129
5.1.
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
CARRERAS PROFESIONALES
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.]
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.]
CIBERTEC
CARRERAS PROFESIONALES
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
Servidor COM+
Servidor BD
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.
CIBERTEC
CARRERAS PROFESIONALES
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.
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
CARRERAS PROFESIONALES
133
9.1.
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
CARRERAS PROFESIONALES
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.
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
CARRERAS PROFESIONALES
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
CIBERTEC
CARRERAS PROFESIONALES
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
CARRERAS PROFESIONALES
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
CARRERAS PROFESIONALES