UML

1) Qué es UML?

El Lenguaje Unificado de Modelado (Unifield Modeling Lenguaje UML), es un lenguaje estándar para escribir planos de software, UML se puede utilizar para visualizar, especificar, construir y documentar los artefactos de un sistema que involucra una gran cantidad de software. UML prescribe 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.

UML se puede usar para modelar distintos tipos de sistemas como por ejemplo: sistemas de software, sistemas de hardware, y organizaciones del mundo real. UML ofrece nueve diagramas en los cuales modelar sistemas. Es un lenguaje muy expresivo,  que  cubre  todas  las  vistas  necesarias  para  desarrollar  y  luego desplegar tales sistemas.

UML es sólo un lenguaje y por tanto es tan solo una parte de un método de desarrollo  de  software,  además,  es  independiente  del  proceso,  aunque  para utilizar óptimamente se debería usar en procesos que fuesen dirigidos por los casos de uso, centrados en la arquitectura, lo interactivo e incremental.

2) Por qué es necesario UML?

Los programadores en los inicios de los sistemas de computación no realizaban análisis fuertes o profundos sobre u problema a resolver,  eventualmente realizaban un bosquejo o medianamente un diagrama con poca técnica donde se daba a entender una idea mínima de lo que  pensaban realizar en el proceso de programación. A los programadores se podrían considerar como temerarios en el desarrollo de aplicaciones, ya que  estás se está ajustando según los requerimientos del momento, significando un alto riesgo para las empresas o entidades donde se realice los proyectos. En la actualidad este procedimiento se considera un problema de alto riesgo para los negocios.

Por tal razón los sistemas de información en la actualidad parten de un análisis y diseño muy bien evaluado, donde el cliente reconozca y entienda a detalle lo que el grupo de programadores realizará y que este pueda sugerir cambios que permitan cumplir con las necesidades o cambiar de opinión frente a un proceso y aplicarlo de otra manera en el sistema,  una vez el diseño sea claro y que sea de completo consentimiento del cliente, el grupo de trabajo procederá a desarrollar la solución tal cual como se diseñó.

Es por ello que si desea crear un sistema en la actualidad, se deberá partir con la pregunta: ¿Cómo se manejara un nivel tan alto de complejidad?

UML es la respuesta, pues mediante este lenguaje se organizará el proceso de diseño donde los analistas, clientes, desarrolladores y todo el equipo de trabajo que intervenga en el proyecto, comprenderán  y participará en la mejor solución al problema presentado, enfrentando la complejidad que se presente y se resuelva de una manera organizada. Por ejemplo: un carro, un avión un edificio, parten de un diseño (Dibujo) muy detallado y  aunque estos resultados se evidencian de forma tangible, no significa que un sistema de información que es intangible no cuente con su propio diseño, por el contrario, si dicho sistema cuenta con una buena planificación en su diseño, obtendrá un excelente resultado para el usuario final.

También es importante tener claro, que un sistema de información que cuente con un buen diseño (dibujo), permitirá realizar fácilmente futuras modificaciones de manera puntual y precisa, ahorrando tiempo y dinero en el proceso de actualización en la programación de una solución anteriormente diseñada.

VERSIONES DE UML

UML 1.X (comprende UML 1.1, 1.2, 1.3, 1.4, 1.5): desde finales de los 90 se empezó a trabajar con el estándar UML. En los años sucesivos fueron apareciendo nuevas versiones que introducían mejoras o ampliaban a las anteriores.

UML 2.X (comprende UML 2.1 hasta UML 2.5, 2.6, etc.): en torno a 2005 se difundió una nueva versión de UML a la que podemos denominar UML 2.X. Comprenden varias revisiones.

UML 3.X: evolución que se espera para UML 2.X.

Uml 0.8
la versión0.8 del método unificado. Fue lanzado para OOPSLA (octubre) de 1995.fue
llamado el"Método Unificado" y fue obra de Boochy Rumbaugh.

Uml 0.9
En 1996 publicado un 0.9 y una versión 0.91que incluye el trabajo de Jacobson. esta
vez que se cambió el nombre a UML.

Uml 1.0
La versión 1.0 del UML fue sometido al análisis y OMG diseño en 1997.

En UML1.0, el término rol principalmente indica una dirección de una asociación

UML 1.1 tiene dos relaciones de casos de uso: «uses» y «extends», tanto de que son los estereotipos de la generalización.

UML1.1 se refiere a este uso como un extremo de la asociación.
También hay un papel colaboración, que es un papel que una instancia de una clase juega en una colaboración. Muchas personas siguen utilizando el término rolde
significaría una dirección de una asociación, aunque extremo de la asociación es la oficial.

