COMPORTAMIENTO DEL SISTEMA: CASOS DE USO

Objetivos: Comportamiento del Sistema

Al terminar este Captulo, usted podr:
Definir el comportamiento del sistema en trminos de casos de uso

Definir casos de uso y actores

Crear un diagrama de caso de uso para mostrar los actores, el caso de uso y la forma en que interactan

Definir escenarios para los casos de uso

Entender la manera de documentar casos de uso

Qu es Comportamiento del Sistema?

Comportamiento del Sistema
Es como el sistema acta y reacciona a estmulos externos Es la actividad visible exteriormente y a la que se le pueden hacer pruebas Define los requerimientos funcionales del sistema

El comportamiento del sistema se captura en los casos de uso Los casos de uso describen al sistema, su ambiente y las relaciones entre el sistema y su ambiente

El Modelo de Casos de Uso

Es un modelo de las funciones deseadas del sistema (casos de uso) y lo que lo rodea (actores) Es usado para capturar los requerimientos funcionales del sistema Es la base del proceso de desarrollo e impulsa el anlisis, diseo, implementacin y pruebas del sistema
El propsito principal del modelo de casos de uso es comunicar la funcionalidad y comportamiento del sistema al cliente y/o usuario final para que este lo valide.

El Modelo de Casos de Uso

Se usa para identificar

Los flujos funcionales que deben realizarse con el sistema Los roles de usuarios que deberan interactuar con el sistema Las interfaces que debe tener el sistema hacia sistemas externos

Se usa para verificar

Que todos los requerimientos funcionales se han capturado Que todos los desarrolladores han entendido estos requerimientos

Facilita la comunicacin con los usuarios finales y expertos del dominio

Proporciona aceptacin desde las primeras etapas de desarrollo del sistema

Conceptos Importantes en Modelacin de Casos de Uso

Un actor representa cualquier cosa que interacta con el sistema Actor Un caso de uso es una secuencia de acciones que el sistema ejecuta que produce un resultado observable para un actor en particular

Caso de Uso

Actores
Los actores no son parte del sistema, ellos representan roles que pueden jugar usuarios del sistema Un actor puede intercambiar informacin activamente con el sistema Un actor puede ser un receptor pasivo de informacin Un actor puede representar a un ser humano, una mquina o a otro sistema

Actor

Identificando Actores: preguntas tiles

Quin est interesado en cierto requerimiento? Dnde se usa el sistema en la organizacin? Quin suplir al sistema de informacin, quien usa y elimina esta informacin? Quin usar esta funcin? Quin dar soporte y mantenimiento al sistema? El sistema usa un recurso externo? Qu actores necesitan los casos de uso? Algn actor interpreta varios roles diferentes? Existen varios actores con el mismo rol?

Instancias de Actores
Ivar representa al actor Cliente
Inserte su Tarjeta
123 456 789 *0#

Tom representa al actor Cliente

Modelo de casos de uso

Cliente

Hacer Transaccin Bancaria

Un Usuario puede Actuar como Diferentes Actores

Carlos como Tcnico

Inserte su Tarjeta

123 456 789 *0#

Carlos como Cliente

Tcnico Mantenimiento
Cliente

Actores y Fronteras del Sistema

Tcnico Mantenimiento

Frontera del Sistema?

Cajero de Ventanilla

Sistema Cajeros Automticos Sistema Bancario

Actores y Fronteras del Sistema

Tcnico Mantenimiento

Frontera del Sistema?

Cajero de Ventanilla

Sistema Cajeros Automticos Sistema Bancario

Casos de Uso

Caso de Uso

Un Caso de Uso modela un dilogo entre actores y el sistema Un CU inicia cuando un actor invoca cierta funcionalidad del sistema Un CU es un flujo completo y significativo de eventos Tomados juntos, los casos de uso constituyen todas las formas posibles del uso del sistema

Identificando Casos de Uso: preguntas tiles

Cules son las tareas de este actor? El actor crear, guardar, cambiar, eliminar o leer informacin del sistema? Con qu caso de uso se crear, guardar, cambiar, eliminar o leer esta informacin? El actor necesitar informar al sistema acerca de cambios externos repentinos? Necesita el actor ser informado acerca de ciertas ocurrencias en el sistema? Le proporciona el sistema al negocio el comportamiento correcto? Qu casos de uso darn soporte y mantenimiento al sistema? Pueden los casos de uso ejecutar todos los requerimientos funcionales?

Asociaciones: Interacciones entre Actores y Casos de Uso

Una asociacin implica comunicacin

La asociacin se representa con una linea con punta de flecha

Hacer Retiro De Ahorros o Cheques? Ahorros Que Cuenta? Cuenta XXXXXXX

Esta linea entre el actor y el caso de uso indica que ellos interactan enviando mensajes uno al otro
Para cada mensaje enviado se asume una respuesta La direccin de la flecha indica quien envio el primer mensaje
Cajero de Ventanilla

Hacer Transaccin Para Cliente

Hacer Cierre de Caja

Sistema Bancario

Ejemplo de Diagrama Casos de Uso

Realiza Transaccin Bancaria

Cliente Banco Ejecuta Reportes De Control

Tcnico Mantenimiento

Mantiene el Cajero Automtico

Fuentes de informacin para Casos de Uso

Especificaciones del sistema / formulacin del problema (Documento Visin en RUP) Literatura y documentacin relevante al dominio Entrevistas con los expertos del dominio Conocimiento personal del dominio Sistemas anteriores

Documentacin de Casos De Uso

Los casos de uso se documentan con:

Una Descripcin Breve que establece el propsito del caso de uso en pocas lneas Un Flujo de Eventos detallado

La documentacin debe poderse leer como un dilogo entre el actor y el caso de uso La documentacin se redacta en trminos que el cliente pueda entender (usando el lenguaje del dominio)

Flujo de Eventos de Casos de Uso

Cada caso de uso:
Tiene una secuencia bsica (flujo bsico) de eventos Puede tener varias secuencias secundarias (flujos alternos) de eventos Usualmente tiene una o mas secuencias de eventos de excepcin (flujos de excepcin) para manejar errores Tambin puede tener pre-condiciones y post-condiciones bien definidas

Flujo de Eventos de Casos de Uso

Un Flujo Bsico (Happy Day Path) Varios Flujos Alternos

Variantes del Flujo Bsico Casos Especiales

Flujos de Excepcin (para manejar

situaciones de error)

Gua para Hacer el Flujo de Eventos

El flujo de eventos debe describir
Cmo y cundo el caso de uso comienza y termina En que momento el caso de uso interacta con los actores Qu informacin se intercambia entre el actor y el caso de uso (no describa los detalles de la interfase con el usuario) El flujo de eventos bsico Cualquier flujo de eventos alterno

Describir slo los eventos que pertenecen al caso de uso Evite terminologa vaga como por ejemplo, informacin y etc.

Asociaciones Especiales: Interacciones entre CU

Una asociacin puede darse entre dos casos de uso

Se representa con una linea con punta de flecha cerrada y se le asigna un estereotipo Los dos estereotipos mas comnes son <<uses>> y <<extends>> <<uses>> implica que un CU utiliza el flujo funcional de otro CU como parte de su flujo basico. A esta asociacin tambien se le conoce como <<includes>> <<extends>> implica que un CU extiende el flujo basico de otro CU resultando en un flujo alterno
<<uses>>

Consultar Cuenta De Cheques <<extends>> Imprimir Estado De Cuenta

Cajero de Ventanilla

Hacer Deposito De Cheques

Quin lee la documentacin de los Casos de Uso?

Los clientes aprueban lo que el sistema debe hacer Usuarios aumentan su comprensin del sistema Desarrolladores del Sistema documentan el comportamiento del sistema Revisores examinan el flujo de eventos Analistas de Sistemas (Diseadores del Sistema) proveen la base para el anlisis y el diseo Probador del Sistema la usa como base para los casos de prueba Lder de Proyecto proporciona informacin para planear proyectos Escritor Tcnico es la base para escribir la gua del usuario

Ejemplo Registro Estudiantil Descripcin del Problema

Al principio de cada semestre, se llevara a cabo un Proceso de Registro que durar 3 das. Durante este proceso, los estudiantes debern asignarse los cursos que llevaran durante el semestre. El primer da se dar orientacin y registro a los estudiantes de primer ao.Todos los dems estudiantes podrn registrarse a partir del segundo da. El tercer da se utilizar adems para resolver los conflictos en las asignaciones de cursos. Para manejar el proceso, la Oficina de Registro necesita de un nuevo sistema que pueda ser utilizado desde el Internet y/o la intranet de la universidad, por los estudiantes, profesores y el personal de la oficina de registro, para realizar las diferentes funciones implcitas en el proceso. Este sistema se utilizara luego del proceso de registro para que los profesores puedan registrar las calificaciones de los estudiantes, y estos a su vez puedan consultarlas.
(contina)

Ejemplo Registro Estudiantil

