Contenido

§ Introducción: Modelado de SI
Análisis y Diseño § Breve Tour por UML
§ El Paradigma Orientado a Objetos
Orientado a Objetos usando – Fundamentos del Modelado OO
– Captura de Requisitos
la notación UML – Modelado de Interacciones
– Modelado de la Estructura del Sistema
Ing. Mario Alberto Pérez – Diagramas de Estados
Universidad Nacional de Colombia – Modelado de Componentes
– Modelado de Distribución
§ Proceso de Desarrollo de SW con UML
Basada en material de la Universidad Politécnica de Valencia § Conclusiones
1 2

Construcción de una casa para “fido”

Introducción: Modelado de SI
Puede hacerlo una sola persona
Requiere :
Modelado mínimo
Proceso simple
Herramientas simples

3 4

Construcción de una casa Construcción de un rascacielos

Construida eficientemente y en un tiempo

razonable por un equipo
Requiere :
Modelado
Proceso bien definido
Herramientas más sofisticadas
5 6

1
 Claves en Desarrollo de SI Abstracción - Modelado Visual (MV)

“El modelado captura las

Notación partes esenciales del sistema ”

Orden

Item

envío

Proceso de Negocios
Herramientas Proceso
Sistema Computacional
7 8

MV para definir la Arquitectura

MV para manejar la complejidad del Software
Interfaz de Usuario
(Visual Basic,
Java, ..)
Lógica del Negocio
(C++, Java, ..)

Servidor de BDs
(C++ & SQL, ..)

“Modelar el sistema independientemente

9
del lenguaje de implementación” 10

MV promueve la reutilización

Múltiples Sistemas

Breve Tour por UML

Componentes
Reutilizados

11 12

2
¿Qué es UML? Situación de Partida
§ UML = Unified Modeling Language § Diversos métodos y técnicas OO, con muchos aspectos
en común pero utilizando distintas notaciones
§ Un lenguaje de propósito general para el
modelado orientado a objetos § Inconvenientes para el aprendizaje, aplicación,
§ Documento “OMG Unified Modeling Language construcción y uso de herramientas, etc.
Specification” § Pugna entre distintos enfoques (y correspondientes
§ UML combina notaciones provenientes desde: gurús)
• Modelado Orientado a Objetos
• Modelado de Datos => Necesidad de una notación estándar
• Modelado de Componentes
• Modelado de Flujos de Trabajo (Workflows)

13 14

Historia de UML
Historia de UML
2001 ? UML 2.0

§ Comenzó como el “Método Unificado”, con la 2000 UML 1.4

participación de Grady Booch y Jim Rumbaugh. 1999 UML 1.3

Revisiones menores
1998
Se presentó en el OOPSLA’95 Nov ‘97 UML aprobado por el OMG
UML 1.2

§ El mismo año se unió Ivar Jacobson. Los “Tres

Amigos” son socios en la compañía Rational
Software. Herramienta CASE Rational Rose

15 16

Participantes en UML 1.0 UML “aglutina” enfoques OO

§ Rational Software § MCI Systemhouse Rumbaugh
(Grady Booch, Jim Rumbaugh y § Microsoft
Ivar Jacobson) Booch Jacobson
§ Digital Equipment § ObjecTime
Odell
§ Hewlett-Packard § Oracle Corp. Meyer
§ i-Logix (David Harel) § Platinium Technology Pre- and Post-conditions

Shlaer-Mellor
§ IBM § Sterling Software Objectlife cycles
UML
§ ICON Computing Harel
§ Taskon State Charts
(Desmond D’Souza) Gamma et. al.
§ Texas Instruments
§ Intellicorp and James Frameworks, patterns,

Unisys
notes
Martin & co. (James Odell) § Embly Wirfs-Brock
Singleton classes Responsabilities
Fusion
Operation descriptions,
message numbering
17 18

3
Aspectos Novedosos Métodos Formales en Modelado
§ Definición semi-formal del Metamodelo de UML § Tipos de enfoques: no-formales, semi-formales y
formales
§ Mecanismos de Extensión en UML:
§ Stereotypes § Las principales mejoras al utilizar métodos formales
son:
§ Constraints
• Mayor rigor en la especificación
§ Tagged Values
• Mejores condiciones para realizar la verificación
Permiten adaptar los elementos de modelado, y validación en forma más exhaustiva
asignándoles una semántica particular • Mejores condiciones para automatización de
Ver UML V1.3 página 2-67 procesos para la generación automática de
prototipos y/o código final

19 20

Inconvenientes en UML Perspectivas de UML

§ Definición del proceso de desarrollo usando § UML será el lenguaje de modelado orientado a
objetos estándar predominante los próximos años
UML. UML no es una metodología
§ Razones:
§ Falta integración con respecto de otras técnicas • Participación de metodólogos influyentes
tales como patrones de diseño, interfaces de • Participación de importantes empresas
usuario, documentación, etc. • Aceptación del OMG como notación estándar
§ Evidencias:
§ Ejemplos aislados • Herramientas que proveen la notación UML
§ “Monopolio de conceptos, técnicas y métodos • “Edición” de libros
• Congresos, cursos, “camisetas”, etc.
en torno a UML”
21 22

Diagramas de UML ... Diagramas de UML

State
State de
Diagrams
Diagramas Diagrama de Casos de Uso
Use
UseCase
Case de Diagrams
Clases State
Use
UseCase
Diagrams
Diagramas
Diagrams
Case de Casos
State de
Diagrams
Diagramas Diagrama de Clase (incluyendo Diagrama de Objetos)
Diagramas
Diagrams de Uso Diagrams
Diagrams Objetos Diagramas de Comportamiento
Secuencia
Diagrama de Estados
Scenario State Diagrama de Actividad
Scenario State
Diagrams
Diagramas
Diagrams de Diagrams
Diagramas de Diagramas de Interacción
Diagrams
Colaboración Modelo Componentes
Diagrama de Secuencia
Scenario Component Diagrama de Colaboración
Scenario de Component
Diagramas de
Diagramas
Diagrams Diagrams
Diagrams Diagramas de implementación
Diagrams Distribución
Estados Diagramas de
Actividad Diagrama de Componentes
Diagrama de Despliegue
“Un modelo es una descripción completa de un sistema desde una perspectiva concreta”
23 24

4
Paquetes en UML
§ Los paquetes ofrecen un mecanismo general
para la organización de los modelos
agrupando elementos de modelado
§ Se representan gráficamente como:
Nombre de
paquete
… Paquetes en UML
§ Cada paquete corresponde a un subconjunto
del modelo y contiene, según el modelo, clases,
objetos, relaciones, componentes y diagramas
asociados
§ Un paquete puede contener otros paquetes, sin
límite de anidamiento pero cada elemento
pertenece a (está definido en) sólo un paquete

25 26

Práctica 1

… Paquetes en UML … Paquetes en UML

§ El operador “::” permite designar una clase
§ Una clase de un paquete puede aparecer en definida en un contexto distinto del actual
otro paquete por la importación a través de una
relación de dependencia entre paquetes § Por ejemplo, la expresión Ventas::Producto
designa la clase Producto definida en el
paquete Ventas
§ Todas las clases no son necesariamente visibles
desde el exterior del paquete, es decir, un
paquete encapsula a la vez que agrupa

27 28

Diagramas de Casos de Uso Ejemplos

