8/20/2019 Analisis y Diseno Orientado a Objetos Co
1/595
1
ANÁLISIS Y DISEÑO
ORIENTADO A OBJETOS
CON UML
ANÁLISIS Y DISEÑO
ORIENTADO A OBJETOS
CON UML
8/20/2019 Analisis y Diseno Orientado a Objetos Co
2/595
2
n Dirigido an Personas con la necesidad de aprender las características y
métodos de la tecnología de objetos, principalmente aquellasque desarrollan sistemas complejos.
n Objetivosn Al finalizar el curso, los participantes podrán:
• Explicar el proceso de desarrollo iterativo e incremental• Definir los requerimientos de un sistema desde el punto de vista
del usuario• Crear un modelo orientado a objetos del comportamiento y de los
aspectos estructurales de los requerimientos de un sistema• Crear una arquitectura lógica de un sistema• Diseñar un sistema aplicando los conceptos de abstracción,
encapsulamiento, herencia, polimorfismo y patrones
Auditorio y Objetivos
8/20/2019 Analisis y Diseno Orientado a Objetos Co
3/595
3
Contenidon Introducción
• Antecedentes del análisis y diseño orientado a objetos yUML
n Desarrollo Iterativo e Incremental• Ciclo de vida del desarrollo de sistemas por medio de unaaproximación iterativa e incremental
n Comportamiento del Sistema• Análisis de requerimientos a través de Casos de Uso (Use
case)• Desarrollo de escenarios
n Objetos y Clases• Definición de objetos, clases, estereotipos y paquetes
8/20/2019 Analisis y Diseno Orientado a Objetos Co
4/595
4
Contenidon Interacción de Objetos
• Representación gráfica del escenario
n Definición de Clases• La aplicación del análisis de Casos de Uso para definir clases
en el sistema• Definición de paquetes• Creación de diagramas de clase
n Relaciones• Definición de relaciones necesarias para la interacción de
objetos
n Operaciones y Atributos• Definición de la estructura y comportamiento de una clase
8/20/2019 Analisis y Diseno Orientado a Objetos Co
5/595
5
Contenidon Herencia
• Aplicación de los principios de generalización y especializaciónpara definir relaciones de superclase/subclase
n Comportamiento de Objetos• Desarrollo de diagramas de transición de estado para mostrar
gráficamente el comportamiento de un objeto
n Homogeneización• Mezclar clases descubiertas en diferentes Casos de Uso
n Arquitectura• Discusión de la Arquitectura “4+1” Vistas
8/20/2019 Analisis y Diseno Orientado a Objetos Co
6/595
6
Contenidon Mecanismos Clave
• Discusión de estrategias de mecanismos clave• Designación de clases• Diseño de la interfaz de usuario
• Incorporación de patrones
n Diseño de relaciones• Soporte C++ para relaciones
n
Diseño de Atributos y Operaciones• Soporte C++ para atributos y operaciones
n Diseño para Herencia• Soporte C++ para herencia
8/20/2019 Analisis y Diseno Orientado a Objetos Co
7/595
7
Contenidon Resumen
• Resumen del curso de análisis y diseño
n Lectura recomendadas• Lista de libros
n Planteamiento del Problema de Nómina• Requerimientos para un sistema de nómina
n
Solución del Problema Nómina• Elaboración del análisis y diseño para el problema denómina
8/20/2019 Analisis y Diseno Orientado a Objetos Co
8/595
8
Introducción
8/20/2019 Analisis y Diseno Orientado a Objetos Co
9/595
9
Objetivos: Introducción
n Usted será capaz de:
• Explicar la crisis del software• Discutir el poder de la tecnología de objetos
• Discutir dónde puede emplearse la tecnología OO
• Definir análisis y diseño
• Explicar el origen del UML
8/20/2019 Analisis y Diseno Orientado a Objetos Co
10/595
8/20/2019 Analisis y Diseno Orientado a Objetos Co
11/595
11
La Crisis del Software (cont.)n En Marzo de 1989, Arthur Andersen reportó
• Más de $300 mil mdd por año invertidos en actividades desoftware comercial en los Estados Unidos
• Sólo el 8% del software entregado brinda resultados yfunciona
n ¿Cuáles son las razones de la crisis delsoftware?• Constantes cambios en los requerimientos• Fallas en el manejo de riesgos• Complejidad del software
8/20/2019 Analisis y Diseno Orientado a Objetos Co
12/595
12
Cambios en los requerimientosn Los requerimientos del negocio se definen en ciclos de
desarrollo más pequeños• Los usuarios esperan más en términos de flexibilidad
n Los requerimientos iniciales generalmente estánpobremente definidos
8/20/2019 Analisis y Diseno Orientado a Objetos Co
13/595
13
Fallas en el Manejo de Riesgosn El ciclo de vida en cascada puede retrasar la identificación
del probleman No hay prueba de que el sistema funcionará, sino hasta el
final del ciclo de vidan El resultado, el máximo riesgo
8/20/2019 Analisis y Diseno Orientado a Objetos Co
14/595
14
Complejidad del Softwaren Está creciendo la demanda de software de negocios
n Nadie entiende el sistema en su totalidad
n Deben mantenerse los sistemas anteriores, pero losdesarrolladores de los mismos ya se han ido
8/20/2019 Analisis y Diseno Orientado a Objetos Co
15/595
15
Poder de la Tecnología de Objetosn Un paradigma único
• Los usuarios, analistas, diseñadores e programadoresutilizan el mismo lenguaje
n Facilita la re-utilización de arquitectura y código
n Los modelos reflejan de manera más cercana al mundoreal• Describe con mayor precisión los procesos y datos• Descomposición basada en partición natural• Más fácil de entender y mantener
n Estabilidad• Un cambio en los requerimientos no significa cambios
masivos en el sistema en desarrollo
8/20/2019 Analisis y Diseno Orientado a Objetos Co
16/595
8/20/2019 Analisis y Diseno Orientado a Objetos Co
17/595
17
Vendedor Producto
Ventas
Corporativo
Cliente
Individual Trailer
Vehiculo
Tren
Diagrama de Clases de Ventas
8/20/2019 Analisis y Diseno Orientado a Objetos Co
18/595
18
Efecto en el Cambio de
Requerimientos
Vendedor Producto
Ventas
Corporativo
Cliente
Individual Trailer
Vehiculo
Tren
8/20/2019 Analisis y Diseno Orientado a Objetos Co
19/595
19
¿Dónde se está usando OO?n Sistemas basados en GUI
• La metodología OO facilita el diseño e implementación desistemas con interfaz gráfica de usuario (GUI)
8/20/2019 Analisis y Diseno Orientado a Objetos Co
20/595
20
¿Dónde se está usando OO?n Sistemas Inmersos
• Los métodos OO permiten desarrollar sistemas inmersos y detiempo real con mayor calidad y flexibilidad
8/20/2019 Analisis y Diseno Orientado a Objetos Co
21/595
21
Plataformas PC
Estación deTrabajo
BD con interfaz de objetos yaplicaciones existentes
¿Dónde se está usando OO?n Cómputo Cliente/Servidor
• La metodología OO pude encapsular información demainframe en objetos, permitiendo obtener aplicaciones
pequeñas
8/20/2019 Analisis y Diseno Orientado a Objetos Co
22/595
22
Software Existente Software con Re-ingeniería
¿Dónde se está usando OO?n En la Re-ingeniería
• Los métodos OO permiten hacer re-ingeniería a partes delsistema, protegiendo las inversiones hechas en aplicacionesde software existentes
8/20/2019 Analisis y Diseno Orientado a Objetos Co
23/595
23
Análisis y Diseño Orientado a
Objetos
OOD Agregar decisiones de
diseño y de detalle
Perspectiva del Desarrollador
OOADesarrollo del modelode requerimientos
Perspectiva del Usuario
8/20/2019 Analisis y Diseno Orientado a Objetos Co
24/595
24
¿Qué es UML?n El Lenguaje de Modelado Unificado (Unified Modeling
Language, UML) es descrito en “The Unified ModelingLanguage for Object-Oriented Development” escrito porGrady Booch, Jim Rumbaugh, e Ivar Jacobson
• Disponible en http:\\www.rational.com
n Basado en las experiencias personales de los autores
n Incorpora contribuciones de otras metodologías
n Sometido aprobación a la OMG por Rational Software,Microsoft, Hewlett-Packard, Oracle, Texas Instruments,MCI Systemhouse y otros
8/20/2019 Analisis y Diseno Orientado a Objetos Co
25/595
25
Entradas al UML
Fusion
Descripción de operaciones,Numeración de mensajes
UML
Meyer
Antes y después delas condicioones
Harel
Mapas de estado
Wirfs-Brock
Responsabilidades
Embley
Clases únicas,Vista de alto-nivel
Odell
Clasificación
Shlaer - Mellor
Ciclos de vida de objetos
Gamma, et.al
Estructura del trabajo, patrones,notas
Booch
JacobsonRumbaugh
8/20/2019 Analisis y Diseno Orientado a Objetos Co
26/595
26
Evolución del UMLIndustrialización
Estandardización
Unificación
FragmentaciónBooch´91
Booch´93
Unified Method 0.8
UML 1.0
OMT-2
OMT-1 OOSE
UML 0.9 & 0.91
OOPSLA ´95
Junio´96 & Oct´96
Sometido a OMG, Julio´97
Otros métodos
Retro-alimen-tación
Publicación delEstándar 1.0 Dic´96
Experto en UML
UML 1.1
8/20/2019 Analisis y Diseno Orientado a Objetos Co
27/595
27
Beneficios de UMLn Ofrece un proceso de modelado sin fallas durante el
análisis, para diseñar la implementación
n Define una notación expresiva y consistente
• Facilita la comunicación con otros• Ayuda a señalar omisiones e inconsistencias• Soporta tanto análisis como diseño de pequeños y grandes
sistemas
8/20/2019 Analisis y Diseno Orientado a Objetos Co
28/595
8/20/2019 Analisis y Diseno Orientado a Objetos Co
29/595
29
Desarrollo Iterativo e Incremental
8/20/2019 Analisis y Diseno Orientado a Objetos Co
30/595
30
Objetivos: Desarrollo Iterativo e
Incremental
n Usted podrá:
• Definir un proceso de desarrollo iterativo e incremental• Listar las fases, los productos y las actividades principales
para cada fase de un proceso de desarrollo iterativo e
incremental
• Definir una iteración y listar sus actividades
8/20/2019 Analisis y Diseno Orientado a Objetos Co
31/595
31
¿Qué es Desarrollo Iterativo e
Incremental?n Desarrollo iterativo e incremental es el proceso de
construir sistemas de software en pasos pequeños
n Beneficios• Reducción del riesgo basándose en la retroalimentacióntemprana
• Mayor flexibilidad para acomodar requerimientos nuevos ocambios en los mismos
• Incremento de la calidad del software
8/20/2019 Analisis y Diseno Orientado a Objetos Co
32/595
32
Inicio Elaboración Construcción Transición
tiempo
Ciclo de vida del Softwaren El ciclo de vida del software se divide en una serie de
ciclos de desarrollo, donde la salida de un ciclo dedesarrollo es la generación de un producto de software
n Cada ciclo es una sucesión de fases• Inicio• Elaboración• Construcción• Transición
8/20/2019 Analisis y Diseno Orientado a Objetos Co
33/595
33
Fase de Inicion Propósito:
• Establecer casos de uso de un sistema nuevo o para laactualización importante de un sistema existente
n Productos requeridos:• Requerimientos esenciales para el proyecto• Valoración del riesgo inicial
n Productos opcionales:• Un prototipo conceptual
• Un modelo inicial del dominio (avance de un 10% - 20%)
8/20/2019 Analisis y Diseno Orientado a Objetos Co
34/595
34
Fase de Elaboraciónn Propósito
• Analizar el dominio del problema
• Establecer una base arquitectónica sólida
• Manejar los elementos de mayor riesgo del proyecto
• Desarrollar un plan comprensivo que muestre como secompletará el proyecto
8/20/2019 Analisis y Diseno Orientado a Objetos Co
35/595
35
Fase de Elaboración (cont.)n Productos
• Un modelo del comportamiento del sistema, que incluya elcontexto del sistema, escenarios y un modelo del dominio(avance de un 80%)
• Una arquitectura de ejecutables• Una visión del producto base de acuerdo al modelo de
dominio• Una valoración revisada del riesgo• Un plan de desarrollo
•Criterios de evaluación
• Publicar descripciones• Un manual de usuario preliminar (opcional)• Estrategia de prueba• Plan de pruebas
8/20/2019 Analisis y Diseno Orientado a Objetos Co
36/595
36
Fase de Construcciónn Propósito
• Desarrollar un producto de software completo, de formaincremental, que esté en transición a la comunidad deusuarios
n Productos• Una serie de ejecutables liberados• Prototipos de comportamiento• Resultados que aseguren calidad• Documentación del sistema y del usuario• Plan de desarrollo• Criterio de evaluación para al menos la siguiente iteración
8/20/2019 Analisis y Diseno Orientado a Objetos Co
37/595
37
Fase de Transiciónn Propósito
• Hacer la transición del producto de software a lacomunidad de usuario
n Productos
• Una serie de ejecutables liberados
• Resultados que aseguren calidad• Documentación del sistema y del usuario actualizados
• Análisis “postmortem” del desempeño del proyecto
8/20/2019 Analisis y Diseno Orientado a Objetos Co
38/595
38
Iteración de
Arquitectura
Iteración de
Transición
Iteración de
Transición
Iteración de
Desarrollo
Iteración de
Desarrollo
Iteración de
Desarrollo
Iteración de
Arquitectura
Iteración
Preliminar
¿Qué es una Iteración?n Una iteración es un loop o ciclo de desarrollo que
desemboca en la liberación de un subconjunto delproducto final
n Cada iteración pasa a través de todos los aspectos deldesarrollo del software• Análisis de requerimientos• Diseño• Implementación• Pruebas
• Documentación
n Cada liberación iterativa es una “pieza” totalmentedocumentada del sistema final
8/20/2019 Analisis y Diseno Orientado a Objetos Co
39/595
39
Reducción del Riesgo a través de
IteracionesRiesgos inicialesÁmbito inicialdel proyecto
Define iteración paradireccionar los riesgosmayores
Planear y desarrollar la iteración
Evaluar la iteración
Riesgos eliminados
Revisar riesgos minimizados o nuevos
Revisar plan del
proyecto
Iteración N
8/20/2019 Analisis y Diseno Orientado a Objetos Co
40/595
40
Planeación de Iteracionesn Identificar y asignar prioridades a los riesgos del proyecto
n Seleccionar un pequeño número de escenarios queejemplifiquen los riesgos de mayor prioridad
n Los escenarios seleccionados son utilizados por:• Los desarrolladores, para identificar lo que se va a
implementar en la iteración• Los evaluadores, para desarrollar planes y procedimientos
de prueba para la iteración
n Al final de la iteración• Determinar los riesgos que han sido reducidos o eliminados• Determinar la posibilidad de nuevos riesgos descubiertos• Actualización del plan de iteraciones siguientes
8/20/2019 Analisis y Diseno Orientado a Objetos Co
41/595
41
Reunión de todos los elementos
P ro j e ct M a n a g e m e n t
P ro c e s s C o n f ig u r a tio n
R e q u i r e m e n t s
A n a lys is
A rc h it ec tu reL e v e l
C la ss L e v e l
I mp lem en t a ti on
Test
D e s i g n
p re l i m i na ry
i te ra t ion(s)
i te ra t ion
# 1
i tera t ion
#2. . .
i te ra t ion
# n
i tera t ion
# n + 1
i teration
#n+2 . . .
i te ra t ion
#m
P h a s e s
P ro c e ss C o m p o n e n ts
I t e r a t i o n s
i te ra t ion
# m + 1 . . .
E la b o ra t io n C o n st r u c tio n T r a n s i t i o nI n c e p t i o n
S u p p o r t i n g A c t iv it ie s
8/20/2019 Analisis y Diseno Orientado a Objetos Co
42/595
42
8/20/2019 Analisis y Diseno Orientado a Objetos Co
43/595
43
Comportamiento del Sistema
8/20/2019 Analisis y Diseno Orientado a Objetos Co
44/595
8/20/2019 Analisis y Diseno Orientado a Objetos Co
45/595
45
¿Qué es el Comportamiento del
Sistema?n El comportamiento del sistema es como este actúa y
reacciona a su entorno
• La actividad aparentemente visible y comprobable de unsistema
n El comportamiento del sistema se captura en casos de uso
• Describen al sistema, su ambiente y las relaciones entre elsistema y su ambiente
8/20/2019 Analisis y Diseno Orientado a Objetos Co
46/595
46
Actor
Caso de Uso
Conceptos Importantes en el
Modelado de Casos de Uso
n Un actor representa cualquier cosaque interactúa con el sistema
n Un caso de uso es una secuenciade acciones que un sistema
desempeña y que produce unresultado observable por un actor
8/20/2019 Analisis y Diseno Orientado a Objetos Co
47/595
47
El objetivo principal del modelo de casos de uso escomunicar la funcionalidad y el comportamiento del
sistema hacia el cliente o usuario final
El objetivo principal del modelo de casos de uso escomunicar la funcionalidad y el comportamiento del
sistema hacia el cliente o usuario final
¿Qué es un Modelo de Casos de Uso?n Un modelo de casos de uso es una representación de las
funciones intencionales del sistema (casos de uso) y sus
alrededores (actores)
n El mismo modelo de casos de uso se emplea en el análisis
de requerimientos, diseño y pruebas
8/20/2019 Analisis y Diseno Orientado a Objetos Co
48/595
48
Beneficios de un Modelo de Casos
de Uson El modelo de casos de uso
n Se utiliza para comunicarse con los usuarios finales yexpertos del dominio
• Proporciona una etapa previa al desarrollo de sistemas
• Asegura el entendimiento mutuo de los requerimientos
n Se utiliza para identificar• ¿Quién interactuará con el sistema y qué debe hacer el
sistema?• ¿Qué interfaz debe tener el sistema?
n Se utiliza para verificar• Que se capturen todos los requerimientos• Que los desarrolladores hayan entendido los
requerimientos
8/20/2019 Analisis y Diseno Orientado a Objetos Co
49/595
49
Actoresn Los actores no son parte del sistema,
representan roles que un usuario delsistema puede ejecutar
n Un actor puede intercambiar informaciónactivamente con el sistema
n Un actor puede ser un recipiente pasivode información
n Un actor puede representar a unapersona, a una máquina o a otro sistema
Actor
8/20/2019 Analisis y Diseno Orientado a Objetos Co
50/595
50
Identificación de Actores:
Preguntas Útilesn ¿Quién está interesado en cierto requerimiento?
n ¿En qué parte de la organización se usará el sistema?
n ¿Quién proveerá al sistema con información, la usará
y/o borrará?n ¿Quién usará esta función?
n ¿Quién le dará soporte y mantenimiento al sistema?
n ¿El sistema usa una fuente externa?
n ¿Qué actores necesitan los casos de uso?n ¿Puede un actor desempeñar roles diferentes?
n ¿Varios actores desempeñan el mismo rol?
8/20/2019 Analisis y Diseno Orientado a Objetos Co
51/595
51
Instancias de Actores
1 2 34 5 67 8 9* 0 #
Insert card
Ivan actúacomo unactor
Tom actúacomo unactor
Modelo de Casos de Uso
Actor caso de uso
8/20/2019 Analisis y Diseno Orientado a Objetos Co
52/595
52
Un usuario puede actuar como
varios actores
1 2 34 5 6
7 8 9* 0 #
Insert cardCharlie como
operador
Cliente
Operador Charlie como
cliente
Charlie
8/20/2019 Analisis y Diseno Orientado a Objetos Co
53/595
53
Límites de los actores y el sistema
MantenimientoATM
Cajero
¿Límite del sistema?
Sistema ATM
S is tema del Banco
8/20/2019 Analisis y Diseno Orientado a Objetos Co
54/595
54
Casos de Uson Un caso de uso modela un diálogo entre
actores y el sistema
n Un actor inicia un caso de uso para
invocar cierta funcionalidad del sistema
n Un caso de uso es un flujo de eventoscompleto y significativo
n El conjunto de todos los casos de uso,representa todas las formas posibles deuso del sistema
Caso de Uso
8/20/2019 Analisis y Diseno Orientado a Objetos Co
55/595
55
Identificación de Casos de Uso:
Preguntas Útilesn ¿Cuáles son las tareas que realiza este actor?n ¿El actor creará, almacenará, cambiará, borrará o leerá
información en el sistema?n ¿Qué caso de uso creará, almacenará, cambiará, borrará
o leerá esta información?n ¿Necesitará el actor informar al sistema sobre cambios
externos repentinos?n ¿Necesitará el actor recibir información en relación a
ciertas ocurrencias en el sistema?n ¿El sistema proporciona al negocio el comportamiento
correcto?n ¿Qué casos de uso van a darle soporte y mantenimiento
al sistema?n ¿Pueden todos los requerimientos funcionales ser
ejecutados por los casos de uso?
8/20/2019 Analisis y Diseno Orientado a Objetos Co
56/595
8/20/2019 Analisis y Diseno Orientado a Objetos Co
57/595
57
Cliente
Transacciones del Banco
Operador
de ATM
Mantener Máquina ATM
Ejecución de Reportes
Banco
Diagrama Casos de Uson Se dibuja un d i a g r am a d e c a so s d e u s o para ilustrar los
casos de uso y los actores que interactúan enviándoseestímulos el uno al otro
8/20/2019 Analisis y Diseno Orientado a Objetos Co
58/595
58
Documentación de un Caso de Uson Los casos de usos se documentan con:
n Una breve descripción• Se expone el propósito del caso de uso en unas cuantas
líneas
n Flujo de eventos detallado• Descripción del flujo primario y los flujos alternos de
eventos que ocurren desde el inicio el casos de uso
n La documentación debe leerse como un diálogo entre elactor y el caso de uso
n Ambas partes de la documentación deben estar escritosen términos que el cliente entienda
8/20/2019 Analisis y Diseno Orientado a Objetos Co
59/595
59
Flujo de Eventos en un Caso de Uson Cada caso de uso
• Tiene una secuencia de transacciones normal o básica
• Debe tener varias secuencias alternativas de transacciones
• Generalmente tiene secuencias de excepción a
transacciones que manejan situaciones erróneas
• También debe tener pre y post condiciones bien definidas
8/20/2019 Analisis y Diseno Orientado a Objetos Co
60/595
60
Flujo de Eventos en un Caso de Uso
(cont.)n Describe sólo los eventos que pertenecen al caso de
uso, y no lo que ocurren en otros casos de uso
n Evitar el uso de terminología vaga como: “por ejemplo”, “etc.” e “información”
n El flujo de eventos deberá describir:• ¿Cómo y cuándo inicia y termina el caso de uso?• ¿Cuándo interactúa el caso de uso con los actores?
• ¿Qué información se intercambia entre un actor y el casode uso?
• No describe los detalles de la interfaz de usuario• Describe el flujo básico de eventos• Cualquier flujo de eventos alterno
8/20/2019 Analisis y Diseno Orientado a Objetos Co
61/595
8/20/2019 Analisis y Diseno Orientado a Objetos Co
62/595
62
Ejemplo: Inscripción a Cursosn Al inicio de cada semestre, los alumnos solicitan un catálogo que
contiene la lista de los cursos que se impartirán en el semestre,en el cual se incluyen también datos relacionados como:profesor, departamento y pre-requisitos.
n El sistema nuevo deberá permitir que los alumnos seleccionencuatro cursos para el semestre que inicia. Además, cada alumnoindicará dos cursos alternativos en caso de que no pueda serasignada la primera selección. Los nuevos cursos tendrán unmáximo de diez alumnos y un mínimo de tres. Un curso conmenos de tres alumnos será cancelado. Una vez que el procesode inscripción se ha completado para un alumno, el sistema deregistro envía la información al sistema de cobros, para que elalumno pueda pagar por el semestre.
8/20/2019 Analisis y Diseno Orientado a Objetos Co
63/595
63
Ejemplo: Inscripción a Cursos
(cont.)n Los profesores deben ser capaces de ingresar al sistema para
indicar que cursos van a impartir. También podrán ver quéalumnos están inscritos en sus cursos.
n Para cada semestre, hay un periodo en el que los alumnospueden cambiar su horario. Los alumnos deben ser capaces deingresar al sistema durante este tiempo para agregar o cancelarcursos.
8/20/2019 Analisis y Diseno Orientado a Objetos Co
64/595
64
Diagrama de casos de uso
Alumno
Sistemade Cobro
Inscripción a CursosPetición de Catálogo deCurso
Selección de Cursos aImpartir
Profesor
Mantener Información deAlumno
MantenerInformación deProfesor Mantener Información
de Cursos
Generar Catálogo
Administrador
8/20/2019 Analisis y Diseno Orientado a Objetos Co
65/595
65
1. Breve Descripción: Caso de Uso
Inscripción a Cursos1.1 Breve Descripción
n Este caso de uso es iniciado por un alumno. Proporciona lacapacidad para que un alumno cree, borre, modifique y/orevise un horario de curso para un semestre dado.
8/20/2019 Analisis y Diseno Orientado a Objetos Co
66/595
66
2. Flujo de Eventos: Casos de Uso
Inscripción a Cursos2.1 Pre-condiciones
Ninguna
2.2 Flujo PrincipalEste casos de uso inicia cuando un alumno introduce el
numero de id de alumno. El sistema verifica que el número deid de alumno sea valido (E-1) y permite que el alumnoseleccione el semestre actual o uno futuro (E-2). El sistemapermite que el alumno seleccione la actividad deseada:Crear, Revisar, Modificar, Imprimir, Borrar o Salir.
Si la actividad seleccionada es:
A-1 Crear: Subflujo Crear un Horario Nuevo.A-2 Revisar: Subflujo Revisar un Horario.A-3 Modificar: Subflujo Modificar un Horario.A-4 Imprimir: Subflujo Imprimir un Horario.A-5 Borrar: Subflujo Borrar un Horario.Salir: termina el caso de uso.
8/20/2019 Analisis y Diseno Orientado a Objetos Co
67/595
67
2. Flujo de Eventos: Casos de Uso
Inscripción a Cursos (cont.)2.3 Flujos Alternos
A-1 Crear: Subflujo Crear un Horario Nuevo:El sistema despliega una pantalla de horario en blanco. Losalumnos introducen los 4 cursos primarios y 2 cursos alternativos(E-3). El alumno envía su requerimiento de cursos. Por cada curso
primario seleccionado el sistema revisa que se satisfagan los pre-requisitos (E-4) y agrega al alumno al curso si éste está abierto(E-5). El sistema imprime el horario del alumno (E-6) y envía estainformación al sistema de cobros para procesarla (E-7). El Caso deUso inicia de nuevo.
A-2 Revisar: Subflujo Revisar un Horario:
El sistema recupera (E-8) y despliega la información para todoslos cursos a los cuales el alumno se registro: nombre del curso,número del curso, número de lugares del curso, días de lasemana, hora, lugar y número de horas necesarias. Cuando elalumno indica que el o ella ha terminado su revisión, el Caso deUso inicia de nuevo.
8/20/2019 Analisis y Diseno Orientado a Objetos Co
68/595
8/20/2019 Analisis y Diseno Orientado a Objetos Co
69/595
69
2. Flujo de Eventos: Casos de Uso
Inscripción a Cursos (cont.)A-4 Imprimir: Subflujo Imprimir un Horario:El sistema imprime el horario del alumno (E-6). El Caso de Usoinicia de nuevo.
A-5 Borrar: Subflujo Borrar un Horario:
El sistema recupera (E-8) y despliega la información actual delhorario. El sistema pide al usuario que confirme la eliminación delhorario. Si se confirma, se borra el horario del sistema. Si laeliminación no se confirma, la operación se cancela y el Caso deUso inicia de nuevo.
A-6 Borrar Curso: Subflujo Borrar un Curso:
El alumno introduce el número del curso para borrarlo. El sistemapide al usuario que confirme la eliminación del curso. Si seconfirma, se borra el curso del horario del alumno. Si laeliminación no se confirma, la operación se cancela y el caso deuso inicia de nuevo.
8/20/2019 Analisis y Diseno Orientado a Objetos Co
70/595
70
2. Flujo de Eventos: Casos de Uso
Inscripción a Cursos (cont.)A-7 Agregar Curso: Subflujo Agregar un Curso:El alumno introduce el número de curso para agregarlo. Elsistema revisa que se satisfagan los pre-requisitos (E-4) yagrega el alumno al grupo si el curso esta abierto (E-5). Elcaso de uso inicia de nuevo.
Flujos de ExcepciónE-1: Se introdujo un número id de alumno inválido. El usuariopuede re-introducir el número id o finalizar el caso de uso.E-2: Se introdujo un semestre inválido. El usuario puede re-introducir el semestre o finalizar el casos de uso.E-3: El número de curso no es válido. El usuario puede re-
introducir el número válido o finalizar el caso de uso.E-4: Los pre-requisitos no fueron satisfechos por el usuario.Se le informa al alumno que un curso no puede ponerse en elhorario y el motivo. De ser posible, se sustituye con un cursoalterno. El caso de uso continua.
8/20/2019 Analisis y Diseno Orientado a Objetos Co
71/595
71
2. Flujo de Eventos: Casos de Uso
Inscripción a Cursos (cont.)E-5: E curso seleccionado esta cerrado. De ser posible, sesubstituye con un curso alterno. El caso de uso continua.
E-6: No es posible imprimir el horario. La información seguarda y se le informa al usuario que la petición de impresión
del horario debe ser reintroducida. El caso de uso continua.E-7: No es posible enviar la información al sistema de cobro.El sistema guarda toda la información de cobro y la re-envíadespués al sistema de cobros. El caso de uso continua.
E-8: El sistema no puede recuperar la información del horario.El caso de uso inicia nuevamente.
E-9: El sistema informa al usuario que no se puede modificarun horario. El caso de uso inicia nuevamente.
8/20/2019 Analisis y Diseno Orientado a Objetos Co
72/595
72
¿Qué son los escenarios?n Un escenario es una instancia de un casos de uso
n Es un flujo determinado de eventos en un caso de uso
n
Cada caso de uso tiene múltiples escenariosn Escenarios primarios (happy path scenarios)
• Flujo normal: la forma en la que debe trabajar elsistema
n Escenarios secundarios
• Excepciones del escenario primarios
8/20/2019 Analisis y Diseno Orientado a Objetos Co
73/595
73
Escenario para el Caso de Uso
Inscripción a Cursosn John introduce el número id de alumno 369 52 3449 y el
sistema lo valida. El sistema pregunta que a semestre deseainscribirse. John le indica al sistema el semestre actual y eligecrear un horario nuevo.
n De una lista de cursos disponibles, John selecciona lossiguientes 4 cursos primarios: English 101, Geology 110, WorldHistory 200, y College Algebra 110. Después selecciona 2cursos alternos: Music Theory 110 y Introduction to JavaProgramming 180.
n El sistema determina que John tiene todos los pre-requisitosnecesarios y lo agrega a las listas de los cursos
correspondientes.
n El sistema indica que la actividad esta completa. El sistemaimprime el horario del alumno y envía la información de cobrode cuatro cursos primarios al sistema de cobros para que seaprocesado.
8/20/2019 Analisis y Diseno Orientado a Objetos Co
74/595
74
Escenarios Secundariosn ¿Qué escenarios secundarios podrían considerarse
para el caso de uso: “Inscripción a Cursos”?
8/20/2019 Analisis y Diseno Orientado a Objetos Co
75/595
75
Escenarios Secundarios (cont.)n Algunos escenarios secundarios a considerarse:
• El alumno no seleccionó los 4 cursos primarios
• Algún curso primario no esta disponible
• Los cursos primarios y secundarios no están
disponibles
• No se puede agregar el alumno a la lista de un curso
• No se puede crear el horario del alumno
8/20/2019 Analisis y Diseno Orientado a Objetos Co
76/595
76
¿Cuántos escenarios se necesitan?n Respuesta sencilla: tantos como se necesiten para
entender el desarrollo del sistema
n Sugerencia:n Escenarios Primarios• Dedicar aproximadamente el 80% del tiempo a estos
escenarios
n Escenarios Secundarios• Elaborar algunos de los escenarios secundarios
interesantes y de alto riesgo
8/20/2019 Analisis y Diseno Orientado a Objetos Co
77/595
77
Ejercicio: Comportamiento del
Sisteman Utilice el problema que proporciona el instructor
n Dibujar un diagrama de casos de uso
n Escribir una definición para cada actor
n Para un caso de uso
• Escribir una breve descripción (dos sentencias máximo)
• Escribir el flujo de eventos
• Listar algunos escenarios posibles
8/20/2019 Analisis y Diseno Orientado a Objetos Co
78/595
78
8/20/2019 Analisis y Diseno Orientado a Objetos Co
79/595
8/20/2019 Analisis y Diseno Orientado a Objetos Co
80/595
80
Objetivos: Objetos y Clasesn Usted podrá:
• Definir y dar ejemplos de objetos
• Definir y dar ejemplos de clases• Describir las relaciones entre clases y objetos
• Definir estereotipos
8/20/2019 Analisis y Diseno Orientado a Objetos Co
81/595
81
Trailer
Proceso Químico
Lista Ligada
¿Qué es un objeto?n Informalmente, un objeto representa una
entidad, ya sea física, conceptual o software
• Entidad física
• Entidad conceptual
• Entidad de software
8/20/2019 Analisis y Diseno Orientado a Objetos Co
82/595
8/20/2019 Analisis y Diseno Orientado a Objetos Co
83/595
83
Nombre: Joyce Clark
Empleado ID: 567138Fecha de contrato: March 21, 1987Estado: Tenured
Profesora Clark
a + b = 10
Un Objeto tiene Estadon El estado de un objeto es una de las condiciones posibles en
las que un objeto puede existir
n El estado de un objeto normalmente cambia con el paso deltiempo
n El estado de un objeto generalmente se implementa por unaserie de propiedades (llamadas atributos), con los valores delas propiedades, más las relaciones que el objeto pueda tenercon otros objetos
8/20/2019 Analisis y Diseno Orientado a Objetos Co
84/595
84
Curso de Algebra 101
Asignar al Profesor Clark
(Regresa:confirmación)
Sistema de Inscripción
a + b = 10
Un Objeto tiene Comportamienton El comportamiento determina como actúa y responde un objeto
n El comportamiento define como responde un objeto a peticionesde otros objetos
n El comportamiento visible de un objeto se modela por un
conjunto de mensajes a los que puede responder (lasoperaciones que el objeto puede desempeñar)
8/20/2019 Analisis y Diseno Orientado a Objetos Co
85/595
85
Profesor “J Clark”imparte Algebra
Profesor “J Clark”imparte Algebra
Profesor “J Clark”imparte Algebra
Un Objeto tiene Identidadn Cada objeto tiene identidad única, aún si el estado es
idéntico al de otro objeto
8/20/2019 Analisis y Diseno Orientado a Objetos Co
86/595
86
¿Qué son las clases?n Hay varios objetos identificados en cualquier dominio
n Una clase es una descripción de un grupo de objetos conpropiedades comunes (atributos), comportamiento
común (operaciones), relaciones comunes con otrosobjetos (asociaciones y agregaciones) y semánticascomunes.n Un objeto es una instancia de una clase
n Una clase es una abstracción en la que ella:n
Enfatiza características relevantesn Suprime otras características
n La abstracción nos ayuda a manejar la complejidad
8/20/2019 Analisis y Diseno Orientado a Objetos Co
87/595
87
Ejemplo de Clase
a + b = 10
ClaseCurso
Estructura
NombreUbicación
Días ofrecidos
Horas de créditos
Hora inicioHora término
Comportamiento
Agregar un alumnoBorrar un alumno
Obtener catálogo de cursos
Determinar si está lleno
8/20/2019 Analisis y Diseno Orientado a Objetos Co
88/595
88
Clases de Objetosn ¿Cuántas clases ve?
8/20/2019 Analisis y Diseno Orientado a Objetos Co
89/595
89
Objetos
Clase
Profesor
Profesor Smith
Profesor Jones
Profesor Mellon
Relaciones entre Clases y Objetosn Una clase es una definición abstracta de un objeto
• Define la estructura y comportamiento de cada objeto en laclase
• Sirve como una plantilla para crear objetos
n Los objetos pueden agruparse en clases
8/20/2019 Analisis y Diseno Orientado a Objetos Co
90/595
90
Algebra 101Art HistoryChemistry
Spanish 101
Guía para identificar Clasesn Una clase debe capturar una y solo una llave de abstracción
n Mala abstracción: la clase Alumno sabe la información del
alumno y su horario para el semestre actual
n
Buena abstracción: Separar las clases en una para alumno y otrapara Horario del alumno
8/20/2019 Analisis y Diseno Orientado a Objetos Co
91/595
91
¿Cómo nombrar a una Clase?n El nombre de una clase debe ser un nombre en singular
que caracterice de la mejor forma a la abstracción
n La dificultad al nombrar a una clase puede indicar que
una abstracción está pobremente definida
n Los nombres deben venir directamente del vocabulario
del dominio
8/20/2019 Analisis y Diseno Orientado a Objetos Co
92/595
8/20/2019 Analisis y Diseno Orientado a Objetos Co
93/595
8/20/2019 Analisis y Diseno Orientado a Objetos Co
94/595
94
Al ir estudiando más el problema, se descubren clases y se
mejoran las definiciones de las anteriores, agregándolas aldiccionario del modelo
Al ir estudiando más el problema, se descubren clases y se
mejoran las definiciones de las anteriores, agregándolas aldiccionario del modelo
Ejemplo de Entradas al Diccionario
del Modelon Nombre: StudentInformation
• Definición: Información relacionada a una persona registradapara asistir a clases en la Universidad
n Nombre: Course• Definición de Trabajo: Una clase ofrecida por la Universidad
8/20/2019 Analisis y Diseno Orientado a Objetos Co
95/595
95
Professor
Profesor Clark
a + b = 10
Representación de Clasesn Una clase se representa usando un rectángulo con tres
divisiones
8/20/2019 Analisis y Diseno Orientado a Objetos Co
96/595
96
Professor nameempID
create( )save( )delete( )change( )
Professor
nameempID
Professor
create( )
save( )
delete( )
change( )
Professor
Professor
Divisiones de Clasen Una clase comprende tres secciones
n La primera sección contiene el nombre de la clase
n La segunda sección muestra la estructura (atributos)
n La tercera sección muestra el comportamiento (operaciones)
n La segunda y tercera sección pueden suprimirse si no esnecesario que sean visibles en el diagrama
8/20/2019 Analisis y Diseno Orientado a Objetos Co
97/595
97
Estereotiposn Un estereotipo es un nuevo tipo de elemento de modelado que
extiende la semántica del metamodelo• Deben estar basados en tipos o clases existentes en el
metamodelo
n Cada clase puede tener como máximo un estereotipon Estereotipos comunes
• Clase Boundary• Clase Entity• Clase Control• Clase Exception• Metaclase• Clase Utility
n Los Estereotipos se muestran en la parte donde se escribe elnombre de la clase entre >
8/20/2019 Analisis y Diseno Orientado a Objetos Co
98/595
98
ScheduleForm
Clases Boundaryn Una clase boundary modela la comunicación entre los
alrededores del sistema y sus funciones internas
n Clases boundary típicas• Windows (interfaz de usuario)
• Protocolo de Comunicación (interfaz del sistema)• Interfaz de impresora• Sensores
n En el escenario de “Inscripción a Cursos”, se crea unapantalla de horario (ScheduleForm) para aceptar informacióndel usuario
8/20/2019 Analisis y Diseno Orientado a Objetos Co
99/595
99
BillingSystem
Interfaz con otros sistemasn Una clase boundary se usa también para modelar una interfaz
con otro sisteman Las características importantes de este tipo de clases son:
• La información que va a pasarse al otro sistema• El protocolo de comunicación que se use para “hablar” con
el otro sistema
n En el escenario “Inscripción a Cursos”, la información debeenviarse al sistema de cobros (BillingSystem)• Se crea una clase llamada BillingSystem para mantener la
interfaz del sistema externo
8/20/2019 Analisis y Diseno Orientado a Objetos Co
100/595
100
Schedule
CourseRoster
Catalogue
Course
Clases Entityn Una clase entity modela información y comportamiento
asociado que es generalmente de larga vida (persistente)• Puede reflejar un fenómeno de la vida real• También puede necesitarse para las tareas internas del
sistema
• Los valores de sus atributos son proporcionadosgeneralmente por un actor• Su comportamiento es independiente de los alrededores
n Clases entity en el caso de uso “Inscripción a Cursos” • Course• Schedule
• Catalogue• CourseRoster
8/20/2019 Analisis y Diseno Orientado a Objetos Co
101/595
101
RegistrationManager
Clases Controln Una clase control modela el comportamiento de control
específico a uno o más casos de uson Una clase control
• Crea, inicia y borra objetos controlados• Controla la secuencia o coordinación de ejecución de
objetos controlados• Controla elementos actuales para clases controladas• Es, la mayor parte de las veces, la implementación de un
objeto intangible
n En el escenario “Inscripción a Cursos”, la claseRegistrationManager controla el proceso de inscripción
8/20/2019 Analisis y Diseno Orientado a Objetos Co
102/595
102
8/20/2019 Analisis y Diseno Orientado a Objetos Co
103/595
103
Interacción de Objeto
8/20/2019 Analisis y Diseno Orientado a Objetos Co
104/595
104
Objetivos: Interacción de Objeton Usted podrá:
• Usar diagramas de secuencia y colaboración paramostrar las interacciones de los objetos
8/20/2019 Analisis y Diseno Orientado a Objetos Co
105/595
105
¿Qué es un Diagrama de
Interacción?n Un diagrama de interacción es una representación
gráfica de las interacciones entre objetos
n Hay dos tipos de diagramas de interacción• Diagramas de Secuencias
• Un diagrama de secuencias están ordenado de acuerdoal tiempo
• Diagramas de Colaboración• Un diagrama de colaboración incluyen el flujo de datos
• Cada uno provee un punto de vista diferente de la mismainteracción
8/20/2019 Analisis y Diseno Orientado a Objetos Co
106/595
106
¿Qué es un Diagrama de
Secuencias?n Un diagrama de secuencia muestra interacciones de
objetos ordenados en el tiempo
n El diagrama muestra• Los objetos que participan en la interacción• La secuencia de mensajes intercambiados
n Un diagrama de secuencias contiene:
• Objetos con sus “líneas de vida” • Mensajes intercambiados entre objetos en ordensecuencial
• Enfoque de control (Focus of Control) (opcional)
8/20/2019 Analisis y Diseno Orientado a Objetos Co
107/595
8/20/2019 Analisis y Diseno Orientado a Objetos Co
108/595
108
cursos
disponibles
Cursos : Catálogo
disponibles
: Catálogo
Objetos ClasesObjetos y Clases
¿Cómo nombrar a los Objetos en
un Diagrama de Secuencias?n Los objetos se dibujan como rectángulos con los nombres
subrayados
n Las “líneas de vida” se representan con líneas de guiones
descendentes
8/20/2019 Analisis y Diseno Orientado a Objetos Co
109/595
109
forma dehorarios
Obtener cursos
cursosdisponibles
Mostrar las interacciones entre
objetosn La interacción de objetos se indica con flechas horizontales
que se dirigen desde la línea vertical que representa al objeto
cliente hasta la línea que representa al objeto proveedor
n Las flechas horizontales se etiquetan con un mensaje
n El orden en que ocurren los mensajes es indicado por laposición vertical, con el más cercano en la parte superior
n La numeración es opcional, ya que la orden se basa en laposición vertical
8/20/2019 Analisis y Diseno Orientado a Objetos Co
110/595
110
¿Qué es el Enfoque de Control?n El Enfoque de Control representa el tiempo relativo en el
que el flujo de control se enfoca sobre un objeto• Representa el tiempo en que un objeto dirige sus mensajes
n El Enfoque de Control puede mostrarse en un diagramade secuencia
8/20/2019 Analisis y Diseno Orientado a Objetos Co
111/595
8/20/2019 Analisis y Diseno Orientado a Objetos Co
112/595
112
forma dehorario
obtener cursos
cursosdisponibles
cursos disponibles para
el semestre elegido
Notasn Las notas pueden agregarse para agregar más
información al diagrama
8/20/2019 Analisis y Diseno Orientado a Objetos Co
113/595
113
Scripts en Diagramas de
Secuenciasn Para escenarios complejos, los diagramas de secuencias
pueden ser mejorados mediante el uso de scripts
n
Un script se escribe a la izquierda de un diagrama desecuencia con la secuencia de pasos alineados a lasinteracciones del objeto
n Los scripts se pueden escribir en lenguaje natural o en
pseudo código
8/20/2019 Analisis y Diseno Orientado a Objetos Co
114/595
114
Ejemplo de Script
Procesa los cursos primariosy solo recurre a los cursosalternos si es necesario
forma dehorario
obtener prerequisito
un curso
8/20/2019 Analisis y Diseno Orientado a Objetos Co
115/595
8/20/2019 Analisis y Diseno Orientado a Objetos Co
116/595
116
Ejemplo de un Diagrama de
Colaboración
John : Alumno
registration form
forma horarioclases disponibles
1: introducir id
2: validar id
3: introducir semestre actual
4: crear nuevo horario5: desplegar
6: obtener cursos
8/20/2019 Analisis y Diseno Orientado a Objetos Co
117/595
117
Ingles
101
Ingles 101:
Curso
:Curso
Objetos ClasesObjetos y Clases
Representación de Objetos en un
Diagrama de Colaboraciónn Los objetos se dibujan como rectángulos con nombressubrayados
ó
8/20/2019 Analisis y Diseno Orientado a Objetos Co
118/595
118
formaHorario : Forma un curso : Curso
Representación de Ligas en un
Diagrama de Colaboraciónn Una liga de interacción en un diagrama de colaboración se
representa como una línea que conecta iconos de objetos
n
Una liga indica que hay una ruta de comunicación entreobjetos conectados
8/20/2019 Analisis y Diseno Orientado a Objetos Co
119/595
119
Anotaciones de Ligan Una liga de interacción en un diagrama de
colaboración se puede anotar con:• Una flecha apuntando del objeto cliente al objeto
proveedor
• El nombre del mensaje con una lista opcional deparámetros y/o valores de retorno
• Un número opcional que muestre el orden relativo enel cual se envían los mensajes
8/20/2019 Analisis y Diseno Orientado a Objetos Co
120/595
120
Notación de Liga
formaHorario : Forma un curso : Curso
Supplier object
Message
points from client tosupplier
Client object
Data return
1: obtener prerequisitos
2: obtener cursos
lista curso
Objeto
Mensaje
Mensaje
Objeto
Liga
8/20/2019 Analisis y Diseno Orientado a Objetos Co
121/595
121
8/20/2019 Analisis y Diseno Orientado a Objetos Co
122/595
8/20/2019 Analisis y Diseno Orientado a Objetos Co
123/595
123
Objetivos: Identificación de Clasesn Usted podrá:
• Discutir el análisis de casos de usos• Identificar objetos y clases llevando a cabo el análisis
casos de usos• Usar tarjetas CRC para descubrir clases• Diagramar un escenario usando diagramas de
interacción
• Crear paquetes• Crear diagramas de clase iniciales
8/20/2019 Analisis y Diseno Orientado a Objetos Co
124/595
124
¿Qué es un Análisis Casos de Uso?n El análisis casos de uso es el proceso de estudiar los
casos de usos para descubrir objetos y clases para eldesarrollo del sistema• Los escenarios se detallan y se representan gráficamente
en diagramas de interacciones• Se crean clases entity, boundary y control
• Las clases se agrupan en paquetes
• Se crean diagramas de clases
8/20/2019 Analisis y Diseno Orientado a Objetos Co
125/595
125
Identificación de Objetos Entity
n Los objetos entity se identifican al examinar los
sustantivos en los escenarios
n Los sustantivos encontrados pueden ser:
• Objetos
• Descripción del estado de un objeto
• Entidades externas y/o Actores• Otros
8/20/2019 Analisis y Diseno Orientado a Objetos Co
126/595
126
Filtrado de Sustantivosn Cuando se identifican sustantivos, debe estar consciente
de que:
• Varios términos se pueden referir al mismo objeto• Un término se puede referir a más de un objeto• El lenguaje natural es muy ambiguo
n Este acercamiento puede identificar muchos objetos sinimportancia
• La lista de sustantivos debe filtrarse
8/20/2019 Analisis y Diseno Orientado a Objetos Co
127/595
127
Línea principal: Cada sustantivo debe considerarse en el contexto
del dominio del problema -- no puede considerarse por sí mismo
Línea principal: Cada sustantivo debe considerarse en el contexto
del dominio del problema -- no puede considerarse por sí mismo
Observar los Sustantivosn El siguiente expresión fue escrita para un sistema de
bancario• “Los requerimientos legales se tomarán en cuenta”
n Si SOLO se consideraran los sustantivos, ¿qué pasaría?
8/20/2019 Analisis y Diseno Orientado a Objetos Co
128/595
128
Escenario: “Crear horario”n John introduce el número id de alumno 369 52 3449 y el
sistema valida el número. El sistema pregunta qué semestre.John indica el semestre actual y elige crear un horario.
n De una lista de cursos disponibles, John selecciona los cuatro
cursos primarios English 101, Geology 110, World History 200,y College Algebra 110. Después selecciona los cursos alternosMusic Theory 110 y Introduction to Java Programming 180.
n El sistema determina que John tiene todos los pre-requisitosnecesarios al examinar el registro del alumno y lo agrega a lalista de los cursos.
n El sistema indica que la actividad se ha completado. Elsistema imprime el horario del alumno y envía información decobro para cuatro cursos al sistema de cobro para procesarlo.
S stanti os del Escena io “C ea
8/20/2019 Analisis y Diseno Orientado a Objetos Co
129/595
129
¿Qué sustantivos deben filtrarse?¿Qué sustantivos deben filtrarse?
Sustantivos del Escenario “CrearHorario”
n Johnn Sisteman Semestren Horarion Geology 110n College Algebra 110n Cursos alternosn Music Theory 110n Prerequisitos necesariosn Horario de estudianten Información de cobron Cuatro cursosn Sistema de cobro
n Número de ID 369523449n Númeron Semestre actualn Lista de cursos disponiblesn Cursos primariosn English 101n Introduction to Java
Programming 180n World History 200n Registro de estudianten Lista del curso
n Actividad
8/20/2019 Analisis y Diseno Orientado a Objetos Co
130/595
130
Decisiones de Filtradon John -- filtrado (actor)
n Número de ID 369523449 -- filtrado (propiedad del alumno)
n Sistema -- filtrado (lo que se está construyendo)
n Número -- filtrado (lo mismo que el numero id del alumno)
n Semestre -- filtrado (estado -- cuando la selección aplica)n Semestre actual -- filtrado (igual que el semestre)
n Horario -- candidato a objeto
n Lista de cursos disponibles -- candidato a objeto
n Cursos primarios -- filtrado (estado de un curso seleccionado)
n
English 101 -- candidato a objeton Geology 110 -- candidato a objeto
n World History 200 -- candidato a objeto
n College Algebra 110 -- candidato a objeto
8/20/2019 Analisis y Diseno Orientado a Objetos Co
131/595
131
Decisiones de Filtradon Cursos alternos -- filtrado (estado de un curso seleccionado)
n Music Theory 110 -- candidato a objeto
n Introduction to Java Programming 180 -- candidato a objeto
n Prerequisitos necesarios -- filtrado (curso como otros cursos
identificados)n Registro de estudiante -- candidato a objeto
n Lista del curso -- candidato a objeto
n Actividad -- filtrado (Expresión en inglés)
n Horario de estudiante -- filtrado (igual que el nuevo horario)
n Información de cobro -- candidato a objeto
n Cuatro cursos -- filtrado (información necesitada por lainformación de cobro)
n Sistema de cobro -- filtrado (actor)
Candidatos a Objetos en el
8/20/2019 Analisis y Diseno Orientado a Objetos Co
132/595
132
Candidatos a Objetos en elEscenario
n Horario -- lista de cursos por semestre para un alumno
n Lista de cursos disponibles -- lista de todos los
cursos que se imparten en un semestre
n English 101 -- una oferta para un semestren Geology 110 -- una oferta para un semestre
n World History 200 -- una oferta para un semestre
n College Algebra 110 -- una oferta para un semestre
n Music Theory 110 -- una oferta para un semestren Introduction to Java Programming 180 -- una
oferta para un semestre
Candidatos a Objetos en el
8/20/2019 Analisis y Diseno Orientado a Objetos Co
133/595
133
Candidatos a Objetos en elEscenario
n Registro de estudiante -- una lista de cursos que el
alumno tomo en semestres previos
n Lista del curso -- lista de alumnos para una oferta de
curso específican Información de cobro -- información que necesita el
actor sistema de cobro
8/20/2019 Analisis y Diseno Orientado a Objetos Co
134/595
134
Creación de Clases
n Los objetos entity encontrados se agrupan en clases
• Basado en estructura y/o comportamiento similar
n Esto es sólo un intento inicial
• Las clases pueden cambiar al examinar más escenarios
8/20/2019 Analisis y Diseno Orientado a Objetos Co
135/595
8/20/2019 Analisis y Diseno Orientado a Objetos Co
136/595
136
Identificación de Clases Boundaryn Examinar cada par: actor/escenario y crear clases boundary
obvias• Durante el diseño, la clase se refinará en base a los
mecanismos de la interfaz de usuario elegida
n Ejemplo:• Al alumno se le presentan diferentes opciones en el caso de
uso “Inscripción a Cursos”• Se crea una clase boundary llamada RegistrationForm para
permitir que el alumno seleccione la opción deseada
• El alumno debe introducir información del curso al sistemaen el escenario “Crear Horario”
• Se crea una clase boundary llamada ScheduleForm paramantener la información que el alumno introduce
Clases Candidatas Boundary
8/20/2019 Analisis y Diseno Orientado a Objetos Co
137/595
137
Clases Candidatas Boundary --
Escenario “Crear Horario”
ScheduleForm
RegistrationForm
8/20/2019 Analisis y Diseno Orientado a Objetos Co
138/595
138
Prototipo de Ventanan Los prototipos de ventanas pueden crearse para comunicar la
apariencia y percepción de la clase boundary al usuario
8/20/2019 Analisis y Diseno Orientado a Objetos Co
139/595
139
Identificación de Clases Boundary
n Las clases boundary también se crean por la
comunicación de sistema-a-sistema
• Puede ser otro sistema de software o una pieza de
hardware (impresoras, alarmas, etc.)
n Las clases boundary se agregan para describir el
protocolo de comunicación elegido
Clases Candidatas Boundary --
8/20/2019 Analisis y Diseno Orientado a Objetos Co
140/595
140
BillingSystem
Printer
Clases Candidatas Boundary --Escenario “Crear Horario”
n El horario del alumno se imprime en el escenario “CrearHorario”
• Se crea una clase boundary Printer
n La información de cobro se envía al Sistema de Cobro enel escenario “Crear Horario” • Se crea una clase boundary BillingSystem
8/20/2019 Analisis y Diseno Orientado a Objetos Co
141/595
141
Identificación de Clase Controln Las clases control contienen típicamente información
secuencial• Precaución: las clases control NO deben desempeñar las
responsabilidades que pertenecen típicamente a las clasesentity y/o boundary
n En este nivel de análisis, una clase control se agregatípicamente para cada caso de uso• Responsable por el flujo de eventos en el caso de uso
n Este es sólo un breve inicio• Cuanto más casos de uso y escenarios se desarrollen,
pueden eliminarse, dividirse o combinarse las clases decontrol
Reglas para el Caso de Uso
8/20/2019 Analisis y Diseno Orientado a Objetos Co
142/595
142
Reglas para el Caso de Uso“Inscripción a Cursos”
n Se agrega una clase control llamada RegistrationManager• Recibe información de la clase boundary ScheduleForm• Para cada curso seleccionado
• Pide los prerequisitos del curso
• Revisa para asegurarse de que todos los prerequisitos deun curso se tomaron al preguntar a StudentRecord si un
prerequisito de curso se había completado
• Sabe que hacer si no se tiene un prerequisito• Pregunta si el curso está abierto• Pide a Course que agregue al alumno (si el curso está
abierto)
• Sabe que hacer si no están disponibles 4 cursos• Crea los objetos StudentSchedule y BillingInformation• Pide al BillingSystem que envíe la BillingInformation
Clase Candidata Control -- Caso de
8/20/2019 Analisis y Diseno Orientado a Objetos Co
143/595
143
Clase Candidata Control -- Caso de
Uso “Inscripción a Cursos”
RegistrationManager
Tarjetas Responsabilidad-
8/20/2019 Analisis y Diseno Orientado a Objetos Co
144/595
144
Tarjetas ResponsabilidadColaboración de Clases
n Las clases también pueden descubrirse usando tarjetasresponsabilidad-colaboración de clases (Class-Responsibility-Collaboration Cards, CRC)n Introducidas por Ward Cunningham y Kent Beck at OOPSLA
en 1989
n Una tarjeta CRC es una tarjeta de 3” x 5” que muestran El nombre y descripción de la clase
n Las responsabilidades de la clase
• Conocimiento interno de la clase
• Servicios proporcionados por la clasen Los colaboradores para las responsabilidades
• Un colaborador es una clase cuyos servicios necesitanuna responsabilidad
8/20/2019 Analisis y Diseno Orientado a Objetos Co
145/595
145
Tarjeta CRC para la Clase Curso
Nombre de Clase Curso
Responsabilidades Colaboraciones
Agregar un alumno
Saber donde de lleva a cabo
Saber cuando se lleva a cabo
Alumno
Conocer los pre-requisitos
Servicio proporcionado
Conocimineto interno
8/20/2019 Analisis y Diseno Orientado a Objetos Co
146/595
146
Una sesión de tarjeta CRC
n Un grupo de personas ejecutan un escenario
n Se crea una tarjeta para cada objeto en el escenario
n Se le asigna un grupo de tarjetas a cada participante
• La persona se convierte en la “clase”
n Los participantes actúan a los escenarios definidos
n Se anotan responsabilidades y colaboraciones en las
tarjetas
n Se crean tarjetas para los objetos descubiertos
8/20/2019 Analisis y Diseno Orientado a Objetos Co
147/595
147
Beneficios de las Tarjetas CRCn Al completar más y más escenarios, emergen los
patrones de colaboración
n Las tarjetas pueden arreglarse físicamente pararepresentar estas colaboraciones cerradas
n Esto puede ayudar a identificar jerarquías degeneralización/especialización o jerarquías deagregación entre las clases
n Las tarjetas CRC son más efectivas para grupos quedesconocen las técnicas OO, ya que ellos:
• Evitan enfocarse a elementos OOP• Evitan generalización prematura
• Fortalecen “object think”
8/20/2019 Analisis y Diseno Orientado a Objetos Co
148/595
148
¿Cómo lo estoy haciendo?n Las cosas van bien si...
• Todas las clases tienen nombre significativos, específicosdel dominio
• Cada clase tiene un pequeño grupo de colaboradores• No hay clases “indispensables” (una clase que colabora con
todos necesita ser redefinida)• La información para cada clase se ajusta bien en una
tarjeta de 3X5• Las clases pueden manejar un cambio en requerimientos
n Las cosas van mal si...• Varias clases no tienen responsabilidades• Una sola responsabilidad se le asigna a varias clases• Todas las clases colaboran con todas las clases
8/20/2019 Analisis y Diseno Orientado a Objetos Co
149/595
8/20/2019 Analisis y Diseno Orientado a Objetos Co
150/595
Diagrama de Secuencias para el
8/20/2019 Analisis y Diseno Orientado a Objetos Co
151/595
151
Diagrama de Secuencias para elEscenario “Crear Horario”(cont.)
:AdministradorInscripcion
:Cursos :RegistroAlumno
:Horario :Impresora :InformaciónCobro
:SistemaCobro
11: obtener los pre-requisitos (curso)
13: disponible ?
14: agregar alumno
12: pre-requisitos tomados (curso)
15: crear
16: imprimir (horario)
17: crear
18: enviar (información de cobre)
LOOP en todaslas ofertas decurso
Diagrama de Colaboración para el
8/20/2019 Analisis y Diseno Orientado a Objetos Co
152/595
152
Diagrama de Colaboración para elEscenario “Crear Horario”
: Alumno
: RegistrationForm
: ScheduleForm
: Catalogue
: RegistrationManager
: CourseOffering
: StudentRecord
: Schedule
: Printer
: BillingInformation
: BillingSystem
2: validar id
5: desplegar
6: obtener ofertas de curso
7: mostrar ofertas de curso
10: crear horario
(alumno, semestre,ofertas)
11: obtener pre-requisitos de cursos
12: tomar pre-requisios (curso)
13: disponible ?14: agregar alumno (alumno)
15: crear
16: imprimir (horario)
17: crear
18: enviar (información de pago)
1: introducir id
3: introducir semestre
4: crear horario
8: seleccionar ofertas de cursos
9: enviar
8/20/2019 Analisis y Diseno Orientado a Objetos Co
153/595
Paquetes en el Sistema de
8/20/2019 Analisis y Diseno Orientado a Objetos Co
154/595
154
qInscripción
n Las clases en el Sistema de Inscripción se puedenagrupar en tres paquetes:• University Artifacts, Business Rules, e Interfaces
n
UniversityArtifacts• Schedule, Catalogue, CourseOffering, StudentRecord,CourseRoster, y Billing Information
n BusinessRules• RegistrationManager
n Interfaces• RegistrationForm, ScheduleForm, BillingSystem, and
Printer
8/20/2019 Analisis y Diseno Orientado a Objetos Co
155/595
155
¿Qué es un Diagrama de Clases?n La vista lógica se hace de varios paquetes y clases
n Un diagrama de clases es la vista lógica de algunos (o todos)los paquetes y clases• Generalmente hay varios diagramas de clase
• El diagrama de clases principal es típicamente una vista lógicade los paquetes a alto nivel
n Cada paquete posee su propio diagrama de clases principal
n Los diagramas de clases adicionales se agregan como seanecesario
• Vista de las clases participando en un escenario• Vista de las clases “privadas” en el paquete• Vista de una clase, sus atributos y operaciones• Vista de una jerarquía de herencia
Diagrama de Clases Principal para
8/20/2019 Analisis y Diseno Orientado a Objetos Co
156/595
156
ag a a de C ases c pa pa ael Sistema de Inscripción
University Artifacts
Interfaces BusinessRules
Diagrama de Clases Principal de
8/20/2019 Analisis y Diseno Orientado a Objetos Co
157/595
157
g pUniversity Artifacts
BillingInformation Catalogue CourseOffering
CourseRoster Schedule StudentRecord
Diagrama de Clases Principal de
8/20/2019 Analisis y Diseno Orientado a Objetos Co
158/595
158
g pInterfaces
BillingSystem
Printer
RegistrationForm ScheduleForm
Diagrama de Clases Principal de
8/20/2019 Analisis y Diseno Orientado a Objetos Co
159/595
159
g pBusiness Rules
RegistrationManager
8/20/2019 Analisis y Diseno Orientado a Objetos Co
160/595
160
Ejercicio: Identificación de Clasesn Tome un caso de uso desarrollado en la lección previa
• Diagrame al menos un escenario en un diagrama deinteracción
• Cree clases entity, boundary y/o control que seannecesarias
• Escriba una definición para cada clase
n Cree paquetes para el modelo
n
Coloque las clases descubiertas en paquetes
n Cree diagramas de clase iniciales
8/20/2019 Analisis y Diseno Orientado a Objetos Co
161/595
161
8/20/2019 Analisis y Diseno Orientado a Objetos Co
162/595
162
Relaciones
8/20/2019 Analisis y Diseno Orientado a Objetos Co
163/595
8/20/2019 Analisis y Diseno Orientado a Objetos Co
164/595
164
La Necesidad de Relaciones
n Todos los sistemas abarcan varias clases y objetos
n Los objetos contribuyen al comportamiento del sistema
colaborando unos con otros• La colaboración se realiza a través de las relaciones
n Hay dos importantes tipos de relaciones durante el
análisis
• Asociación• Agregación
8/20/2019 Analisis y Diseno Orientado a Objetos Co
165/595
165
RegistrationManager
Course
Asociacionesn Una asociación es una conexión semántica bi-direccional
entre clases• Esto implica que hay una liga entre objetos entre las clases
asociadas
n Las asociaciones se representan en diagramas de clasepor una línea que conecta las clases asociadas
n La información puede fluir en cualquier dirección o enambas direcciones a través de la liga
8/20/2019 Analisis y Diseno Orientado a Objetos Co
166/595
8/20/2019 Analisis y Diseno Orientado a Objetos Co
167/595
167
RegistrationManager
Coursemaneja
Nombrando Asociacionesn Una asociación se debe nombrar para esclarecer su
significado
n El nombre se representa con una etiqueta que se pone a lo
largo de la línea de asociación, entre los iconos de clases
n Un nombre de asociación es generalmente un verbo o unafrase con verbo
ó
8/20/2019 Analisis y Diseno Orientado a Objetos Co
168/595
168
Person Teacher Course
Definición de Rolesn Un rol denota el propósito o capacidad en la que una
clase se asocia con otra
n Los nombres de roles son típicamente sustantivos ofrases con sustantivo
n Un nombre de rol se pone a lo largo de la línea deasociación cerca de la clase que modifica• En uno o en ambos extremos de una asociación se pueden
tener roles
8/20/2019 Analisis y Diseno Orientado a Objetos Co
169/595
8/20/2019 Analisis y Diseno Orientado a Objetos Co
170/595
170
Asociaciones Múltiples (cont.)
¿Modelo bueno o malo?¿Modelo bueno o malo?
adds student toCourseSelection Course
deletes student from
8/20/2019 Analisis y Diseno Orientado a Objetos Co
171/595
I di d d M l i li id d
8/20/2019 Analisis y Diseno Orientado a Objetos Co
172/595
172
Exactamente uno
Cero o más
Uno o más
Cero o uno
Rango específico
1
0..*
1..*
0..1
2..4
Muchos*
Indicadores de Multiplicidadn Cada extremo de una asociación tiene indicadores de
multiplicidadn Indica el numero de objetos que participan en la relación
Ej l M lti li id d
8/20/2019 Analisis y Diseno Orientado a Objetos Co
173/595
173
1..*
PersonTeacher
Course
1
Ejemplo: Multiplicidad
n La multiplicidad expone varias hipótesis ocultas sobre el
problema que se está modelando
n ¿Puede estar un maestro en sabático?
n ¿Puede tener un curso dos maestros?
8/20/2019 Analisis y Diseno Orientado a Objetos Co
174/595
A ió
8/20/2019 Analisis y Diseno Orientado a Objetos Co
175/595
175
ScheduleFormRegistrationForm
1 111
Agregaciónn La agregación es una forma especializada de asociación
en la que un todo se relaciona con sus partes• La agregación es conocida como la relación “parte de” o
“contiene a”
n Una agregación se representa como una asociación con
un diamante en el extremo de la liga, del lado de laclase que denota el agregado (todo)
n La multiplicidad se representa de la misma manera queotras asociaciones
P b d A ió
8/20/2019 Analisis y Diseno Orientado a Objetos Co
176/595
176
Pruebas de Agregaciónn ¿Se usa la frase “parte de” para describir relaciones?
• Una Puerta es “parte de” un Carro
n ¿Se aplican algunas operaciones en el todo y automáticamentea sus partes?• Al mover el Carro, se mueve la Puerta
n ¿Se propagan algunos valores de atributos del todo a todas oalgunas de sus partes?• El Carro es azul, la Puerta es azul
n ¿Hay una asimetría intrínseca a la relación donde una clase se
subordina a la otra?• Una Puerta es parte de un Carro, un Carro NO es parte deuna Puerta
¿A i ió A ió ?
8/20/2019 Analisis y Diseno Orientado a Objetos Co
177/595
177
Curriculum y Course están muyligados -- Curriculum estácompuesto de 1 a muchos Courses
Objetos independientes
StudentCourse
3..10
Curriculum
1..* 0..*1
¿Asociación o Agregación?
n Si dos objetos están estrictamente limitados por unarelación complementaria• La relación es un agregación
n Si dos objetos se consideran usualmente comoindependientes, y aún así están ligados• La relación es una asociación
Asociaciones Refle i as
8/20/2019 Analisis y Diseno Orientado a Objetos Co
178/595
178
Un curso puede tener muchos pre-requisitosUn curso puede ser pre-requisito de otros cursos
Course
Pre-requisite
0..*
0..*
Asociaciones Reflexivasn En una asociación reflexiva, se relacionan los objetos de la
misma clase
• Indica que múltiples objetos en la misma clase colaboran juntas en otra forma
Agregaciones Reflexivas
8/20/2019 Analisis y Diseno Orientado a Objetos Co
179/595
179
Un objeto ProductPart está “compuesto de”cero o más objetos ProductPart
ProductPart
0..*
1
Agregaciones Reflexivasn Las agregaciones pueden también ser reflexivas
• El tipo de problema clásico de productos y sus partes
n Esto indica una relación recursiva
Clase de Asociación
8/20/2019 Analisis y Diseno Orientado a Objetos Co
180/595
180
Student 0..*
3-10
Course
Clase de Asociaciónn Si quisiéramos rastrear los grados para todos los cursos
que un alumno ha tomado, entonces…
n La relación entre Student y Course es una relación demuchos-a-muchos
n ¿Dónde ponemos el atributo de grado?
Clase de Asociación (cont )
8/20/2019 Analisis y Diseno Orientado a Objetos Co
181/595
181
Clase de Asociación (cont.)n El atributo grado no puede ponerse en la clase Course
porque existen (potencialmente) varias ligas a objetosStudent
n El atributo grado no puede ponerse en la clase Student
porque existen (potencialmente) varias ligas a objetosCourse
n Por lo tanto, el atributo en realidad pertenece a la ligaStudent-Course
n Una clase de asociación se usa para mantener dichainformación
Dibujo de Clase de Asociación
8/20/2019 Analisis y Diseno Orientado a Objetos Co
182/595
182
Student 1..*
3-10
Course
grade
Dibujo de Clase de Asociaciónn Se crea una clase de asociación usando el icono clase
n Se conecta el icono de la clase a la línea de asociacióncon una línea punteada
n
La clase de asociación puede incluir múltiplespropiedades de la asociación
n Sólo se permite una clase de asociación por asociación
Clase de Asociación y Multiplicidad
8/20/2019 Analisis y Diseno Orientado a Objetos Co
183/595
183
Student 13-10
Course
grade
Student 1
3-10
Course
grade
Clase de Asociación y Multiplicidadn Las clases de asociación se emplean en asociaciones de
muchos-a-muchos
n Si la multiplicidad en cualquiera de los extremos de unaasociación es “a-una” n El atributo puede ponerse en la clase donde la relación es “amuchos”, on Puede aún usarse una clase asociación
Calificadores
8/20/2019 Analisis y Diseno Orientado a Objetos Co
184/595
184
Dado un objeto Department y unvalor para un Employee ID hayexactamente un objeto Professor
Dado un objeto Department y un
valor para Title hay un conjunto deobjetos Professor
Department Professor
TitleTitleTitle
1..*1
Department Professor EmployeeIDEmployeeIDEmployeeID
11
Calificadoresn Un calificador es un atributo o grupo de atributos cuyos
valores dividen el conjunto de objetos relacionado a unobjeto a través de una asociación
Restricciones
8/20/2019 Analisis y Diseno Orientado a Objetos Co
185/595
185
1..*
{Ordered byemployee id}
Professor Department
1..*
is a member of
is head of
{Subset}
1
1 1
Restricciones
n Una restricción es la expresión de alguna condición que se
debe preservar
• Una restricción se muestra como una línea punteada
Identificación de Asociaciones yAgregaciones
8/20/2019 Analisis y Diseno Orientado a Objetos Co
186/595
186
RegistrationForm“habla” conScheduleForm
ScheduleForm“habla” conRegistrationManager
aform:RegistrationForm
aform:ScheduleForm
theMgr:RegistrationManager
despliega
crea
Agregacionesn Deben examinarse los escenarios para determinar si una
relación debe existir entre dos clasesn Dos objetos pueden comunicarse solo si se “conocen” entre
ellos
n Las asociaciones y/o agregaciones proporcionan una ruta
de comunicación
¿Asociación o Agregación?
8/20/2019 Analisis y Diseno Orientado a Objetos Co
187/595
187
¿Asociación o Agregación?
RegistrationForm y ScheduleForm están muy ligadas-- una ScheduleForm es “parte de” la RegistrationForm
ScheduleForm yRegistrationManagerson independientes
RegistrationForm
11 ScheduleForm
1 1
RegistrationManager
1
1
1
1
Relaciones de Paquetes
8/20/2019 Analisis y Diseno Orientado a Objetos Co
188/595
188
Interfaces
Business Rules
University
Artifacts
Relaciones de Paquetesn Los paquetes se relacionan unos
con otros a través de una relaciónde dependencia
n Si una clase en un paquete “habla” con una clase en otropaquete entonces se agrega unarelación de dependencia al niveldel paquete
n Los diagramas de escenario y declases se evalúan para determinarlas relaciones entre paquete
Relaciones en el Análisis y Diseño
8/20/2019 Analisis y Diseno Orientado a Objetos Co
189/595
189
Relaciones en el Análisis y Diseñon Durante el análisis, se establecen conexiones
(asociaciones y agregaciones) entre clases• Estas conexiones existen debido a la naturaleza de las
clases y no debido a una implementación específica• Hacer una estimación inicial de multiplicidad para exponer
hipótesis ocultas
n Los diagramas de clases se actualizan para mostrar lasrelaciones agregadas
n Durante el diseño:
• Se refinan y actualizan las estimaciones de multiplicidad• Se avalúan y refinan las asociaciones y agregaciones• Se evalúan y refinan las relaciones de paquetes• Se maduran los diagramas de clases
8/20/2019 Analisis y Diseno Orientado a Objetos Co
190/595
Actualización del Diagrama deClases de Interfaces
8/20/2019 Analisis y Diseno Orientado a Objetos Co
191/595
191
Clases de Interfaces
RegistrationForm
11
1
RegistrationManager (de Business Rules)
BillingSystem
1
1
1
ScheduleForm
1 1
1
1
Catalogue(de UniversityArtifacts)
1
1
1
1
Actualización del Diagrama deClases de University Artifacts
8/20/2019 Analisis y Diseno Orientado a Objetos Co
192/595
192
Clases de University Artifacts
Course
Catalogue
ScheduleForm
(de Interfaces)
1
1
1
1
1
CourseRoster
Schedule
RegistrationManager (de Business Rules)
1
0..4agrega alumno a1
1
1
1
1
1
StudentRecord1
1
1
1
1
1
1
1
0..4
accesa
crea Agrega alumno a
Actualización del Diagrama deClases de Business Rules
8/20/2019 Analisis y Diseno Orientado a Objetos Co
193/595
193
Clases de Business Rules
Course(de UniversityArtifacts)
0..41
BillingSystem(de Interfaces)
ScheduleForm(de Interfaces)
CourseRoster (de UniversityArtifacts)
Schedule(de UniversityArtifacts)
StudentRecord(de UniversityArtifacts)
RegistrationManager
1
agrega alumno a
11
1
11
1
agrega alumno a
1
1
crea
1
1
accesa
11
1
11
1
1
1
1
1
Ejercicio: Relaciones
8/20/2019 Analisis y Diseno Orientado a Objetos Co
194/595
194
Ejercicio: Relacionesn Usando los escenarios y diagramas de secuencias
generados en lecciones anterioresn Actualizar los diagramas de clases mostrando relaciones
entre clases• Asegurarse de que se tomen las decisiones de
multiplicidad inicial
n Agregar relaciones a los paquetes para el sistema
8/20/2019 Analisis y Diseno Orientado a Objetos Co
195/595
Operaciones y Atributos
8/20/2019 Analisis y Diseno Orientado a Objetos Co
196/595
196
Operaciones y Atributos
Objetivos: Operaciones y Atributos
8/20/2019 Analisis y Diseno Orientado a Objetos Co
197/595
197
Objetivos: Operaciones y Atributos
n Usted podrá:
• Definir operaciones para clases
• Definir atributos para clases• Definir encapsulación y establecer sus beneficios
• Representar atributos y operaciones en diagramas de clase
¿Qué es una operación?
8/20/2019 Analisis y Diseno Orientado a Objetos Co
198/595
198
Una operación debe desempeñar una función simple y cohesivaUna operación debe desempeñar una función simple y cohesiva
¿Qué es una operación?n Una clase engloba un conjunto de responsabilidades que definen
el comportamiento de los objetos de esa clase
n Las responsabilidades de una clase se llevan a cabo por susoperaciones
n
Esto no es necesariamente un mapeo de uno-a-uno• Responsabilidad de la clase Producto -- precio de venta
• Operaciones para esta responsabilidad• Buscar información de una base de datos
• Calcular el precio
n Una operación es un servicio que puede ser solicitado desde unobjeto al comportamiento de efecto
Las operaciones dependen deldominio
8/20/2019 Analisis y Diseno Orientado a Objetos Co
199/595
199
Perspectiva del Banquero
recibir rentamanejar cuentarecibir líneaDeCrédito
Perspectiva del Doctor
examinar tomarMedicinairAlHospitalrecibirFactura
dominio
n Listar las operaciones relevantes al dominio del problema
• Las operaciones de la clase Persona serán diferentesdependiendo de “quién esté preguntando”
Nombrando Operaciones
8/20/2019 Analisis y Diseno Orientado a Objetos Co
200/595
200
Nombrando Operacionesn Las operaciones deben nombrarse para indicar su resultado,
no los pasos detrás de la operación.
n Ejemplos:
n calculateBalance()• Pobremente nombrado
• Indica que se debe calcular el balance -- esta es unadecisión de implementación/optimización
n getBalance()• Bien nombrado
• Indica solamente el resultado
Nombrando Operaciones (cont.)
8/20/2019 Analisis y Diseno Orientado a Objetos Co
201/595
201
Nombrando Operaciones (cont.)n Las operaciones deben nombrarse desde la perspectiva del
proveedor no del cliente
n En una gasolinera, la gasolina se recibe de la bomba
n La bomba tiene su responsabilidad a través de unaoperación -- ¿cómo se le debe llamar?
• Nombres adecuados -- dispense(), giveGas()
• Nombre malo -- receiveGas()
• La bomba da la gasolina -- no recibe la gasolina
¿Qué es una operación primitiva?
8/20/2019 Analisis y Diseno Orientado a Objetos Co
202/595
202
Q op ó pn Una operación primitiva es una operación que no puede ser
implementada usando solamente las operaciones internas de
la clase
• Todas las operaciones de una clase son típicamenteprimitivas
n Ejemplo:
• Agregar un objeto a un conjunto -- operación primitiva• Agregar cuatro objetos a un conjunto -- no primitiva
• Se puede implementar con llamadas múltiples a la
operación de agregar un objeto a
Recommended