Casos de Uso

COMPORTAMIENTO DEL SISTEMA: CASOS DE USO

Objetivos: Comportamiento del Sistema

Al terminar este Capítulo, usted podrá:Definir el comportamiento del sistema en términos de casos de usoDefinir casos de uso y actoresCrear un diagrama de caso de uso para mostrar los actores, el caso de uso y la forma en que interactúanDefinir escenarios para los casos de usoEntender la manera de documentar casos de uso

¿Qué es Comportamiento del Sistema?Comportamiento del Sistema Es como el sistema actúa y reacciona a estímulos 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 usoLos casos de uso describen al sistema, su ambiente y las relaciones entre el sistema y su ambiente

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 sistemaEs la base del proceso de desarrollo e impulsa el análisis, diseño, implementación y pruebas del sistema

El propósito 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

requerimientosFacilita la comunicación con los usuarios finales y expertos del dominio• Proporciona aceptación desde las primeras etapas de desarrollo

del sistema

El Modelo de Casos de Uso

Conceptos Importantes en Modelación de Casos de Uso

Un actor representa cualquier cosa que interactúa con el sistema

Caso de Uso

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

ActoresLos actores no son parte del sistema, ellos representan roles que pueden jugar usuarios del sistemaUn actor puede intercambiar información activamente con el sistemaUn actor puede ser un receptor pasivo de informaciónUn actor puede representar a un ser humano, una máquina o a otro sistema

Actor

Identificando Actores: preguntas útiles ¿Quién está interesado en cierto requerimiento? ¿Dónde se usa el sistema en la organización? ¿Quién suplirá al sistema de información, quien usa y

elimina esta información? ¿Quién usará esta función? ¿Quién dará soporte y mantenimiento al sistema? ¿El sistema usa un recurso externo? ¿Qué actores necesitan los casos de uso? ¿Algún actor interpreta varios roles diferentes? ¿Existen varios actores con el mismo rol?

Instancias de Actores

Inserte su Tarjeta

1 2 34 5 67 8 9* 0 #

Ivar representa al actor “Cliente”

Tom representa al actor ”Cliente”

Modelo de casos de uso

Hacer TransacciónBancariaCliente

Un Usuario puede Actuar como Diferentes Actores

Carlos como “Cliente”

Carlos como “Técnico”

Cliente

TécnicoMantenimiento

Inserte su Tarjeta

1 2 34 5 67 8 9* 0 #

Actores y Fronteras del Sistema

¿Frontera del

Sistema?

Sistema Cajeros Automáticos

Sistema Bancario

Cajero deVentanilla


Casos de UsoUn Caso de Uso modela un diálogo entre actores y el sistemaUn CU inicia cuando un actor invoca cierta funcionalidad del sistemaUn CU es un flujo completo y significativo de eventosTomados juntos, los casos de uso constituyen todas las formas posibles del uso del sistema

Caso de Uso

Identificando Casos de Uso: preguntas útiles ¿Cuáles son las tareas de este actor? ¿El actor creará, guardará, cambiará, eliminará o leerá

información del sistema? ¿Con qué caso de uso se creará, guardará, cambiará, eliminará o

leerá esta información? ¿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 darán soporte y mantenimiento al sistema? ¿Pueden los casos de uso ejecutar todos los requerimientos

funcionales?

Asociaciones: Interacciones entre Actores y Casos de Uso

Una asociación implica comunicación

• La asociación se representa con una linea con punta de flecha

• Esta linea entre el actor y el caso de uso indica que ellos interactúan enviando mensajes uno al otro

• Para cada mensaje enviado se asume una respuesta

• La dirección de la flecha indica quien envio el primer mensaje

Sistema Bancario

Hacer Cierre de Caja

Hacer Transacción Para Cliente

Cajero deVentanilla

Hacer RetiroDe Ahorros o Cheques?

AhorrosQue Cuenta?

Cuenta XXXXXXX


Cliente

Realiza Transacción Bancaria

Mantiene el Cajero Automático

Ejecuta ReportesDe Control

Banco

Ejemplo de Diagrama Casos de Uso

Fuentes de información para Casos de Uso

Especificaciones del sistema / formulación del problema (Documento Visión en RUP)Literatura y documentación relevante al dominioEntrevistas con los expertos del dominioConocimiento personal del dominioSistemas anteriores

Documentación de Casos De Uso Los casos de uso se documentan con:

Una Descripción Breve que establece el propósito del caso de uso en pocas líneas

Un Flujo de Eventos detallado La documentación debe poderse leer como un diálogo

entre el actor y el caso de uso La documentación se redacta en términos que el cliente

pueda entender (usando el lenguaje del dominio)

Flujo de Eventos de Casos de UsoCada caso de uso: Tiene una secuencia básica (flujo básico) de eventos Puede tener varias secuencias secundarias (flujos alternos) de

eventos Usualmente tiene una o mas secuencias de eventos de excepción

(flujos de excepción) para manejar errores También puede tener pre-condiciones y post-condiciones bien

definidas

Flujo de Eventos de Casos de Uso Un Flujo Básico (“Happy Day Path”) Varios Flujos Alternos

Variantes del Flujo Básico Casos Especiales

Flujos de Excepción (para manejar situaciones de error)

Guía para Hacer el Flujo de Eventos

El flujo de eventos debe describir Cómo y cuándo el caso de uso comienza y termina En que momento el caso de uso interactúa con los actores Qué información se intercambia entre el actor y el caso de uso (no describa los detalles de la interfase con el usuario) El flujo de eventos básico Cualquier flujo de eventos alterno

Describir sólo los eventos que pertenecen al caso de uso Evite terminología vaga como “por ejemplo”, “información” y “etc.”

Una asociación 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 comùnes son <<uses>> y <<extends>>• <<uses>> implica que un CU utiliza el flujo funcional de otro CU como

parte de su flujo basico. A esta asociación tambien se le conoce como <<includes>>

• <<extends>> implica que un CU extiende el flujo basico de otro CU resultando en un flujo alterno

Asociaciones Especiales: Interacciones entre CU

Hacer DepositoDe Cheques

Cajero deVentanilla Imprimir Estado

De Cuenta

Consultar CuentaDe Cheques

<<uses>>

<<extends>>