§ Casos de Uso es una técnica para capturar Verificar Situación

información de cómo un sistema o negocio

Vendedor

trabaja actualmente, o de cómo se desea que

trabaje Cliente

Establecer Crédito Supervisor

§ No pertenece estrictamente al enfoque

orientado a objeto, es una técnica para captura
de requisitos Preparar Catálogo
Secretaria

Tipos de Venta

29 30

5
… Ejemplos … Ejemplos
En el paquete tipos de venta:

Venta Normal
Realizar préstamo
Socio Encargado

tarjeta caducada

<<extend>>
<<extends>>
Venta en Rebajas
Cliente Vendedor

Solicitar nueva tarjeta

Venta en Oferta
31 32

Práctica 2

… Ejemplos Diagramas de Secuencia

: Libro : Ficha socio : Ficha libro : Préstamo

: Socio : Encargado

Coger libro

Reintegro cuenta corriente <<include>>

<<uses>>

Solicitar préstamo

Verificar situación socio

Situación socio ok
Cliente Validar operación
Verificar situación libro

Situación libro ok
<<uses>>
<<include>>
Introducir préstamo

Autorizar préstamo

Reintegro cuenta crédito

33 34

Práctica 3

Diagramas de Colaboración Diagramas de Clases (y objetos)

1: Coger libro
: Socio 2: Solicitar préstamo
3: Verificar situación socio
8: Autorizar préstamo
6: Situación libro ok : Encargado
5: Verificar situación libro
: Libro
§ El Diagrama de Clases es el diagrama principal para el
análisis y diseño
: Ficha s
ocio
§ Un diagrama de clases presenta las clases y objetos
del sistema con sus relaciones estructurales y de
4: Situación socio ok herencia
§ La definición de clase u objeto incluye definiciones
para atributos y operaciones
7: Introducir préstamo
: Présta
mo § El trabajo realizado en los D. de Casos de Uso, D. de
Secuencia y D. de Colaboración aporta información
para establecer las clases, objetos, atributos y

: Ficha li
bro
operaciones
35 36

6
Ejemplos (Clase y Visibilidad) … Ejemplos (Asociación)

Alumno
DNI : char[10] dirige director
número_exp : int Departamento Profesor
nombre : char[50]
0..1 1

alta()
poner_nota(asignatura : char *, año : int, nota : float)
matricular(cursos : asignatura, año : int)
listar_expediente()

37 38

… Ejemplos (Clase Asociación) … Ejemplos (Generalización)

empleador trabajador
Empresa Empleado
Empleado
* 1..*

Cargo {disjunta, completa}

+superior
nombre
sueldo
0..1

1..* Directivo Administrativo Obrero

+subordinado

39 40

Prácticas 4-8

… Ejemplos Diagramas de Estados

Motor Piloto Vendedor de billetes

alta baja
1..4 1..2 1

número_préstamos = 0
sin préstamos

1 * *
1 * 1 * Socio Biblioteca
Avión Vuelo Reserva
Número : int
Nombre : char[50] prestar devolver[ número_préstamos = 1 ]
* Número préstamos : int = 0
{ disjunta, completa }
Alta()
Baja() número_préstamos > 0
1 Prestar(CódigoLibro : int, Fecha : date)
Devolver(CódigoLibro : int, Fecha : date)
Avión comercial con préstamos
Avión militar Línea aérea

prestar
{ disjunta, completa }

devolver[ número_préstamos > 1 ]

Avión de carga Avión de pasajeros

41 42

7
 Práctica 9

Diagramas de Actividad … Otro Ejemplo (con swim lines)

Pasajero Vendedor Airline
[no zumo]
§ Buscar Bebida
[no hay café]

