El documento explica la importancia de UML (Lenguaje de Modelado Unificado) en el diseño y la comunicación de sistemas complejos, enfatizando la necesidad de documentación para facilitar el entendimiento entre arquitectos y clientes. Describe la evolución de UML desde sus inicios en los años 80 hasta su estandarización en 1997, y detalla los diferentes tipos de diagramas que se utilizan para representar clases, asociaciones, herencias y otros elementos de un sistema. Además, se discuten las dinámicas de trabajo en grupos de desarrollo y cómo UML ayuda a alinear las expectativas del cliente con las capacidades del sistema.

1. UML (Unified Modeling Language

2. ¿Porque documentar?
 ¿Porque todos lo necesitan?
 Arquitecto de sistemas.
 Trabajo en grupo
 Programas grandes
 Análisis de error
 Análisis de Requerimiento
 Actualizaciones

3. ¿Que es UML?
 Permite a los creadores de sistemas generar diseños que
capturen sus ideas en una forma convencional y fácil de
comprender para comunicarlas a otras personas.
 Un cliente tiene que comprender que es lo que haremos, y
poder señalar que entendimos mal, en lo posible antes de
comenzar con la codificación.
 Un arquitecto no podría crear una compleja estructura sin
crear primero un anteproyecto. Ídem para generar un
complejo sistema.
 Un arquitecto le muestra la idea al cliente para que este la
acepte, o sea que ponga la firma de que eso es lo que quiere.
De la misma manera, el diseño de un sistema se debe firmar.

4. Concepción del UML
 Grady Booch, James Rumbaugh, e Ivar Jacobson.
 Trabajaban en empresas distintas a principios de los ’80 y
c/u habia creado una forma de documentar sus proyectos.
Estas dominaron sobre las de sus competidores.
 En los ’90 comenzaron a intercambiar ideas y trabajar en
conjunto. Crearon el UML.
 Como era muy util se creo un consorcio del UML formado
por DEC, HP, Intellicorp, Microsoft, Oracle, Texas
Instruments y Rational.
 En 1997 UML 1.0 es entregado a la OMG (grupo de
administración de objetos)
 Finales de 1997 UML 2.0 es adoptado como estándar en la
industria del software para la POO.

5. Diagramas del UML
 Diagrama de Clases
 Representa las clases y las relaciones entre ellas.
 Diagrama de Objetos
 Un objeto es una instancia de una clase.
 Diagrama de Casos de Uso
 Descripción de las acciones de un sistema desde el
punto de vista del usuario.
 Permite obtener los requerimientos del sistema.
 Diagrama de Estados
 Representa el estado en el que se encuentra el
objeto, sus transiciónes y la causa de las mismas.

6. Diagramas de UML
 Diagrama de Secuencias
 Muestra la mecánica de la interacción con base
en el tiempo.
 Diagrama de Actividades
 Muestra las actividades que suceden dentro de
un caso de uso.
 Diagrama de Colaboraciones
 Muestra como se relacionan y colaboran entre si
los elementos de un sistema.

7. Diagramas de UML
 Diagrama de Componentes
 Revela la interacción entre los distintos
componentes de un sistema.
 Diagrama de Distribución
 Muestra arquitectura física de un
sistema.

8. Clases
 Para representar una clase, se utiliza un
rectángulo, con el nombre de la clase en la
parte superior del mismo.
 La lista de los atributos, iniciara luego de
una línea que la separe del nombre de la
clase.
 Podrá especificar el tipo para cada atributo,
colocando : entre el nombre y el tipo.
 Podrá también especificar el valor que tomara
por defecto.

9. Clases
 Podrá mostrar los métodos, debajo de una línea
que separa a los métodos de los atributos.
 Dentro de los paréntesis podrá mostrar el parámetro con
el que funcionará la operación junto con su tipo de dato.
 En caso de necesitar repetir una clase en un
diagrama, se puede mostrar como un rectángulo
vacío (solo con el nombre de la clase).
 Se pueden utilizar estereotipos para organizar las
listas de atributos y métodos. Estos se escriben
entre << xxxxx >>.
 Al final de la clase, se puede crear una última
división, que indica la responsabilidad de la clase.
O sea lo que debe recibir y lo que debe dar como
resultado.
 Las restricciones se indican fuera del rectángulo y
entre {}.

10. Clases

11. ¿Como encontrar las clases?
 En las charlas con el cliente, preste
atención a los sustantivos que utilizan, ya
que éstos se convertirán en las clases de su
modelo.
 Los verbos, constituirán las operaciones de
sus clases.
 Los atributos surgirán como sustantivos
relacionados con los nombres de la clase.
 Luego de tener identificadas las clases,
preguntando que hacen cada una, obtendrá
las responsabilidades de ellas.

12. Ejemplo: Ejercicio Parcial

13. Relaciones entre Clases
 Asociación: Cuando se conectan entre sí de
forma conceptual.
 Símbolo: línea, con el nombre de la asociación
justo sobre la línea, y un rectángulo relleno
indicando la dirección. La restricción se indica
entre {}

14. Relaciones entre Clases
 Otro tipo de Restricción es la relación
O ( {Or} )
 Se representa con una línea discontinua
que conecta dos líneas de asociación.

15. Relación entre Clases
 Multiplicidad: es la cantidad de objetos
de una clase que se relaciona con un
objeto de la clase asociada.
 Se simboliza con un número sobre la
línea junto a la clase correspondiente.

16. Relaciones entre Clases

17. Herencia y generalización
 Si conoce algo de una categoría de cosas,
automáticamente sabrá algunas cosas que podrá
transferir a otras categorías.
 Si sabe que algo es un animal, dará por hecho que come,
duerme, nace, se traslada, etc.
 Una clase (secundaria o subclase) puede heredar
los atributos y operaciones de otra (la clase
principal o superclase).
 Símbolo: Una línea que conecte las clases con un
triangulo sin rellenar que apunte a la clase principal.
 La conexión se interpreta como “es un tipo de”.

18. Herencia

19. Herencia
 Una clase que no proviene de una
clase principal, se llama clase base o
raíz.
 Si tiene una clase principal, tendrá
herencia simple.
 Si tiene más de una clase principal,
tendrá herencia múltiple.

20. Agregación
 Cuando una clase consta de otras.
 Símbolo: una línea que conecta las
clases, y un rombo sin relleno en la
línea cerca de la clase “padre”.
 Restricciones: se puede utilizar la
restricción O.

21. Agregación

22. Composición
 Cada componente dentro de una
composición puede pertenecer tan
sólo a un todo.

23. Ejemplo

24. Interfaces
 Public: la funcionalidad se extiende a
otras clases.
 Protected: La funcionalidad se otorga
sólo a las clases que heredan la clase
original.
 Privated: Sólo la clase original tiene
acceso.

25. Resumen
 Las ideas estáticas ayudas a que el analista
se comunique con un cliente.
 Las ideas dinámicas, ayudan a comunicarse
con un grupo de desarrolladores, y ayuda a
estos a crear programas.
 Ninguno de estos refleja el comportamiento
del sistema a los ojos del usuario. Este
punto de vista es clave para generar
sistemas útiles y funcionales (que cumplan
con los requerimientos y sean fáciles de
usar)

26. Casos de Uso