M.S.C.

Enrique Martnez Tllez

Herramientas de programacin
M.S.C. Enrique Martnez Tllez
M.S.C. Enrique Martnez Tllez
Que es UML?
UML (Unified Modeling Language).
Lenguaje Estndar para:
Visualizar
Especificar
Construir
Documentar los planos del software

Indican como crear y leer modelos bien formados pero no
nos dicen qu modelos se deben crear ni cundo se los
deberan crear

M.S.C. Enrique Martnez Tllez
UML es un lenguaje para visualizar
La distancia entre pensar en una implementacin y transformarla en
cdigo es casi cero.
UML es algo ms que un simple montn de smbolos grficos.
En algunos casos: Lo que piensas lo codificas.
Algunas cosas se modelan mejor textualmente; otras se modelas
mejor de forma grfica
M.S.C. Enrique Martnez Tllez
UML es un lenguaje para especificar
Significa construir modelos precisos, no ambiguos y completos
Pero sus modelos pueden conectarse a una gran variedad de lenguajes de
programacin
UML cubre todas las decisiones de anlisis, diseo e implementacin
No es un lenguaje de programacin
UML es un lenguaje para construir
M.S.C. Enrique Martnez Tllez
UML es un lenguaje para documentar
UML cubre la documentacin de la arquitectura de un sistema y todos sus
detalles
Proporciona un lenguaje:
Expresar requisitos y pruebas
Modelar actividades de planificacin de proyectos y
gestin de versiones
M.S.C. Enrique Martnez Tllez
Breve historia 1/2
Los lenguajes de modelamiento orientados a objetos
aparecieron entre mediados de los 70's y fines de los 80's.
debido a dos factores fundamentales: la aparicin de
lenguajes orientados a objetos, y la aparicin de aplicaciones
cada vez ms complejas.
En 1989 haban aproximadamente 10 mtodos orientados a
objetos.
En 1994 ms de 50. Esta poca fue llamada la "guerra de
los mtodos.
Entre todos estos mtodos destacaron tres: el de Booch, el
OOSE (Object-Oriented Software Engineering) de Jacobson,
y el OMT (Object Modeling Technique) de Rumbaugh. Otros
mtodos importantes fueron: Fusion, Shlaer-Mellor y Coad-
Yourdon.

M.S.C. Enrique Martnez Tllez
Breve historia 2/2

A mediados de los 90's cada autor de los tres mtodos ms
reconocidos (Booch, Jacobson y Rumbaugh) empieza a
adoptar ideas de los otros 2 mtodos. En 1994 Rumbaugh se
une a Booch, y sacan la versin 0.8 de Unified Method, el cual
es publicado en 1995.
Luego Jacobson se une a Rational, y sacan la versin 0.9 de
UML, en junio de 1996.
Posteriormente sacan la versin 1.0 en enero de 1997, con
la aprobacin de un grupo de empresas llamado OMG (Object
Management Group).
El lenguaje es abierto a otras empresas, y con nuevas
observaciones y recomendaciones sale la versin 1.1 en
noviembre de 1997, y la versin 1.2 en junio de 1998. A fines
de 1998 sale la actual versin 1.3.
M.S.C. Enrique Martnez Tllez
M.S.C. Enrique Martnez Tllez
M.S.C. Enrique Martnez Tllez
M.S.C. Enrique Martnez Tllez
M.S.C. Enrique Martnez Tllez
M.S.C. Enrique Martnez Tllez
Metas de UML 2.0
Proveer un lenguaje de modelado visual
fcil de usar y comprender.
Proveer extensibilidad y especializacin
Soportar especificaciones que no
dependan de lenguaje de programacin
alguno.
Proveer un lenguaje de modelado exacto
y accesible
Apoyar a las crecientes herramientas de
objetos del mercado
Apoyar conceptos avanzados de
desarrollo
M.S.C. Enrique Martnez Tllez
Simbologa
16
CASOS DE USO
Qu es un caso de uso?
Para que sirven los casos de uso?
Cmo se representan?
Cmo se debe crear un caso de uso?
Flujo de eventos
Relaciones
Diagramas de caso de uso


Use Case 2
Specification
Actor 2
Use case 1
Model
Use case 2
Use case 3
M.S.C. Enrique Martnez Tllez
17
QU ES UN CASO DE USO?
Describen una interaccin tpica entre un usuario (actores) y un sistema
de cmputo.

