Tipos de Diagramas UML

Diagramas de Casos de Uso


Los Casos de Uso no forma parte de la llamada Fase de Diseño, sino parte de la fase de Análisis, respondiendo el interrogante ¿Qué?. De forma que al ser parte del análisis ayuda a describir que es lo que el sistema debe hacer.

Estos diagramas muestran operaciones que se esperan de una aplicación o sistema y como se relaciona con su entorno, es por ello que se ve desde el punto de vista del usuario. Describen un uso del sistema y como éste interactúa con el usuario.

Los casos de usos se representan en el diagrama por una elipses la cual denota un requerimiento solucionado por el sistema.
El conjunto de casos de usos representa la totalidad de operaciones que va a desarrollar el sistema. Por último a estos elipses lo acompaña un nombre significativo de manera de rótulo.

Otro elemento fundamental de estos diagramas son los actores la cual representa a un usuario del sistema, que necesita o interactúa con algún caso de uso, la que también es acompañado por un nombre.Por último tenemos los flujos de eventos que corresponde a la ejecución normal y exitosa del caso de uso.

Diagrama de Clases

En UML el diagrama de clases es uno de los tipos de diagramas o símbolo estático y tiene como fin describir la estructura de un sistema mostrando sus clases, atributos y relaciones entre ellos.

Estos diagramas son utilizados durante el proceso de análisis y diseño de los sistemas informáticos, en donde se intentan conformar el diagrama conceptual de la información que se manejará en el sistema.

Como ya sabemos UML es un modelado de sistema Orientados a Objetos, por ende los conceptos de este paradigma se incorporan a este lenguaje de modelado.

Los diagramas de clases tiene las siguientes características:

• Las clases define el ámbito de definición de un conjunto de objetos.
• Cada objeto pertenece a una clase.
• Los objetos se crean por instanciación de las clases.

Diagramas de Objetos

Forma parte de la vista estática del sistema. En este diagrama se modelan las instancias de la clases del Diagrama de Clases. Este diagrama cabe aclarar que cuenta con objetos y enlaces. En estos diagramas también es posible encontrar las clases para tomar como referencia su instanciación.

En otras palabras el Diagrama de Objetos muestra un conjunto de objetos y sus relaciones en un momento concreto.Los Diagramas de Objetos son realmente útiles para modelar estructuras de datos complejas

Diagramas de Comportamiento

Diagramas de Estados

Un estado es una condición durante la vida de un objeto, de forma que cuando dicha condición se satisface se lleva a cabo alguna acción o se espera por un evento.
 El estado de un objeto se puede caracterizar por el valor de uno o varios de los atributos de su clase, además, el estado de un objeto también se puede caracterizar por la existencia de un enlace con otro objeto.


El diagrama de estados engloba todos los mensajes que un objeto puede enviar o recibir, en otras palabras es un escenario que representa un camino dentro de un diagrama.

Como característica de estos diagramas siempre cuentan con dos estados especiales, el inicial y el final, con la particularidad que este diagrama puede tener solo un estado inicial pero varios estados finales.

Una transición entre estados representa un cambio de un estado origen a un estado sucesor destino que podría ser el mismo que el estado origen, dicho cambio de estado puede estar aparejado con alguna acción. Además las acciones se asocian a las transiciones y se consideran que ocurre de forma rápida e ininterrumpible.

Los elementos que componen estos diagramas son:

• Círculo lleno, apuntando el estado inicial.
• Círculo hueco que contiene un círculo lleno más pequeño en el interior, indicando el estado final.
• Rectángulo redondeado dividido por una línea horizontal, indicado los estados, en la parte de arriba se encuentra el nombre del estado y abajo se indica la actividad que realiza.
• Flecha, la cual denota la transición, el nombre del evento que causa esta transición etiqueta el cuerpo de la flecha.

Diagramas de Actividad

Un Diagrama de Actividades representa un flujo de trabajo paso a paso de negocio y operacionales de los componentes en un sistema.

En UML 1, un diagrama de actividades es una variación del Diagrama de Estados UML donde los estados representan operaciones y las transiciones representan las actividades que ocurren cuando la operación es completa.


