Clase 6

UNPSJB - 2005 Ingeniera de Software - Clase 6 1
Ingeniera de Software
Clase 6
UML
Contenido de la clase 6
Desarrollo de soft OO usando UML
Introduccin
Modelado del soft
UML (Conceptos bsicos)
Paradigma OO
Fundamentos
Diagramas de CU
Diagramas de Interacciones
Diagramas de clase
Diagramas de estado/actividad
Diagrama de componentes
Diagrama de despliegue
Bibliografa
UML
www.dsic.upv.es/~uml
Patricio Letelier Torres UPV (politcnica de
Valencia)
UML Gota a Gota (Fowler)
UML (Booch, Rumbaugh, Jacobson)
Instant UML (Muller)
Webs
www.omg.org/uml

Modelado del software
Ejemplos
Construccin de una
cucha para un perro
Puede hacerlo
una sola persona
Requiere:
Modelado mnimo
Proceso simple
Herramientas
simples
Construccin de una
casa
Construida
eficientemente y
en un tiempo
razonable de un
equipo
Modelado
Proceso bien
definido
Herramientas ms
sofisticadas
Construccin de un
rascacielos
Contexto de
desarrollo
Determinar
configuracin del
proceso
Recursos
necesarios
Herramientas ms
sofisticadas an.

Claves en Desarrollo de SI
Herramientas Proceso
Notacin
Sistema Computacional
Proceso de Negocios
Orden
Item
envo
El modelado captura las
partes esenciales del sistema

Abstraccin - Modelado Visual (MV)
Qu es UML?
UML = Unified Modeling Language
Un lenguaje de propsito general para el
modelado orientado a objetos
Documento OMG Unified Modeling
Language Specification
UML combina notaciones provenientes
desde:
Modelado Orientado a Objetos
Modelado de Datos
Modelado de Componentes
Modelado de Flujos de Trabajo (Workflows)
Motivacin
Diversos mtodos y tcnicas OO, con
muchos aspectos en comn pero
utilizando distintas notaciones
Inconvenientes para el aprendizaje,
aplicacin, construccin y uso de
herramientas, etc.
Pugna entre distintos enfoques (y
correspondientes gurs)
Establecer una notacin estndar
Historia de UML
Comenz como el Mtodo Unificado, con
la participacin de Grady Booch y Jim
Rumbaugh. Se present en el OOPSLA95

El mismo ao se uni Ivar Jacobson. Los
Tres Amigos son socios en la compaa
Rational Software. Herramienta CASE
Rational Rose
Historia de UML
Nov 97
UML aprobado por el OMG
1998
1999
2000
UML 1.2
UML 1.3
UML 1.4
2001
UML 2.0
Revisiones menores
UML aglutina enfoques OO
UML
Rumbaugh
Jacobson
Meyer
Harel
Wirfs-Brock
Fusion
Embly
Gamma et. al.
Shlaer-Mellor
Odell
Booch
Pre- and Post-conditions
State Charts
Responsabilities
Operation descriptions,
message numbering
Singleton classes
Frameworks, patterns,
notes
Object life cycles
Aspectos Novedosos
Definicin semi-formal del Metamodelo de
UML
Mecanismos de Extensin en UML:
Stereotypes
Constraints
Tagged Values

Permiten adaptar los elementos de modelado,
asignndoles una semntica particular
Inconvenientes en UML
Definicin del proceso de desarrollo
usando UML. UML no es una metodologa
Falta integracin con respecto de otras
tcnicas tales como patrones de diseo,
interfaces de usuario, documentacin,
etc.
Monopolio de conceptos, tcnicas y
mtodos en torno a UML
Perspectivas de UML
UML ser el lenguaje de modelado
orientado a objetos estndar
predominante los prximos aos
Razones:
Participacin de metodlogos influyentes
Participacin de importantes empresas
Aceptacin del OMG como notacin estndar
Evidencias:
Herramientas que proveen la notacin UML
Edicin de libros
Congresos, cursos, etc.
Modelos y Diagramas
Un modelo captura una vista de un sistema del
mundo real. Es una abstraccin de dicho sistema,
considerando un cierto propsito. As, el modelo
describe completamente aquellos aspectos del
sistema que son relevantes al propsito del
modelo, y a un apropiado nivel de detalle.
Diagrama: una representacin grfica de una
coleccin de elementos de modelado, a menudo
dibujada como un grafo con vrtices conectados
por arcos
OMG UML 1.4 Specification
... 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 inters
El cdigo fuente del sistema es el modelo ms
detallado del sistema (y adems es ejecutable). Sin
embargo, se requieren otros modelos ...

Cada modelo es completo desde su punto de vista del
sistema, sin embargo, existen relaciones de
trazabilidad entre los diferentes modelos
Diagramas de UML
Diagrama de Casos de Uso
Diagrama de Clases
Diagrama de Objetos
Diagramas de Comportamiento
Diagrama de Estados
Diagrama de Actividad
Diagramas de Interaccin
Diagrama de Secuencia
Diagrama de Colaboracin
Diagramas de implementacin
Diagrama de Componentes
Diagrama de Despliegue
... Diagramas de UML
Use Case
Diagrams
Use Case
Diagrams
Diagramas de
Casos de Uso
Scenario
Diagrams
Scenario
Diagrams
Diagramas de
Colaboracin
State
Diagrams
State
Diagrams
Diagramas de
Componentes
Component
Diagrams
Component
Diagrams
Diagramas de
Distribucin
State
Diagrams
State
Diagrams
Diagramas de
Objetos
Scenario
Diagrams
Scenario
Diagrams
Diagramas de
Estados
Use Case
Diagrams
Use Case
Diagrams
Diagramas de
Secuencia
State
Diagrams
State
Diagrams
Diagramas de
Clases
Diagramas de
Actividad
Modelo
Los diagramas expresan grficamente partes de un modelo
Organizacin de Modelos
4+1 vistas de Kruchten (1995)
Vista Lgica
Vista de
Procesos
Vista de
Distribucin
Vista de
Realizacin
Vista de los
Casos de Uso
Este enfoque sigue el browser de Rational Rose
... Organizacin de Modelos
Propuesta de Rational Unified Process (RUP)
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 Anlisis (Analysis Model)
M. de Diseo (Design Model)
M. de Despliegue (Deployment Model)
M. de Datos (Data Model)
M. de Implementacin (Implementation Model)
M. de Pruebas (Test Model)