El sistema debe incluir un control de acceso que permita que los usuarios ingresen con un cdigo de identificacin y un password, los cuales sern entregados a todos los posibles usuarios antes de que inicie el proceso. El control de acceso determinara que funcionalidad tendr disponible el usuario por parte del sistema, segn el tipo de usuario que sea. Tambin debe validar que solo los estudiantes de primer ao puedan entrar el primer da del proceso de registro. El sistema debe proveer una lista de cursos disponibles para el semestre, en donde los estudiantes puedan consultar la informacin que necesiten de cada curso para tomar decisiones. Esto incluye el nombre, descripcin, crditos y prerrequisitos del curso, as como informacin de las secciones (numero, aula, horario, estado) disponibles por curso. Cada curso puede tener una o mas secciones. El estado de las secciones indica si estn abiertas, cerradas (llenas) o si fueron canceladas. Cada seccin puede tener como mximo 20 estudiantes y al llegar a esa cifra el sistema debe cerrarla y actualizar la lista de cursos disponibles para que la seccin refleje esto en su estado.
(contina)

Ejemplo Registro Estudiantil

Para inscribirse en los cursos que deben llevar, los estudiantes tendrn que crear y mantener un horario de cursos. En este, deben indicar 4 opciones principales y 2 opciones alternas en caso de que sus otras opciones se cancelen. Para indicar cada opcin, los estudiantes deben usar un numero de seccin (que es nico, e implcitamente hace referencia al curso). Si una seccin de un curso tiene menos de 3 estudiantes cuando se cierre el proceso de registro, esta ser cancelada. Tambin puede ser cancelada en cualquier momento por causas de fuerza mayor. Los estudiantes tambin podrn modificar o eliminar su horario y el sistema debe llevar control en lnea del total de estudiantes por seccin, para reabrirla si el total baja de 20 estudiantes. El sistema debe validar cada vez que se crea o modifica un horario, que cada opcin cumple con los prerrequisitos necesarios, segn el historial acadmico del estudiante. Tambin debe validar que la opcin esta dentro del plan de estudios (carrera y especialidad) en que esta inscrito el estudiante y que no existen conflictos de horario con otras opciones (esto ultimo, solo para las opciones principales).
(contina)

Ejemplo Registro Estudiantil

Los estudiantes tambin podrn incluirse en una lista de solicitantes para nuevas secciones, en caso de que quieran asignarse un curso cuyas secciones ya estn llenas. Esta lista estar adjunta a cada curso en la lista de cursos disponibles y ser revisada en el tercer da, pero esto no garantiza que se abrir una nueva seccin. Si se abre una nueva seccin, los estudiantes en la lista sern notificados por correo electrnico para que procedan a inscribirse. Los profesores deben poder usar el sistema desde una semana antes que inicie el proceso, para indicar cuales cursos van a dictar. Para esto deben escoger de la lista de cursos disponibles, la seccin o secciones que mas les convengan de los cursos para los que estn autorizados. Deben asignarse entre 9 y 15 horas semanales de clase (esto debe ser validado por el sistema en lnea). El sistema debe tambin detectar si hay conflictos de horario o de autorizacin en las selecciones del profesor. Los profesores tambin necesitarn consultar cuantos y cuales estudiantes se han inscrito en sus secciones. Esta funcin la usaran durante el semestre para asignar calificaciones a los estudiantes.
(contina)

Ejemplo Registro Estudiantil

El personal de registro deber disponer de un reporte que les indique que cursos tienen mas de 15 estudiantes en la lista de solicitantes para nuevas secciones, de manera que puedan gestionar la posible apertura de una nueva seccin para esos cursos. Tambin deben poder abrir nuevas secciones para las solicitudes aprobadas o cancelar secciones existentes, si esto es necesario. El proceso de registro termina cuando un oficial encargado de la oficina de registro corre el proceso de cierre en el sistema. Durante el cierre se cancelan los cursos con menos de tres estudiantes. Los estudiantes que estn inscritos en cursos cancelados (por cualquier razn) sern reasignados automticamente a otros cursos/secciones, segn sus opciones alternas. Tambin en el cierre, se cierran todas las secciones que todava estn abiertas (< 20 estudiantes) y no hallan sido canceladas, se asignan profesores a las secciones que no tengan uno asignado (se escogen de los que tengan menos de 9) y se enva la informacin de cobros (crditos por estudiante) al sistema externo de facturacin para que al estudiante se le pueda cobrar por el semestre, segn su horario.

Ejemplo Registro Estudiantil Especificaciones Suplementarias

El sistema va a ser utilizado desde el Internet y/o la intranet de la Universidad, por lo que se deben tomar las consideraciones necesarias para desarrollar una aplicacin para ambientes WEB. El nuevo sistema en una parte de la aplicacin que debe sustituir al sistema actual de la Oficina de Registro, que se considera inflexible y ya no se puede mantener. La especificacin anterior solo cubre la parte mas critica de la funcionalidad deseada, y el resto se deber suplir despus en un proyecto de extensin del sistema. Sin embargo, los datos base necesarios para lograr la funcionalidad deseada estn completos y actualizados en la base de datos de sistema actual. Estos datos incluyen la informacin personal e historial acadmico de los estudiantes, informacin de profesores, cursos (incluyendo no solo los disponibles, sino todos los que estan en los planes de estudio) y secciones.
(contina)

Ejemplo Registro Estudiantil

Lo anterior significa que el proyecto debe incluir la actividad de migracin de datos, para minimizar el ingreso y traslado de informacin por otros medios, y porque se desea utilizar un RDBMS para manejar y almacenar la informacin del nuevo sistema. Con respecto a la carga proyectada de usuarios, se estima que pueden haber hasta 1000 estudiantes utilizando el sistema en forma simultanea desde Internet y 500 en la intranet. Si se sobrepasan estas cifras, el sistema debe denegar temporalmente el acceso a los estudiantes que intenten conectarse. Los profesores y personal de la oficina de registro deben poder conectarse siempre, sin importar la carga que se tenga en ese momento el sistema. La oficina de Registro deber proporcionar Guas de Usuario a los estudiantes y profesores, para indicarles como deben usar el sistema. Sin embargo se prev que habrn muchos usuarios que no dispongan de esas guas, por lo que debe estar disponible en lnea, y por lo que el interfaz de usuario debe ser muy sencillo e intuitivo (curva de aprendizaje cero), que es lo normal en aplicaciones para ambientes Web.

Ejemplo Registro Estudiantil

Actores

Encargado del Registro

Profesor Estudiante

Sistema de Facturacin

Ejemplo Registro Estudiantil

Casos de Uso

Los Actores se examinan para determinar sus necesidades

Todos los Usuarios Login Estudiante Consultar lista de cursos disponibles Inscribirse en cursos Solicitar apertura de nuevas seccines Consultar notas de cursos Profesor Escoger cursos a dictar Consultar lista de estudiantes asignados Asignar notas a estudiantes
(contina)

Ejemplo Registro Estudiantil

Casos de Uso

Los Actores se examinan para determinar sus necesidades

Encargado del Registro Lanzar reporte de solicitantes para nuevas seccines Abrir nuevas secciones Cancelar secciones existentes Correr cierre del Proceso de Registro Sistema de Facturacin Recibir la informacin de cobros del registro

Ejemplo Registro Estudiantil

Diagramas de Casos de Uso

Login

Consultar Calificaciones

Consultar Lista De Cursos <<uses>>

Estudiante

Inscribirse en Cursos

<<uses>>

Solicitar Apertura De Nuevas Secciones

Ejemplo Registro Estudiantil

Diagramas de Casos de Uso

Asignar Calificaciones <<extends>>

Profesor

Revisar Lista De Estudiantes

Escoger Cursos A Dictar Login

Ejemplo Registro Estudiantil

Diagramas de Casos de Uso

Cerrar Seccin Abrir Nueva Seccin Encargado del Registro

Correr Proceso de Cierre

Sistema de Facturacin

Login

Lanzar Reporte Solicitudes Nuevas Secciones

Ejemplo Registro Estudiantil

Documentacin de Casos De Uso

Nombre del CU: Inscribirse en Cursos

1 Descripcin Breve
A travs de este caso de uso, el sistema le permite al estudiante crear, modificar y eliminar el horario de cursos para el semestre actual. Tambin le permite generar un versin para impresin del horario.

2 Flujo de Eventos
2.1 Pre-Condiciones
El estudiante debe haber completado el caso de uso Login.
(contina)

Ejemplo Registro Estudiantil

Documentacin de Casos De Uso

2.2 Flujo Principal
2.2.1 Crear un Horario Nuevo
2.2.1.1 El estudiante escoge la opcin Inscribirse en Cursos y el sistema pide al estudiante seleccionar la actividad deseada: CREAR, MODIFICAR, IMPRIMIR , ELIMINAR HORARIO o SALIR. 2.2.1.2 El estudiante escoge Crear un Horario Nuevo para el flujo principal. Si la actividad seleccionada es
MODIFICAR, se ejecuta 2.3.1: Modificar Horario ELIMINAR, se ejecuta 2.3.2: Eliminar Horario IMPRIMIR, se ejecuta 2.3.3: Imprimir Horario SALIR, se termina el caso de uso.
(contina)