En la actualidad, el diagrama de actividades en UML 2.0 es similar al aspecto del diagrama en UML 1, solo que ahora la semántica esta basada en lo que se conoce como Redes de Petri. En UML 2.0, el diagrama general de interacción está basado en el diagrama de Actividad.


Componentes:

• Inicio: el inicio de un diagrama de actividades es representado por un círculo de color negro sólido.
• Actividad: Una actividad representa la acción que será realizada por el sistema la cual representa dentro de un óvalo.
• Transición: Una transición ocurre cuando se lleva acabo el cambio de una actividad a otra, la transición es representada simplemente por una línea con una flecha en su terminación para indicar su dirección.

Diagramas de Interacción

Diagrama de Secuencia

Un Diagrama de Secuencias muestra una interacción ordenada según la secuencia temporal de eventos y el intercambio de mensajes. Los diagramas diagramas de secuencia ponen especial énfasis en el orden y el momento en el que se envían los mensajes a los objetos.

En los diagramas de Secuencias los elementos están representados por líneas intermitentes verticales, con el nombre del objeto en la parte más alta.

Los mensajes pueden ser o bien síncronos, el tipo normal de llamada del mensaje donde se pasa el control a objeto llamado hasta que el método finalize, o asíncronos donde se devuelve el control directamente al objeto que realiza la llamada.

Los mensajes síncronos tienen una caja vertical en un lateral del objeto invocante que muestra el flujo del control del programa


Diagrama de Colaboración

Un diagrama de colaboración, se puede decir que es una forma alternativa al diagrama de secuencias a la hora de mostrar un escenario.
Este tipo de diagrama muestra las interacciones que ocurren entre los objetos que participan en una situación determinada.
A diferencia del diagrama de secuencia, el diagrama de colaboración se enfoca en la relación entre los objetos y su topología de comunicación.

En estos diagramas los mensajes enviados de un objeto a otro se representa mediante flechas, acompañado del nombre del mensaje, los parámetros y la secuencia del mensaje.

Estos diagramas están indicados para mostrar una situación o flujo de programa específico y son considerados uno de los mejores diagramas para mostrar o explicar rápidamente un proceso dentro de la lógica del programa

Diagrama de Implementación

Diagrama de componentes

Lo que distingue el Diagrama de Componentes de otro tipo de diagramas es sin duda su contenido. Normalmente contiene componentes, interfaces y relaciones entre ellos.Los componentes perteneces a un mundo físico, es decir, representan a un bloque de construcción al modelar aspectos físicos de un sistema.

Cada componente debe tener un nombre que lo distinga de los demás. Al igual que las clases los componentes pueden enriquecerse con compartimientos adicionales que muestran sus detalles.

Diagrama de Despliegue

Básicamente este tipo de diagrama se utiliza para modelar el Hardware utilizado en la implementación del sistema y la relaciones entre sus componentes.

Los elementos usados por este tipo de diagrama son nodos, componentes y asociaciones. En el UML 2.0 los componentes ya no están dentro de nodos, en cambio puede haber artefactos (archivo, un programa, una biblioteca o Base de datos) u otros nodos dentro de nodos.

Además los Diagramas de Despliegue muestran la configuración en funcionamiento del sistema incluyendo su software y su hardware. Para cada componente de un diagrama es necesario que se deba documentar las características técnicas requeridas, el trafico de red, el tiempo de respuesta, etc.

UML (Lenguaje Unificado de Modelado UML)

Definición

El Lenguaje Unificado de Modelado preescribe un conjunto de notaciones y diagramas estándar para modelar sistemas orientados a objetos, y describe la semántica esencial de lo que estos diagramas y símbolos significan.

Mientras que ha habido muchas notaciones y métodos usados para el diseño orientado a objetos, ahora los modeladores sólo tienen que aprender una única notación.

UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de hardware, y organizaciones del mundo real. UML ofrece nueve diagramas en los cuales modelar sistemas.