¿Quién lee la documentación de los Casos de Uso?Los clientes – aprueban lo que el sistema debe hacerUsuarios – aumentan su comprensión del sistemaDesarrolladores del Sistema – documentan el comportamiento del sistemaRevisores – examinan el flujo de eventosAnalistas de Sistemas (Diseñadores del Sistema) – proveen la base para el análisis y el diseñoProbador del Sistema – la usa como base para los casos de pruebaLíder de Proyecto – proporciona información para planear proyectosEscritor Técnico – es la base para escribir la guía del usuario

Ejemplo – Registro Estudiantil

Descripción del Problema Al principio de cada semestre, se llevara a cabo un Proceso de

Registro que durará 3 días. Durante este proceso, los estudiantes deberán asignarse los cursos que llevaran durante el semestre.

El primer día se dará orientación y registro a los estudiantes de primer año.Todos los demás estudiantes podrán registrarse a partir del segundo día. El tercer día se utilizará además 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 implícitas 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.

(continúa)

El sistema debe incluir un control de acceso que permita que los usuarios ingresen con un código de identificación y un password, los cuales serán 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, según el tipo de usuario que sea. También debe validar que solo los estudiantes de primer año puedan entrar el primer día del proceso de registro.

El sistema debe proveer una lista de cursos disponibles para el semestre, en donde los estudiantes puedan consultar la información que necesiten de cada curso para tomar decisiones. Esto incluye el nombre, descripción, créditos y prerrequisitos del curso, así como información 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 están abiertas, cerradas (llenas) o si fueron canceladas.

Cada sección puede tener como máximo 20 estudiantes y al llegar a esa cifra el sistema debe cerrarla y actualizar la lista de cursos disponibles para que la sección refleje esto en su estado.

(continúa)


Para inscribirse en los cursos que deben llevar, los estudiantes tendrán 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 opción, los estudiantes deben usar un numero de sección (que es único, e implícitamente hace referencia al curso).Si una sección de un curso tiene menos de 3 estudiantes cuando se cierre el proceso de registro, esta será cancelada. También puede ser cancelada en cualquier momento por causas de fuerza mayor.Los estudiantes también podrán modificar o eliminar su horario y el sistema debe llevar control en línea del total de estudiantes por sección, para reabrirla si el total baja de 20 estudiantes.El sistema debe validar cada vez que se crea o modifica un horario, que cada opción cumple con los prerrequisitos necesarios, según el historial académico del estudiante. También debe validar que la opción 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).

(continúa)


Los estudiantes también podrán incluirse en una lista de solicitantes para nuevas secciones, en caso de que quieran asignarse un curso cuyas secciones ya estén llenas. Esta lista estará adjunta a cada curso en la lista de cursos disponibles y será revisada en el tercer día, pero esto no garantiza que se abrirá una nueva sección. Si se abre una nueva sección, los estudiantes en la lista serán notificados por correo electrónico 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 sección o secciones que mas les convengan de los cursos para los que estén autorizados. Deben asignarse entre 9 y 15 horas semanales de clase (esto debe ser validado por el sistema en línea). El sistema debe también detectar si hay conflictos de horario o de autorización en las selecciones del profesor.Los profesores también necesitarán consultar cuantos y cuales estudiantes se han inscrito en sus secciones. Esta función la usaran durante el semestre para asignar calificaciones a los estudiantes.

(continúa)


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 sección para esos cursos. También 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 estén inscritos en cursos cancelados (por cualquier razón) serán reasignados automáticamente a otros cursos/secciones, según sus opciones alternas.También en el cierre, se cierran todas las secciones que todavía estén 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 envía la información de cobros (créditos por estudiante) al sistema externo de facturación para que al estudiante se le pueda cobrar por el semestre, según su horario.



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 aplicación para ambientes WEB.

El nuevo sistema en una parte de la aplicación que debe sustituir al sistema actual de la Oficina de Registro, que se considera inflexible y ya no se puede mantener. La especificación anterior solo cubre la parte mas critica de la funcionalidad deseada, y el resto se deberá suplir después en un proyecto de extensión del sistema.

Sin embargo, los datos base necesarios para lograr la funcionalidad deseada están completos y actualizados en la base de datos de sistema actual. Estos datos incluyen la información personal e historial académico de los estudiantes, información de profesores, cursos (incluyendo no solo los disponibles, sino todos los que estan en los planes de estudio) y secciones.

(continúa)

Ejemplo – Registro Estudiantil Lo anterior significa que el proyecto debe incluir la actividad de

migración de datos, para minimizar el ingreso y traslado de información por otros medios, y porque se desea utilizar un RDBMS para manejar y almacenar la información 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 Guías de Usuario a los estudiantes y profesores, para indicarles como deben usar el sistema. Sin embargo se prevé que habrán muchos usuarios que no dispongan de esas guías, por lo que debe estar disponible en línea, 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.

Actores

Estudiante

Encargadodel Registro

Profesor

Sistemade Facturación


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 secciónes Consultar notas de cursos

Profesor Escoger cursos a dictar Consultar lista de estudiantes asignados Asignar notas a estudiantes

(continúa)


Los Actores se examinan para determinar sus necesidades Encargado del Registro

Lanzar reporte de solicitantes para nuevas secciónes Abrir nuevas secciones Cancelar secciones existentes Correr cierre del Proceso de Registro

Sistema de Facturación Recibir la información de cobros del registro

Casos de UsoEjemplo – Registro Estudiantil

Diagramas de Casos de Uso

Consultar ListaDe Cursos

Estudiante

Solicitar AperturaDe Nuevas Secciones

Inscribirse enCursos

Login

<<uses>>

<<uses>>

ConsultarCalificaciones



Profesor

Escoger CursosA Dictar

Asignar Calificaciones

Login

Revisar Lista De Estudiantes

<<extends>>



Encargadodel Registro

Sistema deFacturación

Lanzar ReporteSolicitudes

Nuevas Secciones

Correr Proceso de Cierre

Login

Abrir Nueva Sección

CerrarSección


Nombre del CU: Inscribirse en Cursos1 Descripción Breve

A través de este caso de uso, el sistema le permite al estudiante crear, modificar y eliminar el horario de cursos para el semestre actual. También le permite generar un versión “para impresión” del horario.

2 Flujo de Eventos2.1 Pre-Condiciones