Ejemplo Registro Estudiantil

Documentacin de Casos De Uso

2.2.1.3 El sistema muestra una pantalla de horario vaca y la lista de cursos disponibles para que el usuario pueda consultarla. 2.2.1.4 El estudiante ingresa 4 nmeros de seccin (E-1) como opciones principales y 2 nmeros de seccin (E-1) como opciones alternas. 2.2.1.5 El estudiante somete a validacin su horario. Para cada opcin ingresada el sistema verifica que
La seccin este abierta (E-2) no existan conflictos de horario (E-3) que el curso est en el plan de estudio del estudiante (E-4) que los prerrequisitos se cumplan (E-5)

2.2.1.7 Para cada opcin que cumpla las validaciones, el sistema aade al estudiante a la seccin escogida y actualiza totales. 2.2.1.6 Se usa el flujo alterno 2.3.3 Imprimir Horario. Si el estudiante desea sustituir las opciones no aceptadas por otras, debe realizar el flujo alterno 2.3.1 Modificar Horario. Termina el CU.
(contina)

Ejemplo Registro Estudiantil

Documentacin de Casos De Uso

2.3 Flujos Alternos
2.3.1 Modificar Horario 2.3.1.1 El sistema muestra una pantalla con el horario del estudiante y la lista de cursos disponibles para que el usuario pueda consultarla. 2.3.1.2 El estudiante revisa y modifica su horario, incluyendo hasta 4 nmeros de seccin (E-1) como opciones principales y 2 nmeros de seccin (E-1) como opciones alternas. 2.3.1.3 El caso de uso prosigue en el subflujo 2.2.1.5 del flujo principal. 2.3.2 Eliminar Horario 2.3.2.1 El sistema muestra una pantalla con el horario del estudiante y un dialogo para que el estudiante confirme que si desea eliminar el horario.
(contina)

Ejemplo Registro Estudiantil

Documentacin de Casos De Uso

2.3.2.2 Si el estudiante confirma la eliminacin, sigue el caso de uso, y para cada opcin principal del horario, el sistema elimina al estudiante del curso y seccin escogidos, y actualiza el los totales correspondientes. Termina el CU. 2.3.3 Imprimir Horario 2.3.1.1 El sistema muestra una pantalla con el horario listo para imprimir (printer friendly) e instrucciones de cmo imprimirlo usando la funcionalidad del browser. 2.3.1.2 Si el estudiante confirma la impresin, sigue el caso de uso y el horario se enva a imprimir (E-6).Termina el CU.

2.4 Flujos de Excepcin

E-1 El nmero de seccin no es vlido (por formato o porque no existe). El estudiante puede volver a digitar un nmero vlido o terminar el caso de uso.
(contina)

Ejemplo Registro Estudiantil

Documentacin de Casos De Uso

E-2 E-3 E-4 E-5 E-6 El curso/seccin escogido esta cerrado. Se le informa al estudiante que no se puede incluir esa seccin en su horario y porqu. El caso de uso continua. Hay conflictos de horario con otra seccin. Se le informa al estudiante que no se puede incluir ese curso/seccin en su horario y por qu. El CU continua. El estudiante no cumple con los prerrequisitos. Se le informa al estudiante que no se puede incluir ese curso/seccin en su horario y por qu. El CU continua. El curso/seccin no esta en el plan de estudios de estudiante. Se le informa al estudiante que no se puede incluir ese curso/seccin en su horario y por qu. El CU continua. El horario no se puede imprimir. La informacin se guarda y se le informa al usuario que debe volver a pedir una impresin de su horario. El CU continua.
(contina)

Qu son escenarios?
Un escenario es una instancia de un caso de uso
Es un flujo a travs de un caso de uso

Cada caso de uso tendr una red de escenarios

Escenarios primarios ( happy day scenarios)
Flujo basico la forma en la que el sistema debe funcionar idealmente o la mayoria de las veces

Escenarios secundarios
Flujos alternos Flujos de excepcion

Escenario Inscribirse en Cursos Crear un Horario

Estela Gmez ya hizo el Caso de Uso Login y escoge las opciones Inscribirse en Cursos y Crear un Horario Nuevo. Estela consulta la lista de cursos disponibles y selecciona los cursos Ingls 101(seccin 66574), Geologa 110 (55342), Historia Mundial 200 (85463) y lgebra 110 (76453) como opciones primarias. Luego selecciona como opciones alternas Teora de la Msica 110 (44663) e Introduccin a la Programacin en Java 180 (35353). En la pantalla de horario vaca, Estela ingresa los cdigos de las opciones escogidas y somete el horario a validacin. El sistema determina que las opciones de Estela cumplen con todas las validaciones y aade a Estela a la lista de estudiantes inscritos de cada seccin indicada en el horario. El sistema presenta una copia lista para imprimirse del horario y Estela la imprime usando su browser. Termina el CU.

Escenarios Secundarios
Algunos casos secundarios a considerar son
El estudiante ingresa menos de 4 opciones primarias. El estudiante ingresa menos de 2 opciones secundarias. Uno o mas cursos no pasan las validaciones. El estudiante decide cambiar una o mas opciones. Etc.

Cuntos escenarios son necesarios?

Respuesta sencilla: tantos como uno necesite para entender el sistema a desarrollar Recomendacin
Escenarios primarios
Elabore aproximadamente 80% de estos escenarios

Escenarios secundarios
Elabore algunos de los escenarios secundarios interesantes y de alto riesgo

Resumen: Comportamiento del Sistema

El comportamiento del sistema es como el sistema acta y reacciona El comportamiento de un sistema se puede definir con un modelo de casos de uso Un caso de uso es algo de funcionalidad ejecutada por el sistema en respuesta a un estimulo de un actor externo
Proporcionan el vehculo para capturar los requerimientos de un sistema desde el punto de vista de un usuario

Un actor es algo o alguien que debe hacer interfase con el sistema que se desarrolla Un diagrama de casos de uso es una descripcin grfica del sistema que muestra a los actores y los casos de uso identificados para este sistema La documentacin de los casos de uso consiste en una breve descripcin y un flujo de eventos

Ejercicio: Comportamiento del Sistema

Usando el problema indicado por el instructor
Dibuje un diagrama de casos de uso Escriba una definicin para cada actor Para un caso de uso Escriba una breve descripcin (mximo 2 frases) Escriba el flujo de eventos Liste algunos posibles escenarios

Clases y Objetos

Objetivos: Clases y Objetos

Al final de este Captulo, usted podr: Describir los principios bsicos de orientacin a objetos Definir y dar ejemplos de objetos Definir y dar ejemplos de clases Describir la relacin entre clases y objetos Definir y crear el Modelo Conceptual de un sistema usando un diagrama de clases

Principios Bsicos de Orientacin a Objetos

Orientacin a Objetos Encapsulacin

Modularidad

Abstraccin

Jerarquia

Qu es Abstraccin?
Es la capacidad de conceptualizar entidades genricas de informacin a partir de cosas concretas Se enfatizan caractersticas comunes que interesan Se ignoran otras caractersticas

Sistema de Procesamiento de Ordenes Cliente

Producto

Vendedor

La Abstraccin Minimiza la Complejidad

Qu es Encapsulacin?
Es la capacidad de esconder los detalles de como funciona una cosa (la implementacin), detras de un interface Solo se necesita conocer el interface para poder usar la cosa El usuario no se ve afectado si se cambia o mejora el funcionamiento
interno de la cosa, mientras se mantenga el interface

La Encapsulacin Esconde la Complejidad

Que es Polimorfismo?
Es la habilidad de esconder diferentes implementaciones tras un solo interface

Marca A

Marca B

Marca C

Principio de OO: Encapsulacin

Qu es Modularidad?
Es la capacidad de particionar algo complejo y dificil de manejar, en partes mas sencillas y fciles de manejar

Sistema de Procesamiento de rdenes

Facturacin Cobros Envio de rdenes

La Modularidad Administra la Complejidad

Qu es Jerarqua?
Ms Abstracto

La capacidad de manejar niveles de abstraccin

Activo

Cuenta Bancaria

Valores

Bienes Races

Menos Abstracto

Ahorros

Cheques

Acciones

Bonos

Casas

Edificios

Los elementos al mismo nivel de jerarqua deben estar al mismo nivel de abstraccin

La Jeraquia Organiza la Complejidad

Qu es Herencia?
Es la capacidad de los elementos de una jerarqua, de transmitir sus caractersticas desde los niveles mas abstractos a los mas concretos
Activo
Valor

Cuenta Bancaria
Valor Numero Cuenta

Valores
Valor Emisor

Bienes Races
Valor Ubicacion

Ahorros
Valor Numero Cuenta

Valor Numero Cuenta

Cheques

Acciones
Valor Emisor

Bonos
Valor Emisor

Casas
Valor Ubicacion