• Diagramas de Casos de Uso para modelar los procesos 'business'.
• Diagramas de Secuencia para modelar el paso de mensajes entre objetos.
• Diagramas de Colaboración para modelar interacciones entre objetos.
• Diagramas de Estado para modelar el comportamiento de los objetos en el sistema.
• Diagramas de Actividad para modelar el comportamiento de los Casos de Uso, objetos u operaciones.
• Diagramas de Clases para modelar la estructura estática de las clases en el sistema.
• Diagramas de Objetos para modelar la estructura estática de los objetos en el sistema.
• Diagramas de Componentes para modelar componentes.
• Diagramas de Implementación para modelar la distribución del sistema.

UML es una consolidación de muchas de las notaciones y conceptos más usadas orientados a objetos.

Historia e inicios

Empezó como una consolidación del trabajo de Grade Booch, James Rumbaugh, e Ivar Jacobson, creadores de tres de las metodologías orientadas a objetos más populares.

En 1996, el Object Management Group (OMG), un pilar estándar para la comunidad del diseño orientado a objetos, publicó una petición con propósito de un metamodelo orientado a objetos de semántica y notación estándares.

UML, en su versión 1.0, fue propuesto como una respuesta a esta petición en enero de 1997. Hubo otras cinco propuestas rivales.

Durante el transcurso de 1997, los seis promotores de las propuestas, unieron su trabajo y presentaron al OMG un documento revisado de UML, llamado UML versión 1.1. Este documento fue aprobado por el OMG en Noviembre de 1997.

El OMG llama a este documento OMG UML versión 1.1. El OMG está actualmente en proceso de mejorar una edición técnica de esta especificación, prevista su finalización para el 1 de abril de 1999.

Caracteristicas

 UML es el resultado de la evolución de los métodos Booch, OMT, OOSE, varios métodos orientado a objetos y muchas otras fuentes.

Los autores de UML eliminaron elementos de los métodos Booch, OMT y OOSE que no eran útiles en la práctica, agregaron elementos de otros métodos que eran más efectivos e inventaron nuevos sólo cuando la solución no estaba disponible, por esta razón su uso no es complejo.

Hay varios conceptos nuevos que están incluidos en UML, incluyendo los mecanismos de extensibilidad: estereotipos, valores etiquetados, restricciones, hilos y procesos, distribución y concurrencia, modelos/ colaboraciones, diagramas de actividad, refinamiento, interfases y componentes, y un lenguaje de restricción.

UML unificó las ideas anteriores de una manera coherente, lo que permitió realizar mejoras a las semánticas y anotación de los métodos Booch, OMT y OOSE.

La anotación de UML es el resultado de la fusión de la sintaxis gráfica de varias fuentes, con un número de símbolos eliminados y unos pocos agregados.

Los diagramas de caso de uso son similares en apariencia a los del método OOSE.

Los diagramas de clase son el resultado de la fusión de los métodos OMT, Booch, entre otros. Las extensiones pueden ser definidas por varios diagramas para soportar otros estilos de modelamiento, y los estereotipos, restricciones y valores etiquetados son conceptos agregados en UML.

Los diagramas de actividad son similares a los diagramas de flujo de trabajo desarrollados por muchas fuentes.

Los diagramas de secuencia fueron encontrados en una variedad de métodos OO bajo una variedad de nombres.

Los diagramas de colaboración fueron adaptados de los métodos Booch, Fusion y muchas otras fuentes.

Las colaboraciones son entidades de modelamiento de primera clase que a menudo forman la base de modelos.

Los diagramas de implementación son derivados del módulo Booch y los diagramas de proceso.

Objetivos Principales

Hubo varios objetivos detrás del desarrollo de UML. El primero y mas importante, UML es un lenguaje de modelado de propósito general que pueden usar todos los modeladores.

No tiene propietario y esta basado en el común acuerdo de gran parte de la comunidad informática.
Esto significa incluir conceptos de los métodos líderes para que UML pueda usarse como su lenguaje de modelado.

UML no pretende ser un método de desarrollo completo. No incluye un proceso de desarrollo paso a paso.

Un objetivo final de UML era ser tan simple como fuera posible pero manteniendo la capacidad de modelar toda la gama de sistemas que se necesita construir.

UML necesita ser lo suficientemente expresivo para manejar todos los conceptos que se originan en un sistema moderno, tales como la concurrencia y distribución, así como también los mecanismos de la ingeniería de software, tales como encapsulacion y componentes.

