<ul><li>Caso de Estudio Guiado usando </li></ul><ul><li>UML y Rational Rose </li></ul><ul><li>Pedro Sánchez Palma </li></u...
Descripción del ejemplo <ul><li>Gestión de Cursos UPV </li></ul><ul><li>Se asignan profesores a cursos. </li></ul><ul><li>...
Descripción del ejemplo <ul><li>Se imprime un catálogo por curso programado y se entrega a los estudiantes. </li></ul><ul>...
Descripción del ejemplo <ul><li>Tras el periodo de inscripción los profesores reciben la lista de estudiantes apuntados a ...
Registro de los cursos <ul><li>Al principio del semestre los estudiantes reciben la información de los cursos, profesores,...
Registro de los cursos <ul><li>Los profesores deben poder acceder a la información de los cursos. </li></ul><ul><li>Durant...
Actores <ul><li>La identificación de actores no suelen ser inmediata sino más bien iterada. </li></ul><ul><li>Una misma pe...
Actores <ul><li>Actores: </li></ul><ul><ul><li>Los  estudiantes  desean apuntarse a los cursos. </li></ul></ul><ul><ul><li...
Creación de actores en RS <ul><li>Introduzca los actores anteriores en Rational Rose. </li></ul><ul><li>Introduzca las des...
Casos de Uso <ul><li>Registrarse en los cursos. </li></ul><ul><li>Seleccionar los cursos a impartir. </li></ul><ul><li>Sol...
Creación de Casos de Uso <ul><li>Cree los distintos casos de uso. </li></ul><ul><li>Añada una breve descripción de cada ca...
Flujo de eventos para cada caso de uso <ul><li>El flujo de eventos de un caso de uso es una descripción de los eventos que...
Flujo de eventos para cada caso de uso <ul><li>Normalmente se crea en la fase de elaboración de manera iterativa. </li></u...
Flujo de eventos para el CU “seleccionar cursos a impartir” <ul><li>1.0 Flujo de eventos del CU “seleccionar curso a  impa...
Flujo de eventos para el CU “seleccionar cursos a impartir” <ul><ul><li>Si la actividad es ADD se hace el subflujo S-1 “Añ...
Flujo de eventos para el CU “seleccionar cursos a impartir” <ul><ul><li>El sistema enlace profesor y curso (E-5). El caso ...
Flujo de eventos para el CU “seleccionar cursos a impartir” <ul><ul><li>S-4: Imprimir una planificación </li></ul></ul><ul...
Flujo de eventos para el CU “seleccionar cursos a impartir” <ul><ul><li>E-6: Nombre/número de curso no válidos. Reintentar...
Flujo de eventos <ul><li>Establezca un enlace entre el caso de uso “seleccionar curso a impartir” y el fichero anterior de...
Relaciones en los casos de uso <ul><li>Las relaciones de asociación entre el actor y el caso de uso puede ser bidirecciona...
Relaciones en los casos de uso <ul><li>La relación “extiende” se usa para: </li></ul><ul><ul><li>Comportamiento opcional. ...
Creación del diagrama de CU principal <ul><li>Incorpore al diagrama cada uno de los actores involucrados. </li></ul><ul><l...
Creación del diagrama de CU principal <ul><li>Incorpore al diagrama las relaciones de uso. </li></ul>
Creación del diagrama de CU principal
Creación de Clases <ul><li>Considerando que análisis y diseño son procesos iterativos es incrementales, la identificación ...
Creación de Clases <ul><li>Las clases  entorno  manejan la comunicación entre la frontera del sistema y el interior del si...
Creación de Clases <ul><li>Las clases  control  modelan conducta secuencial específica a uno o más casos de uso. Coordinan...
Clases en RS <ul><li>Cree la clase “InformaciónEstudiante” y asocie el estereotipo <<entidad>>, y la siguiente documentaci...
Paquetes en RS <ul><li>Cree el paquete “InformacionPersonas”. </li></ul><ul><li>Reubique las clases InformaciónEstudiante ...
Clases del escenario “añadir oferta de curso para enseñar” <ul><li>El escenario “añadir oferta de curso para enseñar” es u...
Clases del escenario “añadir oferta de curso para enseñar” <ul><li>Identificamos tres clases tipo entidad:  Curso ,  Ofert...
Clases del escenario “añadir oferta de curso para enseñar” <ul><li>Las clases de entorno las ubicamos en el paquete que cr...
Diagrama de clases principal <ul><li>Hacer doble-click en el diagrama de clases principal del logical-view y añadir los pa...
Diagrama de clases principal <ul><li>Hacer doble-click en el paquete  Universidad  e incluir las clases  Cursos  y  Gestor...
Diagrama de clases caso  de uso <ul><li>Situado sobre el caso de uso “seleccionar cursos a impartir” crear un diagrama de ...
Diagrama de clases caso  de uso <ul><li>A cada clase especificar el estereotipo correspondiente (entorno, control o entida...
Diagramas de secuencia <ul><li>Asociar un diagrama de secuencia para el escenario “Crear Catálogo Curso” (cree autom. el d...
Diagramas de secuencia <ul><li>Cree el diagrama  </li></ul><ul><li>de secuencia para  </li></ul><ul><li>el escenario  </li...
Especificando relaciones <ul><li>En el diagrama de clases de Universidad establecer una asociación entre las clases  curso...
Roles en relaciones <ul><li>Cree en el paquete  Personas  un diagrama de clases en el que incluya a  OfertaCursos  e  Info...
Roles en relaciones <ul><li>Considere la cardinalidad siguiente para la asociación anterior: </li></ul><ul><li>1 profesor ...
Relaciones reflexivas <ul><li>Considere que un curso está relacionado consigo mismo con el rol prerrequisito y con cardina...
Analizando relaciones <ul><li>Consideraremos las siguiente relaciones para el diagrama de clases  Universidad : </li></ul>...
Analizando relaciones
Relaciones entre paquetes <ul><li>Si un paquete depende de otro entonces se comunica con alguna clase de éste. </li></ul><...
Relaciones entre paquetes <ul><li>La clase  AñadirOfertaCurso  envía un mensaje a la clase  GestorCursosProfesor . Esto im...
Comportamiento y estructura <ul><li>Los atributos determinan la estructura. </li></ul><ul><li>Las operaciones se derivan d...
Comportamiento y estructura <ul><li>Añada a la clase  cursos  las operaciones  AñadirProfesor ,  ObtenerOfertas  y  Valida...
Relaciones y signatura de operaciones <ul><li>La signatura de una operación puede implicar una relación si el argumento es...
Creación de atributos <ul><li>Añada los atributos siguientes a la clase  cursos : </li></ul><ul><ul><li>Nombre </li></ul><...
Clases asociación <ul><li>Una relación puede tener estructura y comportamiento. Considere que un estudiante puede coger ha...
Clases asociación <ul><li>Añada las clases  Examen  y  TarjetaInforme  que se relacionen tal como se indica: </li></ul>Ofe...
Herencia <ul><li>Incluya en el diagrama de clases de  Personas  la clase  InformaciónUsuario  como generalización de  Info...
Herencia <ul><li>Añada a la clase  InformaciónUsuario  los atributos  nombre  e  identificador , comunes a ambas subclases...
StateCharts <ul><li>Abra el diagrama de clases que contenga la clase  OfertaCursos  y seleccione “Browse-State Diagram”. A...
StateCharts <ul><li>Modifique el diagrama anterior para incorporar las guardas: </li></ul><ul><ul><li>contador <10 en el a...
StateCharts <ul><li>Modifique el estado  Inicialización  de manera que incluya las operaciones  InicializarDatosOfertaCurs...
Chequeo del modelo <ul><li>Una clase puede ser eliminada del modelo si descubrimos que no tiene estructura, comportamiento...
Chequeo del modelo <ul><li>Verifique que cada clase participa en al menos un escenario. </li></ul><ul><li>Verifique que ca...
Chequeo del modelo <ul><li>Verifique que las clases emisora y receptora del D. de secuencia están relacionadas por asociac...
Diseño de la arquitectura <ul><li>Se decide incorporar controles  GUI  al modelo. </li></ul><ul><li>Se considera una clase...
Diseño de la arquitectura <ul><li>Incluya los paquetes anteriores estableciendo una dependiencia de  Universidad  a  BaseD...
Diseño de la arquitectura
Vista de componentes <ul><li>Los paquetes de la vista de componentes corresponden a subsistemas. </li></ul><ul><li>Un paqu...
Vista de componentes <ul><li>En la vista de componentes del modelo un componente representa un fichero software incluido e...
Vista de Componentes <ul><li>Crear un nuevo diagrama de componentes para el paquete Universidad que incluya las especifica...
Componentes
Vista de Procesos <ul><li>Esta vista de la arquitectura se centra en la implementación en tiempo de ejecución del sistema....
Vista de Procesos <ul><li>Dibuje un nuevo diagrama de componentes en el que incluya dos DLL ( Cursos  y  BaseDatos ) un ej...
Vista de Procesos
Despliegue <ul><li>Tras analizar los subsistemas definidos, el HW existente y estimando la carga del sistema durante el pr...
Despliegue <ul><li>Dibuje el diagrama de despliegue siguiente: </li></ul>
Upcoming SlideShare
Loading in …5
×

Curso Uml Caso Estudio Terry Quatrani

1,916 views

Published on

Published in: Technology, Education
  • Be the first to comment

Curso Uml Caso Estudio Terry Quatrani

  1. 1. <ul><li>Caso de Estudio Guiado usando </li></ul><ul><li>UML y Rational Rose </li></ul><ul><li>Pedro Sánchez Palma </li></ul><ul><li>Patricio Letelier Torres </li></ul><ul><li>{ppalma, letelier}@dsic.upv.es </li></ul><ul><li>Departamento Sistemas Informáticos y Computación </li></ul><ul><li>Universidad Politécnica de Valencia (España) </li></ul>
  2. 2. Descripción del ejemplo <ul><li>Gestión de Cursos UPV </li></ul><ul><li>Se asignan profesores a cursos. </li></ul><ul><li>Los estudiantes se registran en los cursos. </li></ul><ul><li>Los profesores deciden qué cursos dar el próximo semestre. </li></ul><ul><li>La oficina de registro introduce la información en el sistema. </li></ul><ul><li>Se imprime un informe para los profesores indicando qué cursos y cuándo. </li></ul>
  3. 3. Descripción del ejemplo <ul><li>Se imprime un catálogo por curso programado y se entrega a los estudiantes. </li></ul><ul><li>Los estudiantes se apuntan a los cursos. </li></ul><ul><li>La oficina de registro introduce los formularios con los cursos solicitados. </li></ul><ul><li>Un proceso batch asignará estudiantes a cursos. </li></ul><ul><li>Cuando exista conflicto en la asignación la oficina de registro informará a los estudiantes las opciones disponibles. </li></ul>
  4. 4. Descripción del ejemplo <ul><li>Tras el periodo de inscripción los profesores reciben la lista de estudiantes apuntados a cada curso que van a impartir. </li></ul><ul><li>Riesgos </li></ul><ul><li>La capacidad de almacenamiento y acceso a la información curricular de manera eficiente. </li></ul><ul><li>El desarrollo de prototipos permitirá deducir que el riesgo puede ser mitigado. </li></ul>
  5. 5. Registro de los cursos <ul><li>Al principio del semestre los estudiantes reciben la información de los cursos, profesores, departamentos, prerrequisitos, etc. </li></ul><ul><li>El estudiante incluirá dos alternativas por si un curso está lleno o se cancela. </li></ul><ul><li>Un curso se cancela si no alcanza un mínimo de 3 alumnos. </li></ul><ul><li>El máximo de alumnos por curso es de 10. </li></ul>
  6. 6. Registro de los cursos <ul><li>Los profesores deben poder acceder a la información de los cursos. </li></ul><ul><li>Durante un periodo de tiempo fijado los estudiantes pueden cambiarse o borrarse de los cursos. </li></ul>
  7. 7. Actores <ul><li>La identificación de actores no suelen ser inmediata sino más bien iterada. </li></ul><ul><li>Una misma persona física puede usar el sistema de dos formas distintas apareciendo entonces como dos actores diferentes. </li></ul><ul><li>Examinamos los diferentes actores y documentamos cómo usan el sistema. </li></ul>
  8. 8. Actores <ul><li>Actores: </li></ul><ul><ul><li>Los estudiantes desean apuntarse a los cursos. </li></ul></ul><ul><ul><li>Los profesores quieren seleccionar cursos para impartirlos. </li></ul></ul><ul><ul><li>El secretario debe crear el catálogo del semestre. </li></ul></ul><ul><ul><li>El secretario debe mantener toda la información sobre los cursos, profesores y estudiantes. </li></ul></ul><ul><ul><li>El sistema de faturación debe recibir la facturación generada. </li></ul></ul>
  9. 9. Creación de actores en RS <ul><li>Introduzca los actores anteriores en Rational Rose. </li></ul><ul><li>Introduzca las descripciones: </li></ul><ul><ul><li>Estudiante: Una persona que se matricula para recibir clases en la Universidad. </li></ul></ul><ul><ul><li>Profesor: Una persona acreditada para dar clases en la universidad. </li></ul></ul><ul><ul><li>Secretario: Una persona responsable del mantenimiento de la información de los cursos. </li></ul></ul><ul><ul><li>Sistema de Facturación: Sistema externo responsable de la facturación a los estudiantes. </li></ul></ul>
  10. 10. Casos de Uso <ul><li>Registrarse en los cursos. </li></ul><ul><li>Seleccionar los cursos a impartir. </li></ul><ul><li>Solicitar lista de apuntados a un curso. </li></ul><ul><li>Mantener información de un curso. </li></ul><ul><li>Mantener información de un profesor. </li></ul><ul><li>Mantener información de un estudiante. </li></ul><ul><li>Crear un catálogo de curso. </li></ul>
  11. 11. Creación de Casos de Uso <ul><li>Cree los distintos casos de uso. </li></ul><ul><li>Añada una breve descripción de cada caso de uso. </li></ul>
  12. 12. Flujo de eventos para cada caso de uso <ul><li>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. </li></ul><ul><li>Escrito en términos del qué y no del cómo. </li></ul><ul><li>Debe incluir: </li></ul><ul><ul><li>Cuándo y cómo empieza o acaba el CU. </li></ul></ul><ul><ul><li>Interacción con actores. </li></ul></ul><ul><ul><li>Datos que necesita el CU. </li></ul></ul><ul><ul><li>Secuencia normal de eventos para el CU. </li></ul></ul><ul><ul><li>Descripción de cualquier flujo alternativo o excepcional. </li></ul></ul>
  13. 13. Flujo de eventos para cada caso de uso <ul><li>Normalmente se crea en la fase de elaboración de manera iterativa. </li></ul><ul><li>Debería seguir una plantilla tal como: </li></ul><ul><ul><li>X Flujo de eventos para el caso de uso <nombre> </li></ul></ul><ul><ul><li>X.1 Precondiciones </li></ul></ul><ul><ul><li>X.2 Flujo principal </li></ul></ul><ul><ul><li>X.3 Subflujos </li></ul></ul><ul><ul><li>X.4 Flujos alternativos </li></ul></ul><ul><ul><li>siendo X un iterador para cada caso de uso </li></ul></ul>
  14. 14. Flujo de eventos para el CU “seleccionar cursos a impartir” <ul><li>1.0 Flujo de eventos del CU “seleccionar curso a impartir” </li></ul><ul><li>1.1 Precondiciones </li></ul><ul><ul><li>El subflujo “Crear oferta de cursos” del caso de uso “Mantener información de un curso” debe ejecutarse antes. </li></ul></ul><ul><li>1.2 Flujo principal </li></ul><ul><ul><li>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. </li></ul></ul>
  15. 15. Flujo de eventos para el CU “seleccionar cursos a impartir” <ul><ul><li>Si la actividad es ADD se hace el subflujo S-1 “Añadir curso” </li></ul></ul><ul><ul><li>Si la actividad es DELETE se hace el subflujo S-2 “Borrar curso” </li></ul></ul><ul><ul><li>Si la actividad es REVIEW se hace el subflujo S-3 “Revisar planificación” </li></ul></ul><ul><ul><li>Si la actividad es PRINT se hace el subflujo S-4 “Imprimir planificación” </li></ul></ul><ul><ul><li>Si la actividad es QUIT el caso de uso termina. </li></ul></ul><ul><li>1.3 Subflujos </li></ul><ul><ul><li>S-1: Añadir curso. </li></ul></ul><ul><ul><li>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). </li></ul></ul>
  16. 16. Flujo de eventos para el CU “seleccionar cursos a impartir” <ul><ul><li>El sistema enlace profesor y curso (E-5). El caso de uso comienza de nuevo. </li></ul></ul><ul><ul><li>S-2: Borrar un curso. </li></ul></ul><ul><ul><li>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. </li></ul></ul><ul><ul><li>S-3: Revisar una planificación </li></ul></ul><ul><ul><li>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. </li></ul></ul>
  17. 17. Flujo de eventos para el CU “seleccionar cursos a impartir” <ul><ul><li>S-4: Imprimir una planificación </li></ul></ul><ul><ul><li>El sistema imprime la planificación de los cursos para el profesor (E-9). El caso de uso comienza. </li></ul></ul><ul><li>1.4 Flujos alternativos </li></ul><ul><ul><li>E-1: El identificador de profesor no es válido. El usuario puede intentarlo de nuevo o salir. </li></ul></ul><ul><ul><li>E-2: El código de semestre no es valido. Repetir o salir. </li></ul></ul><ul><ul><li>E-3: Número/nombre de curso no válido. Repetir o salir. </li></ul></ul><ul><ul><li>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. </li></ul></ul><ul><ul><li>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. </li></ul></ul>
  18. 18. Flujo de eventos para el CU “seleccionar cursos a impartir” <ul><ul><li>E-6: Nombre/número de curso no válidos. Reintentar o salir. </li></ul></ul><ul><ul><li>E-7: No se puede borrar el enlace. Se salva la información para reintentarlo más tarde. El caso de uso continúa. </li></ul></ul><ul><ul><li>E-8: El sistema no puede extraer la información para la planificación. El caso de uso comienza. </li></ul></ul><ul><ul><li>E-9: La planificación no puede imprimirse. El caso de uso comienza. </li></ul></ul><ul><li>Esta información se mantiene aparte y se enlaza porteriormente con Rational Rose. </li></ul>
  19. 19. Flujo de eventos <ul><li>Establezca un enlace entre el caso de uso “seleccionar curso a impartir” y el fichero anterior de flujo de eventos. </li></ul>
  20. 20. Relaciones en los casos de uso <ul><li>Las relaciones de asociación entre el actor y el caso de uso puede ser bidireccionalmente navegable o en una sóla dirección. </li></ul><ul><li>Entre casos de uso tenemos el incluye y el extiende . </li></ul><ul><li>Por ejemplo, todos los casos de uso anteriores empiezan con la verificación del acceso (es decir, “lo incluyen”). </li></ul>
  21. 21. Relaciones en los casos de uso <ul><li>La relación “extiende” se usa para: </li></ul><ul><ul><li>Comportamiento opcional. </li></ul></ul><ul><ul><li>Comportamiento que se lleva a cabo bajo ciertas circunstancias. </li></ul></ul><ul><ul><li>Diferentes flujos que se ejecutan en función de la selección del actor. </li></ul></ul>
  22. 22. Creación del diagrama de CU principal <ul><li>Incorpore al diagrama cada uno de los actores involucrados. </li></ul><ul><li>Incorpore al diagrama cada uno de los casos de uso involucrados (arrastrando el CU). </li></ul><ul><li>Establezca la comunicación entre actores y casos de uso (unidireccional o bidireccional con la asociación). </li></ul><ul><li>Podemos establecer el estereotipo <<se comunica con>> </li></ul>
  23. 23. Creación del diagrama de CU principal <ul><li>Incorpore al diagrama las relaciones de uso. </li></ul>
  24. 24. Creación del diagrama de CU principal
  25. 25. Creación de Clases <ul><li>Considerando que análisis y diseño son procesos iterativos es incrementales, la identificación de las clases cambiará con el tiempo. </li></ul><ul><li>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). </li></ul>
  26. 26. Creación de Clases <ul><li>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. </li></ul><ul><li>En la fase de elaboración estas clases entorno no se detallan apenas. </li></ul>
  27. 27. Creación de Clases <ul><li>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. </li></ul><ul><li>En la fase de elaboración se suele incluir una clase control para cada par actor/caso de uso. </li></ul>
  28. 28. Clases en RS <ul><li>Cree la clase “InformaciónEstudiante” y asocie el estereotipo <<entidad>>, y la siguiente documentación: </li></ul><ul><ul><li>Información necesaria para registrar y facturar a los estudiantes. Un estudiante es alguien que es registrado para ir a clases a la universidad. </li></ul></ul><ul><li>Haga lo mismo para la clase “InformacionProfesor”. </li></ul>
  29. 29. Paquetes en RS <ul><li>Cree el paquete “InformacionPersonas”. </li></ul><ul><li>Reubique las clases InformaciónEstudiante e InformaciónProfesor en el paquete creado. </li></ul>
  30. 30. Clases del escenario “añadir oferta de curso para enseñar” <ul><li>El escenario “añadir oferta de curso para enseñar” es uno de los subflujos del caso de uso “seleccionar cursos a impartir”. </li></ul><ul><li>Este caso de uso interacciona sólo con el actor profesor . </li></ul><ul><li>Es necesaria una clase (de entorno) que ofrezca todas las posibilidades del caso de uso (la clase OpcionesCursoProfesor ). </li></ul><ul><li>Identificamos también la clase (de entorno) AñadirOfertaCurso para este escenario. </li></ul>
  31. 31. Clases del escenario “añadir oferta de curso para enseñar” <ul><li>Identificamos tres clases tipo entidad: Curso , OfertaCurso e InformacionProfesor . </li></ul><ul><li>Identificamos una clase tipo control para manejar el flujo de eventos para el caso de uso (la clase GestorCursosProfesor ). </li></ul>
  32. 32. Clases del escenario “añadir oferta de curso para enseñar” <ul><li>Las clases de entorno las ubicamos en el paquete que creemos llamado Interfaces . </li></ul><ul><li>Las clases entidades las ubicamos en el paquete llamado Universidad . </li></ul>
  33. 33. Diagrama de clases principal <ul><li>Hacer doble-click en el diagrama de clases principal del logical-view y añadir los paquetes creados. </li></ul>
  34. 34. Diagrama de clases principal <ul><li>Hacer doble-click en el paquete Universidad e incluir las clases Cursos y GestorCursosProfesor . </li></ul><ul><li>Añadir en el paquete Interfaces las dos clases de entorno indicadas. </li></ul><ul><li>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. </li></ul>
  35. 35. Diagrama de clases caso de uso <ul><li>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 . </li></ul>
  36. 36. Diagrama de clases caso de uso <ul><li>A cada clase especificar el estereotipo correspondiente (entorno, control o entidad). </li></ul>
  37. 37. Diagramas de secuencia <ul><li>Asociar un diagrama de secuencia para el escenario “Crear Catálogo Curso” (cree autom. el de colaboración): </li></ul>
  38. 38. Diagramas de secuencia <ul><li>Cree el diagrama </li></ul><ul><li>de secuencia para </li></ul><ul><li>el escenario </li></ul><ul><li>“ Añadir Curso”: </li></ul>
  39. 39. Especificando relaciones <ul><li>En el diagrama de clases de Universidad establecer una asociación entre las clases cursos y GestorCursosProfesor. </li></ul><ul><li>Indicar la agregación existente entre cursos y OfertaCursos . </li></ul>
  40. 40. Roles en relaciones <ul><li>Cree en el paquete Personas un diagrama de clases en el que incluya a OfertaCursos e InformaciónProfesor con una asociación entre ellos. </li></ul><ul><li>Especificar que existe un rol llamado InformaciónProfesor en el diagrama de clases de Personas y entre las clases OfertaCursos y InformaciónProfesor . </li></ul>
  41. 41. Roles en relaciones <ul><li>Considere la cardinalidad siguiente para la asociación anterior: </li></ul><ul><li>1 profesor puede dar hasta 4 cursos </li></ul><ul><li>1 curso sólo lo da un profesor </li></ul>
  42. 42. Relaciones reflexivas <ul><li>Considere que un curso está relacionado consigo mismo con el rol prerrequisito y con cardinalidad 0..* en ambos lados. </li></ul>
  43. 43. Analizando relaciones <ul><li>Consideraremos las siguiente relaciones para el diagrama de clases Universidad : </li></ul><ul><ul><li>De OpcionesCursoProfesor a AñadirOfertaCurso Agregación </li></ul></ul><ul><ul><li>De AñadirOfertaCurso a GestorCursosProfesor Asociación </li></ul></ul><ul><ul><li>De GestorCursosProfesor a Cursos Asociación </li></ul></ul><ul><ul><li>De Cursos a OfertaCursos Agregación </li></ul></ul>
  44. 44. Analizando relaciones
  45. 45. Relaciones entre paquetes <ul><li>Si un paquete depende de otro entonces se comunica con alguna clase de éste. </li></ul><ul><li>Examinando los escenarios y las relaciones entre clases podemos descubrir las relaciones de dependencia entre paquetes. </li></ul>
  46. 46. Relaciones entre paquetes <ul><li>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. </li></ul>
  47. 47. Comportamiento y estructura <ul><li>Los atributos determinan la estructura. </li></ul><ul><li>Las operaciones se derivan de los mensajes presentes en los diagramas de interacción. </li></ul><ul><li>A veces, recibir un mensaje no implica implementar una operación (p.e. controles gráficos como botones, etc.). </li></ul><ul><li>Tampoco se implementan los mensajes que reciben los actores. </li></ul>
  48. 48. Comportamiento y estructura <ul><li>Añada a la clase cursos las operaciones AñadirProfesor , ObtenerOfertas y ValidarProfesor . </li></ul><ul><li>Las dos primeras desde el diagrama de secuencia introducido. La última directamente en la clase. </li></ul><ul><li>Documentación para AñadirProfesor : </li></ul><ul><ul><li>Añadir un profesor como docente de un curso particular de la oferta de cursos. </li></ul></ul><ul><ul><li>Entradas : Profesor y curso ofertado </li></ul></ul><ul><ul><li>Salidas : Indicador de éxito. </li></ul></ul>
  49. 49. Relaciones y signatura de operaciones <ul><li>La signatura de una operación puede implicar una relación si el argumento es de tipo clase. </li></ul><ul><li>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: </li></ul><ul><ul><li>Curso con InformaciónProfesor </li></ul></ul><ul><ul><li>Curso con OfertaCursos </li></ul></ul>
  50. 50. Creación de atributos <ul><li>Añada los atributos siguientes a la clase cursos : </li></ul><ul><ul><li>Nombre </li></ul></ul><ul><ul><li>Descripción </li></ul></ul><ul><ul><li>CréditosHoras </li></ul></ul>
  51. 51. Clases asociación <ul><li>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. </li></ul>
  52. 52. Clases asociación <ul><li>Añada las clases Examen y TarjetaInforme que se relacionen tal como se indica: </li></ul>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
  53. 53. Herencia <ul><li>Incluya en el diagrama de clases de Personas la clase InformaciónUsuario como generalización de InformaciónProfesor e InformaciónEstudiante . </li></ul>
  54. 54. Herencia <ul><li>Añada a la clase InformaciónUsuario los atributos nombre e identificador , comunes a ambas subclases. </li></ul>
  55. 55. StateCharts <ul><li>Abra el diagrama de clases que contenga la clase OfertaCursos y seleccione “Browse-State Diagram”. Añada el diagrama de la figura siguiente: </li></ul>Inicialización Abrir Cancelado Cerrado añadir estudiante cancelar añadir estudiante
  56. 56. StateCharts <ul><li>Modifique el diagrama anterior para incorporar las guardas: </li></ul><ul><ul><li>contador <10 en el arco reflexivo a Abierto. </li></ul></ul><ul><ul><li>contador=10 en el arco de Abierto a Cerrado </li></ul></ul><ul><li>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 . </li></ul>
  57. 57. StateCharts <ul><li>Modifique el estado Inicialización de manera que incluya las operaciones InicializarDatosOfertaCursos a realizar a la entrada al estado. </li></ul><ul><li>Lo mismo para el estado Abierto: </li></ul><ul><ul><li>Al entrar: RegistrarEstudiante </li></ul></ul><ul><ul><li>Al salir: enviar el mensaje AñadirEstudiante a ListaCursos con el argumento estudiante </li></ul></ul><ul><li>Modifique el arco de Cancelado a Cerrado para enviar el mensaje Borrar a ListaCursos . </li></ul>
  58. 58. Chequeo del modelo <ul><li>Una clase puede ser eliminada del modelo si descubrimos que no tiene estructura, comportamiento o no participa en los casos de uso. </li></ul><ul><li>Verifique que dos objetos que se comunican están conectados a través de asociación o agregación. </li></ul>
  59. 59. Chequeo del modelo <ul><li>Verifique que cada clase participa en al menos un escenario. </li></ul><ul><li>Verifique que cada operación de una clase está incluido en algún escenario. </li></ul><ul><li>Verifique que cada mensaje recibido por una clase en un diagrama de secuencia está definido en la clase receptora. </li></ul><ul><li>Verifique que la clase que envía el mensaje en el D. de secuencia es responsable del envío. </li></ul>
  60. 60. Chequeo del modelo <ul><li>Verifique que las clases emisora y receptora del D. de secuencia están relacionadas por asociación o por agregación. </li></ul><ul><li>Si una clase tiene un statechart asociado verifique entonces que el evento está representado en el diagrama de la clase receptora. </li></ul><ul><li>Dos clases pueden llegar a fusionarse. </li></ul><ul><li>Una clase puede ser dividida en dos o más independientes. </li></ul>
  61. 61. Diseño de la arquitectura <ul><li>Se decide incorporar controles GUI al modelo. </li></ul><ul><li>Se considera una clase persistente de base de datos para cada clase del modelo (incluidas en el paquete basedatos ). </li></ul><ul><li>Se considera un paquete con utilidades comerciales (paquete global a todos). </li></ul><ul><li>Se considera un paquete global para la gestión de errores (paquete ManejoErrores ). </li></ul>
  62. 62. Diseño de la arquitectura <ul><li>Incluya los paquetes anteriores estableciendo una dependiencia de Universidad a BaseDatos , de Personas a BaseDatos y de Interfaces a GUI . </li></ul><ul><li>Incluya también los paquetes globales. </li></ul>
  63. 63. Diseño de la arquitectura
  64. 64. Vista de componentes <ul><li>Los paquetes de la vista de componentes corresponden a subsistemas. </li></ul><ul><li>Un paquete de la vista lógica puede pasar a la vista de componentes. </li></ul><ul><li>La relación entre paquetes es la siguiente: </li></ul><ul><ul><li>Paq. Componentes Paq. Lógico </li></ul></ul><ul><ul><li>Interfaces Interfaces, GUI </li></ul></ul><ul><ul><li>Universidad Universidad, Personas </li></ul></ul><ul><ul><li>BaseDatos BaseDatos </li></ul></ul><ul><ul><li>Comerciales Comerciales </li></ul></ul><ul><ul><li>ManejoErrores ManejoErrores </li></ul></ul>
  65. 65. Vista de componentes <ul><li>En la vista de componentes del modelo un componente representa un fichero software incluido en algún paquete (subsistema). </li></ul><ul><li>El tipo de este fichero es dependiente del lenguaje (C++, .java, etc.). </li></ul>
  66. 66. Vista de Componentes <ul><li>Crear un nuevo diagrama de componentes para el paquete Universidad que incluya las especificación de paquetes: </li></ul><ul><ul><li>Cursos </li></ul></ul><ul><ul><li>OfertaCursos </li></ul></ul><ul><ul><li>InformaciónUsuario </li></ul></ul><ul><ul><li>InformaciónEstudiante </li></ul></ul><ul><ul><li>InformaciónProfesor </li></ul></ul>
  67. 67. Componentes
  68. 68. Vista de Procesos <ul><li>Esta vista de la arquitectura se centra en la implementación en tiempo de ejecución del sistema. </li></ul><ul><li>Se considera productividad, escalabilidad, integridad, manejo y sincronización. </li></ul><ul><li>Los componentes se incluyen con relaciones de dependencia entre ellos. </li></ul><ul><li>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. </li></ul>
  69. 69. Vista de Procesos <ul><li>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 ). </li></ul>
  70. 70. Vista de Procesos
  71. 71. Despliegue <ul><li>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). </li></ul>
  72. 72. Despliegue <ul><li>Dibuje el diagrama de despliegue siguiente: </li></ul>

×