Ejercicios de UML

Sistema de Cajero Automático

Sistema de Biblioteca

Sistema Restaurant

Sistema de Clinica

Sistema de Inscripción

Sistema de Matricula y Pension

Sistema de Matricula Estudiante

Sistema de Matricula y Pensión

Uso de <<Extends>> y <<Inlcude>>

Sistema de Compañía de Buses

Tipos de Diagramas UML

Diagramas. Vistazo general.

La explicación se basará en los diagramas, en lugar de en vistas o anotación, ya que son estos la esencia de UML. Cada diagrama usa la anotación pertinente y la suma de estos diagramas crean las diferentes vistas. Las vistas existentes en UML son:

Vista casos de uso: Se forma con los diagramas de casos de uso, colaboración, estados y actividades.

Vista de diseño: Se forma con los diagramas de clases, objetos, colaboración, estados y actividades.

Vista de procesos: Se forma con los diagramas de la vista de diseño. Recalcando las clases y objetos referentes a procesos.

Vista de implementación: Se forma con los diagramas de componentes, colaboración, estados y actividades.

Vista de despliegue: Se forma con los diagramas de despligue, interacción, estados y actividades.

Se Dispone de dos tipos diferentes de diagramas los que dan una vista estática del sistema y los que dan una visión dinámica. Los diagramas estaticos son:

Diagrama de clases: muestra las clases, interfaces, colaboraciones y sus relaciones. Son los más comunes y dan una vista estática del proyecto.

Diagrama de objetos: Es un diagrama de instancias de las clases mostradas en el diagrama de clases. Muestra las instancias y como se relacionan entre ellas. Se da una visión de casos reales.

Diagrama de componentes: Muestran la organización de los componentes del sistema. Un componente se corresponde con una o varias clases, interfaces o colaboraciones.

Diagrama de despliegue.: Muestra los nodos y sus relaciones. Un nodo es un conjunto de componentes. Se utiliza para reducir la complejidad de los diagramas de clases y componentes de un gran sistema. Sirve como resumen e índice.

Diagrama de casos de uso: Muestran los casos de uso, actores y sus relaciones. Muestra quien puede hacer que y relaciones existen entre acciones(casos de uso). Son muy importantes para modelar y organizar el comportamiento del sistema.

Lo diagramas dinámicos son:

Diagrama de secuencia, Diagrama de colaboración: Muestran a los diferentes objetos y las relaciones que pueden tener entre ellos, los mensajes que se envían entre ellos. Son dos diagramas diferentes, que se puede pasar de uno a otro sin pérdida de información, pero que nos dan puntos de vista diferentes del sistema. En resumen, cualquiera de los dos es un Diagrama de Interacción.

Diagrama de estados: muestra los estados, eventos, transiciones y actividades de los diferentes objetos. Son útiles en sistemas que reaccionen a eventos.

Diagrama de actividades: Es un caso especial  del diagrama de estados. Muestra el flujo entre los objetos. Se utilizan para modelar el funcionamiento del sistema y el flujo de control entre objetos.

Como podemos ver el número de diagramas es muy alto, en la mayoría de los casos excesivos, y UML permite definir solo los necesarios, ya que no todos son necesarios en todos los proyectos. En el documento se dará una breve explicación de todos, ampliándose para los más necesarios.

Diagramas recomendados.

Los diagramas a representar dependerán del sistema a desarrollar, para ello se efectúan las siguientes recomendaciones dependiendo del sistema. Estas recomendaciones se deberán adaptar a las características de cada desarrollo, y seguramente será la práctica lo que nos diga las cosas que echamos en falta o los diagramas que parecen ser menos necesarios.

Aplicación monopuesto:

Diagrama de casos de uso.

Diagrama de clases.

Diagrama de interacción.

Aplicación monopuesto, con entrada de eventos:

Añadir: Diagrama de estados.

Aplicación cliente servidor:

Añadir: Diagrama de despliegue y diagrama de componentes, dependiendo de la complejidad.

