Curso Uml Caso Estudio Terry Quatrani

1 www.dsic.upv.es/~uml

Caso de Estudio Guiado usandoUML y Rational Rose

Pedro Sánchez PalmaPatricio Letelier Torres

{ppalma, letelier}@dsic.upv.es

Departamento Sistemas Informáticos y ComputaciónUniversidad Politécnica de Valencia (España)


Descripción del ejemploGestión de Cursos UPV

� Se asignan profesores a cursos.

� Los estudiantes se registran en los cursos.

� Los profesores deciden qué cursos dar el próximo semestre.

� La oficina de registro introduce la información en el sistema.

� Se imprime un informe para los profesores indicando qué cursos y cuándo.


Descripción del ejemplo

� Se imprime un catálogo por curso programado y se entrega a los estudiantes.

� Los estudiantes se apuntan a los cursos.� La oficina de registro introduce los

formularios con los cursos solicitados.� Un proceso batch asignará estudiantes a

cursos.� Cuando exista conflicto en la asignación la

oficina de registro informará a los estudiantes las opciones disponibles.


Descripción del ejemplo

� Tras el periodo de inscripción los profesores reciben la lista de estudiantes apuntados a cada curso que van a impartir.

Riesgos� La capacidad de almacenamiento y acceso

a la información curricular de manera eficiente.

� El desarrollo de prototipos permitirá deducir que el riesgo puede ser mitigado.


Registro de los cursos

� Al principio del semestre los estudiantes reciben la información de los cursos, profesores, departamentos, prerrequisitos, etc.

� El estudiante incluirá dos alternativas por si un curso está lleno o se cancela.

� Un curso se cancela si no alcanza un mínimo de 3 alumnos.

� El máximo de alumnos por curso es de 10.


Registro de los cursos

� Los profesores deben poder acceder a la información de los cursos.

� Durante un periodo de tiempo fijado los estudiantes pueden cambiarse o borrarse de los cursos.


Actores

� La identificación de actores no suelen ser inmediata sino más bien iterada.

� Una misma persona física puede usar el sistema de dos formas distintas apareciendo entonces como dos actores diferentes.

� Examinamos los diferentes actores y documentamos cómo usan el sistema.


Actores

� Actores:

• Los estudiantes desean apuntarse a los cursos.• Los profesores quieren seleccionar cursos para

impartirlos.• El secretario debe crear el catálogo del semestre.• El secretario debe mantener toda la información

sobre los cursos, profesores y estudiantes.• El sistema de faturación debe recibir la facturación

generada.


Creación de actores en RS

� Introduzca los actores anteriores en Rational Rose.

� Introduzca las descripciones:• Estudiante: Una persona que se matricula para

recibir clases en la Universidad.• Profesor: Una persona acreditada para dar clases

en la universidad.• Secretario: Una persona responsable del

mantenimiento de la información de los cursos.• Sistema de Facturación: Sistema externo

responsable de la facturación a los estudiantes.


Casos de Uso

� Registrarse en los cursos.� Seleccionar los cursos a impartir.� Solicitar lista de apuntados a un curso.� Mantener información de un curso.� Mantener información de un profesor.� Mantener información de un

estudiante.� Crear un catálogo de curso.


Creación de Casos de Uso

� Cree los distintos casos de uso.� Añada una breve descripción de cada

caso de uso.


Flujo de eventos para cada caso de uso

� El flujo de eventos de un caso de uso es una descripción de los eventos que necesita para llevar a cabo el comportamiento descrito en el caso de uso.

� Escrito en términos del qué y no del cómo.� Debe incluir:

• Cuándo y cómo empieza o acaba el CU.• Interacción con actores.• Datos que necesita el CU.• Secuencia normal de eventos para el CU.• Descripción de cualquier flujo alternativo o excepcional.


Flujo de eventos para cada caso de uso

� Normalmente se crea en la fase de elaboración de manera iterativa.

� Debería seguir una plantilla tal como:X Flujo de eventos para el caso de uso <nombre>X.1 PrecondicionesX.2 Flujo principalX.3 SubflujosX.4 Flujos alternativos

siendo X un iterador para cada caso de uso


Flujo de eventos para el CU “seleccionar cursos a impartir”

1.0 Flujo de eventos del CU “seleccionar curso a impartir”

1.1 PrecondicionesEl subflujo “Crear oferta de cursos” del caso de uso “Mantener

información de un curso” debe ejecutarse antes.

1.2 Flujo principalEste CU empieza cuando el profesor se conecta al sistema e

