Contextualizacion del Lenguaje Unificado de Modelado (UML) dentro del proceso de desarrollo de software.

1. UML
Y el proceso unificado de desarrollo
trabajando con objetos
Javier González Sánchez, MCs
javiergs@acm.org
Departamento de Tecnologías de Información
ITESM, campus Guadalajara

2. javiergs@acm.org

3. Expectativas del Curso
Expectativas
Antecedentes de UML
Experiencia en Modelado de Software
Experiencia en A&D Orientado a Objetos
Experiencia con Lenguajes de Programación
javiergs@acm.org

4. Contenido
1. Introducción:
Arquitectura del Software
Principios de Orientación a Objetos
2. Modelado Estructural
UML
Objetos y Clases (modelado de la arquitectura)
3. Modelado de Comportamiento
Casos de Uso (modelado del comportamiento)
4. Modelado de Comportamiento
Secuencias y Colaboración
javiergs@acm.org
5. Modelado de Comportamiento

5. 1.1.
Introducción:
Arquitectura del Software

6. Objetivo
Contextualizar al Lenguaje Unificado de Modelado dentro del proceso de
desarrollo de software
Definir el concepto de modelo y la importancia del modelado en el proceso de
desarrollo de software
Comprender los conceptos de objeto, relación, componente y capa como
parte de cualquier arquitectura de software
javiergs@acm.org

7. La casa del perro
Recursos:
• una sola persona
Conocimientos:
• modelado mínimo
• proceso simple
• herramientas simples
javiergs@acm.org

8. La casa de la familia
Recursos:
• Un equipo
Considerar:
• eficiencia
• tiempo razonable
Requiere:
• Modelado
• Proceso bien definido
• Herramientas sofisticadas
javiergs@acm.org

9. Aclarando Ideas
reglas
lenguaje
modelo(s)
[ UML ]
elementos
reglas
objeto (s) elementos Arquitectura reglas
elementos
producto
real
javiergs@acm.org

10. Desarrollo de Software
Necesidad Notación
Proceso Herramientas
Producto
javiergs@acm.org

11. Proceso = abstracción, modelo, objeto
El modelado captura las partes esenciales del sistema
Orden
Objetos
Item
Metodologías de A&D
envío
Proceso de Negocios Sistema de cómputo
javiergs@acm.org

12. Notación: arquitectura
La mente humana puede trabajar con 7 más/menos 2 cosas a la vez …
Divide y vencerás
Interfase de Usuario Múltiples Sistemas
(Visual Basic,
Java, ..) Lógica del Negocio
(C++, Java, ..)
Servidor de BDs
(C++ & SQL, ..)
capas componentes
Modelar el sistema independientemente del lenguaje de implementación
Reuso de alto nivel
javiergs@acm.org

13. Resumen
Objeto A&D
Clase
Orientado a Objetos
Capa
Componente
A&D
Arquitectura Estructurado
Modelo
Metodología A&D
Distribuido
Análisis
Diseño
Implementación
Test
Deploy
javiergs@acm.org

14. 1.2.
Introducción:
Principios de Orientación a Objetos

15. Objetivo
Explicar los conceptos básicos detrás de la orientación a objetos
clase, objeto, interfase
atributo, estado, operación, mensaje, comunicación
relación, asociación, herencia
Identificar los elementos que conforman a las clases y objetos
Describir las relaciones entre objetos y entre clases
javiergs@acm.org

16. Contexto
Problema:
Actualmente, Software Grande y Complejo.
Demanda de interfaces más completas, funcionalidades más elaboradas
Impacto en complejidad del producto.
Requisitos:
Los programas deben poder ser mantenidos y ampliados con garantías de éxito.
Solución:
Estructuración, modelado.
javiergs@acm.org

17. Objeto
“cosa” del mundo real : una entidad física o abstracta
representaciones abstractas de entidades del mundo, tangibles o no,
con la intención de emularlas.
Elemento que interviene en el proceso del negocio
Estructura de datos con sus operaciones asociadas
Unidad atómica que encapsula estado y comportamiento
La encapsulación en un objeto permite una alta cohesión y un bajo
acoplamiento
Posee un OID identificador único y global dentro del sistema que es
determinado en el momento de su creación.
javiergs@acm.org

18. Estado y Comportamiento individual
Estado: situación en que se encuentra un objeto, tal que cumple alguna
condición/es particulares, realiza una actividad o espera que suceda un
acontecimiento.
Los objetos mantienen su estado en uno o más atributos.
El estado evoluciona con el tiempo
Algunos atributos pueden ser constantes
El comportamiento agrupa las competencias de un objeto y describe las
acciones y reacciones de ese objeto. Exhibido a través de métodos
Las operaciones de un objeto son consecuencia de un estímulo externo
representado como mensaje enviado desde otro objeto
javiergs@acm.org

19. Comunicación
Un sistema informático puede verse como un conjunto de objetos
autónomos y concurrentes que trabajan de manera coordinada en la
consecución de un fin específico
El comportamiento global se basa pues en la comunicación entre los
objetos que la componen
El envío de mensajes es la forma en que se invoca los comportamientos de
un objeto (cada método define un comportamiento).
La invocación de métodos permite a un objeto cambiar su estado o el de otro
objeto.
javiergs@acm.org

20. Comportamiento global
Categorías de objetos:
Objeto Activo: posee un hilo de ejecución (thread) propio y puede iniciar una
actividad
Objeto Pasivo: no puede iniciar una actividad pero puede enviar estímulos
una vez que se le solicita un servicio
Cliente: es el objeto que solicita un servicio.
Servidor: es el objeto que provee el servicio solicitado
Agente:
javiergs@acm.org

21. Mensaje
La unidad de comunicación entre objetos se llama mensaje
El mensaje es el soporte de una comunicación que vincula dinámicamente los
objetos que fueron separados previamente en el proceso de descomposición
Adquiere toda su fuerza cuando se asocia al polimorfismo y al enlace dinámico
javiergs@acm.org

22. Persistencia
La persistencia de los objetos designa la capacidad de un objeto trascender
en el espacio/tiempo
Se dice que un objeto es reconstruido o reanimado si es trasladado de
memoria secundaria a memoria primaria, para utilizarlo (materialización del
objeto)
javiergs@acm.org

23. Relaciones entre objetos
Usar: invocar un objeto a un método de otro objeto ( asociación )
Tener: un objeto puede estar dentro de otro objeto ( composición )
Cardinalidad en las relaciones de objetos
javiergs@acm.org

24. Clase
Son patrones que definen qué atributos y qué métodos son comunes a un
conjunto de objetos, que pertenecen a dicha clase.
Es más fácil de entenderlo si se toma tipo como equivalente.
Todos los objetos del mismo tipo comparten el mismo juego de atributos y
métodos y, por tanto, pertenecen a la misma clase.
javiergs@acm.org

25. Atributos y métodos de Clase
Hay atributos que no varían de una instancia a otra. Todas las instancias de la
clase tienen el mismo valor. Estos atributos que no varían de instancia a
instancia se conocen como variables de clase.
De manera análoga hay métodos de instancia y métodos de clase.
javiergs@acm.org

