Analisis y Diseno Orientado a Objetos Co

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


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


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


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


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


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


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/595

8

Introducción


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


10/595


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


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


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


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


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


16/595


17/595

17

Vendedor Producto

Ventas

Corporativo

Cliente

Individual Trailer

Vehiculo

Tren

Diagrama de Clases de Ventas


18/595

18

Efecto en el Cambio de

Requerimientos

Vendedor Producto

Ventas

Corporativo

Cliente

Individual Trailer

Vehiculo

Tren


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)


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


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


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


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


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


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


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


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


28/595


29/595

29

Desarrollo Iterativo e Incremental


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


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


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


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%)


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


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


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


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


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


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


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


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


42/595

42


43/595

43

Comportamiento del Sistema


44/595


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


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


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


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


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


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?


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


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


53/595

53

Límites de los actores y el sistema

MantenimientoATM

Cajero

¿Límite del sistema?

Sistema ATM

S is tema del Banco


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


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?


56/595


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


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


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


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


61/595


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.


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.


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


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.


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.


67/595

67


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.


68/595


69/595

69


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.


70/595

70


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.


71/595

71


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.


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


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.


74/595

74

Escenarios Secundariosn ¿Qué escenarios secundarios podrían considerarse

para el caso de uso: “Inscripción a Cursos”?


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


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


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


78/595

78


79/595


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


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


82/595


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


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)


85/595

85

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


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


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


88/595

88

Clases de Objetosn ¿Cuántas clases ve?


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


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


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


92/595


93/595


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


95/595

95

Professor

Profesor Clark

a + b = 10

Representación de Clasesn Una clase se representa usando un rectángulo con tres

divisiones


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


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 >


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


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


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


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


102/595

102


103/595

103

Interacción de Objeto


104/595

104

Objetivos: Interacción de Objeton Usted podrá:

• Usar diagramas de secuencia y colaboración paramostrar las interacciones de los objetos


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


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)


107/595


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


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


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


111/595


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


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


114/595

114

Ejemplo de Script

Procesa los cursos primariosy solo recurre a los cursosalternos si es necesario

forma dehorario

obtener prerequisito

un curso


115/595


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


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

ó


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


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


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


121/595

121


122/595


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


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


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


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


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?


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


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


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


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


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


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


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


135/595


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


137/595

137

Clases Candidatas Boundary --

Escenario “Crear Horario”

ScheduleForm

RegistrationForm


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


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 --


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


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


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


143/595

143

Clase Candidata Control -- Caso de

Uso “Inscripción a Cursos”

RegistrationManager

Tarjetas Responsabilidad-


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


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


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


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”


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


149/595


150/595

Diagrama de Secuencias para el


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


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


153/595

Paquetes en el Sistema de


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


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


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


157/595

157

g pUniversity Artifacts

BillingInformation Catalogue CourseOffering

CourseRoster Schedule StudentRecord



158/595

158

g pInterfaces

BillingSystem

Printer

RegistrationForm ScheduleForm



159/595

159

g pBusiness Rules

RegistrationManager


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


161/595

161


162/595

162

Relaciones


163/595


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


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


166/595


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

ó


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


169/595


170/595

170

Asociaciones Múltiples (cont.)

¿Modelo bueno o malo?¿Modelo bueno o malo?

adds student toCourseSelection Course

deletes student from


171/595

I di d d M l i li id d


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


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?


174/595

A ió


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ó


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ó ?


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


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


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


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 )


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


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


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


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


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


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



187/595

187


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


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


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


190/595

Actualización del Diagrama deClases de Interfaces


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


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


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


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


195/595

Operaciones y Atributos


196/595

196

Operaciones y Atributos

Objetivos: Operaciones y Atributos


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?


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


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


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.)


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?


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

Documents

Analisis y Diseno Orientado a Objetos Co