introduce su password. El sistema verifica su password (E-1) y le solicita seleccione un curso del semestre actual o futuro (E-2). El profesor introduce el semestre. El sistems entonces solicita la actividad deseada: ADD, DELETE, REVIEW, PRINT o QUIT.



Si la actividad es ADD se hace el subflujo S-1 “Añadir curso”

Si la actividad es DELETE se hace el subflujo S-2 “Borrar curso”

Si la actividad es REVIEW se hace el subflujo S-3 “Revisar planificación”

Si la actividad es PRINT se hace el subflujo S-4 “Imprimir planificación”

Si la actividad es QUIT el caso de uso termina.

1.3 SubflujosS-1: Añadir curso.

El sistema muestra la pantalla de cursos con dos campos (nombre y número). El profesor introduce ambos campos (E-3). El sistema muestra los datos del curso seleccionado (E-4).



El sistema enlace profesor y curso (E-5). El caso de uso comienza de nuevo.

S-2: Borrar un curso.

El sistema muestra la oferta de cursos y el profesor introduce el nombre y número de un curso (E-6). El sistema deshace la relación entre el profesor y el curso (E-7). El caso de uso empieza de nuevo.

S-3: Revisar una planificación

El sistema obtiene (E-8) y muestra la información: nombre del curso, número, días de la semana, hora y lugar. Cuando el profesor indica que la revisión ha terminado el CU empiza de nuevo.



S-4: Imprimir una planificaciónEl sistema imprime la planificación de los cursos para el

profesor (E-9). El caso de uso comienza.

1.4 Flujos alternativosE-1: El identificador de profesor no es válido. El usuario puede

intentarlo de nuevo o salir.E-2: El código de semestre no es valido. Repetir o salir.E-3: Número/nombre de curso no válido. Repetir o salir.E-4: La oferta de cursos no puede mostrarse. Se informa al

usuario de que la información no está disponible. El caso de uso comienza.

E-5: No se puede crear el enlace profesor-curso. Se guarda la información para crear el enlace posteriormente. El caso de uso continúa.



E-6: Nombre/número de curso no válidos. Reintentar o salir.

E-7: No se puede borrar el enlace. Se salva la información para reintentarlo más tarde. El caso de uso continúa.

E-8: El sistema no puede extraer la información para la planificación. El caso de uso comienza.

E-9: La planificación no puede imprimirse. El caso de uso comienza.

Esta información se mantiene aparte y se enlaza porteriormente con Rational Rose.


Flujo de eventos

� Establezca un enlace entre el caso de uso “seleccionar curso a impartir” y el fichero anterior de flujo de eventos.


Relaciones en los casos de uso

� Las relaciones de asociación entre el actor y el caso de uso puede ser bidireccionalmente navegable o en una sóla dirección.

� Entre casos de uso tenemos el incluye y el extiende.

� Por ejemplo, todos los casos de uso anteriores empiezan con la verificación del acceso (es decir, “lo incluyen”).


Relaciones en los casos de uso

� La relación “extiende” se usa para:• Comportamiento opcional.• Comportamiento que se lleva a cabo bajo ciertas

circunstancias.• Diferentes flujos que se ejecutan en función de la

selección del actor.


Creación del diagrama de CU principal

� Incorpore al diagrama cada uno de los actores involucrados.

� Incorpore al diagrama cada uno de los casos de uso involucrados (arrastrando el CU).

� Establezca la comunicación entre actores y casos de uso (unidireccional o bidireccional con la asociación).

� Podemos establecer el estereotipo <<se comunica con>>



� Incorpore al diagrama las relaciones de uso.



Estudiante

seleccionar cursos a impartir

Profesor

crear lista de cursos

mantener inf estudiante

crear catalogo cursomantener inf curso

Secretario

mantener inf profesor

registrarse en cursos

S. Facturación

<<se comunica con>>

Valida usuario

<<usa>>

<<usa>>


Creación de Clases

� Considerando que análisis y diseño son procesos iterativos es incrementales, la identificación de las clases cambiará con el tiempo.

� Las clases entidad modelan información y comportamiento que perdura en el tiempo. Suelen ser clases del mundo real o bien internas al sistema. Suelen poder usarse en varias aplicaciones (son aplicación-independientes).


Creación de Clases

� Las clases entorno manejan la comunicación entre la frontera del sistema y el interior del sistema. Proporcionan un interface a usuarios o a otros sistemas. Documentan los interfaces.

