Requisitos
ISIS2603 Desarrollo de Software en Equipos. Uniandes. 2019
Objetivos- Explicar la importancia del proceso de descubrimiento (elicitation en inglés) y análisis de requisitos
- Utilizar el método de casos de uso para documentar los requisitos
- Utilizar los diagramas de clase para modelar el mundo del problema
- Diferenciar entre requisitos funcionales y no funcionales
- Definir términos como: escalabilidad, mantenibilidad, confiabilidad, rendimiento, acoplamiento, cohesión
- Utilizar los diagramas de secuencia para verificar qué casos de uso podrán realizarse con el modelo del mundo
- Reconocer que la documentación de requisitos requiere diferentes niveles de detalle
- Identificar las características del contenido de un documento de definición de requisitos
| Herramienta | |
|---|---|
| www.genmymodel.com | Permite realizar de forma colaborativa diagramas de UML. |
| acceder con el login uniandes. |
Uno de los riesgos más complejos de manejar en el desarrollo de software es el de construir la aplicación que no se necesita; es decir, que no satisfaga lo esperado por el cliente y los usuarios y que no sirva para lo que se esperaba. Si esto sucede, las consecuencias pueden ser económicamente catastróficas. Puede suceder que se descarte el proyecto y se pierda todo el trabajo realizado o que se tenga que rehacer gran parte del mismo.
Hay muchas acciones posibles para mitigar este riesgo y todas pueden ser complementarias. La más importante, porque afecta completamente el ciclo de vida del desarrollo de software, es la de construir incrementos funcionales que puedan ir siendo validados por el cliente y usuarios del sistema. En términos de las metodologías ágiles, significa entregar valor al usuario en un software que funciona y que se puede validar. Si se encuentra que el incremento o alguna funcionalidad no satisface lo esperado, entonces el costo de rehacer será menor que si se tuviera que realizar sobre un software completamente terminado.
Otra acción es realizar las actividades de descubrimiento y análisis de lo que se requiere del sistema de una manera organizada que facilite la comunicación, documentación, análisis y validación de los requisitos.
Definición de RequisitoDe acuerdo con la definición de la IEEE, un requisito es:
-
Una condición o capacidad que un usuario necesita para poder resolver un problema o lograr un objetivo (IEEE).
-
Una condición o capacidad que debe exhibir o poseer un sistema para satisfacer un contrato, estándar, especificación, u otra documentación formalmente impuesta (IEEE).
Otros autores como Robertson, definen requisito de software como algo que el sistema debe hacer o una cualidad que el sistema debe poseer.
Al revisar los requisitos de software, podemos identificar varios tipos:
-
Requisitos funcionales: funcionalidades del software.
-
Requisitos no funcionales: exigencias en otros aspectos del software. Por ejemplo, requisitos en torno a atributos de calidad como rendimiento, tolerancia a fallas y seguridad.
-
Reglas de negocio: validaciones, reglas y normas que deben ser soportadas por el software.
-
Otros requisitos: Otros tipos de exigencias que no pertenecen a las otras categorías. Por ejemplo, tiempos, personal involucrado y presupuestos para el proyecto.
Es el proceso consiste en cuatro actividades (no secuenciales) así:
- Recopilar, descubrir (Elicitation)
- Analizar
- Documentar (Especificar)
- Validar (Lograr un acuerdo con el cliente)
Los pasos anteriores no definen un proceso secuencial. Se trata de un proceso iterativo donde el orden depende de los avances y del entendimiento que se logre con el cliente.
Gradualmente durante estos pasos se va construyendo un documento de definición de requisitos como el que se presenta en el ejemplo Documento Especificación de Requisitos..
Es la obtención y el descubrimiento de los requisitos del software según diversos Stakeholders (constituyentes) y otras fuentes (leyes, restricciones). Las técnicas para realizar esta actividad son las entrevistas, el análisis de documentos, los grupos de discusión, los cuestionarios.
Siempre debemos buscar eliminar las ambigüedades que llevan a interpretaciones distintas del mismo requisito. Los problemas comunes son:
- Requisitos olvidados en particular los no funcionales y las restricciones
- Palabras ambiguas (“pequeño”, “barato”, ...)
- Vocabulario dependiente del contexto del negocio
- Creer que se entendió (el ingeniero)
- Creer que se explicó claro (cliente)
- Pasar por alto lo importante
- Lo necesario vs. lo ideal
- Lo actual vs. el cambio
Un proceso posible para identificar los requisitos es:
| Acción | Descripción |
|---|
| Enunciar el problema | El problema puede ser definido como una diferencia entre cómo las cosas son percibidas y cómo son deseadas. | | Enunciar el propósito | Identificar lo que daría más valor al cliente. | | Modelar el mundo del problema y definir un vocabulario común. | Identificar los conceptos y las relaciones importantes en los elementos del mundo del problema. Por ejemplo utilizando un Diagrama de clases UML. | | Documentar | Explicar los conceptos (clases) y las relaciones en un glosario. | | Entrevistar | VAlidar el entendimiento con el cliente. Obtener más información. |
Analizar los requisitos significa:
- Determinar si los requisitos son los indicados: claros, completos, coherentes, si se podrán probar (testable)
- Resolver los conflictos que puedan surgir entre los involucrados (stakeholders)
Técnicas: abstraer, modelar, identificar funcionalidad, identificar restricciones, características, prototipar, simular, discutir, …
En la [siguiente sección] (#1casos) discutiremos los Casos de Uso como técnica para analizar y documentar los requisitos.
Los casos de uso se utilizan para especificar los escenarios en los que un actor interactúa con la aplicación. Básicamente permite documentar, con mucho más detalle, requisitos funcionales de la aplicación considerando los diferentes escenarios y reglas de negocio que deben implementarse.
Es posible especificar los requisitos funcionales usando casos de uso de una manera gradual. La idea es construir una especificación inicial e irla completando a medida que se avanza en el análisis de los requisitos. Una especificación mínima puede incluir una pequeña descripción e información de las entradas y salidas.
Ejemplo Documento Especificación de Requisitos.
El propósito de validar los requisitos de software con el Cliente es corroborar que el entendimiento sobre lo que se espera que haga el sistema es correcto. De nuevo, buscamos evitar construir el sistema que no se necesita.
Las técnicas para validar los requisitos pueden ser basadas en:
- Inspección de los documentos por parte del cliente y como resultado él reportará sus hallazgos.
- Presentaciones y reuniones y como resultado se discute y argumenta y se trata de llegar a un acuerdo.
- Prototipos en donde el cliente puede ver más fácilmente lo que será la aplicación.
- Una mezcla de las anteriores (esta siempre es la mejor opción).
- El Lenguaje Unificado de Modelado. Grady Booch, James Rumbaugh e Ivar Jacobson. Addison Wesley, 1999 Capítulos 16 y 17
- Object Oriented Software Engineering. . Prentice Hall, 2000. Capítulo 4, pág. 100–106, 118-119
- Karl. E.Wiegers. Software Requirements. Microsoft Press, 1999. Capítulo 9, pág. 153-162. Capítulo 11
- Suzanne Robertson and James Robertson. 2012. _Mastering the Requirements Process: Getting Requirements Right _(3rd ed.). Addison-Wesley Professional.
| Versión | 1.0 Inicial Básica |
|---|---|
| Fecha | Marzo 15 de 2008 |
| Autor | Grupo Los 5 Magníficos |
La librería de la Universidad El Pensador quiere ofrecer a sus usuarios una tienda virtual para sus productos, libros, ropa, cuadernos, esferos, etc.. Quiere contar con un catálogo de la librería en línea donde se pueda hacer búsquedas bajo distintos criterios y adquirir los productos por internet.
Este sistema se ocupará solo de la venta de los libros.
| Concepto | Descripción |
|---|---|
| Book | Libro en la tienda. |
| Author | Autor de uno o muchos libros disponibles en la tienda. Un libro puede tener varios autores. |
| Editorial | representa las empresas Editoriales de los libros. Cada libro tiene una editorial. |
Para este sistema hay dos actores: el usuario _Comprador y el Administrador. _
El Administrador es quien se ocupará de crear la información en el sistema.
| Nombre | Resumen | |
|---|---|---|
| CU1 | Consultar datos de un libro | El sistema permite que un usuario consulte la información de un libro en particular |
| CU2 | Crear un libro | El sistema permite el registro de un libro nuevo en la tienda |
| CU2 | Ver la información de todos los libros | El sistema muestra el catálogo de libros de la librería. |
- No existen dos libros con el mismo ISBN
- No se puede eliminar un autor si tiene algún libro registrado
Algunos requisitos no funcionales, relacionados con atributos de calidad son:
- El software debe soportar varios usuarios trabajando simultáneamente
- La interface usuario debe ser muy intuitiva y agradable.
Entre los otros requisitos, están
- El software deberá funcionar en servidores de aplicaciones Glassfish 4.x y servidores de bases de datos MySQL
- la integración continua debe hacerse con Jenkins
- La administración de versiones debe hacerse en Github
- :
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.
Los 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.
Para 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.
Este libro fue creado para el curso ISIS2603 Desarrollo de Sw en Equipos en la Universidad de los Andes. © Desarrollado por Rubby Casallas con la colaboración de César Forero, Kelly Garcés y Jaime Chavarriaga. Universidad de los Andes, Bogotá, Colombia. 2019