Edificios
Valor Ubicacion

Qu es un Objeto?

Informalmente, un objeto representa a una entidad, ya sea fsica, conceptual o software

Entidad fsica

Camin

Entidad conceptual

Proceso Qumico

Entidad de Software

Lista Enlazada

Una Definicin ms Formal

Un objeto es un concepto, abstraccin o cosa con fronteras definidas y con sentido para una aplicacin Un objeto es algo que tiene:
Estado Comportamiento Identidad

Un Objeto tiene Estado

El estado de un objeto es una de las posibles condiciones en que un objeto puede existir El estado de un objeto normalmente cambia con el tiempo El estado de un objeto es usualmente implementado por un conjunto de propiedades llamadas atributos, mas los enlaces que el objeto pueda tener con otros objetos El estado lo establecen los valores de los atributos y enlaces

=(a/)

Profesora Clark

Nombre: Joyce Clark Id Empleado: 4322456 01/06/1995 Contratacin: Profesora Titular Puesto:

Un Objeto tiene Comportamiento

El comportamiento determina como un objeto acta y reacciona El comportamiento define la manera en la que un objeto responde a las peticiones de otros objetos El comportamiento visible de un objeto se modela con un conjunto de mensajes a los que el puede responder Los mensajes se implementan como las operaciones del objeto

Asignar a Profesora Clark a dar Calculo Integral 332 (Devuelve: confirmacin)

Oficial de Registro Jimenez

Profesora Clark

Un Objeto tiene Identidad

Cada objeto tiene una identidad nica, aun si su estado en un momento dado, es idntico al de otros objetos

Profesor J. Prez Ensea Matemticas

Profesor J. Prez Ensea Matemticas

Profesor J. Prez Ensea Matemticas

Representando Objetos con UML

Existen varios tipos de diagramas de UML que deben incluir objetos; un objeto se representa con un rectangulo que contiene el nombre del objeto, subrayado El nombre del objeto puede representarse en tres formatos distintos dependiendo de si se quiere hacer referencia a un objeto especfico (usualmente al modelar un escenario de CU) o a un objeto generico
Objeto Especfico
Solo Nombre del Objeto Nombres de Clase* y Objeto Joyce Clark Joyce Clark:Profesor

=(a/)
Profesora Joyce Clark

Objeto Genrico
Solo Nombre de Clase* :Profesor

* Pronto se definira lo que es Clase

Qu son Clases?
Cuando se han identificado muchos objetos en un dominio, decimos que una clase es una abstraccin que describe un grupo de objetos que tienen: propiedades en comn (atributos) comportamiento en comn (operaciones) relaciones comunes con otros objetos (asociaciones) semntica en comn (descripcin breve) Una clase es una abstraccin porque: enfatiza caractersticas relevantes al sistema suprime otras caractersticas

La Relacin entre Clases y Objetos

Una clase en una definicin abstracta de un objeto
Define la estructura y comportamiento de cada objeto en la clase Sirve como una plantilla para crear objetos

Un objeto es una instancia concreta de una clase

Los objetos pueden agruparse en clases

Clase
Estudiante A. Pineda E. Gomez G. Rodrguez

Ejemplo de Clase
Clase Seccion
Estructura Nombre Aula Crditos Das Hora de Inicio Hora Final

=(a/)

Comportamiento

Aadir un Estudiante Eliminar un Estudiante Ver si est lleno

Clases y Objetos
Cuntas clases ve usted?

El Modelo Conceptual
Es el primer modelo de clases que se debe hacer y rene las abstracciones principales (key abstractions) del sistema que se desea construir

Es un primer intento de definir la estructura del sistema Se obtiene al examinar la Descripcin del Problema y en entrevistas con los expertos del dominio Se usa como una base de entendimiento y cooperacin con los expertos de dominio y / o clientes No debe incluir los detalles de las clases, solo debe identificarlas Un Diccionario del Modelo Uno o mas Diagramas de Clases (normalmente solo uno)

Incluye:

Gua para encontrar Clases

Una clase debe capturar una y solo una abstraccin principal
Mala abstraccin: clase Estudiante que incluye el horario del estudiante para el semestre Buenas abstracciones: clases separadas para Estudiante y Horario :Horario

Estela Gomez

Ingls 101 (66574) Geologa 110 (55342) Historia Mundial 200 (85463) lgebra 110 (76453)

Nombrando las Clases

El nombre de una clase, debe ser el sustantivo singular que mejor caracteriza la abstraccin que se quiere representar con esa clase El que haya dificultad para nombrar una clase, puede ser indicio de que la abstraccin que esta representa no se entiende bien o no esta bien definida Los nombres de las clases deben tomarse directamente del vocabulario del dominio Se debe evitar la tendencia de tratar de dar nombres mas representativos a las

clases que modelan cosas que ya tienen un nombre ampliamente difundido y utilizado en el dominio (eje: tratar de usar OrdenDeTrabajo en vez de Ticket) Las mejores fuentes para escoger nombres, son las entrevistas con los expertos del dominio y la documentacin misma del dominio (que existe aparte del la que se ha creado durante el proyecto; eje. guas de operacin, manuales de procedimientos, etc) Los principales trminos, siglas, apodos, etc. del vocabulario del dominio, deben definirse e incluirse en la documentacin del proyecto (en el RUP se llama a esto el Documento de Glosario)

Gua de Estilo para Nombrar Clases

El proyecto debe contar con una gua de estilo que dicte convenciones y / o estndares para dar y presentar los nombres de las clases Proporciona consistencia al proyecto Resulta en modelos y cdigo fuente ms fcil de mantener Muestra de una Gua de Estilo Las clases se nombran con sustantivos en singular Los nombre de clases comienzan con mayscula El carcter de subrayado no se usa para unir palabras Los nombres compuestos de varias palabras se unen y la inicial de
cada palabra se pone en mayscula

Ejemplos:

Estudiante, Profesor, PlanDeEstudios

Definir la Semntica de la Clase

Luego de nombrar la clase, debe hacerse una descripcin breve y concisa de la clase (Definicin de Trabajo o Working Definition) Enfquese en el propsito de la clase, no en la implementacin El nombre de la clase y la descripcin forman la base de un Diccionario del Modelo

Busque los QUES e ignore los COMOS

Muestra del Diccionario del Modelo

Nombre: Estudiante

Definicin de Trabajo: Informacin acerca de una persona registrada para realizar diversas actividades en la Universidad (principalmente recibir clases), con el fin de completar los cursos que conforman un Plan de Estudios Definicin de Trabajo: Una materia ofrecida por la Universidad, que es parte de un Plan de Estudios

Nombre: Curso

Mientras ms del problema se descubre, deben afinarse las definiciones de las clases conocidas y debe agregarse cualquier clase nueva al diccionario.

Representando Clases con UML

Las clases se representan en Diagramas de Clases, que son diagramas que en un mismo plano muestran uno o mas iconos, donde cada icono representa una clase especfica En UML, el icono que se utiliza para representar una clase es un rectngulo que contiene el nombre de la clase y opcionalmente 3 compartimientos

Profesor o Profesor

=(a/)

Profesora Joyce Clark

Compartimientos de las Clases

Una clase se puede representar con 3 compartimentos o secciones
La primera seccin contiene el nombre de la clase La segunda seccin muestra la estructura o propiedades (atributos) La tercera seccin muestra el comportamiento (operaciones)

El contenido de las secciones segunda y tercera puede suprimirse si no es necesario mostrarlo en el diagrama de clases
Esto depende del nivel de detalle que requiera la perspectiva del diagrama Se pueden suprimir las secciones mismas
Profesor nombre Identificacin crear() guardar() eliminar() cambiar() Profesor Profesor crear() guardar() eliminar() cambiar() Profesor

nombre identificacin

Profesor

Perspectiva en los Diagramas de Clases

Los diagramas de clases pueden ser desde muy abstractos hasta muy concretos, dependiendo de lo que algunos autores* llaman la perspectiva que se haya tomado al crearlos. Esta perspectiva tiene una correlacion directa con el flujo de trabajo en donde se producen los diagramas, y se puede clasificar asi:
Perspectiva Conceptual es la que se usa para hacer el Modelo Conceptual; sirve para modelar conceptos puros o abstracciones, como clases, sin importar como sean estas clases. Los diagramas hechos desde esta pespectiva normalmente son muy sencillos y no tienen detalle alguno mas que para nombrar las clases. Perspectiva de Especificacion es la que se usa para hacer el Modelo de Analisis. Vistas desde esta perspectiva, las clases estan en el punto medio de ser abstractas y concretas; se define que es lo que deben hacer, pero no como deben hacerlo. Los diagramas aqu tienen algun grado de complejidad y detalle. Perspectiva de Implementacion es la que se usa para hacer el Modelo de Diseo. Las clases aqu son muy concretas pues deben incluir toda la informacion de cmo construirlas. Los diagramas creados desde esta perspectiva son muy detallados y complejos.