[hay café [hay zumo]

Solicitar pasaje
Verificar
existencia vuelo
Poner café en filtro Añadir agua al depósito Coger taza
Dar detalles vuelo

Poner filtro en máquina Coger zumo Informar alternativas

y precios
Seleccionar vuelo
Encender máquina
^cafetera.On
Café en preparación Solicitar pago Reservar plazas

Confirmar
indicador de fin Pagar pasaje plaza reservada
Servir café
Beber
Emitir billete

43 44

Práctica 10

Diagramas Componentes Diagramas de Distribución

Servidor Central Control y Análisis
Control y Análisis
Acceso a BD Comment
Interfaz de Terminal
Comment Comment

Comment
Rutinas de Coneccion

Terminal de Consulta
Interfaz de Terminal
Gestión de Cuentas Acceso a BD Rutinas de Coneccion
Rutinas de Coneccion Comment
Comment Comment
Comment Punto de Venta
Rutinas de Coneccion
Comment

Gestión de Cuentas Interfaz de Terminal

45 46

Resumen
Captura de Requisitos Análisis y Diseño Implementación

Diagramas de
Estados
Diagramas de
Secuencia Diagramas de
Distribución El Paradigma
Orientado a Objetos
Diagramas de Diagramas
Casos de Uso De Clases

Diagramas de Diagramas de
Colaboración Componentes

Diagramas de Diagramas de
Actividad Actividad

"You can model 80 percent of most problems by using about 20 percent of the UML."-- Grady Booch
47 48

8
 ¿Por qué la Orientación a Objetos? ¿Por qué la Orientación a Objetos?

§ Proximidad de los conceptos de modelado § Conceptos comunes de modelado durante el

respecto de las entidades del mundo real análisis, diseño e implementación
• Mejora captura y validación de requisitos
• Acerca el “espacio del problema” y el “espacio de la • Facilita la transición entre distintas fases
solución” • Favorece el desarrollo iterativo del sistema
• Disipa la barrera entre el “qué” y el “cómo”
§ Modelado integrado de propiedades estáticas y
dinámicas del ámbito del problema
§ Sin embargo, existen problemas ...
• Facilita construcción, mantenimiento y reutilización

49 50

Problemas en OO
“...Los conceptos básicos de la OO se conocen desde hace
dos décadas, pero su aceptación todavía no está tan
extendida como los beneficios que esta tecnología puede
sugerir”
“...La mayoría de los usuarios de la OO no utilizan los
conceptos de la OO de forma purista, como inicialmente
se pretendía. Esta práctica ha sido promovida por
muchas herramientas y lenguajes que intentan utilizar los
conceptos en diversos grados”
--Wolfgang Strigel
51
… Problemas en OO
§ Un objeto contiene datos y operaciones que operan
sobre los datos, pero ...
§ Podemos distinguir dos tipos de objetos degenerados:
• Un objeto sin datos (que sería lo mismo que una biblioteca
de funciones)
• Un objeto sin “operaciones”, con sólo operaciones del tipo
crear, recuperar, actualizar y borrar (que se correspondería
con las estructuras de datos tradicionales)
§ Un sistema construido con objetos degenerados no es
un sistema verdaderamente orientado a objetos
“Las aplicaciones de gestión están constituidas
mayoritariamente por objetos degenerados”
52

Reflexiones respecto de Situación

Actual de Desarrollo de SI
Análisis Diseño Implementación

DFDs DEs
Enfoque Entornos de
Estructurado E-R
Modelo
Programación
Visual Fundamentos del Modelado
Orientado a Objetos
Diagramas de Casos de Uso Relacional
Diagramas de Actividad
Diagramas de Secuencia
Diagramas de Colaboración Modelo
Bosquejos de Interfaces Relacional !!
Bases de Datos
(Objeto-)
Enfoque OO Diagrama de Clases Relacionales
Diagrama de Estados
Diagramas de Actividad

53 54

9
 Objetos … Objetos
§ Objeto = unidad atómica que integra estado y § El Modelado de Objetos permite representar el
comportamiento ciclo de vida de los objetos a través de sus
interacciones
§ La encapsulación en un objeto permite una alta § En UML, un objeto se representa por un
cohesión y un bajo acoplamiento rectángulo con un nombre subrayado

§ Un objeto puede caracterizar una entidad física Otro

Objeto
(coche) o concepto (ecuación matemática) Un Objeto
más

Otro
Objeto

55 56

… Objetos … Objetos
§ Ejemplo de varios objetos relacionados: § Objeto = Identidad + Estado + Comportamiento
§ El estado está representado por los valores de los
Cuenta
atributos
Dos clientes
del banco corriente
Felipe
§ Un atributo toma un valor en un dominio concreto
Libreta de
ahorro a
Un coche
Juan plazo
Azul
Libreta de 979 Kg
ahorro 70 CV
Cuenta ...
corriente
57 58

Identidad
§ Oid (Object Identifier)
Cada objeto posee un oid. El oid establece la identidad
del objeto y tiene las siguientes características:
• Constituye un identificador único y global para cada
objeto dentro del sistema
• Es determinado en el momento de la creación del objeto
… Identidad
• Es independiente de las propiedades del objeto, lo cual
implica independencia de valor y de estructura
• No cambia durante toda la vida del objeto. Además, un
oid no se reutiliza aunque el objeto deje de existir
• No se tiene ningún control sobre los oids y su
manipulación resulta transparente

• Es independiente de la localización física del objeto, es § Sin embargo, es preciso contar con algún medio para
decir, provee completa independencia de localización hacer referencia a un objeto utilizando referencias del
dominio (valores de atributos)
59 60

10
Estado Comportamiento
§ El estado evoluciona con el tiempo § Ejemplo de interacción:
§ Algunos atributos pueden ser constantes
Otro objeto
§ El comportamiento agrupa las competencias de Un mensaje
un objeto y describe las acciones y reacciones
de ese objeto Operacion 2

§ Las operaciones de un objeto son consecuencia Un objeto

de un estímulo externo representado como
mensaje enviado desde otro objeto Operacion 1

61 62

… Comportamiento
§ 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
Persistencia
§ La persistencia de los objetos designa la capacidad de
un objeto trascender en el espacio/tiempo
§ Un objeto persistente conserva su estado en un
sistema de almacenamiento permanente (usualmente
memoria secundaria)
§ Podremos después reconstruirlo , es decir, cogerlo de
memoria secundaria para utilizarlo en la ejecución
(materialización del objeto)

§ Los lenguajes OO no proponen soporte adecuado para

la persistencia, pues ésta debería ser transparente, un
objeto existe desde su creación hasta que se destruya
63 64

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
65
… Comunicación
§ Categorías de objetos:
• Activos - Pasivos
• Cliente – Servidores, Agentes
§ 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
66

11
… Comunicación … Comunicación
§ Los agentes reúnen las características de § Ejemplo en el que un agente hace de aislante:
clientes y servidores Enrutamiento
dinámico
§ Son la base del mecanismo de delegación
Sevidor 1
§ Introducen indirección: un cliente puede Un agente

comunicarse con un servidor que no conoce

directamente
Servidor 2
Un cliente

Aislante
67 68

El Concepto de Mensaje … El Concepto de Mensaje

§ La unidad de comunicación entre objetos se
llama mensaje Objeto 1
: Mensaje A
§ El mensaje es el soporte de una comunicación
que vincula dinámicamente los objetos que Objeto 2

fueron separados previamente en el proceso

de descomposición : Mensaje C : Mensaje E
§ Adquiere toda su fuerza cuando se asocia al
polimorfismo y al enlace dinámico Objeto 3 Objeto 4

: Mensaje D
69 70

Mensaje y Estímulo
§ Un estímulo causará la invocación de una operación, la
creación o destrucción de un objeto o la aparición de
una señal
§ Un mensaje es la especificación de un estímulo Captura de Requisitos
§ Tipos de flujo de control:
• Llamada a procedimiento o flujo de control anidado
• Flujo de control plano
• Retorno de una llamada a procedimiento
• Otras variaciones
• Esperado (balking)
• Cronometrado ( time-out)

71 72

12
Casos de Uso
§ Los Casos de Uso (Ivar Jacobson) describen
bajo la forma de acciones y reacciones el
comportamiento de un sistema desde el p.d.v.
del 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
§ Comparación con respecto a los Diagramas de
Flujo de Datos del Enfoque Estructurado
73
… Casos de Uso
§ 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 basado en el lenguaje natural, es decir, es
accesible por los usuarios
74

… Casos de Uso … Casos de Uso

§ Ejemplo: Actores:
• Principales: personas que usan el sistema
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
Caso de uso X • Otros sistemas: sistemas con los que el sistema interactúa

§ La misma persona física puede interpretar varios

Actor A papeles como actores distintos
Actor B
§ El nombre del actor describe el papel desempeñado
Caso de uso Y

75 76

… Casos de Uso Casos de Uso: Relaciones

§ Los Casos de Uso se determinan observando y § UML define cuatro tipos de relación en los
precisando, actor por actor, las secuencias de Diagramas de Casos de Uso:
interacción, los escenarios, desde el punto de vista del
usuario • Comunicación:

§ Un escenario es una instancia de un caso de uso

§ Los casos de uso intervienen durante todo el ciclo de

vida. El proceso de desarrollo estará dirigido por los Actor
casos de uso
Caso de Uso

77 78

13
… Casos de Uso: Relaciones … Casos de Uso: Relaciones
• Inclusión : una instancia del Caso de Uso origen • Extensión : el Caso de Uso origen extiende el
incluye también el comportamiento descrito por el comportamiento del Caso de Uso destino
Caso de Uso destino

<<include> >
<<extend >>
Caso de uso destino

Caso de uso destino

Caso de uso origen

En UML 1.3 se estereotipa como <<include>> lo que Caso de uso origen

antes llevaba el estereotipo <<uses>>

79 80

… Casos de Uso: Relaciones … Casos de Uso: Relaciones

• Herencia : el Caso de Uso origen hereda la § Ejemplo:
especificación del Caso de Uso destino y
posiblemente la modifica y/o amplía
<<extend>>
<<extends>>
Transferencia porInternet
Giro por Internet

Cliente

<<includes>>
<<include>> Transferencia
Giro
Caso de uso destino

Caso de uso origen

Identificación

81 82

Casos de Uso: Construcción … Casos de Uso: Construcción

§ Un caso de uso debe ser simple, inteligible, claro y § La descripción del Caso de Uso comprende:
conciso • el inicio: cuándo y qué actor lo produce?
§ Generalmente hay pocos actores asociados a cada • el fin: cuándo se produce y qué valor devuelve?
Caso de Uso
• la interacción actor-caso de uso: qué mensajes
§ Preguntas clave: intercambian ambos?
• ¿cuáles son las tareas del actor? • objetivo del caso de uso: ¿qué lleva a cabo o
• ¿qué información crea, guarda, modifica, intenta?
destruye o lee el actor? • cronología y origen de las interacciones
• ¿debe el actor notificar al sistema los cambios • repeticiones de comportamiento: ¿qué
externos? operaciones son iteradas?
• ¿debe el sistema informar al actor de los • situaciones opcionales: ¿qué ejecuciones
cambios internos? alternativas se presentan en el caso de uso?
83 84

14
 RF - <id del requisito> <nombre del requisito funcional>
Versión <numero de versión y fecha>
Autores <autor>

Casos de Uso: Pruebas

Fuentes <fuente de la versión actual>
Objetivos asociados <nombre del objetivo>
Descripción El sistema deberá comportarse tal como se describe en
el siguiente caso de uso { concreto cuando <evento de
activación> , abstracto durante la realización de los
casos de uso <lista de casos de uso>}

§ El modelo de casos de uso permite realizar

Precondición <precondición del caso de uso>
Secuencia Paso Acción

pruebas orientadas a la verificación y

Normal 1 {El <actor> , El sistema} <acción realizada por el
actor o sistema>, se realiza el caso de uso
< caso de uso RF -x >
2 Si <condición>, {el <actor> , el sistema} <acción
realizada por el actor o sistema>>, se realiza el validación del sistema
caso de uso < caso de uso RF-x>
3
4
5 § Verificar significa confirmar que el sistema se
6
n desarrolla correctamente
Postcondición <postcondición del caso de uso>
Excepciones Paso Acción

§ Validar asegura que el sistema bajo

1 Si <condición de excepción>,{el <actor> , el
sistema} }<acción realizada por el actor o