26. Relación entre clases
Las clases permiten su definición a partir de otras clases.
Esto permite definir una jerarquía de especialización o bien generalizar a
entidades existentes
Una Clase definida a partir de otra, hereda todos los atributos y métodos de su
clase ancestro.
Las clases herederas pueden sobrescribir los atributos y los métodos heredados y
pueden añadir nuevos.
Las clases herederas pueden además sobrecargar los métodos heredados
javiergs@acm.org

27. Herencia
La clase tomada como patrón se conoce
como superclase o clase padre,
mientras que la heredera se llama clase
hija o subclase
La jerarquía de herencia puede ser todo lo
profunda que sea necesario. Una clase
puede tener varias clases como patrón.
javiergs@acm.org

28. Interfaces
Mecanismo que emplean dos objetos para interactuar.
Definen un conjunto de métodos para establecer el protocolo en base al que
interactúan dos objetos.
Las interfaces capturan similitudes entre clases no relacionadas.
Son a su vez clases, en particular clases totalmente abstractas
¿ clases abstractas ?
¿ entonces existirán métodos y/o atributos abstractos ?
javiergs@acm.org

29. Polimorfismo
Es la capacidad de diferentes objetos para responder al mismo mensaje,
cada uno a su manera.
Mensaje: hablar
Objetos: gato, perro, niño
Cada uno reacciona de acuerdo a su implementación
Beneficios: simplicidad y flexibilidad.
javiergs@acm.org

30. Resumen
Objeto Composición
Estado
Comportamiento Agregación
Encapsular Generalización
Cohesión Especialización
Acoplamiento
IOD
Sobreescribir
Clase Sobrecargar
Atributo
Método Atributo de clase
Método de clase
Mensaje
Herencia
Polimorfismo
Interfase
javiergs@acm.org

31. Práctica 1
name:
javiergs@acm.org

32. Práctica 1
Objetos
Clases
Relaciones
¿Cómo representarlas ?
• Un grafo
• Texto
• Quizás instrucciones en un lenguaje especifico, un lenguaje de programación
javiergs@acm.org

33. javiergs@acm.org

34. 2.1.
Modelado:
UML

35. Unified Modeling Language
Un lenguaje de propósito general para el modelado orientado a objetos
Grafico y textual
No es una metodología, i.e. no define un ciclo de vida
Documento “OMG Unified Modeling Language Specification”
http://www.uml.org/
UML combina notaciones provenientes desde:
Modelado Orientado a Objetos
Modelado de Datos
Modelado de Componentes
Modelado de Flujos de Trabajo (workflow)
javiergs@acm.org

36. Historia
Diversos métodos y técnicas OO, con muchos aspectos en común pero
utilizando distintas notaciones.
Inconvenientes para el aprendizaje, aplicación, construcción y uso de
herramientas, etc.
Pugna entre distintos enfoques ( y correspondientes gurús )
Establecer una notación estándar
javiergs@acm.org

37. Historia
Microsoft
Oracle
HP
IBM
Ivar Jacobson – Use Case - OOSE
Rumbaugh – Análisis - OMT
Booch – Arquitectura - Booch
javiergs@acm.org

38. Unificado
javiergs@acm.org

39. Bloques básicos
UML tiene tres bloques básicos de construcción:
1. Elementos:
• estructurales: partes estáticas de los modelos, representan aspectos conceptuales
o materiales.
• de comportamiento: partes dinámicas de los modelos, representan comportamientos en el
tiempo y espacio.
• de agrupación: partes organizativas de los modelos.
• de Notación: partes explicativas de los modelos.
2. Relaciones
3. Diagramas
javiergs@acm.org

40. Generando modelos
UML es simplemente un lenguaje.
Define un conjunto de elementos y las relaciones entre ellos y esto se emplea
para definir modelos.
Los modelos representan :
las propiedades estáticas (estructura) y
las propiedades dinámicas (comportamiento)
UML se usa típicamente como parte de un proceso de desarrollo, con ayuda de
una herramienta CASE.
UML es independiente de cualquier proceso particular, no está ligado a ningún
ciclo de vida de desarrollo de software concreto.
javiergs@acm.org

41. Modelos y Diagramas
Un modelo captura una vista de un sistema del mundo real. Es una
abstracción de dicho sistema, considerando un cierto propósito. Así, el
modelo describe completamente aquellos aspectos del sistema que son
relevantes al propósito del modelo, y a un apropiado nivel de detalle.
Diagrama: una representación gráfica de una colección de elementos de
modelado, a menudo dibujada como un grafo con vértices conectados por
arcos
javiergs@acm.org

42. Modelos y Diagramas
Un proceso de desarrollo de software debe ofrecer un conjunto de modelos
que permitan expresar el producto desde cada una de las perspectivas de interés
El código fuente del sistema es el modelo más detallado del sistema (y además
es ejecutable). Sin embargo, se requieren otros modelos.
Cada modelo es completo desde su punto de vista del sistema
Existen relaciones de trazabilidad entre los diferentes modelos
javiergs@acm.org

43. Diagramas de UML
Los diagramas expresan gráficamente partes de un modelo desde cierta perspectiva
State
State
Diagrams de
Use Case Diagramas
Diagrams
Use Case
Diagrams de Clases State
Use Case Diagramas
Diagrams State
Use Case Diagrams de
Diagramas
Diagrams de
Diagramas Casos de Uso Diagrams
Diagrams Objetos
Secuencia
Scenario State
Scenario
Diagrams de State
Diagrams de
Diagramas
Diagrams Diagramas
Diagrams
Colaboración Componentes
Modelo(s)
Scenario Component
Scenario
Diagrams de
Component
Diagrams
Diagramas de
Diagramas
Diagrams Diagrams
Estados Distribución
Diagramas de
Actividad Estáticos
Dinámicos
De Estructura
De funcionalidad
De arquitectura
De Comportamiento
javiergs@acm.org

44. Propuesta para Modelos
M. de Casos de Uso del Negocio (Business Use-Case Model)
M. de Objetos del Negocio (Business Object Model)
M. de Casos de Uso (Use-Case Model)
M. de Análisis (Analysis Model)
M. de Diseño (Design Model)
M. de Despliegue (Deployment Model)
M. de Datos (Data Model)
M. de Implementación (Implementation Model)
M. de Pruebas (Test Model)
javiergs@acm.org

45. Propuesta para Diagramas
Diagrama de Casos de Uso *
Diagrama de Clases *
Diagrama de Objetos
Diagramas de Comportamiento
Diagrama de Estados
Diagrama de Actividad
Diagramas de Interacción
Diagrama de Secuencia
Diagrama de Colaboración
Diagramas de implementación
Diagrama de Componentes
Diagrama de Despliegue
javiergs@acm.org

