Lenguaje Unificado de Modelado

1. UML
Lenguaje Unificado de Modelado

2. ¿Qué es UML?
• En todas las disciplinas de la Ingeniería
se hace evidente la importancia de los
modelos ya que describen el aspecto y
la conducta de "algo". Ese "algo"
puede existir, estar en un estado de
desarrollo o estar, todavía, en un estado
de planeación. Es en este momento
cuando los diseñadores del modelo
deben investigar los requerimientos del
producto terminado y dichos
requerimientos pueden incluir áreas
tales como funcionalidad, performance
y confiabilidad. Además, a menudo, el
modelo es dividido en un número de
vistas, cada una de las cuales describe
un aspecto específico del producto o
sistema en construcción.

3. Historia de UML
• Después de que la Rational Software Corporation
contratara a James Rumbaugh de General Electric, en
1994, la compañía se convirtió en la fuente de los dos
esquemas de modelado orientado a objetos más
populares de la época: Object-Modeling Technique
(OMT) de Rumbaugh, que era mejor para análisis
orientado a objetos, y el Método Booch (de Grady
Booch) que era mejor para el diseño orientado a objetos.
Poco después se les unió Ivar Jacobson, el creador del
método de ingeniería de software orientado a objetos.
Jacobson se unió a Rational, en 1995, después de que su
compañía Objectory AB fuera comprada por Rational.
Los tres metodologistas eran conocidos como los Tres
Amigos, porque se sabía de sus constantes discusiones
sobre las prácticas metodológicas.
En 1996 Rational concluyó
que la abundancia de lenguajes
de modelado estaba alentando
la adopción de la tecnología de
objetos, y para orientarse hacia
un método unificado,
encargaron a los Tres Amigos
que desarrollaran un "lenguaje
unificado de modelado"
abierto. Se consultó con
representantes de compañías
competidoras en el área de la
tecnología de objetos durante
la OOPSLA '96; eligieron
"cajas" para representar clases
en lugar de la notación de
Booch que utilizaba símbolos
de "nubes".

4. V
VENTAJAS UML
UML Se puede usar para diferentes tipos de
sistemas
UML consolida muchas de las notaciones y
conceptos más usadas orientados a objetos.
UML es facilmente entendible
DESVENTAJAS UML
UML no es un método de desarrollo.
UML al no ser un método de desarrollo es
independiente del ciclo de desarrollo
UML no se presta con facilidad al diseño de
sistemas distribuidos.

5. Los antecedentes de UML se sitúan en la década de los 90 con distintos estándares
para modelado de software, no obstante podemos hablar de dos grandes versiones:
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.
Hay que tener en cuenta que UML es un conjunto muy amplio de normas.
Prácticamente nadie las conoce todas. Según la empresa o universidad, institución o
centro de trabajo se usan determinados programas para crear diagramas y se
conocen ciertas partes de UML, pero no el conjunto de UML.

6. ¿Qué versión usar?
Para generar diagramas UML se usan programas informáticos.
Usa un programa actualizado pero no te preocupes en exceso
por qué versión de UML usar, lo importante es que en tu
grupo de trabajo o personas a las que se les vaya a enviar
documentación sobre un proyecto software sepan interpretar lo
que se les envía. A nivel profesional no se le presta demasiada
atención a que se cumpla estrictamente con las normas de una
determinada versión de UML, sino a que los esquemas estén
bien construidos y razonados.

7. Diagramas de bases de datos UML
Dado que las aplicaciones de software
interactúan con cantidades de datos cada vez
mayores, las estructuras y el diseño de bases
de datos son una parte fundamental de los
proyectos de desarrollo de software. Con
UModel puede importar tablas de BD
relacionales para crear diagramas de base de
datos UML, modificar diagramas de tablas de
datos ya existentes y generar scripts de
cambios SQL para sincronizar la base de
datos. También puede diseñar tablas y
relaciones de BD nuevas desde cero y generar
scripts CREATE SQL.