El estudiante debe haber completado el caso de uso “Login”.

(continúa)

Documentación de Casos De UsoEjemplo – Registro Estudiantil

2.2 Flujo Principal2.2.1 “Crear un Horario Nuevo”

2.2.1.1 El estudiante escoge la opción “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.

Documentación de Casos De Uso

(continúa)


2.2.1.3 El sistema muestra una pantalla de horario vacía y la lista de cursos disponibles para que el usuario pueda consultarla.

2.2.1.4 El estudiante ingresa 4 números de sección (E-1) como opciones principales y 2 números de sección (E-1) como opciones alternas.

2.2.1.5 El estudiante somete a validación su horario. Para cada opción ingresada el sistema verifica que

• La sección 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 opción que cumpla las validaciones, el sistema añade al estudiante a la sección 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.

(continúa)


2.3 Flujos Alternos2.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 números de sección (E-1) como opciones principales y 2 números de sección (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 Horario2.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.

(continúa)


2.3.2.2 Si el estudiante confirma la eliminación, sigue el caso de uso, y para cada opción principal del horario, el sistema elimina al estudiante del curso y sección escogidos, y actualiza el los totales correspondientes. Termina el CU.

2.3.3 Imprimir Horario2.3.1.1 El sistema muestra una pantalla con el horario “listo para

imprimir” (printer friendly) e instrucciones de cómo imprimirlo usando la funcionalidad del browser.

2.3.1.2 Si el estudiante confirma la impresión, sigue el caso de uso y el horario se envía a imprimir (E-6).Termina el CU.

2.4 Flujos de ExcepciónE-1 El número de sección no es válido (por formato o porque

no existe). El estudiante puede volver a digitar un número válido o terminar el caso de uso.

(continúa)


E-2 El curso/sección escogido esta cerrado. Se le informa al estudiante que no se puede incluir esa sección en su horario y porqué. El caso de uso continua.

E-3 Hay conflictos de horario con otra sección. Se le informa al estudiante que no se puede incluir ese curso/sección en su horario y por qué. El CU continua.

E-4 El estudiante no cumple con los prerrequisitos. Se le informa al estudiante que no se puede incluir ese curso/sección en su horario y por qué. El CU continua.

E-5 El curso/sección no esta en el plan de estudios de estudiante. Se le informa al estudiante que no se puede incluir ese curso/sección en su horario y por qué. El CU continua.

E-6 El horario no se puede imprimir. La información se guarda y se le informa al usuario que debe volver a pedir una impresión de su horario. El CU continua.

(continúa)


¿Qué son escenarios?Un escenario es una instancia de un caso de uso Es un flujo a través 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 Gómez 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

Inglés 101(sección 66574), Geología 110 (55342), Historia Mundial 200 (85463) y Álgebra 110 (76453) como opciones primarias. Luego selecciona como opciones alternas Teoría de la Música 110 (44663) e Introducción a la Programación en Java 180 (35353).

• En la pantalla de horario vacía, Estela ingresa los códigos de las opciones escogidas y somete el horario a validación.

• El sistema determina que las opciones de Estela cumplen con todas las validaciones y añade a Estela a la lista de estudiantes inscritos de cada sección 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 SecundariosAlgunos 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.

¿Cuántos escenarios son necesarios?

Respuesta sencilla: tantos como uno necesite para entender el sistema a desarrollarRecomendación Escenarios primarios

• Elabore aproximadamente 80% de estos escenarios Escenarios secundarios

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

Resumen: Comportamiento del SistemaEl comportamiento del sistema es como el sistema actúa y reaccionaEl comportamiento de un sistema se puede definir con un modelo de casos de usoUn caso de uso es algo de funcionalidad ejecutada por el sistema en respuesta a un estimulo de un actor externo Proporcionan el vehículo 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 desarrollaUn diagrama de casos de uso es una descripción gráfica del sistema que muestra a los actores y los casos de uso identificados para este sistemaLa documentación de los casos de uso consiste en una breve descripción 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 definición para cada actor Para un caso de uso• Escriba una breve descripción (máximo 2 frases)• Escriba el flujo de eventos• Liste algunos posibles escenarios

Clases y Objetos

Objetivos: Clases y Objetos

Al final de este Capítulo, usted podrá: Describir los principios básicos de

orientación a objetos Definir y dar ejemplos de objetos Definir y dar ejemplos de clases Describir la relación entre clases y objetos Definir y crear el Modelo Conceptual de un

sistema usando un diagrama de clases

Orientación a Objetos

Enca

psul

ació

n

Abst

racc

ión

Jera

rqui

a

Mod

ular

idad

Principios Básicos de Orientación a Objetos

Cliente VendedorProducto

La Abstracción Minimiza la Complejidad

¿Qué es Abstracción?Es la capacidad de conceptualizar entidades genéricas de información a partir de cosas concretas• Se enfatizan características comunes que interesan• Se ignoran otras características

Sistema de Procesamiento

de Ordenes

¿Qué es Encapsulación?

La Encapsulación Esconde la Complejidad

Es la capacidad de esconder los detalles de como funciona una cosa (la implementación), 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

Marca C

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

Principio de OO:Encapsulación

Marca AMarca B

Sistema de Procesamiento de

ÓrdenesCobros

Facturación

Envio de Órdenes

La Modularidad Administra la Complejidad

¿Qué es Modularidad?

Es la capacidad de particionar algo complejo y dificil de manejar, en partes mas sencillas y fáciles de manejar

Los elementos al mismo nivel de jerarquía deben estar al mismo nivel de abstracción

¿Qué es Jerarquía? La capacidad de manejar niveles de abstracción

Menos Abstracto

Más Abstracto Activo

Bienes RaícesCuenta Bancaria Valores

Ahorros Cheques Acciones Bonos Casas Edificios

La Jeraquia Organiza la Complejidad

¿Qué es Herencia? Es la capacidad de los elementos de una jerarquía, de transmitir sus características desde los niveles mas abstractos a los mas concretos

Activo

Ahorros Cheques Acciones Bonos Casas Edificios

Bienes RaícesCuenta Bancaria Valores

Valor

Valor Valor Valor

Valor Valor Valor Valor Valor Valor

Numero Cuenta

Numero Cuenta Numero Cuenta

Emisor

Emisor Emisor

Ubicacion

Ubicacion Ubicacion

¿Qué es un Objeto?

• Entidad física

Informalmente, un objeto representa a una entidad, ya sea física, conceptual o software

• Entidad conceptual

• Entidad de SoftwareLista Enlazada

Proceso Químico

Camión

Una Definición más Formal

Un objeto es un concepto, abstracción o cosa con fronteras definidas y con sentido para una aplicación

Un objeto es algo que tiene: Estado Comportamiento Identidad

Un Objeto tiene EstadoEl estado de un objeto es una de las posibles condiciones en que un objeto puede existirEl estado de un objeto normalmente cambia con el tiempoEl estado de un objeto es usualmente implementado por un conjunto de propiedades llamadas atributos, mas los enlaces que el objeto pueda tener con otros objetosEl estado lo establecen los valores de los atributos y enlaces

Nombre:Id Empleado:Contratación:

Puesto:Profesora Clark

=(a/) Joyce Clark432245601/06/1995Profesora Titular

Un Objeto tiene ComportamientoEl comportamiento determina como un objeto actúa y reaccionaEl comportamiento define la manera en la que un objeto responde a las peticiones de otros objetosEl comportamiento visible de un objeto se modela con un conjunto de mensajes a los que el puede responderLos mensajes se implementan como las operaciones del objeto

Profesora ClarkOficial de Registro Jimenez

Asignar a Profesora Clark a dar Calculo Integral 332

(Devuelve: confirmación)

Un Objeto tiene IdentidadCada objeto tiene una identidad única, aun si su estado en un momento dado, es idéntico al de otros objetos

Profesor “J. Pérez”Enseña Matemáticas



Joyce Clark

Solo Nombre del Objeto

Representando Objetos con UMLExisten varios tipos de diagramas de UML que deben incluir objetos; un objeto se representa con un rectangulo que contiene el nombre del objeto, subrayadoEl nombre del objeto puede representarse en tres formatos distintos dependiendo de si se quiere hacer referencia a un objeto “específico” (usualmente al modelar un escenario de CU) o a un objeto “generico”

* Pronto se definira lo que es Clase

Joyce Clark:Profesor

Nombres de Clase* y Objeto

ProfesoraJoyce Clark

=(a/)Objeto Específico

:Profesor

Solo Nombre de Clase*Objeto Genérico

¿Qué son Clases?Cuando se han identificado muchos objetos en un dominio, decimos que una clase es una abstracción que describe un grupo de objetos que tienen:• propiedades en común (atributos)• comportamiento en común (operaciones)• relaciones comunes con otros objetos (asociaciones) • semántica en común (descripción breve)

Una clase es una abstracción porque:• enfatiza características relevantes al sistema• suprime otras características

La Relación entre Clases y ObjetosUna clase en una definición 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

Estudiante

Clase

A. Pineda G. RodríguezE. Gomez

ClaseSeccion

=(a/)

Estructura

Nombre Aula

CréditosDías

Hora de InicioHora Final

Comportamiento

Añadir un Estudiante Eliminar un Estudiante

Ver si está lleno

Ejemplo de Clase

Clases y Objetos

¿Cuántas clases ve usted?

El Modelo ConceptualEs el primer modelo de clases que se debe hacer y reúne 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 Descripción del Problema y en

entrevistas con los expertos del dominio• Se usa como una base de entendimiento y cooperación con los

expertos de dominio y / o clientes• No debe incluir los detalles de las clases, solo debe identificarlas

Incluye:• Un Diccionario del Modelo• Uno o mas Diagramas de Clases (normalmente solo uno)

Guía para encontrar ClasesUna clase debe capturar una y solo una abstracción principal

Mala abstracción: clase Estudiante que incluye el horario del estudiante para el semestreBuenas abstracciones: clases separadas para Estudiante y Horario

:Horario

• Inglés 101 (66574)• Geología 110 (55342)• Historia Mundial 200 (85463) • Álgebra 110 (76453)

Estela Gomez

Nombrando las ClasesEl nombre de una clase, debe ser el sustantivo singular que mejor caracteriza la abstracción que se quiere representar con esa claseEl que haya dificultad para nombrar una clase, puede ser indicio de que la abstracción que esta representa no se entiende bien o no esta bien definidaLos 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 documentación misma del dominio (que existe aparte del la que se ha creado durante el proyecto; eje. guías de operación, manuales de procedimientos, etc)

• Los principales términos, siglas, apodos, etc. del vocabulario del dominio, deben definirse e incluirse en la documentación del proyecto (en el RUP se llama a esto el Documento de Glosario)

Guía de Estilo para Nombrar ClasesEl proyecto debe contar con una guía de estilo que dicte convenciones y / o estándares para dar y presentar los nombres de las clases• Proporciona consistencia al proyecto• Resulta en modelos y código fuente más fácil de mantener

Muestra de una Guía de Estilo• Las clases se nombran con sustantivos en singular• Los nombre de clases comienzan con mayúscula• El carácter 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 mayúscula

Ejemplos: Estudiante, Profesor, PlanDeEstudios

Definir la Semántica de la Clase

Luego de nombrar la clase, debe hacerse una descripción breve y concisa de la clase (Definición de Trabajo o Working Definition) Enfóquese en el propósito de la clase, no en la implementaciónEl nombre de la clase y la descripción forman la base de un Diccionario del Modelo

Busque los “QUES” e ignore los “COMOS”

Muestra del Diccionario del Modelo

Nombre: Estudiante• Definición de Trabajo: Información 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

Nombre: Curso• Definición de Trabajo: Una materia ofrecida por la Universidad,

que es parte de un Plan de Estudios

Mientras más del problema se descubre, deben afinarse las definiciones de las clases conocidas y

debe agregarse cualquier clase nueva al diccionario.

Representando Clases con UMLLas 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 específicaEn UML, el icono que se utiliza para representar una clase es un rectángulo que contiene el nombre de la clase y opcionalmente 3 compartimientos

Profesor

Profesor

Profesora Joyce Clark

=(a/)o

Compartimientos de las ClasesUna clase se puede representar con 3 compartimentos o secciones La primera sección contiene el nombre de la clase La segunda sección muestra la estructura o propiedades (atributos) La tercera sección 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

Profesor

crear()guardar()eliminar()cambiar()

ProfesornombreIdentificación

crear()guardar()eliminar()cambiar()

Profesor

nombreidentificación

Profesor

Perspectiva en los Diagramas de ClasesLos 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 Diseño. Las clases aquí son muy concretas pues deben incluir toda la informacion de cómo 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)