Aplicación compleja distribuida:

Todos.

Así tenemos que para una aplicación sencilla debemos realizar entre tres y seis tipos de diagramas, y para una aplicación compleja unos nueve tipos. ¿Es esto demasiado trabajo? En un principio no lo parece, ya que el tiempo dedicado a la realización de los diagramas es proporcional al tamaño del producto a realizar, no entraremos en la discusión de que el tiempo de diseño no es tiempo perdido si no ganado. Para la mayoría de los casos tendremos suficiente con tres o cuatro diagramas. Debemos pensar que UML está pensado para el modelado tanto de pequeños sistemas como de sistemas complejos, y debemos tener en cuenta que los sistemas complejos pueden estar compuestos por millones de líneas de código y ser realizados por equipos de centenares de programadores. Así que no debemos preocuparnos, el mayor de nuestros proyectos, desde el punto de vista de UML no deja de ser un proyecto mediano tirando a pequeño. 

Diagrama de casos de uso.

Se emplean para visualizar el comportamiento del sistema, una parte de el o de una sola clase. De forma que se pueda conocer como responde esa parte del sistema. El diagrama de uso es muy útil para definir como debería ser el comportamiento de una parte del sistema, ya que solo especifica como deben comportarse y no como están implementadas las partes que define. Por ello es un buen sistema de documentar partes del código que deban ser reutilizables por otros desarrolladores. El diagrama también puede ser utilizado para que los expertos de dominio se comuniquen con los informáticos sin llegar a niveles de complejidad. Un caso de uso especifica un requerimiento funcional, es decir indica esta parte debe hacer esto cuando pase esto.

En el diagrama nos encontramos con diferentes figuras que pueden mantener diversas relaciones entre ellas:

Casos de uso: representado por una elipse, cada caso de uso contiene un nombre, que indique su funcionalidad. Los casos de uso pueden tener relaciones con otro caso de uso. Sus relaciones son:

Include: Representado por una flecha, en el diagrama de ejemplo podemos ver como un caso de uso, el de totalizar el coste incluye a dos casos de uso.

Extends: Una relación de una caso de Uso A hacia un caso de uso B indica que el caso de uso B implementa la funcionalidad del caso de uso A.

Generalization: Es la típica relación de herencia.

Actores: se representan por un muñeco. Sus relaciones son:

Communicates: Comunica un actor con un caso de uso, o con otro actor.

Parte del sistema (System boundary): Representado por un cuadro, identifica las diferentes partes del sistema y contiene los casos de uso que la forman.

En este grafico encontramos tres casos de usos Crear producto utiliza Validar producto, y Crear pack productos es una especialización de Crear productos.

Podemos emplear el diagrama de dos formas diferentes, para modelar el contexto de un sistema, y para modelar los requisitos del sistema.

Modelado del contexto.

Se debe modelar la relación del sistema con los elementos externos, ya que son estos elementos los que forman el contexto del sistema.

Los pasos a seguir son:

Identificar los actores que interactúan con el sistema.

Organizar a los actores.

Especificar sus vías de comunicación con el sistema.

Modelado de requisitos.

La función principal, o la más conocida del diagrama de casos de uso es documentar los requisitos del sistema, o de una parte de él.

Los requisitos establecen un contrato entre el sistema y su exterior, definen lo que se espera que realice el sistema, sin definir su funcionamiento interno. Es el paso siguiente al modelado del contexto, no indica relaciones entre autores, tan solo indica cuales deben ser las funcionalidades (requisitos) del sistema. Se incorporan los casos de uso necesarios que no son visibles desde los usuarios del sistema.

Para modelar los requisitos es recomendable:

Establecer su contexto, para lo que también podemos usar un diagrama de casos de uso.

Identificar las necesidades de los elementos del contexto (Actores).

Nombrar esas necesidades, y darles forma de caso de uso.