Paquetes en UML
Los paquetes ofrecen un mecanismo
general para la organizacin de los
modelos/subsistemas agrupando
elementos de modelado
Se representan grficamente como:
Nombre de
paquete
Paquetes en UML
Cada paquete corresponde a un
submodelo (subsistema) del modelo
(sistema)
Un paquete puede contener otros
paquetes, sin lmite de anidamiento pero
cada elemento pertenece a (est definido
en) slo un paquete
Una clase de un paquete puede aparecer
en otro paquete por la importacin a
travs de una relacin de dependencia
entre paquetes
Paquetes en UML
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
Paquetes en UML
Diagrama de Casos de Uso
Casos de Uso es una
tcnica para capturar
informacin de cmo
un sistema o negocio
trabaja, o de cmo se
desea que trabaje
No pertenece
estrictamente al
enfoque orientado a
objeto, es una tcnica
para captura de
requisitos
Supervisor
Verificar Situacin del Cliente
Administrativo
Preparar Catlogo
Sistema
Inventario
Tipos de Venta
Ejemplos
En el paquete tipos de venta:
Venta Normal
Venta en Rebajas
Venta en Ofertas
Vendedor
Solicitar Nueva Tarjeta
Cliente
Solicitar Prstamo
<<extend>>
[Tarjeta Caducada]
Otro Ejemplo
Ejemplos
Verificar Operacin
Reintegro Cuenta Corriente
Cliente
Reintegro Cuenta de Crdito
<<include>>
<<include>>
: Encargado
:WInPrstamos :Socio :Video :Prstamo
prestar(video, socio)
verificar situacin socio
verificar situacin video
registrar prstamo
entregar recibo
: Encargado
:WInPrstamos
:Socio
:Video
:Prstamo
1: prestar(video, socio)
2: verificar situacin socio
3: verificar situacin video
4: registrar prstamo
5: entregar recibo
Diagrama de Clases
El Diagrama de Clases es el diagrama principal
para el anlisis y diseo
Un diagrama de clases presenta las clases del
sistema con sus relaciones estructurales y de
herencia
La definicin de clase incluye definiciones para
atributos y operaciones
El modelo de casos de uso aporta informacin
para establecer las clases, objetos, atributos y
operaciones
Ejemplos
(Clase y Visibilidad) Asociacin
Profesor Departamento
1 0..1
director
1
dirige
0..1
Ejemplos (Clase Asociacin)
Empresa Empleado
1..* * 1..* *
trabajadores empleador
Cargo
nombre
sueldo
0..1
1..*
superior
subordinado
1..*
0..1
Ejemplos (Generalizacin)
Trabajador
Directivo Administrativo Obrero
{ disjunta, completa }
Ejemplos
Avin militar
Avin comercial
Avin de carga Avin de pasajeros
Motor Vendedor de billetes
Avin
1..4
1
1..4
1
Piloto
Reserva
n
1
n
1
Lnea area
Vuelo
n 1 n 1
1..2
n
1..2
n
n 1 n 1
1
n
1
n
Diagrama de Estados
con prstamos
sin prstamos
alta baja
prestar devolver[ nmero_prstamos = 1 ]
prestar
devolver[ nmero_prstamos > 1 ]
nmero_prstamos = 0
nmero_prstamos > 0
Socio
nmero : int
nombre : char[50]
nmero_prestamos : int = 0
alta()
baja()
prestar(cdigo_libro : int, fecha : date)
devolver(cdigo_libro : int, fecha : date)
Buscar Bebida
Poner caf en filtro Aadir agua al depsito Agarrar taza
Poner filtro en mquina
Encender mquina
Caf en preparacin
Servir caf
Agarrar zumo
Beber
[no hay caf]
[hay caf
[no zumo]
[hay zumo]
/ cafetera.On
indicador de fin
Emitir billete
Pasajero
Vendedor Airline
Otro Ejemplo (con swim lines)
Solicitar pago Reservar plazas
Confirmar
plaza reservada
Pagar pasaje
Informar alternativas
y precios
Verificar
existencia vuelo
Dar detalles vuelo
Solicitar pasaje
Seleccionar vuelo
Diagrama Componentes
Control y Anlisis
Comment
Acceso a BD
Comment
Rutinas de Coneccion
Comment
Interf az de Terminal
Comment
Gestin de Cuentas
Comment
Punto de Venta
Servidor Central
Terminal de Consulta
Gestin de Cuentas
Comment
Interfaz de Terminal
Comment
Comment
Comment
Interfaz de Terminal
Comment
Comment
Acceso a BD
Comment
Control y Anlisis
Comment
Resumen
UML define una notacin que se expresa como
diagramas sirven para representar
modelos/subsistemas o partes de ellos
El 80 por ciento de la mayora de los problemas
pueden modelarse usando alrededor del 20 por
ciento de UML-- Grady Booch

UML
Paradigma OO
Diagramas
Por qu la Orientacin a Objetos?
Proximidad de los conceptos
de modelado respecto de las
entidades del mundo real
Mejora captura y validacin
de requisitos
Acerca el espacio del
problema y el espacio de la
solucin
Modelado integrado de
propiedades estticas y
dinmicas del mbito del
problema
Facilita construccin,
mantenimiento y reutilizacin
Conceptos comunes
de modelado durante
el anlisis, diseo e
implementacin
Facilita la transicin
entre distintas fases
Favorece el
desarrollo iterativo
del sistema
Disipa la barrera
entre el qu y el
cmo
Sin embargo, existen
problemas ...
Problemas en OO
...Los conceptos bsicos de la OO se
conocen desde hace dos dcadas, pero su
aceptacin todava no est tan extendida
como los beneficios que esta tecnologa
puede sugerir
...La mayora de los usuarios de la OO no
utilizan los conceptos de la OO de forma
purista, como inicialmente se pretenda.
Esta prctica ha sido promovida por
muchas herramientas y lenguajes que
intentan utilizar los conceptos en diversos
grados
--Wolfgang Strigel
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 sera lo mismo que una
biblioteca de funciones)
Un objeto sin operaciones, con slo operaciones
del tipo crear, recuperar, actualizar y borrar (que se
correspondera con las estructuras de datos
tradicionales)
Un sistema construido con objetos degenerados
no es un sistema verdaderamente orientado a
objetos
Las aplicaciones de gestin estn constituidas
mayoritariamente por objetos degenerados
Reflexiones respecto de Situacin Actual de
Desarrollo de SI
Anlisis Diseo
Enfoque
Estructurado
Enfoque OO
Diagramas de Casos de Uso
Diagramas de Actividad
Diagramas de Secuencia
Diagramas de Colaboracin d
DFDs
Diagrama de Clases
Diagrama de Estados
Diagramas de Actividad
DEs
Modelo
Relacional !!
Implementacin
Entornos de
Programacin
Visual
Bases de Datos
(Objeto-)
Relacionales
Modelo
Relacional
E-R
Diagramas de Casos de Uso
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 lmites
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
implementacin
Comparacin con respecto a los
Diagramas de Flujo de Datos del
Enfoque Estructurado
Un caso de uso es una funcin
atmica ofrecida por el sistema al
entorno (actores)
DFD puede ser detallada en un
DFD Hijo
Caso Uso y Proceso igual
modelado, pero caso de uso
expresa funcionalidad mediante
interaccin de actores
Caso de uno no modela detalle
funcional interno
Relaciones de extensin y
generalizacin de CU no tienen
igual en DFD
Casos de Uso
Los Casos de Uso cubren
la carencia existente en
mtodos previos (OMT,
Booch) en cuanto a la
determinacin de
requisitos
Los Casos de Uso
particionan el conjunto
de necesidades
atendiendo a la
categora de usuarios
que participan en el
mismo
Estn basado en el
lenguaje natural, es
decir, es accesible por
los usuarios
Actor A
Caso de Uso A
Actor B
Caso de Uso B
Casos de Uso
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
aplicacin y deben ser utilizados
Otros sistemas: sistemas con los que el sistema
interacta
La misma persona fsica puede interpretar varios
papeles como actores distintos
El nombre del actor describe el papel
desempeado
Casos de Uso
Los Casos de Uso se determinan
observando y precisando, actor por actor,
las secuencias de interaccin, los
escenarios, desde el punto de vista del
usuario
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 casos de uso
Casos de Uso: Relaciones
UML define cuatro
tipos de relacin
en los Diagramas
de Casos de Uso:
Comunicacin
Inclusin : una
instancia del Caso de
Uso origen incluye
tambin el
comportamiento
descrito por el Caso
de Uso destino

