1. Desarrollo de software orientado
a objetos
Unidad 4:
Modelo de Análisis

2. Agenda
 Introducción
 Clases de Análisis
 Modelo Conceptual

3. Introducción

4. Introducción
 En el Workflow de Análisis se
analizan, refinan y estructuran los
requerimientos capturados con el
propósito de estructurar el sistema
completo.
 Los modelos que se desarrollan
describen qué es lo que el sistema
va a hacer.

5. Introducción
 Los modelos que se desarrollan están
orientados al problema y no al
ambiente en el que el sistema va a ser
desarrollado e implementado.
 El modelo de análisis proporciona una
configuración conceptual del sistema
que consiste de objetos de control,
entidad e interfaces.

6. Introducción
 Se describe un diagrama preliminar
de clases persistentes (Modelo
Conceptual)
 Se describen el comportamiento
preliminar del sistema (Diagrama de
Secuencia del Sistema y Contratos).

7. Modelo de Casos de Uso vs.
Modelo de Análisis
Modelo de Casos de Uso
Modelo de Análisis
 Se describe usando el  Se describe usando el
lenguaje del cliente.
lenguaje del
desarrollador.
 Es la vista externa del
 Es la vista interna del
sistema.
sistema

8. Modelo de Casos de Uso vs.
Modelo de Análisis
Modelo de Casos de Uso
Modelo de Análisis
 Se usa a manera de
 Se usa para que los
contrato entre clientes
desarrolladores
y desarrolladores para
comprendan como
definir lo que el sistema
el sistema debe ser
debe y no debe hacer
diseñado e
implementado.

9. Modelo de Casos de Uso vs.
Modelo de Análisis
Modelo de Casos de Uso
 Puede contener

redundancias e
inconsistencias en el
enlace con los
requerimientos.
 Captura funcionalidad 
del sistema
Modelo de Análisis
No debe contener
redundancias ni
inconsistencias en la
interpretación de los
requerimientos.
Bosqueja como
realizar la
funcionalidad dentro
del sistema.

10. Clases de Análisis

11. Clases de análisis
 El modelo conceptual de clases de
análisis ayuda a refinar los
requerimientos y permite a los
desarrolladores describir la estructura
interna del sistema.
 Los estereotipos son tres: interfaces,
entidades y controladoras

12. Clases Interfaz o Frontera
 Las Clases “Boundary” se usan para
modelar la interacción entre el
sistema y los actores.
 Esta interacción involucra recibir (y
presentar) información y peticiones
desde usuarios y sistemas externos.

13. Clases Interfaz o Frontera
 Representan la abstracción de de
ventanas, formularios, paneles,
interfaces de comunicación,
impresoras, sensores, terminales o
dispositivos.

14. Clases Interfaz o Frontera
Ejemplo:
 La interfaz de pago es usada para
soportar la interacción entre el actor
cajero y el caso de uso de Registrar
Pago.
Cajero
Interfaz Pago

15. Clases Entidad
 Las Clases Entidad (Entity) son usadas
para modelar la información que tiene
permanencia en el tiempo y es
persistente.
 Modelan la información y el
comportamiento asociado de algún
concepto como una persona, evento
u objeto del mundo real.

16. Clases Entidad
 Usualmente muestran la estructura de
datos lógica que contribuye a la
comprensión de la información que
depende el sistema.

17. Clases Entidad
Ejemplo:
 La clase entidad Pago permite
mostrar la información de un pago
en la interfaz de pago.
consulta
Cajero
Interfaz Pago
Pago

18. Clase Controladora
 Las clases “control” representan la
coordinación, secuencia, gestión de
transacciones y control de otros
objetos.
 Usualmente se usan para encapsular el
control relacionado con un caso de
uso específico.

19. Clase Controladora
 También se usan para representar
cálculos y derivaciones complejas,
como la lógica del negocio que no se
puede relacionar con ninguna entidad.
 La dinámica del sistema se modela en
una clase controladora, que se encarga
de delegar trabajo a otras clases.

20. Clase Controladora
Ejemplo:
 La controladora de pagos es
