Curso Adoo Uml

ESPECIALIZACIN EN TECNOLOGAS AVANZADAS PARA EL DESARROLLO DE SOFTWARE
ANALISIS Y DISEO ORIENTADO A OBJETOS UNIFIED MODELING LANGUAGE (UML)
Ing. Sandra Johanna Moreno Valero (Este material es reproducido con fines educativos)
Mayo de 2006
1. INTRODUCCION Anlisis y diseo es el primer paso en el desarrollo de un sistema de software. Anlisis es el proceso de obtener los requerimientos del software y organizarlos en formatos estndares que pueden ser pasados al diseo por ingenieros desarrolladores. Los clientes, administradores y usuarios finales hablan un lenguaje diferente a los ingenieros del software. El anlisis es el puente entre quienes utilizaran el software y quienes los desarrollarn. En el contexto del desarrollo de software, la fase de anlisis se enfoca en los siguientes tems: Establecer una vista clara del problema del negocio Hacer un bosquejo de las tareas que el sistema debe ejecutar Desarrollar un vocabulario comn para el problema del negocio Hacer un bosquejo de la mejor solucin para el problema del negocio El diseo es el proceso de pasar los resultados del anlisis en un borrador para el sistema en desarrollo. El diseo muestra suficientes detalles que le permiten a un grupo diverso de administradores y programadores desarrollar el sistema. En el contexto del desarrollo de software, la fase de diseo se enfoca en los siguientes tems: Resolver el problema del negocio Definir cmo en lugar de qu Introducir elementos de soporte que harn que el sistema trabaje Definir una estrategia de implementacin del sistema Sin embargo, no existe una divisin clara entre anlisis y diseo en el proceso de desarrollo de un sistema de informacin En los aos 70s las metodologas de anlisis y diseo de sistemas se hicieron ms formales y provean una manera estndar de hacer un sistema de informacin en papel antes de iniciar el desarrollo. Estos mtodos se centraban en el flujo de informacin dentro de fuera de subsistemas funcionales.
Orden
Despachar orden
Base de datos de inventarios
Inventario
Ordenar inventario
Orden de compra
Proveedor
Cliente
Orden
Orden
Tomar orden
Base de datos de rdenes Ordenes
Despachar orden
Reporte
Administrador
Orden
Figura 1-1: Ejemplo de diagrama de flujo de datos El flujo de datos est representado por las flechas comenzando del origen (como un cliente) pasando por el proceso (como poner una orden o generar un reporte) y terminando en la informacin de los clientes (como la administracin). Descomponiendo el sistema de esta manera, los subsistemas funcionales pueden ser desarrollados individualmente. La mayora de los principios desarrollados en estos tempranos modelos de anlisis y diseo desembocaron en las modernas metodologas de anlisis y diseo orientado a objetos. 1.1. ANLISIS Y DISEO ORIENTADO A OBJETOS Los modelos estructurados centran su atencin en el flujo de informacin a travs del manejo de datos y funciones. Anlisis y diseo permite a los diseadores y desarrolladores visualizar el software como un conjunto de funciones atmicas la cual cada una de ellas realizan una tarea especfica. Esto permite un desarrollo ms rpido, menos errores de cdigo y reduce los riesgos del proyecto. Sin embargo, debido a que los computadores cada vez son ms veloces, pequeos y baratos, se ha demandado el desarrollo de sistemas de informacin ms complicados y menos centralizados los cuales estn distribuidos sobre mltiples sistemas computacionales, sistemas operativos y ubicacin geogrfica. Los mtodos orientados a objetos intentan satisfacer estas demandas. El componente fundamental del modelo estructurado es la funcin. Los datos son generados fuera del sistema y fluyen a travs de un conjunto de funciones antes de ser almacenados o
procesados. En un modelo orientado a objetos, los datos se convierten en el componente fundamental en forma de objetos. Examine el flujo de datos de la figura anterior. Un cliente coloca una orden, su informacin es pasada a las funciones Tomar Orden y Despachar Orden. En un modelo orientado a objetos, la informacin de la orden podra ser identificada como un objeto. Un objeto mantiene propiedades acerca de su estado. Por ejemplo, el objeto orden podra mantener una lista de tems ordenados, una direccin de envo y un mtodo cuenta. Pero de qu manera es un objeto diferente de los datos en un programa estructurado?. En un programa estructurado, los datos son pasados a travs de funciones que operan en ellos. En un programa orientado a objetos, se envan mensajes a los objetos para que ellos decidan cmo operan sobre ellos mismos. La figura 2, ilustra un objeto orden con propiedades definidas dentro de l. En lugar de pasar el objeto orden a travs de una funcin, el objeto orden es enviado al mensaje Despachar Orden y la orden se enva ella misma.
Despachar Orden
Orden tems Direccin de envo Mtodo de pago
Figura 1-2: Objeto Orden
1.2. METODOLOGA DE ANLISIS Y DISEO ORIENTADO A OBJETOS Una metodologa de anlisis y diseo orientado a objetos es un proceso que contiene una notacin para la definicin del software, basado en el concepto de objetos que combinan la estructura y el comportamiento en una entidad simple. Este proceso no es necesariamente lineal sino predecible, repetible, es posible probarlo y hacerle seguimiento. La notacin de OOA&D es una definicin visual que permite compartir el conocimiento acerca del sistema disminuyendo ambigedades. La metodologa OOA&D consiste de tres partes: Un proceso o secuencia de actividades relacionadas y entregables que son utilizadas para modelar y construir el software.
Una notacin o representacin, generalmente grfica, de los susbsistemas que forman el sistema y la descripcin de cmo interactan. Un conjunto de reglas que describen cmo funciona el sistema. 1.3. CRISIS DEL SOFTWARE Anlisis y diseo tiene varios propsitos. Esto permite a los desarrolladores enfocarse en las dificultades tcnicas, ayuda a asegurar que las entregas cumplan las expectativas del usuario y lo ms importante minimiza el riesgo. Cuando el desarrollo de un producto es demorado se dice que existe crisis del software y los eventos que llevaron a buscar soluciones a esto fueron: En marzo de 1989, Arthur Andersen report: o Ms de $ 300 billones por ao son gastados en las actividades de mejoramiento de software comercial en los Estados Unidos. o Slo el 8% del software que es entregado trabaja sin ningn cambio. El aeropuerto computarizado de Denver tuvo prdidas millonarias debido al retraso en la apertura del mismo a causa del software. 1.4. VENTAJAS DE LA TECNOLOGA DE OBJETOS Un paradigma simple El modelo refleja el mundo real Mantenible: La programacin orientada a objetos hacen el cdigo mantenible, porque es ms fcil identificar el origen de los errores ya que se encuentran dentro de los mismos objetos. Reusable: Porque los objetos contienen datos y funciones que actan sobre datos, los objetos pueden ser como cajas negras. Esta caracterstica hace fcil la reutilizacin de cdigo en nuevos sistemas. Los mensajes proveen una interfaz predefinida de los datos y funcionalidad de un objeto. Escalable: Los programas orientados a objetos son ms escalables. Como una interfaz de un objeto provee una ruta para la reutilizacin del objeto en una aplicacin nueva, tambin provee toda la informacin necesaria para reemplazar el objeto sin afectar otro cdigo. 1.5. DESVENTAJAS DE LA ORIENTACIN A OBJETOS Existen pocos retos en esta transicin de la ingeniera del software a la tecnologa orientada a objetos. Varios sistemas empresariales fueron construidos bajo el paradigma estructural. Lograr interfaces con estos sistemas no provee retos tcnicos sino retos de diseo. La meta es minimizar los efectos de los sistemas estructurales sobre los nuevos diseos orientados a objetos. La capacitacin hacia estas nuevas tecnologas podra ser una desventaja porque la programacin orientada a objetos ha existido desde finales de los 80s, sin embargo, sus principios aparecieron en el mbito educativo slo hasta 1995.
1.6. CARACTERSTICAS PRINCIPALES DE LA PROGRAMACIN ORIENTADA A OBJETOS
1.6.1. Abstraccin Se refiere al concepto de ignorar los detalles y concentrarse en las caractersticas esenciales de un objeto o entidad. La abstraccin simplifica la funcionalidad y la informacin y ayuda a los usuarios interactuar con el objeto. El proceso de desarrollar clases en trminos de sus interfaces y funcionalidad, en lugar de los detalles de implementacin, es llamado abstraccin. La abstraccin es utilizada para manejar la complejidad. Los ingenieros del software utilizan la abstraccin para descomponer sistemas complejos en componentes ms pequeos. 1.6.2. Encapsulacin La encapsulacin oculta los datos dentro de un objeto. Por ejemplo, el funcionamiento interno de un telfono est oculto para el usuario o est encapsulado. Los botones del telfono proveen la interfaz para que el usuario opere el telfono.
La encapsulacin produce dos vistas de cada objeto: Vista externa, la cual muestra lo que el objeto hace Vista interna, la cual muestra cmo el objeto ejecuta sus tareas La ventaja de la encapsulacin es que la clase puede cambiar. Si los cambios se reflejan slo en la implementacin oculta, y si la nueva interfaz es compatible con la original, los programas que utilizan dicha clase, no se ven afectados. 1.6.3. Asociacin La asociacin es la forma en que los objetos interactan. Los objetos son asociados cuando un objeto utiliza los servicios u operaciones de otro objeto. Por ejemplo, dos objetos independientes pueden decidir colaborar para alcanzar cierto objetivo. Despus que el objetivo es alcanzado, ellos continan existiendo independientemente uno del otro. 1.6.4. Agregacin La agregacin define un objeto en trminos de las partes que lo componen. Por ejemplo, un carro tiene un motor, llantas, sillas, etc. Si falta alguna de ellas, el carro no funciona adecuadamente. El carro es definido por sus partes, o el carro tiene una relacin de agregacin con sus partes. Esta clase de relacin tiene un es llamada agregacin. La agregacin es un tipo de asociacin. 1.6.5. Composicin La composicin se da cuando un objeto es contenido dentro de otro. La composicin se caracteriza por una relacin de contencin. Por ejemplo, un lpiz est compuesto por
una mina en la punta y un objeto de madera en forma de tubo. Sin la mina, el lpiz no ejecutara su funcin correctamente. En varias ocasiones, los objetos no pueden existir independientemente de otro. En este caso, la composicin es la relacin ms adecuada. 1.6.6. Herencia La herencia es un mecanismo que define una clase nueva en trminos de otra existente. Esto permite agrupar clases relacionadas, por lo tanto, pueden ser usadas y manejadas colectivamente. La herencia se identifica por las frases Es un o Es una clase de. 1.6.7. Cohesin y Acoplamiento Cohesin es una medida del soporte que una entidad brinda en el mismo propsito dentro del sistema. Acoplamiento es una medida de dependencia entre entidades. El acoplamiento es tambin una medida de dependencia entre objetos. Los objetos pueden ser clases, sistemas, subsistemas, aplicaciones, grupos de clases u objetos individuales. 1.6.8. Polimorfismo Polimorfismo es el concepto de definicin operaciones similares para ms de una clase. Una funcin es descrita como polimrfica si es posible aplicarla a objetos de diferentes clases para alcanzar el mismo resultado semntico. El concepto de polimorfismo est basado en la herencia. El polimorfismo soporta la reutilizacin y el mantenimiento. La implementacin de una funcin polimrfica depende del objeto en el cual se aplica. Algunas clases definen objetos similares y tienen mtodos iguales. Por ejemplo, si se tiene una pelota de ftbol americano y otra de tenis, estas dos son similares y es posible definir la operacin lanzar. La implementacin de la operacin es diferente. Una pelota de ftbol americano se lanza con las dos manos y una de tenis se lanza al aire con una mano para servir. Cuando se crea una nueva pelota, no es necesaria la instruccin para la utilizacin del mtodo. La hija reconoce la clase de pelota y aplica el mtodo genrico lanzar. El polimorfismo funciona slo cuando la operacin comn es semnticamente similar.
2. UNIFIED MODELING LANGUAGE (UML) Lenguaje escrito por Grady Booch, Jim Rumbaugh e Ivar Jacobson, y desde noviembre de 1997 es un estndar y pertenece a la OMG (Object Management Group). UML es un lenguaje grfico para especificar, construir, visualizar y documentar los artefactos o productos entregables de un sistema de software. UML utiliza un lenguaje de notacin grfica para representar los artefactos que hacen parte del OOA&D. UML brinda la sintaxis para describir la estructura de clases, componentes, programas y sistemas de software as como tambin describe la interaccin entre estos tems. Es importante recordar que UML no define un proceso, slo se puede utilizar UML cuando se tiene un proceso clara para OOA&D. El proceso OOA&D es una aplicacin o un problema independiente. A pesar que el proceso unificado (Unified Process) est altamente relacionado con UML, UML fue desarrollado en forma separada de este proceso y est diseado para ser utilizado con cualquier proceso de desarrollo iterativo de software. UML maneja diagramas que permiten tener un modelo mental del sistema de software. Estos diagramas son usados para construir varios artefactos en el flujo de trabajo y son los siguientes: o o o o o o o o o o Diagrama de casos de uso que representan el comportamiento del sistema con un actor dado. Diagrama de clases que representa una coleccin de clases de software y sus relaciones. Diagrama de objetos que representa una toma de los objetos de software y sus relaciones en el momento de ejecucin. Diagrama de colaboracin, representa una coleccin de objetos que trabajan en conjunto para soportar el comportamiento del sistema. Diagrama de secuencia que representa una perspectiva de la colaboracin de los objetos durante un periodo de tiempo. Diagrama de actividades que representa un flujo de actividades que pueden ejecutarse por el sistema o por un actor. Diagrama de transicin de estados que representa el conjunto de estados que un objeto puede experimentar y las transiciones que sufre de un estado a otro. Diagrama de componentes que representa una coleccin de componentes de software y sus relaciones. Diagrama de distribucin que representa una coleccin de componentes y muestra cmo se distribuyen a travs de uno o ms computadores. Diagrama de paquetes que representa una coleccin de otros elementos y diagramas modelados.
Los diagramas de UML crean diferentes vistas del sistema. Una vista de comportamiento compuesta por el diagrama de casos de uso y presenta lo que se requiere del sistema; una vista estructural que muestra cmo est estructurado el sistema para satisfacer los requerimientos y est compuesto por los diagramas de paquetes, de componentes, de clases, de objetos y de distribucin; y una vista dinmica que muestra cmo el sistema interacta para satisfacer los requerimientos y est compuesta por los diagrama de secuencia, de colaboracin de transicin de estados y de actividades.
Fuente: Object-Oriented Analysis and Design using UML. Student guide with instructor notes. Sun Microsystems 2003. Revision C.
Figura 2-1. Vistas de los diagramas de UML. Es posible ver la vista dinmica desde dos niveles: el ciclo de vida de un objeto desde que se crea hasta que se libera, y la interaccin de los objetos con el sistema, tal es el caso del diagrama de estados de UML que describe un objeto y los diagramas de secuencia y colaboracin que describen la interaccin entre objetos. Existen otros elementos importantes dentro de UML como lo son la notacin para los paquetes, y los mecanismos de extensin como las notas, estereotipos, y reglas.
3. PROCESO UNIFICADO DE DESARROLLO 3.1. PROCESO DE DESARROLLO TRADICIONAL El mtodo de Cascada es el proceso de desarrollo de software ms popular.
Requerimientos
Tiempo
Anlisis Diseo Implementacin Pruebas
Figura 3-1: Metodologa de cascada para el desarrollo de software En el mtodo de cascada, el proceso de desarrollo es completado en una direccin a travs de las fases requerimientos, anlisis, diseo, implementacin y pruebas. Cada fase debe ser completada y documentada antes de pasar a la siguiente fase. Si se encuentra un problema en una fase posterior, es difcil devolverse a una fase anterior. Los proyectos que siguen este proceso toman mucho tiempo y esfuerzo en asegurar que cada fase sea correcta. Para maximizar los beneficios de UML, es necesario utilizar un proceso de anlisis y diseo orientado a objetos. 3.2. PROCESO UNIFICADO DE DESARROLLO A continuacin se describe una metodologa basada en el proceso unificado de desarrollo de software, desarrollado por Ivar Jacobson, Grady Booch y Jame Rumbaugh. El proceso unificado de desarrollo de software es conducido por los casos de uso, centrado en la arquitectura e Iterativo e Incremental.
Conducido por los casos de uso: Un caso de uso es la manera en la cual el usuario interacta con el sistema. Los casos de uso son el centro del proceso unificado. Ellos funcionan como requerimientos del sistema de software. El modelo de casos de uso representa la interfaz entre la funcionalidad del sistema y los usuarios del mismo. Cada caso de uso sirve como un requerimiento que pasa a travs del proceso de diseo, implementacin y pruebas. Centrado en la arquitectura: El proceso unificado presta gran atencin en la arquitectura de un sistema de software. Ningn software existe en el vaco. Por ejemplo, en un sistema de biblioteca que opera sobre un servidor UNIX y utiliza un paquete particular de base de datos. Tambin es posible acceder a datos de un mainframe. Los usuarios acceden al sistema desde computadores con Windows localizados dentro de la biblioteca. Los empleados de la biblioteca utilizan hardware especial para automatizar el proceso de prstamo de libros. Los usuarios remotos acceden al sistema con una interfaz web y un applet de Java. Todas estas opciones de software componen la arquitectura del sistema de biblioteca. Debido a que los computadores han llegado a ser ms poderosos y omnipresentes, el software ha incrementado la complejidad y han llegado a ser ms distribuidos. Por lo tanto, la arquitectura del sistema es bastante importante y requiere una atencin especial. El proceso unificado hace de la arquitectura una parte integral del desarrollo de software. Iterativo e incremental: El proceso unificado divide un proyecto de desarrollo en una serie de iteraciones. Una iteracin es un ciclo de desarrollo que termina con la entrega de un subconjunto del producto final. Cada iteracin tiene todos los aspectos del desarrollo de software. Cada entrega iterativa es una pieza totalmente documentada al final del sistema. Esta caracterstica presenta los siguientes beneficios: Reduccin del riesgo basado en la temprana realimentacin Mayor flexibilidad de acomodar nuevos requerimientos Reduccin de costos Incrementar la calidad del software En cada iteracin se deben realizar los siguientes pasos: Seleccionar y analizar los casos de uso relevantes Crear un diseo utilizando la arquitectura seleccionada Implementar el diseo en componentes Verificar que los componentes satisfacen los casos de uso Cuando se consigue la meta en una iteracin, se procede a la siguiente iteracin. El proceso est compuesto por fases, las cuales se componen de flujos de trabajos (workflow), estos se componen de actividades especficas, las cuales involucran trabajadores y artefactos. Un trabajador es una persona que ejecuta una actividad. Un artefacto es una pieza tangible de informacin que es producida por una actividad; por ejemplo, diagramas, documentos y el cdigo de software.
Figura 3-2: Pirmide del desarrollo de software orientado a objetos 3.3. FASES DEL PROCESO UNIFICADO El proceso unificado se compone de las fases de inicio, elaboracin, construccin y transicin y no sigue actividades especficas como lo hacan modelos anteriores. Todas las actividades de desarrollo desde los requerimientos hasta las pruebas, se realizan durante cada fase. Por lo tanto, cada incremento del software consiste de cinco flujos de trabajo: Requerimientos y anlisis inicial Anlisis Diseo Implementacin Pruebas
Figura 3-3: Fases del Ciclo de Desarrollo
3.3.1. Fase de Inicio Los propsitos de la fase de inicio son: Comenzar el proyecto Establecer una fundamentacin para el proyecto Determinar el alcance del proyecto Crea un problema de negocio Identificar los riesgos crticos Definir el alcance del proyecto para entender el problema Crear documentos que expliquen el problema del negocio Preparar el ambiente para el proyecto Los productos entregables en esta fase son: Principales requerimientos del proyecto (funcionales y no funcionales) Una visin del producto Estimacin inicial de riegos Glosario Opcionales: Un prototipo conceptual 3.3.2. Fase de Elaboracin Los propsitos de la fase de elaboracin son: Crear un modelo de anlisis y diseo de alto nivel Establecer una arquitectura de base para el proyecto Analizar el dominio del problema
Monitorear los riesgos crticos del proyecto Desarrollar un plan que presente cmo ser terminado el proyecto. Los productos entregables en esta fase son: Modelo del comportamiento del sistema Una arquitectura a seguir Un plan de desarrollo Plan de iteraciones con entregas descritas Unos criterios de evaluacin 3.3.3. Fase de Construccin El propsito de la fase de construccin es: Desarrollar incrementalmente el producto software. Administrar recursos, controlarlos y optimizarlos Los productos entregables de esta fase son: Entregas ejecutables Prototipos de comportamiento Resultados de calidad Documentacin del sistema y del usuario Plan de distribucin Criterios de evaluacin para la siguiente iteracin 3.3.4. Fase de Transicin Los propsitos de la fase de transicin son: Presentacin del producto al cliente Completar la capacitacin de usuarios y pruebas Validar el sistema con las expectativas del usuario Los productos entregables en esta fase son: Producto terminado Anlisis del proyecto Documentacin de pruebas
4. DESARROLLO DE UN SISTEMA DE SOFTWARE 4.1. CAPTURA DE REQUERIMIENTOS Es posible obtener informacin de diferentes fuentes, dentro de las cuales encontramos: Especificacin inicial de requerimientos por parte del cliente Expertos del dominio Clientes y usuarios Administradores Proyectos anteriores Documentacin sobre polticas y procedimientos
Figura 4-1: Mapa del proceso Captura de Requerimientos
Existen dos tipos de requerimientos a ser capturados, los requerimientos funcionales y los no funcionales. Los requerimientos funcionales especifican las tareas que el sistema ejecutar. En la mayora de los casos, los requerimientos funcionales describen la forma en la cual el sistema reaccionar con las entradas del usuario. Los requerimientos funcionales (FR) tambin incluyen la interfaz del usuario, la cual debe ser descrita en papel o es posible construir un prototipo para ayudar a los usuarios a entender la manera como ellos interactuarn con el sistema. Los requerimientos no funcionales (NFR) son propiedades del sistema, como rendimiento, utilizacin de memoria, confiabilidad, flexibilidad, entre otros. En muchos casos, los requerimientos no funcionales aplican a un conjunto especfico de casos de uso. Rendimiento se refiere a la habilidad de procesar operaciones de un usuario dentro de los rangos de tiempos deseados. Escalabilidad se refiere a la habilidad de crecer a travs del tiempo y est relacionada con el rendimiento. Usabilidad se refiere a la forma de interaccin del usuario con el sistema, comnmente su valor debe ser fcil de usar. Seguridad es la habilidad de controlar el acceso a los servicios y la informacin de un sistema, como tambin de detectar, aislar y recuperar informacin en caso de fallas. Despus de la captura de requerimientos es conveniente generar un documento que describa claramente los clientes y los requerimientos del sistema para el proyecto (SRS: System Requirements Specification). Este documento en donde se declara el problema debe especificar lo siguiente: Toda la informacin que es pertinente para el anlisis y diseo del proyecto Cualquier regla o restriccin que debe considerarse en el desarrollo del proyecto Los usuarios que utilizarn el sistema Las entradas y salidas del sistema 4.1.1. Diagramas de Casos de Uso El principal medio de captura de requerimientos en el proceso unificado es el diagrama de casos de uso, el cual ilustra las relaciones entre un sistema software y sus usuarios. Estos diagramas describen todas las formas en las cuales un usuario interacta con el sistema. El conjunto de los diagramas de casos de uso y sus descripciones constituye el modelo de casos de uso. Este modelo es uno de los principales entregables del flujo de trabajo de requerimientos. El diagrama de casos de uso provee una representacin visual de los requerimientos funcionales del sistema.
4.1.1.1. Actores Los usuarios de un sistema de software estn representados como actores en un diagrama de casos de uso. Los actores se utilizan para representar usuarios especficos, grupos de usuarios, usuarios organizacionales e incluso sistemas de software externos. Un actor se representa como la figura mostrada a continuacin.
Estudiante
Figura 4-2: Ejemplo de un actor Mltiples usuarios pueden asumir el rol de un actor. Por ejemplo, todos los estudiantes asumirn el rol del actor estudiante. 4.1.1.2. Casos de Uso Los actores mantienen relaciones con los casos de uso. Un caso de uso es la descripcin de alguna actividad del software que un actor debe iniciar; tambin se puede describir como la especificacin de una secuencia de acciones que el sistema debe ejecutar. Un caso de uso se representa por un ovalo con una etiqueta que identifica el caso de uso.
Matricular
Figura 4-3: Ejemplo de un caso de uso A continuacin se presentan algunas preguntas tiles para encontrar casos de uso en un sistema de software: Qu tareas realiza el actor? El actor crea, almacena, cambia, elimina o lee informacin del sistema? Qu casos de uso crearn, almacenarn, cambiarn, leern esta informacin? El actor necesita informarle al sistema sobre cambios externos? El actor necesita ser informado acerca de ocurrencias en el sistema? Qu casos de uso darn soporte y mantenimiento al sistema? El origen de la informacin para los casos de uso se encuentra en: Especificacin del sistema Literatura correspondiente al dominio
Entrevistas con los expertos del dominio Conocimiento personal del dominio Sistemas anteriores
Ejemplo: Sistema Acadmico
Al comenzar cada semestre, los estudiantes requieren un catlogo que contiene la lista de los cursos ofrecidos para cada semestre. La informacin de cada curso, como el profesor, facultad y prerequisitos sern incluidos para ayudar a los estudiantes en la toma de decisiones. El nuevo sistema le permitir a los estudiantes seleccionar cuatro cursos para el semestre entrante. Adems, cada estudiante indicar dos alternativas en caso de que un curso ofrecido se llene o sea cancelado. Ningn curso ofrecido tendr ms de 10 estudiantes, ni menos de 3 estudiantes. Un curso con menos de 3 estudiantes ser cancelado. Una vez el proceso de matrcula es completado por el estudiante, el sistema de matrcula enva la informacin al sistema financiero. Los profesores deben acceder el sistema en lnea para indicar cul curso ensear. Tambin necesitan conocer cules estudiantes estn matriculados para su curso. Para cada semestre, existe un periodo de tiempo en el cual el estudiante puede cambiar su horario. Los estudiantes accedern el sistema durante este tiempo y aadir y cancelar cursos. Actores Estudiantes Profesores Sistema Financiero Administrador Sistema Casos de Uso Estudiantes Matricular Profesores Seleccionar cursos a ensear Requerir lista del curso Administrador Sistema Mantener informacin del curso Mantener informacin del estudiante Mantener informacin profesor Generar catlogo
4.1.1.3. Relaciones de los Casos de Uso En los casos de uso pueden participar cuatro tipos de relaciones: asociacin, generalizacin, inclusin y extensin. Cada relacin tiene su propsito y notacin. Relacin Asociacin Generalizacin Inclusin Extensin Propsito Denota una relacin entre un actor y un caso de uso Denota herencia entre casos de uso Incluye la funcionalidad de uno caso de uso en otro Extiende la funcionalidad de un caso de uso a otro bajo ciertas condiciones Notacin
<<include> > <<extend> >
Figura 4-4: Diagrama de Casos de Uso Sistema Acadmico 4.1.2. Escenarios de Casos de Uso Un caso de uso describe una funcin fundamental del sistema desde la perspectiva del usuario. Sin embargo, existe ms de una forma para terminar una funcin dada. Un escenario es una instancia de un caso de uso, esto es, un camino lgico del inicio al final del mismo; es un ejemplo concreto de un caso de uso.
Los escenarios no contienen elementos condicionales porque describen uno de los posibles caminos de un caso de uso. Por lo tanto, nunca se debe encontrar un if en un escenario. Por ejemplo, no es posible tener un escenario con la siguiente oracin si el cliente requiere una habitacin doble, le pregunta si tiene ms huspedes. Si esto se va a presentar, entonces es necesario crear mltiples escenarios que cubran cada caso del if. Todos los escenarios comienzan de la misma manera, sin embargo, cada uno de ellos termina diferente. No es necesario realizar todos los escenarios, pero si los principales. Es posible dejar de definir escenarios cuando se haya descubierto el comportamiento del sistema. Existen dos tipos de escenarios; los primarios que son aquellos que obtienen resultados exitosos y los secundarios que obtienen eventos de fallas. Los escenarios se utilizan para crear los diagramas de actividades, el plan de pruebas y los diagramas de objetos. Escenario para el caso de uso Matricular Juan ingresa su identificacin 91558899 la cual el sistema valida. De un catlogo de cursos disponibles, Juan selecciona como cursos principales Ingls, Geologa, Historia y lgebra. Tambin selecciona Msica y Java como materias alternativas. El sistema determina que Juan cumple con los pre-requisitos necesarios y lo agrega a la lista de estudiantes de ese curso. El sistema indica que la actividad se ha completado, imprime el horario del estudiante y le enva la informacin correspondiente al sistema financiero. Escenarios secundarios Estudiante no selecciona 4 cursos primarios El curso primario no est disponible Los cursos primarios y secundarios no estn disponibles No puede agregar el estudiante al curso No puede crear el horario del estudiante
Ejercicio de trabajo durante el curso Definir el la especificacin de requerimientos funcionales, no funcionales y el diagrama de casos de uso para el siguiente enunciado. Una compaa requiere un sistema de nmina. Ellos necesitan que el sistema opere en sus dos sucursales, cada una de ellas tiene diferente moneda, impuestos y polticas de nmina. El pago es calculado mensualmente y semanalmente dependiendo del tipo del pago del empleado. Actualmente los tipos de pago son, mensuales, semanales y por horas.
Los empleados pagados mensualmente tienen un salario anual dividido en doce cantidades iguales, las cuales corresponden a los pagos de cada mes. Los empleados pagados semanalmente, son pagados con una tarifa semanal al final de la semana. Los empleados pagados por hora tienen una tarifa por horas. Las horas trabajadas por estos empleados estn determinadas por el tiempo de entrada y el tiempo de salida almacenado en un sistema de tiempo. Las horas extras son pagadas segn las tarifas aplicadas en la sucursal correspondiente. La mayora de los empleados son pagados por hora. La informacin del tiempo de trabajo para estos empleados puede ser descargada directamente del sistema. Esto debe hacerse cada 24 horas. Los empleados se identifican con sus nombres y el nmero de identificacin. Los empleados pagados por hora y semanalmente, pueden elegir si desean el pago en efectivo o en cheque. A los empleados mensuales slo se les paga en cheque. Todos los pagos se hacen en la moneda local aplicable a la sucursal correspondiente. Los pagos son calculados aplicando los impuestos correspondientes segn la sucursal. Los impuestos son acumulados para el ao financiero. Los impuestos de pensin y de seguridad son descontados sobre el salario base y proporcional a cada uno. Los impuestos de salud y de contaminacin son descontados del salario base y son tarifas fijas. Existen otros conceptos opcionales para descuento como el seguro de salud. Las pensiones se descuentan a todos los empleados y tienen un porcentaje fijo. Las tasas de pago y los detalles de los empleados slo pueden ser almacenados y modificados a travs de Recursos Humanos. Semanalmente y mensualmente se corre la opcin correspondiente por la persona encargada y se generan los pagos de nmina. Esto produce una lista resumen de los pagos y descuentos realizados a cada empleado. Este resumen presenta el total de descuentos generado por todos los empleados. Al final del ao, la persona encargada de esta labor, requiere un resumen de pagos de impuestos para todos los empleados durante el ao. Impuestos Sucursal 1: Pensin, Contaminacin y Seguridad. Impuestos Sucursal 2: Pensin y Salud.
4.2. ANLISIS DE REQUERIMIENTOS
Fuente: Object-Oriented Analysis and Design using UML. Student guide with instructor notes. Sun Microsystems 2003. Revision C. * CRC = Class Responsability Collaborator
Figura 4-5: Mapa del proceso Anlisis de Requerimientos El anlisis se refiere a la capacidad de extraer datos ms detallados de la captura de requerimientos. Para ello es necesario crear una descripcin detallada de los casos de uso y refinar el diagrama. 4.2.1. Descripcin del caso de uso La descripcin del caso de uso contiene los siguientes tems: Cdigo y nombre del caso de uso Descripcin Actores Prioridad (alta, media, baja) Riesgo (alto, medio, bajo). Los casos de uso de alto riesgo deben desarrollarse en las primeras iteraciones. Los riesgos se pueden encontrar en las siguientes reas;
Riesgos de requerimientos; Riesgos tecnolgicos, Riesgos de capacidades, Riesgos de recursos, Riesgos de polticas Precondiciones (desde el punto de vista del funcionamiento del caso de uso con el usuario) Flujo de eventos Flujos alternos (desde el punto de vista del funcionamiento del caso de uso con el usuario) Poscondiciones Requerimientos no funcionales La descripcin de los flujos de eventos sigue la estrategia de relevamiento como se presenta en la siguiente figura:
Funcionalidad deseada Errores Excepciones
Camino o flujo bsico