� En la fase de elaboración estas clases entorno no se detallan apenas.


Creación de Clases

� Las clases control modelan conducta secuencial específica a uno o más casos de uso. Coordinan los eventos necesarios para llevar a cabo el caso de uso.

� En la fase de elaboración se suele incluir una clase control para cada par actor/caso de uso.


Clases en RS

� Cree la clase “InformaciónEstudiante” y asocie el estereotipo <<entidad>>, y la siguiente documentación:

Información necesaria para registrar y facturar a los estudiantes. Un estudiante es alguien que es registrado para ir a clases a la universidad.

� Haga lo mismo para la clase “InformacionProfesor”.


Paquetes en RS

� Cree el paquete “InformacionPersonas”.

� Reubique las clases InformaciónEstudiante e InformaciónProfesor en el paquete creado.


Clases del escenario “añadir oferta de curso para enseñar”

� El escenario “añadir oferta de curso para enseñar” es uno de los subflujos del caso de uso “seleccionar cursos a impartir”.

� Este caso de uso interacciona sólo con el actor profesor.

� Es necesaria una clase (de entorno) que ofrezca todas las posibilidades del caso de uso (la clase OpcionesCursoProfesor).

� Identificamos también la clase (de entorno) AñadirOfertaCurso para este escenario.



� Identificamos tres clases tipo entidad: Curso, OfertaCurso e InformacionProfesor.

� Identificamos una clase tipo control para manejar el flujo de eventos para el caso de uso (la clase GestorCursosProfesor).



� Las clases de entorno las ubicamos en el paquete que creemos llamado Interfaces.

� Las clases entidades las ubicamos en el paquete llamado Universidad.


Diagrama de clases principal

� Hacer doble-click en el diagrama de clases principal del logical-view y añadir los paquetes creados.

Interfaces

Universidad InformacionPersonas


Diagrama de clases principal

� Hacer doble-click en el paquete Universidad e incluir las clases Cursos y GestorCursosProfesor.

� Añadir en el paquete Interfaces las dos clases de entorno indicadas.

� Los diagramas de clases también pueden añadirse en la vista de casos de uso y suelen corresponder a clases que participan en el caso de uso.


Diagrama de clases caso de uso

� Situado sobre el caso de uso “seleccionar cursos a impartir” crear un diagrama de clases que se llame igual en el que se incluyan las clases participantes: OpcionesCursoProfesor, AñadirOfertaCurso, Cursos, InformacionProfesor, GestorCursosProfesor y OfertaCursos.


Diagrama de clases caso de uso

� A cada clase especificar el estereotipo correspondiente (entorno, control o entidad).

OfertaCursos(from Universidad)

<<entidad>>

InformacionProfesor(from InformacionPersonas)

<<entidad>>

GestorCursosProfesor(from Universidad)

<<control>>

OpcionesCursoProfesor(from Interfaces)

<<entorno>>

Cursos(from Universidad)

<<entidad>>

AñadirOfertaCurso(from Interfaces)

<<entorno>>


Diagramas de secuencia

� Asociar un diagrama de secuencia para el escenario “Crear Catálogo Curso” (cree autom. el de colaboración):

: Secretario

Formulario Curso

El gestor UnCurso : Cursos

fija info curso

procesar

añadir curso

nuevo curso


Diagramas de secuencia

Cree el diagrama de secuencia para el escenario “Añadir Curso”:

: Profesor : OpcionesCurs

oProfesordisplay ofertas :

AñadirOfertaCurso : GestorCursos

ProfesorMatemáticas :

Cursos : OfertaCursos

1: introduce passw ord

2: verif ica passw ord

3: introduce semestre

4: añadir una oferta

5: display

6: select matemáticas7: obtener oferta(cursos)

8: obtener oferta(curso)9: obtener oferta

11: selecciona ofertas

10:

12: f ijar oferta(informacionProfesor, OfertaCurso)

13: añadir oferta(InformaciónProfesor, OfertaCurso)


Especificando relaciones

� En el diagrama de clases de Universidad establecer una asociación entre las clases cursos y GestorCursosProfesor.

� Indicar la agregación existente entre cursos y OfertaCursos.

OfertaCursos

AñadirProfesor()

<<entidad>>

Cursosnombredescripcioncreditoshoras

<<entidad>>

1 1..*1 1..*

0..*0..* 0..*prerrequisitos0..*

GestorCursosProfesor<<control>>

1..*0..* 1..*0..*

maneja1


Roles en relaciones