46. Ciclo de vida en RUP
Flujos de trabajo fases
del proceso Iniciación Elaboración Construcción Transición
Modelado del
negocio
Requisitos
Análisis y diseño
Implementación
Pruebas
Despliegue
Flujos de trabajo
de soporte
Gestión del cambio
y configuraciones
Gestión del proyecto
Entorno
Iteraciones Iter Iter Iter Iter Iter Iter Iter
preliminares #1 #2 #n #n+1 #n+2 #m #m+1
Fuente: Jacobson et al., 2000
javiergs@acm.org

47. Resumen
UML define una notación que se expresa como diagramas sirven para
representar modelos/subsistemas o partes de ellos
El 80 por ciento de la mayoría de los problemas pueden
modelarse usando alrededor del 20 por ciento de UML–
Grady Booch
javiergs@acm.org

48. Práctica 2
name:
javiergs@acm.org

49. Práctica 2
Diagrama Estático [ deployment ]
¿ donde se requiere el sistema ?
¿ para qué se requiere ?
¿ cómo se requiere ?
Diagrama Dinámico [ actividades ]
¿ que actores están presentes en el escenario del problema ?
¿ que acciones importantes realizan?
¿ interactúan ?
javiergs@acm.org

50. 2.2.
Modelado:
Objetos

51. Objetos y Vínculos (asociaciones)
El Modelado de Objetos permite representar el ciclo de vida de los objetos a
través de sus interacciones (asociación ó vinculo)
En UML, un objeto se representa por un rectángulo con un nombre
subrayado y estos se pueden relacionar
CuentaCorriente 101
O o
tro bjeto Juan
Unobjeto Bancode Valencia
Banco
O objetom
tro ás
Felipe
CuentaCorriente 114
javiergs@acm.org

52. Objetos y Clases
Objeto = Identidad + Estado + Comportamiento
El estado está representado por los valores de los atributos
Un atributo toma un valor en un dominio concreto
Un coche
Azul
979 Kg
70 CV
...
Atributo:Tipo = valor
javiergs@acm.org

53. Preguntas
Ejemplo de interacción
¿identificas nuevos elementos y/o relaciones?
¿esto será un diagrama?
Un Objeto Operación 1
1: Un mensaje Operación 2
Se puede
Otro Objeto Emplear
---
javiergs@acm.org

54. Mensaje – Comportamiento - Estado
Los mensajes navegan por los enlaces, a priori en ambas
direcciones
Estado y comportamiento están relacionados
Ejemplo: no es posible aterrizar un avión si no está volando.
Está volando como consecuencia de haber despegado del
suelo
javiergs@acm.org

55. Mensaje – Comportamiento - Estado
Objeto 1 1: Mensaje A Objeto 2
2: Mensaje C
4: Mensaje E
Objeto 3 Objeto 4
3: Mensaje D
javiergs@acm.org

56. 2.3.
Modelado de la Arquitectura:
Clases

57. Clases
firmaOperacion (n:tipo) visibilidad
Atributo:tipo = valorinicial << estereotipos>>
Paquete::clase { restricciones }
Reglas de visibilidad
Motocicleta Atributo público : Integer
color lista Atributo protegido : Integer
cilindrada Atributo privado : Integer
velocidad máxima primero()
ultimo() "Operación pública"()
arrancar() añadir() "Operación protegida"()
acelerar() quitar() "Operación privada"()
frenar() cardinalidad()
javiergs@acm.org

58. Paquete
Todas las clases no son
necesariamente visibles desde el
exterior del paquete, es decir, un
paquete encapsula a la vez que agrupa
El operador “::” permite designar una
clase definida en un contexto distinto
del actual
javiergs@acm.org