Es una tcnica para capturar informacin de cmo un sistema o negocio
trabaja actualmente, o de cmo se desea que trabaje

Produce algo de valor para algn actor como el clculo de algn
resultado

Describe qu hace un sistema pero no especifica cmo lo hace

El caso de uso capta alguna funcin visible para el usuario.
El caso de uso puede ser pequeo o grande.
El caso de uso logra un objetivo discreto para el usuario.

Un caso de uso debe ser simple, claro y conciso

M.S.C. Enrique Martnez Tllez
18
PARA QUE SIRVEN LOS CASOS DE USO?
Para capturar el comportamiento deseado del sistema sin
tener que especificar como se implementa ese comportamiento

Como medio de comprensin del sistema para
desarrolladores, usuarios finales y expertos del dominio

Ayudan a validar la arquitectura y a verificar el sistema en el
transcurso del desarrollo de este
M.S.C. Enrique Martnez Tllez
19
Un caso de uso se representa en UML como un valo:
CMO SE REPRESENTAN?
Nombre del Caso de Uso
En UML, un actor se representa como monigote
Actor
M.S.C. Enrique Martnez Tllez
20
ACTORES
Representa un conjunto de roles que los usuarios de los casos de uso
juegan al interactuar con stos

Representa un rol que es jugado por una persona, un dispositivo hardware u
otro sistema que interacte con nuestro sistema

Se puede definir categoras generales de actores (como cliente) y
especializarlos (como ClienteComercial) a travs de relaciones de
generalizacin
Cliente
Cliente
Comercial
actor
actor
generalizacin
Un actor y un caso de uso se pueden comunicar a travs de una
asociacin en donde cada uno de ellos pueden enviar y recibir mensaje.
M.S.C. Enrique Martnez Tllez
21
FLUJO DE EVENTOS
Cmo y cundo empieza y acaba el caso de uso

Cundo interactan con los actores y que objetos se intercambian

Conviene separa el flujo principal de uno alternativo


M.S.C. Enrique Martnez Tllez
22
Ejemplo:

VALIDACIN DE USUARIO

M.S.C. Enrique Martnez Tllez
23
RELACIONES
Para extraer el comportamiento de los casos de uso en los que se incluye y
poniendo ese comportamiento en otros casos de uso que lo extiende

Tipos:
- GENERALIZACIN
- EXTENSIN
- INCLUSIN



M.S.C. Enrique Martnez Tllez
24
GENERALIZACIN
El caso hijo hereda el comportamiento y significado de caso
de uso padre
El hijo puede aadir o redefinir el comportamiento del padre
El Caso de Uso fuente hereda la especificacin del Caso de
Uso destino

Caso de uso origen
Caso de uso destino
M.S.C. Enrique Martnez Tllez
25

INCLUSIN

Un caso base de uso base incorpora
expolisitamente el comportamiento de otro caso de
uso en el lugar especificado en el caso base.
Se usa para evitar describir el mismo flujo de
eventos repetidas veces, poniendo
comportamiento comn en un caso de uso aparte
Se representa como una dependencia
estereotipada con <<include>>




M.S.C. Enrique Martnez Tllez
26
Caso de uso origen
Caso de uso destino
<<include>>
Ingresando pedido
Buscando datos de
producto
Obtener reporte
De Ventas por
producto
<<include>>
<<include>>
Empleado de
ventas
Gerente
REPRESENTACI
N:
EJEMPLO:
M.S.C. Enrique Martnez Tllez
27
EXTENSIN
> Significa que un caso de uso base incorpora implcitamente el
comportamiento de otro caso de uso en el lugar especificado
indirectamente por el caso de uso que extiende al base
> Se usa esta relacin cuando se tiene un caso de uso que es similar
a otro, pero que hace un poco ms.

Caso de uso
origen
Caso de uso
destino
<<extends>>
M.S.C. Enrique Martnez Tllez
28
Ejemplo.- se tiene un telfono convencional en el cual se
desea tener llamadas de voz, es decir el sistema tiene
entre sus propiedades el de permitir al usuario del mismo
comunicarse remotamente por medio de conexiones de
voz


