Conferencia Caso Uml

Caso de Estudio Guiado usando UML y Rational Rose Pedro Sánchez Palma Patricio Letelier Torres {ppalma, letelier}@dsic.upv.es Departamento Sistemas Informáticos y Computación Universidad Politécnica de Valencia Cursos de Postgrado Valencia, Junio de 2000

Descripción del ejemplo Gestió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 Precondiciones X.2 Flujo principal X.3 Subflujos X.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 Precondiciones El subflujo “Crear oferta de cursos” del caso de uso “Mantener información de un curso” debe ejecutarse antes. 1.2 Flujo principal Este 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.

Flujo de eventos para el CU “seleccionar cursos a impartir” 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 Subflujos S-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).

Flujo de eventos para el CU “seleccionar cursos a impartir” 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.

Flujo de eventos para el CU “seleccionar cursos a impartir” S-4: Imprimir una planificación El sistema imprime la planificación de los cursos para el profesor (E-9). El caso de uso comienza. 1.4 Flujos alternativos E-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.

Flujo de eventos para el CU “seleccionar cursos a impartir” 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>>

Creación del diagrama de CU principal Incorpore al diagrama las relaciones de uso.

Creación del diagrama de CU principal

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.

Clases del escenario “añadir oferta de curso para enseñar” 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 ).

Clases del escenario “añadir oferta de curso para enseñar” 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.

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

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

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

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 .

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 cursos 1 curso sólo lo da un profesor

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

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.

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ónProfesor Curso con OfertaCursos

Creación de atributos Añada los atributos siguientes a la clase cursos : Nombre Descripción Cré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..10 0..4 3..10 Examen nota TarjetaInforme 1 1 1 1 1 0..4 1 0..4

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

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 Cerrado añadir estudiante cancelar añ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: RegistrarEstudiante Al 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 ).

Diseño de la arquitectura 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.

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ógico Interfaces Interfaces, GUI Universidad Universidad, Personas BaseDatos BaseDatos Comerciales Comerciales ManejoErrores 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: Cursos OfertaCursos InformaciónUsuario Informació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 ).

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:

Conferencia Caso Uml

Más contenido relacionado

La actualidad más candente (19)

Similar a Conferencia Caso Uml (20)

Último (20)

Conferencia Caso Uml