Identificar que casos de uso pueden ser especializaciones de otros, o buscar especializaciones comunes para los casos de uso ya encontrados.

Diagrama de clases.

Forma parte de la vista estática del sistema. En el diagrama de clases como ya hemos comentado será donde definiremos las características de cada una de las clases, interfaces, colaboraciones y relaciones de dependencia y generalización. Es decir, es donde daremos rienda suelta a nuestros conocimientos de diseño orientado a objetos, definiendo las clases e implementando las ya típicas relaciones de herencia y agregación.

En el diagrama de clases debemos definir a estas y a sus relaciones.

La Clase.

• Una clase está representada por un rectángulo que dispone de tres apartados, el primero para indicar el nombre, el segundo para los atributos y el tercero para los métodos.
• Cada clase debe tener un nombre único, que las diferencie de las otras.
• Un atributo representa alguna propiedad de la clase que se encuentra en todas las instancias de la clase. Los atributos pueden representarse solo mostrando su nombre, mostrando su nombre y su tipo, e incluso su valor por defecto.
• Un método o operación es la implementación de un servicio de la clase, que muestra un comportamiento común a todos los objetos. En resumen es una función que le indica a las instancias de la clase que hagan algo.
• Para separar las grandes listas de atributos y de métodos se pueden utilizar estereotipos.

Diagrama de objetos.

Forma parte de la vista estática del sistema. En este diagrama se modelan las instancias de las clases del diagrama de clases. Muestra a los objetos y sus relaciones, pero en un momento concreto del sistema. Estos diagramas contienen objetos y enlaces. En los diagramas de objetos también se pueden incorporar clases, para mostrar la clase de la que es un objeto representado.

En este diagrama se muestra un estado del diagrama de eventos. Para realizar el diagrama de objetos primero se debe decidir que situación queremos representar del sistema. Es decir si disponemos de un sistema de mensajería, deberemos decidir que representaremos el sistema con dos mensajes entrantes, los dos para diferentes departamentos, dejando un departamento inactivo. Para el siguiente diagrama de clases:

Diagrama de componentes.

Se utilizan para modelar la vista estática de un sistema. Muestra la organización y las dependencias entre un conjunto de componentes. No es necesario que un diagrama incluya todos los componentes del sistema, normalmente se realizan por partes. Cada diagrama describe un apartado del sistema.

En el situaremos librerías, tablas archivos, ejecutables y documentos que formen parte del sistema.

Uno de los usos principales es que puede servir para ver que componentes pueden compartirse entre sistemas o entre diferentes partes de un sistema.

Aquí tenemos un componente del sistema de Windows. En el diagrama de componentes de Windows debe salir este componente, ya que sin el  sistema no funcionaría.

En esta otra figura tenemos el mismo componente, pero indicamos que dispone de un interface. Al ser una Dll el interface nos da acceso a su contenido. Esto nos hace pensar que la representación anterior es incorrecta, pero no es así solo corresponde a un nivel diferente de detalle.

Como ya hemos indicado antes todo objeto UML puede ser modificado mediante estereotipos, los standard que define UML son:

• Executable
• Library
• Table
• File
• Document. 

Aunque por suerte no estamos limitados a estas especificaciones. Que pasa si queremos modelar un proyecto de Internet donde nuestros componentes son ASP, HTML, y Scripts, y queremos marcarlo en el modelo. Pues utilizamos un estereotipo. Existe ya unos definidos WAE (Web Applications Extensión).

Podemos modelar diferentes partes de nuestro sistema, y modelar diferentes entidades que no tiene nada que ver entre ellas.

• Ejecutables y bibliotecas.
• Tablas.
• API
• Código fuente.
• Hojas HTML.

Diagramas de despliegue.

En el diagrama de despliegue se indica la situación física de los componentes lógicos desarrollados. Es decir se sitúa el software en el hardware que lo contiene. Cada Hardware se representa como un nodo.

Un nodo se representa como un cubo, un nodo es un elemento donde se ejecutan los componentes, representan el despliegue físico de estos componentes.