responsable de la coordinación entre la
interfaz de pagos y la entidad pago.
Registrar
Crear
Cajero
Interfaz
Pago
Controladora
de Pagos
Pag

21. Diagrama de Clases
 Es un diagrama que muestra las clases
de análisis y sus relaciones.
 Se realizan para cada Caso de Uso.
Registrar
Crear
Cajero
Interfaz
Pago
Controladora
de Pagos
Pag
o

22. ¿Cómo encontrar clases?
 Análisis de los Casos de Uso.
 Paquetes.

23. Análisis de los Casos de Uso
 Es el proceso de examinar los casos de
uso y descubrir los objetos y clases del
sistema bajo estudio.
 Se pone énfasis en el estudio de los
cursos o flujos de eventos.
 Se descubren y crean las clases
controladoras, entidad y de interfaz.

24. Encontrando Objetos Entidad
 Los objetos entidad se identifican
examinando los nombres y sustantivos
usados en la descripción de los flujos de
eventos.
 Los sustantivos encontrados pueden ser:




Objetos
Descripción del estado de un objeto.
Entidades externas y/o actores.
Nada de lo descrito anteriormente.

25. Filtrando Sustantivos
 Con la identificación de sustantivos
podemos darnos cuenta de que:
 Muchos términos se refieren al mismo
objeto.
 Un término puede referirse a mas de un
objeto.
 El lenguaje natural es muy ambiguo

26. Filtrando Sustantivos
 Este método puede identificar objetos
sin importancia, en consecuencia:
 La lista de nombres debe filtrarse.
 Advertencia: Cualquier nombre puede
verbalizarse y viceversa.

27. Observando los sustantivos
 Un requerimiento se ha expresado
como:
 “Se deben tomar en cuenta las
condiciones legales vigentes al hacer
una venta.”
 Si sólo consideramos los nombres sin
estudiarlos ¿qué pasaría?
Nota: Cada nombre debe ser considerado dentro
Nota: Cada nombre debe ser considerado dentro
del contexto del problema. No singularmente.
del contexto del problema. No singularmente.

28. Escenario normal del caso de uso
“Crear horario”
Acción del actor
Respuesta del sistema
1.
<Estudiante>: Indica
semestre e ingresa su
número de matrícula para
crear un nuevo horario.
2.
Valida el número y muestra
lista de cursos obligatorios
disponibles para el
semestre.
3.
<Estudiante>: Selecciona
cursos obligatorios.
4.
Muestra lista de cursos
electivos del semestre.
5.
<Estudiante>: Selecciona
cursos electivos.
6.
Determina si el alumno
cumple con los
prerrequisitos requeridos
examinando su record
académico y si es así, lo
incorpora al registro de
alumnos del curso.

29. Escenario normal del caso de uso
“Crear horario”
Acción del actor
7. <Estudiante>: Indica
que ha terminado el
registro si todo está
conforme.
Respuesta del sistema
8. Graba el registro de
nuevo horario y
matrícula e imprime
boleta de inscripción.
9. <Estudiante>: Indica fin 10. Envía la información de
de registro.
matrícula al sistema de
pagos.

30. Sustantivos del escenario de
“Crear horario”








Estudiante, número de Matrícula
Sistema
Semestre
Nuevo Horario
Lista de cursos obligatorios disponibles
Cursos obligatorios
Lista de cursos electivos disponibles
Cursos electivos
¿Qué nombres
¿Qué nombres
deben filtrarse?
deben filtrarse?

31. Sustantivos del escenario de
“Crear horario”







Prerrequisitos requeridos
Record académico
Lista de alumnos del Curso
Matrícula
Boleta de inscripción
Información de matrícula
Sistema de Pagos
¿Qué nombres
¿Qué nombres
deben filtrarse?
deben filtrarse?

32. Objetos entidad candidatos
 Nuevo horario: lista de cursos del
estudiante para un semestre.
 Lista de cursos disponibles: lista de los
cursos ofrecidos en un semestre.
 Curso obligatorio: un curso ofrecido
en un semestre.
 Curso electivo: un curso ofrecido en
un semestre.

33. Objetos entidad candidatos
 Prerrequisitos: Una lista de los cursos que