9. Los diagramas de base de datos de UML son
compatibles con varias bases de datos y son
capaces de acomodar dialectos SQL, tipos de
datos y otras características propias de cada tipo
de base de datos. UModel admite estos
elementos de base de datos: esquemas, tablas,
vistas, restricciones de comprobación, claves
primarias, foráneas y únicas, índices,
procedimientos almacenados, funciones,
desencadenadores, asociaciones de relación entre
BD y relaciones entre BD con atributos.
Importar bases de datos en UML
Los diagramas de BD aparecen dentro de una
categoría especial de la ventana "Árbol de
diagramas". Los diagramas de BD tienen un
aspecto parecido al de los diagramas de clases.
Por ejemplo, las líneas de relación entre tablas
son iguales que las asociaciones de clases.

10. ¿Cómo modificar bases de datos?
Mientras edita su diagrama de BD, la
ventana de finalización automática de
instrucciones SQL le ayudará a crear
diagramas válidos para el tipo de base
de datos SQL.
Scripts de cambios
El modelo supone un nivel extra de abstracción
entre el diseño y la base de datos, al igual que los
diagramas UML constituyen una abstracción del
código fuente del proyecto.
Cuando genere código fuente a partir del
proyecto de UModel, los cambios realizados en el
diagrama de BD dan lugar a un script de cambios
con comandos SQL con los que podrá
implementar las correcciones.
Los scripts de cambios creados en UModel
pueden guardarse como archivos SQL, ejecutarse
directamente en la BD o abrirse en el editor SQL
de DatabaseSpy. El cuadro de diálogo "Script de
cambios de la base de datos" incluye un práctico
botón para cada una de estas 3 opciones.
De la misma manera, si otro miembro del equipo
modifica la tabla directamente en la base de
datos, el modelo UML se puede actualizar con
solo combinar los cambios de la base de datos.

11. Diagrama de clases
En ingeniería de software, un diagrama de clases en Lenguaje Unificado de Modelado
(UML) es un tipo de diagrama de estructura estática que describe la estructura de un
sistema mostrando las clases del sistema, sus atributos, operaciones (o métodos), y las
relaciones entre los objetos.

12. Un diagrama de colaboración
En las versiones de UML 1.x es esencialmente un
diagrama que muestra interacciones organizadas
alrededor de los roles. A diferencia de los diagramas
de secuencia, los diagramas de colaboración,
también llamados diagramas de comunicación,
muestran explícitamente las relaciones de los roles.
Por otra parte, un diagrama de comunicación no
muestra el tiempo como una dimensión aparte, por
lo que resulta necesario etiquetar con números de
secuencia tanto la secuencia de mensajes como los
hilos concurrentes.
Muestra cómo las instancias específicas de las clases
trabajan juntas para conseguir un objetivo común.
Implementa las asociaciones del diagrama de clases
mediante el paso de mensajes de un objeto a otro.
Dicha implementación es llamada "enlace".

13. Un diagrama de secuencia
Muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo
y se modela para cada caso de uso. A menudo es útil para complementar a un diagrama
de clases, pues el diagrama de secuencia se podría describir de manera informal como
"el diagrama de clases en movimiento", por lo que ambos deben estar relacionados
entre sí (mismas clases, métodos, atributos...). Mientras que el diagrama de casos de uso
permite el modelado de una vista business del escenario, el diagrama de secuencia
contiene detalles de implementación del escenario, incluyendo los objetos y clases que
se usan para implementar el escenario y mensajes intercambiados entre los objetos.

14. Diagrama de casos de uso
En el Lenguaje de Modelado Unificado, un
diagrama de casos de uso es una forma de
diagrama de comportamiento UML mejorado. El
Lenguaje de Modelado Unificado (UML), define
una notación gráfica para representar casos de
uso llamada modelo de casos de uso. UML no
define estándares para que el formato escrito
describa los casos de uso, y así mucha gente no
entiende que esta notación gráfica define la
naturaleza de un caso de uso; sin embargo una
notación gráfica puede solo dar una vista general
simple de un caso de uso o un conjunto de casos
de uso. Los diagramas de casos de uso son a
menudo confundidos con los casos de uso.
Mientras los dos conceptos están relacionados,
los casos de uso son mucho más detallados que
los diagramas de casos de uso. En los conceptos
se debe detallar más de un caso de uso para
poder identificar qué es lo que hace un caso de
uso.