desarrollo es el que el usuario realmente

sistema>>, se realiza el caso de uso
< caso de uso RF -x>, a continuación este caso
de uso {continu a, aborta}
2
3 quiere
Rendimiento Paso Cota de tiempo
1 n segundos
2 n segundos
Frecuencia esperada <nº de veces> veces / <unidad de tiempo>
Importancia {sin importancia, importante, vital}
Urgencia {puede esperar, hay presión, inmediatamente}
Come n t a r i o s <comentarios adicionales> 85 86

Modelo de Casos de Uso y Práctica 11

Modelo Conceptual
§ La especificación de cada caso de uso y los
correspondientes D. de Interacción establecen
el vínculo con el modelo conceptual
Modelado de Interacciones
§ En métodos OO que carecen de una técnica de
captura de requisitos se comienza
inmediatamente con la construcción del
modelo conceptual

87 88

Interacción Diagramas de interacción

§ Los objetos interactúan para realizar § Los Diagramas de Secuencia son más
colectivamente los servicios ofrecidos por las adecuados están para observar la perspectiva
aplicaciones. Los diagramas de interacción cronológica de las interacciones
muestran cómo se comunican los objetos en § Los Diagramas de Colaboración ofrecen una
una interacción mejor visión espacial mostrando los enlaces de
comunicación entre objetos
§ Existen dos tipos de diagramas de
interacción: los Diagramas de Colaboración y § Normalmente el D. de Colaboración se obtiene
los Diagramas de Secuencia a partir del correspondiente D. de Secuencia

89 90

15
Diagramas de Secuencia … Diagramas de Secuencia
§ Muestra la secuencia de mensajes entre § Un ejemplo:
objetos durante un escenario concreto
A B C

§ Cada objeto viene dado por una barra

vertical m1

§ El tiempo transcurre de arriba abajo m2

§ Cuando existe demora entre el envío y la m3

atención se puede indicar usando una línea m4

oblicua m5

91 92

… Diagramas de Secuencia … Diagramas de Secuencia

§ Ejemplo Quien llama Línea telefónica Llamado
§ Un objeto puede enviarse a sí mismo un mensaje:
descuelga

tono
a
marcar

Las bandas
mensaje reflexivo
rectangulares
indicación de llamada timbre

representan los descuelga

periodos de
actividad de los diga?

objetos

93 94

… Diagramas de Secuencia … Diagramas de Secuencia

§ Normalmente no es necesario indicar el retorno
§ Gráficamente también se puede indicar del control:
cuándo el mensaje es para crear el objeto
(va dirigido al rectángulo del objeto o a b

etiquetado con new) o para destruirlo (va

dirigido a la línea del objeto pero el final de
la flecha es una cruz)
El retorno se
§ Ver UML V1.3 página 3-100 considera implícito
cuando el envío es
síncrono

95 96

16
… Diagrama de Secuencia Tipos de Control
§ El Diagrama de Secuencia refleja de manera
§ En el caso asíncrono el retorno, si existe, se
indirecta las opciones de control
debe representar:
§ Un control centralizado tiene una forma como
esta:
a : aa b : aa

97 98

… Tipos de control … Estructuras de control

§ Un control descentralizado tiene una forma § Podemos representar iteraciones en el envío de
como esta: mensajes, p.e., mientras se cumpla una
condición:

While X
Loop

end Loop

99 100

… Estructuras de control … Estructuras de control

§ La iteración puede expresarse también como § Las bifurcaciones condicionales pueden
parte del mensaje: representarse de esta forma:

*[condición] Mensaje If condición

else

end if

101 102

17
Diagramas 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
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):

§ La estructura estática viene dada por los enlaces; la

dinámica por el envío de mensajes por los enlaces A.1, B.3 / 1:Mensaje B

103 104

… Mensajes … Mensajes
§ Un mensaje se envía iterada y secuencialmente § Un mensaje se envía iterada y
a un conjunto de instancias: concurrentemente a un conjunto de instancias:

1 *[i:=1..n] : Mensaje
1 *| | [i:=1..n] : Mensaje
B
B
A
A

105 106

… Mensajes … Mensajes
§ Un mensaje se envía de manera condicionada: § Un mensaje que devuelve un resultado:

[x>y] 1: Mensaje 1: distancia:= mover(x,y)

B B

A A

107 108

18
 Práctica 12

… Mensajes
§ Los argumentos de un mensaje pueden ser
valores obtenidos como consecuencia de las
llamadas anteriores
§ Los argumentos pueden ser también Modelado Conceptual
expresiones de navegación construidas a partir
del objeto cliente

§ Los argumentos pueden omitirse en el

diagrama

109 110

Clases Clases
§ Modelado Conceptual: § El mundo real puede ser visto desde abstracciones
diferentes (subjetividad)

Organización del conocimiento del dominio del § Mecanismos de abstracción:

problema en un conjunto de abstracciones
ordenadas de forma que se obtiene un
conocimiento más profundo del problema
• Clasificación / Instanciación
• Composición / Descomposición
• Agrupación / Individualización
• Especialización / Generalización

§ La clasificación es uno de los mecanismos de

abstracción más utilizados
111 112

Clases Clases: Notación Gráfica

§ Cada clase se representa en un rectángulo
§ La clase define el ámbito de definición de un con tres compartimientos:
conjunto de objetos
• nombre de la clase
§ Cada objeto pertenece a una clase • atributos de la clase motocicleta

• operaciones de la clase color

§ Los objetos se crean por instanciación de las cilindrada
velocidad maxima
clases
arrancar
acelerar
frenar

113 114

19
Clases: Notación Gráfica Clases: Encapsulación
§ Otros ejemplos: § La encapsulación presenta dos ventajas básicas:
• Se protegen los datos de accesos indebidos
lista • El acoplamiento entre las clases se disminuye
pila • Favorece la modularidad y el mantenimiento