La perspectiva de los diagramas no es parte formal del UML, pero es una consideracion importante que debe tomarse al crear y revisar los diagramas de clases.

* Steve Cook & Jon Daniels (1994), Martin Fowler (1997)

Ejemplo Registro Estudiantil

Diagrama de Clases para el Modelo Conceptual

Estudiante Horario Seccion Profesor

Curso

Semestre

PlanDeEstudios

ListadoDeCursosDisponibles

EncargadoDelRegistro

ListaDeSolicitantesParaNuevasSecciones

Resumen: Clases y Objetos

Una objeto es algo que tiene estado, comportamiento e identidad
El estado de un objeto es una de las posibles condiciones en las que el objeto puede existir El comportamiento determina como un objeto acta y reacciona a peticiones de otros objetos Cada objeto tiene una identidad nica an si su estado es idntico al de otro objeto

Una clase es una definicin abstracta de un conjunto de objetos que comparten una estructura y comportamiento en comn A las clases se les debe dar un nombre que mejor caracterice la abstraccin que representan
(contina)

Resumen: Clases y Objetos

El Modelo Conceptual es el primer modelo de clases que debe hacerse como parte del A&DOO

Rene las abstracciones principales del sistema Incluye uno o mas diagramas de clases y un Diccionario del Modelo Se hace conjuntamente con los expertos del dominio para establecer
una base de entendimiento y cooperacin

Las clases se representan en UML con un rectngulo que contiene el nombre de la clase y opcionalmente 3 compartimientos

El primer compartimiento contiene el nombre de la clase El segundo compartimiento muestra la estructura (atributos) El tercer compartimiento muestra el comportamiento (operaciones)

Ejercicio: Clases y Objetos

Usando el problema indicado por el instructor
Dibuje un diagrama de clases que represente el Modelo Conceptual Escriba una definicin para cada Clase

Captulo 7

Modelo de Anlisis

Objetivos: Modelo de Anlisis

Al final de este Captulo, usted podr:
Definir el Modelo de Anlisis Utilizar el anlisis de casos de uso para crear un Modelo de Anlisis Encontrar objetos y clases realizando anlisis de casos de uso (Clases de Anlisis) Definir y usar los estereotipos bsicos de clases Usar tarjetas CRC para descubrir clases

El Modelo de Anlisis
Es el resultado del proceso de Anlisis Representa la conceptualizacin del Dominio del Problema Para construirlo se hace el Anlisis de Casos de Uso"

Se toma como base el Modelo de Casos de Uso y el Modelo

Conceptual de clases Se usa la documentacin disponible (descripcin del problema, especificaciones suplementarias, entrevistas, etc.) Se usan los escenarios de CU para ordenar, dirigir y ejecutar el proceso; para cada CU deben hacerse una o mas Realizaciones de Casos de Uso Del Modelo Conceptual, se usan directamente algunas clases, otras se transforman y algunas se desechan
(contina)

El Modelo de Anlisis
Puede tambin agruparse en 2 partes o vistas:

El Modelo Esttico, que representa la estructura del modelo

de anlisis e incluye: Diagramas de Clases

Diagramas de Paquetes

El Modelo Dinmico, que muestra las interacciones y responsabilidades que se manejan en el sistema e incluye: Diagramas de Interaccin Colaboracin Diagramas de Estado

Secuencia

Entrevistas Descripcion Del Problema Especificaciones Suplementarias

Documentacin Criterios de Arquitectura

Diagramas Colaboracion

Modelo Conceptual

Diccionario

Anlisis de Casos de Uso

Diagramas Secuencia

Modelo de Anlisis (Dinamico)

Modelo de Casos de Uso

Escenarios

Contruyendo el Modelo de Anlisis

Modelo de Anlisis (Estatico)

Qu es el Anlisis de Casos de Uso?

Es la primera etapa para crear las Realizaciones de Casos de Uso El anlisis de casos de uso es el proceso de examinar los casos de uso para descubrir los objetos y clases del sistema a desarrollar (Clases de Anlisis) Para estas clases deben identificarse:
Su estructura (propiedades) Su comportamiento (responsabilidades) Sus relaciones con otras clases

Las clases deben agruparse en paquetes segn criterios de Arquitectura de Software

Se identifican los primeros candidatos para componentes

Las clases de anlisis son el primer paso hacia componentes ejecutables.

Clases de Anlisis: un primer paso hacia Ejecutables

Casos de Uso

Clases de Elementos Anlisis De Diseo

Codigo Fuente

Ejecutables

Anlisis de Casos de Uso

Qu es una Realizacin de Casos de Uso?

Una Realizacin de Casos de Uso (RCU) describe cmo un escenario de un CU es realizado por varios objetos colaborando entre si. Esto se representa con diagramas de secuencia, colaboracin y de clases. La definicion de una RCU se inicia con el Anlisis de Casos de Uso (para el Modelo de Anlisis) y se completa con el Diseo de Casos de Uso (para el Modelo de Diseo). El objetivo final de una RCU es especificar que clases deben ser construidas para implementar ese CU. En UML, una RCU se muestra como un valo con limite punteado, que esta asociado al caso de uso que realiza, con una flecha de linea punteada y cabeza cerrada.

Qu es una Realizacin de Casos de Uso?

Modelo de Caso de Uso Modelo Diseo

Caso de Uso XX

Realizacin de Caso de Uso XX

Diagrama de Secuencia

Diagrama de Colaboracin

Escenarios de Caso de Uso XX

Diagrama de Clases

Cmo se hace el Anlisis de Casos de Uso?

1. Los escenarios de CU se analizan para identificar los objetos y clases que participan en ellos (Captulo 7)

Se definen objetos y clases de entidad, limite y control Se crean diagramas de clases participantes (VOPC) para cada RCU

2. Los escenarios de CU se detallan grficamente en diagramas de interaccin para identificar las propiedades y responsabilidades de los objetos y clases (Captulos 8 y 9)

Se establece cuando y porque se comunican entre si los objetos y clases Se identifica que informacin contienen los mensajes que se envan entre si los objetos y clases En base a lo anterior, se definen y asignan propiedades (atributos) y responsabilidades (operaciones) a los objetos y clases
(contina)

Cmo se hace el Anlisis de Casos de Uso?

3. Se identifican y dibujan relaciones entre clases en los diagramas VOPC, para afinar y detallar la definicin de las clases participantes (Captulo 10)

Se identifican y representan todas las conexiones semnticas entre clases (incluyendo relaciones de asociacin, agregacin y generalizacin) Se incluyen como asociaciones todas las relaciones de colaboracin

4. Algunas clases con comportamiento especial se detallan en diagramas de estado para afinar la definicin de sus atributos y operaciones (Captulo 11) 5. Las clases resultantes se agrupan en paquetes tomando criterios de Arquitectura de Software para la definicin de componentes (Captulo 12)

Se crean diagramas de clases para cada paquete y diagramas de paquetes para indicar las dependencias entre estos

Anlisis de Casos de Uso

PASO 1:

Los escenarios de CU se analizan para identificar los objetos y clases que participan en ellos

Se definen objetos y clases de entidad, limite y control Se crean diagramas de clases participantes (VOPC) para cada Realizacin de Caso de Uso

Encontrando Clases en los Casos de Uso

El flujo completo de un caso de uso debe distribuirse en Clases de Anlisis
<<boundary>>

<<control>>

<<boundary>>

<<entity>>
<<entity>>

Como son las Clases de Anlisis?

Son clases estereotipadas segun la metodologa OOSE de Ivar Jacobson para crear modelos ideales de objetos Modelo
Esta metodologa se basa en el patron de anlisis MVC (Model-View-Controller), que define clases enfocadas a la separacin de responsabilidades para conseguir componentes extensibles y reutilizables.

<<entity>> Informacin del Sistema

<<boundary>>

Vista
Limites del Sistema

<<control>> Coordinacin del Flujo de los CU

Estereotipos (Stereotypes)
Un estereotipo, es un nuevo tipo de elemento de modelacin que extiende la semntica el meta modelo
Deben de estar basados en tipos existentes o clases del meta modelo

Es el mecanismo que el UML provee para extender la notacin Cada clase de anlisis debe tener un estereotipo Estereotipos comunes
Clase de lmite Clase de entidad Clase de control Clase de excepcin Clase de Utilera Meta clase

Los estereotipos se muestran en el compartimiento del nombre de la clase encerrado entre << >> (guillemets) o con un icono

Clase de Limite (Boundary)

Una clase de lmite, modela la comunicacin entre lo que rodea al sistema y su funcionamiento interno Clases de lmite tpicas
Pantallas o interfaces de usuario Reportes Interfaces programticos a otros sistemas

Ejemplo:
En el caso de uso Inscribirse en Cursos, se utiliza una pantalla de horario para que el estudiante ingrese las opciones de cursos
<<boundary>> PantallaDeHorario

PantallaDeHorario
PantallaDeHorario

Interfases con otros Sistemas

Una clase de lmite tambin se puede usar para modelar una interfase (API) con otro sistema Las caractersticas importantes de este tipo de clase de lmite son:

