1. UNIVERSIDAD REGIONAL AUTONOMA DE
LOS ANDES “UNAINDES”
UML
ING. DEL SOFTWARE II
Henry Velasco
Sexto Ing. En Sistemas

2. 1. Introducción
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.

3. 2. PAUTAS GENERALES PARA
DESARROLLAR USANDO UML
● ¿Por qué modelamos?
● Una empresa que:
●
● Produce de forma consistente software que satisface las necesidades de sus usuarios.
● Puede desarrollar el software de forma predecible y puntual.
● Con un uso eficiente y efectivo de recursos tanto humanos como materiales
● Tiene un negocio sostenible.
● El producto principal de un equipo de desarrollo:
● No son documentos ni reuniones muy importantes.
● Es un buen software que satisfaga las necesidades de sus usuarios y la empresa.
●

4. ● Para desarrollar software rápida, efectiva y eficientemente es necesario:
● Trabajo repetido.
● Mínimo desecho de software.
● Gente apropiada.
● Enfoque apropiado.
● Herramientas apropiadas.
● Considerar las necesidades del problema y tecnología.
●
● El modelado es una parte central de todas las actividades que conducen a la producción de buen software.
● Construimos modelos para:
● Comunicar la estructura deseada y el comportamiento de nuestro sistema.
● Visualizar y controlar la arquitectura de nuestro sistema.
● Comprender qué estamos construyendo, muchas veces descubriendo oportunidades para la simplificación y reutilización.
● Controlar el riesgo.
●

5. 3. Paquetes y dependencia
● Paquetes:
La forma que tiene UML de agrupar elementos en subsistemas es a través del uso de
Paquetes, pudiéndose anidar los paquetes formando jerarquías de paquetes. De hecho un
sistema que no tenga necesidad de ser descompuesto en subsistemas se puede considerar
como con un único paquete que lo abarca todo.
● Dependencia:
La relación de dependencia entre dos elementos de un diagrama significa que un cambio
en el elemento destino puede implicar un cambio en el elemento origen (por tanto, si
cambia el elemento destino habría que revisar el elemento origen).
Una dependencia se representa por medio de una línea de trazo discontinuo entre los dos
elementos con una flecha en su extremo. El elemento dependiente es el origen de la flecha
y el elemento del que depende es el destino (junto a él está la flecha).

6. 4. Diagrama de Casos de Uso
Un Diagrama de Casos de Uso muestra la
relación entre los actores y los casos de uso del
sistema. Representa la funcionalidad que ofrece
el sistema en lo que se refiere a su interacción
externa.

7. Elementos
Los elementos que pueden aparecer en un Diagrama de Casos de Uso son: actores, casos de uso y
relaciones entre casos de uso.
1 Actores
Un actor es una entidad externa al sistema que realiza algún tipo de interacción con el mismo. Se
representa mediante una figura humana dibujada con palotes. Esta representación sirve tanto para
actores que son personas como para otro tipo de actores (otros sistemas, sensores, etc.).
2 Casos de Uso
Un caso de uso es una descripción de la secuencia de interacciones que se producen entre un actor
y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea específica. Expresa una
unidad coherente de funcionalidad, y se representa en el Diagrama de Casos de Uso mediante una
elipse con el nombre del caso de uso en su interior. El nombre del caso de uso debe reflejar la tarea
específica que el actor desea llevar a cabo usando el sistema.
3 Relaciones entre Casos de Uso
Entre dos casos de uso puede haber las siguientes relaciones:
• Extiende: Cuando un caso de uso especializa a otro extendiendo su funcionalidad.
• Usa: Cuando un caso de uso utiliza a otro.
Se representan como una línea que une a los dos casos de uso relacionados, con una flecha en
forma de triángulo y con una etiqueta <<

8. 5. Diagrama de Secuencia y
diagrama de Colaboración
Diagrama de Secuencia
Un diagrama de Secuencia muestra una interacción ordenada según la secuencia temporal
de eventos. En particular, muestra los objetos participantes en la interacción y los
mensajes que intercambian ordenados según su secuencia en el tiempo.
Diagrama de Colaboración
Un Diagrama de Colaboración muestra una interacción organizada basándose en los
objetos que toman parte en la interacción y los enlaces entre los mismos (en cuanto a la
interacción se refiere). A diferencia de los Diagramas de Secuencia, los Diagramas de
Colaboración muestran las relaciones entre los roles de los objetos. La secuencia de los
mensajes y los flujos de ejecución concurrentes deben determinarse explícita mente
mediante números de secuencia.

9. 6. Diagrama de Objetos y
diagrama de Clases

10. 7. Diagrama de Estados
Un Diagrama de Estados muestra la secuencia de estados por los que pasa un
caso de uso o un objeto a lo largo de su vida, indicando qué eventos hacen que
se pase de un estado a otro y cuáles son las respuestas y acciones que genera.
En cuanto a la representación, un diagrama de estados es un grafo cuyos nodos
son estados y cuyos arcos dirigidos son transiciones etiquetadas con los
nombres de los eventos.
Un estado se representa como una caja redondeada con el nombre del estado
en su interior. Una transición se representa como una flecha desde el estado
origen al estado destino. La caja de un estado puede tener 1 o 2
compartimentos. En el primer compartimento aparece el nombre del estado. El
segundo compartimento es opcional, y en él pueden aparecer acciones de
entrada, de salida y acciones internas.

11. 8. Diagrama de Componentes
Un diagrama de componentes muestra la organización y las
dependencias entre un conjunto de componentes.
Para todo sistema OO se han de construir una serie de diagramas que
modelan tanto la parte estática (diagrama de clases), como dinámica
(diagramas de secuencia, colaboración, estados y de actividades), pero
llegado el momento todo esto se debe materializar en un sistema
implementado que utilizará partes ya implementadas de otros sistemas,
todo esto es lo que pretendemos modelar con los diagramas de
componentes.

12. 9. Diagrama de Despliegue
Técnicas más comunes de modelado
a) Modelado de un sistema empotrado
El desarrollo de un sistema empotrado es más que el desarrollo de un sistema
software. Hay que manejar el mundo físico. Los diagramas de despliegue son útiles
para facilitar la comunicación entre los ingenieros de hardware y los de software.
Para modelar un sistema empotrado es necesario:
Ø Identificar los dispositivos y nodos propios del sistema.
Ø Proporcionar señales visuales, sobre todo para los dispositivos poco usuales.
Ø Modelar las relaciones entre esos procesadores y dispositivos en un diagrama de
despliegue.

13. b) Modelado de un sistema cliente servidor
La división entre cliente y servidor en un sistema es complicada ya que implica
tomar algunas decisiones sobre dónde colocar físicamente sus componentes
software, qué cantidad de software debe residir en el cliente, etc.
Para modelar un sistema cliente/servidor hay que hace lo siguiente:
Ø Identificar los nodos que representan los procesadores cliente y servidor del
sistema.
Ø Destacar los dispositivos relacionados con el comportamiento del sistema.
Ø Proporcionar señales visuales para esos procesadores y dispositivos a través
de estereotipos.
Ø Modelar la tipología de esos nodos mediante un diagrama de despliegue.

14. 10. REFERENCIAS
Desarrollo Orientado a Objetos con UML Xavier
Ferré Grau, María Isabel Sánchez Segura