Diagrama de Clases para el Modelo Conceptual

Curso

Estudiante ProfesorHorario Seccion

PlanDeEstudios

ListadoDeCursosDisponibles

ListaDeSolicitantesParaNuevasSecciones

EncargadoDelRegistro

Semestre

Resumen: Clases y ObjetosUna 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 actúa y reacciona a

peticiones de otros objetos Cada objeto tiene una identidad única – aún si su estado es idéntico al

de otro objetoUna clase es una definición abstracta de un conjunto de objetos que comparten una estructura y comportamiento en comúnA las clases se les debe dar un nombre que mejor caracterice la abstracción que representan

(continúa)

El Modelo Conceptual es el primer modelo de clases que debe hacerse como parte del A&DOO• Reúne 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 cooperaciónLas clases se representan en UML con un rectángulo 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)

Resumen: Clases y Objetos

Ejercicio: Clases y Objetos

Usando el problema indicado por el instructor Dibuje un diagrama de clases que represente el

Modelo Conceptual Escriba una definición para cada Clase

Capítulo 7Modelo de Análisis

Objetivos: Modelo de AnálisisAl final de este Capítulo, usted podrá:

Definir el Modelo de AnálisisUtilizar el análisis de casos de uso para crear un Modelo de AnálisisEncontrar objetos y clases realizando análisis de casos de uso (Clases de Análisis)Definir y usar los estereotipos básicos de clasesUsar tarjetas CRC para descubrir clases