son necesarios para llevar un curso dado.
 Record académico: Una lista de los
cursos llevados por el estudiante en
semestres anteriores.
 Lista de alumnos del curso: Lista de los
estudiantes matriculados en un curso
ofrecido.
 Información de matrícula: Información
requerida por el sistema de pagos.

34. Creando clases entidad
 Los objetos entidad se agrupan en
clases.
 Basados en una estructura y
comportamiento similares.
 Las clases entidad se refinan
estudiando otros escenarios.

35. Clases entidad candidatas
Clase
Descripción
Horario
Lista de los cursos de un
estudiante para un semestre
Lista de todos los cursos ofrecidos
en un semestre
Un curso ofrecido en un semestre
Catálogo
Curso
Prerrequisito
Un curso necesario para llevar
otro curso

36. Clases entidad candidatas
Clase
Descripción
Record
Académico
Alumnos x
Curso
Información
Matrícula
Lista de los cursos previamente
llevados por un estudiante
Lista de los estudiantes
matriculado en un curso ofrecido
Información de la matrícula
requerida por el Sistema de Pagos

37. Encontrando clases interfaz
 Examinar cada par actor / escenario y
crear las clases interfaz obvias.
 Ejemplo:
 Una interfaz “FormularioRegistro” se
requiere para que el estudiante se
identifique y seleccione la opción
deseada.
 Una interfaz “FormularioHorario” se
necesita para ingresar la información de
cursos seleccionados por el estudiante.

38. Prototipo
 Se usan para comunicar la apariencia y manejo de
una interfaz al usuario.

39. Encontrando clases interfaz
 Las clases interfaz se crean también
para la comunicación sistema-asistema.
 Se adicionan para describir el
protocolo de comunicación elegido.

40. Encontrando clases
controladoras
 Las clases controladoras
típicamente contienen
información secuencial.
 Advertencia: No deben realizar
responsabilidades que le
competen a las clases entidad
e interfaz.

41. Encontrando Clases
Controladoras
 En este nivel de análisis debe
adicionarse una controladora por
caso de uso.
 Una sola controladora se
responsabiliza por cada
escenario y flujo de eventos de un
caso de uso.

42. Encontrando Clases
Controladoras
 Este estudio es inicial.
 A medida que se desarrollan mas
casos de uso y sus escenarios se
pueden eliminar, dividir o
combinar.

43. Clase controladora candidata
 Se adicionar una clase de Control
denominada AdministradorRegistros
 Recibe información de la Interfaz
“FormularioHorarios”.
 Para cada curso seleccionado:
 Solicita sus prerrequisitos.
 Verifica en el Record académico del
estudiante si este aprobó los prerrequisitos
del curso de su elección.

44. Clase controladora candidata
 .....
 Sabe que hacer si un prerrequisito no
ha sido aprobado.
 Verifica si el curso esta con cupo.
 Sabe que hacer cuando uno de los
cursos seleccionados por el estudiante
ya no tiene cupo.
 Crea los objetos de Horario e
InformacionMatrícula.
 Asocia el pago al Horario matriculado.

45. Paquetes
 Es un mecanismo de propósito general
para organizar elementos en grupos.
 Como el número de clases crece a
medida que se van analizando más y
más escenarios es conveniente:
 Que las clases se agrupen en paquetes.
 Proporciona la habilidad de organizar el
modelo en desarrollo.
Paquete

46. Paquetes en el Sistema de
Matrícula
 Para agrupar clases podemos reconocer
tres paquetes:
 Artefactos de la Universidad
 Reglas de Negocio e
 Interfaces.
 Artefactos de la Universidad:
 Horario, Catalogo, Curso, RecordAcademico,
AlumnosXCurso InformacionPago.

47. Paquetes en el Sistema de
Matrícula
 Reglas del Negocio:
 AdministradoraRegistros
 Interfaces:
 FormularioRegistro,
FormularioHorario, SistemaPago, e
Impresora.

48. Diagramas de Clases
 Es una vista de los paquetes y clases del
sistema en estudio.
 Usualmente se elabora mas de uno para su