Debe ser un lenguaje universal, como cualquier lenguaje de programación de propósito general.

Modelos de ciclo de vida

Modelo en Cascada

 

El más conocido, esta basado en el ciclo convencional de una ingeniería, el paradigma del ciclo de vida abarca las siguientes actividades

Ingeniería y Análisis del Sistema: Debido a que el software es siempre parte de un sistema mayor el trabajo comienza estableciendo los requisitos de todos los elementos del sistema y luego asignando algún subconjunto de estos requisitos al software.

Análisis de los requisitos del software: el proceso de recopilación de los requisitos se centra e intensifica especialmente en el software. El ingeniero de software (Analistas) debe comprender el ámbito de la información del software, así como la función, el rendimiento y las interfaces requeridas.

Diseño: el diseño del software se enfoca en cuatro atributos distintos del programa: la estructura de los datos, la arquitectura del software, el detalle procedimental y la caracterización de la interfaz. El proceso de diseño traduce los requisitos en una representación del software con la calidad requerida antes de que comience la codificación.

Codificación: el diseño debe traducirse en una forma legible para la maquina. El paso de codificación realiza esta tarea. Si el diseño se realiza de una manera detallada la codificación puede realizarse mecánicamente.

Prueba: una vez que se ha generado el código comienza la prueba del programa. La prueba se centra en la lógica interna del software, y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren.

Mantenimiento: el software sufrirá cambios después de que se entrega al cliente. Los cambios ocurrirán debido a que hayan encontrado errores, a que el software deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos periféricos), o debido a que el cliente requiera ampliaciones funcionales o del rendimiento.

Desventajas:

• Los proyectos reales raramente siguen el flujo secuencial que propone el modelo, siempre hay iteraciones y se crean problemas en la aplicación del paradigma.
  
 
• Normalmente, es difícil para el cliente establecer explícitamente al principio  todos los requisitos. El ciclo de vida clásico lo requiere y tiene dificultades en acomodar posibles incertidumbres que pueden existir al comienzo de muchos productos.
  

• El cliente debe tener paciencia. Hasta llegar a las etapas finales del proyecto, no estará disponible una versión operativa del programa. Un error importante no detectado hasta que el programa este funcionando puede ser desastroso.

            La ventaja de este método radica en su sencillez ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el software.

 

 

Modelo V


El Modelo V tiende a ser muy relacionado con el Modelo de Cascada puesto que es una evolución del mismo.

Puede notarse que su primera mitad es similar al Modelo en Cascada, y la otra mitad tiene como finalidad hacer pruebas e integración asociado a cada una de las etapas de la mitad anterior.


Se puede identificar una ventaja principal con respecto al Modelo Cascada más simple, y se refiere a que este modelo involucra chequeos de cada una de las etapas del modelo de cascada.

Desventajas:

• El riesgo es mayor que el de otros modelos, pues en lugar de hacer pruebas de aceptación al final de cada etapa, las pruebas comienzan a efectuarse luego de haber terminado la implementación, lo que puede traer como consecuencia un “roll-back” de todo un proceso que costó tiempo y dinero.
 
• El modelo no contempla la posibilidad de retornar a etapas inmediatamente anteriores, cosa que en la realidad puede ocurrir.
 
• Se toma toda la complejidad del problema de una vez y no en iteraciones o ciclos de desarrollo, lo que disminuye el riesgo.
 
 

            A pesar de todo lo antes mencionado, definitivamente se trata de un modelo más robusto y completo que el Modelo de Cascada, y puede producir software de mayor calidad que con el modelo de cascada.

Ciclo de vida de un sistema de información

  

Definición

El ciclo de vida es el período de tiempo que "vive" un sistema informático desde que es pensado hasta que es desechado.

El ciclo de vida de desarrollo de sistemas informáticos puede dividirse en actividades o fases que, en general, se ajustan al esquema mostrado en el gráfico. Este esquema gráfico es el ciclo de vida típico, dado que existen gran cantidad de variantes que dependen de la organización, del tipo de sistema que se realizará, de los gustos de los administradores, de los tiempos, etc.

 Fases

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

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 practicas 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 area 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 area 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 deacuerdo 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 el.
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.

La 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úa 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