Aquí tenemos dos nodos, el cliente y el servidor, cada uno de ellos contiene componentes. El componente del cliente utiliza un interface de uno de los componentes del servidor. Se muestra la relación existente entre los dos Nodos. Esta relación podríamos asociarle un estereotipo para indicar que tipo de conexión disponemos entre el cliente y el servidor, así como modificar su cardinalidad, para indicar que soportamos diversos clientes.

Diagrama Secuencia.

El diagrama de secuencia forma parte del modelado dinámico del sistema. Se modelan las llamadas entre clases desde un punto concreto del sistema. Es útil para observar la vida de los objetos en sistema, identificar llamadas a realizar o posibles errores del modelado estático, que imposibiliten el flujo de información o de llamadas entre los componentes del sistema.

En el diagrama de secuencia se muestra el orden de las llamadas en el sistema. Se utiliza un diagrama para cada llamada a representar. Es imposible representar en un solo diagrama de secuencia todas las secuencias posibles del sistema, por ello se escoge un punto de partida. El diagrama se forma con los objetos que forman parte de la secuencia, estos se sitúan en la parte superior de la pantalla, normalmente en la izquierda se sitúa al que inicia la acción. De estos objetos sale una línea que indica su vida en el sistema. Esta línea simple se convierte en una línea gruesa cuando representa que el objeto tiene el foco del sistema, es decir cuando el esta activo.

Introducción a UML

UML

Introducción a UML

Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.

Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.

Se puede aplicar en el desarrollo de software gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar.

UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, sin embargo, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos.

UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas.

Unified Modeling Languaje

UML [UML] es un lenguaje para especificar, construir, visualizar y documentar los artefactos de un sistema de software orientado a objetos (OO). Un artefacto es una información que es utilizada o producida mediante un proceso de desarrollo de software.

UML se quiere convertir en un lenguaje estándar con el que sea posible modelar todos los componentes del proceso de desarrollo de aplicaciones. Sin embargo, hay que tener en cuenta un aspecto importante del modelo: no pretende definir un modelo estándar de desarrollo, sino únicamente un lenguaje de modelado. Otros métodos de modelaje como OMT (Object Modeling Technique) o Booch sí definen procesos concretos. En UML los procesos de desarrollo son diferentes según los distintos dominios de trabajo; no puede ser el mismo el proceso para crear una aplicación en tiempo real, que el proceso de desarrollo de una aplicación orientada a gestión, por poner un ejemplo.

Las diferencias son muy marcadas y afectan a todas las faces del proceso. El método del UML recomienda utilizar los procesos que otras metodologías tienen definidos.

Los Inicios