El Modelo de AnálisisEs el resultado del proceso de AnálisisRepresenta la conceptualización del Dominio del ProblemaPara construirlo se hace el “Análisis de Casos de Uso"• Se toma como base el “Modelo de Casos de Uso” y el “Modelo

Conceptual” de clases• Se usa la documentación disponible (descripción 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

(continúa)

El Modelo de AnálisisPuede también agruparse en 2 partes o vistas:

• El “Modelo Estático”, que representa la estructura del modelo de análisis e incluye:

• Diagramas de Clases• Diagramas de Paquetes

• El “Modelo Dinámico”, que muestra las interacciones y responsabilidades que se manejan en el sistema e incluye:

• Diagramas de Interacción• Secuencia• Colaboración

• Diagramas de Estado

Análisisde Casos

de Uso

Modelo de Análisis(Estatico)

Criterios deArquitectura

Modelo de Casos de Uso

Escenarios

Modelo Conceptual

Diccionario

Diagramas Secuencia

Diagramas Colaboracion

Modelo de Análisis (Dinamico)

Contruyendo el Modelo de Análisis

Entrevistas

DescripcionDel Problema

EspecificacionesSuplementarias

Documentación

¿Qué es el Análisis de Casos de Uso?Es la primera etapa para crear las “Realizaciones de Casos de Uso”El análisis 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 Análisis)Para estas clases deben identificarse:• Su estructura (propiedades)• Su comportamiento (responsabilidades)• Sus relaciones con otras clases

Las clases deben agruparse en paquetes según criterios de Arquitectura de Software• Se identifican los primeros candidatos para componentes

Las clases de análisis son el primer paso hacia componentes ejecutables.

Casos de Uso

Clases deAnálisis

CodigoFuente EjecutablesElementos

De Diseño

Análisis de Casos de Uso

Clases de Análisis: un primer paso hacia Ejecutables

¿Qué es una Realización de Casos de Uso?Una Realización de Casos de Uso (RCU) describe cómo un escenario de un CU es realizado por varios objetos colaborando entre si. Esto se representa con diagramas de secuencia, colaboración y de clases.La definicion de una RCU se inicia con el Análisis de Casos de Uso (para el Modelo de Análisis) y se completa con el Diseño de Casos de Uso (para el Modelo de Diseño).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.

Diagrama de Clases

Diagrama de Secuencia

Diagrama de Colaboración

Escenarios de Caso de Uso XX

Modelo de Caso de Uso Modelo Diseño

Realización de Caso de Uso XX

¿Qué es una Realización de Casos de Uso?

Caso de Uso XX

¿Cómo se hace el Análisis de Casos de Uso?1. Los escenarios de CU se analizan para identificar los