correcta revisión y control.
 El diagrama de clases principal muestra
solamente la relación entre paquetes.
 Los secundarios usualmente muestran las
clases relacionadas con el paquete o con un
caso de uso específico.

49. Diagrama de Clases Principal
Reglas del
Negocio
Interfaces
Arterfactos
de la
Universidad

50. Clases por Paquete
Formulario
Registro
Formulario
Horario
Sistema
de Pago
Interfaces
Impresora

51. Clases por Paquete
Administradora
Registros
Reglas del
Negocio

52. Clases por Paquete
0..n
1
1
Curso
Arterfactos
de la
Universidad
0..n
Catálogo
1
1
0..n
0..n
Record
1
Alumno
Horario
1..n
0..n
1
1
0..n
Matricula
Información
Pago

53. Modelo Conceptual

54. El Modelo Conceptual
 Es una vista que muestra los
conceptos básicos del sistema:
sus partes y relaciones.
 Se utiliza un diagrama de clases
de UML simplificado.
 Es una representación de las
relaciones entre clases entidad.

55. Relaciones
 Son vínculos que se establecen entre los
conceptos o clases.
 En esta primera etapa del análisis
revisaremos las:
 Asociaciones
 Agregaciones
 Herencia

56. Relación de Asociación
 Representa una relación o conexión
semántica entre objetos de diferentes
clases
 Indica un camino de comunicación o
vínculo en el que las objetos de las
clases tienen cierta independencia.

57. Relación de Asociación
 Pueden ser binarias, ternarias o de
orden superior.
 Por defecto son bidireccionales

58. Relación de Asociación
Asociación binaria
 Se denota gráficamente como un
arco sólido conectando dos
símbolos de clase.

59. Relación de Asociación
Asociación binaria
TRIPULANTE
viaja
VUELO

60. Atributos de las Relaciones
 Multiplicidad: Es indicada por un
rango en el rol. Indicar el número de
instancias vinculadas entre las clases.
 Rol: Cada final de la asociación es
un rol (opcionalmente se documenta
con un nombre).

61. La Multiplicidad
 Define cuántas ocurrencias de un tipo
A pueden ser asociados con una
instancia de un tipo B.
VUELO
posee
1
lugar
n
ASIENTO

62. La Multiplicidad
Muchos
Exactamente uno
Cero or muchos
Uno o muchos
Cero o uno
Rango específico
n
1
0..n
1..n
0..1
2..4

63. Atributos de las Relaciones
 Navegabilidad: Indica el grado de
visibilidad que tienen las intancias de
una clase respecto de otra.
 Nombre: Cada asociación puede
tener un nombre

64. Nombre de Asociaciones
Legible y Entendible
AVION
posee
ASIENTO

65. Relación de Asociación
Empresa
Clase
asociativa
1..n
Trabaja-para
1..n
empleador empleado
Trabajador jefe
salario 0..1
trabajador
Persona
Relación
involutiva
n
gerencia
Dirección de lectura del nombre de relación

66. Agregaciones
 Las agregaciones se identifican con
relaciones entre tipos que impliquen
que uno “tiene a” otro.

67. Agregaciones Vs. Asociaciones
Avion
Vuelo
Aeropuerto
¿El Vuelo está compuesto de Avión y
Aeropuerto?

68. Agregación
Contiene
3..*
Polígono
n
1
Punto
Estilo
color
textura
densidad

69. Composición
 Es una forma fuerte de agregación
donde el tiempo de vida de la parte
coincide con el todo.
 Las partes no deben sobrevivir fuera
del todo.
 Operaciones de copia o eliminación al
todo deben propagarse a las partes.
 Soporta encapsulamiento.

70. Agregación vs. Composición
Punto
Círculo
Polígono
Estilo

71. Test de Agregaciones
 ¿Para describir la relación se usa la
frase “es parte de”?
 Una puerta “es parte de” un Carro
 ¿Hay operaciones sobre el todo que
se aplican automáticamente a las
partes?
 Al mover el carro, se mueven sus puertas

72. Test de Agregaciones
 ¿Hay valores de atributos que se
