Casos de Uso
Los usuarios, cuando utilizan una aplicación lo hacen con un propósito en mente. Siempre esperan obtener algo concreto de la aplicación como:
- Registrar un nuevo pedido
- Calcular el total vencido
- Ver la colección de canciones
- Enviar un correo, etc.
ActoresLos usuarios se pueden clasificar, desde el punto de vista de un software, en roles o grupos de personas que esperan cosas particulares de la aplicación.
Un Actor representa un rol de un usuario. Identificar los Actores es el primer paso para identificar qué se espera de la aplicación.
Un actor puede ser cualquier cosa con comportamiento, como una persona (identificada por un rol), un sistema informatizado o una organización. La misma persona física puede interpretar varios roles como actores distintos. Es importante que el nombre del actor describa el papel desempeñado.
Identificación de los ActoresPara identificar los actores, es útil hacerse las siguientes preguntas:
- ¿Cuáles usuarios el sistema apoya para desarrollar su trabajo?
- ¿Cuáles usuarios ejecutan las funciones principales del sistema?
- ¿Cuáles usuarios desempeñan funciones secundarias, como mantenimiento y administración?
- ¿El sistema interactúa con algún sistema externo o software?
Este ejemplo, ilustra los actores principales que utilizan el sistema Banner en la Uniandes. Cada actor tiene propósitos distintos. Por ejemplo, el usuario en el rol de Estudiante (actor Estudiante) está interesado en ver sus notas de un curso, mientras que el actor Profesor está interesado en registrar las notas de sus estudiantes:
Figura 2
El objetivo de un caso de uso es el de capturar el comportamiento deseado del sistema en desarrollo sin tener que especificar cómo se implementa este comportamiento. Un caso de uso es una interacción específica entre un usuario y la aplicación para que el usuario obtenga un resultado concreto. Para que un servicio de la aplicación sea considerado un caso de uso, debe haber interacción entre un Actor y el sistema. En esta interacción hay un intercambio de información y al final debe ser claro qué obtuvo el usuario
Los casos de uso proporcionan un medio para que los desarrolladores, los usuarios finales del sistema y los expertos del dominio lleguen a una comprensión común del sistema.
El objetivo es identificar los casos de uso por actor y representarlos en un diagrama de casos de uso. Un caso de uso se representa con un círculo y su nombre en él. Un actor se representa con una figura humana simplificada.
El nombre del caso de uso debe ser claro y permitir identificar el servicio que ofrece el sistema.
El siguiente es tal vez el ejemplo más popular de casos de uso: Un cajero automático. En el diagrama de casos de uso hay tres actores: el banco, el cliente del banco y alguien de mantenimiento. Tanto el banco como el cliente del banco utilizan el sistema para retirar dinero en efectivo, transferir fondos y depositar fondos.
Figura 3
El nombre un caso de uso debe comenzar por un verbo en infinitivo y luego tener palabras complementarias definidas en el contexto del problema que aclaren el propósito del caso de uso. Ejemplos de malos nombres de casos de uso porque no dan una idea clara del propósito concreto del caso de uso:
- Manejar datos: qué es manejar y a qué datos se refiere?
- Reportar información: reportar a quién, qué, cuál información?
Ejemplos de buenos nombres de casos de uso:
- Registrar las notas finales de un curso (Banner. Actor: Profesor)
- Retirar dinero de un cajero automático
- Comprar un libro
Como ya mencionamos, para el nombre del caso de uso, se utilizan verbos en infinitivo que representan las acciones del usuario con el sistema. Siempre debe existir un tipo de usuario (Actor) que lo utilice (al menos uno).
Rol de los usuarios que ejecutan el caso de uso.
Es una frase que aclara el resultado que obtendrá el actor al finalizar el caso de uso.
La especificación del caso de uso es una descripción de un conjunto de secuencias de acciones, incluyendo escenarios o variantes, que ejecuta un sistema y un Actor para producir un resultado observable de valor para el Actor. Puede haber distintos tipos de secuencias en el mismo caso de uso, y estas se pueden clasificar en dos grupos:
- Todo sale bien y el caso de uso se termina con éxito o
- Algo no sale bien y el caso de uso debe interrumpirse con una excepción.
En el flujo de eventos o secuencia de acciones, en cada paso debe ser claro quién realiza la acción: el Actor o el sistema.
El Flujo de eventos principal o curso básico de eventos, se refiere a la secuencia de interacciones entre el Actor y el sistema y donde el caso de uso termina con éxito. El siguiente ejemplo muestra la especificación de un curso básico de eventos o escenario de un caso de uso exitoso. Contiene un Nombre, Actor, Resumen y el curso básico de eventos:
| Nombre del escenario | Consultar listado de estudiantes de un curso |
| Actor | Profesor |
| Resumen | Dando el semestre y el código del curso, el profesor obtiene la lista de estudiantes inscritos en él. |
| Curso básico de eventos | |
| 1. El Profesor ingresa al sistema indicando sus datos. | |
| 2. El sistema despliega cada una de las posibilidades del sistema. | |
| 3. El Profesor indica que quiere sacar un listado de un curso. | |
| 4. El sistema solicita ingresar la información del código, sección y semestre de la materia. | |
| 5. El Profesor ingresa 21251, 02, 2018-1. | |
| 6. El sistema devuelve la información correspondiente al curso indican el nombre, carnet, carrera y correo electrónico de cada uno de los alumnos. |
Como el objetivo de especificar el caso de uso es entender cuál es el servicio que se debe desarrollar, es importante que en las acciones del flujo de eventos se defina claramente la información que se intercambia. Si, por ejemplo, en el paso 4 especificamos: "solicita ingresar la información" , el caso de uso estaría mal especificado por incompletitud, ya que no hay forma de saber a cuál información se refiere.
Un error común al definir los casos de uso es utilizar frases como "El usuario ingresa los datos". Está mal porque no se puede saber a qué datos se refiere ni cuáles son las características de esos datos.
Un evento de excepción durante un flujo de eventos implica que el caso de uso se termina sin que el usuario obtenga lo esperado. Esto puede ocurrir porque el Actor cancela el caso de uso o porque ingresa información inválida que no permite continuar. En este caso, se debe indicar claramente qué sucede en el caso de uso. En el ejemplo anterior, en el paso 5, si el Profesor no ingresa un semestre y sección válidos y un código de curso válidos, el sistema debe informar el error hasta que sea corregido o hasta que el Actor cancele el caso de uso. Esto se especifica de la siguiente forma:
| Nombre del escenario | Consultar listado de estudiantes de un curso |
| Actor | Profesor |
| Resumen | Dando el semestre y el código del curso, el profesor obtiene la lista de estudiantes inscritos en él. |
| Curso básico de eventos | |
| 1. El Profesor ingresa al sistema indicando sus datos. | |
| 2. El sistema despliega cada una de las posibilidades del sistema. | |
| 3. El Profesor indica que quiere sacar un listado de un curso. | |
| 4. El sistema solicita ingresar la información del código, sección y semestre de la materia. | |
| 5. El Profesor ingresa 21251, 02, 2018-1. | |
| 6. El sistema devuelve la información correspondiente al curso indican el nombre, carnet, carrera y correo electrónico de cada uno de los alumnos. | |
| Caminos de excepción | En el paso 4. Si el Actor ingresa información del semestre, curso o sección inválidos, el sistema debe informar claramente el error y pedir de nuevo la información. |
Otro ejemplo de un camino de excepción lo tenemos en un caso de uso del cajero automático donde podemos especificar el comportamiento del sistema de la siguiente forma:
| ... | ... |
| Flujo de eventos excepcional | |
| Paso 4: Si el cliente introduce un código de seguridad inválido, el caso de uso vuelve a empezar. | |
| Paso 4: Si el cliente introduce tres veces seguidas un código de seguridad inválido, el sistema cancela la transacción completa, impidiendo que el Cliente utilice el cajero durante 24 horas. |
El propósito de especificar los caminos de excepción es aclarar cómo se van a manejar las acciones erróneas del usuario en la aplicación; cómo responder y cómo debe comportarse la aplicación a partir de ese momento. Esta información será muy útil en la etapa de diseño para considerar adecuadamente la realimentación que se le da al usuario en caso de problemas en la interacción con la aplicación.
Muchas veces es importante definir el estado de la aplicación antes de iniciar el caso de uso. Este estado o más bien, lo que es válido en este estado es lo que llamamos pre condición. Son supuestos que de no ser válidos el caso de uso no podrá tener lugar.
En la siguiente tabla modificamos el caso de uso de banner para incluir como supuesto o pre condición que el profesor ya se encuentra autenticado correctamente en el sistema y tiene permisos para ejecutar este caso de uso.
| Nombre del escenario | Consultar listado de estudiantes de un curso |
| Actor | Profesor |
| Resumen | Dando el semestre y el código del curso, el profesor obtiene la lista de estudiantes inscritos en él. |
| Pre condición | El profesor ya se encuentra autenticado correctamente en el sistema y tiene permisos para ejecutar este caso de uso. |
| Curso básico de eventos | |
| ... |
Las post condiciones sirven para precisar el estado de la aplicación cuando el caso de uso termina de manera exitosa. Es importante definirlas cuando el caso de uso cambia el estado de la aplicación.
Indica que en el flujo de eventos del caso de uso base se incluye el comportamiento del otro caso de uso. Esta relación sirve para Factorizar comportamiento común (NO hacer descomposición funcional) SOLAMENTE se hace cuando la parte común es utilizada por otro caso de uso o cuando es utilizada por otro actor.
Un caso de uso extiende otro caso de uso, si el caso de uso extendido incluye el comportamiento del otro bajo ciertas condiciones. Se utiliza para modelar la parte de un caso de uso que el usuario puede ver como comportamiento opcional del sistema. Por ejemplo cuando retiramos dinero de un cajero automático, el caso de uso "Pedir Donación" extiende el caso de uso "Retirar Dinero".
Esta relación se utiliza cuando tenemos distintas formas de implementar en la interfaz usuario un caso de uso esto es, hay una interacción distinta en cada caso entre el sistema y el Actor. Por ejemplo en el caso de uso " Autenticar un usuario en el sistema", esta autenticación puede hacerse de maneras distintas: con un password, con la lectura de la huella digital. Esto se representa en el diagrama así:
Figura 5
Decimos que el caso de uso Autenticar Usuario es una generalización de los casos de uso Autenticar usuario con password y de Autenticar usuario con huella digital. También decimos que Autenticar usuario con password es una especialización de Autenticar Usuario.
Al final este tema, el estudiante debe estar en capacidad de:
- Leer correctamente un diagrama de clases
- Dadas unas preguntas analizar si a partir de un modelo de clases sería posible obtener la respuesta y explicar las razones.
- Construir, utilizando correctamente la sintaxis, un diagrama de clases de un problema dado.
- Utilizar correctamente Genmymodel para construir los diagramas de clases.
- Interpretar con respecto a la realidad lo expresado en un diagrama de clases identificando información incompleta.
- Analizar un diagrama de clases con respecto a una realidad y construir preguntas para mejorar el entendimiento.
Este material hace parte del curso “MISO4100 Nivelatorio de modelamiento” de la Maestría en Ingeniería de Software
¿Para qué sirven los diagramas de clases?
Sirven para representar aspectos estructurales de un sistema orientado a objetos. Estos diagramas son uno de los 13 tipos de diagramas pertenecientes al estándar UML 2.0
Los diagramas de clase muestran los bloques constructores de un sistema y las relaciones entre dichos bloques. Este mapa de bloques y relaciones se conoce como vista estática del sistema orientado a objetos.
La siguiente Figura muestra un ejemplo de un diagrama de clases:
Figura 1
Este ejemplo modela los elementos principales de una universidad a través de un diagrama de clases. El ejemplo ilustra los tipos de elementos básicos : clases y asociaciones.
Toda clase tiene un nombre explícito que, por convención, debe:
- Comenzar con mayúscula.
- Si es un nombre compuesto por varias palabras, usar CamelCase, es decir, cada nueva palabra empieza por una mayúscula. V.gr., EstudianteUniversitario
Cada clase puede tener uno o varios atributos que aparecen en el segundo compartimento del rectángulo. La clase Estudiante del ejemplo tiene como atributos edad, nombre, género, etc.
Cada atributo se expresa con un nombre, una visibilidad y un tipo de dato. Por convención, el nombre del atributo comienza por minúscula, v.gr., edad. Si el nombre es compuesto se usa CamelCase, v.gr., fechaDeNacimiento.
La visibilidad define si las propiedades de las clases (i.e., atributos y métodos) pueden ser vistas o usadas por otras clases. Los niveles de visibilidad son: público, privado o protegido, los cuales se representan con los íconos +, -, #, respectivamente. En el ejemplo, edad es un atributo privado.
Una propiedad privada puede ser vista y usada sólo por la clase que la contiene. Una propiedad pública puede ser vista y usada por la clase que la contiene y por cualquier otra clase. Una propiedad protegida puede ser vista y usada sólo por la clase que la contiene y por las subclases de ésta.
El tipo de dato de un atributo puede ser primitivo o definido por el usuario. Los tipos primitivos de UML estándar son:
- Boolean,
- Integer,
- UnlimitedNatural,
- String,
- Real.
En el ejemplo, edad es un atributo de tipo Integer. Ver más información sobre los tipos de datos en UML en UML Data Types.
En el tercer compartimento se proponen los métodos de la clase. Cada método tiene también un nombre, una visibilidad, una lista de parámetros y un tipo de dato de retorno.
Por convención, los nombres de los métodos comienzan por minúscula. Si el nombre del método es compuesto se usa Camel Case, e.g., calcularPromedioSemestre.
Al igual que los atributos, los métodos tienen una visibilidad que puede ser pública, privada o protegida.
La lista de parámetros puede tener cero o varios parámetros de un tipo determinado. Si observamos el ejemplo, el método darNombre, de la clase Estudiante, es público, no tiene parámetros y retorna una cadena de caracteres (String). Enla misma clase, el método calcularPromedioSemestre es público. Tiene un parámetro de tipo entero (Integer) y retorna un Real.
El otro elemento importante de los diagramas de clases es la asociación. Una asociación, por definición, relaciona dos clases en el diagrama y se representan usando una línea.
Cada asociación puede tener un nombre. De estar presente, el nombre va en la mitad de la línea que la representa. El nombre de la asociación, por convención: 1) Empieza por minúscula. 2) Si el nombre es compuesto por varias palabras, se usa Camel Case. 3) Es significativo de lo que representa. En la siguiente figura hay dos asociaciones entre la clase Curso y la clase Estudiante: Una para asociar con un curso los estudiantes que lo están viendo (esVistoPor) y otra para representar los estudiantes que asisten como visitantes (visitadoPor).
Figura 2
En el ejemplo de la Figura 1 hay varias asociaciones. Existe una entre Curso y Salón: significa que cada uno de los objetos de la clase Curso está asociado con un (y solo uno) objeto de la clase Salón. Para indicar que sólo un curso y solo un salón están involucrados en la asociación se escribe en el extremo al lado de la clase correspondiente el número 1 (no escribir ningún número significa que la cardinalidad es 1).
En la Figura 2, en las asociaciones esVistoPor y visitadoPor la cardinalidad de la clase Estudiante y de la clase Curso es múltiple (representada por el símbolo *). Significa que dado un objeto de la clase Curso, este tiene una asociación con un conjunto de objetos de la clase Estudiante. En el otro sentido significa que: un estudiante puede estar asociado con varios objetos de la clase Curso.
La cardinalidad del rol puede ser un entero o una expresión. Por ejemplo:
- 1
- 1..5 mínimo 1 máximo 5
- 0..1 cero o uno
- * cero o muchos
- 1..* uno o muchos
En el ejemplo anterior el conjunto de estudiantes destino de la asociación esVistoPor se llama estudiantes. Este nombre se llama el rol de la clase Estudiante en la asociación.
La navegabilidad es indicada por la punta de la flecha. En el ejemplo de la Figura 1, la punta de la flecha indica que en una asociación entre un objeto de la clase Curso y un objeto de la clase Salon, el objeto curso tiene acceso al objeto salón (se toma la dirección hacia la cual apunta la flecha).
De aquí deducimos que Salon no tiene acceso a Curso ya que la asociación no apunta en esa dirección.
La ausencia de punta de flecha en ambas terminaciones de la relación suele significar, generalmente, que hay navegabilidad en ambos sentidos.
La figura 3 muestra los distintos tipos de asociaciones que puede haber entre dos clases en un diagrama de clases UML:
Figura 3
Su notación correspondiente es un rombo vacío. En la Figura 2, la asociación entre Curso y Estudiantes es de este tipo. Supongamos que tenemos los objetos c1 y c2 de la clase Curso y algunos objetos de la clase Estudiante que llamaremos e1, e2 , e3 y e4 Ahora representaremos dos colecciones de estudiantes. Estudiantes1 será una colección asociada, a través de esVistoPor, con el curso c1 y que contiene los objetos e1, e2 y e3. Estudiantes2 será una colección asociada con el curso c2 que contiene los objetos e3 y e4.
Figura 4
Note que el objeto e3 es compartido por las colecciones estudiantes1 y estudiantes2 de los objetos C1 y c2.
Su notación correspondiente es un rombo relleno. En la Figura 2, la asociación entre Universidad y Programa es de este tipo. Significa que si tenemos dos universidades u1 y u2; los programas de la universidad u1 no pueden ser programas de la universidad u2. La Figura 5 ilustra el caso:
Figura 5. Ejemplo asociación "composite" o de agregación fuerte
Decimos que en las asociaciones de agregación fuerte se tienen dos propiedades: 1. Exclusividad (como en el ejemplo anterior) y 2. Existencialidad que significa que si se destruye elk objeto de origen (en el ejemplo u1) se destruyen los objetos destino (en el ejemplo p1, p2 y p3).
- Hacer un diagrama de clases para modelar un sistema de archivos. Un directorio es un archivo que contiene archivos. Los archivos pueden ser terminales o directorios. Cada archivo tiene un nombre y un tamaño.
- Hacer un diagrama de clases para modelar las clases y sus relaciones del siguiente (fragmento) enunciado: " Un concierto de música se presenta en varias funciones, por cada función se sabe el día, la hora y el lugar. Los lugares de los conciertos tienen un nombre y una capacidad. Del concierto se sabe el nombre.
- Hacer un diagrama de clases para modelar un portafolio de obras de arte. Cada obra tiene un tipo (escultura, pintura, video,…), uno o más autores, una fecha de creación, un valor estimado. Adicionalmente cada obra tiene asociado un conjunto de fotografías y/o videos para exhibirla en el portafolio. A partir del portafolio se crean exposiciones de las obras en galerías. Cada exposición tiene unas fechas, un lugar y una descripción. Para una exposición se selecciona un conjunto de obras el portafolio que se van a presentar.
- Una empresa se identifica a través de su nombre y un NIT. Una empresa tiene empleados y departamentos: Un empleado se registra bajo un nombre y se lleva la cuenta de sus años de servicio. Los departamentos reciben un nombre de acuerdo a sus funciones. Los empleados trabajan para un departamento. Adicionalmente un departamento necesita un empleado que ejerza la función de revisor y uno que ocupe la dirección. Los empleados deben estar afiliados al régimen de retiro de la empresa, al que pueden hacer aportes voluntarios u obligatorios. Por otra parte, una empresa cuenta con un Fondo de Empleados, un departamento al que los empleados pueden o no estar afiliados.
- UML 2.1 Tutorial By Sparx Systems
- UML Basics by IBM
- Practical UML by Codegear
- Introduction to the Diagrams of UML 2.0
- UML
Entre los diagramas UML2.0 para representar comportamiento, están los diagramas que hacen énfasis en aspectos de interacción entre los objetos. Estos incluyen diagramas de comunicación, interacción, secuencia y tiempo.
Los diagramas de secuencia permiten modelar la secuencia de interacciones entre distintos objetos para lograr alguna tarea ya sea un escenario de un caso de uso, la lógica de un método o la lógica de un servicio.
En un diagrama de secuencia se representan objetos y no clases. Un objeto se representa con una caja rectangular y una línea punteada que sale de la caja hacia abajo. Se debe indicar la clase dela cual el objeto es una instancia y si se requiere mencionar el mismo objeto en otra parte del diagrama, se le da un nombre. En la siguiente figura, el objeto se llama u1 y es una instancia de la clase Universidad:
Figura 1
La línea punteada que sale de la caja se llama la línea de la vida del objeto (lifeline). Esta línea sirve para definir un orden en las acciones que realiza el objeto (el orden de las acciones van de arriba hacia abajo). Cuando un objeto aparece en un diagrama de secuencia significa que éste está activo en ejecución, es decir que otros objetos se pueden comunicar con él.
La interacción entre los objetos se realiza a través de mensajes que se envían entre ellos. En la figura, el objeto obj3 de la clase Clase2envía un mensaje llamado “mensajeEjemplo” al objeto obj1 instancia de la clase Clase1.
Figura 2
Los mensajes pueden ser de distintos tipos: síncronos o asíncronos, perdidos, encontrados, llamados o señales. Por ahora vamos a focalizar en mensaje síncronos que corresponden a llamados de métodos.
La diferencia en el diagrama está en el tipo de flecha:
Figura 3
En el siguiente ejemplo, decimos que el objeto u1 de la clase Universidad le envía un mensaje al objeto p1 de la clase Programa. En este ejemplo, el mensaje corresponde al llamado del método darNombre(). Este es un mensaje síncrono. Lo que significa que una vez que se ejecute el método darNombre en el objeto p1, la secuencia (el control) regresa al objeto quien hizo el llamado, en este caso el objeto u1.
Figura 4
En la siguiente figura, el obj3 de la clase Clase2 envía un mensaje al objeto obj1 de la clase Clase1. Este mensaje es el llamado del método “nombreMetodo” con sus argumentos arg1 y arg2.
Figura 5
Note que para que, en la figura anterior, este mensaje sea válido, se tienen que cumplir dos cosas:
- El objeto
obj3“conoce” al objetoobj1. - El método
nombreMetodoestá definido en la claseClase1con los parámetros correspondientes para que el llamado sea válido
En el siguiente diagrama de clases, se cumple que todos los objetos de la clase Clase2 tienen una asociación con un objeto de Clase1 llamado obj1. Así, el obj3 conoce al obj1.
Figura 6
Para la segunda condición, podemos observar que el método está efectivamente definido en la Clase1.
El rectángulo delgado en cada una de las líneas de vida de los objetos representa una ocurrencia de ejecución o activación de un foco de control. La siguiente imagen señala, para el ejemplo anterior, que la invocación al método, desde el obj3, ocurrió durante ese foco de control. Durante la ejecución del método en el obj1 se creó un foco de control. Al terminar la ejecución se regresa al foco de control, donde iba, del obj3.
Figura 7
Para representar alternativas o ejecuciones condicionales en los diagramas de secuencia debemos recurrir a los fragmentos combinados.
Un fragmento combinado es un agrupamiento lógico, representado por un rectángulo que contiene la estructura condicional que afecta el flujo de los mensajes.
Figura 8
En la figura anterior, podemos observar la sintaxis básica que es el rectángulo que delimita el alcance del fragmento. El tipo del fragmento se escribe en la parte superior izquierda.
Los fragmentos combinados sirven para representar secuencias de interacción que dependen de que una condición o guarda se cumpla.
Sirven para denotar caminos alternativos, secuencias que se pueden ejecutar en paralelo, secuencias en orden estricto, ciclos de ejecución y varios más.
El caso de uso "crear una película", nos permite ilustrar el uso de un fragmento combinado alternativo. De acuerdo con lo planteado, queremos expresar que sólo crearemos la película en la cartelera si esta no existe. Necesitamos poder expresar que la creación de la película se ejecutará únicamente si la esta no existe
El fragmento se muestra en el siguiente diagrama. Adicionamos una guarda o condición que pregunta si el resultado del método buscarPelicula es igual a null ( lo que implica que la película no existe en la cartelera). Sólo si la condición es verdadera es posible crear un nuevo objeto de tipo Película.
Note que la interacción para la creación está ahora dentro del rectángulo que define el fragmento combinado.
Figura 9
Suponga que ahora nos interesa modelar el comportamiento del caso de uso
“Calcular el número de estudiantes cuyo género es Femenino y que estén inscritas en un curso, dado su código, de un programa dado el nombre del programa.” Hay varias preguntas que debemos hacernos.
- Quién es responsable de saber el género de un estudiante?
- Quién es responsable de saber cuántos estudiantes con género femenino hay en un curso?
- Quién es responsable de encontrar el curso que corresponde a un código dado?
- Quién es responsable de encontrar el programa que corresponde a un nombre dado?
- Quién es el responsable de recibir del actor externo la información del nombre del programa y del código curso sobre el que se quiere saber cuántas mujeres hay?
Al responder las preguntas utilizando el patrón experto, obtuvimos el diagrama de clases actualizado:
Figura 10
Respuestas a las preguntas:
-
"Quién es responsable de saber el género de un estudiante?": la clase Estudiante quien tiene la información.
-
"Quién es responsable de saber cuántos estudiantes con género femenino hay en un curso?. LA clase curso que tiene acceso a la colección de estudiantes inscritos en él.
-
Quién es responsable de encontrar el curso que corresponde a un código dado?. Con esta pregunta decidimos que los cursos son de la
Universidady no de los programas por esa razón se creó una nueva relación a pesar de que con esto se aumenta el acoplamiento. Un curso puede ser dictado en más de un programa. -
Quién es responsable de encontrar el programa que corresponde a un nombre dado?. La universidad quien es la dueña de los programas.
-
Quién es el responsable de recibir del actor externo la información del nombre del programa y del código curso sobre el que se quiere saber cuántas mujeres hay?: La universidad.
Figura 11
El diagrama de secuencia con el fragmento combinado que representa el ciclo es:
Figura 12
Se itera sobre la colección de estudiantes y por cada uno se pregunta el género. Si es valor es F, entonces se cuenta el la variable mujeres. La instrucción estudiante=*next() permite avanzar en el ciclo.