A partir del año 1994, Grady Booch [Booch96](precursor de Booch '93) y Jim Rumbaugh (creador de OMT) se unen en una empresa común, Rational Software Corporation, y comienzan a unificar sus dos métodos. Un año más tarde, en octubre de 1995, aparece UML (Unified Modeling Language) 0.8, la que se considera como la primera versión del UML. A finales de ese mismo año, Ivan Jacobson, creador de OOSE (Object Oriented Software Engineer) se añade al grupo.

Como objetivos principales de la consecución de un nuevo método que aunara los mejores aspectos de sus predecesores, sus protagonistas se propusieron lo siguiente:

El método debía ser capaz de modelar no sólo sistemas de software sino otro tipo de sistemas reales de la empresa, siempre utilizando los conceptos de la orientación a objetos (OO).

Crear un lenguaje para modelado utilizable a la vez por máquinas y por personas.

Establecer un acoplamiento explícito de los conceptos y los artefactos ejecutables.

Manejar los problemas típicos de los sistemas complejos de misión crítica.

Lo que se intenta es lograr con esto que los lenguajes que se aplican siguiendo los métodos más utilizados sigan evolucionando en conjunto y no por separado. Y además, unificar las perspectivas entre diferentes tipos de sistemas (no sólo software, sino también en el ámbito de los negocios), al aclarar las fases de desarrollo, los requerimientos de análisis, el diseño, la implementación y los conceptos internos de la OO.

Ciclo de Vida de un Sistema Informático

El Ciclo De Vida De Un Sistema Informático  

Son los pasos a seguir desde que se comienza con la necesidad de un sistema hasta que el mismo es sustituido.

FASES

Fase I - Requerimientos

Fase II - Análisis / Diseño

Fase III - Construcción

Fase IV - Pruebas

Fase V - Producción / Mantenimiento

• Fase I – Requerimientos

Esta fase fundamental para que la estrategia informática encaje dentro de las metas de la empresa, ya que en ella se cumplen las funciones del modelaje del negocio y planificación de sistemas; esto con el fin de proyectar las estrategias del negocio y determinar de esta forma sus requerimientos de información.

Durante esta fase se desarrolla un modelo del área estudiada, donde se representa: Los procesos que se llevan a cabo, la información utilizada por ellos y las reglas políticas y prácticas de la empresa relacionada con estos procesos.

Este modelo permite proyectar las estrategias, procesos y flujos de datos de la empresa al igual que las interrelaciones entre procesos y datos, con el fin de desarrollar un plan de sistema de información capaz de guiar el desarrollo de un sistema que permita dar soporte al área en estudio en el cumplimiento de sus objetivos.

El Plan de Sistemas debe contener:

• Los sistemas que requiere el área del negocio, así como sus bases de datos y la información que intercambiaran o compartieran.
• Descripción detallada de cada sistema y aplicación incluyendo sus objetivos funcionales y sus bases de diseño.
• Todo hardware y software que serán utilizados para el funcionamiento requeridos por el área de negocio (incluyendo las redes).
• Métodos de desarrollo para cada sistema como lo es adquisición de paquetes, nuevo desarrollo o actualizaciones.
•  Esquema de los problemas actuales del área de negocio y de las posibles mejoras que se puedan realizar en cada sistema.
• Análisis de los beneficios que se espera derivar de los sistemas que conforman la arquitectura

El plan de sistemas de información es uno de los factores más importantes para el departamento de informática o sistemas ya que constituye la guía para emprender los proyectos que requiera el cliente, reclutar y adiestrar al personal necesario y la adquisición e instalación de hardware y software necesarios.  

• Fase II - Análisis / Diseño

El objetivo de esta fase es desarrollar el diseño arquitectónico de los sistemas, utilizando los requerimientos obtenidos en la primera fase. En el diseño arquitectónico se engloban dos componentes: los datos y los procesos, los cuales serán analizados y diseñados desde una perspectiva conceptual a una física, dentro de las cuatros actividades que se encuentran en esta fase.

• Actividades dentro de la fase de Análisis/Diseño.
• Analizar y Diseñar Proceso: Las operaciones del negocio y los requerimientos de funcionamiento definidos en la primera fase, se toman en cuenta con el propósito de determinar la forma en que debe funcionar el sistema.
• Analizar y Diseñar Los Datos: Con los requerimientos de información definidos en la fase I se debe organizar los distintos modelos de datos que nos ayuden a diseñar la base de datos que hagan falta para que el sistema funcione de acuerdo al modelo de funcionamiento.
• Diseñar y Organizar Los Componentes Físicos: Todo componente físico como (pantallas, base de datos) que hagan posible el funcionamiento del sistema de acuerdo al modelo de funcionamiento.
• Planificar El Desarrollo De Los Componentes Físicos: actividad en la cual planificamos la forma en que pueden ser construidos e implementados los componentes físicos de una forma rápida y productiva.

En esta fase de análisis / diseño puede incluirse una sub.-fase de evaluación de paquetes. Esta se pudiese realizar si en los requerimientos se estableció adquirir un paquete de aplicaciones en lugar de completar un diseño arquitectónico.

• Fase III – Construcción

Dentro de esta fase de construcción existen actividades separadas en cinco sub.-fases:

 ü    DESARROLLO DE INFRAESTRUCTURA

Durante esta fase se desarrollará y organizará la infraestructura que permita cumplir las tareas de construcción en la forma más productiva posible.

ü ADAPTACIÓN DE PAQUETE

Uno de los objetivos centrales de esta subfase es conocer al máximo detalle posible el funcionamiento del paquete, este asegurará que el paquete será utilizado con el máximo provecho, tanto desde el punto de vista del negocio, como de la utilización de recursos. Cada componente del paquete será revisado en forma exhaustiva por el equipo Analista – Usuario, con el fin de conocer y comprender todos los aspectos del paquete.

ü  DESARROLLO DE UNIDADES DE DISEÑO INTERACTIVAS

Las unidades de diseño interactivas, son procedimientos que se cumple o se ejecutan a través de un dialogo usuario – sistema.
Las actividades de esta subfase tienen como objetivo central:

• Especificar en detalle las tareas que debe cumplir la unidad de diseño.
• Desarrollar componentes.
• Realizar las pruebas unitarias y las pruebas de integración a nivel de la unidad de diseño.

 ü DESARROLLO DE UNIDADES DE DISEÑO BATCH

En esta sub.-fase se preparan especificaciones hechas utilizando una combinación de técnicas como flujo gramas, diagramas de estructuras, tablas de decisiones etc. Cualquiera que se utilice será útil para que la especificación sea clara y se logre el propósito de que el programador comprenda y pueda programar y probar los programas correspondientes.

ü DESARROLLO DE UNIDADES DE DISEÑO MANUALES

Las actividades de esta subfase tienen como objetivo central desarrollar todos los procedimientos administrativos que rodearán y gobernarán la utilización de los componentes computarizados desarrollados en la fase de diseño detallado y construcción.

• Fase IV – Pruebas

Esta fase, da inicio luego de que las diferentes unidades de diseño han sido desarrolladas y probadas por separado. Durante su desarrollo, el sistema se emplea de forma experimental para asegurar que el software no falle, es decir que funcione de acuerdo a sus especificaciones y a la manera que los usuarios esperan que lo haga, y de esta forma poder detectar cualquier anomalía, antes de que el sistema sea puesto en marcha y se dependa de él. Para evaluar el desenvolvimiento del sistema, en esta fase se llevan a cabo varios niveles de prueba:

· Funcional: Prueba desde el punto de vista de los requerimientos funcionales.

·De Sistema: Prueba desde el punto de vista de los niveles de calidad del sistema y de desempeño.

·De Integración: Prueba de interfaces.

·De Aceptación Técnica: Prueba de manejo de condiciones extremas.

Si el Sistema cumple de forma satisfactoria con estos niveles mencionados anteriormente, se procede a realizar la carga de los archivos, base de datos y tablas del nuevo sistema, para de esta forma dar inicio al proceso de aceptación final, durante el cual, el sistema comenzará a funcionar bajo la responsabilidad del departamento de operaciones y del usuario, por un lapso determinado de tiempo llamado Periodo de Aceptación.

Finalizado el Periodo de Aceptación, se le dará al sistema la aprobación final, para que pase a ser el sistema oficial.

• Fase V - Producción / Mantenimiento

“Una vez que un sistema pasa a formar parte de la vida diaria de la empresa, cada programa, cada procedimiento y cada estructura de datos se convierte en una pieza del negocio que, como tal, deberá funcionar en forma constante, exacta y confiable. L a operación del negocio ahora dependerá del funcionamiento del sistema, por lo que las tareas de mantenimiento cobran vital importancia.

Durante la fase de mantenimiento, se ponen en práctica todas las políticas y los procedimientos destinados a garantizar la operación continúan de los de los sistemas y a asegurar su uso efectivo, con el fin, de que éstos se constituyan en una verdadera herramienta de apoyo al logro de los objetivos estratégicos de la empresa