propagan del todo a sus partes?
 El carro es azul, sus puertas son azules
 ¿Existe una asimetría intrínseca en la
relación donde una clase está
subordinada a la otra?
 Las puertas SON parte del carro, un
carro NO ES parte de una puerta

73. Atributos
 Los atributos deben definirse de en
correspondencia con los necesarios
para representar los objetos del
mundo real y no con componentes de
software.

74. Atributos
 No utilizar atributos complejos
(objetos). Utilice asociaciones
Vuelo
Destino
Destino es complejo,
modele como concepto
sus posibles valores

75. Atributos
 No utilizar atributos que sean llaves
foráneas. Utilice asociaciones
Vuelo
NumPiloto
NumPiloto es una llave
foránea, modele una
asociación con Piloto

76. Atributos
 Los atributos “Tipo”, “Categoría”,
“Estado” generalmente no se modelan
como tales.
Vuelo
Tipo
Existe otra forma de
Modelarlos.
¡Son objetos con
comportamientos
Distintos!

77. Herencia
 La herencia define una relación entre clases,
donde una clase comparte estructura y/o
comportamiento con una o mas clases.
 La herencia define una jerarquía de
abstracciones en que una subclase hereda
de una o mas superclases.
 Con una herencia simple, la subclase hereda de
una única superclase.
 Con una herencia múltiple la subclase hereda de
una o mas superclases.

78. Diagramando una Herencia
Usuario
Superclase
Relación de Herencia
Estudiante
Subclase
Herencia es la
Herencia es la
relación que se
relación que se
define como: “es
define como: “es
un” o “es una clase
un” o “es una clase
de”.
de”.

79. Consideraciones
 Desde que la herencia no relaciona
objetos individuales.
 La relación no tiene nombre
 La multiplicidad no es significativa
 En teoría no existen límites para los
niveles de herencia.
 Depende del lenguaje de desarrollo.

80. ¿Qué ventajas tiene la
herencia?
 Una subclase hereda de su padre:
 Atributos
 Operaciones
 Relaciones
 Una subclase puede:
 Tener atributos adicionales, operaciones
y relaciones propios.
 Redefinir operaciones heredadas (¡ Usar
esto con precaución !)

81. Heredando Atributos
 Los atributos son definidos en el mas alto
nivel de la jerarquía de herencia en
donde son aplicables.
 Las subclases de una clase hereda todos
sus atributos.
 Cada subclase puede tener atributos
propios.

82. Heredando Atributos
 Ejemplo
Vehiculo
Peso
NumeroPlaca
Carro
Un camión tiene tres atributos:
Un camión tiene tres atributos:
• NumeroPlaca
• NumeroPlaca
• Peso
• Peso
• Tonelaje
• Tonelaje
Camion
Tonelaje

83. Heredando Operaciones.
 Las operaciones son definidas en el mas
alto nivel de la jerarquía de herencia en
donde son aplicables.
 Las subclases de una clase hereda todas
sus operaciones.
 Cada subclase puede aumentar o
redefinir las operaciones heredadas.

84. Heredando Operaciones.
 Ejemplo:
Un camión tiene tres
Un camión tiene tres
atributos:
atributos:
• NumeroPlaca
• NumeroPlaca
• Peso
• Peso
• Tonelaje
• Tonelaje
y dos operaciones:
y dos operaciones:
• registrar()
• registrar()
• obtenerImp()
• obtenerImp()
Vehiculo
Peso
NumeroPlaca
registrar( )
Camion
Carro
Tonelaje
obtenerImp ( )

85. Heredando Relaciones
 Las relaciones también se heredan y son
definidas en el mas alto nivel de la
jerarquía de herencia en donde son
aplicables
 Las subclases de una clase hereda todas
sus relaciones
 Cada subclase puede participar de otras
relaciones.

86. Heredando Relaciones
 Ejemplo:
Vehiculo
Peso
numeroPlaca
Camion
registrar( )
Carro
0..*
dueña Persona
1
Trailer
tonelaje
obtenerImp()
• Un carro se
• Un carro se
relaciona con su
relaciona con su
dueño
dueño
• Un camión se
• Un camión se
relaciona con su
relaciona con su
dueño
dueño
• Un camión tiene un
• Un camión tiene un
trailer
trailer