<<include>>
reemplaz al
denominado
<<uses>>
Actor
Caso de Uso
Caso de Uso Origen Caso de Uso Destino
<<include>>
Extensin : el Caso
de Uso origen
extiende el
comportamiento
del Caso de Uso
destino
Herencia : el Caso
de Uso origen
hereda la
especificacin del
Caso de Uso
destino y
posiblemente la
modifica y/o ampla

Caso de Uso Origen Caso de Uso Destino
<<extend>>
Caso de Uso Hijo Caso de Uso Padre
Ejemplo:
Identificacin
Transferencia en Internet
Cliente
Transferencia
<<include>>
<<extend>>
Ejemplo:
Casos de Uso: Construccin
Un caso de uso debe ser simple, inteligible, claro
y conciso
Generalmente hay pocos actores asociados a cada
Caso de Uso
Preguntas clave:
cules son las tareas del actor?
qu informacin 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?
Casos de Uso: Construccin
La descripcin del Caso de Uso comprende:
el inicio: cundo y qu actor lo produce?
el fin: cundo se produce y qu valor devuelve?
la interaccin actor-caso de uso: qu mensajes
intercambian ambos?
objetivo del caso de uso: qu lleva a cabo o
intenta?
cronologa y origen de las interacciones
repeticiones de comportamiento: qu operaciones
son iteradas?
situaciones opcionales: qu ejecuciones
alternativas se presentan en el caso de uso?
RF- <id del requisito> <nombre del requisito funcional>
Versin <numero de versin y fecha>
Autores <autor>
Fuentes <fuente de la versin actual>
Objetivos asociados <nombre del objetivo>
Descripcin El sistema deber comportarse tal como se describe en
el siguiente caso de uso { concreto cuando <evento de
activacin> , abstracto durante la realizacin de los
casos de uso <lista de casos de uso>}
Precondicin <precondicin del caso de uso>
Paso Accin
1 {El <actor> , El sistema} <accin realizada por el
actor o sistema>, se realiza el caso de uso
< caso de uso RF-x>
2 Si <condicin>, {el <actor> , el sistema} <accin
realizada por el actor o sistema>>, se realiza el
caso de uso < caso de uso RF-x>
3
4
5
6
Secuencia
Normal
n
Postcondicin <postcondicin del caso de uso>
Paso Accin
1 Si <condicin de excepcin>,{el <actor> , el
sistema} }<accin realizada por el actor o
sistema>>, se realiza el caso de uso
< caso de uso RF-x>, a continuacin este caso
de uso {continua, aborta}
2
Excepciones
3
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 presin, inmediatamente}
Comentarios <comentarios adicionales>