� Cree en el paquete Personas un diagrama de clases en el que incluya a OfertaCursos e InformaciónProfesor con una asociación entre ellos.

� Especificar que existe un rol llamado InformaciónProfesor en el diagrama de clases de Personas y entre las clases OfertaCursos y InformaciónProfesor.


Roles en relaciones

� Considere la cardinalidad siguiente para la asociación anterior:

1 profesor puede dar hasta 4 cursos1 curso sólo lo da un profesor

InformacionProfesor<<entidad>>OfertaCursos

AñadirProfesor()

<<entidad>>

10..4

+InformaciónProfesor

10..4


Relaciones reflexivas

� Considere que un curso está relacionado consigo mismo con el rol prerrequisito y con cardinalidad 0..* en ambos lados.


Analizando relaciones

� Consideraremos las siguiente relaciones para el diagrama de clases Universidad:

De OpcionesCursoProfesor a AñadirOfertaCurso Agregación

De AñadirOfertaCurso a GestorCursosProfesor Asociación

De GestorCursosProfesor a Cursos Asociación

De Cursos a OfertaCursos Agregación


Analizando relaciones

OfertaCursos<<entidad>>

Cursos<<entidad>>

1

1..*

0..*0..*

prerrequisitos

0..*0..*

1

1..*

OpcionesCursoProfesor<<entorno>>

AñadirOfertaCurso<<entorno>>

1 11 1

GestorCursosProfesor<<control>>

1..*0..*

1..*0..*

maneja

1

1

1

1


Relaciones entre paquetes

� Si un paquete depende de otro entonces se comunica con alguna clase de éste.

� Examinando los escenarios y las relaciones entre clases podemos descubrir las relaciones de dependencia entre paquetes.


Relaciones entre paquetes

� La clase AñadirOfertaCurso envía un mensaje a la clase GestorCursosProfesor. Esto implica una relación entre los paquetes Interfaces y Universidad. Expréselo en RS.

Interfaces



Comportamiento y estructura

� Los atributos determinan la estructura.� Las operaciones se derivan de los

mensajes presentes en los diagramas de interacción.

� A veces, recibir un mensaje no implica implementar una operación (p.e. controles gráficos como botones, etc.).

� Tampoco se implementan los mensajes que reciben los actores.


Comportamiento y estructura

� Añada a la clase cursos las operaciones

AñadirProfesor, ObtenerOfertas y ValidarProfesor.

� Las dos primeras desde el diagrama de secuencia

introducido. La última directamente en la clase.

� Documentación para AñadirProfesor:

Añadir un profesor como docente de un curso particular de la

oferta de cursos.

Entradas: Profesor y curso ofertado

Salidas: Indicador de éxito.


Relaciones y signatura de operaciones

� La signatura de una operación puede implicar una relación si el argumento es de tipo clase.

� Esto ocurre por ejemplo en la operación AñadirProfesor de la clase curso que tiene como argumentos a InformaciónProfesor y a OfertaCurso. Entonces surgen las relaciones:

Curso con InformaciónProfesorCurso con OfertaCursos


Creación de atributos

� Añada los atributos siguientes a la clase cursos:

NombreDescripciónCréditosHoras


Clases asociación

� Una relación puede tener estructura y comportamiento. Considere que un estudiante puede coger hasta 4 cursos y un curso puede involucrar entre 3 y 10 estudiantes. Añada esta relación.


Clases asociación

� Añada las clases Examen y TarjetaInforme que se relacionen tal como se indica:

OfertaCursos

AñadirProfesor()

<<entidad>>

InformacionEstudiante

<<entidad>>

0..4 3..100..4 3..10

Examen

nota

TarjetaInforme

1

1

1

1

10..4 10..4


Herencia

� Incluya en el diagrama de clases de Personas la clase InformaciónUsuario como generalización de InformaciónProfesor e InformaciónEstudiante.

InformacionProfesor<<entidad>>

InformacionEstudiante<<entidad>>

InformacionUsuario


Herencia

� Añada a la clase InformaciónUsuario los atributos nombre e identificador, comunes a ambas subclases.


StateCharts

� Abra el diagrama de clases que contenga la clase OfertaCursos y seleccione “Browse-State Diagram”. Añada el diagrama de la figura siguiente:

Inicialización

Abrir

Cancelado

Cerradoañadir estudiante

cancelarañadir estudiante


StateCharts

� Modifique el diagrama anterior para incorporar las guardas:

contador <10 en el arco reflexivo a Abierto.contador=10 en el arco de Abierto a Cerrado