Uml 1.2
La versión 1.2 en julio de 1998. Este comunicado fue interno que uml 1,1 se mantuvo la norma oficial UML. Usted podría pensar en la versión 1.2 como una versión beta. En la práctica, esta distinción difícilmente importaba como los únicos cambios en la norma fueron editorial: fijación errores tipográficos, errores gramaticales y similares.
1995
1996
1997
1998
1998
2005

Uml 1.3
Un cambio más importante se produjo con la versión 1.3, sobre todo afectando los casos de uso y diagramas de actividad. Guía del usuario Los amigos y el manual de referencia se publicaron a finales de 1998 con el 1.3 cambios, ante los 1,3 documentos oficiales se hicieron públicos, que causado cierta confusión.
Casos de uso Los cambios en el uso de los casos implican nuevas relaciones entre casos de uso.

UML 2.0, esta asunción cambió de manera drástica y se modificó el lenguaje, de manera tal que permitiera capturar mucho más comportamiento (Behavior). De esta forma, se permitió la creación de herramientas que soporten la automatización y generación de código ejecutable, a partir de modelos UML.

Uml 2.0
Desarrollada en 2005 Al momento de desarrollar el nuevo estándar 2.0 de UML, la OMG se planteó, entre otros, dos objetivos que podríamos considerar principales, debido a la influencia de éstos en la nueva versión del estándar: 

1.Hacer el lenguaje de modelado más extensible. 
2.permitir la validación y ejecución de modelos

En las versiones previas del UML, se hacía un fuerte hincapié en que UML no era un lenguaje de programación. Un modelo creado mediante UML no podía ejecutarse. En el UML 2.0, esta asunción cambió de manera drástica y se modificó el lenguaje, de manera tal que permitiera capturar mucho más comportamiento (Behavior). De esta forma, se permitió la creación de herramientas que soporten la automatización y generación de código ejecutable, a partir de modelos UML.

VERSIONES FORMALES DE UML

VERSIÓN ACTUAL DE UML

UML 2.5.1

Descripción: Una especificación que define un lenguaje gráfico para visualizar, especificar, construir y documentar los artefactos de los sistemas de objetos distribuidos.

TIPOS DE DIAGRAMAS EN UML

Diagramas de casos de uso: representan a los actores y casos de uso (procesos principales) que intervienen en un desarrollo de software.

Diagramas de clases:para UML una clase es una entidad, no una clase software. Un diagrama de clases UML puede ser un diagrama del dominio o representación de conceptos que intervienen en un problema, o también un diagrama de clases software. El sentido de un diagrama UML se lo da la persona que lo construye.

Diagramas de secuencia:suelen usarse para representar objetos software y el intercambio de mensajes entre ellos, representando la aparición de nuevos objetos de izquierda a derecha.

Diagramas de colaboración:suelen usarse para representar objetos o clases y la forma en que se transmiten mensajes y colaboran entre ellos para cumplir un objetivo.

Diagramas de estados:suelen usarse para representar cómo evoluciona un sistema (cómo va cambiando de estado) a medida que se producen determinados eventos.

Otros diagramas:diagramas de actividad, diagramas de paquetes, diagramas de arquitectura software, etc.

Diagramas Estructurales 

Los diagramas estructurales presentan elementos estáticos del modelo, tales como clases, paquetes o componentes; en tanto que los diagramas de comportamiento muestran la conducta en tiempo de ejecución del sistema, tanto visto como un todo como de las instancias u objetos que lo integran.

Por otra parte, en la figura se ve que hay tres tipos de diagramas señalados en un color distinto: los diagramas de estructura compuesta, de tiempo y de resumen de interacción. Se han resaltado dado que son nuevos dentro del UML por lo que resultan ser de los menos conocidos. También aspiro a tener una descripción de ellos en los días por venir.

Comentario: Es un diagrama para clasificar un determinado tema en sus partes principales.

Diagrama de Estructura Compuesta: nuevo en UML2, este diagrama muestra la estructura INTERNA de un elemento o clase.

Un diagrama de comportamiento se define formalmente como: Diagrama que expresa las secuencias de estados por los que pasa un objeto a lo largo de su vida en respuesta a eventos.

Hablando en un lenguaje más llano, se trata de diagramas que muestran diferentes estados de un proceso. Mediante estos diagramas se plasman de forma gráfica los procesos a programar.

Estos diagramas se usan para visualizar y especificar, a la vez que documentar, aspectos dinámicos de un sistema.

Cuando hablamos de desarrollo de software, estos aspectos dinámicos pueden ser mensajes que se generan, acciones de entrada de datos, eventos, etc…

Estos diagramas pueden ser muy simples o muy complejos en función del proceso que están representando. Hacen referencia a objetos, ya que se emplean mucho en la programación orientada a objetos. Un objeto puede ser cualquier entidad con un determinado estado y comportamiento.