59. Visibilidad
Los niveles de encapsulación están heredados de los niveles de C++:
(-) Privado : es el más fuerte. Esta parte es totalmente invisible (excepto para
clases friends en terminología C++)
(#) Los atributos/operaciones protegidos están visibles para las clases friends
y para las clases derivadas de la original
(+) Los atributos/operaciones públicos son visibles a otras clases (cuando se
trata de atributos se está transgrediendo el principio de encapsulación)
javiergs@acm.org

60. Relaciones entre Clases
Los enlaces entre de objetos pueden representarse entre las respectivas
clases.
Formas de relación entre clases:
Asociación
Agregación (vista como un caso particular de asociación)
Generalización/Especialización
Las relaciones de Agregación y Generalización forman jerarquías de
clases
javiergs@acm.org

61. Asociación
La asociación expresa una conexión bidireccional entre objetos
Una asociación es una abstracción de la relación existente en los enlaces entre
los objetos
ITESM
Univ. de Murcia : Universidad Un enlace Antonio : Estudiante
ó vinculo
U n iv e rs id a d E s tu d ia n te
U n a a s o cia ció n
Rol – nombre – dirección – cardinalidad - { restricciones} – asociación calificada
javiergs@acm.org

62. Asociación
¿identificas nuevos elementos y/o relaciones?
¿esto será un diagrama?
marido
casado-con
0..1
mujer
0..1 Persona Compañía
nombre * trabaja-para nombre
s.s. dirección
emplea-a *
jefe 0..1
*
Administra
empleado
javiergs@acm.org

63. Cardinalidad
Especificación de multiplicidad (mínima...máxima)
1 Uno y sólo uno
0..1 Cero o uno
M..N Desde M hasta N (enteros naturales)
* Cero o muchos
0..* Cero o muchos
1..* Uno o muchos (al menos uno)
La multiplicidad mínima >= 1 establece una restricción deexistencia
javiergs@acm.org

64. Asociación
Member-of * Committee
Person *
{ subset }
1 Chair-of *
Represents an
incorporated entity.
worker Person employee employer Company
* * 0..1
0..1
boss
{Person.employer =
Person.boss.employer}
javiergs@acm.org

65. Asociación
Persona
*
Cuenta *
or Asociación excluyente
* Empresa
1
Usuario está-autorizado-en Estación
* *
Autorización
Clase de asociación
prioridad
privilegios
camb_privil()
javiergs@acm.org

66. Agregación
La agregación representa una relación parte_de entre objetos
¿Puede el objeto parte comunicarse directamente con objetos externos al objeto
agregado?
No => inclusiva
Si => no inclusiva
¿Puede cambiar La composición del objeto agregado?
Si => dinámica
No => estática
javiergs@acm.org

67. Agregación
Polígono contiene Punto
Agregación 1
3..*
{ordenado}
W in d o w
s c r o llb a r [2 ] : S lid e r
title : H e a d e r
body : Panel
Y podría colocar
aquí un -- OR –
¿?
W in d o w
1 1
1
s c r o llb a r
2 title 1 b o dy 1
S lid e r H e a de r Panel composición
javiergs@acm.org

68. Diagramas de Clases y Diagrama de Objetos
Diagrama de Clases y Diagramas de Objetos pertenecen a dos vistas
complementarias del modelo
Un Diagrama de Clases muestra la abstracción de una parte del dominio
Un Diagrama de Objetos representa una situación concreta del dominio
Las clases abstractas no son instanciadas
ClaseAbstract <<interface>> Clase
nombre
Interface
javiergs@acm.org

69. Generalización y Especialización
Generalización y Especialización no son operaciones reflexivas ni simétricas pero
sí transitivas
Vehículo
Particionamiento
del espacio de objetos
Clasificación Estática
Particionamiento Veihículo Terrestre Vehículo Aéreo
del espacio de estados de los objetos
Clasificación Dinámica
Coche Camión Avión Helicóptero
javiergs@acm.org

70. Generalización y Especialización
Ve hícu lo Aéreo Coche
{ estática } { dinámica }
Avión Helicóptero Funcionando Estropeado
javiergs@acm.org

71. Generalización y Especialización
Ejemplo: varias especializaciones a partir de la misma clase padre,
usando discriminadores:
Comercial Militar
uso
Vehículo Aéreo
estructura
Avión Helicóptero
javiergs@acm.org

72. Herencia Múltiple
Uso disciplinado de la herencia múltiple: clasificaciones disjuntas con clases
padre en hojas de jerarquías alternativas
Bípedo Cuadrúpedo
nro patas nro patas
Con Pelos Herbívoro
cubertura comida
Animal
Con Plumas cobertura
comida
cobertura Carnívoro
Con Escamas
Conejo
javiergs@acm.org

73. Principio de Sustitución
El Principio de Sustitución de Liskow (1987) afirma que:
“Debe ser posible utilizar cualquier objeto instancia de una subclase en el lugar de
cualquier objeto instancia de su superclase sin que la semántica del programa
escrito en los términos de la superclase se vea afectado.”
i.e. Polimorfismo
El polimorfismo representa en nuestro caso la posibilidad de desencadenar
operaciones distintas en respuesta a un mismo mensaje
La búsqueda automática del código que en cada momento se va a ejecutar es
fruto del enlace dinámico
javiergs@acm.org

74. Polimorfismo
Ejemplo: todo animal duerme, pero cada clase lo hace de forma distinta
Animal Dormir()
{
dormir()
}
León Oso Tigre
dormir() dormir() dormir()
Dormir() Dormir() Dormir()
{ { {
sobre el vientre sobrela espalda en un árbol
} } }
javiergs@acm.org

75. Anexo
Dependencia
javiergs@acm.org

76. Práctica 3
Titulo
Resumen
Contenido
Foto
archivos anexos
reportero
admin
usuario
javiergs@acm.org

77. Resumen
Diagrama de Clases
Es el el diagrama principal de diseño y análisis para un sistema.
Durante el análisis del sistema, el diagrama se desarrolla buscando una
solución ideal.
Durante el diseño, se usa el mismo diagrama, y se modifica para satisfacer los
detalles de las implementaciones
Diagrama de Objetos
Especialmente útiles para modelar estructuras de datos complejas.
Evidentemente puede existir una multitud de posibles instancias de una clase
particular, y para un conjunto de clases con N relaciones entre ellas, pueden
existir muchas más configuraciones posibles de objetos.
Diagramas de Colaboración y de Secuencia
javiergs@acm.org

78. javiergs@acm.org

79. 3.1.
Modelado:
Casos de Uso

80. Casos de Uso
Los Casos de Uso (Ivar Jacobson) describen bajo la forma de acciones y
reacciones el comportamiento de un sistema desde el punto de vista de un
observador externo y/o el propio usuario.
Permiten definir los límites del sistema y las relaciones entre el sistema y el
entorno
Los Casos de Uso son descripciones de la funcionalidad del sistema
independientes de la implementación. Describe el QUE más que el COMO
Los Casos de Uso cubren la carencia existente en métodos previos (OMT,
Booch) en cuanto a la determinación de requisitos
Los Casos de Uso particionan el conjunto de necesidades atendiendo a la
categoría de usuarios que participan en el mismo
Están basados en el lenguaje natural, es decir, son accesibles para los
usuarios (hasta cierto punto)
javiergs@acm.org

81. Diagrama de Casos de Uso
Caso de Uso A
Actor A
Caso de Uso B
Actor B
javiergs@acm.org

82. Relación entre los resultados
Modelo de
Casos de Uso verificado por
especificado por
realizado por
Modelo de
distribuido por Prueba
Modelo de
Análisis
Modelo de implementado por
Diseño
Modelo de
Despliegue
Modelo de
Implementación
Los casos de uso intervienen durante todo el ciclo de vida.
El proceso de desarrollo estará dirigido por los casos de uso
javiergs@acm.org

83. Actores
Tipos de Actores:
Principales: personas que usan el sistema.
Secundarios: personas que mantienen o administran el sistema.
Material externo: dispositivos materiales imprescindibles que forman parte del
ámbito de la aplicación y deben ser utilizados.
Otros sistemas: sistemas con los que el sistema interactúa
La misma persona física puede interpretar varios papeles ( actores distintos )
El nombre del actor describe el papel desempeñado
javiergs@acm.org

84. Relaciones: comunicación
UML define cuatro tipos de relación en los Diagramas de Casos de Uso:
1. Comunicación
C aso de U so
Actor
javiergs@acm.org

85. Relaciones: inclusión
2. Inclusión
una instancia del Caso de Uso origen incluye también el
comportamiento descrito por el Caso de Uso destino
<<include>>
Caso de Uso Origen Caso deUso Destino
<<include>> reemplaza a <<uses>>
javiergs@acm.org

86. Relaciones: extensión
3. Extensión
el Caso de Uso origen extiende el comportamiento del Caso de
Uso destino
<<extend>>
Caso de Uso Origen Caso deUso Desti no
javiergs@acm.org

87. Relaciones: herencia
4. Herencia
el Caso de Uso origen hereda la especificación del Caso de Uso destino
y posiblemente la modifica y/o amplía
Caso de UsoHijo Caso de Uso Padre
javiergs@acm.org

88. Ejemplo
Ide n i i caci ó
tf n
<<include>>
Transferencia
Cliente
<< exten d>>
Transferencia en Internet
javiergs@acm.org

89. Ejemplo
Supply Customer Data Order Product
Arrange Payment
<<include>> <<include>>
<<include>>
the salesperson asks
for the catalog
1 * <<extend>>
Salesperson Request Catalog
Place Order
javiergs@acm.org

90. Ejemplo
frontera
estereotipo
generalización
orden irrelevante
javiergs@acm.org

91. Escenario
Los Casos de Uso se determinan observando y precisando, actor por actor,
las secuencias de interacción, los escenarios, desde el punto de vista del
usuario
Un escenario es una instancia de un caso de uso
javiergs@acm.org

92. Construcción de Casos de Uso
Un caso de uso debe ser simple, inteligible, claro y conciso
Generalmente hay pocos actores asociados a cada Caso de Uso
Preguntas clave:
¿cuáles son las tareas del actor?
¿qué información crea, guarda, modifica, destruye o lee el actor?
¿debe el actor notificar al sistema los cambios externos?
¿debe el sistema informar al actor de los cambios internos?
javiergs@acm.org

93. Descripción
La descripción del Caso de Uso comprende:
objetivo del caso de uso: ¿qué lleva a cabo o intenta?
el inicio: cuándo y qué actor lo produce?
el fin: cuándo se produce y qué valor devuelve?
la interacción actor-caso de uso: qué mensajes intercambian ambos?
cronología y origen de las interacciones
repeticiones de comportamiento: ¿qué operaciones son iteradas?
situaciones opcionales: ¿qué ejecuciones alternativas se presentan en el
caso de uso?
javiergs@acm.org

94. Documento
R F - < id d e l r e q u is ito > < n o m b r e d e l r e q u is ito fu n c io n a l>
V e r s ió n < n u m e r o d e v e r s ió n y f e c h a >
A u to re s < a u to r>
F u e n te s < f u e n t e d e la v e r s ió n a c t u a l>
O b je tiv o s a s o c ia d o s < n o m b r e d e l o b je t iv o >
D e s c r ip c ió n E l s is t e m a d e b e r á c o m p o r t a r s e t a l c o m o s e d e s c r ib e e n
e l s ig u ie n t e c a s o d e u s o { c o n c r e t o c u a n d o < e v e n t o d e
a c t iv a c ió n > , a b s t r a c t o d u r a n t e la r e a liz a c ió n d e lo s
c a s o s d e u s o < lis t a d e c a s o s d e u s o > }
P r e c o n d ic ió n < p r e c o n d ic ió n d e l c a s o d e u s o >
S e c u e n c ia Paso A c c ió n
N o rm a l 1 { E l < a c t o r > , E l s is t e m a } < a c c ió n r e a liz a d a p o r e l
a c t o r o s is t e m a > , s e r e a liz a e l c a s o d e u s o
< c a s o d e u s o R F -x >
2 S i < c o n d ic ió n > , { e l < a c t o r > , e l s is t e m a } < a c c ió n
r e a liz a d a p o r e l a c t o r o s is t e m a > > , s e r e a liz a e l
c a s o d e u s o < c a s o d e u s o R F -x >
3
4
5
6
n
P o s tc o n d ic ió n < p o s t c o n d ic ió n d e l c a s o d e u s o >
E x c e p c io n e s Paso A c c ió n
1 S i < c o n d ic ió n d e e x c e p c ió n > , { e l < a c t o r > , e l
s is t e m a } } < a c c ió n r e a liz a d a p o r e l a c t o r o
s is t e m a > > , s e r e a liz a e l c a s o d e u s o
< c a s o d e u s o R F - x > , a c o n t in u a c ió n e s t e c a s o
d e u s o { c o n t in u a , a b o r t a }
2
3
R e n d im ie n to Paso C o ta d e tie m p o
1 n segundos
2 n segundos
F r e c u e n c ia e s p e r a d a < n º d e v e c e s > v e c e s / < u n id a d d e t ie m p o >
Im p o r ta n c ia { s in im p o r t a n c ia , im p o r t a n t e , v it a l}
U r g e n c ia { p u e d e e s p e r a r , h a y p r e s ió n , in m e d ia t a m e n t e }
C o m e n ta r io s < c o m e n t a r io s a d ic io n a le s >
javiergs@acm.org