� Modifique el arco AñadirEstudiante de Inicialización a Abierto de manera que se haga set contador=0 y se envíe el mensaje Create sin argumentos a la clase ListaCursos.


StateCharts

� Modifique el estado Inicialización de manera que incluya las operaciones InicializarDatosOfertaCursos a realizar a la entrada al estado.

� Lo mismo para el estado Abierto:Al entrar: RegistrarEstudianteAl salir: enviar el mensaje AñadirEstudiante a ListaCursos

con el argumento estudiante

� Modifique el arco de Cancelado a Cerrado para enviar el mensaje Borrar a ListaCursos.


Chequeo del modelo

� Una clase puede ser eliminada del modelo si descubrimos que no tiene estructura, comportamiento o no participa en los casos de uso.

� Verifique que dos objetos que se comunican están conectados a través de asociación o agregación.


Chequeo del modelo

� Verifique que cada clase participa en al menos un escenario.

� Verifique que cada operación de una clase está incluido en algún escenario.

� Verifique que cada mensaje recibido por una clase en un diagrama de secuencia está definido en la clase receptora.

� Verifique que la clase que envía el mensaje en el D. de secuencia es responsable del envío.


Chequeo del modelo

� Verifique que las clases emisora y receptora del D. de secuencia están relacionadas por asociación o por agregación.

� Si una clase tiene un statechart asociado verifique entonces que el evento está representado en el diagrama de la clase receptora.

� Dos clases pueden llegar a fusionarse.

� Una clase puede ser dividida en dos o más independientes.


Diseño de la arquitectura

� Se decide incorporar controles GUI al modelo.

� Se considera una clase persistente de base de

datos para cada clase del modelo (incluidas

en el paquete basedatos).

� Se considera un paquete con utilidades

comerciales (paquete global a todos).

� Se considera un paquete global para la

gestión de errores (paquete ManejoErrores).



� Incluya los paquetes anteriores estableciendo una dependiencia de Universidad a BaseDatos, de Personas a BaseDatos y de Interfaces a GUI.

� Incluya también los paquetes globales.



Interfaces


BaseDatos ManejoErrores

global

Comerciales

global

GUI


Vista de componentes

� Los paquetes de la vista de componentes corresponden a subsistemas.

� Un paquete de la vista lógica puede pasar a la vista de componentes.

� La relación entre paquetes es la siguiente:Paq. Componentes Paq. LógicoInterfaces Interfaces, GUIUniversidad Universidad, PersonasBaseDatos BaseDatosComerciales ComercialesManejoErrores ManejoErrores


Vista de componentes

� En la vista de componentes del modelo un componente representa un fichero software incluido en algún paquete (subsistema).

� El tipo de este fichero es dependiente del lenguaje (C++, .java, etc.).


Vista de Componentes

� Crear un nuevo diagrama de componentes para el paquete Universidad que incluya las especificación de paquetes:

CursosOfertaCursosInformaciónUsuarioInformaciónEstudianteInformaciónProfesor


Componentes

Cursos OfertaCursos

InformaciónUsuariosInformaciónEstudiante InformaciónProfesor


Vista de Procesos

� Esta vista de la arquitectura se centra en la implementación en tiempo de ejecución del sistema.

� Se considera productividad, escalabilidad, integridad, manejo y sincronización.

� Los componentes se incluyen con relaciones de dependencia entre ellos.

� Los componentes run-time muestran la relación de las clases con librerías de ejecución tales como applets java, Componentes Active X y DLLs.


Vista de Procesos

� Dibuje un nuevo diagrama de componentes en el que incluya dos DLL (Cursos y BaseDatos) un ejecutable (Profesor) y tres ejecutables más (OpcionesCursoProfesor, AñadirOfertaCursos e InformaciónProfesor).


Vista de ProcesosProfesor

BaseDatos

InformacionProfesor

AñadirOfertaCursos

OpcionesCursoProfesor

Cursos


Despliegue

� Tras analizar los subsistemas definidos, el HW existente y estimando la carga del sistema durante el proceso de inscripción se decide ubicar 5 procesadores, uno para el ejecutable de profesores, otro para la base de datos y tres para la matriculación de los estudiantes (en la biblioteca, edificio principal y colegio mayor).


Despliegue

� Dibuje el diagrama de despliegue siguiente:

Registro Servidor Base Datos

Colegio Mayor Edificio Principal

Biblioteca

Technology

Curso Uml Caso Estudio Terry Quatrani