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.
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
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
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
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
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
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.
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.
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.
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?
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.
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.
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.
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”.
Notas del editor
Again, this is what you THINK not what is written !
Again, this is what you THINK not what is written !
Tell the students not to spend a LOT of time trying to figure out all the classes needed for the user interface. The actual classes are very dependent on the type of GUI (and / or GUI Builder) used in design.
Stress that the control class is per use case NOT per scenario.
Caution to students. Make sure the control classes ONLY do the sequencing and that they do not perform the responsibilities that belong to boundary and/or entity classes.
Example: a course has students. It should be the responsibility of the course to add a student and the responsibility of the control class to know WHEN a course should add the student. The control class should not know how to add a student to a class.
Stress that the control class is per use case NOT per scenario.
Caution to students. Make sure the control classes ONLY do the sequencing and that they do not perform the responsibilities that belong to boundary and/or entity classes.
Example: a course has students. It should be the responsibility of the course to add a student and the responsibility of the control class to know WHEN a course should add the student. The control class should not know how to add a student to a class.
Stress that the control class is per use case NOT per scenario.
Caution to students. Make sure the control classes ONLY do the sequencing and that they do not perform the responsibilities that belong to boundary and/or entity classes.
Example: a course has students. It should be the responsibility of the course to add a student and the responsibility of the control class to know WHEN a course should add the student. The control class should not know how to add a student to a class.
Point out that the control class only controls the sequencing in the scenario and is NOT responsible for anything that is covered by the boundary and entity classes.
Point out that the control class only controls the sequencing in the scenario and is NOT responsible for anything that is covered by the boundary and entity classes.
Definition of metamorphosis -- a physical change in form, structure, or function.
This is not just a change in state -- it is a change in the structure and behavior of an object.
This is a very difficult concept for students.