Para aclarar de una forma visual el concepto, podéis ver la imagen que adjunto a este texto donde se representa un proceso mediante un diagrama de comportamiento.

Para desarrollar estos diagramas, se suele utilizar la notación UML (Unified Modeling Language), que no es más que un estándar de lenguaje para el modelado de sistemas de software y que recoge un conjunto de símbolos apropiados para cada tipo de estado o acción.

COMENTARIO: El diagrama de comportamiento es para llevar una secuencia del proceso acerca de algun software previo a desarrollar.

 Diagrama de Resumen de Interacción: dado que no hay paquetes de actividades se muestran las partes de un diagrama de actividad agrupando estas a la manera de un paquete, pero con un símbolo distinto.

1. IDENTIFICACIÓN DE REQUERIMIENTOS

REQUERIMIENTOS EMPLEADO

• Visualizar Mobiliario A Cargo
• Imprimir Mobiliario A Cargo
• Visualizar MyE De Baja
• Imprimir MyE De Baja
• Modificar Usuario Asignado
• Modificar Contraseña Asignado
• Ingreso Equipo Y Mobiliario
• Modificación Equipo Y Mobiliario
• Eliminación Equipo Y Mobiliario
• Lectura Equipo Y Mobiliario

REQUERIMIENTOS ENCARGADO INVENTARIO

• Ingresar al sistema 
• Ingresar Fecha Ingreso de Mobiliario y equipo 
• Controlar Ingreso de Mobiliario y equipo Nuevo 
• Controlar Asignación De Equipo A Usuario 
• Cargar Sistema Equipo 
• Modificación Equipo Existente 
• Ver e Imprimir el equipo 
• Ver Lista MYE Asignado a un Usuario y/o depto. 
• Lista MYE Ingresado

REQUERIMIENTOS ADMINISTRADOR

• 
  
• Ingresar al sistema 
• Crear usuarios de tipo empleado y encargado 
• Ver Lista Usuarios de tipo empleado y encargado existentes 
• Actualizar usuarios de tipo empleado y encargado 
• Eliminar usuarios de tipo empleado y encargado 
• Ver Información de Usuarios de tipo empleado y encargado

REQUERIMIENTOS SUPER ADMINISTRADOR

• Ingresar al sistema 
• Crear usuarios de todo tipo 
• Ver listado de usuarios generales 
• Modificar usuarios de todo tipo 
• Eliminar todo tipo de usuario

2.  IDENTIFICAR ACTORES Y CASOS DE USO

• EMPLEADO 
• ENCARGADO DE INVENTARIO: 
• ADMINISTRADOR 
• SUPER ADMINISTRADOR

3. IDENTIFICAR CLASES, ATRIBUTOS Y MÉTODOS

• EMPLEADO

Código

ID

Hora de ingreso

Hora de salida

Area/depto.

Salario

ver e imprimir mobiliario y equipo asignado activo

visualizar e imprimir mobiliario y equipo en estado de baja asignado

modificar usuario asignado

modificar contraseña asignada

• ENCARGADO DE INVENTARIO

Código

ID

Hora de ingreso

Hora de salida

Area/depto.

Salario

Asignación de mobiliario y equipo a cargo

visualizar Mobiliario y Equipo a  cargo

Ingreso de Mobiliario y equipo Nuevo

Asignación De Equipo A Usuario

Cargar al Sistema Mobiliario y Equipo

Modificación Equipo Existente

Dar de baja a Mobiliario y  Equipo

Ver e Imprimir:

Lista de mobiliario y equipo  asignado a Usuario específico

Lista de mobiliario y equipo asignado por él

LIsta mobiliario y equipo asignado a algún Depto.

• ADMINISTRADOR

Código

ID

Hora de ingreso

Hora de salida

Area/depto.

Salario

Tiene Usuarios a cargo:

Encargado De CRUD de usuarios de tipo Encargado

CRUD Usuarios tipo empleado

Ver Lista Usuarios totales existentes

Buscar por código a los Usuarios

Buscar por nombre a Usuarios

Buscar por departamento a Usuarios

Buscar por tipo de Usuarios

• SUPER ADMINISTRADOR

Código

ID

Hora de ingreso

Hora de salida

Area/depto.

Salario

CRUD a todas las entidades del sistema:

CRUD a usuarios tipo empleado

CRUD a usuarios tipo Encargado de Inventario

CRUD a usuarios tipo Administrador

• MOBILIARIO Y EQUIPO

Serie

Dimensiones

Capacidad

Marca

Color

Tiempo de Duración

Precio

Encender

Apagar

Reparar

Mantener

Procesar Datos

Modificar datos

Eliminar datos