objetos y clases que participan en ellos (Capítulo 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 gráficamente en diagramas de interacción para identificar las propiedades y responsabilidades de los objetos y clases (Capítulos 8 y 9)• Se establece cuando y porque se comunican entre si los objetos y

clases• Se identifica que información contienen los mensajes que se envían

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(continúa)

¿Cómo se hace el Análisis de Casos de Uso?3. Se identifican y dibujan relaciones entre clases en los

diagramas VOPC, para afinar y detallar la definición de las clases participantes (Capítulo 10)• Se identifican y representan todas las conexiones semánticas entre

clases (incluyendo relaciones de asociación, agregación y generalización)

• Se incluyen como asociaciones todas las relaciones de colaboración4. Algunas clases con comportamiento especial se detallan en

diagramas de estado para afinar la definición de sus atributos y operaciones (Capítulo 11)

5. Las clases resultantes se agrupan en paquetes tomando criterios de Arquitectura de Software para la definición de componentes (Capítulo 12)• Se crean diagramas de clases para cada paquete y diagramas de

paquetes para indicar las dependencias entre estos


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 Realización de Caso de Uso

<<boundary>>

<<boundary>><<control>>

<<entity>>

<<entity>>

Encontrando Clases en los Casos de UsoEl flujo completo de un caso de uso debe distribuirse en Clases de Análisis

Limites del Sistema

<<control>>

<<boundary>>

<<entity>>

Coordinación del Flujo de

los CU

Información del Sistema

¿Como son las Clases de Análisis?Son clases estereotipadas segun la metodología OOSE de Ivar Jacobson para crear modelos ideales de objetos

• Esta metodología se basa en el patron de análisis MVC (Model-View-Controller), que define clases enfocadas a la separación de responsabilidades para conseguir componentes extensibles y reutilizables.

Modelo

ControlVista

Estereotipos (Stereotypes)Un estereotipo, es un nuevo tipo de elemento de modelación que extiende la semántica 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 notaciónCada clase de análisis debe tener un estereotipoEstereotipos comunes Clase de límite Clase de entidad Clase de control Clase de excepción Clase de Utilería 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 límite, modela la comunicación entre lo que rodea al sistema y su funcionamiento internoClases de límite típicas Pantallas o interfaces de usuario Reportes Interfaces programáticos 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

PantallaDeHorario<<boundary>>

PantallaDeHorarioPantallaDeHorario

Interfases con otros SistemasUna clase de límite también se puede usar para modelar una interfase (API) con otro sistemaLas características importantes de este tipo de clase de límite son:• Las funciones que provee el otro sistema• La información a ser pasada al otro sistema• El “protocolo” de comunicación usado para “hablar” con el otro sistema

Ejemplo: En el caso CU “Correr Proceso de Cierre” hay información que debe ser enviada a un Sistema de Facturación externo. Se puede crear una clase de limite llamada SistemaDeFacturación para representar la interfase con el sistema externo.

SistemaDeFacturacion<<boundary>>

Modelar la interacción entre el sistema y sus alrededores

Actor

<<boundary>>

<<boundary>>

<<control>><<boundary>>

<<entity>> <<entity>>

El Rol de una Clase Limite

Actor

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 duración (persistente).• Puede reflejar un fenómeno 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

Horario<<entity>>

Horario

Horario

Almacenar y administrar la información en el sistema

Customer

<<boundary>>

<<boundary>>

<<control>>

<<boundary>>


El Rol de una Clase de Entidad

Actor

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

coordinación del flujo de eventos asociado a uno o más CU• Sirve como intermediario entre las clases de limite y las de entidad• Controla la secuencia o la coordinación de la ejecución 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 mayoría de las veces es la implementación de un objeto intangible

Ejemplo: En el caso de uso “Inscribirse en Cursos”, hay una clase ControlInscripción que coordina el CU

ControlInscripcion<<control>>

ControlInscripcionControlInscripcion

El Rol de una Clase de Control

Coordinar el comportamiento del caso de uso

Actor

<<boundary>>

<<boundary>>

<<control>><<boundary>>


Actor

Encontrando Objetos de Entidad

Los Objetos de Entidad se identifican examinando los sustantivos y frases de sustantivos en los escenariosLos 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 SustantivosCuando se identifican sustantivos tenga presente que Varios términos pueden referirse al mismo objeto Un término puede referirse a más 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 redacción 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 Gómez 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

Inglés 101(sección 66574), Geología 110 (55342), Historia Mundial 200 (85463) y Álgebra 110 (76453) como opciones primarias. Luego selecciona como opciones alternas Teoría de la Música 110 (44663) e Introducción a la Programación en Java 180 (35353).

• En la pantalla de horario vacía, Estela ingresa los códigos de las opciones escogidas y somete el horario a validación.

• El sistema determina que las opciones de Estela cumplen con todas las validaciones y añade a Estela a la lista de estudiantes inscritos de cada sección 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 Gómez • Caso de Uso • opciones • Cursos • Horario Nuevo• lista de cursos disponibles • Inglés 101(sección 66574) • Geología 110 (55342)• Historia Mundial 200 (85463)• Álgebra 110 (76453)• opciones primarias • opciones alternas • Teoría de la Música 110 (44663)

• Introducción a la Programación en Java 180 (35353)

• pantalla de horario• Códigos• opciones escogidas• horario • Sistema• validaciones• lista de estudiantes inscritos • sección• copia “lista para imprimirse”• browser

¿Qué sustantivos se deben filtrar?

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

Estela Gómez (actor)Caso de Uso (fuera de contexto)opciones (fuera de contexto)• Cursos• Horario Nuevo • lista de cursos disponibles • Inglés 101(sección 66574) • Geología 110 (55342)• Historia Mundial 200 (85463)• Álgebra 110 (76453)opciones primarias (atributos)opciones alternas (atributos)• Teoría de la Música 110 (44663)

• Introducción a la Programación en Java 180 (35353)

pantalla de horario (objeto limite)Códigos (atributos)opciones escogidas (atributos)• horario Sistema (fuera de contexto)validaciones (acciones)• lista de estudiantes inscritos• sección copia “lista para imprimirse”

(objeto limite)Browser (fuera de contexto)

Análisis de Objetos Filtrados en Escenario de CU“Inscribirse en Cursos – Crear un Horario”

• Cursos• Horario Nuevo• lista de cursos disponibles • Inglés 101(sección 66574) • Geología 110 (55342)• Historia Mundial 200 (85463)• Álgebra 110 (76453)• Teoría de la Música 110 (44663)• Introducción a la Programación en Java 180 (35353)• horario • lista de estudiantes inscritos• sección

Varios objetos cursoEstado objeto horarioObjeto genéricoInstancia Objeto secciónInstancia Objeto secciónInstancia Objeto secciónInstancia Objeto sección Instancia Objeto secciónInstancia Objeto secciónObjeto genéricoObjeto genéricoObjeto genérico

Creando Clases de Entidad

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

se agrupan en clases

Este es sólo 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”

Curso una materia ofrecida por la universidad que es parte de un Plan de Estudios

ListaDeCursosDisponibles lista de todos los cursos a enseñar en un semestre

Horario lista de secciones de cursos escogidas para un semestre por un estudiante

ListaDeEstudiantesInscritos lista de estudiantes para una sección curso ofrecido

Sección un curso ofrecido en un lugar y horario específicos

Encontrando Clases LímitePara cada par de actor físico y escenario cree una clase de limite Durante el diseño, esta clase se transformara dependiendo de los

mecanismos de interfase escogidosAñada mas clases de limite para modelar navegación entre interfaces (por ejemplo pantallas) en el mismo caso de usoEjemplo: Al estudiante se le presentan diferentes opciones en el caso de uso

“Inscribirse en Cursos”Se crea una clase de límite llamada PantallaInscripción para

permitirle al estudiante seleccionar la opción 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

información ingresada por el estudiante

Candidatos a Clase Límite en Escenario “Inscribirse en Cursos - Crear un Horario”

<<boundary>>

PantallaHorario

<<boundary>>

PantallaInscripcion

Bosquejo de PantallaSe pueden crear “storyboards”, prototipos y bosquejos de pantallas para comunicar el “look & feel” de la clase límite al usuario

Encontrando Clases de ControlLas clases de control contienen información de secuencia para coordinar los casos de usoEn este nivel de análisis, típicamente se añade 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 límiteEsto es sólo 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 añade una clase de control llamada ControlInscripción Recibe información de la clase límite PantallaHorario Para cada opción ingresada

• Valida que la sección 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 Sección.

<<control>>

ControlInscripción

Diagramas de Clases en el Modelo de AnalisisUn diagrama de clases muestra una o mas clases en un mismo plano, usando la nomenclatura que se ha presentado antes. Cada Realización de Caso de Uso tiene uno o más 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

<<entity>> Curso

<<entity>>Horario

<<entity>> Sección

<<entity>> ListadoDeCursosDisponibles

<<entity>> ListaDeEstudiantesInscritos

<<control>>ControlInscripción

<<boundary>>PantallaHorario

<<boundary>>PantallaInscripcion

Estudiante

Inscribirse enCursos

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

Tarjetas Clase-Responsabilidad-ColaboraciónLas clases también se pueden descubrir usando tarjetas Clase-Responsabilidad-Colaboración (CRC) Fueron introducidas por Ward Cunningham y Kent Beck en

OOPSLA en 1989Una tarjeta CRC es una tarjeta de índice de 3 x 5 que muestra. El nombre y descripción 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 Sección

Responsabilidades Colaboraciones

Nombre de la Clase Sección

Añadir un estudiante

Conocer cuando se dicta el curso

Asignar Profesor

Estudiante,ListaDeEstudiantesInscritos

Conocer donde se dicta el curso

Servicio brindado

Conocimiento Interno

Profesor

Una sesión de Tarjetas CRCSe escoge un grupo de personas para representar los roles de los objetos que participan en un escenario de CUSe crea una tarjeta para cada objeto del escenarioA 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 escenariosSe crean tarjetas para cualquier objeto nuevo que se descubra

Beneficio de las Tarjetas CRCLos patrones de colaboración emergen a medida que más y más escenarios se completanLas tarjetas se pueden distribuir físicamente para representar las colaboraciones estrechas Esto puede ayudar a identificar las jerarquías de generalización o

especialización, y asociaciones de agregación entre las clases (estos temas se desarrollan mas adelante)

Las tarjetas de CRC son más efectivas para grupos nuevos en técnicas de OO porque: Previenen enfocarse en temas de Programacion OO Previenen la generalización Impulsan a “pensar orientado a objetos”

¿Cómo voy con las tarjetas CRC?Las cosas van bien si... Todas las clases tienen nombres significativos y específicos del

dominio Cada clase tiene un pequeño grupo de colaboradores No hay clases “indispensables” (una clase que colabora con todo

necesita ser redefinida) La información de cada clase cabe bien dentro de una tarjeta de 3x5” Un cambio en los requerimientos puede ser bien manejado por las

clasesLas cosas van mal si... Existen clases sin responsabilidades Una misma responsabilidad se asigna a varias clases Todas las clases colaboran con todas las otras clases

Resumen: Modelo de AnálisisEl Modelo de Análisis es el resultado del proceso de AnálisisEl Modelo de Análisis incluye un modelo Estático y un modelo Dinámico del sistemaPara desarrollar el Modelo de Análisis debe hacerse “Análisis de Casos de Uso”Con el Análisis de Casos de Uso se inicia la Realización de Casos de Uso (RCU)El producto mas importante del Análisis de Casos de Uso son las Clases de Análisis

(continúa)

Resumen: Modelo de AnálisisLas Clases de Análisis son el primer paso hacia la creación de componentes ejecutablesLas Clases de Análisis son clases estereotipadas según la metodología OOSE de Ivar JacobsonEl estereotipo representa un tipo de clase• Cada Clase de Análisis debe tener un estereotipo

Estereotipos comunes: límite, entidad, control, excepción, meta clase y utilitarioUna clase límite modela la comunicación entre lo que rodea al sistema y su funcionamiento interno

(continúa)

Resumen: Modelo de AnálisisUna clase de entidad modela la información y comportamiento asociado, que es de larga duración (debe ser almacenada)Una clase de control modela comportamiento de coordinación especifico a uno o más casos de usoPara cada RCU deben hacerse uno o mas VOPC, o diagramas de clases participantesUn técnica útil para complementar el Análisis de Casos de Uso es utilizar tarjetas CRC en sesiones de representación de escenarios de CU

Ejercicio: Modelo de Análisis

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

Capítulo 8Interacción entre Objetos

Objetivos: Interacción entre Objetos

Al final de este Capítulo, usted podrá:• Crear diagramas de secuencia y colaboración para

mostrar interacciones entre objetos• Identificar, distribuir y asignar responsabilidades a

clases, en función de las interacciones modeladas en los diagramas de secuencia y colaboración


PASO 2: Los escenarios de CU se detallan gráficamente

en diagramas de interacción 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 información contienen los mensajes que

se envían 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 Interacción?Un diagrama de interacción es una representación gráfica de las interacciones o intercambios de mensajes que deben darse entre los objetos participantes para completar un escenario de CUExisten 2 tipos de diagramas de interacción Diagramas de Secuencia Diagramas de Colaboración

Cada uno provee una vista diferente de las mismas interacciones

• Los diagramas de Secuencia se ordenan en el tiempo• Los diagramas de Colaboración 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 tiempoIncluye:• Los objetos que participan en el escenario con sus

“líneas 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 rectángulos con nombres subrayados (nombres en 3 diferentes formatos)También se pueden representar los objetos con iconos según su estereotipoLas “líneas de vida” de los objetos se muestran como líneas descendientes intermitentes y representan el tiempo en que los objetos están instanciados

Ingles 101Ingles 101:Curso

:Curso

Objeto especificoObjeto especifico con clase

Objeto generico

Lineas de Vida

Ingles 101:Curso

Estereotipo

Mostrando la Interacción entre ObjetosLa interacción se indica con flechas horizontales que van de la línea 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 todavía se esta haciendo Análisis)El orden de los mensajes en el tiempo, se indica por su posición vertical; el primer mensaje es el que aparece más arribaLa numeración es opcional ya que el orden se basa en la posición vertical, pero puede utilizarse para hacer referencia a la numeración jerárquica de los eventos tal como se describen en el Flujo Detallado del CU