87. Jerarquía de herencias
 Tanto la generalización como la
especialización se usan para
desarrollar una jerarquía de
herencias.
 Durante el análisis las herencias de las
clases se establecen si son evidentes
y necesarias.

88. Jerarquía de herencias
 Durante el diseño estas jerarquías se
refinan para:
 Incrementar el reuso.
 Incorporar clases de implementación.
 Incorporar librerías de clases disponibles.

89. Niveles de Abstracción
Vehiculo
Terrestre
Ford
Camion
Aéreo
Avion
Las clases deben ser
Las clases deben ser
modeladas de
modeladas de
acuerdo a un mismo
acuerdo a un mismo
nivel de abstracción
nivel de abstracción
Helicoptero

90. Herencia Múltiple
ObjetoVolador
Animal
Herencia
Múltiple
Avion
Helicoptero
Pajaro
Lobo
Caballo
El Pajaro hereda tanto de ObjetoVolador
El Pajaro hereda tanto de ObjetoVolador
como de Animal
como de Animal

91. Conceptos de herencia múltiple
 Conceptualmente son necesarias
para modelar de manera adecuada
el mundo real.
 En la práctica puede haber problemas
para su implantación.
 No todos los lenguajes del programación
dan soporte al problema de la herencia
múltiple de manera directa.

92. Conceptos de herencia múltiple
 Conceptualmente son necesarias
para modelar de manera adecuada
el mundo real.
Use herencia
Use herencia
 En la práctica puede haber problemas
múltiple sólo cuando
múltiple sólo cuando
para su implantación.
se requiera
se requiera
 No todos los lenguajes del con
pero siempre programación
pero siempre con
le dan soporte al problema ! la
precaución de
precaución !
herencia múltiple de manera directa.

93. Problemas de Herencia Múltiple
Conflicto de nombres en atributos y
operaciones
ObjetoVolador
color
getColor
Animal
color
Herencia Repetida
ObjetoAnimado
color
getColor
ObjetoVolador
Animal
Pajaro
Cada lenguaje/ambiente
Cada lenguaje/ambiente
escoje la manera de
escoje la manera de
resolver el problema
resolver el problema
Pajaro

94. Encontrando la Herencia
 Es importante evaluar todas las clases
para descubrir herencias posibles.
 Examinar el comportamiento común
(operaciones) y estado (atributos) en
clases.
 Técnica de adición...
 Adicionar nuevas operaciones/atributos a
la(s) subclase(s).

95. Encontrando la Herencia
 Técnica de modificación...
 Redefinir operaciones
 Cuidar de no cambiar la semántica. Las
operaciones modificadas no deben
cambiar su propósito.

96. Herencia versus Agregación
 Usualmente se confunden.....
 La herencia representa una relación “es
un”.
 La agregación representa la relación
“tiene a”.
 Esta palabras clave ayudan a aclarar
la relación

97. Window y Scrollbar
Window
Scrollbar
WindowScrollbar
Una WindowScrollbar “es una” Window
Una WindowScrollbar “es una” Window
Una WindowScrollbar “tiene una”
Una WindowScrollbar “tiene una”
Scrollbar
Scrollbar
¿Que relaciones deben usarse?
¿Que relaciones deben usarse?

98. Window y Scrollbar (cont.)
Window
Scrollbar
WindowScrollbar
Window
WindowScrollbar
Scrollbar
1
1

99. Cuadro Comparativo
Herencia
Agregación
• Keywords “es una”
• Keywords “tiene a”
• Un objeto
• Relaciona objetos de
diferentes clases
• Respresentada por una
flecha
• Representada por un diamante

100. ¿Qué es una metamorfosis?
 Es un cambio de forma, estructura o
función
 Cualquier cambio marcado como
en carácter, apariencia o
condición.
Problema: ¿Cómo se puede
Problema: ¿Cómo se puede
modelar?
modelar?

101. Ejemplo:
 En la Universidad hay estudiantes a
tiempo completo y a tiempo
parcial.
 Los estudiantes a tiempo completo