Modelo de Casos de Uso y
Modelo Conceptual (Anlisis)
La especificacin de cada caso de uso y
los correspondientes D. de Interaccin
establecen el vnculo con el modelo
conceptual
En mtodos OO que carecen de una
tcnica de captura de requisitos se
comienza inmediatamente con la
construccin del modelo conceptual
(anlisis)
Diagramas de Interaccin
Interaccin
Los objetos interactan para realizar
colectivamente los servicios ofrecidos por
las aplicaciones. Los diagramas de
interaccin muestran cmo se comunican
los objetos en una interaccin
Existen dos tipos de diagramas de
interaccin: el Diagrama de Colaboracin
y el Diagrama de Secuencia
Mensajes:
Sintaxis para mensajes
Predecesor/fuarda secuencia:retorno := msg
(args)
Diagramas de interaccin
El Diagrama de Secuencia es ms
adecuados para observar la perspectiva
cronolgica de las interacciones
El Diagrama de Colaboracin ofrece una
mejor visin espacial mostrando los
enlaces de comunicacin entre objetos
El D. de Colaboracin puede obtenerse
automticamente a partir del
correspondiente D. de Secuencia (o
viceversa)
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
envo y la atencin se puede indicar
usando una lnea oblicua
mostrando foco de control,
condiciones, recursin
creacin y destruccin
de objetos
Son tiles en la fase exploratoria para
identificar objetos
La distribucin de los objetos en el
diagrama permite observar
adecuadamente la interaccin de un
objeto con respecto de los dems
La estructura esttica viene dada por los
enlaces; la dinmica por el envo de
mensajes por los enlaces
Mensajes
Un mensaje
desencadena una
accin en el objeto
destinatario
Un mensaje se enva
si han sido enviados
los mensajes de una
lista (sincronizacin):

Un mensaje se
enva de manera
condicionada:
A
B
A.1, B.3 / 1:Mensaje
A
B
[x>y] 1: Mensaje
Mensajes
Un mensaje que devuelve un
resultado:

A
B
1: distancia:= mover(x,y)
Diagrama de Clases
Clasificacin
El mundo real puede ser visto desde
abstracciones diferentes (subjetividad)
Mecanismos de abstraccin:
Clasificacin / Instanciacin
Composicin / Descomposicin
Agrupacin / Individualizacin
Especializacin / Generalizacin
La clasificacin es uno de los mecanismos
de abstraccin ms utilizados
Clases
La clase define el
mbito de
definicin de un
conjunto de
objetos
Cada objeto
pertenece a una
clase
Los objetos se
crean por
instanciacin de
las clases

Cada clase se
representa en un
rectngulo con tres
compartimientos:
nombre de la clase
atributos de la clase
operaciones de la
clase
motocicleta
color
cilindrada
velocidad maxima
arrancar
acelerar
frenar
Clases: Notacin Grfica
Otros ejemplos:

lista
primero
ultimo
aadir
quitar
cardinalidad
pila
apilar
desapilar
cardinalidad
Clases: Encapsulacin
La encapsulacin presenta dos ventajas
bsicas:
Se protegen los datos de accesos indebidos
El acoplamiento entre las clases se disminuye
Favorece la modularidad y el mantenimiento
Los atributos de una clase no deberan ser
manipulables directamente por el resto de
objetos
Clases: Encapsulacin (Recordar)
Los niveles de encapsulacin estn
heredados de los niveles de C++:
(-) Privado : es el ms fuerte. Esta parte es
totalmente invisible (excepto para clases
friends en terminologa C++)
(#) Los atributos/operaciones protegidos estn
visibles para las clases friends y para las clases
derivadas de la original
(+) Los atributos/operaciones pblicos son
visibles a otras clases (cuando se trata de
atributos se est transgrediendo el principio de
encapsulacin)
Clases: Encapsulacin
Ejemplo:
Reglas de visibilidad
+ Atributo pblico : int
# Atributo protegido : int
- Atributo privado : int
+ "Operacin pblica"
# "Operacin protegida"
- "Operacin privada"
Relaciones entre Clases
Los enlaces entre de objetos pueden
representarse entre las respectivas clases
Formas de relacin entre clases:
Asociacin y Agregacin (vista como un caso
particular de asociacin)
Generalizacin/Especializacin
Las relaciones de Agregacin y
Generalizacin forman jerarquas de
clases
Asociacin
La asociacin expresa una conexin
bidireccional entre objetos
Una asociacin es una abstraccin de la
relacin existente en los enlaces entre los
objetos
Universidad
Estudiante
Univ. de Murcia:Universidad Antonio:Estudiante
Una asociacin
Un enlace
Asociacin
Ejemplo:

Persona Compaa
trabaja-para
nombre
s. s.
nombre
direccin
jefe
Administra
empleado
*
*
emplea-a
0.. 1
0.. 1
0.. 1
*
marido
casado-con
mujer
Asociacin
Especificacin de multiplicidad
(mnima...mxima)
1 Uno y slo 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 mnima >= 1 establece
una restriccin de existencia
Asociacin Cualificada
Aerolnea Viajero nro_billete
*
0..1
Tablero
Ajedrez
fila
columna
1
1
Cuadro
Reduce la multiplicidad del rol opuesto al considerar el valor
del cualificador
Agregacin
La agregacin representa una relacin
parte_de entre objetos
En UML se proporciona una escasa
caracterizacin de la agregacin
Puede ser caracterizada con precisin
determinando las relaciones de
comportamiento y estructura que existen
entre el objeto agregado y cada uno de
sus objetos componentes
Agregacin: Caracterizacin
Caracterizaciones relacionadas con la multiplicidad
Objeto Agregado
Objeto Componente
Mxima
1 disjunto
> 1 no disjunto

Multiplicidad Mxima
1 univaluado
> 1 multivaluado

Multiplicidad Mnima
0 flexible
> 0 estricta Multiplicidad

Multiplicidad Mnima
0 nulos permitidos
> 0 nulos no permitidos
(mn
c
, mx
c
)
(mn
a
, mx
a
)
... Agregacin: Caracterizacin
En UML slo se distingue entre agregacin
y composicin (aggregate composition),
siendo esta ltima disjunta y estricta
Adems se una agregacin se podra
caracterizar segn:
Puede el objeto parte comunicarse
directamente con objetos externos al objeto
agregado?
No => inclusiva
Si => no inclusiva
Puede cambiar La composicin del objeto
agregado?
Si => dinmica
No => esttica
Ejemplos

... Ejemplos

Ejemplos
Cuenta
Persona
1
*
or
Asociacin excluyente
Empresa
*
*
Usuario Estacin
est-autorizado-en
prioridad
privilegios
camb_privil
Autorizacin
*
*
Clase de asociacin
Polgono
Punto
contiene
3.. * 1
{ordenado}
Agregacin
Clases y Objetos
Diagrama de Clases y Diagramas de
Objetos pertenecen a dos vistas
complementarias del modelo
Un Diagrama de Clases muestra la
abstraccin de una parte del dominio
Un Diagrama de Objetos representa una
situacin concreta del dominio
Las clases abstractas no son instanciadas
Generalizacin
Permite gestionar la complejidad
mediante un ordenamiento taxonmico de
clases
Se obtiene usando los mecanismos de
abstraccin de Generalizacin y/o
Especializacin
La Generalizacin consiste en factorizar
las propiedades comunes de un conjunto
de clases en una clase ms general

... Generalizacin
Nombres usados: clase
padre - clase hija. Otros
nombres: superclase -
subclase, clase base -
clase derivada
Las subclases heredan
propiedades de sus clases
padre, es decir, atributos
y operaciones (y
asociaciones) de la clase
padre estn disponibles
en sus clases hijas
La Generalizacin y
Especializacin son
equivalentes en
cuanto al resultado: la
jerarqua y herencia
establecidas
Generalizacin y
Especializacin no son
operaciones reflexivas
ni simtricas pero s
transitivas
... Generalizacin

Vehculo
Veihculo Terrestre Vehculo Areo
Coche Camin Avin Helicptero
... Generalizacin
La especializacin es una tcnica muy
eficaz para la extensin y reutilizacin

Restricciones predefinidas en UML:
disjunta - no disjunta
total (completa) - parcial (incompleta)
Funcionando Estropeado
Coche
... Generalizacin
La nocin de clase est
prxima a la de conjunto
Dada una clase, podemos
ver el conjunto relativo a
las instancias que posee o
bien relativo a las
propiedades de la clase
Generalizacin y
especializacin expresan
relaciones de inclusin
entre conjuntos
Particionamiento del
espacio de objetos =>
Clasificacin Esttica
Particionamiento del
espacio de estados de
los objetos =>
Clasificacin Dinmica
En ambos casos se
recomienda considerar
generalizaciones/espe
cializaciones disjuntas
... Generalizacin
Un ejemplo de Clasificacin
Esttica:
Vehculo Areo
Avin Helicptero
{ esttica }
... Generalizacin
Un ejemplo de Clasificacin
Dinmica:

Funcionando Estropeado
Coche
{ dinmica }
... Generalizacin
Extensin: Posibles instancias de una
clase
Intensin: Propiedades definidas en una
clase
int(A) int(B)

ext(B) ext(A)
A
B
... Generalizacin
Clasificacin Esttica

ext(C
0
) = ext(C
i
) completa
ext(C
i
) ext(C
j
) = disjunta
C
0
C
1
C
n
{ static }
... Generalizacin
Clasificacin Dinmica

ext(C
0
) = ext(C
i
) completa
ext
t
(C
i
) ext
t
(C
j
) = disjunta en t

ext
t1
(C
i
) ext
t2
(C
j
) posiblemente
no disjunta en
diferentes
instantes
C
0
C
1
C
n
{ dinmica }
... Generalizacin
Ejemplo: varias especializaciones a partir de
la misma clase padre, usando
discriminadores:

Vehculo Areo
Avin Helicptero
Comercial Militar
estructura
uso
Clasificacin Mltiple (herencia mltiple)
Se presenta cuando una subclase tiene
ms de una superclase
La herencia mltiple debe manejarse con
precaucin. Algunos problemas son el
conflicto de nombre y el conflicto de
precedencia
Se recomienda un uso restringido y
disciplinado de la herencia. Java y Ada 95
simplemente no ofrecen herencia mltiple
Herencia Mltiple
Uso disciplinado de la herencia mltiple:
clasificaciones disjuntas con clases padre en hojas de
jerarquas alternativas
Animal
Bpedo Cuadrpedo
Con Pelos
Con Plumas
Con Escamas
Herbvoro
Carnvoro
cubertura
cobertura
cobertura
comida
nro patas nro patas
comida
Conejo
Principio de Sustitucin
El Principio de Sustitucin 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
semntica del programa escrito en
los trminos de la superclase se vea
afectado.
Principio de Sustitucin
Dado que los programadores pueden
introducir cdigo en las subclases
redefiniendo las operaciones, es posible
introducir involuntariamente
incoherencias que violen el principio de
sustitucin
El polimorfismo que veremos a
continuacin no debera implementarse
sin este principio
Polimorfismo
El trmino polimorfismo se refiere a que
una caracterstica 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
Polimorfismo
Ejemplo: todo animal duerme, pero
cada clase lo hace de forma distinta
dormir
?
?
Ani mal
dormi r()
Len Oso Ti gre
Polimorfismo
Dormir()
{
en un rbol
}
Dormir()
{
sobrela espalda
}
Dormir()
{
sobre el vientre
}
Dormir()
{
}
Animal
dormir()
Len
dormir()
Oso
dormir()
Tigre
dormir()
Polimorfismo
La bsqueda automtica del cdigo
que en cada momento se va a
ejecutar es fruto del enlace
dinmico
El cumplimiento del Principio de
Sustitucin permite obtener un
comportamiento y diseo coherente
Diagrama de Estados
Diagrama de Estados
Los Diagramas de Estados
representan autmatas de
estados finitos, desde el
p.d.v. de los estados y las
transiciones
Son tiles slo para los
objetos con un
comportamiento
significativo
El formalismo utilizado
proviene de los
Statecharts (Harel)
Cada objeto est en un estado en
cierto instante
El estado est caracterizado
parcialmente por los valores
algunos 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
Diagrama de Estados
Los D. de Estados son autmatas
jerrquicos que permiten expresar
concurrencia, sincronizacin y jerarquas
de objetos
Los D. de Estados son grafos dirigidos
Los D. De Estados de UML son
deterministas
Los estados inicial y final estn
diferenciados del resto
La transicin entre estados es instantnea
y se debe a la ocurrencia de un evento

Diagrama de Estados
Estados y Transiciones

A
B
Evento [condicin] / Accin
Tanto el evento como la accin se
consideran instantneos
Diagrama de Estados
Ejemplo de un Diagrama de Estados
para la clase persona:
en el paro en activo
jubilado
contratar
perder empleo
jubilarse
jubilarse
Acciones
Podemos especificar la solicitud de un
servicio a otro objeto como consecuencia de
la transicin:

A
B
Evento [condicin] / OtroObjeto.Operacin

Acciones
Se puede especificar el ejecutar una accin
como consecuencia de entrar, salir, estar en
un estado, o por la ocurrencia de un evento
estado A
entry: accin por entrar
exit: accin por salir
do: accin mientras en estado
on evento: accin
Generalizacin de Estados
Podemos reducir la complejidad de estos
diagramas usando la generalizacin 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
Ejemplo:
A
B
C
e1
e2
e2
Quedara como:
C
a b
A
B
e1
e2
Las transiciones de entrada deben ir hacia
subestados especficos:
C
a b
A
B
e1
e2
e0
Es preferible tener estados iniciales de
entrada a un nivel de manera que desde los
niveles superiores no se sepa a qu
subestado se entra:
C
a b
A
B
e1
e2
e1
e0
La agregacin de estados es la
composicin de un estado a partir
de varios estados independientes
La composicin es concurrente por
lo que el objeto estar en alguno de
los estados de cada uno de los
subestados concurrentes
Ejemplo:
e1
e1
Ejemplo:
Historia
Por defecto, los autmatas no tienen
memoria
Es posible memorizar el ltimo subestado
visitado para recuperarlo en una
transicin entrante en el superestado que
lo engloba
Tambin es posible la memorizacin para
cualquiera de los subestados anidados
(aparece un * junto a la H)
Historia
Ejemplo:
A
d2
d1
H*
B
C
x y
D
out
in
Historia
Ejemplo:
Enjuague Lavado
Secado
H
Enjuague Lavado
Secado
H
Espera
abir puerta
cerrar puerta
Destruccin del Objeto
La destruccin de un objeto es
efectiva cuando el flujo de control
del autmata alcanza un estado
final no anidado
La llegada a un estado final anidado
implica la subida al superestado
asociado, no el fin del objeto
Destruccin de Objeto
Ejemplo:
En tierra
Crear(matricula)
En vuelo
aterrizar
despegar
crash
Transiciones temporizadas
Las esperas son actividades que tienen
asociada cierta duracin
La actividad de espera se interrumpe
cuando el evento esperado tiene lugar
Este evento desencadena una transicin
que permite salir del estado que alberga
la actividad de espera. El flujo de control
se transmite entonces a otro estado
Transiciones temporizadas
Ejemplo: A
esperar dinero
entry: Mostrar mensaje
exit: cerrar ranura
B
anular
transaccin
/ Abrir ranura
Depsito efectuado
despus de
30 segundos
El Diagrama de Actividad es una
especializacin del Diagrama de Estado,
organizado respecto de las acciones y
usado para especificar:
Un mtodo
Un caso de uso
Un proceso de negocio (Workflow)
Las actividades se enlazan por
transiciones automticas. Cuando una
actividad termina se desencadena el paso
a la siguiente actividad
Ejemplos
... Ejemplos
... Ejemplos
Los diagramas de
componentes describen
los elementos fsicos del
sistema y sus relaciones
Muestran las opciones
de realizacin
incluyendo cdigo
fuente, binario y
ejecutable
Los componentes representan
todos los tipos de elementos
software que entran en la
fabricacin de aplicaciones
informticas. Pueden ser simples
archivos, paquetes de Ada,
bibliotecas cargadas
dinmicamente, etc.
Las relaciones de dependencia se
utilizan en los diagramas de
componentes para indicar que un
componente utiliza los servicios
ofrecidos por otro componente
Diagramas de Componentes
Ejemplo:
Los Diagramas de Despliegue
muestran la disposicin fsica de los
distintos nodos que componen un
sistema y el reparto de los
componentes sobre dichos nodos
Nodo
Los estereotipos permiten precisar
la naturaleza del equipo:
Dispositivos
Procesadores
Memoria
Los nodos se interconectan
mediante soportes bidireccionales
que pueden a su vez estereotiparse
Ejemplo de conexin entre nodos:
Terminal Punto
de Venta
<<Cliente>>
Base de
Datos
<<Servidor>>
Control
<<TCP/IP>>
<<RDSI>>
Podemos distinguir tipos
de nodos y connexiones
por estereotipado
<<RDSI>>
Proceso de Desarrollo de SW
basado en UML
Qu es un Proceso de Desarrollo de SW?
Define Quin debe hacer Qu, Cundo y
Cmo debe hacerlo

No existe un proceso de software
universal. Las caractersticas de cada
proyecto (equipo de desarrollo, recursos,
etc.) exigen que el proceso sea
configurable
Requisitos nuevos
o modificados
Sistema nuevo
o modificado
Proceso de Desarrollo
de Software
Historia de RUP
Pruebas funcionales
Pruebas de desempeo
Gestin de requisitos
Gestin de cambios y
configuracin
Ingeniera de Negocio
Ingeniera de datos
Diseo de interfaces
Rational Unified Process
1998
Rational Objectory Process
1996-1997
Objectory Process
1987-1995
Enfoque Ericsson
UML
Dos dimensiones
Fases e Hitos (Milestones)
tiempo
Objetivos
(Vision)

Arquitectura

Capacidad
Operacional
Inicial

Release
del Producto
Inception Elaboration Construction Transition
Elementos en RUP
Workflows (Disciplinas)
Workflows Primarios
Business Modeling (Modado del Negocio)
Requirements (Requisitos)
Analysis & Design (Anlisis y Diseo)
Implementation (Implementacin)
Test (Pruebas)
Deployment (Despliegue)
Workflows de Apoyo
Environment (Entorno)
Project Management (Gestin del Proyecto)
Configuration & Change Management (Gestin
de Configuracin y Cambios)
... Elementos en RUP
Workflow, Workflow Detail , Workers, Actividades
y Artefactos. Ejemplos
Workflow Detail:Analyse the Problem Workflow: Requirements
Actividades
Workers
Artefactos
Workers
Analyst workers
Business-Process
Analyst
Business Designer
Business-Model
Reviewer
Requirements
Reviewer
System Analyst
Use-Case Specifier
User-Interface
Designer
Developer workers
Architect
Architecture
Reviewer
Capsule Designer
Code Reviewer
Database Designer
Design Reviewer
Designer
Implementer
Integrator
Testing professional
workers
Test Designer
Tester
Manager workers
Change Control
Manager
Configuration Manager
Deployment Manager
Process Engineer
Project Manager
Project Reviewer
Other workers
Any Worker
Course Developer
Graphic Artist
Stakeholder
System Administrator
Technical Writer
Tool Specialist

Workers, Actividades, Artefactos
Ejemplo: System Analyst Worker

Artefactos
Resultado parcial o
final que es producido
y usado durante el
proyecto. Son las
entradas y salidas de
las actividades
Un artefacto puede
ser un documento, un
modelo o un elemento
de modelo
Conjuntos de
Artefactos
Business Modeling
Set
Requirements Set
Analysis & Design Set
Implementation Set
Test Set
Deployment Set
Project Management
Set
Configuration & Change
Management Set
Environment Set
Artefactos, Workers, Actividades
Ejemplo:Business Modeling Artifact Set

Caractersticas Esenciales de RUP
Proceso Dirigido por los Casos de
Uso
Proceso Iterativo e Incremental
Proceso Centrado en la Arquitectura

Requisitos
Capturar, definir y
validar los casos de uso
Realizar los
casos de uso
Verificar que se
satisfacen los casos
de uso
Anlisis & Diseo
Implementacin
Pruebas

Casos de Uso
integran el
trabajo

Proceso dirigido por los Casos de Uso
Caso de Uso Realizacin de Anlisis Realizacin de Diseo
Caso de Prueba
X
trace trace
trace
trace
Pruebas Funcionales
Pruebas
Unitarias
[The Unified Software Development Process. I. Jacobson, G. Booch and J. Rumbaugh. Addison-Wesley, 1999]
... Proceso dirigido por los Casos de Uso
..Proceso dirigido por los casos de Uso
El ciclo de vida iterativo se basa en la
evolucin de prototipos ejecutables que
se muestran a los usuarios y clientes
En el ciclo de vida iterativo a cada
iteracin se reproduce el ciclo de vida en
cascada a menor escala
Los objetivos de una iteracin se
establecen en funcin de la evaluacin de
las iteraciones precedentes
... Proceso Iterativo e Incremental
Las actividades se encadenan en una mini-
cascada con un alcance limitado por los
objetivos de la iteracin
Anlisis
Diseo
Codific.
Pruebas e
Integracin
n veces
Cada iteracin comprende:
Planificar la iteracin (estudio de riesgos)
Anlisis de los Casos de Uso y escenarios
Diseo de opciones arquitectnicas
Codificacin y pruebas. La integracin del nuevo
cdigo con el existente de iteraciones anteriores
se hace gradualmente durante la construccin
Evaluacin de la entrega ejecutable (evaluacin
del prototipo en funcin de las pruebas y de los
criterios definidos)
Preparacin de la entrega (documentacin e
instalacin del prototipo)
Enfoque
Cascada
Enfoque
Iterativo e
Incremental
Grado de Finalizacin de Artefactos
Proceso Centrado en la Arquitectura
Arquitectura de un sistema es la organizacin o
estructura de sus partes ms relevantes
Un arquitectura ejecutable es una implementacin
parcial del sistema, construida para demostrar
algunas funciones y propiedades
RUP establece refinamientos sucesivos de una
arquitectura ejecutable, construida como un
prototipo evolutivo
Architecture
Inception Elaboration Construction Transition
Fases del Ciclo de Vida
El ciclo de vida consiste en una serie de ciclos,
cada uno de los cuales produce una nueva versin
del producto
Cada ciclo est compuesto por fases y cada una
de estas fases est compuesta por un nmero de
iteraciones
Las fases son:
Inicio o Estudio de oportunidad
Elaboracin
Construccin
Transicin
...Fases del Ciclo de Vida
Inicio o Estudio de oportunidad
(inception)
Define el mbito y objetivos del proyecto
Se define la funcionalidad y capacidades del
producto
Elaboracin
Tanto la funcionalidad como el dominio del
problema se estudian en profundidad
Se define una arquitectura bsica
Se planifica el proyecto considerando recursos
disponibles
Construccin
El producto se desarrolla a travs de iteraciones
donde cada iteracin involucra tareas de anlisis,
diseo e implementacin
Las fases de estudio y anlisis slo dieron una
arquitectura bsica que es aqu refinada de
manera incremental conforme se construye (se
permiten cambios en la estructura)
Gran parte del trabajo es programacin y pruebas
Se documenta tanto el sistema construido como el
manejo del mismo
Esta fase proporciona un producto construido
junto con la documentacin
Transicin
Se libera el producto y se entrega al usuario
para un uso real
Se incluyen tareas de marketing, empaquetado
atractivo, instalacin, configuracin,
entrenamiento, soporte, mantenimiento, etc.
Los manuales de usuario se completan y
refinan con la informacin anterior
Estas tareas se realizan tambin en iteraciones
Esfuerzo respecto de las Workflows
15%
10%
15%
30%
15%
10% gestin cambios 5% mantenimiento
P r e l i m i n a r y
I t e r a t i o n ( s )
i t e r .
# 1
i t e r .
# 2
i t e r .
# n
i t e r .
# n + 1
i t e r .
# n + 2
i t e r .
# m
i t e r .
# m + 1
I n c e p t i o n E l a b o r a t i o n C o n s t r u c t i o n T r a n s i t i o n
Una iteracin en la
fase de elaboracin
Requisitos
Diseo
Implementacin
Pruebas
Anlisis
...Esfuerzo respecto de las Fases
P r e l i m i n a r y
I t e r a t i o n ( s )
i t e r .
# 1
i t e r .
# 2
i t e r .
# n
i t e r .
# n + 1
i t e r .
# n + 2
i t e r .
# m
i t e r .
# m + 1
I n c e p t i o n E l a b o r a t i o n C o n s t r u c t i o n T r a n s i t i o n
Esfuerzo: 5% 20% 65% 10%
Duracin: 10% 30% 50% 10%
Una iteracin en la
fase de elaboracin
Requisitos
Diseo
Implementacin
Pruebas
Anlisis
UML - ANEXO
Fundamentos del Modelado OO
Para evaluacin por parte de los
alumnos
Objetos
Objeto = unidad atmica que encapsula estado
y comportamiento

La encapsulacin en un objeto permite una alta
cohesin y un bajo acoplamiento

Un objeto puede caracterizar una entidad fsica
(coche) o abstracta (ecuacin matemtica)
Objetos
El Modelado de Objetos permite
representar el ciclo de vida de los
objetos a travs de sus interacciones
En UML, un objeto se representa por
un rectngulo con un nombre
subrayado
Otro
Objeto
Un Objeto
Otro
Objeto
ms
Objetos
Ejemplo de varios objetos
relacionados:
Felipe
Juan
Cuenta Corriente 101
Cuenta Corriente 114
Banco de Valencia
Objetos
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
...
Clases y Objetos
Identidad
Oid (Object Identifier)
Cada objeto posee un oid. El oid establece la
identidad del objeto y tiene las siguientes
caractersticas:
Constituye un identificador nico y global para
cada objeto dentro del sistema

Es determinado en el momento de la creacin del
objeto

Es independiente de la localizacin fsica del
objeto, es decir, provee completa independencia
de localizacin

Es independiente de las propiedades del
objeto, lo cual implica independencia de valor
y de estructura
No cambia durante toda la vida del objeto.
Adems, un oid no se reutiliza aunque el
objeto deje de existir
No se tiene ningn control sobre los oids y su
manipulacin resulta transparente
Sin embargo, es preciso contar con algn
medio para hacer referencia a un objeto
utilizando referencias del dominio (valores de
atributos)
Identidad
Estado
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
Las operaciones de un objeto son
consecuencia de un estmulo externo
representado como mensaje enviado
desde otro objeto
Comportamiento
Ejemplo de interaccin:
Otro objeto
Un objeto
Un mensaje
Operacion 1
Operacion 2
Comportamiento
Los mensajes navegan por los enlaces, a
priori en ambas direcciones

Estado y comportamiento estn
relacionados
Ejemplo: no es posible aterrizar un avin
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
Podremos despus reconstruirlo, es decir,
tomarlo de memoria secundaria para utilizarlo
en la ejecucin (materializacin del objeto)

Los lenguajes OO no proponen soporte
adecuado para la persistencia, la cual debera
ser transparente, un objeto existe desde su
creacin hasta que se destruya
Comunicacin
Un sistema informtico puede verse
como un conjunto de objetos
autnomos y concurrentes que trabajan
de manera coordinada en la consecucin
de un fin especfico

El comportamiento global se basa pues
en la comunicacin entre los objetos
que la componen
Comunicacin
Categoras de objetos:
Activos - Pasivos
Cliente Servidores, Agentes
Objeto Activo: posee un hilo de ejecucin
(thread) propio y puede iniciar una
actividad
Objeto Pasivo: no puede iniciar una
actividad pero puede enviar estmulos 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
III. El Paradigma OO: Fundamentos de Modelado OO
Comunicacin
Los agentes renen las caractersticas
de clientes y servidores
Son la base del mecanismo de
delegacin
Introducen indireccin: un cliente
puede comunicarse con un servidor
que no conoce directamente
Comunicacin
Ejemplo en el que un agente hace de
aislante:
Un agente
Un cliente
Sevidor 1
Servidor 2
El Concepto de Mensaje
La unidad de comunicacin entre objetos se
llama mensaje
El mensaje es el soporte de una comunicacin
que vincula dinmicamente los objetos que
fueron separados previamente en el proceso
de descomposicin
Adquiere toda su fuerza cuando se asocia al
polimorfismo y al enlace dinmico

El Concepto de Mensaje
Objeto 4 Objeto 3
Objeto 2
Objeto 1
: Mensaje E
: Mensaje D
: Mensaje C
: Mensaje A
Mensaje y Estmulo
Un estmulo causar la invocacin de una
operacin, la creacin o destruccin de un
objeto o la aparicin de una seal
Un mensaje es la especificacin de un estmulo
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)

Clase 6

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Clase 6

Cargado por

Copyright:

Formatos disponibles

UNPSJB - 2005 Ingeniera de Software - Clase 6 1

También podría gustarte