95. Práctica 4
Titulo
Resumen
Contenido
Foto
archivos anexos
reportero
admin
usuario
javiergs@acm.org

96. Práctica 4
Casos de Uso
javiergs@acm.org

97. Resumen
La especificación de cada caso de uso y los correspondientes diagramas de
Interacción asociados establecen el vínculo con el modelo conceptual
En las metodologías Orientadas a Objeto que carecían de una técnica de captura
de requisitos se comienza inmediatamente con la construcción del modelo
conceptual (análisis).
javiergs@acm.org

98. javiergs@acm.org

99. 4.1.
Modelado:
Diagramas de Interacción
Secuencia y Colaboración

100. Interacción
Los objetos interactúan para realizar colectivamente los servicios ofrecidos por las
aplicaciones. Los diagramas de interacción muestran cómo se comunican los
objetos en una interacción
Existen dos tipos de diagramas de interacción:
El Diagrama de Secuencia adecuados para observar la perspectiva
cronológica de las interacciones.
El Diagrama de Colaboración ofrece una mejor visión espacial mostrando los
enlaces de comunicación entre objetos
El Diagrama de Colaboración puede obtenerse automáticamente a partir del
correspondiente Diagrama de Secuencia (o viceversa)
javiergs@acm.org

101. Sintaxis para Mensajes
predecesor / guarda secuencia: retorno := mensaje( args )
javiergs@acm.org

102. Diagrama de Secuencia
Muestra la secuencia de mensajes entre objetos durante un escenario
concreto
Cada objeto viene dado por una barra vertical
El tiempo transcurre de arriba abajo
Cuando existe demora entre el envío y la atención se puede indicar usando
una línea en diagonal
javiergs@acm.org

103. Diagrama de Secuencia
Describen cómo los objetos del sistema colaboran.
Detalla cómo las operaciones se llevan a cabo en
términos de qué mensajes son enviados y cuando
(en torno al tiempo).
tiempo
Los corchetes expresan condición [condición].
Si son precedidos por “*” iteración mientras.
Línea de vida obj.
Su vida termina.
Orden participación
javiergs@acm.org

104. Diagrama de Secuencia
Diagrama de Secuencia:
Los rectángulos verticales son barras de activación. Representan la duración de la
ejecución del mensaje.
Mensaje asíncronos: El emisor puede enviar otros mientras éste está siendo procesado.
Es independiente a otros mensajes.
Mensaje síncronos: El emisor debe esperar que termine el tiempo de proceso de éste
para enviar nuevos mensajes.
Mensaje simple Mensaje simple Síncrono
puede ser síncrono de vuelta (opt) Asíncrono
o asíncrono
javiergs@acm.org

105. Diagrama de Secuencia
javiergs@acm.org

106. Diagrama de Secuencia
Caller Exchange Receiver
a: lift receiver
{b.receiveTime b: dial tone
- a.sendTime < 1 sec.}
{c.receiveTime c: dial digit
-b.sendTime < 10 sec.}
...
The call is routed d: route
through the network
{d.receiveTime ringing tone phone rings
-d.sendTime < 5 sec.}
answer phone -----
< 1 sec
At this point the stop tone stop ringing -----
parties can talk
javiergs@acm.org

107. Diagrama de Secuencia
ob 3 : C3 ob4 : C 4
Condiciones op( ) ob 1 : C1
[x > 0 ] f o o l( x ) ob2 : C2
[x < 0 ] b a r (x )
d o it ( z )
Recursion d o it ( w )
Creación y
Destrucción m o re ( )
De Objetos
javiergs@acm.org

108. Diagrama de Secuencia
Diagram 1
ob1 : C1
[x<0] bar(x)
Diagram 2
ob3 : C3 ob4 : C4
Sequence Diagram:
Diagrams / Diagram 2
bar(x)
doit(w)
Sequence Diagram:
Diagrams / Diagram 1
javiergs@acm.org

109. Diagrama de Colaboración
Son útiles en la fase exploratoria para identificar objetos
La distribución de los objetos en el diagrama permite observar adecuadamente
la interacción de un objeto con respecto de los demás
La estructura estática viene dada por los enlaces; la dinámica por el envío de
mensajes por los enlaces
javiergs@acm.org