tienen un Id y una fecha de
graduación esperada, pero un
estudiante a tiempo parcial no.
 Los estudiantes a tiempo parcial
pueden tomar un máximo de 3 cursos.
Los a tiempo completo no tienen un
máximo de cursos.

102. Ejemplo:
EstudiantePartTime
Nombre
Direccion
NroDeCursos
EstudianteFullTime
Nombre
Direccion
IDEstudiante
FechaGraduacion

103. Una aproximación.....
Estudiante
Nombre
Direccion
EstudiantePartTime
NroDeCursos
¿Qué pasa si un
¿Qué pasa si un
estudiante a tiempo
estudiante a tiempo
parcial se convierte en
parcial se convierte en
un estudiante a tiempo
un estudiante a tiempo
completo?
completo?
EstudianteFullTime
IDEstudiante
FechaGraduacion

104. Definiciones
 Es muy difícil cambiar la clase de un
objeto.
 Una mejor técnica de
modelamiento es…:
 Situar la estructura y comportamiento
que “cambia” dentro de la propia
clase.

105. Definiciones
Estudiante
Nombre
Direccion
0,1
ClasificaPartTime
NroDeCursos
0,1
ClasificaFullTime
IDEstudiante
FechaGraduacion

106. Definiciones (cont.)
Mary Smith
Full time student
MarySmith : Estudiante
1
1
: ClasificaFullTime
Joe Jones
Part time student
JoeJones : Estudiante
1
1
: ClasificaPartTime

107. Definiciones (cont.)
 La Metamorfosis está acompañada
de la conversación de un objeto a
sus partes cambiantes.
: Control
Estudiante
: Clasifica
PartTime
: Estudiante
CambiarAFullTime()
Eliminar()
Crear()
:Clasifica
FullTime

108. Metamorfosis y herencia
 La herencia se debe usar para modelar
la estructura, comportamiento y/o
relaciones comunes para las partes
“cambiantes”.
Estudiante
1
Nombre
Direccion
FullTime
IDEstudiante
FechaGraduacion
Clasificacion
PartTime
NroCursos

109. Metamorfosis y flexibilidad
 Esta técnica también adiciona flexibilidad
al modelo.
 Ejemplo: Un estudiante puede también
vivir en el campus. En este caso, existe un
identificador de residencia (pabellón), un
número de cuarto y de llave.

110. Metamorfosis y flexibilidad
Estudiante
InformacionResidencia
Pabellon
Cuarto
IDCuarto
0..1
1
Nombre
Direccion
1
Clasificacion
FullTime
IDEstudiante
FechaGraduacion
PartTime
NroCursos

111. Resumen de Relaciones
 Una asociación es una conexión entre
dos clases que representa
comunicación.
 La multiplicidad es el número de
instancias que participan en una
asociación.
 Se la representa en cada final de la línea
de asociación.

112. Resumen de Relaciones (cont.)
 Una agregación es una forma especial de
asociación en la cual un todo se relaciona
con sus partes.
 Una clase puede tener una asociación
reflexiva o involutiva.
 Dos objetos de una misma clase relacionados
entre si.
 Las agregaciones también pueden ser
involutivas.
 Problemas de Catálogo de Materiales (partes que
se confeccionan a partir de otras partes).

113. Resumen de Relaciones
(cont.)
 La herencia define una relación donde
una clase comparte su estructura y/o
comportamiento con una o mas clases.
 Define una jerarquía de abstracciones en
donde una subclase hereda de una o
muchas superclases.
 Herencia Simple - una clase hereda de
una única superclase.
 Herencia Múltiple - una clase hereda de
mas de una superclase.

114. Resumen de Relaciones
(cont.)
 Una subclase hereda atributos, operaciones
y relaciones de sus superclase(s).
 Una subclase puede:
 Tener atributos, operaciones y relaciones
propias.
 Refinar operaciones heredadas.

115. Resumen de Relaciones (cont.)
 La herencia y la agregación se
confunden usualmente.
 La herencia representa una relación
“es-un” o “es-una-clase-de”.
 La agregación representa una relación
“tiene-a”.