Funcionalidad no deseada
Figura 4-6: Esquema de relevamiento de la descripcin de los flujos de eventos Para la descripcin de cada uno de los pasos de los flujos de eventos, se recomienda utilizar la tcnica del scripting como se describe a continuacin: Rol: quien tiene la responsabilidad de llevar a cabo el comportamiento del sistema (actor) Responsabilidad: cada comportamiento desarrollado por un rol Dos tipos de actores: iniciador y participante Dos tipos de responsabilidades: accin y servicio Una colaboracin: entre ambos roles
Descripcin del caso de uso Matricular Este caso de uso es iniciado por un estudiante y provee la posibilidad para que el estudiante cree, elimine, modifique y revise la informacin de un horario de para un semestre dado. Precondiciones: Se muestra la pantalla principal de inclusin de cursos. Flujo de Eventos Matricular Este caso de uso comienza cuando el estudiante digita su identificador. El sistema verifica que este identificador sea vlido, y le permite al estudiante seleccionar el semestre actual o uno posterior. El estudiante selecciona el semestre deseado. El sistema le presenta al estudiante las siguientes actividades a realizar: Crear horario Revisar horario Cambiar horario Eliminar un curso Agregar un curso El estudiante indica que la actividad es finalizada. El sistema imprime el horario del estudiante y notifica que su matrcula est terminada. El sistema le enva la informacin al sistema financiero para su procesamiento. Flujo alterno Si el identificador es invlido, el sistema no le permite el acceso al sistema de matrcula. Si el estudiante intenta crear un horario para un semestre donde ya est matriculado, el sistema solicita que elija otro semestre. Crear un horario El estudiante ingresa los 4 cursos primarios, selecciona los 2 cursos alternativos y el sistema valida: Verifica que los prerequisitos estn satisfechos para el curso requerido Agrega el estudiante al curso, si ste est abierto. Flujo alterno Si el curso primario no est disponible, el sistema lo sustituye con un curso alterno. Flujo alterno Si el estudiante no cumple con los prerrequisitos necesarios, el sistema le presenta el mensaje al usuario y no lo matricula en el curso correspondiente. Revisar un horario El estudiante requiere la informacin de todos los cursos ofrecidos en los cuales est matriculado para un semestre dado. El sistema muestra todos los cursos solicitados, incluyendo el nombre del curso, nmero, das de la semana, tiempo, ubicacin, crditos.
Cambiar horario Eliminar un curso El estudiante indica cual curso va a eliminar. El sistema verifica que la fecha final para los cambios no haya sido excedida. El sistema elimina al estudiante de los cursos seleccionados. El sistema notifica que la solicitud ha sido tenida en cuenta. Agregar un curso El estudiante indica cul curso desea agregar. El sistema verifica que la fecha final para cambios no haya sido excedida. El sistema: Verifica que el mximo nmero de estudiantes del curso no sea excedido. Verifica los prerequisitos Agrega el estudiante en el curso Poscondiciones: La informacin se almacena en la base de datos. Se cierra la ventana de matrculas y se presenta la pantalla principal. 4.2.2. Refinacin del diagrama de casos de uso Algunos casos de uso definidos en la captura de requerimientos estn en un nivel muy superior, como por ejemplo informacin del curso. En este caso, es necesario introducir nuevos casos de uso que separen las actividades involucradas en l. Por ejemplo, un caso de uso para crear un nuevo curso, otro para consultar un curso, otro para modificar un curso y otro para eliminar un curso.
Figura 4-7: Refinacin caso de uso mantenimiento de la informacin de cursos
Otra forma de hacer refinamiento del diagrama de casos de uso es a travs de la identificacin de herencia entre actores y casos de uso. Para ello: Un actor puede heredar todos las asociaciones de los casos de uso de su actor padre Un caso de uso puede ser dividido en casos de uso especializados. Estos casos de uso usualmente se identifican por variaciones en los escenarios. Por ejemplo en las bsquedas de informacin por diferentes parmetros. Finalmente, es necesario refinar las relaciones entre todos los casos de uso identificados a travs de las relaciones inclusin y extensin. Para ello se debe tener en cuenta: Un caso de uso a incluye a un caso de uso b, si el caso de uso a requiere la funcionalidad de otro caso de uso b y siempre ejecuta el caso de uso incluido. Un caso de uso a extiende un caso de uso b, si el caso de uso a puede usar la funcionalidad de otro caso b, por lo tanto, el caso de uso a se extiende al caso de uso b. La extensin permite identificar comportamientos del sistema que no son parte de flujos primarios, sino que existe en escenarios alternos.
Figura 4-8: Refinacin caso de uso Matricular Otro ejemplo de diagrama de caso de uso se presenta a continuacin y se refiere a los requerimientos funcionales de una tienda virtual.
Figura 4-9. Diagrama de casos de uso de una tienda virtual
4.2.3. Casos de Prueba A partir de la descripcin de los casos de uso, se definen los casos de prueba, con el fin de utilizarlos al final de cada iteracin y verificar la funcionalidad del sistema.
Caso de prueba 1 Ingresa 4 cursos primarios SI Cumple con Hay cupo Ingresa dos cursos prerrequisitos alternos SI SI SI Resultado
FB
FB + FA1
SI
SI
SI
NO
FB + FA2
SI
SI
NO
SI
Estudiante matriculado en los cursos primarios seleccionados. Estudiante matriculado en los cursos primarios y alternos especificados. Estudiante matriculado solo en los cursos en los cuales tiene completos los prerrequisitos.
FB= flujo bsico FA1= flujo alterno 1 Ejercicio: Realizar el diagrama de casos de uso y la descripcin de uno de ellos para el Sistema de Nmina.
4.2.4. Diagramas de Actividades Despus de crear los casos de uso, se pueden realizar los diagramas de actividades para presentar grficamente las actividades o flujos de eventos dentro de los casos de uso. El diagrama de actividades puede extender la descripcin de los casos de uso. Son similares a un diagrama de flujo que describe el orden de las actividades de un proceso. Se debe realizar un diagrama de actividades por cada caso de uso. Los diagramas de actividades incluyen los siguientes elementos: Actividades Decisiones Divisin de control Unin de control Iteracin Flujo de objetos
Actividad
Bifurcacin
Flujo
Unin
Inicio
Subdivisin Fin
Separador
Unin
Figura 4-10: Notacin del Diagrama de Actividades
Selecciona Matricular
Consultar Horario Consulta Cursos
Crear Horario Selecciona Cursos Agregar Cursos
Modificar Horario
Eliminar Cursos Elimina Cursos Curso Abierto
Actualiza Matrcula
Figura 4-11: Diagrama de Actividades Caso de Uso Matricular Sistema Acadmico
Un diagrama de actividades puede considerarse como un caso especial de un diagrama de estados en el cual casi todos los estados son estados accin (identifican una accin que se ejecuta al estar en l) y casi todas las transiciones evolucionan al trmino de dicha accin (ejecutada en el estado anterior). Un diagrama de actividades puede dar detalle a un caso de uso, un objeto o un mensaje en un objeto. Permiten representar transiciones internas al margen de las transiciones o eventos externos. En la figura siguiente se presenta un ejemplo de diagrama de actividades para un mensaje de un objeto.
Figura 4-12: Ejemplo de un Diagrama de Actividades de una mquina dispensadora de bebidas
La interpretacin de un diagrama de actividades depende de la perspectiva considerada: en un diagrama conceptual, la actividad es alguna tarea que debe ser realizada; en un diagrama de especificacin o de implementacin, la actividad es un mtodo de una clase. Generalmente se suelen utilizar para modelar los pasos de un algoritmo.
Un estado de accin representa un estado con accin interna, con por lo menos una transicin que identifica la culminacin de la accin (por medio de un evento implcito). No deben tener transiciones internas ni transiciones basadas en eventos, ya que si fuera este el caso, se representara con un diagrama de estados. Los estados de accin se representan por un rectngulo con bordes redondeados, y permiten modelar un paso dentro de un algoritmo. Las flechas dirigidas entre estados de accin representan transiciones con evento implcito que, en el caso de decisiones, pueden tener una condicin o guarda asociada (que al igual que en los diagramas de estado evala a true o a false). Las decisiones se representan mediante una transicin mltiple que sale de un estado y donde cada camino tiene una etiqueta distinta. Se representa mediante un rombo al cual llega la transicin del estado origen y del cual salen las mltiples transiciones de los estados destino. Un ejemplo se muestra en la figura 5.7 cuando no hay caf y se toma una decisin entre hay cola o no hay cola. En un diagrama de actividades tambin pueden existir barras de sincronizacin (synchronization bar), como la que sigue a [found cofee] en la figura anterior, a las que se encuentran asociadas varios caminos salientes. Cada camino saliente se dirige a una actividad (Put Coffee in Filter, Add Water to Reservoir y Get Cups), realizndose dichas actividades en paralelo. Esto quiere decir que el orden en que se realicen dichas actividades es irrelevante, siendo vlido cualquier orden entre ellas. Dado que el diagrama de actividades permite expresar el orden en que se realizan las cosas, resulta adecuado para el modelado de organizaciones (business modeling) y el de programas concurrentes (permiten representa grficamente los hilos de ejecucin). Como la mayora de las tcnicas de modelado de comportamiento, los diagramas de actividades tienen sus puntos fuertes y sus puntos dbiles, de forma que es necesario utilizarlos en combinacin con otras tcnicas. Su principal aportacin al modelado del comportamiento es que soportan el comportamiento paralelo, lo que resulta adecuado para el modelado de flujo de trabajo (workflow) y programacin multihilo (multi-thread). Por contra, su principal desventaja es que no muestran de una forma clara los enlaces existentes entre las acciones y los objetos, siendo mucho ms apropiado para ello los diagramas de interaccin. En general resulta adecuado utilizar diagramas de actividades para: Anlisis de casos de uso: Durante el anlisis de los casos de uso no estamos interesados en asociar acciones a objetos, sino en entender qu acciones se necesitan llevar a cabo y cuales son las dependencias en el comportamiento. Comprensin del flujo de trabajo a lo largo de diferentes casos de uso. Modelado de aplicaciones multihilo. Por contra, resultan en general del todo inadecuados a la hora de mostrar la colaboracin entre objetos y la evolucin del comportamiento de los objetos durante su tiempo de vida.
4.2.5. Abstracciones principales El modelo de anlisis provee ms detalles de cada caso de uso, escrito en el lenguaje del desarrollador; este modelo es una vista interna del sistema. La fase anlisis identifica los objetos requeridos por el problema para asegurar la funcionalidad del sistema y sigue el siguiente proceso: Definir qu debe hacer el sistema, esto es, la funcionalidad del mismo. Identificar los candidatos a objetos y clases, analizando sus relaciones y responsabilidades Actualizar el diccionario de datos o glosario de trminos. Todos los trminos nuevos identificados durante la fase de anlisis, se deben incluir en el diccionario de datos En general, el modelo de anlisis provee una transicin entre la captura de requerimientos y el diseo. El proceso de anlisis sirva para modificar y finalizar requerimientos. 4.2.6. Clases y Objetos Una clase es la plantilla para un objeto, es decir, una clase define un objeto. El siguiente ejemplo de galletas ilustra el concepto. Considere la memoria dentro de un computador como si fuera una masa para hacer galletas. Cuando se inicia, la masa no tiene caractersticas. Cada parte luce exactamente como la otra. Es posible utilizar un molde para crear las galletas deseadas. Slo se posee un molde, pero puede utilizarse para crear tantas galletas como las deseadas hasta utilizar toda la cantidad de masa disponible. Todas las galletas son iguales despus de cortadas. Cada una de ellas puede ser nica agregando diferentes caras y botones con colores y decoraciones y todas tendrn caractersticas individuales. El molde es similar a una clase en trminos de programacin orientada a objetos. Es posible definir una clase por cada tipo de objeto que se necesita. Las clases se crean antes de que el programa se ejecute. La galleta en forma de hombre y con sabor a ginebra es similar a un objeto en trminos de programacin orientada a objetos. Son creados en tiempo de ejecucin utilizando una de las clases previamente definidas. En la programacin estructurada, las funciones son los componentes fundamentales de una aplicacin. Debido a que todos los datos y mtodos estn asociados con objetos, stos son los componentes fundamentales de un programa orientado a objetos. Aprender a identificar objetos potenciales es un paso importante para entender el anlisis y diseo orientado a objetos. Todos los objetos representan un sustantivo. El objeto ms simple es un tem tangible como una persona, un orden de compra o un reporte. Los objetos tambin pueden representar sustantivos intangibles como conceptos. Un objeto puede ser:
Una cosa: Un objeto puede representar un tem tangible que existe dentro del mundo real como una parte de un automvil, un cliente o un elemento de una interfaz grfica como un botn. Un evento: Un objeto puede representar un suceso como la fecha de entrega, una llamada telefnica o la activacin de un elemento dentro de una interfaz grfica. Un proceso: Un objeto puede representar un proceso, como colocar una orden o la interaccin con una base de datos. Un objeto puede ser simple o complejo, real o imaginario y puede tener atributos y operaciones. Por ejemplo, si e objetos es un nube, los atributos pueden ser forma, tamao, contenido de agua. Un ejemplo de las operaciones puede ser llover, nevar o tronar. Cuando se intenta asignar operaciones a un objeto, las operaciones ejecutadas sobre el objeto son asignadas al objeto mismo. Por ejemplo, si se tiene una cuenta bancaria como un objeto, las operaciones de la cuenta podran ser abrir la cuenta, cerrar la cuenta, y as sucesivamente. Un objeto es un concepto dinmico. En cualquier momento, un sistema involucra un conjunto de objetos que contienen informacin e invocan funcionalidades entre si. Identificacin de los objetos del Sistema Acadmico Para encontrar, se examinan los sustantivos de los casos de uso y los escenarios. Por lo tanto, los sustantivos del escenario de matrcula: Juan Sistema Horario Cursos primarios Geologa Algebra Msica Pre-requisitos Objetos candidatos Juan (actor) Sistema (lo que va a ser construido) Horario (candidato a objeto) Cursos primarios (estado de un curso) Geologa (candidato a objeto) Algebra (candidato a objeto) Msica (candidato a objeto) Pre-requisitos (candidato a objeto)
Ejercicio: Identificar los posibles objetos del Sistema de Nmina. 4.2.7. Diagramas de Clases Un diagrama de clase es una notacin grfica utilizada para representar un conjunto de objetos que comparten atributos y caractersticas comunes. Un diagrama de clase consiste de uno o ms rectngulos con una seccin para el nombre de la clase, otra parar los atributos y otra para las operaciones.
Profesor nombre Id crear() guardar() eliminar() cambiar()
Figura 4-13: Notacin de clases en UML Los diagramas de clases son utilizados para ilustrar las relaciones entre clases y son el fundamento para el proceso de diseo. Las clases participan principalmente en cuatro relaciones: Asociacin Agregacin Composicin Generalizacin 4.2.7.1. Asociacin Una asociacin ilustra una relacin utiliza un entre las instancias de una clase. Una asociacin provee un camino de comunicacin entre objetos. Esta relacin est representada por una lnea entre dos clases.
Departamento
Profesor
Figura 4-14: Ejemplo de una relacin de asociacin Las asociaciones deben tener una direccin la cual indica la navegabilidad de la misma.
4.2.7.2. Multiplicidad La multiplicidad es utilizada para denotar el nmero de instancias de una clase involucradas en una relacin.
Profesor
o..*
Curso
Figura 4-15: Ejemplo de una relacin de asociacin con multiplicidad
Existen asociaciones reflexivas en donde los objetos de la misma clase estn relacionados.
Materia
Pre-requisitos 0..*
0..*
Una materia puede tener uno o varias materias prerrequisitos y una materia puede ser prerrequisito de una o varias materias
Figura 4-16: Ejemplo de una relacin de asociacin reflexiva 4.2.7.3. Agregacin La agregacin es utilizada para mostrar que una clase es parte de otra. La relacin se denota utilizando un diamante y una lnea entre las clases. El diamante del lado de la clase Catlogo, indica que el es parte de la clase Catlogo.
Catlogo
1..*
Curso
Figura 4-17: Ejemplo de una relacin de agregacin 4.2.7.4. Composicin La composicin es el segundo tipo de una relacin es parte de entre clases y es ms fuerte que la agregacin, con la expresin est compuesto por. Esta relacin es ms fuerte, porque las partes nacen y mueren con el todo. Est representada por un diamante relleno y una lnea entre las clases. El diamante relleno indica que el pensum est compuesto por materias.
Pensum
1..*
Materia
Figura 4-18: Ejemplo de una relacin de composicin
Un ejemplo de todas de un diagrama de clases con sus diferentes conceptos, se presenta en la siguiente figura.
Persona + atributo: operaci on() : voi d
clase
generalizacin
Vendedor Cliente
nota
Origen
1..1
1..1 soli ci ta 0..* Pedido Producto i ncl uye 0..* 0..* 1..* provi ene de
1..1
0..*
asociacin
atiende
navegabilidad
clase asociacin
ItemPedido
multiplicida d
Figura 4-19: Conceptos involucrados en un diagrama de clases 4.2.7.5. Clase Asociacin Una clase asociacin corresponde a asociacin que se modela como clase o viceversa. Es importante tener presente que la multiplicidad entre la clase y la asociacin es 1..1.
Factura 0..* 1..*
Artculo
ItemFacturado
Figura 4-20: Ejemplo 1 de una clase asociacin 4.2.7.8. Dependencia Una relacin de dependencia significa que una clase es dependiente de otra por algn servicio. Una relacin de dependencia se indica si las operaciones de la clase cliente crean objetos de la clase proveedora y si las operaciones de la clase cliente pasan argumentos a las instancias de la clase proveedora. 4.2.7.9. Herencia La herencia describe cmo es posible compartir atributos y funcionalidad entre clases de naturaleza o propsitos similares. La herencia o generalizacin es una relacin de es un. Cuando una clase hereda de otra, esta es llamada subclase y la clase de la cual hered, es llamado superclase. Existen dos tipos de herencia, la herencia simple la cual es la ms comn, y la herencia mltiple. Esta ltima no es permitida por todos los lenguajes orientados a objetos, C++ lo permite, pero Java no lo permite. Cuando se decida utilizar herencia mltiple, es necesario considerar su relevancia dentro del sistema. Una subclase hereda de su padre atributos, operaciones y relaciones. Una subclase puede agregar atributos, operaciones y relaciones adicionales y redefinir las operaciones heredadas. Existen dos formas para aadir el concepto de herencia en un modelo, Generalizacin y Especializacin. 4.2.7.10. Generalizacin Provee la capacidad de crear superclases que encapsulan la estructura y/o comportamiento comn de varias subclases. El procedimiento de generalizacin es identificar las estructuras/comportamientos similares entre clases.
4.2.7.11. Especializacin Provee la capacidad de crear subclases que representan el refinamiento en el cual la estructura y/o comportamiento de una superclase es aadido o modificado. El procedimiento de especializacin es identificar que algunas instancias de la superclase exhiben comportamiento especializado. 4.2.8. Modelo del dominio El modelo del dominio es una de las vistas del modelo de requerimientos, las otras corresponden a los requerimientos textuales del documento SRS y el modelo de casos de uso. Las clases en el modelo del dominio son las abstracciones principales del sistema y el modelo se representa como un diagrama de clases con las abstracciones identificadas durante el anlisis.
Figura 4-21: Diagrama de clases del modelo del dominio Una tcnica para validar el modelo del dominio con el problema es construir el diagrama de objetos desde los escenarios de los casos de uso y verificar si el diagrama de objetos se ajusta con el diagrama de clases. Ejercicio: Hacer el modelo del dominio para el sistema de nmina.
4.2.9. Diagrama de objetos El diagrama de objetos es una instancia de un diagrama de clases y presenta los detalles de un estado del sistema en un punto del tiempo determinado. En UML el diagrama de objetos representa los objetos y sus relaciones en tiempo de ejecucin. Para validar el modelo del dominio es necesario ejecutar los siguientes pasos: 1. Elegir uno o ms casos de uso que estn altamente relacionados con el modelo del dominio. 2. Elegir uno o ms escenarios de los casos de uso seleccionados en el punto anterior. Es recomendable elegir escenarios que exploren diferentes situaciones. 3. Ir a travs de cada escenario en forma separada, y construir los objetos con los datos mencionados en el escenario. 4. Comparar cada diagrama de objetos con el modelo del dominio para analizar si se han violado algunas restricciones.
Creando el diagrama de objetos desde el escenario: Juan ingresa su identificacin 91558899 la cual el sistema valida.
Figura 4-22: Diagrama de objetos escenario de matricula paso 1 De un catlogo de cursos disponibles, Juan selecciona como cursos principales Ingls, Geologa, Historia y lgebra. Tambin selecciona Msica y Java como materias alternativas.
Figura 4-23: Diagrama de objetos escenario de matricula paso 2
El sistema determina que Juan cumple con los pre-requisitos necesarios, lo agrega a la lista de estudiantes de ese curso, imprime el horario del estudiante y le enva la informacin correspondiente al sistema financiero
Figura 4-24: Diagrama de objetos escenario de matricula paso 3 4.3. DISEO
Figura 4-25: Mapa del proceso Diseo
El modelo de diseo es creado desde los requerimientos funcionales y describe los tipos de componentes requeridos para ejecutar el caso de uso. El modelo de diseo se integra con el modelo arquitectnico para producir la solucin al modelo. Ivar Jacobson identific tres tipos principales de clases en un sistema orientado a objetos: entidad, interfaz y control. 4.3.1. Clases Entidad Las clases entidad, modelan el mundo real. Todos los objetos estudiados hasta el momento son de entidad. El proceso de anlisis comienza identificando las entidades de informacin del negocio, como diferentes tipos de reportes, informacin de clientes, de inventario, entre otras. La mayora de esta informacin puede ser trasladada directamente a clases entidad. 4.3.2. Clases Interfaz Las clases interfaz son el puente entre el sistema y los usuarios. Los objetos que forman una interfaz grfica de usuario son ejemplos de clases interfaz. Estas clases frecuentemente hacen parte de una ventana, o un objeto impresora. En anlisis, cada clase de tipo interfaz mantiene una relacin con al menos un actor. 4.3.3. Clases de Control Las clases de control implementan la lgica del negocio que no puede ser fcilmente implementada en una clase entidad o interfaz. Las clases de control representan conceptos utilizados para mantener el sistema unido. Cada clase tiene su propia notacin.
Clase entidad
Clase interfaz
Clase control
Figura 4-26: Estereotipos de clases en UML
4.3.4. Interaccin entre Objetos Una vez se han identificado los objetos es necesario modelar cmo stos interactan dentro del sistema, para ello se utilizan los diagramas de secuencia y colaboracin. Los Diagramas de Secuencia presentan grficamente los objetos que toman parte en un escenario particular y muestra sus interacciones a travs del tiempo. En anlisis se debe
producir al menos un diagrama de secuencia por cada escenario, o por lo menos un diagrama de secuencia por cada flujo bsico de cada caso de uso. Los pasos para elaborar este tipo de diagramas son: 1. 2. 3. 4. 5. Seleccione un caso de uso Coloque el actor en el diagrama Identifique las clases de interfaz Identifique las clases de control Identifique las clases de entidad
Figura 4-27: Diagrama de Secuencia Caso de Uso Matricular
Los objetos son dibujados como rectngulos con los nombres subrayados, las lneas de vida son representadas por lneas punteadas y la interaccin se indica por una lnea horizontal entre objetos. Los diagramas de colaboracin son una alternativa de los diagrama de secuencia y
describe las relaciones entre objetos.
Figura 4-28: Diagrama de Colaboracin Caso de Uso Matricular Ejercicio: Hacer el diagrama de secuencia para el caso de uso definido en clase. 4.3.5. Refinando el modelo de dominio Una clase debe tener atributos y mtodos asignados, los cuales le permiten conocer sus responsabilidades. Los atributos le permiten a una clase almacenar informacin relacionada con una tarea en particular. Los mtodos u operaciones, son funciones que manipulan los valores de los atributos. Las operaciones deben ser nombradas desde la perspectiva del proveedor de la operacin, no desde el cliente. Los nombres de los mtodos y atributos deben ser nicos dentro de una clase. Se pueden obtener de la informacin filtrada de los casos de uso y escenarios.
Figura 4-29: Atributos y operaciones de la clase curso Existen algunas convenciones recomendables, los atributos y operaciones deben comenzar con una letra minscula, no se deben utilizar guiones, los nombres compuestos por varias palabras se unen con las primeras letras de cada palabra en mayscula. Durante la fase de diseo, todos los atributos deberan ser privados y slo ser visibles a otras clases a travs de los mtodos pblicos, de esta manera se refleja la encapsulacin, una de las principales caractersticas de la programacin orientada a objetos. Cada atributo se debe definir en trminos de: Tipo de dato Valor por defecto (si aplica) Restricciones (si aplica) Cada clase pueden tener mtodos, existen diferentes tipos pueden ayudar a encontrar mtodos: Mtodos de acceso: para acceder atributos privados, por ejemplo, los mtodos get y set Mtodos de administracin: como los constructores y destructores de C++, consultas, clculos, comparaciones, entre otros. 4.3.6. Paquetes Es una forma de agrupar tems. Se pueden utilizar para agrupar clases, componentes de software, de hardware, otros paquetes y cualquier producto relevante dentro del modelo. La notacin de UML es similar al icono de carpeta de windows. En las primeras fases del desarrollo del sistema es posible utilizar los paquetes para los siguientes objetivos: Tener una vista del sistema sin mucho detalle Tener vistas de pequeas porciones del sistema Crear pequeas porciones del sistema que pueden trabajar independientemente En un nivel superior se identifican tres paquetes: Interfaces, Reglas del Negocio y Entidad y los diagramas de clase se presentan organizados por paquetes.
Existe una dependencia entre paquetes cuando por lo menos una clase de un paquete depende de una clase dentro de un segundo paquete. Esta relacin se representa con una lnea punteada. Cuando existe dependencia cclica entre paquetes, es recomendable dividir los paquetes por funcionalidad, para romper estas dependencias cclicas.
La clase C pertenece al paquete A, la clase D pertenece al paquete B. Si existe una relacin de asociacin entre estas clases, existe una relacin de dependencia entre paquetes. En este caso, se construye primero el paquete B, porque A depende de B.
La clase C pertenece al paquete A, la clase D pertenece al paquete B. Si existe una relacin de agregacin entre estas clases, existe una relacin de dependencia entre paquetes. En este caso, se construye primero el paquete B, porque A depende de B.
La clase C pertenece al paquete A, la clase D pertenece al paquete B. Si existe una relacin de herencia entre estas clases, existe una relacin de dependencia entre paquetes. En este caso, se construye primero el paquete A, porque B depende de A.
Figura 4-30: Relaciones entre paquetes
Figura 4-31: Relaciones entre los paquetes identificados del sistema acadmico
4.3.7. Diagrama de clases de diseo Las nuevas clases identificadas en los diagramas de secuencia se deben representar y relacionar en un nuevo diagrama de clases.
Figura 4-32: Diagrama de clases de diseo
Ejercicio: Identificar paquetes y realizar el diagrama de clases de diseo del Sistema de Nmina, teniendo en cuenta los diferentes tipos de relaciones vistas anteriormente.
4.3.7. Arquitectura del sistema
Figura 4-33: Mapa del proceso Arquitectura Los arquitectos del sistema se encargan de hacer cumplir los requerimientos no funcionales como: o Para manejo de errores: Los objetos deberan detectar errores que puedan violar su integridad y se debe tener en cuenta que los errores pueden ser resultado de superar sus operaciones, resultado de los parmetros recibidos por un cliente, resultado de los valores retornados por un proveedor. Es importante tener un plan para monitorear la salud del sistema. Para la comunicacin entre procesos: Suponer que la Clase A llama a la Clase B, qu pasa si la clase A y la B estn en diferentes procesos?. Esto llega a ser un hecho crtico en sistemas distribuidos, por lo tanto, es necesario definir mecanismos estndares para el manejo de esta comunicacin. Almacenamiento de datos: Las bases de datos relacionales son herramientas poderosas para este objetivo. Sin embargo, el modelo relacional, difiere del modelo de objetos y es conveniente separarlos con los objetos persistentes. Un objeto persistente es un objeto que existe lgicamente y va ms all del programa que lo crea. En los lenguajes orientados a objetos, stos existen slo en
memoria. Un objeto persistente tiene la habilidad de almacenar el valor de sus atributos. El almacenamiento puede hacerse utilizando simples archivos o sistemas administradores de bases de datos. Existen diferentes modelos para DBMS: Jerrquico Relacional Orientada a Objetos Segn el modelo existen consideraciones a tener en cuenta: Se deben adicionar mtodos para almacenar y recuperar estos objetos Se deben adicionar atributos para manejar los detalles del almacenamiento Se deben adicionar clases que sirvan de interfaz con el DBMS Si se eligen bases de datos relaciones existen diferentes estrategias para las superclases y las subclases como Repetir todos los atributos en la tabla superclase, problema: desperdicio de espacio; o repetir todos los atributos en las tablas subclase, problema: redundancia. Rendimiento vs Almacenamiento son criterios involucrados en las situaciones de herencia.
Persona Nombre Telefono
Em pleado FechaInicio
Cliente Ide nti fica cio nCliente Preferencias
Figura 4-34: Ejemplo de una relacin de herencia
Persona ID (PK) Nombre Telfono FechaInicio NumeroCliente Preferencias TipoDeObjeto
Figura 4-35: Mapeo de herencia. Una tabla para la jerarqua de la clase persona
Figura 4-36: Mapeo de herencia. Una tabla por clase concreta
Persona
ID (PK) Nombre Telfono TipoDeObjeto
Es un
Es un
Empleado
ID (FK) FechaInicio
Cliente
ID (FK) NumeroCliente Preferencias
Figura 4-37: Mapeo de herencia. Una tabla por clase A continuacin se presenta un cuadro comparativo de los mtodos de mapeo presentados anteriormente:
Factores a Considerar Facilidad de Implementacin Facilidad de Acceso de datos Dependencia de las clases Una tabla para la jerarqua entera de una clase Simple Simple Muy Alta Una tabla por clase concreta Media Simple Alta Una tabla por clase Difcil Simple/Media Baja
Velocidad de Acceso de Datos Soporte a Polimorfismo Normalizacin Necesidad de Espacio en la BD
Rpido Media Ninguna Alta
Rpido Baja Media Media
Media/Rpido Alta Total Alta
El mayor cuestionamiento asociado con la interfaz con un RDBMS es si se debe separar el comportamiento de la aplicacin del comportamiento de la base de datos. Suponer que la clase Cliente se ha decidido volver persistente: Debera la clase cliente contener los detalles de pasar de OO a RDMSB? Debera la clase cliente contener el comportamiento para interactuar con un agente RDBMS? Debera la clase cliente tambin saber que es persistente? Cualquier modelo trabajara, slo que cada uno tiene sus ventajas y desventajas. El primer modelo cada clase persistente puede tener crear, leer, actualizar y borrar. Ventajas: Ninguna implementacin tcnicamente complicada Desventajas: OO y RDBMS no estn separados Funcionalidad CRUD no siempre es heredada transparentemente Si el comportamiento de la aplicacin se separa del comportamiento de la base de datos, el sistema puede ser modelado en dos partes: Aplicacin e Interfaz de Base de Datos. Para cada clase persistente, es necesario definir una interfaz para la base de datos que entienda la relacin de OO a RDBMS. Carga de trabajo del sistema Dispositivos fsicos 4.3.8. Tipos de arquitectura La arquitectura depende de los siguientes factores: o Las restricciones de la plataforma en los requerimientos del sistema, ya que en muchos casos la especificacin de requerimientos menciona sistema operativo y hardware especficos. Las formas de interaccin del usuario, por ejemplo si debe ser va web o va PDA. Los mecanismos de persistencia. La integridad de datos y transacciones.
o o o
Una capa es la organizacin fsica o lgica de componentes dentro de una cadena de ordenamiento de clientes y proveedores. Existen metodologas que sugieren la separacin en tres, cuatro o cinco capas. A continuacin se describen las cinco, pero se pueden reducir de acuerdo a las necesidades de cada sistema. o Capa del cliente, consiste de un cliente liviano como un navegador. La capa del cliente contiene todos los componentes con los cuales interacta el usuario. En una aplicacin web son las pginas web y los formularios que el servidor web entrega al navegador. Capa de presentacin que provee las pginas web y formularios que son enviados al navegador y procesa los requerimientos del usuario. Capa del negocio que provee los servicios del negocio y las entidades. All los componentes manejan la lgica, reglas y entidades de la aplicacin. Capa de integracin que provee componentes para integrar la capa de negocio con la de recursos. Los componentes de esta capa ejecutan las operaciones de crear, consultar, actualizar y eliminar una entidad. Capa de recurso que contiene los DBMS.
o o o
Existen cientos de arquitecturas exitosos, sin embargo las ms comunes son: o Aplicaciones standalone, compuesta de un componente que corre en una estacin de trabajo, como por ejemplo, una aplicacin de procesador de palabra, editores de texto, etc. Estas aplicaciones no acceden datos centralizados como una base de datos, ni participan en comunicaciones a travs de la red.
Figura 4-38: Aplicaciones standalone o Aplicaciones de dos capas (cliente/servidor), en la cual la aplicacin reside en la mquina del usuario y sta se comunica a un almacenamiento de datos centralizados.
Figura 4-39: Aplicaciones cliente - servidor Aplicaciones de n capas, en las cuales se separan los componentes del negocio de la aplicacin del cliente. Por lo tanto, el servidor de aplicaciones se encarga de administrar la integridad de datos y ejecuta todas las operaciones de almacenamiento.
Figura 4-40: Aplicaciones de n capas o Aplicaciones web de n capas, en donde las aplicaciones se acceden a travs de un navegador y la lgica del negocio reside en un servidor web.
Figura 4-41: Aplicaciones web de n capas
Aplicaciones empresariales de n capas, la cual representa un hbrido entre las aplicaciones de n capas y las aplicaciones web de n capas. En donde tanto los servidores web como las estaciones de trabajo de los clientes se comunican con el servidor de aplicaciones.
Figura 4-42: Aplicaciones empresariales de n capas
4.3.9. Refinando el modelo de dominio Posterior a la definicin de la arquitectura, es necesario crear las clases identificadas durante la arquitectura del sistema para el almacenamiento de la informacin.
Figura 4-43: Diagrama de clases de diseo
4.3.10. Diagrama de Transicin de Estados Los diagramas de transicin de estados son similares a los diagramas de actividad. Los estados de inicio y finalizacin tambin son representados con un crculo. Las transiciones de los objetos van hasta su destruccin. Los estados son representados por rectngulos con esquinas redondeadas y las transiciones entre estados son representadas por flechas. Un diagrama de transicin de estados muestra cmo cambia un objeto a travs del tiempo. Todos los objetos tienen un estado y su valor lo determina el valor de sus atributos. Un estado de un objeto es una de las posibles condiciones en las cuales puede existir. El estado inicial es que posee un objeto cuando es creado y es obligatorio. Slo es permitido un estado inicial. El estado final que indica el final de la vida del objeto y es opcional. Puede existir ms de un estado final. Un evento es una ocurrencia que sucede en un punto del tiempo. El estado del objeto determina la respuesta a los diferentes
eventos. Una transicin es un cambio hecho de un estado original a un estado sucesor como resultado de un estmulo. Una accin es una operacin que est asociada con una transicin. El nombre de una accin es mostrada en la flecha de la transicin precedida por un slash.
Agregar estudiante(numest<10)
Abierto Entry: Matricular un estudiante
No Asignado Do: Asignar profesor al curso Iniciado Do: Iniciar el objeto curso
Cancelar Curso
Cancelar Curso
Cancelado Do: Enviar mensaje de cancelacin Cupo Incompleto Do: Eliminar estudiantes matriculados
Cancelar Curso
Cerrado Do: Reporte curso lleno Finalizacin Matrcula Do: Generar lista de clase
Figura 4-44: Diagrama de Transicin de Estados Objeto Curso 4.3.11. Diagrama de Componentes Los componentes son grupos de piezas de software clases que representan todo el sistema, sus relaciones y son responsables por las operaciones dentro del sistema. Los diagramas de componentes muestran el empaquetamiento fsico del cdigo. Esto puede ser una clase, un archivo comprimido, un paquete, un ejecutable, libreras compartidas, bases de datos, entre otras. Cuando un componente colabora con otro, esta colaboracin es representada como una dependencia entre el componente cliente y el componente servicio. Control y Anlisis
Interfaz de Terminal Comment Comment
Gestin de Cuentas Comment
Rutinas de Coneccion Comment
Acceso a BD Comment
Figura 4-45: Ejemplo de Diagrama de Componentes
Cuando uno de los componentes cambia, puede afectar a otro. Esto es llamado, dependencia. Las clases de java son dependientes del cdigo fuente. 4.3.12. Diagrama de Distribucin Algunos sistemas corren sobre una misma plataforma, mientras que otros estn distribuidos en una serie de mquinas. Existen diversas razones para construir soluciones distribuidas. UML utiliza el diagrama de distribucin para mostrar que el sistema corre a travs de diferentes plataformas. Los diagramas de distribucin consisten de nodos los cuales representan algn dispositivo de hardware como servidores, estaciones de trabajo, PCs, sensores, telfonos, entre otros y muestran la configuracin de los nodos, procesos, componentes y objetos que residen en ellos en tiempo de ejecucin. Las conexiones entre los nodos corresponden a las conexiones de red entre ellos, presentadas como estereotipos.
Servidor Central Ac ceso a BD Comment
Control y Anlisis Comment
Rutinas de Coneccio n Comment
Terminal de Consulta Rutinas de Coneccio n Comment
Interfaz de Terminal Comment
Punto de Venta
Rutinas de Coneccio n Comment
Gestin de Cuentas Comment
Interfaz de Terminal Comment
Figura 4-46: Ejemplo de Diagrama de Distribucin
4.4. IMPLEMENTACIN DEL SISTEMA El cdigo es ejecutado dentro de la etapa de implementacin. El modelo de implementacin describe cmo las clases e interfaces del sistema se convertirn en cdigo fuente y finalmente en archivos ejecutables. Dentro del proceso unificado, existen dos entregas principales, el cdigo fuente y los archivos ejecutables, llamados componentes.
Figura 4-47: Mapa del proceso Implementacin 4.4.1. Plan de desarrollo Basado en los requerimientos funcionales y los no funcionales, el arquitecto del sistema determina cunta gente es necesaria y qu habilidades requieren para desarrollar el sistema. Para determinar el nmero de desarrolladores se debe tener en cuenta: o o o o o Tamao y complejidad de los casos de uso Tamao y complejidad de la arquitectura del sistema Integracin con aplicaciones existentes Duracin del proyecto Modularidad de los componentes
Para determinar las habilidades de los desarrolladores se debe tener en cuenta: o o El lenguaje de programacin y la plataforma Tecnologas especficas o Capa del cliente: HTML, JavaScript, Swing, VB o Capa de presentacin: JSP, PHP, ASP. o Capa de negocio: RMI, EJB, CORBA.
o Capa de integracin: JDBC, XA, MOM o Capa de recurso: DBMS Ambiente de desarrollo en donde se tienen en cuenta las herramientas existentes.
Otra parte del plan de desarrollo es la seleccin de los casos de uso para las iteraciones y cada uno debe entregar una parte claramente definida del comportamiento del sistema completo. Por lo tanto, casos de uso completos deben asignarse a iteraciones especficas. Posterior a la definicin de iteraciones, se estima el tiempo de desarrollo de los casos de uso y por lo tanto, de cada iteracin. 4.4.2. Cdigo de la solucin
4.4.2.1. Tipos de clases Existen tres tipos de clases y para cada una de ellas existe un cdigo de definicin diferente. Clases concretas:
public class MyClass { // members }
Clases abstractas:
public abstract class AbsClass { // members }
Interfaz:
public interface MyInterface { // members }
Herencia: El cdigo para la definicin de una subclase B que hereda de A es el siguiente:

public class B extends A { // members }
4.4.2.2. Atributos El cdigo para definir atributos de una clase es el siguiente:
public class Customer { private final String firstName; private final String lastName; private Address address= new Address(); }
4.4.2.3. Relaciones
Estudiante
1..n
Direcciones
Figura 4-48: Relacin de asociacin entre clases
public class Estudiante { private Direcciones [] direcciones; public [] Direcciones getDirecciones () { return direcciones; } public void addDirecciones (Direcciones d) { direcciones[0] = d; } } //En otra parte de cdigo Estudiante est = new Estudiante (2344,Sandra); Direcciones dir = new Direcciones (1,carrera 29); est.addDirecciones(dir);
4.4.2.4. Agregacin
Catlogo
1..n
Cursos
Figura 4-49: Relacin de agregacin entre clases

import java.util.*; public class Catalogo { private Cursos [] cursos; public Catalogo (Cursos cursos, String carrera){ this.cursos[0] = cursos } } //En otro cdigo Cursos cursos = new Cursos (H99,lgebra); Catalogo catalogo = new Catalogo(cursos, Facultad);
4.4.2.5. Composicin Tomando el mismo ejemplo anterior.
import java.util.*; public class Catalogo { private Cursos []cursos; Catalogo (int codigo, String nombre, String carrera){ this.cursos[0] = new Cursos (codigo,nombre); //dems cdigo } } //En otro cdigo Catalogo catalogo = new Catalogo(H99, lgebra, Facultad);
4.4.3. Ejemplo de la creacin de un estudiante utilizando tres capas Generalmente la programacin se realiza en arquitecturas cliente servidor de la siguiente manera:
import java.sql.*; public class TodoenUno{ public static void main(String[] args) { ResultSet rst = null; PreparedStatement pstm = null; Connection conn = null; String nombre="Sandra Johanna"; String documento="63508526"; String apellido="Moreno Valero"; String mail="smoreno@unab.edu.co"; String strIP = "numeroIP"; String strPuerto = "1521"; String strNombreDB = "nombreBD"; String strUsuario = "nombreUsuario"; String strPassword = "contrasena"; try { Class.forName("oracle.jdbc.driver.OracleDriver"); conn = DriverManager.getConnection("jdbc:oracle:thin:@" + strIP + ":" + strPuerto + ":" + strNombreDB + "", "" + strUsuario + "", "" + strPassword + ""); pstm = conn.prepareStatement("INSERT INTO PERSONA MHOV_IDENTIFICA, CHOV_NOMBRES, CHOV_PRIMERAPELLID, CHOV_EMAIL) VALUES (" + documento + ",'" + nombre + "','" + apellido + "','" + mail+"')"); pstm.executeQuery(); pstm = conn.prepareStatement("SELECT A.CHOV_NOMBRES, A.CHOV_PRIMERAPELLID, A.MHOV_IDENTIFICA, A.CHOV_EMAIL FROM PERSONA A WHERE A.MHOV_IDENTIFICA = " + documento); rst = pstm.executeQuery(); while (rst.next()) { System.out.println(rst.getString(1)); } Estudiante.java if (pstm!=null) pstm.close(); if (conn!=null) conn.close(); }catch(SQLException error1){} catch(ClassNotFoundException error2){} } }
Utilizando objetos y una arquitectura multinivel, el mismo cdigo presentado anteriormente quedara:
public class Estudiante { protected String strNombre; protected String strApellidos; protected int intDocumentoIdentidad; protected int intCodigo; public Estudiante(String n, String a, int c, int d) { strNombre=n; strApellidos=a; intDocumentoIdentidad=c; intCodigo=d; } public String getNombre() { return strNombre; } public String getApellidos() { return strApellidos; } public int getDocumentoIdentidad() { return intDocumentoIdentidad; } public int getCodigo() { return intCodigo; } public void guardarEstudiante() throws SQLException { public static ResultSet rst = null; public static PreparedStatement pstm = null; conn.setConeccion(); pstm = conn.prepareStatement("INSERT INTO ESTUDIANTES (NOIDENTIFICACION, NOMBRES, APELLIDOS, CODIGO) VALUES+ (+ intDocumentoIdentidad +,+ strNombre +, + strApellidos+,+ intCodigo+)"); pstm.executeQuery(); conn.cerrarConexion(); } } }
Coneccion.java
import java.sql.*; public class Coneccion { public static Connection conn = null; public static Connection setConeccion() throws ClassNotFoundException,SQLException { Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); conn = DriverManager.getConnection("jdbc:odbc:DRIVER={Microsoft Access Drive (*.mdb)}; DBQ=c:\\estudiantes.mdb", "admin",""); return conn; } public void CerrarConexion() throws SQLException { conn.close(); } }
Programa principal o interfaz PruebaAdmStma.java
import java.sql.*; public class PruebaAdmStma { public static void main(String[] args) { String nombre="Sandra Johanna"; int documento=5454545; String apellido="Moreno Valero"; int codigo=1111; Estudiante est = new Estudiante(); est.strNombre=nombre; est.strApellidos=apellido; est.intDocumentoIdentidad=documento; est.intCodigo=codigo; est.guardarEstudiante(); } }
4.4.4. Refinacin del diagrama de componentes

Interfaces .class
Administrador. class
Entidades .class
Intefaces .java
DB.class
<<Applet>> ChartMaker. class
Intefaces .jsp
Base de Datos
Figura 4-50: Diagrama de componentes
4.5. PRUEBAS DEL SISTEMA
Figura 4-51: Mapa del proceso Pruebas
Dentro de esta etapa, los desarrolladores prueban el sistema. El modelo de pruebas describe las pruebas para asegurar que la interfaz del sistema cumple con los requerimientos del documento inicial. El modelo est compuesto por casos, procedimientos y componentes de prueba. Un caso de prueba describe una forma de probar el sistema y especifica las entradas del sistema, las condiciones bajo las cuales deberan ser conducidas y las salidas esperadas. Un procedimiento de prueba describe el mtodo para ejecutar una o ms pruebas y describe cmo son ingresadas las entradas del sistema utilizando la interfaz del usuario y cmo se muestran los resultados. Los componentes de prueba son utilizados para automatizar el proceso de prueba y son programas o scripts que son ejecutados en contra del sistema para realizar las pruebas. Existen numerosas pruebas que se pueden aplicar. A continuacin se mencionan algunas de ellas: Pruebas de un solo componente o unidad Pruebas de integracin que garanticen el adecuado funcionamiento de grupos de componentes. Pruebas funcionales las cuales se hacen a travs de todo el sistema siguiente los casos de uso definidos en la etapa de captura de requerimientos. Pruebas de carga que verifican que el sistema puede manejar numerosos usuarios concurrentes. Pruebas con condiciones de lmite que verifican que los componentes, las clases, los subsistemas y el sistema en general puede manejar entradas que estn fuera de los valores aceptables. Pruebas de usabilidad que verifican la eficiencia, claridad y facilidad de uso en la interfaz del usuario. Para desarrollar una prueba funcional es necesario seguir los siguientes pasos: Identificar las entradas para la prueba, basadas en las entradas de un escenario especfico. Especificar los resultados de la prueba. Especificar las condiciones bajo las cuales se ejecut la prueba Escribir variaciones de la prueba para verificar fallas de procesamiento, condiciones de lmite, etc.
BIBLIOGRAFIA
Object-Oriented Application Analysis and Design for Java Technology (UML). 00-226. Student Guide. Sun Microsystems. Revision B.2, April 2002.
Object-Oriented Analysis and Design: Academic Student Guide. CIW Object-Oriented Analysis and Design Series. CIWv4. Prosoft Training. 2000-2002.
Methodology, Process, Education and Training for Todays Software Development Practices. Object- Oriented Analysis and Design. Student Manual. Rational University. Product # 4100-06180, V3.5
Object-Oriented Analysis and Design Using UML. 00-226. Student Guide With Instructor Notes. Sun Microsystems. Revision C. 2003.
ANEXO 1. PLANTILLA DE ESPECIFICACIN DE CASOS DE USO
<Project Name> Use Case Specification: <Use-Case Name>

Version <1.0>
[Note: The following template is provided for use with the Rational Unified Process. Text enclosed in square brackets and displayed in blue italics (style=InfoBlue) is included to provide guidance to the author and should be deleted before publishing the document. A paragraph entered following this style will automatically be set to normal (style=Body Text).] [To customize automatic fields in Microsoft Word (which display a gray background when selected), select File>Properties and replace the Title, Subject and Company fields with the appropriate information for this document. After closing the dialog, automatic fields may be updated throughout the document by selecting Edit>Select All (or Ctrl-A) and pressing F9, or simply click on the field and press F9. This must be done separately for Headers and Footers. Alt-F9 will toggle between displaying the field names and the field contents. See Word help for more information on working with fields.]
Revision History
Date <dd/mmm/yy> Version <x.x> <details> Description Author <name>
Table of Contents
1. Use-Case Name 1.1 Brief Description Flow of Events 2.1 2.2 Basic Flow Alternative Flows 2.2.1 < First Alternative Flow > 2.2.2 < Second Alternative Flow > 70 70 70 70 70 70 70 71 71 71 71 71 71 Error! Marcador no definido. Error! Marcador no definido.
2.
3.
Special Requirements 3.1 < First Special Requirement >
4.
Pre-conditions 4.1 < Pre-condition One >
5.
Post-conditions 5.1 < Post-condition One > Extension Points 6.1 <Name of Extension Point>
6.
Use Case Specification: <Use-Case Name>

[The following template is provided for a Use-Case Specification, which contains the textual properties of the use case. This document is used with a requirements management tool, such as Rational RequisitePro, for specifying and marking the requirements within the use-case properties. The use-case diagrams can be developed in a visual modeling tool, such as Rational Rose. A use-case report, with all properties, may be generated with Rational SoDA. For more information, see the tool mentors in the Rational Unified Process.]
Use-Case Name Brief Description

[The description briefly conveys the role and purpose of the use case. A single paragraph will suffice for this description.]
Flow of Events Basic Flow

[This use case starts when the actor does something. An actor always initiates use cases. The use case describes what the actor does and what the system does in response. It is phrased in the form of a dialog between the actor and the system. The use case describes what happens inside the system, but not how or why. If information is exchanged, be specific about what is passed back and forth. For example, it is not very illuminating to say that the actor enters customer information. It is better to say the actor enters the customers name and address. A Glossary of Terms is often useful to keep the complexity of the use case manageable you may want to define things like customer information there to keep the use case from drowning in details. Simple alternatives may be presented within the text of the use case. If it only takes a few sentences to describe what happens when there is an alternative, do it directly within the Flow of Events section. If the alternative flow is more complex, use a separate section to describe it. For example, an Alternative Flow subsection explains how to describe more complex alternatives. A picture is sometimes worth a thousand words, though there is no substitute for clean, clear prose. If it improves clarity, feel free to paste graphical depictions of user interfaces, process flows or other figures into the use case. If a flow chart is useful to present a complex decision process, by all means use it! Similarly for state-dependent behavior, a state-transition diagram often clarifies the behavior of a system better than pages upon pages of text. Use the right presentation medium for your problem, but be wary of using terminology, notations or figures that your audience may not understand. Remember that your purpose is to clarify, not obscure.]
Alternative Flows < First Alternative Flow >

[More complex alternatives are described in a separate section, referred to in the Basic Flow subsection of Flow of Events section. Think of the Alternative Flow subsections like alternative behavior each alternative flow represents alternative behavior usually due to exceptions that occur in the main flow. They may be as long as necessary to describe the events associated with the alternative behavior. When an alternative flow ends, the events of the main flow of events are resumed unless otherwise stated.]
< An Alternative Subflow >

[Alternative flows may, in turn, be divided into subsections if it improves clarity.]
< Second Alternative Flow >

[There may be, and most likely will be, a number of alternative flows in a use case. Keep each alternative flow
separate to improve clarity. Using alternative flows improves the readability of the use case, as well as preventing use cases from being decomposed into hierarchies of use cases. Keep in mind that use cases are just textual descriptions, and their main purpose is to document the behavior of a system in a clear, concise, and understandable way.]
Special Requirements
[A special requirement is typically a nonfunctional requirement that is specific to a use case, but is not easily or naturally specified in the text of the use cases event flow. Examples of special requirements include legal and regulatory requirements, application standards, and quality attributes of the system to be built including usability, reliability, performance or supportability requirements. Additionally, other requirements such as operating systems and environments, compatibility requirements, and design constraints should be captured in this section.]
< First Special Requirement > Pre-conditions

[A pre-condition of a use case is the state of the system that must be present prior to a use case being performed.]
< Pre-condition One > Post-conditions

[A post-condition of a use case is a list of possible states the system can be in immediately after a use case has finished.]
< Post-condition One >
ANEXO 2. EJEMPLO DE PLANTILLA DE CASO DE USO
<Portales UNAB> Especificacin del Caso de Uso <Solicitud Usuario UNAB> Versin <1.0>
Historia de Revisiones
Fecha Versin Descripcin Autor 26/08/2004 <1.0> Especificacin inicial del caso de uso Camilo Ernesto Rodrguez 28/08/2004 <1.0> Ajuste de flujos alternos, especificacin Sandra Johanna Moreno de referencias, definiciones, Valero requerimientos especiales y poscondiciones. 31/08/2004 <1.0> Modificacin de flujos alternos que Karol Dalila Reyes verifica la coincidencia del correo registrado en el sistema de informacin con LDAP, antes de presentar el mensaje que ya tiene un correo asignado. 06/09/2004 <1.0> Agregar la validacin que la persona Karol Dalila Reyes que solicita no sea del Instituto Caldas
Tabla de Contenido
1. Introduccin 1.1 Referencias 1.2 Definiciones, Acrnimos, y Abreviaturas Flujo de Eventos 2.1 Descripcin breve 2.2 Descripcin del flujo normal 2.3 Descripcin del flujo alterno Requerimientos especiales Precondiciones Poscondiciones 75 75 75 75 75 75 76 77 77 77
2.
3. 4. 5.
Especificacin del Caso de Uso <Solicitud de usuario UNAB>

Introduccin Este documento presenta la especificacin funcional del caso de uso solicitud de usuario UNAB. El propsito de este documento es describir el comportamiento del servicio e identificar los subsistemas relacionados. Tambin describir los requerimientos no funcionales, restricciones del diseo y otros factores necesarios para proveer una completa y comprensiva descripcin de los requerimientos del software. Referencias Caso de uso aplicacin Alpha. Manual de usuario aplicacin Alpha. Casos de prueba del caso de uso Solicitud de usuario UNAB. Doc N. Manual de uso del correo electrnico UNAB. Definiciones, Acrnimos, y Abreviaturas Cosmos: Nombre dado al sistema acadmico de la UNAB. SARA: Nombre dado al sistema de gestin de talento humano de la UNAB. LDAP: Nombre dado al sistema que almacena la base de datos de usuarios UNAB. IntraUNAB: Portal de acceso a servicios para docentes y administrativos de la UNAB. Portal del estudiante: Portal de acceso a servicios para estudiantes de pregrado y posgrado de la universidad. Alfa: Aplicacin realizada en Java que permite actualizar datos en el LDAP y desactivar cuentas de correo de estudiantes retirados. Flujo de Eventos Descripcin breve El caso de uso es iniciado por un estudiante o un empleado que va a solicitar un nombre de usuario para acceder al correo electrnico y al portal del estudiante o IntraUNAB segn corresponda. Este caso de uso no aplica para los estudiantes del Instituto Caldas. Descripcin del flujo normal {1}. El usuario selecciona la opcin de solicitud de usuario UNAB y el sistema le presenta un formulario para ingresar el documento de identidad. {2}. El usuario ingresa su documento de identidad y el sistema valida que los caracteres ingresados sean solo numricos, y que el usuario no sea estudiante del Instituto Caldas y se encuentre registrado en el sistema acadmico o de gestin de talento humano, segn sea estudiante o empleado.
{3}. El sistema verifica que el usuario no tenga registrado cuenta de correo en el sistema de informacin correspondiente y le presenta un formulario para que pueda crear el usuario y la cuenta de correo UNAB. {4}. El usuario ingresa la contrasea y el sistema valida que tiene que ser mnimo 8 caracteres y debe ser diferente de la cdula y el cdigo en caso sea estudiante. {5}. El usuario ingresa confirmacin de contrasea y el sistema valida que tiene que ser igual a la contrasea digitada anteriormente. {6}. El usuario ingresa correo contacto que es una cuenta alterna y el sistema valida que cumpla con los parmetros generales de una cuenta que correo, donde verifica que tenga la @ y su respectivo dominio. {7}. El usuario enva los datos y el sistema crea el usuario y la cuenta de correo UNAB, actualiza la informacin de correo en el sistema de informacin correspondiente. Descripcin del flujo alterno Usuario no registrado {2.1 }. La persona que solicita la creacin de usuario UNAB, no se encuentra registrado en el sistema de informacin correspondiente, por lo tanto, presenta un mensaje indicando que no se encuentra registrado en el sistema y que se comunique con Secretara General o la Oficina de Personal segn corresponda. Cuenta de correo registrada en el sistema de informacin y en LDAP {3.1}. La persona que solicita la creacin de usuario UNAB, ya tiene registrada una cuenta de correo en el sistema correspondiente y el sistema verifica que las cdula registrada en LDAP de ese nombre de usuario, coincide con la cdula registrada en el sistema de informacin. {3.2}. El sistema presenta un mensaje indicando que la persona que solicita ya tiene un usuario y cuenta de correo creada y le presenta el nombre de usuario con el cual puede ingresar al portal del estudiante o IntraUNAB segn corresponda y al correo UNAB. Adems, el sistema actualiza en LDAP los atributos correspondientes segn el caso. Para estudiantes, actualiza los atributos facultad, cdigo y estudiante, para administrativos, actualiza los atributos cargo, dependencia y administrativo y para los docentes, actualiza los atributos cargo, dependencias y docente. Cuenta de correo errnea registrada en el sistema de informacin y no existe usuario en LDAP para la persona solicitante {3.1.1}. La persona que solicita la creacin de usuario UNAB, ya tiene registrada una cuenta de correo en el sistema correspondiente y el sistema verifica que la cdula registrada en LDAP de ese nombre de usuario, no coincide con la cdula registrada en el sistema de informacin. {3.1.2}. El sistema le presenta el formulario para que pueda solicitar usuario UNAB y se ejecutan los pasos registrados en el flujo de eventos normal, presentados en el punto 2.2. {3.1.3}. La persona enva la solicitud y el sistema verifica que no exista un usuario asignado a la persona solicitante, crea el usuario, actualiza el dato correo en el sistema de informacin correspondiente y presenta un mensaje indicando que se ha creado satisfactoriamente el usuario.
Cuenta de correo errnea registrada en el sistema de informacin y si existe usuario en LDAP para la persona solicitante {3.1.2.1}. La persona enva la solicitud y el sistema verifica que si exista un usuario asignado a la persona solicitante, por lo cual, actualiza el dato correo en el sistema de informacin correspondiente y presenta un mensaje indicando que la persona ya tena un usuario creado pero no se encontraba registrado en el sistema correspondiente. Por lo tanto, con el proceso que acaba de ejecutar, se han actualizado los datos del perfil del usuario. Adems, el sistema actualiza en LDAP los atributos correspondientes segn el caso. Para estudiantes, actualiza los atributos facultad, cdigo y estudiante, para administrativos, actualiza los atributos cargo, dependencia y administrativo y para los docentes, actualiza los atributos cargo, dependencias y docente.
Requerimientos especiales No identificados en esta fase. Precondiciones La persona que va a solicitar usuario y cuenta de correo UNAB debe ser un estudiante que se encuentre registrado en el sistema Cosmos, o un empleado que se encuentre registrado en el sistema SARA. La persona que no pertenezca a estos sistemas de informacin y desee usuario y correo electrnico UNAB, necesitar comunicarse con la dependencia encargada para que se le asigne utilizando un procedimiento diferente al especificado en este caso de uso. Poscondiciones Para mantener actualizados la informacin del servidor de directorios y los sistemas de informacin que permiten validar los usuarios autorizados para ingresar a los portales se debe tener en cuenta los siguientes procedimientos: La persona encargada de administrador el correo UNAB deber ejecutar la aplicacin alfa una vez al mes para desactivar los correos de los empleados retirados y una vez al semestre para desactivar los estudiantes que se han retirado de la universidad. Cada vez que un estudiante se grade o se retire de la universidad, se le debe eliminar la informacin del correo institucional del sistema Cosmos, ya que los nombres de usuarios y las cuentas de correo se desactivan en los servidores de directorio y correo y se vuelven a reutilizar para otros usuarios. De lo contrario, si el estudiante regresa a la universidad y va a solicitar nuevamente un correo, le aparecer un mensaje indicando que ya tiene asignado un correo. Cada vez que un empleado se retire de la universidad, se le debe eliminar la informacin del correo electrnico del SARA, para evitar el mismo inconveniente descrito en el punto anterior.
ANEXO 3. EJEMPLO DE CASO DE PRUEBA
Portal de Estudiante Especificacin de Caso de Prueba: Caso de Pruebas de Solicitud de Usuario UNAB
Version 1.0
Historial de Revisiones
Fecha 25/08/2004 28/08/2004 Version 1.0 1.0 Description Especificacin inicial del caso de prueba Detalle de los resultados esperados y evaluacin de la prueba. Quedaron pendientes algunas pruebas por desconocimiento de qu es lo que se verifica. Author Camilo Ernesto Rodrguez Sandra Johanna Moreno Valero
Tabla de Contenido
1.Descripcin 2.Estudiante que solicita un usuario UNAB 2.1 Descripcin 2.2 Condiciones de ejecucin 2.3 Entrada 2.4 Resultado esperado 2.5 Evaluacin de la prueba 3. Estudiante que solicita un usuario UNAB, pero ya tiene registrado el correo institucional en Cosmos 3.1 Descripcin 3.2 Condiciones de ejecucin 3.3 Entrada 3.4 Resultado esperado 3.5 Evaluacin de la prueba 4. Estudiante que es administrativo y tiene una cuenta de correo UNAB, actualizados los atributos de estudiante en LDAP. 4.1 Descripcin 4.2 Condiciones de ejecucin 4.3 Entrada 4.4 Resultado esperado 4.5 Evaluacin de la prueba 5. Empleado que solicita un usuario UNAB. 5.1 Descripcin 5.2 Condiciones de ejecucin 5.3 Entrada 5.4 Resultado esperado 5.5 Evaluacin de la prueba 6. Empleado que solicita un usuario UNAB, pero ya tiene registrado el campo email en SARA. 6.1 Descripcin 6.2 Condiciones de ejecucin pero no estn
6.3 Entrada 6.4 Resultado esperado 6.4 Evaluacin de la prueba 7. Empleado que tiene un usuario UNAB, pero no estn actualizados los atributos de empleado en LDAP. 7.1 Descripcin 7.2 Condiciones de ejecucin 7.3 Entrada 7.4 Resultado esperado 7.5 Evaluacin de la prueba
1. Descripcin Este artefacto cubre el conjunto de pruebas realizadas sobre el Caso de Uso Solicitud Correo UNAB. Las pruebas realizadas a este caso de uso son: Estudiante que solicita un usuario UNAB. Estudiante que solicita un usuario UNAB, pero ya tiene registrado el correo institucional en Cosmos. Estudiante que es administrativo y tiene un usuario UNAB, pero no estn actualizados los atributos de estudiante en LDAP. Empleado que solicita un usuario UNAB. Empleado que solicita un usuario UNAB, pero ya tiene registrado el campo mail en SARA. Empleado que tiene usuario UNAB, pero no estn actualizados los atributos de empleado en LDAP. El entorno del cual partiremos para realizar las pruebas ser el formulario de entrada de la aplicacin, segn sea el caso, Portal del estudiante o IntraUNAB.
2. Estudiante que solicita un usuario UNAB. 2.1 Descripcin Ingresamos al portal del estudiante como visitante y hacemos clic en la columna derecha en Solicita aqu tu usuario UNAB, seguidamente nos enva a la pagina de solicitud de usuario donde presenta una caja de texto. El sistema solicita la cdula del estudiante y se proceder a crear el usuario UNAB. 2.2 Condiciones de Ejecucin Las condiciones de ejecucin del caso de prueba es que el usuario con la cedula 63557609 se encuentre registrado en Cosmos y que la tabla General.Goremal de Cosmos no tenga registrado ninguna cuenta de correo UNAB y en LDAP no tenga asignado un usuario. 2.3 Entrada El estudiante introduce en la caja de texto el numero de identificacin 63557609 y hace clic en buscar. Aparece el formulario de solicitud de correo con los campos contrasea, confirmar contrasea y correo contacto. El estudiante ingresa en el campo contrasea 123456
El estudiante ingresa en el campo confirmar contrasea 1234567 El estudiante ingresa en el campo correo contacto jaimeBar@hotmail.cccs El estudiante hace clic en enviar. Aparece un mensaje que dice La contrasea debe ser mnimo de 8 caracteres. El estudiante cambia la contrasea por 12345678. El estudiante hace clic en enviar. Aparece un mensaje que dice La contrasea debe ser igual que confirmacin contrasea. El estudiante cambia la confirmacin contrasea por 12345678 El estudiante hace clic en enviar Aparece un mensaje que dice El dominio del correo contacto es incorrecto El estudiante cambia el correo por jaimeBar@hotmail.com El estudiante hace clic en enviar. El sistema present un mensaje que dice Tu usuario UNAB ha sido creado satisfactoriamente, por lo cual ests habilitado para ingresar al Portal del Estudiante y al servicio de correo UNAB, con Tu nombre: JULIANA BALLESTEROS TRILLOS, Tu usuario: jballesteros3, Tu correo: jaballesteros3@unab.edu.co. 2.4 Resultado esperado
Creacin de la cuenta de correo para el estudiante con documento 63557609 y la actualizacin de la tabla General.Goremal con esta informacin. 2.5 Evaluacin de la prueba
La prueba superada con xito, ya que se verific la creacin del usuario en LDAP, se accedi a la cuenta de correo a travs de la web y comprob la actualizacin de la tabla General.Goremal en Cosmos. 3. Estudiante que solicita un usuario UNAB, pero ya tiene registrado el correo institucional en Cosmos. 3.1 Descripcin Ingresamos al portal del estudiante como visitante y hacemos clic en la columna derecha en Solicita aqu tu usuario UNAB, seguidamente se presenta la pagina de solicitud de usuario donde nos muestra una caja de texto. Se ingresa la cedula del estudiante y se procede a la creacin del usuario UNAB.
3.2 Condiciones de Ejecucin Las condiciones de ejecucin del caso de prueba es que el usuario con la cedula 13722001 se encuentra registrado en Cosmos y que en la tabla General.Goremal de Cosmos se encuentre registrado el correo institucional. 3.3 Entrada El estudiante introduce en la caja de texto el nmero de identificacin 13722001 y hace clic en buscar. Aparece un mensaje que dice El sistema reporta que ya tienes asignada la cuenta de usuario UNAB crodrigr@unab.edu.co para acceder al Portal de Estudiante y al servicio de correo. Para mayor informacin consulta con la Red Institucional en el primer piso del edificio de biblioteca, o la extensin 389 3.4 Resultado esperado No se hizo la creacin de la cuenta de correo UNAB, por que ya tiene asignada una cuenta de correo en Cosmos 3.5 Evaluacin de la prueba La prueba superada con xito, ya que se verific, que no se cre el usuario en LDAP, y se verifico tambin, que en Cosmos en la tabla General.Goremal la cuenta de correo crodrigr@unab.edu.co pertenece al estudiante con la cedula 13722001. 4. Estudiante que es administrativo y tiene una cuenta de correo UNAB, pero no estn actualizados los atributos de estudiante en LDAP. 4.1 Descripcin Ingresamos al portal del estudiante como visitante y hacemos clic en la columna derecha en Solicita aqu tu usuario UNAB, seguidamente nos enva a la pagina de solicitud de correo donde nos muestra una caja de texto, ingresamos la cedula del estudiante y procedemos a solicitar el usuario UNAB. 4.2 Condiciones de Ejecucin Las condiciones de ejecucin del caso de prueba es que el usuario con la cedula 77185418 se encuentra registrado en Cosmos y que la tabla General.Goremal no tenga registrado ninguna cuenta de correo UNAB y que en LDAP tenga asignado una cuenta de correo.
4.3 Entrada El estudiante introduce en la caja de texto el nmero de identificacin 77185418 y hace clic en buscar. Aparece el formulario de solicitud de correo con los campos contrasea, confirmar contrasea y correo contacto. El estudiante ingresa en el campo contrasea 12345678 El estudiante ingresa en el campo confirmar contrasea 12345678 El estudiante ingresa en el campo correo contacto Silvio@yahoo.com El estudiante hace clic en enviar. El sistema present un mensaje que dice El sistema reporta que ya tienes asignada la cuenta de usuario UNAB scuellod@unab.edu.co para acceder al Portal de Estudiante y al servicio de correo. Para mayor informacin consulta con la Red Institucional en el primer piso del edificio de biblioteca, o la extensin 389 4.4 Resultado esperado Actualizar el perfil de estudiante en LDAP y registrar en Cosmos en la tabla General.Goremal la cuenta de correo scuello@unab.edu.co, la informacin para actualizar en LDAP son los atributos, estudiante en si, cdigo del estudiante y cdigo de la facultad. 4.5 Evaluacin de la prueba La prueba superada con xito, se verific la correcta actualizacin de los atributos estudiante si, cdigo U00009487 y facultad EDRE en LDAP y tambin se verific que se registr en la tabla General.Goremal de Cosmos, la cuenta de correo scuellod@unab.edu.co.
5. Empleado que solicita un usuario UNAB.

5.1 Descripcin Ingresamos a la IntraUNAB y hacemos clic en Solicitud usuario UNAB, seguidamente nos enva a la pagina de solicitud de usuario donde nos muestra una caja de texto, ingresamos la cdula del empleado y procedemos solicitar el usuario UNAB. 5.2 Condiciones de Ejecucin Las condiciones de ejecucin del caso de prueba es que el usuario con la cedula 13842037 se encuentre registrado en SARA y no tenga registrado ninguna cuenta de correo UNAB y en LDAP no tenga asignado una cuenta de correo.
5.3 Entrada El empleado introduce en la caja de texto el numero de identificacin 13842037 y hace clic en buscar. Aparece el formulario de solicitud de correo con los campos contrasea, confirmar contrasea y correo contacto. El empleado ingresa en el campo contrasea 123456 El empleado ingresa en el campo confirmar contrasea 1234567 El empleado ingresa en el campo correo contacto jmartineza@dian.gov.coom El empleado hace clic en enviar. Aparece un mensaje que dice La contrasea debe ser mnimo de 8 caracteres. El empleado cambia la contrasea por 12345678. El empleado hace clic en enviar. Aparece un mensaje que dice La contrasea debe ser igual que confirmacin contrasea. El empleado cambia la confirmacin contrasea por 12345678 El empleado hace clic en enviar Aparece un mensaje que dice El dominio del correo contacto es incorrecto El empleado cambia el correo por jmartineza@dian.gov.co El empleado hace clic en enviar. El sistema present un mensaje que dice Su usuario UNAB ha sido creado satisfactoriamente, por lo cual ests habilitado para ingresar a la IntraUnab y al servicio de correo UNAB. Tu nombre: AIME NEL MARTINEZ ANGEL, Tu usuario: jmartinez7 , Tu correo: jmartinez7@unab.edu.co. 5.4 Resultado esperado Creacin de la cuenta de correo para el empleado con documento 13842037 y registro de la cuenta de correo jmartinez7@unab.edu.co en la tabla ACTUALIZACION_CORREO de SARA. 5.5 Evaluacin de la prueba La prueba superada con xito, se verific la creacin de la cuenta correo en LDAP y registro de la misma en la tabla ACTUALIZACION_CORREO de SARA.
6. Empleado que solicita usuario UNAB, pero ya tiene registrado el dato email en
SARA. 6.1 Descripcin
Ingresamos a la IntraUNAB y hacemos clic en Solicitud usuario UNAB, seguidamente nos enva a la pgina de solicitud de correo donde nos muestra una caja de texto, ingresamos la cdula del empleado y procedemos a solicitar el usuario UNAB. 6.2 Condiciones de Ejecucin Las condiciones de ejecucin del caso de prueba es que el usuario con la cedula 13722001 se encuentra registrado en SARA y tiene registrado el dato email en SARA. 6.3 Entrada El empleado introduce en la caja de texto el numero de identificacin 13722001 y hace clic en buscar. Aparece un mensaje que dice El sistema reporta que ya tienes asignada la cuenta de usuario UNAB crodrigr@unab.edu.co para acceder a la IntraUNAB y al servicio de correo. Para mayor informacin consulta con la Red Institucional en el primer piso del edificio de biblioteca, o la extensin 389 6.4 Resultado esperado
No se hizo la creacin de la cuenta de correo UNAB, por que ya tiene asignada una cuenta en SARA. 6.5 Evaluacin de la prueba
La prueba superada con xito, se verific en Ldap que ya existe una cuenta de correo con la cedula 13722001 que corresponde al empleado Camilo Ernesto Rodrguez Moreno, con cdula 13722001 y con la cuenta de correo crodrigr@unab.edu.co , tambin se verific que la informacin con respecto al nombre, cdula y cuenta de correo en LDAP es igual a la de SARA. 7. Empleado que un usuario UNAB, pero no estn actualizados los atributos de empleado en LDAP. 7.1 Descripcin Ingresamos a la IntraUNAB y hacemos clic en Solicitud usuario UNAB, seguidamente nos enva a la pagina de solicitud de correo donde nos muestra una caja de texto, ingresamos la cedula del empleado y procedemos a la creacin del usuario UNAB.
7.2 Condiciones de Ejecucin Las condiciones de ejecucin del caso de prueba es que el usuario con la cdula 13746331 se encuentra registrado en SARA y que no tenga registrado ninguna cuenta de correo UNAB, pero que en LDAP tenga asignado una cuenta de correo. 7.3 Entrada El empleado introduce en la caja de texto el nmero de identificacin 13746331 y hace clic en buscar. Aparece el formulario de solicitud de correo con los campos contrasea, confirmar contrasea y correo contacto. El empleado ingresa en el campo contrasea 12345678 El empleado ingresa en el campo confirmar contrasea 12345678 El empleado ingresa en el campo correo contacto edgar@yahoo.com El empleado hace clic en enviar. El sistema present un mensaje que dice El sistema reporta que ya tienes asignada la cuenta de usuario UNAB eagudel2@unab.edu.co para acceder a la IntraUNAB y al servicio de correo. Para mayor informacin consulta con la Red Institucional en el primer piso del edificio de biblioteca, o la extensin 389 7.4 Resultado esperado Actualizar el perfil de empleado en LDAP y en la tabla ACTUALIZACION_CORREO. La informacin a actualizar en LDAP son los atributos, segn sea el caso, administrativo en si o docente en si, dependencia y title. 7.5 Evaluacin de la prueba La prueba superada con xito, se verifico que se hizo la correcta actualizacin de los atributos administrativo si ,docente si y facdocente UNAB TECNOLGICA en LDAP y tambin se verific que se actualiz en SARA en la tabla ACTUALIZACION_CORREO el login eagudel2 y cdula 13746331.

Curso Adoo Uml

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Curso Adoo Uml

Cargado por

Copyright:

Formatos disponibles

ESPECIALIZACIN EN TECNOLOGAS AVANZADAS PARA EL DESARROLLO DE SOFTWARE

ANALISIS Y DISEO ORIENTADO A OBJETOS UNIFIED MODELING LANGUAGE (UML)

Base de datos de inventarios

Base de datos de rdenes Ordenes

Orden tems Direccin de envo Mtodo de pago

Figura 1-2: Objeto Orden

1.6. CARACTERSTICAS PRINCIPALES DE LA PROGRAMACIN ORIENTADA A OBJETOS

Anlisis Diseo Implementacin Pruebas

Figura 3-3: Fases del Ciclo de Desarrollo

Figura 4-1: Mapa del proceso Captura de Requerimientos

Ejemplo: Sistema Acadmico

<<include> > <<extend> >

4.2. ANLISIS DE REQUERIMIENTOS

Camino o flujo bsico

Figura 4-7: Refinacin caso de uso mantenimiento de la informacin de cursos

Figura 4-9. Diagrama de casos de uso de una tienda virtual

Figura 4-10: Notacin del Diagrama de Actividades

Consultar Horario Consulta Cursos

Crear Horario Selecciona Cursos Agregar Cursos

Eliminar Cursos Elimina Cursos Curso Abierto

Figura 4-11: Diagrama de Actividades Caso de Uso Matricular Sistema Acadmico

Figura 4-12: Ejemplo de un Diagrama de Actividades de una mquina dispensadora de bebidas

Figura 4-15: Ejemplo de una relacin de asociacin con multiplicidad

Figura 4-18: Ejemplo de una relacin de composicin

Factura 0..* 1..*

Figura 4-23: Diagrama de objetos escenario de matricula paso 2

Figura 4-24: Diagrama de objetos escenario de matricula paso 3 4.3. DISEO

Figura 4-25: Mapa del proceso Diseo

Figura 4-26: Estereotipos de clases en UML

Figura 4-27: Diagrama de Secuencia Caso de Uso Matricular

describe las relaciones entre objetos.

Figura 4-30: Relaciones entre paquetes

Figura 4-32: Diagrama de clases de diseo

4.3.7. Arquitectura del sistema

Persona Nombre Telefono

Cliente Ide nti fica cio nCliente Preferencias

Figura 4-34: Ejemplo de una relacin de herencia

Persona ID (PK) Nombre Telfono FechaInicio NumeroCliente Preferencias TipoDeObjeto

Figura 4-36: Mapeo de herencia. Una tabla por clase concreta

Velocidad de Acceso de Datos Soporte a Polimorfismo Normalizacin Necesidad de Espacio en la BD

Rpido Media Ninguna Alta

Rpido Baja Media Media

Media/Rpido Alta Total Alta

Figura 4-41: Aplicaciones web de n capas

Figura 4-42: Aplicaciones empresariales de n capas

Figura 4-43: Diagrama de clases de diseo

Gestin de Cuentas Comment

Rutinas de Coneccion Comment

Figura 4-45: Ejemplo de Diagrama de Componentes

Servidor Central Ac ceso a BD Comment

Control y Anlisis Comment

Rutinas de Coneccio n Comment

Terminal de Consulta Rutinas de Coneccio n Comment

Interfaz de Terminal Comment

Rutinas de Coneccio n Comment

Gestin de Cuentas Comment

Interfaz de Terminal Comment

Figura 4-46: Ejemplo de Diagrama de Distribucin

Herencia: El cdigo para la definicin de una subclase B que hereda de A es el siguiente:

4.4.2.2. Atributos El cdigo para definir atributos de una clase es el siguiente:

Figura 4-48: Relacin de asociacin entre clases

Figura 4-49: Relacin de agregacin entre clases

4.4.2.5. Composicin Tomando el mismo ejemplo anterior.

Programa principal o interfaz PruebaAdmStma.java