110. Diagrama de Colaboración
Son otro tipo de diagramas de interacción. Contienen la misma información que los
diagramas de secuencia, pero se centran en la responsabilidad de cada objeto en lugar
de en el tiempo en que los mensajes son enviados
Cada mensaje tiene un número de secuencia. El primer nivel comienza en 1, los
mensajes que son enviados durante la misma llamada a un método se numeran
1.1, 1.2 ... 1.i, tantos niveles como sea necesario.
javiergs@acm.org

111. Mensajes
Un mensaje desencadena una acción en el objeto destinatario
Un mensaje se envía si han sido enviados los mensajes de una lista
(sincronización):
1, 3 / 10:Mensaje B
A
javiergs@acm.org

112. Mensajes
Un mensaje se envía de manera condicionada:
[x>y] 1: Mensaje
B
A
javiergs@acm.org

113. Mensajes
Un mensaje que devuelve un resultado:
1: distancia:= mover(x,y)
B
A
javiergs@acm.org

114. Secuencia vs Colaboración
: WInP réstamos :Socio :Video : Préstamo
: Encargado
prestar(video, socio)
verificar situación socio
verificar situación video
registrar préstamo
entregar recibo
javiergs@acm.org

115. Secuencia vs Colaboración
:Socio
:Video
2: verificar situación socio
1: prestar(video, socio) 3: verificar situación video
:WInPréstamos
5: entregar recibo
: Encargado 4: registrar préstamo
:Préstamo
javiergs@acm.org

116. Anexos
Crear objeto en diagrama de colaboración amerita el uso de un
estereotipo
Manejar estados en el diagrama de secuencia se representa
con un rectángulo redondeado en la línea de tiempo
Manejar estados en el diagrama de colaboración implica
colocar entre [ ] al lado derecho el nombre del estado
(repitiendo al objeto en el diagrama)
javiergs@acm.org

117. Resumen
D. Clases
Escenarios D. Casos de Uso
D. Secuencia D. Colaboración
D. Objetos
Diagramas de Comportamiento
Diagramas de Componentes Deployment
javiergs@acm.org

118. Diagramas por Modelo (estático y dinámico)
M ode lo de l M ode lo de l M ode lo de M ode lo de M ode lo de M ode lo de M ode lo de M ode lo M ode lo de
Ne gocio Dom inio Cas os de Anális is Dis e ño Proce s os De s plie gue Im ple m e n- Prue ba
Us o tación
Es t. Din. Es t. Din. Es t. Din. Es t. Din. Es t. Din. Es t. Din. Es t. Din. Es t. Din. Es t. Din.
Diagram a de
Cas os de Us o X X X
Diagram a de
Inte racción- X X X X X X X X
Se cue ncia
Diagram a de
Inte racción- X X X X X X X X
Colaboración
Diagram a de
Clas e s de X
Anális is
Diagram a de
Obje tos de X
Anális is
Diagram a de
Clas e s de X X
Dis e ño
Diagram a de
Obje tos de X X
Dis e ño
Diagram a de
Es tados X X X X X X
Diagram a de
Actividade s X X X X X
Diagram a de
Com pone nte s X
Diagram a de
De s plie gue X
javiergs@acm.org

119. Práctica 5
Titulo
Resumen
Contenido
Foto
archivos anexos
reportero
admin
usuario
javiergs@acm.org

120. javiergs@acm.org

121. 5.1.
Modelado:
Estados

122. Diagrama de Estados
Los Diagramas de Estados representan autómatas de estados finitos, desde
el punto de vista de los estados y las transiciones
Son útiles sólo para los objetos con un comportamiento significativo
El formalismo utilizado proviene de los Statecharts ( Harel )
Muestra las condiciones de UN solo objeto
javiergs@acm.org

123. Diagrama de Estados
Cada objeto está en un estado en cierto instante
El estado está caracterizado parcialmente por los valores de algunos
atributos del objeto
El estado en el que se encuentra un objeto determina su comportamiento
Cada objeto sigue el comportamiento descrito en el Diagrama de Estados
asociado a su clase
Los Diagramas de Estados y escenarios son complementarios
javiergs@acm.org

124. Diagrama de Estados
Los Diagramas de Estados son autómatas jerárquicos que permiten expresar
concurrencia, sincronización y jerarquías de objetos
Los Diagramas de Estados son grafos dirigidos
Los Diagramas de Estados de UML son deterministas
Los estados inicial y final están diferenciados del resto
La transición entre estados es instantánea y se debe a la ocurrencia de un
evento
javiergs@acm.org

125. Diagrama de Estados
alta baja
núm ero_prés tam os = 0
sin préstam os
Socio
número : int
nombre : char[50]
número_prestamos : int = 0
prestar devol ver[ núm ero_p rést amo s = 1 ]
alta()
baja()
prestar(código_libro : int, fecha : date)
devolver(código_libro : int, fecha : date) núm ero_prés tam os > 0
c on prés tam os
pres tar
devolver[ núm ero_prés tam os > 1 ]
javiergs@acm.org

126. Ejemplo
c ontratar
en el paro en ac tivo
desempleado
perder em pleo
jubilars e
jubil ars e
jub ilado
javiergs@acm.org

127. Estados y Transiciones
Evento [condición] / Acción
A B
Tanto el evento como la acción se
consideran instantáneos
javiergs@acm.org

128. Acciones
Podemos especificar la solicitud de un servicio a otro objeto como
consecuencia de la transición:
A
Evento [condición] / OtroObjeto.Operación
B
javiergs@acm.org

129. Acciones
Se puede especificar el ejecutar una acción como consecuencia de entrar,
salir, estar en un estado, o por la ocurrencia de un evento:
estado A
entry: acción por entrar
exit: acción por salir
do: acción mientras en estado
on evento: acción
javiergs@acm.org

130. Generalización de Estados
Podemos reducir la complejidad de estos diagramas usando la generalización
de estados
Distinguimos así entre superestado y subestados
Un estado puede contener varios subestados disjuntos
Los subestados heredan las variables de estado y las transiciones externas
javiergs@acm.org

131. Generalización de Estados
e1
A B a
e1
b
A B
e2
e2 e2
C
C
javiergs@acm.org

132. Generalización de Estados
Sin embargo. Las transiciones de entrada deben ir hacia subestados
específicos:
e1
a
A b
B
e2
e0
C
javiergs@acm.org

133. Generalización de Estados
O bien tener estados iniciales de entrada en el nivel
e1
Aa b
B
e2 C
e0
javiergs@acm.org