M.S.C. Enrique Martnez Tllez
29
30
31
32
33
Operaciones que se pueden realizar en un Telfono
Cdigo Descripcin
CS- 0100 Llamada de voz
CS- 0101 Tres a la vez
CS- 0102 Plan mvil 100
CS- 0103 Lnea de negocio
CS- 0104 Lada 800
CS- 0105 Audio conferencia LADA
34
35
36
37
38
Flujo de Eventos
39
Flujo Alternativo
Los flujos alternativos pueden ser vistos como una forma de
manejo de errores o bien, como un medio para especificar el
comportamiento del sistema en caso de un error.
40
Conclusiones:
Los Casos de Uso no son parte del diseo (cmo), sino parte del anlisis
(qu).

Los Casos de Uso son qu hace el sistema desde el punto de vista del
usuario. Es decir, describen un uso del sistema y cmo este interacta con el
usuario.

Los diagramas de casos de uso muestran las relaciones entre los casos de
uso de un sistema y sus actores.

En una relacin << extends>>, un actor que lleve a cabo el caso de uso base
puede realizar o no sus extensiones. Mientras, en una relacin <<include>> el
actor que realiza el caso de uso base tambin realiza el caso de uso incluido.

M.S.C. Enrique Martnez Tllez
M.S.C. Enrique Martnez Tllez
1 Diagrama de actividades

42
Definicin
1. Representa el comportamiento interno de una
operacin o de un caso de uso, bajo la forma
de un Desarrollo por etapas, agrupadas
secuencialmente.
El propsito del diagrama de actividad es:
Modelar el flujo de tareas
Modelar las operaciones

43
Elementos de un Diagrama de
actividades
Particiones
Nodos de Accin
Nodos de Control
Nodos de Objeto
Extremos
44
Elementos principales

45
Ejemplo Solicitar Compra

46
46
Caractersticas
1. Llamados tambin diagramas de flujo de
datos.
2. Indican la lgica que rige la ejecucin de
acciones.
3. Se asocian a casos de uso, paquetes, etc.
4. Muestra los aspectos dinmicos de un
sistema
5. Permite elegir el orden en que pueden
hacerse las cosas.

47
Carriles (swimlanes) o calles
1. Franja de divisin Vertical
2. Muestra las actividades responsabilidad de
un determinado objeto
3. Puede representar a un actor, a un
trabajador del negocio que participa en el
proceso de modelado por un caso de uso
48
Componentes (Nodo de Control)
1. Nodo inicial(initial state).
1. indica el comienzo del flujo de actividades.
2. Representa el inicio del flujo de trabajo del
caso de uso del negocio.
3. Se representa a travs de un crculo de
color negro.
4. Se coloca dentro del swimlane
correspondiente al rol que comienza el
caso de uso.
5. Es un estado nico para el flujo de
actividades

49
Componentes (Nodo de Control)
1. Nodo Final(end state).
1. indica el final del flujo de actividades del
caso de uso.
2. Se representa a travs de un crculo de
color negro dentro de un crculo
transparente.
3. Se coloca dentro del swimlane
correspondiente al rol que termina el caso
de uso.
4. Puede haber mas de un estado final en
dependencia de las diferentes maneras de
acabar el caso de uso.

50
Componentes (Nodo de Accin)
1. Actividad(activity).
1. Representa una tarea, actividad o paso dentro del
flujo de trabajo del caso de uso del negocio.
2. Se representa a travs de un rectngulo ovalado en
los extremos.
3. El nombre de la actividad debe:
a) Ser simple y breve.
b) Ser un verbo o frase verbal en infinitivo.
c) Incluir el objeto de la actividad.
d) Colocarse dentro del smbolo de la actividad.
51
Componentes (Extremos)
1. Flujo de Control (Transicin).
1. Seala la direccin en que fluyen las actividades.
2. Representa la secuencia de cada elemento dentro del diagrama.
3. Al completarse la actividad de una actividad el flujo de control
pasa a la siguiente.
4. Se representa por una lnea dirigida.

52
Componentes (Nodo de Control)
1. Nodo de Decisiones.
1. Representa momentos para tomar caminos alternativos.
2. Se representa por un rombo.
3. Debe nombrarse tal y como se hace en el negocio.
4. Se acompaa de la pregunta que debe hacerse el proceso para
tomar la decisin.

53
54
55
56