primero § Los atributos de una clase no deberían ser

ultimo apilar manipulables directamente por el resto de objetos
añadir desapilar
quitar cardinalidad
cardinalidad

115 116

… Clases: Encapsulación … Clases: Encapsulación

Los niveles de encapsulación están heredados de los niveles de
§ § Ejemplo:
C++:

• (-) Privado : es el más fuerte. Esta parte es totalmente

Reglas de visibilidad
invisible (excepto para clases friends en terminología C++)
+ Atributo público : int
• (#) Los atributos/operaciones protegidos están visibles para # Atributo protegido : int
las clases friends y para las clases derivadas de la original
- Atributo privado : int
• (+) Los atributos/operaciones públic os son visibles a otras
clases ( cuando se trata de atributos se está transgrediendo el + "Operación pública"
principio de encapsulación) # "Operación protegida"
- "Operación privada"

117 118

Relaciones entre Clases Asociación

§ Los enlaces entre de objetos pueden § La asociación expresa una conexión bidireccional
representarse entre las respectivas clases entre objetos
§ Una asociación es una abstracción de la relación
§ Formas de relación entre clases: existente en los enlaces entre los objetos
• Asociación y Agregación (vista como un
caso particular de asociación) Univ. de Murcia:Universidad Un enlace Antonio:Estudiante

• Generalización/Especialización

§ Las relaciones de Agregación y Generalización Universidad Estudiante

forman jerarquías de clases Una asociación

119 120

20
 … Asociación … Asociación
§ Ejemplo: § Especificación de multiplicidad
(mínima...máxima)
marido 1 Uno y sólo uno
0..1 Cero o uno
0.. 1
casado -con
0.. 1 M..N Desde M hasta N (enteros naturales)
trabaja-para * Compañía
mujer Persona * * Cero o muchos
emplea -a
jefe nombre nombre 0..* Cero o muchos
0.. 1 s. s. dirección 1..* Uno o muchos (al menos uno)
Administra
* empleado
§ La multiplicidad mínima >= 1 establece una
restricción de existencia

121 122

Asociación Cualificada Agregación

§ La agregación representa una relación parte_de

Aerolínea nro_billete *
0..1
Viajero entre objetos

§ En UML se proporciona una escasa caracterización

de la agregación
Tablero 1 1
fila Cuadro
Ajedrez columna

§ Puede ser caracterizada con precisión

Reduce la multiplicidad del rol opuesto al considerar el valor determinando las relaciones de comportamiento y
del cualificador estructura que existen entre el objeto agregado y
cada uno de sus objetos componentes

123 124

Agregación: Caracterización … Agregación: Caracterización

4. ¿Puede existir un objeto parte sin ser componente de un objeto
1. ¿Puede el objeto parte comunicarse directamente con objetos externos
agregado?
al objeto agregado?
• Si => flexible
• No => inclusiva • No => estricta
• Si => no inclusiva
5. ¿Cuántos objetos de una clase componente puede tener asociados un objeto
2. ¿Puede cambiar La composición del objeto agregado? agregado?
• Más de uno => multivaluada
• Si => dinámica
• Máximo uno => univaluada
• No => estática
6. ¿Puede el objeto agregado no tener objetos de una clase componente en algún
3. ¿Puede el objeto parte ser compartido por más de un objeto agregado? instante?

• No => disjunta • Si => co n nulos permitidos

• No => con nulos no permitidos
• Si => no disjunta
p En UML sólo se distingue entre agregación y composición
(aggregate composition), siendo esta última disjunta y estricta.
125 126

21
 … Agregación: Caracterización Ejemplos
§ Las caracterizaciones 1, 3, 4 y 5 están incluidas en el
concepto más amplio de multiplicidad

Objeto Agregado coche Persona +Hijos

1 *
Multiplicidad Mínima Multiplicidad Mínima 0..2
0 → nulos permitidos 0 → flexible
+Padre
> 0 → nulos no permitidos > 0 → estricta

1
Multiplicidad Máxima Multiplicidad Máxima
motor
1 → univaluado 1 → disjunto
> 1 → multivaluado >1 → no disjunto

Objeto Componente
127 128

… Ejemplos … Clases vs. Objetos

Agregación Polígono 1 contiene 3.. *
Punto § Los Diagramas de Clases y los Diagramas de
{ordenado} Objetos pertenecen a dos vistas complementarias
del modelo
*
§ Un Diagrama de Clases muestra la abstracción de
* Persona
Asociación excluyente una parte del dominio
Cuenta or
*
Empresa § Un Diagrama de Objetos representa una situación
1
concreta del dominio
* está-autorizado -en *
Usuario Estación § Cada objeto es instancia de una clase
Autorización
§ Ciertas clases (clases abstractas o diferidas) no
Clase de asociación prioridad
pueden ser instanciadas
privilegios
camb_privil 129 130

Jerarquías de ... Jerarquías de

Generalización/Especialización Generalización/Especialización
§ Permiten gestionar la complejidad mediante un § Nombres usados: clase padre - clase hija,
ordenamiento taxonómico superclase - subclase, clase base - clase
derivada
§ Se obtiene usando los mecanismos de
abstracción de Generalización y/o Especialización § Las subclases heredan características de sus
§ La Generalización consiste en factorizar las superclases, es decir, atributos y operaciones
propiedades comunes de un conjunto de clases (y asociaciones) de la superclase están
en una clase más general disponibles en sus subclases

131 132

22
... Jerarquías de ... Jerarquías de
Generalización/Especialización Generalización/Especialización
Abstracciones más generales.
§ La Generalización y Especialización son vehiculo
equivalentes en cuanto al resultado: la
jerarquía y herencia establecidas

§ Generalización y Especialización no son

operaciones reflexivas ni simétricas pero sí
vehiculo terrestre vehiculo aéreo

transitivas

camion coche avion helicoptero

133 134

... Jerarquías de ... Jerarquías de

Generalización/Especialización Generalización/Especialización
§ La especialización es una técnica muy eficaz para la § La noción de clase está próxima a la de
extensión y reutilización
conjunto
coche

§ Dada una clase, podemos ver el conjunto

relativo a las instancias que posee o bien
funcionando estropeado relativo a las propiedades de la clase

§ Generalización y especialización expresan

§ Caracterización de la generalización en UML: relaciones de inclusión entre conjuntos
• disjunta - no disjunta
• total (completa) - parcial (incompleta)
135 136

... Jerarquías de ... Jerarquías de

Generalización/Especialización Generalización/Especialización
§ Particionamiento del espacio de objetos => § Un ejemplo de Especialización Estática:
Especialización Estática
vehiculo aéreo
§ Particionamiento del espacio de estados de
los objetos => Especialización Dinámica

§ En ambos casos consideraremos

generalizaciones/especializaciones disjuntas
avion helicoptero

137 138

23
... Jerarquías de ... Jerarquías de
Generalización/Especialización Generalización/Especialización
§ Un ejemplo de Especialización Dinámica: § Extensión: Posibles instancias de una clase

§ Intensión: Propiedades definidas en una

coche clase

A
int(A) ⊆ int(B)
funcionando estropeado
ext(B) ⊆ ext(A)
B

139 140

... Jerarquías de ... Jerarquías de

Generalización/Especialización Generalización/Especialización
§ Estáticas: § Dinámicas:

C0 ext(C 0) = ∪ ext(C i) C0 ext(C 0) = ∪ ext(C i)

ext(C i) ∩ ext(Cj ) = ∅ extt(C i) ∩ extt(Cj ) = ∅
extt1(C i) ∩ extt2(Cj ) ≠ ∅
C1 Cn C1 Cn

141 142

... Jerarquías de ... Jerarquías de

Generalización/Especialización Generalización/Especialización
§ En la Especialización Estática, el objeto es § Ejemplo: varias especializaciones a partir de
instancia de la subclase desde su creación y la la misma superclase:
superclase en las que fue creado. Esta comercial
pertenencia es inmutable
vehiculo aéreo
§ Puede haber más de una especialización estática
o dinámica a partir de la misma superclase

militar

avion helicoptero

143 144

24
... Jerarquías de ... Jerarquías de
Generalización/Especialización Generalización/Especialización
§ En la Especialización Dinámica un objeto puede § Ejemplo: especializaciones dinámicas de la
migrar durante su vida entre las distintas misma superclase:
subclases de la especialización
de menos de 1000kms
§ La migración puede definirse en función de su coche
estado o de los eventos que le acontezcan

de más de 1000 kms

funcionando estropeado

145 146

... Jerarquías de ... Jerarquías de

Generalización/Especialización Generalización/Especialización
§ Un ejemplo combinado:
§ El siguiente es un ejemplo de clasificación no
equilibrada:
vehiculo

comercial

vehiculo terrestre vehiculo aéreo

vehiculo terrestre
estática

estática
estática militar

camion avion helicoptero

de menos de 1000kms coche

dinámica camion coche Harley Davidson
de más de 1000 kms

dinámica

funcionando estropeado
147 148

... Jerarquías de ... Jerarquías de

Generalización/Especialización Generalización/Especialización
§ Por regla general, es mejor limitar el número § Ejemplo: mariposa
de subclases a cada nivel a costa de
aumentar el número de objetos por clase y
reservar los atributos para cualificar oruga crisálida Lepidóptero
afinadamente los objetos
Aspecto
§ A veces, una especialización dinámica tiene mariposa estadio
1
un equivalente a través de una
especialización estática y una asociación ...
oruga crisálida Lepidóptero

149 150

25
Herencia Múltiple … Herencia Múltiple
§ Se presenta cuando una subclase tiene más de § La multiplicidad de la clasificación múltiple se
una superclase puede representar también mediante
asociaciones:
§ La herencia múltiple debe manejarse con Realiza >
precaución. Algunos problemas son el conflicto Clase Tipo
de nombre y el conflicto de precedencia *

§ Se recomienda un uso restringido y disciplinado

de la herencia. Java y Ada 95 simplemente no Tipo A Tipo B Tipo C
ofrecen herencia múltiple

151 152

… Herencia Múltiple Delegación

§ Uso disciplinado de la herencia múltiple
§ La herencia no es una necesidad absoluta y
conejo siempre puede sustituirse por delegación
con pelo
Herbívoro
§ Disminuye el acoplamiento: el cliente no
conoce directamente al proveedor y el
proveedor puede ser modificado sobre la
con plumas
omnívoro
Animal marcha
con escamas

§ Permite implementar herencia múltiple en

carnívoro

Bipedo Cuadrúpedo lenguajes con herencia simple

153 154

… Delegación Principio de Sustitución

§ Ejemplo: delegación en lugar de herencia § El Principio de Sustitución de Liskow (1987)
múltiple Animal
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
x Locomoción x Alimento

los términos de la superclase se vea

afectado.”
Bípedo Cuadrúpedo Herbívoro Carnívoro

155 156

26
… Principio de Sustitución
§ Dado que los programadores pueden introducir
código en las subclases redefiniendo las
operaciones, es posible introducir involuntaria-
mente incoherencias que violen el principio de
sustitución
§ El polimorfismo que veremos a continuación no
debería implementarse sin este principio
Polimorfismo
§ El término polimorfismo se refiere a que una
característica de una clase puede tomar
varias formas
§ El polimorfismo representa en nuestro caso
la posibilidad de desencadenar operaciones
distintas en respuesta a un mismo mensaje
§ Cada subclase hereda las operaciones pero
tiene la posibilidad de modificar localmente
el comportamiento de estas operaciones

157 158

… Polimorfismo … Polimorfismo
§ Ejemplo: todo animal duerme, pero cada Zoo
1
Animal Dormir()

clase lo hace de forma distinta {

* }

Zoo Animal
1
?
*
dormir
León Oso Tigre

León Oso Tigre Dormir() Dormir() Dormir()

{ { {
sobre el vientre sobrela espalda en un árbol
} } }
159 160

… Polimorfismo Comentarios
§ Los Diagramas de Clases v/s los modelos de
§ La búsqueda automática del código que en datos (Diagramas Entidad -Relación)
cada momento se va a ejecutar es fruto del
enlace dinámico

§ El cumplimiento del Principio de Sustitución

permite obtener un comportamiento y diseño
coherente

161 162

27
 Diagramas de Estados
§ Los Diagramas de Estados representan
autómatas de estados finitos, desde el p.d.v.
de los estados y las transiciones
Diagramas de Estados § Son útiles sólo para los objetos con un
comportamiento significativo
§ El resto de objetos se puede considerar que
tienen un único estado
§ El formalismo utilizado proviene de los
Statecharts (Harel)

163 164

… Diagramas de Estados … Diagramas de Estados

§ Cada objeto está en un estado en cierto instante
§ El estado está caracterizado parcialmente por los
valores de los atributos del objeto
§ El estado en el que se encuentra un objeto
determina su comportamiento
§ Cada objeto sigue el comportamiento descrito en
el D. de Estados asociado a su clase
§ Los D. De Estados y escenarios son complementarios
§ Los D. 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 D. 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

165 166

… Diagramas de Estados … Diagramas de Estados

§ Ejemplo de un Diagrama de Estados para la § La comunicación bidireccional puede
clase persona: representarse mediante comunicación
contratar asíncrona. Por ejemplo en un Diagrama de
en el paro en activo Colaboración:
perder empleo
1: una pregunta
jubilarse un otro
jubilarse objeto objeto
2: la respuesta
jubilado

167 168

28
… Diagramas de Estados … Diagramas de Estados
§ Si la comunicación es síncrona el cliente § Las guardas permiten condicionar la
debe esperar la respuesta. Con lo cual en el transición:
cliente tendríamos:
Evento[ condición ]
a a b

plantear pregunta

espera respuesta recibir respuesta

c

169 170

Acciones … Acciones
§ Podemos especificar la ejecución de una § Podemos especificar el envío de un evento a
acción como consecuencia de la transición: otro objeto como consecuencia de la
transición:
a
Evento[ condición ] / acción
a b

Evento( arg1, arg2 )[ condición ] / ^otro_objeto.evento(arg2)

Dicha acción también se

considera instantánea b

171 172

… Acciones .. Acciones
§ Se puede especificar el hacer una acción § Se puede especificar el hacer una acción
como consecuencia de entrar, salir o estar cuando ocurre en dicho estado un evento
en un estado: que no conlleva salir del estado:

estado A estado A
entry: acción por entrar on evento_activador( arg1 )[ condición ]: acción por evento
exit: acción por salir
do: acción mientras en estado

173 174

29
Actividades … Actividades
§ Las actividades son similares a las acciones § Cuando una actividad finaliza se produce una
pero tienen duración y se ejecutan dentro de transición automática de salida del estado
un estado del objeto [ not condición ]
a b
§ Las actividades pueden interrumpirse en do: actividad
todo momento, cuando se desencadena la
operación de salida del estado [ condición ]

175 176

Generalización de Estados Generalización de Estados

§ Podemos reducir la complejidad de estos § Ejemplo:
diagramas usando la generalización de
estados e1
§ Distinguimos así entre superestado y a b
subestados
§ Un estado puede contener varios subestados e2

disjuntos e2
§ Los subestados heredan las variables de c
estado y las transiciones externas

177 178

Generalización de Estados … Generalización de Estados

§ Quedaría como: § Las transiciones de entrada deben ir hacia
subestados específicos:
e1 e1
a b
a b

e2

e0
e2

c
c

179 180

30
… Generalización de Estados … Generalización de Estados
§ Es preferible tener estados iniciales de § Es posible ocultar los detalles de los sub-
entrada a un nivel de manera que desde los estados:
niveles superiores no se sepa a qué
subestado se entra:
e1 c
a b e0
c
e2
e0

181 182

… Generalización de Estados … Generalización de Estados

§ La agregación de estados es la composición § Ejemplo:
de un estado a partir de varios estados
independientes
§ 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

183 184

Historial … Historial
§ Por defecto, los autómatas no tienen § Ejemplo:
memoria a

§ Es posible memorizar el último subestado d2

visitado para recuperarlo en una transición
entrante en el superestado que lo engloba h
in
x y

out
d1

H
185 186

31
… Historial … Historial
§ También es posible la memorización para § Ejemplo:
cualquiera de los subestados anidados (aparece
un * junto a la H) Enjuague Lavado Secado
a

d2

H
in
h x y

out Cerrar
Abrir Puerta Abrir Puerta
Cerrar
d1

H*
Espera

187 188

Destrucción del Objeto … Destrucción de Objeto

§ La destrucción de un objeto es efectiva § Ejemplo:
cuando el flujo de control del autómata
alcanza un estado final no anidado crash
En vuelo

§ La llegada a un estado final anidado implica

la “subida” al superestado asociado, no el fin despegar aterrizar
del objeto Crear(matricula)
En tierra

189 190

Transiciones temporizadas … Transiciones temporizadas

§ Las esperas son actividades que tienen § Ejemplo: a
asociada cierta duración

§ La actividad de espera se interrumpe cuando Si en 30 segundos no se / Abrir ranura

introduce el dinero se
el evento esperado tiene lugar termina la actividad esperar dinero
anular transacción
pasando a anular la entry: Mostrar mensaje
§ Este evento desencadena una transición que transacción. En do: Esperar 30 segundos
exit: cerrar ranura
permite salir del estado que alberga la cualquier caso se cierra
la ranura.
actividad de espera. El flujo de control se Depósito efectuado
transmite entonces a otro estado
b
191 192

32
… Transiciones temporizadas
§ Ejemplo v.2: a § El Diagrama de Actividades es una variante
/ Abrir ranura
esperar dinero
entry: Mostrar mensaje
exit: cerrar ranura
Diagrama de Actividades
de los Diagramas de Estados, organizado
respecto de las acciones y principalmente
destinado a representar el comportamiento
Temporizador interno de un método (la realización de una
(30 segundos)
anular transacción
operación), de un caso de uso o de un
proceso de negocio (Workflow)

Depósito efectuado
§ Una actividad puede considerarse un
estereotipo de estado
b

193 194

...Diagrama de Actividades Ejemplos

[no hay café] [no zumo]
Buscar Bebida
§ Las actividades se enlazan por transiciones [hay café [hay zumo]
automáticas
Poner café en filtro Añadir agua al depósito Coger taza
§ Cuando una actividad termina se
desencadena el paso a la siguiente actividad Poner filtro en máquina Coger zumo

§ Las actividades no poseen transiciones Encender máquina

internas ni transiciones desencadenadas por ^cafetera.On

eventos Café en preparación

indicador de fin
Servir café
Beber

195 196

...Ejemplos (con bandas)

Pasajero Vendedor Airline

Solicitar pasaje
Verificar

Modelado de Componentes
existencia vuelo

Dar detalles vuelo

Informar alternativas
y precios
Seleccionar vuelo

Solicitar pago Reservar plazas

Confirmar
Pagar pasaje plaza reservada

Emitir billete

197 198

33
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
...Diagramas de Componentes
§ Los componentes representan todos los tipos
de elementos software que entran en la
fabricación de aplicaciones informáticas.
Pueden ser simples archivos, paquetes de
Ada, bibliotecas cargadas dinámicamente,
etc.
§ Cada clase del modelo lógico se realiza en
dos componentes: la especificación y el
cuerpo

199 200

… Diagramas de Componentes … Diagramas de Componentes

§ La representación gráfica es la siguiente: § En C++ una especificación corresponde a un
archivo con un sufijo .h y un cuerpo a un
Especificación Cuerpo Genérico
archivo con un sufijo .cpp

§ En Ada la noción de módulo existe

directamente en el lenguaje con el nombre
del paquete

Package Package Generic

specification body package

201 202

Dependencias entre Componentes Subsistemas

§ Las relaciones de dependencia se utilizan en § Los distintos componentes pueden agruparse en
los diagramas de componentes para indicar paquetes según un criterio lógico y con vistas a
que un componente utiliza los servicios simplificar la implementación
ofrecidos por otro componente § Son paquetes estereotipados en <<subsistemas>>

<<subsistema>>
NewPackage4

203 204

34
 … Subsistemas
§ Los subsistemas organizan la vista de realización de
un sistema
§ Cada subsistema puede contener componentes y
otros subsistemas Modelado de Distribución
§ La descomposición en subsistemas no es
necesariamente una descomposición funcional
§ Paquetes (Categorias) y clases en el nivel lógico.
Paquetes (Subsistemas) y componentes en el nivel
físico

205 206

Diagramas de Distribución … Diagramas de Distribución

§ Los Diagramas de Distribución muestran la § Los estereotipos permiten precisar la
disposición física de los distintos nodos que naturaleza del equipo:
componen un sistema y el reparto de los • Dispositivos
componentes sobre dichos nodos • Procesadores
• Memoria

§ Los nodos se interconectan mediante

Nodo
soportes bidireccionales (en principio) que
pueden a su vez estereotiparse

207 208

… Diagramas de Distribución
§ Ejemplo de conexión entre nodos:

<<Procesador> <<dispositivo>>
Proceso de Desarrollo
Nodo <<<<TCP/IP>>>>
conexión1
nodo2 de SW con UML
conexión7
<<RDSI>>
dispositiv
En Rational Rose podemos
o
distinguir entre el dispositivo por
estereotipado y el dispositivo con
su propio símbolo

209 210

35
Hacia un Método OO … Hacia un Método OO
§ Un proceso de desarrrollo de programas § UML no incorpora por sí mismo el modelo de
tiene como objetivo la formalización de las proceso
actividades relacionadas con la elaboración § Los autores destacan las siguientes características
de sistemas informáticos
de UML como esenciales para determinar el proceso
§ Debe ser: de desarrollo:
• Reproducible
• Está dirigido por los casos de uso: desde la especificación
• Definido
hasta el mantenimiento
• Medible en cuanto a rendimiento
• Optimizable • Se centra en la arquitectura: reutilizable y como guía
• ... hasta la solución
• Iterativo e incremental: el trabajo se divide en iteraciones
pequeñas en función de la importancia de los casos de
uso y el estudio de riesgos
211 212

… Hacia un Método OO … Hacia un Método OO

Requisitos Análisis Diseño Implement. Pruebas
§ Las 4+1 vistas de Kruchten (1995):

Vista de
Vista Lógica Realización
Los Casos de Uso forman la unión Vista de los
Casos de Uso

Vista de Vista de
Procesos Distribución

Capturar, clarificar y Realizar los casos de Verificar se

validar los casos de uso satisfacen los casos
uso
de uso
213 214

Ciclo de Vida Iterativo e ...Ciclo de Vida Iterativo e

Incremental Incremental
§ Las actividades se encadenan en una mini-
§ El ciclo de vida iterativo se basa en la cascada con un alcance limitado por los
evolución de prototipos ejecutables que se objetivos de la iteración
muestran a los usuarios y clientes
§ En el ciclo de vida iterativo a cada iteración
Análisis
se reproduce el ciclo de vida en cascada a
menor escala Diseño
§ Los objetivos de una iteración se establecen
en función de la evaluación de las iteraciones Codific.
precedentes n veces Pruebas e
Integración
215 216

36
...Ciclo de Vida Iterativo e
Incremental
§ Cada iteración comprende:
• Planificar la iteración (estudio de riesgos)
• Análisis de los Casos de Uso y escenarios
• Diseño de opciones arquitectónicas
• Codificación y pruebas. La integración del nuevo
código con el existente de iteraciones anteriores
se hace gradualmente durante la construcción
• Evaluación de la entrega ejecutable (evaluación
del prototipo en función de las pruebas y de los
criterios definidos)
• Preparación de la entrega (documentación e
instalación del prototipo)
217
Gestión del Riesgo
§ El análisis de riegos consiste en evaluar el
proyecto, la tecnología y los recursos con el fin
determinar y comprender la naturaleza y el
origen de los riesgos
§ Riesgos:
• Comerciales (competencia, etc.)
• Financieros (económicos, etc.)
• Técnicos (base tecnológica sólida y probada?)
• De desarrollo (equipo experimentado?)
§ El mayor riesgo consiste en no saber dónde
están los riesgos
218

...Gestión del Riesgo Reparto de Actividades

Actividades Fases
§ Cada iteración se basa en la construcción de un Ince ption Elabora tion Construc tion Tr ansition
número reducido de escenarios que se centran
primero en los riesgos más importantes y Requisitos

determinan las clases y las categorías a

Una iteración en la
fase de elaboración

construir en la iteración Análisis

§ Se distinguen prototipos orientados a la interfaz

del usuario, a cuestiones Hw, de reutilización de Diseño

programas o a la validación funcional

Implementación
§ Cada prototipo corresponde a 1 ó más casos de
uso Pruebas

P r eli m in ary iter. iter. iter. iter. ite r. i te r. iter.

219 I te ratio n (s) #1 #2 #n #n +1 #n + 2 #m #m + 1 220

Fases del Ciclo de Vida ...Fases del Ciclo de Vida

§ El ciclo de vida para UML consiste en una serie § Estudio de oportunidad (inception)
de ciclos cada uno de los cuales produce una • Define el ámbito y objetivos del proyecto
nueva versión del producto • Se define la funcionalidad y capacidades del
§ Cada ciclo está compuesto por fases y cada una producto
de estas fases está compuesta por un número § Elaboración
de iteraciones • Tanto la funcionalidad como el dominio del
§ Las fases son: problema se estudian en profundidad
• Estudio de oportunidad • Se define una arquitectura básica
• Elaboración • Se planifica el proyecto considerando recursos
• Construcción disponibles
• Transición

221 222

37
...Fases del Ciclo de Vida ...Fases del Ciclo de Vida
§ Construcción § Transición
• El producto se desarrolla a través de iteraciones
donde cada iteración involucra tareas de análisis, • Se libera el producto y se entrega al usuario
diseño e implementación para un uso real
• Las fases de estudio y análisis sólo dieron una • Se incluyen tareas de marketing, empaquetado
arquitectura básica que es aquí refinada de manera atractivo, instalación, configurac ión,
incremental conforme se construye (se permiten
entrenamiento, soporte, mantenimiento, etc.
cambios en la estructura)
• Gran parte del trabajo es programación y pruebas • Los manuales de usuario se completan y refinan
• Se documenta tanto el sistema construido como el con la información anterior
manejo del mismo • Estas tareas se realizan también en iteraciones
• Esta fase proporciona un producto construido junto
con la documentación

223 224

Esfuerzo Respecto de las Actividades ...Esfuerzo Respecto de las Fases

Inception Ela boration C onstr uction Tra nsition Inception Ela boration C onstr uction Tra nsition

15%
Requisitos Requisitos
Una iteración en la Una iteración en la
fase de elaboración fase de elaboración
Análisis 10% Análisis

Diseño 15% Diseño

30% Implementación
Implementación

Pruebas 15% Pruebas

P re lim i na ry i ter. i te r. i te r. i te r. iter. iter. ite r. P re lim i na ry i ter. i te r. i te r. i te r. iter. iter. ite r.
Iter atio n(s) #1 #2 #n # n+ 1 #n +2 #m # m +1 Iter atio n(s) #1 #2 #n # n+ 1 #n +2 #m # m +1

5% mantenimiento 10% gestión cambios Esfuerzo: 5% 20% 65% 10%

225 Duración: 10% 30% 50% 10% 226

Claves en el Desarrollo de SI
Notación
UML

Conclusiones

Herramientas Proceso
p.e. Rational Rose p.e. Proceso Unificado

227 228

38
Contexto de Desarrollo :
Grado de Complejidad Modelado de SI: Algunas Reflexiones
§ Modelar para la concebir el sistema y/o para la
documentarlo
§ Pragmatismo, los modelos deben ser útiles
§ Sencillez y Elegancia
§ Distintos nivel de abstracción, diferentes modelos
§ Seguimiento de transformaciones durante el proceso
(Traceability)
§ Sincronización de modelos
§ Dificultades para la introducción de técnicas y
herramientas de modelado
229 230

... Finalmente Bibliografía Recomendada

§ Apostar por enfoque Orientado a Objetos
usando notación UML
§ Problemas actuales en implementación, al usar
entornos de programación visual y/o bases de
datos relacionales
§ Posibles mejoras a mediano plazo
• Evolución: Uso de BDOO y/o mejoras en los LPOO
• Revolución: Generación Automática de Código a
partir de Modelos OO (Compilación de Modelos)
§ UML
• www.omg.org/ uml/
• Martin Fowler , “UML Destilled” (“UML Gota a Gota”)
• Terry Quatrani , “Visual Modeling ...”, un caso de estudio
§ Herramientas CASE
• International Council in SE (INCOSE) Tools Database
Working Group . www.incose.org/tools/
§ Otras
• Desmond D’Souza, componentes
• www.enteract.com / ∼bradapp/docs/patterns -intro.html,
patrones
• Revista IEEE Software, Conferencias: OOPSLA, ECOOP

231 232

39