15. Un diagrama de componentes es un
diagrama tipo del Lenguaje Unificado de
Modelado.
Un diagrama de componentes representa
cómo un sistema de software es dividido en
componentes y muestra las dependencias
entre estos componentes. Los componentes
físicos incluyen archivos, cabeceras,
bibliotecas compartidas, módulos,
ejecutables, o paquetes. Los diagramas de
Componentes prevalecen en el campo de la
arquitectura de software pero pueden ser
usados para modelar y documentar
cualquier arquitectura de sistema.
Debido a que los diagramas de
componentes son más parecidos a los
diagramas de casos de usos, éstos son
utilizados para modelar la vista estática y
dinámica 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 él se situarán librerías, tablas, archivos,
ejecutables y documentos que formen
parte del sistema.
Uno de los usos principales es que puede
servir para ver qué componentes pueden
compartirse entre sistemas o entre
diferentes partes de un sistema.

17. Diagrama de Estado: Este
muestra la secuencia de estados
por los que pasa bien un caso de
uso, un objeto a lo largo de su
vida, o bien todo el sistema. Es
una forma de representación
gráfica más intuitiva de los
autómatas finitos basadas en
dígrafos con arcos acotados
llamados transiciones en los
cuales se ponen los símbolos de
tránsito entre un vértice (estado)
y otro y se identifican los estados
de partida y los de aceptación del
resto.
Características
Sea un autómata finito definido por la 5-tupla
A=<Q, T, g, F, q0>, donde Q es el conjunto de
estados, T el alfabeto de símbolos terminales, la
relación de transiciones Definicion transiciones
af.gif, F son los estados finales o de llegada
dentro de Q, q0 es el estado inicial o de partida;
se le llama diagrama de estados de A al grafo
orientado con aristas y vértices

18. Diagrama de despliegue
El Diagrama de Despliegue es un tipo de diagrama del Lenguaje Unificado de Modelado que
se utiliza para modelar la disposición física de los artefactos software en nodos (usualmente
plataforma de hardware).1
La mayoría de las veces el modelado de la vista de despliegue implica modelar la topología
del hardware sobre el que se ejecuta el sistema. Aunque UML no es un lenguaje de
especificación hardware de propósito general, se ha diseñado para modelar muchos de los
aspectos hardware de un sistema a un nivel suficiente para que un ingeniero software pueda
especificar la plataforma sobre la que se ejecuta el software del sistema.

19. Diagramas de actividad
Un diagrama de actividad es un caso especial de diagrama de estados en el que todos
los Estados son estados de acción y el flujo de control se activa al finalizar las
acciones en el estado de origen.
Relacionado con una clase o caso de uso determinado, un diagrama de actividad
describe el comportamiento interno de un método. Utilice un diagrama de actividad
para representar el flujo controlado por acciones generadas internamente. Utilice un
diagrama de estados para representar un flujo en respuesta a eventos externos.
Los diagramas de actividad le ayudan a percibir y documentar actividades paralelas y
simultáneas. Esto los convierte en una herramienta excelente para modelar el flujo
de trabajo, analizar casos de uso y tratar aplicaciones de subproceso múltiple.

20. El estado inicial es el estado de un objeto antes de que los eventos en el diagrama han
actuado en él.
Imagen del botón Un estado de acción es un tipo de estado que representa una actividad
finalizada.
Globo 3 Se produce una transición desde un estado de acción cuando se completa
internos acción del estado de acción.
Paso 4 Utilice una transición de combinación para indicar actividades simultáneas que
deben completarse antes de que comience la siguiente actividad.
Globo 5 Haga doble clic en transiciones de Estados de acción para etiquetarlas con
condiciones restricción y expresiones de acción.
Globo 6 Para indicar las actividades que pueden producirse en paralelo, utilice una
transición de bifurcación.
globo 7 El estado final representa la finalización de la actividad de la situación que
representa el diagrama.

22. GRACIAS POR SU VISITA