:ListaDeCursosDisponibles:ControlInscripcion:PantallaHorario

Evento.orden: mensaje

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

¿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 respuestasEl Enfoque de Control se indica en un diagrama de secuencia dibujando un rectángulo sobre la línea de vida del objeto en que esta enfocado el control



Enfoque de Control

NotasSe pueden usar notas para añadirle más información al diagrama cuando se quiere asegurar que se esta comunicando un detalle especifico o se quiere hacer una aclaraciónSe usa texto libre



cursos disponibles incluyen información de secciones

Scripts en Diagramas de SecuenciaPara escenarios complejos, los diagramas de secuencia pueden mejorarse mediante el uso de scriptsUn script se escribe a la izquierda del diagrama de secuencia con los pasos del script alineados con las interacciones entre objetosLos scripts se pueden escribir en lenguaje natural o en seudo código y son muy útiles para representar estructuras de control como ciclos o puntos de decisión 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

// 2.2.1.5.2 : Validar que la sección esta Abierta

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

// 2.2.1.5.3 : Validar que NO hay conflictos de horario

// 2.2.1.5.5 : Validar que se tienen todos los prerrequisitos

Hacer hasta 4 vecespara las opciones primarias y 2 para

las alternas

Hacer hasta 4 veces solo para las opciones primarias