Las funciones que provee el otro sistema La informacin a ser pasada al otro sistema El protocolo de comunicacin usado para hablar con el otro sistema

Ejemplo:
En el caso CU Correr Proceso de Cierre hay informacin que debe ser enviada a un Sistema de Facturacin externo. Se puede crear una clase de limite llamada SistemaDeFacturacin para representar la interfase con el sistema externo.
<<boundary>> SistemaDeFacturacion

El Rol de una Clase Limite

<<boundary>>

<<control>> Actor <<boundary>> <<boundary>>

Actor

<<entity>>

<<entity>>

Modelar la interaccin entre el sistema y sus alrededores

Clase de Entidad (Entity)

Una clase de entidad corresponde a las abstracciones principales del Modelo Conceptual y modela la estructura y comportamiento asociado a una clase que generalmente es de larga duracin (persistente).
Puede reflejar un fenmeno de la vida real Su comportamiento es independiente de sus alrededores

Ejemplo:
Una de las clases de entidad en el CU Inscribirse en Cursos es Horario
<<entity >>

Horario

Horario
Horario

El Rol de una Clase de Entidad

<<boundary>>

<<control>> Customer <<boundary>> <<boundary>> Actor

<<entity>>

<<entity>>

Almacenar y administrar la informacin en el sistema

Clase de Control Una clase de control modela comportamiento de control o

Sirve como intermediario entre las clases de limite y las de entidad Controla la secuencia o la coordinacin de la ejecucin del flujo de eventos enviando mensajes a los objetos controlados Controla aspectos de concurrencia para las clases controladas Crea, modifica y elimina a los objetos controlados La mayora de las veces es la implementacin de un objeto intangible En el caso de uso Inscribirse en Cursos, hay una clase ControlInscripcin que coordina el CU
<<control>>

coordinacin del flujo de eventos asociado a uno o ms CU

Ejemplo:

ControlInscripcion

ControlInscripcion

ControlInscripcion

El Rol de una Clase de Control

<<boundary>>
<<control>>

Actor
<<boundary>>

<<boundary>>
Actor

<<entity>>

<<entity>>

Coordinar el comportamiento del caso de uso

Encontrando Objetos de Entidad

Los Objetos de Entidad se identifican examinando los sustantivos y frases de sustantivos en los escenarios Los sustantivos encontrados pueden ser:
Objetos especificos o genericos Descripciones del estado de un objeto Entidades externas y/o Actores Ninguno de los anteriores (frases fuera de contexto)

Filtrando Sustantivos
Cuando se identifican sustantivos tenga presente que
Varios trminos pueden referirse al mismo objeto Un trmino puede referirse a ms de un objeto El lenguaje natural es muy ambiguo

De esta manera se pueden identificar muchos objetos sin importancia

La lista de sustantivos se debe filtrar

Advertencia
Cualquier sustantivo puede ser convertido en verbo; cualquier verbo puede ser convertido en sustantivo Los resultados dependen en gran parte de la capacidad de redaccin de el o los autores

Revisando los Sustantivos

El siguiente requerimiento fue escrito para un sistema bancario Los requerimientos legales deben tomarse en cuenta. Si SOLO los sustantivos (o aparentes sustantivos) se consideran, qu suceder?

Cada sustantivo debe considerarse en el contexto del dominio no puede estar aislado

Escenario Inscribirse en Cursos Crear un Horario

Estela Gmez ya hizo el Caso de Uso Login y escoge las opciones Inscribirse en Cursos y Crear un Horario Nuevo. Estela consulta la lista de cursos disponibles y selecciona los cursos Ingls 101(seccin 66574), Geologa 110 (55342), Historia Mundial 200 (85463) y lgebra 110 (76453) como opciones primarias. Luego selecciona como opciones alternas Teora de la Msica 110 (44663) e Introduccin a la Programacin en Java 180 (35353). En la pantalla de horario vaca, Estela ingresa los cdigos de las opciones escogidas y somete el horario a validacin. El sistema determina que las opciones de Estela cumplen con todas las validaciones y aade a Estela a la lista de estudiantes inscritos de cada seccin indicada en el horario. El sistema presenta una copia lista para imprimirse del horario y Estela la imprime usando su browser. Termina el CU.

Los Sustantivos del Escenario del CU Inscribirse en Cursos Crear un Horario

Estela Gmez Caso de Uso opciones Cursos Horario Nuevo lista de cursos disponibles Ingls 101(seccin 66574) Geologa 110 (55342) Historia Mundial 200 (85463) lgebra 110 (76453) opciones primarias opciones alternas Teora de la Msica 110 (44663) Introduccin a la Programacin en Java 180 (35353) pantalla de horario Cdigos opciones escogidas horario Sistema validaciones lista de estudiantes inscritos seccin copia lista para imprimirse browser Qu sustantivos se deben filtrar?

Filtrando el Escenario Casos de Uso Inscribirse en Cursos Crear un Horario

Estela Gmez (actor) Caso de Uso (fuera de contexto) opciones (fuera de contexto) Cursos Horario Nuevo lista de cursos disponibles Ingls 101(seccin 66574) Geologa 110 (55342) Historia Mundial 200 (85463) lgebra 110 (76453) opciones primarias (atributos) opciones alternas (atributos) Teora de la Msica 110 (44663) Introduccin a la Programacin en Java 180 (35353) pantalla de horario (objeto limite) Cdigos (atributos) opciones escogidas (atributos) horario Sistema (fuera de contexto) validaciones (acciones) lista de estudiantes inscritos seccin copia lista para imprimirse (objeto limite) Browser (fuera de contexto)

Anlisis de Objetos Filtrados en Escenario de CU Inscribirse en Cursos Crear un Horario

Cursos Varios objetos curso Horario Nuevo Estado objeto horario lista de cursos disponibles Objeto genrico Ingls 101(seccin 66574) Instancia Objeto seccin Geologa 110 (55342) Instancia Objeto seccin Historia Mundial 200 (85463) Instancia Objeto seccin lgebra 110 (76453) Instancia Objeto seccin Teora de la Msica 110 (44663) Instancia Objeto seccin Introduccin a la Programacin en Java 180 (35353)Instancia Objeto seccin horario Objeto genrico lista de estudiantes inscritos Objeto genrico seccin Objeto genrico

Creando Clases de Entidad

Los objetos de entidad encontrados se agrupan en clases
Los objetos genricos representan clases Las instancias de objetos con estructura y/o comportamiento similar se agrupan en clases

Este es slo un intento inicial

Las clases pueden cambiar a medida que se examinan mas escenarios

Clases de Entidad identificadas en el Escenario de CU Inscribirse en Cursos Crear un Horario una materia ofrecida por la Curso universidad que es parte de un Plan de Estudios ListaDeCursosDisponibles lista de todos los cursos a ensear en un semestre lista de secciones de cursos Horario escogidas para un semestre por un estudiante ListaDeEstudiantesInscritos lista de estudiantes para una seccin curso ofrecido un curso ofrecido en un lugar y Seccin horario especficos

Encontrando Clases Lmite

Para cada par de actor fsico y escenario cree una clase de limite
Durante el diseo, esta clase se transformara dependiendo de los mecanismos de interfase escogidos

Aada mas clases de limite para modelar navegacin entre interfaces (por ejemplo pantallas) en el mismo caso de uso Ejemplo:
Al estudiante se le presentan diferentes opciones en el caso de uso Inscribirse en Cursos Se crea una clase de lmite llamada PantallaInscripcin para permitirle al estudiante seleccionar la opcin deseada El estudiante debe ingresar las secciones de los cursos escogidos al sistema en el escenario Crear un Horario Se crea una clase llamada PantallaHorario para recibir y procesar la informacin ingresada por el estudiante

Candidatos a Clase Lmite en Escenario Inscribirse en Cursos - Crear un Horario

<<boundary>> PantallaInscripcion

<<boundary>> PantallaHorario

Bosquejo de Pantalla
Se pueden crear storyboards, prototipos y bosquejos de pantallas para comunicar el look & feel de la clase lmite al usuario

Encontrando Clases de Control

Las clases de control contienen informacin de secuencia para coordinar los casos de uso En este nivel de anlisis, tpicamente se aade una clase control para cada caso de uso
Es responsable del flujo de eventos en el caso de uso

Las clases de control NO deben ejecutar funciones cuya responsabilidad pertenece a clases de entidad o de lmite Esto es slo un corte inicial
A medida que se desarrollan mas casos de uso y escenarios, las clases de control pueden eliminarse, dividirse o combinarse

Clase de Control para el Caso de Uso Inscribirse en Cursos Se aade una clase de control llamada ControlInscripcin Recibe informacin de la clase lmite PantallaHorario Para cada opcin ingresada
Valida que la seccin este abierta Valida que no existan conflictos de horario Valida que el curso est en el plan de estudio del estudiante Valida que los prerrequisitos se cumplan Asigna al Estudiante a la Seccin.
<<control>> ControlInscripcin