134. Generalización de Estados
lif t r e c e iv e r
/ g e t d ia l
to n e
A c t iv e
T im e o u t
d o / p la y m e s s a g e
a f t e r ( 1 5 s e c .) d ia l d ig it ( n ) [ in c o m p le t e ]
a f t e r ( 1 5 s e c .)
D ia lT o n e d ia l d ig it ( n ) D ia lin g
d o / p l a y d i a l to n e
Id le
di a l d ig it ( n )[ inv a l id ]
d ia l d ig it ( n ) [ v a lid ]
c a lle r h a n g s u p P in n e d In v a li d / connect
/ d i sc o n n ec t
d o / p la y m e s s a g e
c a l le e C o n n e c t in g
c a lle e
hang h an g s
s up up
busy
Busy c o n n e c te d
d o / p la y b u s y t o n e
T a lk in g R in g in g
c a lle e a n s w e r s d o / p l a y r i n g i n g to n e
/ e n a b le
speech
javiergs@acm.org

135. Composición de Estados
La composición es concurrente por lo que el objeto estará en alguno de los
estados de cada uno de los subestados concurrentes
e1
e1
javiergs@acm.org

136. Historia
Por defecto, los autómatas no
tienen memoria
A
Es posible memorizar el
último subestado visitado d2
B
para recuperarlo en una
transición entrante en el in
superestado que lo engloba
D x y
out
d1
C
También es posible la
memorización para
cualquiera de los subestados
anidados (aparece un * junto
a la H) H*
javiergs@acm.org

137. Historia
Enjuague Lavado Secado
H
cerrar puerta abir puerta
Espera
javiergs@acm.org

138. Destrucción del Objeto
La destrucción de un objeto es efectiva cuando el flujo de control del autómata
alcanza un estado final no anidado
La llegada a un estado final anidado implica la “subida” al superestado
asociado, no el fin del objeto
c ras h
E n vuelo
des pegar aterriz ar
Crear(m atric ula)
E n t ierra
javiergs@acm.org

139. Transiciones temporizadas
Las esperas son actividades
que tienen asociada cierta A
duración
/ Abrir ranura
La actividad de espera se
interrumpe cuando el evento
después de
esperado tiene lugar esperar dinero
30 segundos
entry: Mostrar mensaje anular
transacción
Este evento desencadena una exit: cerrar ranura
transición que permite salir del
estado que alberga la actividad
de espera. El flujo de control
se transmite entonces a otro Depósito efectuado
estado
B
javiergs@acm.org

140. Estados Sincronizados
Los estados pueden anidarse, agrupando estados relacionados en un estado
compuesto.
Puede ser necesario cuando una actividad involucra actividades concurrentes o
asíncronas.
javiergs@acm.org

141. Resumen
Los Diagramas de Estados facilitan la comprensión de los objetos a
analistas, diseñadores y desarrolladores
javiergs@acm.org

142. Práctica 6
Titulo
Resumen
Contenido
Foto
archivos anexos
reportero
admin
usuario
javiergs@acm.org

143. 5.2.
Modelado:
Actividades

144. Diagrama de Actividad
El Diagrama de Actividad es una especialización del Diagrama de Estado,
organizado respecto de las acciones y usado para especificar:
• Un método
• Un caso de uso
Las actividades se enlazan por transiciones automáticas.
Cuando una actividad termina se desencadena el paso a la siguiente actividad
javiergs@acm.org

145. Diagrama Dinámico: Actividades
Son diagramas de flujo
adornados, con mucha
similitud a los diagramas
de estados.
Mientras los diagramas de
estados centran su
atención en el proceso
que lleva a cabo un
objeto, los diagramas de
actividades muestran
como las actividades
fluyen y las dependencias
entre ellas.
javiergs@acm.org

146. Ejemplo
Customer Sales Stockroom
Request
service
Take order
Play
Fill order
Deliver order
Collect
order
javiergs@acm.org

147. Ejemplo
C u st o m er S ales S t o ckro o m
Re q ue st se rv i c e O rd e r
[p la c e d ]
T a k e o rd e r O rd e r
[e n te r e d ]
P la y
F i l l o rd e r
O rd e r D e l i v e r o rd e r O rd e r
[d e live r ed ] [fille d ]
C o l l e c t o rd e r
javiergs@acm.org

148. Ejemplo
B u s c a r B e b id a [ n o h a y c a fé ] [ no zumo ]
[ h a y c a fé ]
[ hay z um o ]
P o n e r c a fé A ñ ad i r a g u a C o g e r ta z a
e n filtro a l d e p ós ito C oger
zumo
P o n e r filtro
e n m á q u in a
Encender
m áq u in a
/ c a fe t e ra .O n
C afé e n
p re p a ra c ió n
i n di c a do r d e fi n
S e rv ir c a fé B eber
javiergs@acm.org

149. Ejemplo
P a s a j e ro V ende do r A i r l i ne
S o lic it a r
p a s a je
V e r if ic a r
e x is t e n c ia v u e lo
D a r d e t a lle s
v u e lo
I n fo r m a r a lt e r n a ti v a s y
p r e c io s
S e le c c io n a r
v u e lo
S o lic it a r R e s e rv a r
pago pla z as
C o n fir m a r p la z a
Pagar re s e rv a d a
p a s a je
E m itir
b i ll e t e
javiergs@acm.org

150. Práctica 7
Titulo
Resumen
Contenido
Foto
archivos anexos
reportero
admin
usuario
javiergs@acm.org

151. 6.1.
Para recordar:
programando objetos

152. Herencia, Interfase, Polimorfismo, static, et al.
Libro Revista Imagen
precio año path
isbn volumen mimet ype Documento
imprimir() imprimir() pint ar()
imprimir()
1
Configuracion
BackgroundColor
FontColor
0.. 1
leerArchivoCfg() Acervo
t itulo
resumen
0.. n keywords
imprimir()
Bibliot eca
GUI
1
llenar()
main()
inventario()
javiergs@acm.org

153. 6.2.
Modelado:
componentes

154. Diagrama de Componentes
Los diagramas de componentes describen los elementos físicos del sistema y
sus relaciones
Muestran las opciones de realización incluyendo código fuente, binario y
ejecutable
Las relaciones de dependencia se utilizan en los diagramas de componentes
para indicar que un componente utiliza los servicios ofrecidos por otro
componente
Tipos de Componentes:
De distribución: DLL, EXE, Java Beans o controles ActiveX
De trabajo: archivos de base de datos y de codigo fuente
De ejecución: creados por/para la ejecución del sistema (archivos)
javiergs@acm.org

155. ...Diagrama de Componentes
Paquete::componente
Listar clases
logo.gif
javiergs@acm.org

156. Componentes y su distribución
javiergs@acm.org

157. Notación
NewPackageSpec NewMainSubprog
NewPackageBody
NewSubprogSpec
NewComponent
javiergs@acm.org

158. 6.3.
Modelado:
deployment

159. Diagrama de despliegue/deployment
Muestra la disposición física de los distintos nodos que componen un sistema
y el reparto de los componentes sobre dichos nodos
Los estereotipos permiten precisar la naturaleza del equipo:
Dispositivos
Procesadores
Memoria
Los nodos se interconectan mediante soportes bidireccionales que pueden a
su vez estereotiparse
NewP rocessor
NewDevice N od o
javiergs@acm.org

160. BIOS
javiergs@acm.org
4.17. El UML