las alternas


las alternas

SCRIPT

Anatomia de un Diagrama de Secuencia

2.2.1: Ejecutar Responsabilidad

Objeto Cliente Objeto Servidor

Mensaje

:Cliente :Servidor

Enfoque de Control

Este es un Script de Ejemplo

Mensaje Reflexivo

Lineas de Vida

2.2.1.1: Ejecutar Otra Responsabilidad

Numeración Jerarquica

de Mensajes

: Estudiante : PantallaLogin : ControlAcceso : Usuario : Estudiante

// 2.2: Login

// 2.2.1 Presentar Pantalla de Login

// 2.2.2: Ingresar identificación (codigoUsuario, password)

// 2.2.3: Validar Identificación (codigoUsuario, password)

// 2.2.3.1: Validar Identificación (codigoUsuario, password): tipoUsuario

// 2.2.3.2: Obtener Perfil Estudiante (codigoUsuario): Estudiante

// 2.2.4: Mostrar mensaje de Bienvenida(carnet, nombreEstudiante)

Ejemplo - CU “Login” – Escenario “Estudiante”

Diagramas de ColaboraciónUn diagrama de colaboración es una forma alternativa de representar mensajes intercambiados por un conjunto de objetosEl diagrama muestra los objetos con enlaces entre ellos cuando hay una o mas interacciones. También se muestran las interacciones o mensajes, dibujadas sobre los enlacesUn diagrama de colaboración contiene Objetos Enlaces entre objetos Mensajes intercambiados entre objetos Flujo de datos entre objetos, si existen

Representando Objetos en Diagramas de ColaboraciónLos objetos se dibujan igual que en los diagramas de secuencia, solo que sin “líneas de vida”:• Como rectángulos con nombres subrayados (nombres en 3

diferentes formatos) o como con iconos según su estereotipoLos enlaces indican que hay por lo menos una interacción entre dos objetos y se representan con una línea continua entre ellos

Estela Gómez

Objeto específico

Estela Gómez: Estudiante

Objeto específico con clase

: Estudiante

Objeto genérico

Estela Gómez : Estudiante

: PantallaDeHorario

Enlace

Anotaciones de EnlaceUn enlace de interacción en un diagrama de colaboración se le pueden hacer anotaciones con: Una flecha apuntando del objeto cliente al objeto suplidor El nombre del mensaje con una lista opcional de parámetros y/o

datos de valor de retorno Un número de secuencia opcional mostrando el orden relativo en

el que los mensajes se envían

: Estudiante : PantallaDeHorario

1: // 2.2.1.5 : Someter Horario a ValidacionNumeroSecuencia

Mensaje

1: EjecutaResponsabilidad

Objeto Cliente

Objeto Suplidor

Mensaje

Enlace

:Cliente

:Suplidor

Anatomía de un Diagrama de Colaboración

Ejemplo - CU “Login” – Escenario “Estudiante”

: Estudiante

: PantallaLogin

: ControlAcceso

: Usuarios

: Estudiante

1: // 2.2: Login

2: // 2.2.1 Presentar Pantalla de Login

3: // 2.2.2: Ingresar identificación (codigoUsuario, password)

4: // 2.2.3: Validar Identificación (codigoUsuario, password)

5: // 2.2.3.1: Validar Identificación (codigoUsuario, password): tipoUsuario

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

7: // 2.2.4: Mostrar mensaje de Bienvenida(carnet, nombreEstudiante)

Diagramas de Secuencia vs. Diagramas de Colaboración

Diagramas de Colaboración • 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

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

FA3Flujo Alterno 1

FA1

FA2

Flujo Basico

Un Diagrama de Interaccion NO es Suficiente

Flujo Alterno 2 Flujo Alterno 3

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.

// ejecutarResponsabilidad

:Cliente :Suplidor

Suplidor

// ejecutarResponsabilidad

Diagrama de Interaccion

Diagrama de Clases

¿Como se encuentran las responsabilidades?Describiendo Responsibilidades

Guia para Asignar Responsabilidades a ClasesUsar 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

(continúa)

¿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

Guia para Asignar Responsabilidades a Clases

Resumen: Interacción entre ObjetosLa interacción entre objetos se puede representar gráficamente con un diagrama de secuencia que muestra la existencia de objetos y las interacciones entre los objetos identificados Los objetos se representan con rectángulos con nombres

subrayados La “línea de vida” se representa con una línea 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 añadir para agregar más detalle al

diagrama

Un diagrama de colaboración es una representación alterna de interacciones entre objetos Los objetos se representan con rectángulos con nombres

subrayados Una enlace de interacción (línea) 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 también puede tener una flecha que indica datos que se le

devuelven al objeto

Resumen: Interacción entre Objetos

Ejercicio: Interacción 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

Casos de Uso

Documents

Transcript of Casos de Uso