Diagramas de Clases en el Modelo de Analisis

Un diagrama de clases muestra una o mas clases en un mismo plano, usando la nomenclatura que se ha presentado antes. Cada Realizacin de Caso de Uso tiene uno o ms diagramas de clases que muestran las clases participantes en el CU y sus relaciones. Tales diagramas son llamados Vista de Clases Participantes (View of Participating Classes) lo que se resume como VOPC. Los VOPC inician muy sencillos y pueden llegar a ser muy detallados y complejos, por lo que se puede necesitar usar varios para cada RCU

Ejemplo de VOPC Registro Estudiantil

Este ejemplo muestra las clases participantes en el CU Inscribirse en Cursos

Estudiante
<<control>> ControlInscripcin

Inscribirse en Cursos
<<boundary>> PantallaInscripcion <<boundary>> PantallaHorario

<<entity>> Horario

<<entity>> Seccin

<<entity>> Curso

<<entity>> ListadoDeCursosDisponibles

<<entity>> ListaDeEstudiantesInscritos

Tarjetas Clase-Responsabilidad-Colaboracin
Las clases tambin se pueden descubrir usando tarjetas Clase-Responsabilidad-Colaboracin (CRC)
Fueron introducidas por Ward Cunningham y Kent Beck en OOPSLA en 1989

Una tarjeta CRC es una tarjeta de ndice de 3 x 5 que muestra.

El nombre y descripcin de la clase Las responsabilidades de la clase Conocimiento interno de la clase Servicios que brinda la clase Los colaboradores para las responsabilidades Un colaborador es una clase cuyos servicios son necesarios para cumplir con una responsabilidad

Tarjeta CRC para la Clase Seccin

Nombre de la Clase
Responsabilidades

Seccin
Colaboraciones
Estudiante, ListaDeEstudiantesInscritos

Servicio brindado

Aadir un estudiante
Asignar Profesor Conocer donde se dicta el curso Conocer cuando se dicta el curso

Profesor

Conocimiento Interno

Una sesin de Tarjetas CRC

Se escoge un grupo de personas para representar los roles de los objetos que participan en un escenario de CU Se crea una tarjeta para cada objeto del escenario A cada participante se le asigna un grupo de tarjetas que representan objetos similares
La persona se convierte en una clase