161. Diagrama de despliegue/deployment
Podemos distinguir tipos de nodos y conexiones por estereotipado
<<Cliente>> <<Servidor>>
Terminal Punto <<TCP/IP>>
Base de
de Venta Datos
<<RDSI>>
<<RDSI>>
Control
javiergs@acm.org

162. Combinación
Servidor Central Control y Análisis
Acceso a BD C
C
Rutinas de Coneccion
C
Terminal de Consulta
Interfaz de Terminal
Rutinas de Coneccion
C C
Punto de Venta
Rutinas de Coneccion
C
Gestión de Cuentas Interfaz de Terminal
C C
javiergs@acm.org

163. Práctica 8
Titulo
Resumen
Contenido
Foto
archivos anexos
reportero
admin
usuario
javiergs@acm.org

164. 6.4.
Modelado:
RUP

165. Proceso de Desarrollo de Software
Define Quién debe hacer Qué, Cuándo y Cómo debe hacerlo
PRINCIPIOS DE
PRINCIPIOS DE
LA INGENIERÍA DEL SOFTWARE
LA INGENIERÍA DEL SOFTWARE
NORMAS
TÉCNICAS
NORMAS DE
NORMAS DE OTRAS
LA INGENIERÍA DEL SOFTWARE NORMAS
LA INGENIERÍA DEL SOFTWARE
ESTÁNDARES
MODELOS DE METODOLOGÍAS
METODOLOGÍAS
MODELOS DE
PROCESO / /PARADIGMAS
PARADIGMAS
PROCESO
PROCESO RUP
TÉCNICAS
TÉCNICAS HERRAMIENTAS
HERRAMIENTAS
PRODUCTO
No existe un proceso de software universal. Las características de cada proyecto
(equipo de desarrollo, recursos, etc.) exigen que el proceso sea configurable
javiergs@acm.org

166. Rational Unified Process
Rational Unified Process • Pruebas funcionales
1998
• Pruebas de desempeño
• Gestión de requisitos
Rational Objectory Process
• Gestión de cambios y
1996-1997
configuración
• Ingeniería de Negocio
Objectory Process • Ingeniería de datos
1987-1995
• Diseño de interfaces
javiergs@acm.org

167. RUP es iterativo
Un enfoque iterativo propone una comprensión incremental del problema a
través de refinamientos sucesivos y un crecimiento incremental de una solución
efectiva a través de varias versiones.
Como parte del enfoque iterativo se encuentra la flexibilidad para acomodarse a
nuevos requisitos o a cambios tácticos en los objetivos del negocio.
Permite que el proyecto identifique y resuelva los riesgos más bien pronto que
tarde.
javiergs@acm.org

168. RUP es centrado en la arquitectura
El proceso se centra en establecer al principio una arquitectura de software que
guía el desarrollo del sistema:
La arquitectura de un sistema es el conjunto de decisiones significativas que se
toma en torno a su organización, la selección de elementos estructurales, la
definición de las interfaces entre estos elementos, su comportamiento, su
división en subsistemas, qué elementos son estáticos y cuales dinámicos.
Este diseño arquitectónico sirve como una sólida base sobre la cual se puede
planificar y manejar el desarrollo de software basado en componentes.
javiergs@acm.org

169. RUP esta dirigido por casos de uso
El Proceso Unificado pone un gran énfasis en la construcción de sistemas
basada en una amplia comprensión de cómo se utilizará el sistema que se
entregue.
Las nociones de los casos de uso y los escenarios se utilizan para guiar el
flujo de procesos desde la captura de los requisitos hasta las pruebas, y
para proporcionar caminos que se pueden reproducir durante el desarrollo del
sistema.
javiergs@acm.org

170. RUP es un proceso configurable
Aunque un único proceso no es adecuado para todas las organizaciones de
desarrollo de software, el Proceso Unificado es adaptable y puede configurarse
para cubrir las necesidades de proyectos que van desde pequeños equipos
de desarrollo de software hasta grandes empresas de desarrollo.
También se basa en una arquitectura de proceso simple y clara, que
proporciona un marco común a toda una familia de procesos y que, además,
puede variarse para acomodarse a distintas situaciones.
javiergs@acm.org

171. RUP es orientado a objetos
Los modelos del Proceso Unificado se basan en los conceptos de objeto y clase
y las relaciones entre ellos.
javiergs@acm.org

172. RUP impulsa control de calidad
La evaluación de la calidad va contenida en el proceso, en todas las
actividades, e implicando a todos los participantes, mediante medidas y criterios
objetivos. No se trata como algo a posteriori o una actividad separada.
La gestión del riesgo va contenida en el proceso, de manera que los riesgos
para el éxito del proyecto se identifican y se acometen al principio del proceso
de desarrollo, cuando todavía hay tiempo de reaccionar.
javiergs@acm.org

173. RUP es matricial
RUP tiene una estructura matricial donde se relacionan esfuerzos y tiempos
Los tiempos están definidos por las fases y las iteraciones.
Los esfuerzos están definidos por los flujos de trabajo del proceso y de
soporte.
La representación gráfica se denomina en la jerga el Diagrama de Montañas.
javiergs@acm.org

174. Ciclo de vida en RUP
Flujos de trabajo fases
del proceso Iniciación Elaboración Construcción Transición
Modelado del
negocio
Requisitos
Análisis y diseño
Implementación
Pruebas
Despliegue
Flujos de trabajo
de soporte
Gestión del cambio
y configuraciones
Gestión del proyecto
Entorno
Iteraciones Iter Iter Iter Iter Iter Iter Iter
preliminares #1 #2 #n #n+1 #n+2 #m #m+1
Fuente: Jacobson et al., 2000
javiergs@acm.org

175. Elementos
Los resultados de los flujos de trabajo de proceso son los MODELOS.
La conjunción de tiempo (fases) y esfuerzos (flujos de trabajo) da lugar a las
iteraciones.
La conjunción de resultados (modelos) y esfuerzos (flujos de trabajo) da lugar a
los tipos de modelos.
La conjunción de tiempo (fases) y resultados (modelos) da lugar a las
versiones.
Se puede representar esta estructura conceptual (metamodelo) mediante una
figura tridimensional donde:
Eje X: Fases tiempo
Eje Y: Flujos de trabajo esfuerzos
Eje Z: Modelos resultados
javiergs@acm.org

176. Metamodelo
resultados
Z: Modelos
(x,z): versiones
X,Y,Z:
(y,z): tipos de Configuraciones
modelos del sistema
tiempo
X: Fases
esfuerzo
Y: Flujos (x,y): iteraciones
de trabajo
javiergs@acm.org

177. Fases
Iniciación.
Se establece la planificación del proyecto y se delimita su alcance.
Elaboración.
Se analiza el dominio del problema, se establece una base arquitectónica
sólida, se desarrolla el plan del proyecto y se eliminan los elementos de más
alto riesgo del proyecto.
Construcción.
Se desarrolla de forma iterativa e incremental un producto completo que está
preparado para la transición hacia la comunidad de usuarios.
Transición.
El software se despliega en la comunidad de usuarios.
javiergs@acm.org