Los escenarios que se escojan deben ser desarrollados por los participantes como si se hiciera una representacion En las tarjetas se anotan las responsabilidades y colaboraciones que vayan surgiendo de la re[resentaciones de los escenarios Se crean tarjetas para cualquier objeto nuevo que se descubra

Beneficio de las Tarjetas CRC

Los patrones de colaboracin emergen a medida que ms y ms escenarios se completan Las tarjetas se pueden distribuir fsicamente para representar las colaboraciones estrechas

Esto puede ayudar a identificar las jerarquas de generalizacin o especializacin, y asociaciones de agregacin entre las clases (estos temas se desarrollan mas adelante)

Las tarjetas de CRC son ms efectivas para grupos nuevos en tcnicas de OO porque:

Previenen enfocarse en temas de Programacion OO Previenen la generalizacin Impulsan a pensar orientado a objetos

Cmo voy con las tarjetas CRC?

Las cosas van bien si...

Las cosas van mal si...

Todas las clases tienen nombres significativos y especficos del dominio Cada clase tiene un pequeo grupo de colaboradores No hay clases indispensables (una clase que colabora con todo necesita ser redefinida) La informacin de cada clase cabe bien dentro de una tarjeta de 3x5 Un cambio en los requerimientos puede ser bien manejado por las clases Existen clases sin responsabilidades Una misma responsabilidad se asigna a varias clases Todas las clases colaboran con todas las otras clases

Resumen: Modelo de Anlisis

El Modelo de Anlisis es el resultado del proceso de Anlisis El Modelo de Anlisis incluye un modelo Esttico y un modelo Dinmico del sistema Para desarrollar el Modelo de Anlisis debe hacerse Anlisis de Casos de Uso Con el Anlisis de Casos de Uso se inicia la Realizacin de Casos de Uso (RCU) El producto mas importante del Anlisis de Casos de Uso son las Clases de Anlisis
(contina)

Resumen: Modelo de Anlisis

Las Clases de Anlisis son el primer paso hacia la creacin de componentes ejecutables Las Clases de Anlisis son clases estereotipadas segn la metodologa OOSE de Ivar Jacobson El estereotipo representa un tipo de clase

Cada Clase de Anlisis debe tener un estereotipo

Estereotipos comunes: lmite, entidad, control, excepcin, meta clase y utilitario Una clase lmite modela la comunicacin entre lo que rodea al sistema y su funcionamiento interno
(contina)

Resumen: Modelo de Anlisis

Una clase de entidad modela la informacin y comportamiento asociado, que es de larga duracin (debe ser almacenada) Una clase de control modela comportamiento de coordinacin especifico a uno o ms casos de uso Para cada RCU deben hacerse uno o mas VOPC, o diagramas de clases participantes Un tcnica til para complementar el Anlisis de Casos de Uso es utilizar tarjetas CRC en sesiones de representacin de escenarios de CU

Ejercicio: Modelo de Anlisis

Usando el escenario de CU indicado por el instructor
Encuentre todas las clases de entidad Identifique las clases de limite y control Construya un VOPC

Captulo 8 Interaccin entre Objetos

Objetivos: Interaccin entre Objetos

Al final de este Captulo, usted podr:

Crear diagramas de secuencia y colaboracin para mostrar interacciones entre objetos Identificar, distribuir y asignar responsabilidades a clases, en funcin de las interacciones modeladas en los diagramas de secuencia y colaboracin

Anlisis de Casos de Uso

PASO 2:

Los escenarios de CU se detallan grficamente en diagramas de interaccin para identificar las propiedades y responsabilidades de los objetos y clases

Se establece cuando y porque se comunican entre si los objetos y clases Se identifica que informacin contienen los mensajes que se envan entre si los objetos y clases En base a lo anterior, se definen y asignan propiedades (atributos) y responsabilidades (operaciones) a los objetos y clases

Qu son diagramas de Interaccin?

Un diagrama de interaccin es una representacin grfica de las interacciones o intercambios de mensajes que deben darse entre los objetos participantes para completar un escenario de CU Existen 2 tipos de diagramas de interaccin
Diagramas de Secuencia Diagramas de Colaboracin

Cada uno provee una vista diferente de las mismas interacciones

Los diagramas de Secuencia se ordenan en el tiempo Los diagramas de Colaboracin muestran el flujo de datos

Qu es un Diagrama de Secuencia?
Un diagrama de secuencia sirve para modelar las interacciones entre objetos ordenadas en una secuencia en el tiempo Incluye:

Los objetos que participan en el escenario con sus lneas de vida Los mensajes intercambiados en una secuencia en el tiempo que representa el flujo de eventos del escenario El enfoque del control sobre los objetos (opcional)

Representando Objetos en Diagramas de Secuencia

Los objetos se dibujan como rectngulos con nombres subrayados (nombres en 3 diferentes formatos) Tambin se pueden representar los objetos con iconos segn su estereotipo Las lneas de vida de los objetos se muestran como lneas descendientes intermitentes y representan el tiempo en que los objetos estn instanciados
Objeto especifico
Ingles 101

Objeto especifico con clase

Ingles 101:Curso

Objeto generico
:Curso

Estereotipo

Ingles 101:Curso

Lineas de Vida

Mostrando la Interaccin entre Objetos

La interaccin se indica con flechas horizontales que van de la lnea de vida del objeto cliente (que inicia) a la del objeto suplidor (que recibe y responde) Las flechas horizontales se etiquetan con la frase que mejor represente el mensaje intercambiado, y a la etiqueta se le antepone // para indicar que se trata de un mensaje (es decir que todava se esta haciendo Anlisis) El orden de los mensajes en el tiempo, se indica por su posicin vertical; el primer mensaje es el que aparece ms arriba La numeracin es opcional ya que el orden se basa en la posicin vertical, pero puede utilizarse para hacer referencia a la numeracin jerrquica de los eventos tal como se describen en el Flujo Detallado del CU
:PantallaHorario :ControlInscripcion :ListaDeCursosDisponibles

// 2.2.1.3.2: buscar cursos // 2.2.1.3.3: buscar cursos

Evento.orden: mensaje

Qu es el Enfoque de Control (Focus Control)?

El Enfoque de Control representa el tiempo relativo durante el que el flujo del control se enfoca en un objeto
Representa el tiempo en que un objeto esta enviando mensajes y esperando y recibiendo respuestas

El Enfoque de Control se indica en un diagrama de secuencia dibujando un rectngulo sobre la lnea de vida del objeto en que esta enfocado el control
:PantallaHorario :ControlInscripcion :ListaDeCursosDisponibles

// 2.2.1.3.2: buscar cursos

// 2.2.1.3.3: buscar cursos

Enfoque de Control

Notas
Se pueden usar notas para aadirle ms informacin al diagrama cuando se quiere asegurar que se esta comunicando un detalle especifico o se quiere hacer una aclaracin cursos disponibles Se usa texto libre incluyen informacin de
secciones

:PantallaHorario

:ControlInscripcion

:ListaDeCursosDisponibles

// 2.2.1.3.2: buscar cursos // 2.2.1.3.3: buscar cursos

Scripts en Diagramas de Secuencia

Para escenarios complejos, los diagramas de secuencia pueden mejorarse mediante el uso de scripts Un script se escribe a la izquierda del diagrama de secuencia con los pasos del script alineados con las interacciones entre objetos Los scripts se pueden escribir en lenguaje natural o en seudo cdigo y son muy tiles para representar estructuras de control como ciclos o puntos de decisin en el flujo de eventos

Ejemplo de Script

: Estudiante

: PantallaDeHorario

: ControlInscripcion

: Seccion

: Curso

// 2.2.1.5 : Someter Horario a Validacion // 2.2.1.5.1 : Someter Horario a Validacion Hacer hasta 4 veces para las opciones primarias y 2 para las alternas Hacer hasta 4 veces solo para las opciones primarias Hacer hasta 4 veces para las opciones primarias y 2 para las alternas Hacer hasta 4 veces para las opciones primarias y 2 para las alternas // 2.2.1.5.2 : Validar que la seccin esta Abierta

// 2.2.1.5.3 : Validar que NO hay conflictos de horario

// 2.2.1.5.4: Validar que el curso es parte del plan de carrera apropiado

// 2.2.1.5.5 : Validar que se tienen todos los prerrequisitos

SCRIPT

Anatomia de un Diagrama de Secuencia

Objeto Cliente Objeto Servidor Numeracin Jerarquica de Mensajes

:Cliente

:Servidor

Lineas de Vida
2.2.1: Ejecutar Responsabilidad Este es un Script de Ejemplo

2.2.1.1: Ejecutar Otra Responsabilidad

Mensaje

Mensaje Reflexivo Enfoque de Control

Ejemplo - CU Login Escenario Estudiante

: Estudiante

: PantallaLogin

: ControlAcceso

: Usuario

: Estudiante

// 2.2: Login // 2.2.1 Presentar Pantalla de Login // 2.2.2: Ingresar identificacin (codigoUsuario, password) // 2.2.3: Validar Identificacin (codigoUsuario, password) // 2.2.3.1: Validar Identificacin (codigoUsuario, password): tipoUsuario // 2.2.3.2: Obtener Perfil Estudiante (codigoUsuario): Estudiante // 2.2.4: Mostrar mensaje de Bienvenida(carnet, nombreEstudiante)

Diagramas de Colaboracin
Un diagrama de colaboracin es una forma alternativa de representar mensajes intercambiados por un conjunto de objetos El diagrama muestra los objetos con enlaces entre ellos cuando hay una o mas interacciones. Tambin se muestran las interacciones o mensajes, dibujadas sobre los enlaces Un diagrama de colaboracin contiene
Objetos Enlaces entre objetos Mensajes intercambiados entre objetos Flujo de datos entre objetos, si existen

Representando Objetos en Diagramas de Colaboracin

Los objetos se dibujan igual que en los diagramas de secuencia, solo que sin lneas de vida: Como rectngulos con nombres subrayados (nombres en 3 diferentes formatos) o como con iconos segn su estereotipo Los enlaces indican que hay por lo menos una interaccin entre dos objetos y se representan con una lnea continua entre ellos
Objeto especfico Objeto genrico
Estela Gmez : Estudiante

Enlace

Objeto especfico con clase

Estela Gmez: Estudiante

Estela Gmez : Estudiante

: PantallaDeHorario

Anotaciones de Enlace
Un enlace de interaccin en un diagrama de colaboracin se le pueden hacer anotaciones con:
Una flecha apuntando del objeto cliente al objeto suplidor El nombre del mensaje con una lista opcional de parmetros y/o datos de valor de retorno Un nmero de secuencia opcional mostrando el orden relativo en el que los mensajes se envan
Mensaje Numero Secuencia 1: // 2.2.1.5 : Someter Horario a Validacion

: Estudiante

: PantallaDeHorario

Anatoma de un Diagrama de Colaboracin

Objeto Cliente Enlace
:Cliente
:Suplidor

Objeto Suplidor

1: EjecutaResponsabilidad

Mensaje

Ejemplo - CU Login Escenario Estudiante

2: // 2.2.1 Presentar Pantalla de Login 7: // 2.2.4: Mostrar mensaje de Bienvenida(carnet, nombreEstudiante) 1: // 2.2: Login 3: // 2.2.2: Ingresar identificacin (codigoUsuario, password)

: Estudiante 4: // 2.2.3: Validar Identificacin (codigoUsuario, password) : PantallaLogin

5: // 2.2.3.1: Validar Identificacin (codigoUsuario, password): tipoUsuario

: ControlAcceso 6: // 2.2.3.2: Obtener Perfil Estudiante (carnet): Estudiante

: Usuarios

: Estudiante

Diagramas de Secuencia vs. Diagramas de Colaboracin

Diagramas de Secuencia
Muestran la secuencia explicita de los mensajes en el tiempo Son mejores para visualizar el flujo general del escenario de CU Son mejores para modelar escenarios de tiempo real y escenarios muy conplejos

Diagramas de Colaboracin
Muestran las relaciones ademas de las interacciones Son mejores para visualizar patrones de colaboracion Son mejores para visualizar todos los efectos en un objeto dado

Un Diagrama de Interaccion NO es Suficiente

Flujo Basico FA3

Flujo Alterno 1

Flujo Alterno 2

Flujo Alterno 3

FA1 FA2 Flujo Alterno 4 Flujo Alterno 5 Flujo Alterno n

Describiendo Responsibilidades
Que son Responsabilidades?
Una responsabilidad es un enunciado o frase que describe algo que se puede solicitar a un objeto para que lo provea. Las responsabilidades se identifican en el Analisis de CU y evolucionan en una o mas operaciones de clases en el Modelo de Analisis. Se pueden caracterizar asi: Las acciones que un objeto puede realizar El conocimiento que un objeto mantiene de si mismo y provee a otros objetos Las responsibilidades son derivadas de los mensajes en los diagramas de interaccion. Para cada mensaje, debe examinarse la clase a la que este se envia, y si no existe una responsabilidad que cumpla con lo que requiere el mensaje, esta se debe crear. En los VOPCs y diagramas de clases del modelo de Analisis, debe indicarse que una responsabilidad es tal anteponiendo // a su nombre, al igual que como se hace con los mensajes en los diagramas de interaccion.

Describiendo Responsibilidades
Como se encuentran las responsabilidades?
Diagrama de Interaccion
:Cliente // ejecutarResponsabilidad :Suplidor

Diagrama de Clases
Suplidor // ejecutarResponsabilidad

Guia para Asignar Responsabilidades a Clases

Usar los estereotipos de las clases de analisis
Clases de Limite Comportamiento que implica comunicacion con un actor Clases de Entidad Comportamiento asociado a informacion encapsulada en la abstraccion Clases de Control Comportamiento asociado a un CU especifico, o a un flujo de eventos muy importante

(contina)

Guia para Asignar Responsabilidades a Clases

Quien tiene los datos necesarios para completar una responsabilidad?
Si una clase tiene los datos, asignar la responsabilidad a esta clase (junto a los datos) Si varias clases tienen los datos:
Asignar la responsabilidad a una clase (la que tiene mas datos, mayor jerarquia o es el agregado) y relacionar esta clase con las otras Crear una nueva clase y asignarle la responsabilidad. Luego crear relaciones entre esta clase y todas las que necesita para cumplir con la responsabilidad. Asignar la responsabilidad a la clase de control y agregar relaciones entre esta y las clases necesarias para cumplir con la responsabilidad

Resumen: Interaccin entre Objetos

La interaccin entre objetos se puede representar grficamente con un diagrama de secuencia que muestra la existencia de objetos y las interacciones entre los objetos identificados
Los objetos se representan con rectngulos con nombres subrayados La lnea de vida se representa con una lnea intermitente vertical que desciende del objeto Los mensajes se indican con flechas horizontales que se dirigen del objeto cliente (emisor) al objeto suplidor (receptor) Las flechas horizontales se etiquetan con el nombre del mensaje Un script opcional se puede aadir para agregar ms detalle al diagrama

Resumen: Interaccin entre Objetos

Un diagrama de colaboracin es una representacin alterna de interacciones entre objetos
Los objetos se representan con rectngulos con nombres subrayados Una enlace de interaccin (lnea) se dibuja entre los objetos que se comunican
El enlace es una flecha con el nombre del mensaje que apunta desde el objeto cliente hacia el objeto suplidor El enlace tambin puede tener una flecha que indica datos que se le devuelven al objeto

Ejercicio: Interaccin entre Objetos

Usando el escenario de CU indicado por el instructor
Cree un diagrama de secuencia Genere un diagrama de colaboracion a partir del diagrama de secuencia